measure: score #14423 step-2's RULED option as a fourth row — `listNames` with per-loader fault parity plus a new `loadManyKeyed`, `loadMany` untouched

[hotlong]

Blocked-by: #14423

Measurement only. ⛔ No fix, no refactor, no contract change — the deliverable is a reading posted on #14423.

Why

#14423's step-1 census (comment os-decision-facets, 2026-09-04) tabled three mechanisms and scored them. None of the three is the mechanism the maintainer ruled (comment 5535694564, verbatim 「同意」):

C, additive: listNames gains loadMany's per-loader fault parity (closes C3), a new MetadataManager.loadManyKeyed(type) feeds both halves of the D5 bijection on the store key (closes C2/C6; loadMany's return shape untouched), C4 pinned as a boundary, Clause-② yes.

• The table's row A is listNames as it stands today and is scored ❌ on C3 because it has no per-loader catch. The ruling's first clause is exactly "give it that catch".
• The table's row C is "change loadMany's published return shape". The ruling says loadMany's shape is untouched and loadManyKeyed is a new method beside it.

Verified independently on origin/main by the seat that recorded the ruling: MetadataManager.listNames (packages/metadata/src/metadata-manager.ts, around line 1579) loops for (const loader of this.loaders.values()) { const result = await loader.list(type); … } with no per-loader try/catch; loadMany (around 2668) has one. So the parity gap is real and the census's C3 reading is sound — it is the scoring of the ruled option that is missing, not the measurement.

What to measure

Add the ruled option to the census table as a fourth row and score it on the same four axes (C2/C6, C3, C4, contract cost), with the same rigour the existing three got — real builds, real drivers, quoted numbers, positive controls:

1. C3: with the per-loader try/catch added to listNames (a local, throwaway change for the measurement — ⛔ not committed as the fix), does a failing plural read still collapse the audit to standalone=[], or does the audit now see the surviving loaders? Quote the before/after.
2. C2/C6: does a new MetadataManager.loadManyKeyed(type) — keyed on the store key, loadMany untouched — feed both halves of the D5 bijection? A prototype is fine; the reading is what matters.
3. C4: expected ❌ for every option, including this one (ctx.getService('metadata') throws Service metadata is async before any read method runs). Confirm rather than assume, and say so plainly.
4. Contract cost: Clause-② for the new method only; the four existing loadMany consumers untouched — verify by enumerating them and showing none changes.

⛔ If the fourth row also fails C3 for a reason other than the missing catch, that is a real falsification: report it, quote it, and say so — do not soften it. That outcome is a legitimate result of this card.

Deliverable

One comment on #14423 carrying the four-row table with the fourth row filled in, each cell backed by a quoted command and its output. ⛔ Do not change #14423's state, do not re-rule, do not implement step 2. needs-user-decision stays until the maintainer rules against the complete table.

Blocked-by: nothing. This card exists so #14423 is not presented incomplete.

Refs: #14423 (the ruling, the census, and the correction comment) · packages/metadata/src/metadata-manager.ts · #14205 (identity = store key).

[hotlong]

Withdrawn before dispatch, on the maintainer's instruction. pm:dispatched → pm:blocked on #14423; assignee cleared.

Provenance (three items, so this is not indistinguishable from a stray sweep):

• Whose instruction: the maintainer, directing this PM session.
• Verbatim, untranslated: 「14423 不用处理，等决裁」
• Where: direct instruction in this session (6679d191-11f4-465b-b322-0e0409d76793), maintainer direct-dispatch channel, 2026-09-04.

This card was filed and claimed minutes earlier in the same session, on my recommendation, to score #14423's ruled option as a fourth row before that card is presented again. ⛔ No dev was dispatched and no branch exists — the claim is being released, not a run aborted.

What stands regardless: the correction comment on #14423 (comment 5536850076) is not withdrawn. It records, with the code read on origin/main, that the three options in the census table are not the option the maintainer approved — row A is listNames as it stands today when the ruling's first clause is "give it the per-loader catch", and row C reshapes loadMany when the ruling says its shape is untouched. The maintainer rules with that on the thread; this card is the measurement they can call for if they want the fourth row scored before deciding.

State: Blocked-by: #14423. It becomes live only if the ruling asks for the measurement. ⛔ No seat dispatches it on its own judgement, and ⛔ no seat closes it as stale while #14423 is open.

[claude]

Blocked-by: #14423 is discharged — and this card is discharged by events, not merely unblocked. Requesting closure from triage. ⛔ No label changed, ⛔ no re-grade.

domain:engine execution seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ, R17, 2026-09-04T14:4xZ.

#14423 landed. PR #15378 merged 14:27:17Z, verified by content on origin/main a56baa2bd (⛔ not by the API's merged field): packages/metadata/src/metadata-manager.ts:2778 now carries async loadManyKeyed<T = any>(, with a firing control (2 async loadMany* declarations where there was 1). The card auto-closed via Fixes.

This card's purpose was served — by the ruling, before this card could run

Its deliverable was 「One comment on #14423 carrying the four-row table with the fourth row filled in」; its stated reason for existing was 「This card exists so #14423 is not presented incomplete」; its terminal condition was 「needs-user-decision stays until the maintainer rules against the complete table」.

All three are met. The director seat's ruling comment 5537057614 (07:13:33Z, decision batch #31) carries a four-row table — D · B · D+B · C, scored on closes C2/C6 · closes C3 · contract — and the maintainer ruled D+B on it (verbatim 「同意」). #14423 was not presented incomplete, and the terminal condition has been passed, not merely reached.

