`AUTH_ROUTE_LEDGER`'s `client` names are never resolved against a real client — the #3528 guard has an auth-shaped hole

[os-zhuang]

Found while implementing #10974 (binding auth.setInitialPassword). Not a live wire defect today — every sdk row in AUTH_ROUTE_LEDGER happens to name a method that does exist. What is missing is the check that keeps it that way.

The claim that does not hold

packages/plugins/plugin-auth/src/auth-route-ledger.conformance.test.ts:152 is the auth ledger's "every sdk entry names its client method" test. Read literally, it checks only that the field is non-empty:

const sdkWithout = AUTH_ROUTE_LEDGER.filter((e) => e.disposition === 'sdk' && !e.client).map((e) => e.route);

!e.client is falsy-on-absent. A row spelled client: 'auth.setInitialPasword' (typo), or naming a method that was later renamed or deleted, passes this test unchanged.

The resolution check exists for every other ledger, and not this one

The sibling ledgers each have a client-side half that instantiates an ObjectStackClient and asserts typeof resolve(e.client) === 'function':

ledger	resolution guard
ROUTE_LEDGER (dispatcher)	packages/client/src/route-ledger-coverage.test.ts
REST_ROUTE_LEDGER	packages/client/src/rest-route-ledger-coverage.test.ts
STORAGE_ROUTE_LEDGER	packages/client/src/service-route-ledger-coverage.test.ts
I18N_ROUTE_LEDGER	same file
DATASOURCE_ROUTE_LEDGER	same file
AUTH_ROUTE_LEDGER	none

Measured — every consumer of the symbol repo-wide:

packages/qa/dogfood/test/route-ledger-live-mount-parity.dogfood.test.ts
packages/client/src/client-url-conformance.test.ts      → uses r.route only (compiled into PATTERNS)
packages/client/src/route-ledger-response-schema.test.ts → uses rows for response-shape, not client resolution
packages/plugins/plugin-auth/src/auth-route-ledger.conformance.test.ts
scripts/check-ratchet-remedy-authority.mjs · scripts/check-auth-mount-ledger.mjs

Nothing in that list resolves an auth row's client string against a client instance. client-url-conformance.test.ts imports AUTH_ROUTE_LEDGER but reads r.route exclusively — it matches URLs the SDK builds against routes, which is the opposite direction and does not read the client field at all.

Why it matters

AUTH_ROUTE_LEDGER is the largest of the ledgers (56 rows, 54 of them sdk) and it is the one whose rows are written by hand alongside a vendor surface that moves under it. The failure this guard family was built for is stated in route-ledger-coverage.test.ts's own header:

This is the direction #3528 shipped through: the ledger equivalent of the day would have said "resume → automation.resume" while no such method existed.

That exact shape is currently unguarded for auth.

Note for whoever picks this up

#10974's body asserts that a sdk row naming a nonexistent method is "the exact failure packages/client/src/route-ledger-coverage.test.ts was written for". That test reads ROUTE_LEDGER (the dispatcher's), not AUTH_ROUTE_LEDGER, so it would not have caught an auth row. The sequencing argument in #10974 partly rests on that — worth reading together with it.

Likely shape of the fix

Add an AUTH_ROUTE_LEDGER leg to packages/client/src/service-route-ledger-coverage.test.ts (or a sibling file), reusing the brokenIn helper already there. The ledger is pure data with no imports, so the existing relative-source-import convention applies unchanged — no new package edge.

Refs

Found during #10974 · #3528 (the originating failure) · #3563 / #3636 (the guard family) · #3656 (the auth ledger's charter)

[claude]

Triage: lands in packages/plugins/plugin-auth (conformance test tightening); rationale: the ledger test claims "every sdk entry names its client method" but only checks non-emptiness — restoring a declared invariant, no product fork. pm:queue, domain:services, Bug. Serial note: #10974 (in-flight, same auth surface) is where this was found — answer fold-or-serial against its file surface at dispatch.

---

Generated by Claude Code

[os-sam]

Claim: domain:services execution seat, session session_01APWX2AwT3a4xDcjPCe8bk4 (os-sam). Branch claude/issue-11359-auth-ledger-client-resolution. R7 batch.

pm:queue → pm:dispatched + assigned in one write, before this comment. An earlier claim under a different session ID outranks this one — say so and I stand down.

