Grouping issue, filed as part of a catalog pass over the 2026-08-28 to 2026-08-31 resync and MTP conversion campaign. This issue records the shared cause and adopts the affected issues as sub-issues. It proposes no fix.
The shared cause
spec/files.json and spec/section-model.md declare what a downstream repository carries. They are hand-maintained, they live apart from the documents they describe, and nothing fails when a document changes without them. So a heading edit in GOVERNANCE.md can silently change what the whole fleet carries, and the change is invisible until a resync tries to act on it.
Both children trace to one commit. 86783b9 promoted Running the Linters Locally (Known-Working Invocations) from a subsection of a verbatim section to its own top-level heading, and updated neither spec file:
$ git log --oneline -S"Running the Linters Locally" -- spec/files.json spec/section-model.md
(no output)
The section stopped being carried at that moment. It is not declared verbatim, and it is not declared hub-only either, so it is in neither category the model has.
Children
| Issue |
What it reports |
| #1075 |
CODESTYLE.md links to the section three times, and CODESTYLE.md is itself carried |
| #1120 |
AGENTS.md's carried routing table routes a task to the section, so a downstream repository carries a row pointing at a section it is not supposed to have |
#1120 records the cost measured live: carrying the section to satisfy the routing row produced two new audit findings, and not carrying it leaves the carried routing row dangling. Neither direction is correct, which is what makes this a declaration defect rather than a resync judgment call.
What a fix at this level would have to address
Whether the declaration can be derived from, or checked against, the documents it declares, rather than restated beside them. A check that every anchor a carried document links to resolves to a section the spec also declares would have failed on 86783b9.
Related but separately caused: #1118 and #1129 are about what the fidelity tiers can express, not about the declaration going stale.
Grouping issue, filed as part of a catalog pass over the 2026-08-28 to 2026-08-31 resync and MTP conversion campaign. This issue records the shared cause and adopts the affected issues as sub-issues. It proposes no fix.
The shared cause
spec/files.jsonandspec/section-model.mddeclare what a downstream repository carries. They are hand-maintained, they live apart from the documents they describe, and nothing fails when a document changes without them. So a heading edit inGOVERNANCE.mdcan silently change what the whole fleet carries, and the change is invisible until a resync tries to act on it.Both children trace to one commit.
86783b9promotedRunning the Linters Locally (Known-Working Invocations)from a subsection of averbatimsection to its own top-level heading, and updated neither spec file:The section stopped being carried at that moment. It is not declared
verbatim, and it is not declared hub-only either, so it is in neither category the model has.Children
CODESTYLE.mdlinks to the section three times, andCODESTYLE.mdis itself carriedAGENTS.md's carried routing table routes a task to the section, so a downstream repository carries a row pointing at a section it is not supposed to have#1120 records the cost measured live: carrying the section to satisfy the routing row produced two new audit findings, and not carrying it leaves the carried routing row dangling. Neither direction is correct, which is what makes this a declaration defect rather than a resync judgment call.
What a fix at this level would have to address
Whether the declaration can be derived from, or checked against, the documents it declares, rather than restated beside them. A check that every anchor a carried document links to resolves to a section the spec also declares would have failed on
86783b9.Related but separately caused: #1118 and #1129 are about what the fidelity tiers can express, not about the declaration going stale.