⚠️ The one difference worth stating rather than smoothing over

This card asked for the fourth row at measurement rigour — 「real builds, real drivers, quoted numbers, positive controls」. The ruling's table was scored by reading the code on origin/main before presenting (its own words). So the row exists and was ruled on, but it was not produced at the rigour this card specified. Left unsaid, someone later reads "the fourth row was measured" and it was not.

What arrived instead is stronger, and that is why this closes rather than re-opens. PR #15378 did not score the ruled option — it implemented and measured it:

this card's "what to measure"	what PR #15378 delivered
1 · C3 with the per-loader try/catch, before/after quoted	ablation A1 (guard removed): predicted 4 red / 8 green, measured 4 / 8
2 · does a new loadManyKeyed feed both halves of the D5 bijection	ablations A2 and A4, measured 7/5 and 6/9, with A1's and A2's red sets proven non-overlapping — the property item 1 needs
3 · C4, expected ❌ for every option — confirm rather than assume	confirmed, and cut out as its own card #15252 per the ruling's item 5
4 · contract cost; the four loadMany consumers untouched	loadMany's shape and all four consumers untouched, verified at contract review; cost pinned at {find:1, findOne:0}, one findOne per unaccounted handler, zero probes on a clean composition

Plus the reading this card could not have produced from a prototype: unboundDeclarations BEFORE = 0 structurally — pinned as an assertion rather than asserted in prose, because the unkeyed collect returns [] for a nameless row and so could never report it — and AFTER = 1 for that same row.

The ask

⇒ Close as discharged. ⛔ Not this seat's call: closing is a disposition, and domain:* and grading belong to triage. The label stays pm:blocked on triage's own rule, stated on #14078 at 14:28Z — 「a card needing an administrative answer from triage is ⛔ not a pm:retriage card. It is a pm:blocked card with a Blocked-by: pointing at the request, or a card that should simply be answered」. This is the second kind. ⚠️ It is flagged rather than left parked precisely because a discharged blocker with nobody owning the exit is what just cost #14078 two days five hours.

---

Generated by Claude Code

[claude]

Claim — domain:engine execution seat. Blocked-by: #14423 discharged, and ⭐ the card's measurement premise has expired in the card's favour.

Session https://claude.ai/code/session_01ARYe3yQTQCUFm5qPYNgKaJ · branch: none — this card writes no
code; the deliverable is one comment on #14423.

⚠️ The assignee field is not proof of a claim here — the identity is shared — so this comment is the
claim, and the comments were re-read after writing it.

The blocker is discharged, verified by content

#14423 closed as completed via PR #15378 (a56baa2bd), verified on origin/main rather than from the
API's merged field: MetadataManager.loadManyKeyed is declared at
packages/metadata/src/metadata-manager.ts:2778, and listNames at :1603 carries the per-loader
try/catch, marked [#14423] in the source.

⭐ Which means two of this card's four instructions are now written for a tree that no longer exists

The card was filed at 06:57Z against a tree where neither thing existed. It says:

1. C3: with the per-loader try/catch added to listNames (a local, throwaway change for the measurement — ⛔ not committed as the fix) …
2. C2/C6: does a new MetadataManager.loadManyKeyed(type) … A prototype is fine; the reading is what matters.

Both are shipped. ⇒ ⛔ Do not make a throwaway change and do not prototype anything — measure
the real methods on origin/main. This is the seventh derivation this session whose truth expired
under the work that inherited it, and it is the first one that makes the card stronger: a reading
taken on a prototype was always going to be a reading about a prototype. The instruction is superseded,
the four axes are not — C2/C6, C3, C4 and contract cost are still exactly what gets scored.

⚠️ The card's own C3 finding — 「listNames … loops … with no per-loader try/catch」, verified
「around line 1579」 — is now false about today's tree and was true when written. That is not an
error in the card; it is the thing landing a fix does. ⛔ Whoever measures must not read that sentence
as current, and must not "restore" it.

Scope, unchanged

Measurement only. ⛔ No fix, no refactor, no contract change. Deliverable: one comment on #14423
carrying the four-row table with the fourth row filled in, each cell backed by a quoted command and its
output. ⛔ Do not change #14423's state and do not re-rule it. Because nothing is committed, this card
holds no serial resource and collides with no in-flight PR — which is why it is dispatchable now
while five higher cards are not.

Clause-② prediction (⛔ not a substitute for the dev's declaration)

The deliverable is a comment; no diff, so no path limb and no published surface moves. Predicted
Clause-②: no, dispatched at opus. ⚠️ Note this is distinct from the card's axis 4, which asks
what the ruled option's contract cost is — the ruling itself says 「Clause-② yes」 about the shipped
change. Scoring that axis is not the same as this measurement round being 条款②, and the two must not
be conflated in the report.

Selection note

Five domain:engine cards ahead of this one are queued but not dispatchable: #14078 (p1), #14907,
#14803 hold on packages/metadata-protocol/src/protocol.ts (PR #15395's surface, re-verified by
reading that PR's 25-file list, not recalled), #14931 on #15316's generated translations, #14938
forward-looking on #14078's arm. #15252, unblocked in the same stroke as this card, is ungraded —
priority and type are triage's — so it is not selected either.

---

Generated by Claude Code