Development record
the grounds writer judges the whole file while the reader judges the body so a frontmatter Grounds comment makes triage report success and record nothing
the grounds writer judges the whole file while the reader judges the body so a frontmatter Grounds comment makes triage report success and record nothing
Found by the itd-179 delta security review, which reproduced it end to end through the production path. BRANCH-INTRODUCED. Fail-OPEN.
Root cause, stated by that review better than the symptom states it: the WRITER
(AppendToSection) is handed the whole file, frontmatter and body, while the
READER (groundsEntries) is handed the body alone. The read-back guard is
therefore a property of the whole file rather than of the section the reader
will actually consult, so writer and reader can agree that an entry landed while
disagreeing about where.
The trigger is a legal YAML comment. parseFrontmatterBlock skips a line whose
trimmed form starts with #, so # Grounds sits happily in frontmatter -- and
headingRe (^#{1,6}\s+Grounds\s*$) matches it as the section heading. The
bullet is appended into that pseudo-section, the read-back runs over the whole
file and agrees, and the verb reports success. Then issueFromFrontmatter
computes grounds over the BODY only, finds no heading, and returns nothing.
The record moves to resolved/ carrying a conjecture no surface can read. That
is precisely the outcome adr-57 argues against in its own consequences: a value
nothing reads.
Reachability is lower than its sibling: no committed record carries such a
comment and capture never writes one, so it needs a hand-edited or
contributor-supplied record. It is filed because it shares a root cause with
iss-2608301803423101 and ONE fix closes both -- run the append and its read-back
over the BODY and splice the result back onto the frontmatter, after which
headingRe can never match a frontmatter comment at all.
The sibling shape (# Grounds followed by # Notes) puts the bullet inside the
frontmatter and IS caught downstream, fail-closed, but with a message naming
neither cause nor remedy.
Grounds
- pursued: we expect a writer and a reader that judge the same bytes to make the disagreement unrepresentable, rather than a ban on the one spelling that triggered it
Frontmatter
| id | iss-2608301805069999 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608301805069999-the-grounds-writer-judges-the-whole-file.md
open on GitHub ↗ · commit history ↗
mentions4
- adr-57Grounds accumulate as an append-only section, in one shared form
- dcn-26083000000000192026-08-30 — itd-179 delta close: the grounds APPEND and its read-back run over the record BODY, spliced back onto the frontmatter, rather than over the whole file. `frontmatter.Split` is the one lossless answer to where the block stops and `grounds.Body` is what both halves ask, so the writer judges the bytes the reader consults and the writer/reader disagreement is unrepresentable rather than banned one spelling at a time (iss-2608301805069999). The intent half's reader moves to the same scope, where the whole-file reading would have found an empty pseudo-section. Rejected: refusing a frontmatter `# Grounds` comment, which bans the one spelling that was reported and leaves the scope split that produced it.
- iss-2608301803423101an unclosed comment or fence anywhere in an issue record blinds every grounds triage route permanently and promote orphans a draft per attempt
- itd-179The reasoning behind what was pursued no longer evaporates at the gate — readiness and triage record grounds for the conjecture, not only the decision