Re-anchor the eight `ADR-0057 D10` citations to the framework's `ADR-0124 D1` — D10 decides Setup-nav capability surfacing, not enforcement location, and the framework's own ADR says so

[os-sales]

Filed by the domain:ui execution seat (seat post #5560) as the follow-up pre-registered by #5202's own triage comment — "filed by whichever seat accepts that PR". #5202's PR is #5699. Filed unassigned.

What #5699 fixed, and what it deliberately did not

#5699 fixed the repo-ambiguity half: seven live sites cited a bare ADR-0057 D10, and in this repo that string resolves to docs/adr/0057-console-ai-chat-one-conversation-docked.md — a document about console AI chat docking that contains no D10 at all. Each site now says whose numbering it means.

It did not fix the anchor half, and this card is that half.

The anchor is wrong, and the framework already documented it

Framework docs/adr/0057-erp-authorization-core-business-units-and-scope-depth.md:422:

D10 — Setup-nav surfacing follows the capability (ADR-0029 K2); the object stays open

That is not the rule these sites cite it for. The same file, at :518, carries a note aimed at exactly this citation:

⚠️ The general rule lives in ADR-0124, not here. The server-side/client-side contrast below is nav-scoped and is the closest ancestor of the platform rule "the server enforces; client-side gating is a usability courtesy" — but D10 decides Setup-nav capability surfacing, not enforcement location in general. If a citation of ADR-0057 D10 brought you here looking for that rule, ADR-0124 is where it is decided (#9628).

And framework docs/adr/0124-server-enforces-client-is-courtesy.md:61:

D1 — The server is the enforcement point; client-side gating is a usability courtesy

ADR-0124 is Accepted 2026-08-18 on the maintainer ruling on objectstack#9628, and landed on framework main as 9dd192d (2026-08-21). #5202's triage originally chose option 2 because #9628's timing was "maintainer-merge-bound and therefore unbounded". It is now bounded and landed — as an independent ADR rather than the anticipated ADR-0057 D13 — so that rationale is discharged.

Scope — eight sites

The seven #5699 touched, plus one it was fenced out of:

1. packages/app-shell/src/views/RecordDetailView.tsx
2. packages/app-shell/src/views/studio-design/PackageOwdOverviewPanel.tsx
3. packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx
4. packages/plugin-detail/src/useRecordEditable.ts
5. packages/plugin-detail/src/useRecordEditable.test.tsx
6. packages/plugin-grid/src/hooks/useRecordCrudVerdicts.ts
7. packages/react/src/hooks/useCapabilityGate.ts
8. packages/core/src/evaluator/fieldRules.ts:38 — carries the framework qualifier already, so Qualify ADR-0057 D10 as the framework's numbering at seven live citation sites #5699 correctly left it alone; it points at the same wrong decision and belongs in this sweep.

Also wrong the same way, and ⛔ a GOVERNED SURFACE: docs/adr/0036-field-conditional-rules.md:91 asserts the framework cites "server enforces, client is courtesy" as ADR-0057 D10. It is the wording all the others derive from, so leaving it re-seeds the error. A PR touching docs/adr/** stops at draft for human merge and must never be flipped ready, enqueued or auto-merged.

⛔ Out of scope, and it is a correct citation: packages/data-objectstack/src/appAccessProbe.test.ts:25. It cites D10 for "an app gated by an absent optional service" — the capability/service-gating family D10 genuinely does decide. Leave it byte-untouched.

Sequencing — read this before starting

The framework has its own D10 citations, and they must not be swept indiscriminately. A meaningful share of them (rest-server's filterAppForUser, the dashboard requiresService gates) are the nav/capability family D10 really does decide and are correct as they stand. The split is per-site and has to be read, not pattern-matched — the same distinction that makes appAccessProbe.test.ts:25 correct here.

Open question for whoever picks this up, which I am not deciding: whether objectui should re-anchor ahead of the framework, or wait. The argument for waiting is that objectui citing ADR-0124 while the framework's own live sites still carry the D10 form inverts the direction the inheritance travels. The argument for going first is that objectui's citations are unambiguously in the wrong family, so they are correct to move regardless of what the framework does with its own. Worth one line from the maintainer before a dev starts.

Clause ② is not tripped

The new anchor is derived from an authority — the framework's ADR-0057 explicitly names ADR-0124 as the destination for precisely this citation, and names the deciding issue (#9628). Derived from an authority → repair, not a new contract decision. No ruling needed for the re-anchor itself; the sequencing question above is separate.

Prior art in this repo

The disambiguation wording now shipping at the eight sites came from docs/adr/0036-field-conditional-rules.md:91 and fieldRules.ts:38. Whoever does this should keep deriving rather than inventing a third phrasing — and should update those two sources in the same sweep so the derivation stays honest.