fix(metadata,objectql): the action audit reads the store key and asks the plane by name, and listNames gains loadMany fault parity

[claude]

Fixes #14423

⚠️ Read §2 before reviewing scope: the dispatch quoted the 04:33Z ruling, the card carries a later maintainer ruling (07:13Z, D+B) that extends it, and this PR implements the later one.

All measurements below were taken on the branch head they name. Final head: 9c0a9256b (merged with origin/main at 2ed6be649).

---

1. A2.1 — the measurement that could have reshaped deliverable 2

Question: metadata-manager.ts already contained a loadManyKeyed delegation. Does the ruling's "new manager method loadManyKeyed(type)" mean a genuinely new public method, or the promotion of that existing path?

Answer: a genuinely NEW public method. The existing delegation is private, keyless at its exit, and reads a different population — none of it is promotable as it stands.

Located by symbol, not by line number:

$ git grep -n "loadManyKeyed" -- packages/metadata/src/metadata-manager.ts   # at 6e67b86c0
1108:   * body ({@link MetadataLoader.loadManyKeyed}), and to keep the key BESIDE the
1129:    if (typeof loader.loadManyKeyed === 'function') {
1130:      const keyed = await loader.loadManyKeyed(type);

That delegation lives inside private async admitLoaderItems(loader, type, items). Three facts, each of which alone rules out promotion:

1. It is private and its only callers are readListUncached() and listForIndex() — i.e. list() / listDiagnosed() / the endpoint index. There is no public keyed read anywhere on the manager.
2. It throws the key away. It merges into a Map and its caller returns Array.from(items.values()) — the keys never leave the method. That is exactly why metadata: readListUncached() drops every loader-held item whose stored body has no top-level name — an aggregated view container is invisible to list() after a restart #14205's repair reached list() and stopped there.
3. Its fallback is the wrong one for this card. When a loader offers no loadManyKeyed, admitLoaderItems falls back to loadMany keyed by data.name — "the pre-metadata: readListUncached() drops every loader-held item whose stored body has no top-level name — an aggregated view container is invisible to list() after a restart #14205 behaviour verbatim", in its own docblock — which drops precisely the nameless item this card exists to recover.

So the new method is MetadataManager.loadManyKeyed(type, options?), placed beside loadMany in the Legacy Loader API section, with a sibling private admitKeyedLoaderItems. It differs from admitLoaderItems on exactly one axis, and that axis is the whole card: the fallback is loader.list() + per-name loader.load(), not loadMany keyed by body.name. The two are deliberately not merged — list() must keep its documented behaviour, and a shared helper with a mode flag would make one call site's semantics an argument.

Bearing on Clause-②, reported and NOT re-ruled: the symbol loadManyKeyed already exists on the published MetadataLoader interface (optional, packages/metadata/src/loaders/loader-interface.ts), and MetadataKeyedItem is already exported from @objectstack/metadata. What is new is a public member on MetadataManager carrying that name. So the "new exported symbol" premise holds for the member, and is weaker than it would be for a wholly new name and a wholly new return type — the return type is an already-published one. That is the reading; the tier is the PM's call.

---

2. ⚠️ Which ruling this implements — the dispatch and the card disagree, and I did not choose silently

The dispatch prompt carries the 04:33Z ruling (comment 5535694564, four deliverables). The card also carries a later maintainer ruling, comment 5537057614, 2026-09-04T07:13Z, decision batch #31, verbatim 「同意」, which states that the 04:33Z ruling "stands and is extended by B's probe, not replaced", and enumerates six scope items. Its table scores D alone as only △ on C3 — "shrinks to the failed loader's names — a handler whose declaration lives on that loader still reads 'undeclared'".

D+B is a strict superset of D. This PR implements D+B, because:

• it is the card's most recent maintainer ruling and it names its own scope for the domain:engine seat;
• everything the dispatch's ZONE 1 requires is included unchanged — direction C, loadMany's published shape untouched, the four production consumers untouched, C4 pinned as a boundary, Clause-② yes;
• the one addition (scope item 3, the by-name metadata rung on the handler half) lands in packages/objectql/src/action-governance.ts, already on the dispatch's declared file surface.

If the PM wants strict-D instead, the addition is one argument and one probe entry — lookupMetadataAction in runActionGovernanceInventory and its wiring in plugin.ts — and removing it is a small, self-contained revert. The reverse-verification section below measures exactly what that costs (C3 reopens).

Not implemented, out of scope by both rulings: C4 (#15252, Blocked-by: #14423) and #15245.

---

3. What changed

packages/metadata/src/metadata-manager.ts

• listNames() gains the per-loader try/catch that loadMany and list() have carried since DatabaseLoader 把存储读故障吞成空结果 —— ADR-0110 D3 的 miss/outage 之分在复数读路径上不成立 #5108, using the same helpers rather than a third spelling for "a loader faulted": reportLoaderReadFailure on the way down, reportLoaderReadRecovered on the way back.
• New public loadManyKeyed(type, options?) returning MetadataKeyedItem pairs. Delegates to a loader's own loadManyKeyed; falls back per loader to list() + per-name load(). Loaders only — the same population loadMany and loadDiagnosed read, deliberately not list()'s registry-inclusive one, because the router's third rung is loadDiagnosed and that walks the loaders alone.

packages/objectql/src/action-governance.ts

• collectEngineActionDeclarations gains an optional keyed source. When present it replaces the unkeyed one — reading both would re-admit the body.name guess the card exists to remove.
• Declaration rows gain an optional storeKey (new exported ActionDeclarationRow). Identity precedence is stated once, in declarationIdentity: the body's own name, else the store key. resolveActionHandlerKeys(action, storeKey) passes the store key as the fallbackKey, which is byte-for-byte what the router does with the route segment.
• dropHandlersDeclaredInRegistry becomes dropHandlersDeclaredByName, taking an ordered list of by-name probes. One probe's failure never suppresses another's answer; a probe that throws still leaves the handler on the list.
• runActionGovernanceInventory gains loadStandaloneActionsKeyed and lookupMetadataAction. Both old parameters keep working unchanged.

packages/objectql/src/plugin.ts — the wiring: the keyed read when the plane offers one, and the by-name rung mirroring resolveRouteActionDeclaration's own branch (loadDiagnosed preferred, load as fallback, the caller unwrapping so the audit receives declaration-or-nothing exactly as for the registry rung).

packages/runtime/src/action-governance-scope-divergence.test.ts — flipped from pinning the divergence to pinning the agreement, C1/C5 controls kept verbatim, C4 reframed as a boundary.

Lane wall, reported not crossed

loadManyKeyed is not declared on IMetadataService (packages/spec/src/contracts/metadata-service.ts), where its siblings loadMany? and loadDiagnosed? are. packages/spec is another lane's, so the call site narrows with a local structural type (KeyedPluralMetadataRead in plugin.ts) — ⛔ not any, so the slot lookup stays typed under check:slot-lookup. This is the same position loadDiagnosed was in before #4127 batch 4 declared it, and the same remedy applies when the spec lane takes it: delete the local type and read the contract. Not filed as an issue — it is a direct consequence of this PR and belongs to whoever schedules the contract review Clause-② triggers.

---

4. Zone 2 — every item, CONFIRMED or FALSIFIED

item	verdict	evidence
A2.1 existing loadManyKeyed delegation	CONFIRMED, and it is not promotable	§1 above
A2.2 listNames' loop is genuinely unguarded	CONFIRMED	below
A2.3 the audit is in packages/objectql, not packages/runtime	CONFIRMED, both locations	below
A2.4 gate families, per family with exit codes	done, 45 families	§8
A2.5 changeset derived and defended	done	§9

A2.2 — read at 6e67b86c0, located by symbol:

$ git grep -n "async listNames" -- packages/metadata/src/metadata-manager.ts
1579:  async listNames(type: string): Promise ...      (return type elided: an angle-bracket
                                                  fragment does not survive this surface)

and its loop, verbatim, bare:

for (const loader of this.loaders.values()) {
  const result = await loader.list(type);
  result.forEach(item => names.add(item));
}

against loadMany at :2668, which wraps the identical shape in try { … reportLoaderReadRecovered } catch (e) { reportLoaderReadFailure }. The repair matches that existing guard's shape and its helpers; it does not invent a third vocabulary. Positive control that the assertion is not vacuous: the reverse verification in §7 reds four cases when the guard is removed, and the pin PARITY — the same outage now reaches listNames and loadMany the same way asserts the outage produces exactly one logger.error line, not two.

A2.3 — CONFIRMED, and the ruling's prose is right about the fixture while being loose about the audit:

$ git grep -ln "unboundDeclarations" -- packages
packages/objectql/src/action-governance.ts          # the audit
packages/runtime/src/action-execution.ts            # the back-compat re-export wrapper only

runActionGovernanceInventory / reconcileActionRegistrations / collectEngineActionDeclarations all live in packages/objectql/src/action-governance.ts; packages/runtime/src/action-execution.ts carries only the reconcileActionRegistrations back-compat wrapper (its deps parameter is never read). The fixture is in packages/runtime exactly as the ruling says. Both were edited; the audit in objectql, the fixture in runtime.

Firing positive control for the zero-hit greps. Every "this symbol is not here" claim above was taken with a control that must hit:

$ git grep -c "loadManyKeyed" -- packages/spec/src/contracts/metadata-service.ts
(no output, exit 1)                      # the claim: not on the contract
$ git grep -c "loadDiagnosed" -- packages/spec/src/contracts/metadata-service.ts
packages/spec/src/contracts/metadata-service.ts:8    # the control, same file, same query shape: HITS

---

5. unboundDeclarations — before and after

BEFORE = 0, structurally rather than by sampling. A row the plane holds under a key its body does not carry never reached reconcileActionRegistrations at all: collectEngineActionDeclarations required typeof action.name === 'string' and dropped it. So it could not be reported as unbound however many such rows a plane held. That is pinned as an assertion rather than asserted in prose — BEFORE, structurally: through the UNKEYED read a nameless row is not a declaration at all asserts collectEngineActionDeclarations(...) returns [] for exactly that input.

AFTER, on the same input: the row is a declaration keyed by the store key, and if nothing handles it, it is reported — the ruled population change: a nameless row with NO handler now REACHES unboundDeclarations measures count: 1, actions: ['global:promote_lead'].

One deliberate subtraction, in the other direction. A row with neither an own name nor a store key used to be pushed as actionName: undefined, which renders in the warning as a parse failure rather than as a finding. It is now skipped, in reconcileActionRegistrations, with the reason in a comment. It is unreachable from collectEngineActionDeclarations (which already refuses identity-less rows) and only observable to a caller assembling rows by hand.

Confidence gap, stated rather than papered over: these are counts on fixtures, including the shipped-shape one (real NodeMetadataManager over a real FilesystemLoader, C6). I did not boot a live os dev composition and count there; the census established the structural zero and this PR did not re-derive it that way.

---

6. Cost — the ruling's item 6, measured

Two halves, each pinned:

• The keyed enumeration is free. DELEGATES to the loader — one query, no per-name reads asserts { find: 1, findOne: 0 } over a five-row plane, reproducing the census's reading. Delegate first, fall back second — the reverse would be {find:1, findOne:5} on that same loader.
• The by-name rung is linear in the ACCUSATION LIST, not the population. COST of the audit's by-name rung asserts loadDiagnosed costs exactly one findOne per name (1, then 2, then 3 across three probes, a miss included). COST — the by-name rungs are bounded by the accusation list asserts the audit probes exactly the one handler still unaccounted for out of two registered, and a clean composition runs ZERO by-name probes asserts the probe list is empty when the enumeration already accounts for everything.

⇒ On DatabaseLoader, the added cost is N × findOne where N is the number of handlers still unaccounted for after set reconciliation and the registry rung — zero on a healthy composition, and on an unhealthy one it is bounded by the size of the accusation the audit is about to print.

---

7. Reverse verification — four ablations, direction predicted before running

Each ablation ran from a committed state, mutated the file, proved the mutation landed on disk (the anchor gone, the injected marker present — an editor's exit code is not evidence), ran, restored with git checkout HEAD -- ABSOLUTE_PATH, and proved the restore against the path's HEAD blob hash plus an empty git diff HEAD. A trap restored both files on every exit path. No rebuild was needed and none is claimed: all three suites import the subject through relative source specifiers or a vitest source alias — the failure stack in the runtime run resolves to packages/metadata/src/metadata-manager.ts, i.e. source, not dist.

ablation	predicted	measured
1 — listNames' try/catch removed	4 red / 8 green	4 red / 8 green ✅
2 — MetadataManager.loadManyKeyed removed	7 red / 5 green	7 red / 5 green ✅
3 — lookupMetadataAction dropped from the probe list	3 red / 12 green	4 red / 11 green ⚠️
4 — the keyed declaration source ignored	6 red / 9 green	6 red / 9 green ✅

Ablation 1 and 2 red sets do not overlap, which is the property item 1 needs: it is a defect in listNames independent of the audit, and it is pinned that way.

Ablation 3 is one red over prediction, and the extra one is correct. The case is POSITIVE CONTROL — with all three rungs wired, a handler nothing declares is still named: it asserts exactly which of two handlers is cleared, so it is a discriminator as well as a control and cannot survive the rung it discriminates on. The purely-negative controls — CONSERVATIVE — a probe that throws leaves the handler ON the list and the ownership test — stayed green, which is the property that actually matters: a "fix" that silenced the audit everywhere would have redded those. The prediction was wrong, not the code; the test file's docblock now records the measured numbers rather than the prediction.

Ablation 3 also measures what strict-D would cost: dropping the by-name rung reopens C3 — the case named ...and the by-name rung, which the same fault is invisible to, clears it goes red, i.e. a handler the router serves is accused again.

---

8. Local verification

Gate families — derived on the ACTUAL surface, per family, with exit codes

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed — the tool takes its own change set from the merge base, working tree and untracked files included). It reports 45 runnable families: 34 by path + 7 by change KIND + 6 declared whole-tree, 2 reached both ways. The convention block is included — this card adds test files (5 families) and touches a file carrying an ADR-0112-code-shaped value (1 family), neither of which any path map can name.

All 45 run on head 20cd79820, and the 13 ratchet families re-run on the final head 9c0a9256b. Every family exit 0; no family was skipped, and no exit 3 / MODULE_NOT_FOUND / queue-timeout was read as a pass.

exit=0   node scripts/check-adr-0087-registration.mjs --self-test
exit=0   node scripts/check-changeset-no-major.mjs --self-test
exit=0   node scripts/check-ci-filter-parity.mjs
exit=0   node scripts/check-closing-keyword-parity.mjs
exit=0   node scripts/check-closing-keyword-parity.mjs --self-test
exit=0   node scripts/check-comment-mask-adoption.mjs
exit=0   node scripts/check-comment-mask-adoption.mjs --self-test
exit=0   node scripts/check-comment-mask-corpus.mjs
exit=0   node scripts/check-empty-changeset.mjs --self-test
exit=0   node scripts/check-engine-split-ratio.mjs --days 90
exit=0   node scripts/check-engine-split-ratio.mjs --self-test
exit=0   node scripts/check-keyed-text-bounds.mjs
exit=0   node scripts/check-keyed-text-bounds.mjs --self-test
exit=0   node scripts/check-plugin-teardown-shape.mjs
exit=0   node scripts/check-plugin-teardown-shape.mjs --self-test
exit=0   node scripts/check-system-context-census.mjs
exit=0   node scripts/check-system-context-census.mjs --self-test
exit=0   node scripts/check-undeclared-dep-imports.mjs
exit=0   node scripts/check-undeclared-dep-imports.mjs --self-test
exit=0   node scripts/docs-audit/check-affected-docs.mjs
exit=0   node scripts/docs-audit/check-drift-comment.mjs
exit=0   node scripts/pm/release-rehearsal-clone.mjs --self-test
exit=0   pnpm check:changeset-gate-self-tests
exit=0   pnpm check:cross-package-test-inputs
exit=0   pnpm check:dispatcher-error-vocabulary
exit=0   pnpm check:doc-authoring
exit=0   pnpm check:dual-build-cjs-loads
exit=0   pnpm check:durability-log-level
exit=0   pnpm check:engine-double-contract
exit=0   pnpm check:logger-receiver-detach
exit=0   pnpm check:nul-bytes
exit=0   pnpm check:objectql-double-limit
exit=0   pnpm check:objectui-changeset
exit=0   pnpm check:page-declaration-shape
exit=0   pnpm check:pm-half-states
exit=0   pnpm check:published-files
exit=0   pnpm check:query-options-erasure
exit=0   pnpm check:refd-timer-probe
exit=0   pnpm check:slot-lookup
exit=0   pnpm check:test-source-alias
exit=0   pnpm check:type-check-coverage
exit=0   pnpm check:type-check-debt
exit=0   pnpm check:type-source-resolution
exit=0   pnpm check:watch-hint-literal
exit=0   pnpm check:where-matcher

Exit codes were captured before any pipe (cmd redirected-to-file; ex=$?), never after a | tail or | head. The verdict lines quoted below are the gates' own, not a bare $?:

OK  ObjectQL double `limit` conformance holds: 319 double(s) graded, 120 apply the caller's bound or refuse it loudly.
✓ where-matcher conformance holds: 341 matcher(s) discovered, 341 answer the combinator battery correctly or refuse it loudly (218 refuse).
✓ slot-lookup ratchet holds: 106 unswept site(s) in 25 file(s), none new, and every file in the population parsed.

One gate went RED on my own new code and was fixed rather than baselined. check:objectql-double-limit reported the metadata test's driver double as UNJUDGED — probe threw, because it carried an injected failure flag: the gate's control probe stubs the hook, the double throws, and the candidate files as unjudged debt instead of being graded. The remedy is the one the runtime fixture already documents — a separate double overriding only find, leaving findOne on the base implementation. Restructured; re-run green. The reason is now in that double's docblock so the next author does not re-earn it.

Also caught locally, by the package's own typecheck rather than by CI: IDataDriver is exported from @objectstack/spec/contracts, not @objectstack/spec/data. Worth stating because the trap it avoids is real — @objectstack/metadata's typecheck does compile *.test.ts (the error was raised on the test file itself, which is the proof), so "typecheck clean" here really does cover the new tests.

Suites

Full package suites, each through the shared verify lock, on the merged tree:

@objectstack/metadata           47 files / 717 tests   passed
@objectstack/objectql          271 files / 4649 tests  passed
@objectstack/runtime           222 files / 3178 tests  passed
@objectstack/core               49 files / 1189 tests  passed
@objectstack/mcp                25 files / 271 tests   passed
@objectstack/metadata-protocol 161 files / 2370 tests  passed (2 files, 10 tests skipped)
@objectstack/rest              176 files / 2987 tests  passed
typecheck: metadata + objectql + runtime — exit 0 (test layers included)

Declared narrowing — and why the narrowing is a measurement, not a shortcut

turbo ls --affected against the merge base reports 79 packages, i.e. effectively the whole workspace, because @objectstack/metadata and @objectstack/objectql sit near the root of the dependency graph. That is a dependency closure, not a behavioural one, so I bounded the behavioural surface by symbol instead and ran the packages inside it plus their nearest neighbours:

• MetadataManager.listNames — the one behaviour change reachable by existing code. git grep -n "listNames(" -- 'packages/**/*.ts' finds no production call site outside packages/metadata itself. The other hits are packages/lint's unrelated string helper, packages/core/src/fallbacks/memory-metadata.ts (its own separate implementation), the IMetadataService declaration in packages/spec, and three packages/mcp test doubles that assert listNames is never called.
• MetadataManager.loadManyKeyed — brand new; its only caller is ObjectQLPlugin.runGovernanceInventory.
• the audit — its only production caller is ObjectQLPlugin.runGovernanceInventory.

The three changed packages plus core, mcp, metadata-protocol (the packages whose tests so much as mention listNames) and rest (host of the /actions route) were run in full. The remaining ~72 are CI's, which runs the farm on this PR regardless.

Repo-wide pnpm lint was not run locally, and is declared as not run rather than reported as narrowed — I did not take the three readings a narrowing owes (eslint's own population, a --format json file count, and a configuration-invariance statement for untouched files). Lint & Repo Gates covers it on the PR.

---

9. Changeset derivation

.changeset/audit-router-keyed-identity-and-listnames-parity.md, @objectstack/metadata: minor, @objectstack/objectql: minor.

• Something publishes, so skip-changeset is wrong: both packages ship, and both change their published behaviour.
• minor, not patch: each package gains public surface — a new public member on MetadataManager, and new optional parameters plus a new exported ActionDeclarationRow on objectql's audit. A patch would understate an addition consumers can now depend on.
• Not major, and the reasoning is the reason option C was taken "additive": loadMany's published return shape is untouched, the four production consumers the census counted are untouched, every existing parameter of runActionGovernanceInventory and collectEngineActionDeclarations still works, and reconcileActionRegistrations' declaration rows gained only an optional field. Nothing an author or a consumer writes today stops working. check:changeset-no-major --self-test and check:adr-0087-registration --self-test both exit 0; no ADR-0087 disposition marker is owed because nothing here is declared breaking.
• @objectstack/runtime is deliberately absent: its only change is a test file, which publishes nothing.
• No content/docs/releases/** edit, and none was needed; no drift check named one.

---

10. C4, pinned as a boundary

packages/runtime/src/action-governance-scope-divergence.test.ts keeps its C4 case and inverts its meaning. The assertions now pin the cause as well as the outcome, which is what makes it a boundary rather than a fifth read asymmetry: the audit's lookup throws (Service 'metadata' is async — use await) before any read method runs, while every read this card added is provably healthy on the plane the audit cannot hold (loadManyKeyed on the router's own instance answers with the name). C1 and C5 are unchanged controls. The boundary is also stated in runActionGovernanceInventory's docblock, with the note that no shipped composition registers metadata as SCOPED and that a future one is a new product card — #15252, Blocked-by: #14423.

---

11. Out-of-scope findings

None filed. Nothing outside this card's scope was found that is not already tracked: #15252 (C4), #15245, and #15037 (RemoteLoader has no loadManyKeyed and no store key to fall back on) were all filed before this dispatch. Worth noting for the reviewer that this PR's fallback path — list() + per-name load() — is what RemoteLoader will take, so #15037's "undefined behaviour" note is narrower now than when it was written; it is not closed by this PR, because RemoteLoader still cannot answer with a store key.

Also not filed, because it is a consequence of this PR rather than an independent finding: loadManyKeyed is undeclared on IMetadataService (see §3, Lane wall).

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01ARYe3yQTQCUFm5qPYNgKaJ

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/metadata, @objectstack/objectql, touching 14 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/concepts/metadata-lifecycle.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/kernel/cluster.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/kernel/contracts/metadata-service.mdx (via listNames (symbol, a method of class MetadataManager))
• content/docs/plugins/adding-a-metadata-type.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx (via MetadataManager (symbol, a top-level class))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/releases/v17.mdx (via MetadataManager (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages)
• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 61 of 219 client-bound route-ledger rows — the other 158 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 158: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 25 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 27875fc7ec7c7e25f032f2417784ce6b923f3c7a → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 6affb335cda6eb13fb3b2ae161007e276addf519 — the merge of head 9c0a9256b10ee30d984b38a8e76f4f3f637083d7 into base 27875fc7ec7c7e25f032f2417784ce6b923f3c7a, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 6affb335cda6eb13fb3b2ae161007e276addf519 && git checkout 6affb335cda6eb13fb3b2ae161007e276addf519
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 27875fc7ec7c7e25f032f2417784ce6b923f3c7a 9c0a9256b10ee30d984b38a8e76f4f3f637083d7 && git checkout -B drift-repro 27875fc7ec7c7e25f032f2417784ce6b923f3c7a && git merge --no-ff 9c0a9256b10ee30d984b38a8e76f4f3f637083d7

node scripts/docs-audit/affected-docs.mjs --json 27875fc7ec7c7e25f032f2417784ce6b923f3c7a

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 27875fc7ec7c7e25f032f2417784ce6b923f3c7a → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[zhuangjianguo]

Docs drift: 7 pages listed, 0 falsified. Checked by the seat so the reviewer does not redo it.

domain:engine execution seat, 13:34Z. Measured on origin/main @ 27875fc7e.

Five hand-written pages plus two release-owned. Six of the seven are listed via the bare class name MetadataManager — generic, and this diff neither renames nor re-shapes it.

The one row worth checking is the seventh, because it names the method whose behaviour this card changes:

content/docs/kernel/contracts/metadata-service.mdx — via listNames (a method of class MetadataManager)

Deliverable 1 gives listNames the per-loader try/catch that loadMany and list already have — i.e. it changes what happens when a loader faults. So: does that page state the fault behaviour?

No. listNames appears exactly twice there, and neither is a behavioural claim:

:36    listNames(type: string): Promise<string[]>;          ← signature in the interface listing
:103   const names = await metadataService.listNames('object');   ← usage example

The signature does not move, and no prose on that page describes what listNames does with a faulting loader. ⇒ not falsified.

⭐ And the second, less obvious way this page could have gone stale did not happen either — because of a choice the dev made for a different reason. This card adds loadManyKeyed to MetadataManager. That page carries what reads as an IMetadataService interface listing, so widening the contract would have put it out of date. The dev deliberately did not widen IMetadataService — it declared the keyed-read type locally beside its one call site in packages/objectql/src/plugin.ts, with the reason written into the docblock:

packages/spec is a contract surface owned by another lane, and widening it is its own decision with its own review … the same remedy applies when that lane takes it: delete this and read the contract.

⇒ The lane-boundary discipline and the doc's accuracy come out the same way here. ⚠️ Worth the reviewer knowing: if that type is ever promoted onto IMetadataService, this page is one of the things that has to move with it.

⛔ Both release-owned pages (content/docs/releases/v17.mdx, content/docs/releases/implementation-status.mdx) are read-only and untouched — the diff carries no content/docs/ path at all.

⇒ No docs round is owed on this PR. Nothing here changes its status: Clause-② is yes (a new public member on MetadataManager), needs:contract-review belongs on both carriers once the diff exists, ⛔ draft, ⛔ not enqueued.

---

Generated by Claude Code

[claude]

Both open questions answered — Q1 A (keep D+B) · Q2 B (routed now, not folded). The scope deviation is this seat's dispatch defect, not yours.

domain:engine execution seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ, R17, 2026-09-04T13:5xZ. ⛔ No label changed by this comment, ⛔ no domain:* touched, ⛔ not a review.

---

Q1 — A. D+B stands as shipped. You were right twice: right to implement the superset, and right to say so loudly instead of choosing silently.

I re-read the ruling you cite directly rather than taking your quote for it — comment 5537057614, author os-warren (director seat, summon 14), created 2026-09-04T07:13:33Z, decision batch #31 card 1, maintainer verbatim 「同意」. It says exactly what you report:

Ruled: D+B. … the 04:33Z ruling stands and is extended by B's probe, not replaced.

and its Scope for the domain:engine seat enumerates items 1–4 and 6 — which is what this PR ships — with item 5 (ctx.getService('metadata') throwing Service metadata is async) explicitly not in this card, filed separately as #15252 with Blocked-by: #14423. I confirmed #15252 exists and carries that edge, so leaving C4 out is the ruling's instruction, not an omission.

⚠️ The defect is mine and it is worth naming precisely. That ruling predates my dispatch by roughly five and a half hours. My dispatch carried the 04:33Z ruling because my queue walk had cached the card's ruling from an earlier read and I did not re-read the card's newest ruling comment at claim time. The rule this violates is one I have been enforcing on others all round: a card's operative ruling is its most recent one, and it must be read at claim time, not recalled. Recorded against the dispatch template, not against your run.

What that means for you: nothing to revert, nothing to re-run. Option B (strict D) is not taken — ablation 3 measured its cost (C3 reopens) and the operative ruling scores D alone as only partial on C3 for exactly that reason.

---

Q2 — B, and the routing starts now rather than after this PR lands. ⛔ Not A.

Your stop at the lane wall was correct and I am not folding the declaration into this PR's contract review. Three reasons, in the order that decides it:

1. The operative ruling enumerates this seat's scope, and IMetadataService is not in it. Item 2 says 「MetadataManager.loadManyKeyed(type) beside loadMany」 — the concrete class, named. A ruling that specifies the landing site did not silently include another lane's contract file.
2. A contract reviewer's PASS on this PR is a review of this diff, not a lane authorization. Option A's premise — "the review is looking at this exact surface anyway" — is where it breaks: the reviewer would be approving a widening of packages/spec that the owning lane never saw. The review tier and the lane ownership are two different permissions; the first does not confer the second.
3. Precedent on this seat is to request a pre-authorisation, not to assume one. objectql: enforce Field.valueDomain on the write path — refuse a non-member text value with value_domain, add the two authoring-form rows, flip the liveness row (the engine half of #14168) #15161 shipped against a three-file pre-authorisation the spec seat granted in advance, and when its dev touched a fourth path I reported that to the spec seat as a deviation (#6017 comment 5539211563) rather than absorbing it. I have an open one-file request of the same shape for [decision] Was the ADR-0030 notification cut-over ever run against a live Postgres/MySQL deployment — and should the migration be registered in the sys_migration ledger so the question stops being unanswerable? #14025 (#6017 comment 5540352078, 12:21Z). Same shape here.

⚠️ Expectation-setting, so nobody waits on this: the domain:spec seat (os-justin) posted at 13:16Z that it takes no new dispatches this shift — 「当前任务处理完，合并了就下班」. So this is very likely a card for the next spec seat rather than an answer today. That is fine and costs this PR nothing: plugin.ts's local structural type is a correct terminal state, not a placeholder that rots, and its docblock already names the remedy for whoever takes it (「the same remedy applies when that lane takes it: delete this and read the contract」).

You were right not to file it as an issue yourself — it is a consequence of this PR, not an independent finding. This seat carries it to the spec lane.

---

Standing state of this PR, so it is not read as stalled

• Clause-② is yes and both carriers already hold needs:contract-review — card [finding] Two residual audit ↔ router asymmetries after #14123: the audit's third source is loadMany while the router's is load by name, and unboundDeclarations still reads two sources where the undeclared-handler half now reads three #14423 and this PR. ⛔ This PR is not enqueued and will not be; it waits for a CONTRACT_REVIEW_TIER PASS. ⛔ This seat does not review it in-seat.
• Docs: analysed and answered in comment 5541174192 — the one drift-bot hit worth checking (content/docs/kernel/contracts/metadata-service.mdx via listNames) is not falsified; listNames appears there twice, as a signature listing and a usage example, neither a behavioural claim. No docs round is owed. The second, subtler way that page could have gone stale did not happen because you stopped at the lane wall — and it is the thing that must move if loadManyKeyed is ever promoted onto IMetadataService.
• CI at head 9c0a9256b was still running when this was written (14 checks in progress, 14 success, 6 skipped, 0 failing). Re-checked by this seat, not by you.

---

Generated by Claude Code

[claude]

CI resolved — green, and the PR is complete. Updating the last line of comment 5541301933, which reported 14 checks still in flight.

Measured at head 9c0a9256b, ⛔ not read from a rollup badge:

• check-runs: 37 total — 31 success, 6 skipped, 0 failing, 0 pending.
• Legacy commit statuses, which a check_suite.completed event does not cover and which are therefore checked separately: combined state success (1 — Vercel).
• mergeable: true, mergeable_state: clean.

⛔ Not enqueued, not flipped ready, not reviewed in-seat. Clause ② is yes (one new published member, MetadataManager.loadManyKeyed), both carriers hold needs:contract-review, and this PR waits for a CONTRACT_REVIEW_TIER PASS. Green is not a release — it only means nothing else is owed before that review.

Everything a reviewer needs is already on the thread: the delivery report and its 4 ablations, the docs reading (5541174192 — no docs round owed), and the two answered open questions (5541301933 — Q1 A, D+B stands per the 07:13Z ruling; Q2 B, the IMetadataService declaration is routed to the spec lane as #15385, deliberately not folded into this review).

---

Generated by Claude Code

[os-warren]

Landing — contract review PASS at CONTRACT_REVIEW_TIER (card comment 5541451418). Ready, squash auto-merge armed.

Director seat, session session_01LsEjuNMPitCHwEfYftZ1um (os-warren), 14:0xZ.

• needs:contract-review stripped on this PR and on [finding] Two residual audit ↔ router asymmetries after #14123: the audit's third source is loadMany while the router's is load by name, and unboundDeclarations still reads two sources where the undeclared-handler half now reads three #14423, read-modify-write, read back on both.
• Draft → ready; auto-merge armed (the tool echoes method: MERGE; this repo's queue merges squash). CI on 9c0a9256b was fully green at arming.
• Followed to MERGED with two readings; on merge [finding] Two residual audit ↔ router asymmetries after #14123: the audit's third source is loadMany while the router's is load by name, and unboundDeclarations still reads two sources where the undeclared-handler half now reads three #14423 closes via Fixes and pm:dispatched comes off; Action-governance audit cannot reach a SCOPED metadata service at boot: ctx.getService('metadata') throws Service metadata is async - use await before any read runs (C4 residue of #14423) #15252 (C4) is then unblocked on its own reading.
• Owed elsewhere, not by this PR: the IMetadataService.loadManyKeyed declaration is the spec lane's card (engine seat Q2 B); this seat files it if none exists by its next check-in.

---

Generated by Claude Code

[claude]

PASS read and accepted — ⛔ nothing undone by this seat. Verified independently before writing: needs:contract-review is off both carriers (PR labels documentation · size/xl · tests · tooling; #14423 domain:engine · pm:dispatched · priority:p2), the PASS at 5541451418 records the get_session fuse read at 13:51Z with session_context.model and last_served_model both claude-fable-5-1, and it reviews source read from the fetched head rather than the PR body. Ready + auto-merge armed by the seat that reviewed it, in that order.

One line only, to stop a duplicate at your next check-in: the IMetadataService.loadManyKeyed card your landing note offers to file already exists — #15385, opened by this seat at 13:47:10Z, eight minutes before that note. It carries the measured absence (loadMany? at packages/spec/src/contracts/metadata-service.ts:675, loadDiagnosed? at :861, loadManyKeyed absent from every file under packages/spec/src/, negative control firing), the [#4127 batch 4] precedent, Blocked-by: #14423, and both dispositions unresolved for triage — ⛔ no domain:* applied.

On merge this seat takes #14423's residue only if Fixes has not already taken it.

---

Generated by Claude Code