Filed by the PM dispatch loop as option B of open question 3 on #14921, which this seat ruled A (no docs edit in PR #16086) with B split out here. ⛔ Unassigned and ungraded — domain:*, type and priority are triage's.
The gap
content/docs/kernel/contracts/metadata-service.mdx documents IMetadataService. Its only failure-mode prose (around lines 113-130) is explicitly scoped to the singular read:
Both read one item through the registered loaders … load returns null for both "no loader has this item" and "every loader failed".
⇒ The page is silent on the failure posture of the PLURAL reads (list / listNames). It documented neither the pre-existing per-loader degradation nor any totality claim.
Why it is a card and not a fix on #16086
⭐ Silence is not falsehood. The #14921 round measured that nothing on the page is false — it mentions listNames on exactly two lines (an interface signature and one line of a signature-illustration block), states no return contract beyond the signature, and a grep for first-wins / collision / silently / duplicate / listed twice on that page returns zero. ⇒ E3 「已发布必修」 does not bite, and editing it inside a ruled engine fix would have been writing new documentation the ruling did not ask for.
⚠️ And the decisive reason it cannot be a rider: to be coherent, the new passage would have to describe behaviour older than #14921 — the pre-existing per-loader degradation — not just the refusal that card adds. A docs change whose scope exceeds its host PR's ruling belongs on its own card.
What the page would need to say, after #16086 lands
The plural reads then have two distinct outcomes, and today the page distinguishes neither:
| condition |
outcome |
| a storage outage / a loader that cannot answer |
degrade — the read continues over the remaining loaders (pre-existing behaviour, undocumented) |
| two files under one directory deriving the same stem |
refuse — AmbiguousMetadataStemError, ADR-0112 envelope, code AMBIGUOUS_METADATA_STEM, every colliding path named (added by #14921) |
⇒ Placed beside the existing load / loadDiagnosed passage, so the singular and plural postures sit together.
⛔ Not asserted
⛔ No wording is prescribed and no priority is claimed. ⛔ This card should not land before #16086 does — the refusal half would document behaviour not yet on main.
Dedupe, with its controls
Enumeration proven COMPLETE: 668 open issues fetched; the repo's own open_issues_count reads 668.
| probe |
hits |
plural read failure posture |
0 |
listNames failure contract |
0 |
CONTROL metadata-service.mdx |
2 — #15626, #15385 — fires |
CONTROL listNames |
6 — fires |
⚠️ Stated honestly: this seat did not read #15626 and #15385 in full. They surfaced as the control for the page name and are recorded here as adjacent, possibly overlapping — #15385 concerns MetadataManager.loadManyKeyed landing as a public member without an IMetadataService declaration, which is the same page's neighbourhood but a different claim. ⇒ If triage finds either already carries this gap, ⛔ close this as the duplicate rather than assuming the zero-hit probes settled it.
Refs
#14921 · PR #16086 · #15626 · #15385 (both adjacent, see the caveat above)
Generated by Claude Code
Filed by the PM dispatch loop as option B of open question 3 on #14921, which this seat ruled A (no docs edit in PR #16086) with B split out here. ⛔ Unassigned and ungraded —
domain:*, type and priority are triage's.The gap
content/docs/kernel/contracts/metadata-service.mdxdocumentsIMetadataService. Its only failure-mode prose (around lines 113-130) is explicitly scoped to the singular read:⇒ The page is silent on the failure posture of the PLURAL reads (
list/listNames). It documented neither the pre-existing per-loader degradation nor any totality claim.Why it is a card and not a fix on #16086
⭐ Silence is not falsehood. The #14921 round measured that nothing on the page is false — it mentions
listNameson exactly two lines (an interface signature and one line of a signature-illustration block), states no return contract beyond the signature, and a grep forfirst-wins/collision/silently/duplicate/listed twiceon that page returns zero. ⇒ E3 「已发布必修」 does not bite, and editing it inside a ruled engine fix would have been writing new documentation the ruling did not ask for.What the page would need to say, after #16086 lands
The plural reads then have two distinct outcomes, and today the page distinguishes neither:
AmbiguousMetadataStemError, ADR-0112 envelope, codeAMBIGUOUS_METADATA_STEM, every colliding path named (added by #14921)⇒ Placed beside the existing
load/loadDiagnosedpassage, so the singular and plural postures sit together.⛔ Not asserted
⛔ No wording is prescribed and no priority is claimed. ⛔ This card should not land before #16086 does — the refusal half would document behaviour not yet on
main.Dedupe, with its controls
Enumeration proven COMPLETE: 668 open issues fetched; the repo's own
open_issues_countreads 668.plural read failure posturelistNames failure contractmetadata-service.mdxlistNamesMetadataManager.loadManyKeyedlanding as a public member without anIMetadataServicedeclaration, which is the same page's neighbourhood but a different claim. ⇒ If triage finds either already carries this gap, ⛔ close this as the duplicate rather than assuming the zero-hit probes settled it.Refs
#14921 · PR #16086 · #15626 · #15385 (both adjacent, see the caveat above)
Generated by Claude Code