Skip to content

"ADR-0081 D1" is cited as the source of the default-active-org session hook, but ADR-0081 is the trusted react page tier — the decision behind defaultActiveOrg is anchored to nothing #8474

Description

@os-zhuang

Found while implementing #8247 (PRs #8471 / #8473). Outside both of that card's declared file surfaces — the fix is a citation correction in files I had no reason to rewrite, and re-pointing a cross-reference is a different change class from the ordering fix — so deliberately not fixed there. Filed unassigned and unlabeled; routing and grading are the triage seat's call.

The measurement

packages/plugins/plugin-auth/src/auth-manager.ts attributes the default-active-org session hook to ADR-0081 D1, twice:

518:   * ADR-0081 D1 — default active-org on session create. When enabled
4364:  // ADR-0081 D1 — default active-org on session create. Without it, a user

docs/adr/0081-* is a different record entirely:

$ head -1 docs/adr/0081-trusted-react-page-tier.md
# ADR-0081: A trusted `kind:'react'` page tier — real React executed in the main
  tree, gated by a host capability; and renaming `kind:'jsx'` -> `kind:'html'`

$ grep -ni "activeOrganization|active org" docs/adr/0081-trusted-react-page-tier.md
    (no hits)

The claim being attributed is real, correct and shipped — session.create.before resolving activeOrganizationId from the caller's sys_member row, owner-preferred. Only the cross-reference is wrong.

It propagated, and into a governing record

docs/adr/0093-tenancy-mode-and-membership-lifecycle.md:87 carries the inherited version:

> the ADR-0081-D1 session.create.before hook resolves activeOrganizationId

That is the more serious half: ADR-0093 is the record that actually governs membership lifecycle, so a reader who goes there to find the session hook's decision is sent onward to a page about React pages. Two more sites carry it in test/dogfood prose:

packages/qa/dogfood/test/sharing-rule-org-less-caller.dogfood.test.ts:29
packages/plugins/plugin-auth/src/... (comment blocks referencing "ADR-0081 D1")

Why the ADR-anchor gate does not catch it

pnpm check:adr-anchors verifies that every ADR-NNNN in a tracked file names a record that exists — and docs/adr/0081-* does exist. It cannot check that the record says what the citing file claims. So this citation is green today and will stay green: a wrong-but-existing number is exactly the blind spot between the gate's two audits.

That also makes it worse than a dangling reference, which the gate would catch. A reader following it lands on a real, accepted, plausible-looking ADR and has no signal that they are in the wrong document.

Suggested shape (triage's call)

Establish which record actually holds the decision and re-point every site to it. Two possibilities, and the first step is deciding between them:

  1. ADR-0093 owns it — it is the tenancy-mode / membership-lifecycle record and already describes the hook. If so, the sites become ADR-0093 D<n> and ADR-0093's own line stops citing 0081.
  2. The decision was never recorded — in which case the honest fix is a decision line in ADR-0093 (or its own record), and the code comments point at it. Under Prime Directive [WIP] Add Chinese version of the documentation #13 an undocumented decision is the thing most likely to be reversed by the next author, and this one governs whether a session may exist with no active organization — the exact surface [Decision] What is an authenticated session with NO active organization? Three subsystems answered it three contradictory ways in one shift (fail-open / fail-closed / permanently-invisible ledger rows) #8247 just ruled on.

Either way docs/adr/** is in the diff ⇒ maintainer-merged PR (Prime Directive #14); the code-comment half could be split onto the normal path if wanted.

Dedup

Searched open issues by keyword (ADR-0081, defaultActiveOrg, session.create.before, trusted react page tier) and by path — 0 hits. Closest is #8386 (ADR-0066 crediting ADR-0094 D5 with a claim D5 never makes, inherited by authorization.mdx) — the same family of defect and worth reading alongside, but different documents, different cause, and not a duplicate. #8247 is the card this was found under and does not cover it.

Refs: #8247 / PRs #8471, #8473 · #8386 (related, not duplicate) · ADR-0081, ADR-0093

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions