Development record
confining the frontmatter block to line 0 silently admits a delimited block carrying an excluded key that the manifest still asserts was excluded
confining the frontmatter block to line 0 silently admits a delimited block carrying an excluded key that the manifest still asserts was excluded
Found by the round-9 adversarial security review of build/itd-183. REGRESSION INTRODUCED BY 2225d6cb, and a DELIBERATE one -- flagged as a documented trade to re-confirm, not as a defect.
firstBlockRange refuses to open a block unless line 0 starts with ---
(BOM allowed):
if !strings.HasPrefix(frontmatter.TrimBOM(lines[0]), "---") { return 0, 0, false }
So an admitted .md whose first line is blank, a space, or a preamble, followed
by --- / origin: <value> / ---, reaches the bundle intact. Verified
admitted on HEAD and refused on the parent for a leading blank line, a leading
<!-- x -->, and a leading space.
Why it is defensible: that region is body prose to frontmatter.Fields,
Duplicates and site.StripFrontmatter alike, so it would have travelled as
prose either way. The parent's behaviour was a REFUSAL, not a redaction.
Why it still bites: the blind reader is not this binary. An LLM reading the
bundle reads \n---\norigin: ...\n---\n as frontmatter, and the manifest tells
it that key was excluded. The commit's claim "Agreeing loses no key" is scoped
to this binary's own readers, not to the reader the bundle exists for.
FOR THE FACILITATOR -- two acceptable resolutions:
(a) keep the change and restate the claim honestly in the commit message and
the charter: "a block preceded by anything is body prose to this binary and
travels"; or
(b) open the block at the first NON-BLANK line rather than at byte 0 (skipping
blank/whitespace-only lines and the BOM). That recovers the leading-blank
and leading-space cases without reintroducing the thematic-break false
refusal the change was made to close, since a --- after real prose still
opens nothing.
Grounds
- pursued: we expect refusing exactly the document this binary reads as prose and a reader of the bundle reads as frontmatter to close the gap the line-0 rule left, without reopening the phantom-block class, because a delimiter after real prose is excluded from the shape by construction; an ordinary documentation page with a thematic break being refused, or a displaced block still assembling, would show it wrong
Frontmatter
| id | iss-2608301237456350 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2608301237456350-confining-the-frontmatter-block-to-line.md
open on GitHub ↗ · commit history ↗
mentions5
- iss-2608301423540137the orchestrator committed record bodies to three build branches without running the record and site gates, turning site-render red on two of them
- iss-2609021457186209spc-2609021003136831 section 'The six refusals' states that none of the six shapes appears in a committed record the include table admits, so the refusals refuse nothing on this corpus today. That measurement is wrong. Shape 2, the displaced frontmatter block, is carried by 21 committed glossary records under .abcd/development/brief/glossary/ (core/*.md, interview/*.md and _template.md), each opening with the attribution comment 'Adapted from mattpocock/skills (MIT). See README Acknowledgements.' as an HTML comment on line 0 and its frontmatter delimiter on line 1. The refusal is correct on the merits: frontmatter.Fields requires the delimiter at line 0, so those records' frontmatter keys are invisible to the assembler's redactor while every manifest asserts the key exclusions over them, which is the brief invariant 16 violation iss-2608301237456350 names. The consequence is that once itd-194 ships, reading assemble refuses at every assembling position over this repository's own corpus, and the ac-5 eval TestTheFixtureLeakIsAbsentUnderEveryCommittedPreset, which assembles a clone of HEAD, cannot pass. The two spec requirements are not simultaneously satisfiable while those records stand. Measured remedy, verified on a scratch copy: moving the attribution comment to the line after the frontmatter block's closing delimiter in those 21 files makes the whole corpus assemble with no refusal and leaves record-lint with no new finding. Whether to repair the records, narrow shape 2's HTML-comment clause, or do something else is a corpus decision this spec does not authorise, so it is captured rather than taken.
- itd-183The cold reading sees exactly what the assembler passes — positive inclusion, field projection, and a per-run manifest
- itd-194The reading include table admits only what the exclusion floor can read
- spc-2609021003136831The include table declares what the floor parses, the floor refuses the markdown it cannot resolve, and the manifest marks every item it did not examine