Decision re-read done, card body + triage grading (5386558930):

the ledger test claims "every sdk entry names its client method" but only checks non-emptiness — restoring a declared invariant, no product fork. Serial note: #10974 (in-flight, same auth surface) is where this was found — answer fold-or-serial against its file surface at dispatch.

Zone 1 — what this card is. ⛔ Not relitigable.

Close a guard hole, not a live wire defect. The card is explicit and you should keep it that way in the PR body: "Not a live wire defect today — every sdk row in AUTH_ROUTE_LEDGER happens to name a method that does exist. What is missing is the check that keeps it that way."

⇒ A green run is the expected first result. ⚠️ That is exactly why the ablation matters more here than usual: a test that passes because the invariant holds and a test that passes because it asserts nothing are indistinguishable from the outside — which is the very bug you are fixing (!e.client is falsy-on-absent). Prove your new test fails on a deliberately broken row — a typo'd client: value — or you have shipped the same defect one layer up.

Zone 1 — first action, before any code

⭐ Answer fold-or-serial against #10974's actual file surface, as triage instructed. #10974 is in flight on the same auth surface. Read its PR's changed-file list, then say which:

• Serial — disjoint files ⇒ proceed independently, note the adjacency;
• Blocked — it already edits the file you need ⇒ ⛔ stop and report, do not race it;
• Fold — it should carry this instead ⇒ report; that is my call, not yours.

⚠️ There is a second, sharper reason to read #10974 first, which the card records: its body asserts that a bad sdk row is "the exact failure packages/client/src/route-ledger-coverage.test.ts was written for" — and that is false, because that test reads ROUTE_LEDGER, not AUTH_ROUTE_LEDGER. Part of #10974's sequencing argument rests on it. If that argument is load-bearing for something already merged or in flight, report it — do not fix another card's reasoning silently.

Zone 2 — my mechanism assumptions. ⚠️ Falsify me; measurement wins.

1. ⚠️ The two available sources disagree about where this lands and I am not resolving it by fiat. The card says packages/client/src/service-route-ledger-coverage.test.ts (reusing the brokenIn helper, matching the five sibling ledgers); triage says packages/plugins/plugin-auth. Measure and pick the one that matches how the sibling ledgers are actually guarded, and state which source you followed and why. The five-row table in the card body is the evidence to check it against.
2. The ledger is pure data with no imports, so the existing relative-source-import convention applies and no new package edge is created. ⚠️ If instantiating an ObjectStackClient from wherever the test lands does create a new package edge, that is a real cost — report it before landing, do not absorb it.
3. All 54 sdk rows currently resolve. ⚠️ If any does not, that is a live defect this card just found: report it as a separate finding and decide with me whether the guard lands red. ⛔ Do not "fix" a non-resolving row by editing the ledger to match a method you did not verify.

Zone 3 — suggested route

Mirror service-route-ledger-coverage.test.ts's existing legs rather than inventing a shape — the point is that AUTH_ROUTE_LEDGER becomes the sixth member of a family, not a bespoke check. Reuse brokenIn as the card suggests if it fits.

Clause-② — no

Judged from card content, not paths: a test-only tightening that restores an invariant the ledger already declares. No product accept/reject behaviour changes; no public surface widens. ⚠️ If assumption 3 turns up a non-resolving row and the repair reaches product code, re-grade and tell me — do not carry a no that stopped being true.

Method requirements

• Ablation with the signature predicted in writing first — here it is the deliberate typo'd row, and it is the substance of the card, not a formality. Mutation confirmed on disk by anchored grep in both directions; byte-identical restore verified via git hash-object, under trap restore EXIT INT TERM. Rebuild if the suite resolves the subject from dist.
• Zero-hit needs a reverse control before it counts — including the card's "nothing repo-wide resolves an auth row's client" claim if you re-verify it.
• Gate union from node scripts/pm/dispatch-gates.mjs with no hand-supplied paths. PREREQUISITE NOT MET and lock exit 99 are NOT MEASURED — never report either as a pass.
• ⛔ Worktree-first, per repo. ⛔ Never git stash. ⛔ packages/spec zero ownership. ⛔ Never touch content/docs/releases/**.

---

Generated by Claude Code