Files
msd-core/gsd-core/workflows/progress/steps
0xdhx ef9ce3e598 fix(#3702): count asterisk, plus and ordered markers as deferred-items entries (#3739)
* fix(#3702): deferred-items counts `*`, `+` and ordered markers as list items

`deferred-items.md` has no template and no mandated shape, but its parser
recognised only the `- ` hyphen marker. Asterisk bullets, plus bullets and
dot-terminated ordered lists — all lists in CommonMark and GFM — contributed
ZERO entries on both the headless and the heading-delimited path, and a mixed
file dropped its non-hyphen entries while keeping their hyphenated siblings,
under-reporting without ever looking empty.

The restriction was a regex literal inherited from the Gaps seam, where the
template genuinely mandates the hyphen YAML-lite form; nothing in the module's
stated rationale distinguishes `*` from `-`.

Widened on the deferred path only:
- `splitGapsEntriesCore`'s entry opener, `extractGapEntryFields`' line-0 strip
  and `rawGapEntryText`'s line-0 strip take a `BulletMarkers` parameter that
  DEFAULTS to the hyphen-only set, so `## Gaps` keeps its template-mandated
  grammar byte-for-byte and the module still has exactly one grouping pass.
- `splitDeferredHeadingEntries`' body-bullet test, `stripLeadingBulletMarker`
  and `acknowledgeDeferredItem`'s status-field regexes move in lockstep —
  widening what OPENS an entry without widening what is STRIPPED before field
  extraction would surface an entry that can never resolve.

Unchanged, and pinned by tests: prose-only and bare headings still contribute
nothing ("prose is not an item"); a table under a leaf heading still yields
exactly its rows, since table lines are skipped before the body-marker flag can
be set and a `|` row is not a list marker; the paren-terminated ordered form
`1)` is out of this fix's scope.

* docs(#3702): changeset fragment (pr: 0 placeholder pre-create)

* fix(#3702): widen the forensic-audit prose entry rule to match the parser

Sibling site of the same defect class, found by a defect-class sweep of the
deferred-items consumers. `/gsd-progress` check 7 does NOT go through
`gsd-tools query` — it globs `deferred-items.md` and has the model read entries
by a prose rule that mandated "one entry per top-level `- ` line". Left as-is,
the marker widening would hold on the CLI path while the one consumer that
bypasses the parser kept reporting "No unresolved deferred items" for a file
written with `*`, `+` or an ordered marker: the same false negative, surviving
in the only place the fix could not reach by code.

Also pass DEFERRED_BULLET_MARKERS explicitly where the heading path extracts
fields. It was already correct — stripLeadingBulletMarker pre-strips the widened
set from every line, so the default hyphen strip is a no-op there — but relying
on that leaves a detection site and a strip site nominally on different marker
sets, which is exactly the asymmetry the BulletMarkers doc comment warns about.
Explicit is local; inferred is a trap for whoever edits the strip next.

Out of scope, noted rather than fixed: forensic-audit.md globs only
`.planning/phases/*/` and so misses archived milestone phases that
`scanDeferredItems` covers. Pre-existing, a different defect, and not this
issue's ruling.

* docs(#3702): note the milestone-close halt for heading-shape non-hyphen files in the changeset

A heading-delimited deferred-items.md written with */+/ordered markers
previously parsed to zero and closed silently; it now yields entries whose
heading shape acknowledgeDeferredItem refuses, halting complete-milestone
until hand-edited. User-visible, so the fragment states it.

* chore(#3702): set changeset fragment pr to 3739

* fix(#3702): CR-normalise the heading path and the acknowledge writer (review B1, M4, m2)

B1 — `splitDeferredHeadingEntries` stored RAW lines; on a CRLF file every
body line but the last still carried its `\r`, the `$`-anchored marker
strip failed on it, the marker survived into field extraction and the
field was lost — a `**Status:** resolved` that was not the file's final
line resurfaced its entry as open. The heading path now stores CR-stripped
lines like the headless path already did, and the strip regex tolerates a
trailing CR on its own. Round 1's CRLF test put `**Status:**` on the last
line, the one position `collectSection`'s `.trimEnd()` had already
de-CR'd; the new tests put it first and mid-body.

M4 (pre-existing on `next`) — `acknowledgeDeferredItem` found the status
line on a CR-stripped copy but rewrote the raw line with a `$`-anchored
`.*`, which cannot consume `\r`; `replace` returned its input, and the
writer reported `ok` over byte-identical content. The rewrite now runs on
a CR-stripped line. The comment that claimed `.*$` consumed the `\r` is
corrected — it was the bug, stated as the design.

m2 — the indent probe for an inserted `status:` line ran on the raw line
and fell back to indent 0 on CRLF; it is CR-stripped too.

* fix(#3702): derive every deferred-items marker regex from one source (review M3, N1, N2)

M3 — round 1 carried the marker alternation in FOUR places: the
`BulletMarkers` pair and two inline literals inside
`acknowledgeDeferredItem`, under a doc comment saying the interface
existed so a detection site and its strip site could not drift. All four
now derive from `DEFERRED_MARKER_ALT`; drift is impossible rather than
discouraged. A parity test pins the vocabulary against
`markdown-sectionizer`'s `iterateBullets` on everything the two grammars
are meant to agree on, and names the two points they deliberately differ.

N1 — the ordered marker is `\d{1,9}\.` (CommonMark §5.2), not `\d+\.`.

N2 — the marker is followed by `[ \t]`, not `\s`, which also accepted
`\r`; the tab remains accepted (CommonMark-legal) and the divergence from
`iterateBullets`' literal space is pinned rather than papered over.

The four regexes are exported for the parity test only.

* fix(#3702): an ordered marker opens an entry only from `1.` or inside a run (review B2, m1)

B2 — `\d+\.` alone read ordinary prose as a list: "2026. was a bad year
for this module" and, under `### Notes`, "3. is the number of retries we
settled on." both opened an entry on round 1, the second straight through
the "prose is not an item" contract that round's AC4 claimed to preserve.
CommonMark §5.3 faces the same ambiguity when an ordered list would
interrupt a paragraph and resolves it by requiring the list to start with
1; `matchListOpener` applies that rule wherever an ordered marker is seen,
with the run carried per list (headless) or per leaf-heading body. Numbers
after the first are ignored, as CommonMark ignores them. Stated cost,
pinned: a hand-numbered list starting at 2 reads as prose — every ordered
record in the #3702 scan starts at 1.

Both reviewer cases are pinned as prose; the ruling's `1. alpha / 2. beta`
shape still counts.

m1 — the 9-digit boundary is pinned at both sides (`999999999.` opens,
ten digits is not a marker), and the 3-vs-4-space indentation cliff is
pinned as deliberately NOT applied: the parser is indent-lenient because
surfacing a questionable hand-written entry beats dropping a real one.

* fix(#3702): thematic breaks close the list and fenced code never opens an entry (review M1, M2)

M1 — `- - -` was a phantom `"- -"` entry on base; widening the marker set
added `* * *` and `+ + +` to the class, and `* * *` is the separator an
author writing in the `*` style is most likely to use. A CommonMark §4.1
thematic break (plus the `+ + +` gesture, which is the same garbage as an
entry name) now closes the open entry on the headless path and is dropped
from the body on the heading path — neither an item nor a continuation.

M2 — neither splitter was fence-aware, so `+ `-prefixed diff lines and
`1.`-numbered repro steps inside a code block counted as entries; #3702's
wild records carry exactly those blocks. Both splitters now classify lines
by the sectionizer's own `scanFencedBlocks` (so `~~~`, indented and
unterminated fences behave as `stripFencedCode` would): fence content
never opens an entry, is continuation inside an open one — keeping the
span invariant `acknowledgeDeferredItem` re-verifies — and is discarded
before the first.

* test(#3702): range the #2287 deferred-items property over marker × shape × line ending (review B3)

The `#2287` property hard-coded `- ` and filtered `\r\n` out of its
arbitraries, so the widened marker set — an enumerated domain, exactly
what a property is for — was never under it. It now ranges over
`{-, *, +, ordered}` × `{headless, heading}` × `{LF, CRLF}`, with the
heading shape placing `**Status:**` first or last: the review's
prescription (markers × line endings) would not have reached B1, which
lives on the heading path only, so the shape axis is the load-bearing
addition. Ordered entries are numbered from 1, so the B2 run rule is
under the property too.

A second property drives `acknowledgeDeferredItem` over every unresolved
headless entry across the same marker × line-ending grid — the one that
reaches M4 (a CRLF rewrite that reported `ok` and wrote nothing) and m2.

* test(#3702): pin the milestone-close halt on a heading-delimited `*`/`+`/`1.` file (review m3)

A heading-delimited `deferred-items.md` written with a non-hyphen marker
previously parsed to zero entries and let `complete-milestone` close
silently; it now yields entries whose heading shape `acknowledgeDeferredItem`
refuses, which the milestone loop turns into `record_ack_failure` → exit 1.
The loop is prose in a workflow, so the test drives the two CLI calls it
makes: `audit-open --json` must list the entry, and
`audit-open acknowledge --text <the audit's own text>` must refuse with the
heading-delimited message and write nothing.

* docs(#3702): changeset and forensic-audit prose carry the round-2 grammar

The changeset names the CRLF fixes, the ordered start-at-1 rule, thematic
breaks and fences. The `/gsd-progress` forensic-audit step is the one
prose parser of this file and must state the same grammar the code has.

* fix(#3702): round-review refinements — run ends at a paragraph, rejected ordinals unstripped, breaks at any indent, fenced fields, `## Gaps` scope

Findings from the pre-push adversarial review of round 2, each pinned:

- An ordered run ENDS at a paragraph that follows a blank line (CommonMark
  §5.3); a non-indented line with no blank before it is lazy continuation
  and keeps the run open. `1. a` / blank / `paragraph` / blank / `5. x` is
  one entry, not two.
- The heading path strips the marker off every body line before field
  extraction (#3457); a line whose ordinal `matchListOpener` REJECTED must
  not be stripped, or "3. status: resolved" as prose loses its `3. ` and
  reads as a resolved field. `splitDeferredHeadingEntriesDetailed` now
  carries a per-line opener flag and only accepted openers are stripped —
  in headless regions of a heading-shaped file too.
- A thematic break is recognised at any indent, matching the parser's
  indent-lenient reading of items; `    * * *` was a phantom `* *`.
- Fenced lines carry no FIELDS either: a `status: resolved` quoted inside a
  code block no longer resolves its entry on either path.
- Block structure (breaks, fences) is a property of the GRAMMAR, carried as
  `BulletMarkers.blockStructure`: the deferred set opts in, the Gaps set
  does not, so `## Gaps` is byte-for-byte on its `next` behaviour — the
  round-2 M1/M2 change had reached it through the shared splitter.

* test(#3702): the property exercises the rejected-ordinal branch; the N2 control is independent

Round review: the widened #2287 property numbered every ordered run from 1
and so never generated an ordinal the start-at-1 rule rejects — it could
not tell round 1 from round 2 on B2. Each entry may now carry a decoy prose
line beginning with a non-1 ordinal, placed where it cannot end a run
(before the first headless entry; first in a heading body), followed by a
`status: resolved` that must never become a field; and a decoy-only
heading body must yield no entry.

The N2 assertion accepted a tab, which round 1's `\s` accepted too, so a
`[ \t]` → `\s` revert alone stayed green. NBSP, form-feed and vertical-tab
are now asserted refused — the assertion that fails on that revert on its
own, and the disclosure that `[ \t]` narrows what round 1 accepted.

* fix(#3702): the splitter records its own opener flags; an opener clears the blank-line memory

Round-review continuation, two state defects in the ordered-run logic:

- `blankSeen` survived the headless splitter's opener branch, so an opener
  followed by a lazy continuation line read as "paragraph after a blank" and
  ended the run — `1. a` / blank / `2. b` / lazy / `3. c` folded `c` into `b`.
  The opener branch now clears it.
- The heading path re-derived per-line opener flags for headless regions
  without the paragraph reset, re-accepting a rejected `3. status: resolved`
  under a stale run and stripping it into a field. `GapsEntrySpan` now
  carries the flags the splitter itself computed, and the heading path reads
  them; the re-derivation is deleted.

* fix(#3702): ordered-run memory is per indent — nested runs resolve, nested ordinals never inherit the top-level run

Round-review continuation 2: nested openers consulted the TOP-LEVEL run
flag and never wrote their own, so a nested `1. / 2.` run under a hyphen
entry rejected its `2. status: resolved` (round 1 resolved it), while a
nested `3. status: resolved` under a nested `- ` bullet inherited an open
top-level run and was stripped into a false field.

`OrderedRuns` keys the memory by indent: a new opener at indent d resets
every deeper level, a paragraph after a blank at indent d ends the runs at
d and deeper, a thematic break or a heading clears all. Both splitters use
it; the top level still decides entry boundaries, nested levels decide
only which continuation lines are accepted openers for field stripping.
Pinned for LF and CRLF.

* fix(#3702): run levels — one top level at or above the base, CommonMark column indents, a fence ends its level's runs

Round-review continuation 3:

- A dedenting top-level list (`    1.` / `  2.` / `3.`) lost its entry
  boundaries: the exact-indent run lookup rejected the shallower ordinals
  before the boundary check ran. Every indent at or shallower than the
  list's base is now ONE level, in both splitters.
- `indentOf` counted characters, so a tab and a space aliased to one level
  and `\t1. nested` / ` 2. status: resolved` resolved falsely. Indent is now
  measured in CommonMark columns (§2.2: a tab advances to the next multiple
  of 4), for the run level and the entry-boundary check alike.
- A nested run survived a fenced block. A fence is a non-list block: its
  opening delimiter ends the runs at its level and deeper, exactly as a
  paragraph after a blank does.

* fix(#3702): the indent measure is grammar-scoped — Gaps keeps next's character count

`blockStructure: false` promised the Gaps grammar byte-for-byte parity with
`next`, but the CommonMark-column indent measure added for the deferred
grammar was shared by the whole splitter core, so tab-indented Gaps input
changed entry boundaries in BOTH directions:

  `\t- a` / `  - b`  — next folded into one entry, HEAD split into two
  `  - a` / `\t- b`  — next split into two,      HEAD folded into one

`indentWidth` now keys the measure on the grammar: columns for the deferred
set, raw character count for Gaps. The opt-out covers indent semantics, not
only fences and thematic breaks.

Four cases pin both halves — the two flipped Gaps pairs, the two Gaps pairs
that never moved, and the same tab/space pairs on the deferred path returning
the opposite (column-measured) verdict by design.

* fix(#3702): the acknowledge path reads and writes through one classifier

Round 3, Blockers 1 and 3, and Minors 7 and 8 — one mechanism, so one commit.
Every consumer of an entry's lines now reads the splitter's own per-line
verdict instead of a re-derivation of it.

B1. Round 2 widened the WRITER's status-line finder to the deferred marker set
while `extractGapEntryFields` still de-bulleted line 0 only. A nested
`  * status: pending` was therefore selectable by the writer and invisible to
the reader: acknowledge rewrote it in place, returned `ok`, and the item stayed
outstanding on every later audit. Measured against a `next` build, `*`, `+` and
`1.` each resolved on base and stopped resolving at round 2's head — a
regression, not a gap in new behaviour. The hyphen form of the same shape was
already broken on `next` and is fixed here too: one classifier cannot be right
for three markers and wrong for the fourth.

`parseGapEntryFieldLine` is now the single place a line is classified as a
field, and it reports the offset at which the VALUE begins. The rewrite happens
at that offset rather than through a second regex, so a line the classifier can
select is one whose rewrite it has already located — the selection and the
rewrite cannot disagree. Both `DEFERRED_STATUS_FIELD_RE` and
`DEFERRED_STATUS_REWRITE_RE` are deleted rather than widened. A read-back guard
returns `rewrite_not_readable` rather than `ok`; it is unreachable by
construction today and is the fail-loud floor under the next divergence.

B3. This is the end state the round-3 review prescribed on both #3739 and
#3773: #3773's shared classifier, parameterised by this PR's marker set, with
this PR's two status regexes deleted. #3773 lands first. Its hyphen-only strip
is consistent with `next`'s hyphen-only splitter today, so the writer/reader
divergence is created by THIS merge, which is why widening every consumer
belongs to the PR that widens the domain.

m7. The heading path marker-stripped its lines before calling the reader, so
the reader's fence scan ran over text the splitter never saw: `- ```sh` is an
ordinary bullet to the splitter but strips to a fence opener, and a
`**Status:** resolved` after it was suppressed as fence content — a resolved
entry resurfaced as open. Stripping now happens inside the reader, after the
fence scan.

m8. `rawGapEntryText` stripped a marker off line 0 unconditionally, but on the
heading shape line 0 is the heading TEXT: `### 1. Race in the writer` was
silently renamed to `Race in the writer`, and the name is the key acknowledge
matches on. Line 0 is stripped only when the splitter accepted it as an opener.

Also removed: `splitDeferredHeadingEntries`, whose sole caller only null-checked
it (round 3, M4 — the claim was zero callers, which was wrong; the wrapper's
`.map` was waste at the one call site), and `stripLeadingBulletMarker`, which
this change leaves with no callers at all. The export surface narrows to the two
splitter regexes the behavioural parity test reads (M6).

[PEER-ASK pr-order-12d5]
q: Reviewer blocked both on merge order. I'm declaring #3773 lands first and
   building the end-state shape into #3739 now (both my status regexes
   deleted). Does that match your plan?
reply: CONFIRMED - same order, derived independently. #3773 cannot carry the
   fold: `DEFERRED_BULLET_MARKERS`/`BulletMarkers` have zero occurrences at
   `next` (verified), so the prescribed end state is not executable inside
   #3773 without absorbing this PR's work.
deadline: 03:55 UTC (answered before it)
fallback: declare #3773 first, adopt end-state shape in #3739, push+comment
decision: proceeded as stated; #3773 lands first, this PR carries the widening
   of every consumer.

Refs #3740

* test(#3702): pin the detect/strip symmetry, and drop a white-box test that could not reach it

Round 3, Blocker 2 and Minors 6 and 9.

B2. The regression shipped green because no fixture put a marker on a nested
status line. Four markers x {nested status line}, each asserting the entry
READS BACK as acknowledged rather than that acknowledge merely reported `ok` —
reporting `ok` over a line the reader skips is the whole defect. Plus the bare
capitalised `Status:` case (the reader stores it case-sensitively, so the
writer must not select it), and an idempotence test, which is the failure the
defect actually produced: the item resurfaces, is acknowledged again, and never
settles.

Each of these was run against the pre-fix build first: all five fail there and
pass here. Two further assertions in the block are labelled CONTROL because
they held pre-fix — they guard the new offset-based rewrite and the opener-flag
threading against regressing, and calling them regression tests for a reported
defect would overclaim.

M6. The round-2 parity test asserted that four writer-side regexes embedded the
same source string. That is true of a detect/read asymmetry too, so it could
not have caught B1 — and two of the four regexes were widened into `export =`
purely to let it read them. Replaced with a behavioural test that drives the
real seam: every marker that opens an entry must also resolve it through
acknowledge. The structural assertion is kept for the two splitter regexes,
which really are two copies of one alternation.

m9. `expectedResolved` was computed and immediately voided; the loop beneath it
already asserts both polarities.

m7/m8 coverage lands here too: a bullet whose content is a fence opener must
not suppress the entry's fields, and a heading beginning with a list marker
must keep it in the entry name.

* docs(#3702): document the deferred-items entry shape where the file is written

Round 3, Major 5, and #3702's own item 2. The widened grammar was documented in
the reader (`forensic-audit.md`) but not at the write site, where
`executor-examples.md` still said only "log to deferred-items.md" — so the
question the issue actually raised, which shapes count, remained unanswered
anywhere a human writes the file.

States what opens an entry (`-`, `*`, `+`, and `1.` when the list starts at
`1.`), that `1)` is not a marker here, that a separator closes the list and
fenced content is never an entry or a field, and that an entry without an
explicit `status: resolved` stays open by design.

* chore(#3702): regenerate the changeset through the generator

Round 3, Minor 10. The fragment was hand-named against 64 generated names on
`next`, and its body ran ~250 words against CONTRIBUTING's one-sentence form.
Regenerated via `npm run changeset`, which is also what the random three-word
name is for: concurrent PRs never collide.

* fix(#3702): the fence gate lives on the seam both sides call, not just the reader

Found by the pre-push adversarial review of this round, and it is a regression
this round introduced rather than a pre-existing one.

`extractGapEntryFields` applied `fencedLineSet` before classifying; the
acknowledge writer's status-line search did not. So a `status:` line inside a
fenced block was SELECTED by the writer and SKIPPED by the reader — the write
produced a line nothing reads, the read-back guard refused it, and the entry
became impossible to acknowledge at all: `audit acknowledge` raised an internal
error and `complete-milestone` halted on it.

Measured, `- alpha` / fence / `  status: pending` / fence:

  next          ack=ok                   -> reads back "acknowledged"
  round-2 head  ack=ok                   -> reads back ""      (the B1 defect)
  before this   ack=rewrite_not_readable -> refuses entirely   (worse than next)

`entryFieldLines` is now the seam — per line of an entry, the field it declares
or `null`, fences included — and the reader and the writer both go through it.
That makes "the writer cannot select a line the reader will not read back"
structural rather than asserted, which is what the previous commit's message
claimed while a second read-side filter still lived outside the classifier.

Two comments corrected with it. The read-back guard is NOT "unreachable by
construction": this round shipped a reachable path to it, which is precisely
what an invariant asserted in a comment is worth. And the M6 replacement test
put its marker only on the entry opener, so it passed against the defective
build — the exact weakness it was introduced to fix in round 2's test. It now
marks the nested status line too, and fails pre-fix like the rest.

Round-3 tests against the pre-fix build: 10 of 12 fail there, and the 2 that
hold are labelled CONTROL because they guard this round's new code rather than
pin a reported defect.

* fix(#3702): one end-of-file CRLF algorithm, adopting #3773's with its B4 closed

Round-4 M1. Two open PRs shipped two different answers to "what line ending
does an entry that ENDS THE FILE get?", and the review's ruling was that the
disagreement needs one answer, not two. Neither shipped answer was that one.
Measured on builds of both heads:

  case                                     #3739 r3   #3773   here
  undelimited single entry, CRLF preamble    pass      FAIL    pass
  LF-dominant list, one stray CRLF at EOF    FAIL      pass    pass
  (the other five)                           pass      pass    pass

This PR's content.endsWith('\r\n', matchIndexInContent) reads the terminator of
the PREVIOUS line, so it propagated an isolated CRLF into an LF-dominant list --
refuted by #3773's own LF-dominant fixture, ported here. Withdrawn.

#3773's crlfAtEof asks the right question -- does anything before the entry,
within scope, contradict CRLF -- and fails closed. But its scope goes EMPTY for
an undelimited single-entry list, because the entry-list region runs from the
first entry's start to the insertion point and those coincide; crlfAtEof('') is
false by its own before.length > 0 guard, so 'preamble\r\n\r\n- alpha' gained a
bare \n in a CRLF document. That is #3773's B4, verified by driving its head.

Adopted here with the scope widened to everything preceding the insertion point
where the preferred region is empty, rather than asserting LF from no evidence.
That only ever loosens a scope carrying zero information, and the predicate
stays fail-closed over the wider one. An entry at offset 0 of an undelimited
document has no evidence under either scope and stays LF.

Tests: 10 added. Negative control, driven -- 1 of the 10 fails against this
branch's own pre-fix head (the stray-CRLF fixture); B4 fails against #3773's
head; the remaining 8 are the scope counterexamples ported with the function,
which were regression pins in #3773 and are guards here. Each still kills a
simpler algorithm: drop any one and a refuted scope passes again.

Four deferred-items suites 450/450, 0 skipped. npm run lint:ci exit 0.

* fix(#3702): drop the unreachable rewrite_not_readable guard (B3)

Round-4 B3: the status had zero test coverage in either file. The review
offered two branches -- drive it from a test, or delete it and stop carrying an
untested terminal status. Taking the second, with the reason stated rather than
assumed.

Why it cannot be driven. Round 3 added the guard after a fenced `status:` line
proved the writer could select a line the reader would not read back. Round 3
then closed that divergence STRUCTURALLY, by routing the writer's line selection
and the reader's field extraction through one entryFieldLines seam. The guard
now detects a state construction prevents: 21 document shapes were driven
against it -- fence openers on the bullet line for every marker in the widened
set, duplicate and triplicate status lines, bolded and nested variants, fences
between duplicates -- and none reached it. The only seam that would is routing
the internal call through the module's exports so a test could stub it, which
reshapes production surface for a test.

Why leaving it undriven is not free. RULESET.TESTS.mutation-score runs Stryker
incrementally over changed files at an 80% threshold and says to treat a
surviving mutant as a failing test specification. An undriven `if` on a changed
file is exactly that, on both the condition and the .toLowerCase() comparison.

What this gives up, stated rather than hidden: if a future change re-splits the
writer's selection from the reader's extraction, acknowledgeDeferredItem returns
ok over an item that stays outstanding -- the original #3702 defect class. One
correction to the review's framing: match_verification_failed does NOT backfill
it. That check runs BEFORE the write and compares the matched span to the
target, so it cannot see a post-write read-back failure. The protection against
re-splitting is the shared seam and the round-3 tests that pin it, not a runtime
assertion. A comment at the removal site records all of this.

Removing it also drops the union member from both files, which resolves the PR
body's internal contradiction (it claimed no type-signature changes while adding
one) and the duplicate-status surface #3773 collides on.

No test changed behaviour: 450/450 across the four deferred-items suites, 149/149
across the audit suites, npm run lint:ci exit 0 -- the same figures as before the
removal, which is itself the evidence that nothing exercised the branch.

* fix(#3702): the deferred fence gate is indent-unbounded, like the rest of the grammar (M2)

Round-4 M2. scanFencedBlocks is CommonMark, which caps a fence delimiter's
indent at three spaces -- a fourth makes it an indented code block instead. This
grammar had already opted out of that cliff for entry openers ([ \t]*) and for
THEMATIC_BREAK_RE (^[ \t]*), but not for fences. So a fence at four spaces was
not a fence to the gate, and a `status: resolved` line inside it RESOLVED the
entry containing it.

That is not an exotic shape. A fenced block written under a NESTED bullet sits
at four spaces, so ordinary hand-written deferred-items.md files reach it.
Driven before the fix at indents 4, 5, 8 and a leading tab: all four silently
resolved. It is the #3702 silent-resolution defect class in a new place.

gsd-core/references/executor-examples.md, added by this PR, states flatly that
"nothing inside a fenced code block is an entry or a field". The review offered
fixing the parser or bounding that claim in three places. Fixing it -- the claim
is the one users will rely on, and the grammar had already chosen unbounded
indent everywhere else.

NO second fence dialect (the rule blankIndentedFenceDelimiters states). The
classification is still done by scanFencedBlocks, the one exported CommonMark
state machine, over a de-indented VIEW of the same lines. Run lengths, backtick
vs tilde, closer-must-match-and-not-trail, info-string rules and the
unterminated-at-EOF case remain that engine's answers. Indent is the only
dimension hidden from it, and it is exactly the dimension this grammar has
already declared it does not measure. Index alignment is 1:1 -- map preserves
length -- so every returned line index still addresses the original line.

Scope is the deferred grammar only. Both marker-parameterised call sites gate on
markers.blockStructure, which the Gaps set does not set, so Gaps reaches an empty
set. Verified, not asserted: the 47-fixture Gaps differential (marker x
line-ending x separator x fence x break x key-shape x list-shape) is
BYTE-IDENTICAL across this change, 8033 bytes both sides.

Tests: 14 added, of which 8 fail against the pre-fix source and pass here; the
other 6 are the deliberate controls -- indents 0 through 3, which must NOT move,
and the Gaps opt-out guard.

Four deferred-items suites green; the 58 suites touching uat/deferred/sectionizer
run 6045 tests with an IDENTICAL failing set before and after this change (17
pre-existing environment failures -- installs and an unpinned GSD_EMITTED_BASE;
emitted-attribution passes 259/259 in isolation with its base pinned). lint:ci
exit 0.

* fix(#3702): changeset, both prose parsers, and the minors (M3, M4, m1-m3, m5, n1-n2)

M3 -- the changeset omitted a user-BREAKING change. Measured against next: a
heading-delimited deferred-items.md written with `*`, `+` or `1.` went from
"0 entries, so complete-milestone has nothing to acknowledge and closes" to
"1 entry, the CLI writer refuses the heading shape, ACK_FAILURES accumulates,
exit 1". The `-` form already halted and is unchanged. That is release-note
material: a close that used to succeed now fails, and the correct response is to
fix the file, not revert. Also names the fence-indent fix below, and adds #3740
so #3773's issue is attributed here as it is absorbed.

M4 -- gsd-core/workflows/progress/steps/forensic-audit.md is a SECOND,
model-executed parser of the same grammar, and prose cannot carry a parity test.
Its widened text stated the start-at-1 rule, fences and separators but not the
`1)` exclusion nor the nine-digit ordinal cap, both enforced in code with pinned
tests. Both stated now, along with the round-4 fence-indent rule. (No ack
fragment: the size ratchet's currentSizes does a NON-recursive readdirSync of
gsd-core/workflows and agents, so a file under workflows/progress/steps/ is
outside its scope -- verified by reading the helper, not by the green.)

n1 -- executor-examples.md documented that the BOLDED status key is matched
case-insensitively and left the bare key's rule to inference. Driven: bare
`Status: resolved` is NOT read, so the entry stays open with no warning, while
`**Status:**` is. Stated explicitly, with the digit cap and the any-indent fence
rule (n2).

m1 -- boundary coverage was 2/3. limit (999999999.) and limit+1 (1234567890.)
were pinned; limit-1 (12345678.) added, per RULESET.TESTS.boundary-coverage.

m2 -- THEMATIC_BREAK_RE and the tab-expanding indent counter are hand-rolled
CommonMark rules with no in-repo peer to compare against, so the parity
assertion is against the SPEC: eight positive and five negative fixtures, plus
the two DELIBERATE divergences pinned as deliberate (`+` is a separator here but
not in CommonMark, because `+` is a list marker in this grammar and `+ + +`
would otherwise be a phantom entry; indent is unbounded). One fixture was
initially wrong -- `-- -` IS a CommonMark break, since the spec allows free
spacing between the three characters -- and the parser was right.

m3 -- the result union is hand-duplicated in audit.cts as part of a deliberate
structural view of uat.cjs, so the fix is not to delete a copy but to make drift
observable. Every REACHABLE status is now driven from a fixture; four of the six
(ambiguous, unsupported_heading_shape, already_resolved, match_verification_failed)
had no assertion anywhere in the suite before this. match_verification_failed is
still undriven and the test says so rather than omitting it.

m5 -- DECLINED, with the measurement. The review is right that `(\s*)` in the
opener and `/^[ \t]*/` in the reader disagree about \f, \v and NBSP, but its
prescribed narrowing was implemented, driven and REVERTED: as shipped, an entry
indented with any of those surfaces, parses its status field, acknowledges, and
reads back acknowledged -- a complete round-trip. Narrowing turns all three into
SILENTLY DROPPED entries, which is the #3702 defect class itself and the opposite
of this file's stated fail-safe rule. A latent inconsistency in the safe
direction is not worth a live regression in the unsafe one. Pinned by three
round-trip tests so the prescription cannot be re-applied silently; if it is ever
closed, the direction is to make the readers agree with the opener, not to make
the opener reject lines it accepts today.

Four deferred-items suites 475/475, 0 skipped. lint:ci and lint:changeset exit 0.
The 47-fixture Gaps differential is byte-identical at 8033 bytes.

* fix(#3702): the pinned `## Gaps` phantom now cites its issue (m4)

Round-4 m4. The second assertion in the Gaps byte-for-byte test pins a real
defect as expected output: a spaced hyphen thematic break in `## Gaps` is read
as an ITEM, so `- - -` surfaces a phantom open gap named `- -`. Reproduced on
pristine next at 389bc86e0 across nine separator shapes -- every spaced hyphen
form is affected, `---`/`----`/`* * *`/`___` are not, and the dividing line is a
space after the first hyphen (the Gaps opener is /^(\s*)(-)\s/ with no
thematic-break concept at all).

Filed as open-gsd/gsd-core#3898. The pin stays: scope-limiting Gaps is the point
of the blockStructure opt-out, and this assertion is the only thing that would
notice the Gaps path moving. What was missing was the tracking -- a pinned defect
with no issue behind it reads as intended behaviour to the next reader. The
comment now says which it is and what the expectation becomes when #3898 lands.

* fix(#3702): an unterminated fence runs to the end of its entry, never past it (B1, B2)

Round 4 de-indented every line before `scanFencedBlocks`, so a fence
opened at any indent — and `scanFencedBlocks` runs an unterminated
fence to end-of-document — so one stray delimiter swallowed every entry
after it into the entry before it. `- a` / blank / four-space ``` /
blank / `- b` yielded ONE entry where `next` yields two: a widening
that made an already-counted item vanish, on the mixed-file shape #3702
exists to close. Reproduces at indent 0 as well.

The bound is the entry. CommonMark closes a fence with its container
and a container at the next item at its level; this parser extends
that to a document-level stray delimiter, where CommonMark would
swallow to EOF and the fail-safe rule (surface, don't drop) will not.
`scanFencesFrom` reports the unterminated opener and the walk supplies
the bound — the next line shaped like a top-level item — then RESCANS
from it, so a later delimiter is read on its own terms. Still one
fence dialect: every block boundary is `scanFencedBlocks`' answer.
Entry-scoped `fencedLineSet` (the field reader) already ran an
unterminated fence to the end of its lines, so reader and walk agree
by construction.

Tests: the M2 pin that asserted `[]` for a stray fence before an item
flips (the item counts); the round-4 "runs to end-of-file, exactly as
CommonMark says" test is retitled — its assertion stands because the
bound is the entry — and extended with the next entry; a new block pins
the review reproduction at both indents, a terminated deep fence still
gating, the gated status inside the bounded fence, the rescan case, and
the heading-tokenizer caveat (at indent 0 the tokenizer applies
CommonMark's own fence rule, so a heading after a stray delimiter is
body text there, exactly as on `next`).

Reverted in isolation against the final tree: 3 named tests fail.

* fix(#3702): `0.` starts an ordered list (M1)

The start-at-1 rule applied unconditionally dropped ONLY the first item
of a `0.`-numbered list — the run then started at `1.` — which is the
mixed under-report that looks like a clean parse. CommonMark §5.2
permits any 1-9-digit start and a `0.` list is ordinary; a sentence
opening with "0." is not a shape anyone writes. The threshold is now
`> 1`. The cost is restated accurately in the doc comment and pinned:
a list starting at 2 or more, at a paragraph position, reads as prose
until its first `0.`/`1.` line — the prefix, not the whole list.

Boundary tests at the threshold itself: `0.`, `1.`, `2.` starts, `00.`/
`01.`, and the prefix-loss case. Reverted in isolation: 1 named test
fails.

* fix(#3702): a non-1 ordinal is an item wherever a list is already open at its level (M2)

The per-indent run memory recorded whether the previous opener was
ORDERED, so a bullet item closed the run and `1. a` / `- b` / `5. c`
folded `5. c` into `b` — another mixed-file under-report. In CommonMark
`5. c` there opens a fresh ordered list (start=5): a non-1 start is
refused only where it would interrupt a PARAGRAPH (§5.3), and after a
list item it interrupts nothing. `ListRuns` now records "a list is
open here"; the start rule applies where no list is open at the line's
level — the positions a sentence can occupy — so the round-2 B2 pins
(doc start, after a heading, after a paragraph) hold unchanged.

Two round-2 pins move with it, both CommonMark-backed: `1. alpha` /
`- beta` / `2. gamma` is three items, and a nested `3. status:` after
a nested bullet is a nested item (a field line, as `- status:` would
be); the "rejected ordinal is not stripped" pin is re-anchored at a
paragraph position, where it still holds. Reverted in isolation: 4
named tests fail.

* docs(#3702): the two runtime-loaded docs state the grammar the parser ships (B3, M4 parity)

`executor-examples.md` (the write-site doc) and `forensic-audit.md`
check 7 (the model-executed parser) both asserted "never silently drops
a possibly-open item" over a grammar that dropped three measured shapes.
Both now carry the round-5 grammar — `0.`/`1.` starts, a non-1 ordinal
inside an open list, an unclosed fence ending with its own entry — and
the fail-safe sentence is kept with what it does NOT cover named
beside it: a fenced line, a separator, and an ordered list numbered
from `2.` upward at a paragraph position, and nothing else.

* docs(#3702): changeset reflects the merged contract

The "Breaking, and deliberate: … HALTS complete-milestone" paragraph
described a refusal that #3781 removed from `next`; a heading-shaped
file written with a newly recognised marker now surfaces its entries
and `complete-milestone` acknowledges them in place. The fragment cites
#3702 alone — #3740 and #3775 closed on `next` through #3940 and #3989;
this PR's shared reader/writer classifier subsumes both fixes rather
than closing either issue. The round-5 grammar (ordered start, unclosed
fence bound) is stated in the user-facing sentence.

* fix(#3702): the heading-shape insert lands on a line the reader reads, and keeps a closing `#` sequence

Found by the round's pre-push adversarial review. An entry whose body ends
in a fenced block — closed, or unclosed and therefore running to the
entry's end — received `status: acknowledged` AFTER its last non-blank
line, i.e. as fence content: the writer returned `ok` and the reader
never saw the marker, the item stayed outstanding. That is the #3702
class itself (a write nothing reads), on the shape #3781 just opened.
The insert now walks back over blank AND fenced lines, classified by the
reader's own `fencedLineSet`, so the marker lands on a line the reader
reads; pinned as round-trips for an unclosed fence, a closed fence, and
a pending entry ending in an unclosed fence before a heading. Reverted
in isolation: the round-trip test fails.

Separately, the leaf line-0 rewrite (`### status: open ###`) dropped the
closing `#` sequence; it is kept now. Cosmetic, pinned.

* docs(#3702): the prose parser states the bare-key case rule; both docs say what an unclosed fence does, no more

`forensic-audit.md` check 7 called `status: resolved` case-insensitive
where the code reads a bare key lower-case only (the bolded form in any
case; the value case-insensitively) — `executor-examples.md` already said
so, the model-executed parser did not. And both docs claimed "a stray
delimiter cannot hide the entries after it", which overstates B1: an
UNCLOSED fence ends with its entry; a closed pair of delimiters is a
fence, whatever sits between them, as CommonMark reads it. Found by the
round's pre-push review.

* fix(#3702): a heading whose text is a fence delimiter is a heading, not a fence

Second finding of the round's pre-push review, one door over from the
first: for a leaf headed `### ```` (or `~~~`) the entry-level fence scan
read line 0 — the heading TEXT, not a Markdown line — as a fence opener,
so every body line was fenced: the reader read no field under it, and
the writer's marker (placed by the same scan) landed on a line nothing
reads — `ok`, item outstanding. `entryFencedLines` now owns the entry's
fence view for reader and writer alike, and a leaf's line 0 never opens
a fence (the leaf tell is `openerFlags[0] === false`; a pending or
headless entry's line 0 is a marker line, never a delimiter). Pinned for
both delimiters, read and write; reverted in isolation the pin fails.

---------

Co-authored-by: CI Rebase Check <ci@gsd-redux>
Co-authored-by: Tom Boucher <trekkie@nomorestars.com>
2026-08-31 13:44:47 -04:00
..