b90eef28e8
* enhance(#3829): report code review severity counts and record a per-finding disposition `code_review_gate` extracted `status:` from REVIEW.md's frontmatter and discarded the `critical`/`warning`/`info`/`total` values sitting in the same range, so its output was byte-identical for a review with one `info` finding and a review with a Critical. Nothing anywhere recorded what happened to a finding: no file under `gsd-core/workflows/` branches on `issues_found`, and `gsd-verifier.md` has zero references to REVIEW.md. A phase therefore reached `phase.complete` with Criticals standing and no trace they had been seen. Both halves were approved on the issue; the gate stays advisory. A — severity surfacing, in `execute-phase.md`. The gate states the breakdown it already parsed, accepting `blocker:` as the documented tier-equivalent of `critical:`. The breakdown is shown only when all four counts are numeric (`REVIEW_COUNTS_OK`); otherwise the countless message stands, because gating on the total alone still emits `6 findings — critical` for a review carrying a total and nothing else. Frontmatter is extracted by an `awk` that emits only when it saw the CLOSING delimiter, after stripping CR. A `sed` range re-opens on a body `---` and runs to EOF: first-match protects a key the frontmatter always carries, but not an optional one, so a review with no `findings:` block and a body `total:` line would have reported the body's number. An unterminated block would leak the whole body the same way. Every read is guarded and `|| true`-terminated. This step is advisory, and under `set -e`/`pipefail` a non-matching `grep` exits 1 — an assignment whose command substitution fails would take the step down with it. A REVIEW.md that is missing, a directory, or unreadable now leaves the counts empty and execution continues. B — per-finding disposition, in a new lazily-read step file, `gsd-core/workflows/execute-phase/steps/code-review-disposition.md`, referenced from the gate in the established plain read-and-execute form. One row per finding ID, defaulting to `open`, and: - `fixed`/`skipped` are reconciled from REVIEW-FIX.md, whose section headings are matched WHOLE — a prefix match let `## Fixed Issues Verification` classify every finding beneath it as fixed — and only when the fix report names the SAME finding. Finding ids are reused across re-reviews, so matching on the id alone let a stale fix report declare a brand-new CR-01 already fixed. - headings inside fenced blocks are ignored; a quoted example is not a finding. - an id listed under both sections resolves by first occurrence, not row order. - a recorded disposition is preserved together with the reason in its Source cell, escaped pipes included, and a hand-mangled row missing its trailing pipe still keeps its decision. - a decided finding the current review no longer reports is CARRIED and marked; `--auto` rewrites REVIEW.md each iteration, so this is routine, and dropping the row would erase the record that it was seen. An untriaged `open` row for a vanished finding is not carried. A review reporting nothing still reconciles an existing ledger rather than freezing it. - a run that changes no disposition rewrites nothing, so a re-executed phase does not produce a docs commit whose only delta is a timestamp. The record is a sibling artifact, not a section inside REVIEW.md: `--auto`'s re-review loop rewrites REVIEW.md every iteration, so a ledger kept inside it would not survive the next pass, and REVIEW.md has a single writer that this step is not. B lives in an extracted step file because `execute-phase.md` was 91,493 bytes against a 98,304 hard cap the size-budget test calls a red line, and because `scanWiredKinds` caps a call site's dispatch-coverage region at 6000 characters — an inline version pushed the `kind == "gate"` paragraph out of that window, which silently drops `gate` from the covered set and fails `gen-capability-registry --check` while pointing at the capability rather than at the prose that displaced it. Extraction is what that size test's own message prescribes, and it leaves the file at 93,854 bytes. The tests execute the shipped script rather than modelling it. Three adversarial review rounds each refuted "the mirror is faithful", and mutation testing agreed: with a hand-written model, deleting the carried-row logic from the shipped file turned nothing red. The suite now extracts the embedded script — undoing exactly the four shell double-quote escapes — and runs it, so all ten mutations of its behaviour are caught. * chore(#3829): set changeset fragment pr to 3861 * fix(#3829): keep execute-phase.md under both size ceilings and propagate the launcher probe The first push failed `full test (macos-latest, 24, shard 3/3)`. Two things it caught that the CI-selected scope for this diff does not run, and that I therefore did not run either: 1. `execute-phase.md` is governed by TWO ceilings, not one. The XL hard cap in `tests/workflow-size-budget.test.cjs` (98304) was satisfied at 95179, but the frozen ADR-857 pre-phase-6 ceiling in `tests/claude-orchestration.test.cjs` (93600) was not. The whole budget from base is 2107 bytes, which the inline reporting half alone did not fit. That half now lives in the extracted step file alongside the disposition half, and the parent carries only the paragraph that reads and executes it — 91529 bytes, 36 over base. 2. The step file calls `gsd_run`, so it owes the hermes runtime-home probe that `tests/runtime-launcher-parity.test.cjs` (E) requires of every workflow file that does. Propagated with `node scripts/sync-runtime-launcher.cjs`, the remedy that test names. Verified with the FULL unit suite this time rather than the scoped selection — 14 shards, 0 failures — plus `npm run lint:ci`, and a re-run of the ten mutations of the shipped disposition script, all still caught. * fix(#3829): stop the disposition step instructing the agent to execute itself Blocker 1 and Minor 7 of the round-1 review are one defect. The step file carried a copy of execute-phase.md's pointer paragraph, so it named its own path as something to "read and execute" — unbounded self-recursion at runtime — and that copy is also the duplicated paragraph, sitting immediately above the full instruction it duplicates. Removing the copy resolves both. execute-phase.md remains the only surface that points here, which is what it always intended. Two structural tests guard it. Both are red against the pre-fix file: no behavioural test could see either defect, because they execute the node script through the process seam and so never read the prose that tells the agent what to load. * fix(#3829): re-derive the ledger paths in the block that uses them Blocker 2. The disposition block reads REVIEW_FILE, DISPOSITION_FILE and PADDED, all derived in the step's FIRST shell block. Each fenced block is dispatched as its own shell, so all three are empty by the time the second block runs: the ledger write lands on a bare `-REVIEW-DISPOSITION.md` path and the review read finds nothing. The step then reports success having produced no artifact — the feature's central acceptance criterion, silently unmet, with no error to notice. The tell was already in the file: the gsd_run shim preamble is re-emitted in the second block for exactly this reason. These three paths belong beside it, and now are. The guard test asserts the general property rather than the instance — every block derives what it reads, inheriting only the step's declared inputs (PHASE_DIR, PHASE_NUMBER) — so a third block added later cannot reintroduce it. Red against the pre-fix file. * test(#3829): assert the counts mirror against the shipped shell, and execute its guards Major 4, with Minor 6 and part of Minor 9. The disposition builder stopped being a mirror three rounds ago, and the reason given then was that a hand model of a shell-embedded script drifts while the tests stay green. parseGateCounts kept its mirror anyway. That argument does not stop applying at the boundary between the step's two shell blocks, so the mirror now loses its authority: it is asserted against the shipped awk and greps, run under `set -euo pipefail` in a real shell, across every fixture it is exercised on. Negative-controlled in both directions. Dropping `blocker:` from the mirror alone fails the parity test; replacing the shipped awk with the leaky `sed -n '/^---$/,/^---$/p'` range fails it on the unterminated-frontmatter fixture. Divergence in either half is now red, which is what the finding asks for. Skipped on win32, where there is no bash to compare against. Minor 6: the zero-count edge is covered — `0` is numeric, so a zero-finding review reports `0 findings — 0 critical, …` rather than falling back to the countless form. A guard written against truthiness would have failed here silently, and now cannot. Minor 9, partially: running the block makes its advisory guards behavioural, so the four `src.includes()` assertions that stood in for them are retired — a missing and an unreadable REVIEW.md are now proven not to abort under `set -e`, rather than asserted to contain a string. The remaining docs-parity assertions are kept deliberately; see the PR discussion. * test(#3829): add the render/re-parse fixed-point property for the ledger Major 3. RULESET.TESTS.property-based-testing asks for at least one fc property on a parsing/transformation contract, and the ledger is one with a fixed point stated in its own prose: re-running the gate preserves every disposition except `open`, and rewrites nothing when nothing changed. Two properties, both driving the SHIPPED script rather than a model of it: idempotency — a second run reports `unchanged` and leaves the file byte-identical. Without it, the timestamp alone dirties the tree on every phase re-run. round-trip — a hand-recorded decision AND the reason beside it survive render -> re-parse -> render, escaped pipes included. The Source cell is where a human writes why something was deferred, so losing it loses the only thing that instruction asks for. Negative-controlled per property: disabling the unchanged-check fails the first and only the first; discarding the carried source cell fails the second and only the second. numRuns is 40 rather than the shared 200 because each case spawns the shipped script twice through the process seam. The seed stays pinned, so a failure still reproduces; the deviation is stated in the file header rather than made silently. * fix(#3829): state a stale fix-report match instead of dropping it silently Minor 5, plus the finding-id census this round owes. Exact-title coupling stays — ids are reused across re-reviews, so a stale REVIEW-FIX.md must not mark a brand-new CR-01 as already fixed. What changes is the silence. A row that stays `open` because the report named a different finding under the same id is indistinguishable, to any reader, from a row that stays open because no report mentioned it. The gate now names the ids it could not reconcile, on both report paths, and stays advisory throughout. The census (RV4, self-found — the review did not ask for this). The script enumerates finding-id prefixes in three places: the heading matcher, the ledger re-parser, and the severity map's keys. The DOMAIN those enumerate is owned elsewhere — gsd-code-reviewer.md's body template and its Label-equivalence paragraph — so it can acquire a member without this script changing. Reached: CR, BL, WR, IN — 4 of 4, all present. Not reached: none today. What follows if that changes is the payload: an unlisted prefix is not mis-tiered, it is INVISIBLE — the finding never enters the order list and gets no row at all, so the artifact silently under-reports the review it is meant to record. Adding a prefix to two of the three copies fails the same way, and additionally drops carried rows on the next run. Two guards rather than a rewrite: hoisting the alternation into one constant means rebuilding three regexes inside a double-quoted shell string, which is the exact class of edit that produced both of this round's blockers. The guards make the drift loud instead, and are negative-controlled against each of the two ways it can happen. * docs(#3829): keep the feature reference descriptive, not instructional Minor 8 — a Diataxis mode mix. "Set `deferred` by hand and put the reason in the Source cell" is a how-to instruction sitting in a reference doc. The information belongs there (a reader needs to know the field exists and what preserves it); the imperative does not. Rewritten to describe the field instead: `deferred` is the one disposition the gate never writes, and the reason recorded beside it survives re-runs. The same pass records Minor 5's new behaviour, since the reference described the title coupling but not what happens when it misses. The imperative form is kept where it belongs — inside the ledger the gate renders, which is where a reader meets the field and the only place an instruction has an audience. docs/FEATURES.md regenerated from it; `gen-features.cjs --check` is green. * fix(#3829): close six defects found by reviewing this round's own fixes None of these came from the maintainer's review. They came from adversarially reviewing the five commits above before pushing them, and two are worse than anything the round was opened to fix. 1. A foreign fence marker swapped an example for a finding. The heading scanner toggled fenced/not-fenced on ANY fence marker, so a ~~~ line inside a ``` example closed the fence and the example's real close reopened one. Driven: a review quoting ~~~ inside a fenced example produced a ledger recording CR-77, the illustration, and omitting CR-01, the actual finding. A confidently-written artifact wrong in both directions at once. The open marker's character and length are now remembered, and a fence closes only on the same character at least as long, per CommonMark. 2. The disposition block had no status gate at all. The prose above it says it runs only when the review reports issues — but block 1 computes REVIEW_STATUS, emits nothing, and its shell is discarded, so no later block could act on that condition even in principle. A prose gate on a value nothing downstream can see is not a gate, and a clean re-review would rewrite a ledger it was never meant to touch. Re-derived in block 2's own shell. 3. A numeric breakdown could still be internally false. `total: 0` beside `critical: 1` is four valid numbers rendering `0 findings — 1 critical, …`. Numeric was necessary and not sufficient; an inconsistent breakdown is now withheld for the same reason a partial one is. 4. The carried-marker strip ate hand-written prose. It removed a trailing `(not in the current review)` unboundedly and unconditionally, so a deferral reason that merely ENDED in that phrase lost it — the one field a human writes into this artifact. Now bounded to one occurrence, and only on rows the marker can legitimately be on. The no-growth property it exists for is re-pinned. 5. parseGateCounts diverged from the shipped pipeline in two ways no fixture reached. The shipped reads are `cut -d: -f2 | tr -d ' '`: `tr` removes INTERNAL spaces (`1 0` -> `10`) where `.trim()` keeps them, and `cut` takes only the second colon-field where a tail capture keeps the rest. The mirror models the pipeline now, and both counterexamples are fixtures — a parity assertion that agrees only on well-formed input asserts very little. 6. The prefix census guards were both partly vacuous. The drift guard read the two regex alternations and not the severity map, so a set could agree in both regexes while mis-tiering in the map. The domain guard scanned only `### XX-01:` headings — and BL appears in no heading at all, only in the Label-equivalence prose, so the guard passed purely because BL happened to be hard-coded and would have missed the next prose-defined prefix exactly as it missed BL. Both widened; the domain the guard now sees is BL, CR, IN, WR. Each fix fails a named test on reversion and none fires on the ordinary path. The property generator now deliberately produces the reserved suffix from (4), which a generator drawn only from innocuous characters could never reach. Also corrected: the previous commit's account of the empty-path failure. The script did not write a bare `-REVIEW-DISPOSITION.md`; it threw on reading the empty review path and the trailing `|| echo` swallowed it as a non-blocking skip. Same silent outcome, different mechanism, and the comment said the wrong one. * fix(#3829): the tests now run what bash runs — and six fixes to the fixes A second adversarial pass over the previous commit. It found a regression that commit introduced, and the reason it slipped through is the finding worth keeping. THE FIDELITY GAP. Every test here extracts the embedded script as TEXT and runs it. Bash does not: it expands the double-quoted `node -e "..."` argument first, so a backtick inside it is COMMAND SUBSTITUTION. The previous commit put one in a code comment. Bash duly ran it, failed with `+: command not found`, and handed Node a script two bytes shorter than the one 122 green tests were exercising. No behavioural test could see this, because none of them ever asked bash what it would actually pass. One now does, and it is the general guard: it catches an unescaped backtick, an unescaped $, and any other expansion the extractor cannot model. Then, in the shipped step: - A padded count silently disabled the sum check. `$((08 + …))` fails on base inference; it does not abort — the expansion sits in an `if` condition, where set -e does not fire — so the check simply never ran and an inconsistent breakdown passed with a stray diagnostic as its only trace. `10#` on every operand. - The status guard made the script's own reconciliation unreachable. A clean review with an EXISTING ledger must still be reconciled — decided rows carried, stale `open` rows dropped — or the ledger freezes showing findings as open that the review no longer reports. The guard now skips only when there is nothing to reconcile. - The carried marker is no longer stripped at parse time at all. Bounding the strip still ate a carried row's human-written reason. No-growth is a property of the RENDER, so it is enforced there: a marker already present is not appended again. Nothing is stripped, nothing doubles. - Fence openers are bounded to three leading spaces, per CommonMark. - parseGateCounts matched `[ \t]` where the shipped grep uses `[[:space:]]`, which covers form feed and vertical tab. Third counterexample of the same class, and a fixture. - The census drift guard checked only one direction, so a tier for a prefix the regexes never admit stayed green as dead code that reads as coverage. TWO OF MY OWN TESTS WERE VACUOUS, and the controls are what said so. The leading-zero test asserted exit 0 and a consistent verdict — both true before the fix. The clean-review test drove the node script directly, which never executes the shell guard at all: it passed unchanged with the guard made unconditional. Both are rewritten to test the layer the defect lives on, and both now fail when their fix is reverted. Every fix in this commit fails a named test on reversion, each mutation verified to have applied before its verdict was read. * fix(#3829): the carried marker can no longer outlive the carry A third adversarial pass. Its most important finding is a defect the SECOND pass talked me into, which is worth recording as plainly as the fix. THE MARKER BECAME A LIE. Pass 2 objected that bounding the carried-marker strip still altered a human-written reason, and proposed storing the cell verbatim instead. That objection was a preference, not a defect — its own driven output showed exactly one marker, which is correct — and adopting it created a real one: once the generated marker is stored it can never leave, so a carried finding that REAPPEARS in a later review still renders "not in the current review". The ledger then contradicts its own contents. Driven both runs. The strip is back, bounded to one occurrence and unconditional. The residual ambiguity is irreducible — a reason ending in exactly that phrase is indistinguishable from the marker — and it costs nothing real: on a carried row the render puts the phrase straight back, and on a current row the phrase was self-contradictory to begin with. The unbounded quantifier is what had to go, not the strip. The property now states that contract rather than asserting a verbatim survival the code deliberately does not provide. Also: - An ABSENT REVIEW.md abandoned the ledger it was meant to reconcile. The guard proceeds when a ledger exists, then the script read the review unconditionally, threw, and the trailing fallback swallowed it — the freeze the reconciliation path exists to prevent, reached through the door the guard opened. - Counts are length-bounded as well as digit-only. Bash integers wrap at 2^64, so a 20-digit count arrived at the sum as 0 and an inconsistent breakdown passed. - A closing fence must carry only whitespace after its marker; a line with an info string is an opener's shape and ended the fence early. - parseGateCounts matched [ \t\n\v\f\r] where the shipped grep uses [[:space:]], which under this UTF-8 locale matches EM SPACE. `\s` is the faithful model. Fourth counterexample of that class, and a fixture. - The agent-domain scan required [A-Z]{2,}, so a one-letter prefix like `C-01` — explicit and parseable, not prose — was invisible to it. AND THE FIDELITY GUARD PAID FOR ITSELF INSIDE ONE SESSION: writing this round's first draft I put backticks around a token in a code comment again, in the very commit whose subject is that mistake. The probe failed, named it, and no test of behaviour could have. Two of my own tests also had to be rewritten: one asserted things true before its fix, and one drove the node script directly where the defect lived in the shell. 383 pass across the touched files and the two size ceilings; ten lint gates green; every fix fails a named test on reversion, each mutation verified to have applied before its verdict was read. * docs(#3829): the Source reason is preserved, but not verbatim — say so Found by claim-auditing the response comment before posting it, which is the one place this would have been caught: the doc and the code were written in different commits and only a reader holding both notices they disagree. The feature reference said the hand-written reason is "preserved verbatim across re-runs". It is not, and deliberately so — a reason ending in the literal phrase "(not in the current review)" loses that trailing phrase, because it is indistinguishable from the carried marker the gate appends. The exception is stated rather than dropped, with the reason it is the better trade: storing the marker instead means it never leaves, and a carried finding that later reappears goes on claiming it is absent from the very review that reports it. A ledger wrong about its own contents beats losing a duplicated phrase, but only if the doc admits which one it chose. FEATURES.md regenerated; gen-features --check and lint:docs green. * fix(#3829): the gate now emits the counts it computes (B1a/B1b) Block 1 computed REVIEW_STATUS and the four counts and printed none of them, then the prose below asked the agent to display four of them. The shell exits at the closing fence and the agent sees only stdout, so those values were unobtainable: REQ-REVIEW-08 was unreachable in every shipped path and the fence was decorative. The rule was already stated one block down -- "a prose-only gate on a value no later block can see is not a gate" -- and applied only to block 2. It now governs the block that is this step's primary deliverable. Both arms emit, and the status gate is mechanical rather than prose: a clean/skipped/absent review prints nothing, an inconsistent or partial breakdown prints the countless form, and the full breakdown prints otherwise. Driven against the review's own case (critical: 1, warning: 9, info: 8, total: 18) with no appended emitter: Code review: 18 findings - 1 critical, 9 warning, 8 info. Consider running: /gsd:code-review 1 --fix * test(#3829): the counts harness stops manufacturing the output it asserts on (B2) runShippedGateCounts extracted the shipped fence and then APPENDED its own printf of the six internal variables before running it. Every counts assertion was green against a script that existed only inside the test process: the shipped fence emitted nothing, the tested fence emitted six lines because the test added them. That is why B1a shipped past a suite that looks like it covers exactly that surface -- the green was structurally incapable of turning red for it. The emitter now lives in the fence, so the harness reads the fence's own stdout and synthesizes nothing. Parity with the mirror moved up a level with it: renderGateMessage() renders both arms from the mirror's parsed counts and the assertion compares the WHOLE emitted message, so a drift in any parsed value changes the string or the arm it selects. Asserting on the observable is strictly stronger than asserting on five intermediates, and it can express what the old probe could not -- an absent review now reports NOTHING, which is a different fact from reporting a countless review. A fifth src.includes() assertion converted with it (round 1 retired four). It pinned the PROSE stating the countless condition, so it went red when the emitter moved into the fence while the behaviour it named was untouched -- the pin arguing for its own conversion. Negative control: reverting the shipped echo now turns 16 tests red. Before this commit the same reversion turned zero red, which is the finding. * fix(#3829): the disposition column is an enum, not any lowercase token (B3) ADR-227 requires a trust boundary to validate semantic SHAPE and to coerce a failure to the contract's safe default. The ledger is a trust boundary by construction -- the rendered instruction tells a human to hand-edit it -- and the prior-row parser captured column 3 as ([a-z]+), checked against nothing. One transposed character was enough. `| CR-01 | critical | opne | - |` is not the literal 'open', so it beat the default, was excluded from the `open:` headline count, and was carried forward forever. The ledger then reported the phase fully triaged off a typo. The asymmetry is what made this a correctness bug rather than a style point: a typo OUTSIDE [a-z] ('Deferred') already failed to match, lost the decision and reset the row to open -- safe. A typo INSIDE [a-z] was unsafe. The parser failed open in the one direction that matters. A row that fails the enum now yields no prior entry and the row falls back to 'open', by the same path the capital-D case already took. The property test could not have caught this: DECIDED is drawn from the vocabulary, so no property built on it can present an out-of-vocabulary token. Added JUNK, the arbitrary for the complement, deliberately lowercase so it stays inside the old capture's own character set -- the unsafe half is the token that LOOKS like a decision and is not. The new property also asserts the headline count agrees with the row it renders, which is the half the defect actually reported wrongly. Negative control: the new property fails against the ([a-z]+) capture and passes against the enum. * fix(#3829): a finding the heading parser cannot match is surfaced, not dropped (B4) Two independent parsers produce two numbers one paragraph apart -- the counts from REVIEW.md's frontmatter, the rows from `### <ID>:` heading matches against a closed CR|BL|WR|IN alternation -- and nothing reconciled them. A finding the alternation could not reach contributed no row, no note and no diagnostic, and the ledger then declared `open: 3 of 3` over a set strictly smaller than the console line had reported one paragraph earlier. Two findings recorded nowhere, and neither artifact said so. The PR's own argument for the closed alternation -- that an unlisted prefix produces no row rather than a MIS-CLASSIFIED one -- is the wrong trade under this repo's fail-safe rule. A dropped finding is demoted below every finding that parsed, and an unparseable finding is precisely the one a human most needs to see. Block 2 now derives the frontmatter total (anchored inside the findings: mapping, digit-and-length-bounded like block 1's) and hands it to the script, which reconciles it against the CURRENT review's matched findings -- order.length, never rows.length, which also counts carried rows and would either understate the shortfall or invent one. Surfaced exactly as the stale fix-report case already is: a non-blocking `unparsed: N` key plus the console line, both naming the two numbers so the claim is checkable. Code review disposition recorded: 3 of 3 finding(s) open (2 finding(s) recorded NOWHERE: the review reports 5, but only 3 matched the expected heading shape `### <CR|BL|WR|IN>-NN: <title>`) The key is emitted only when there IS a shortfall, so an ordinary ledger gains no noise key and the unchanged-run check is unaffected. Four tests, including three negative controls the round owed itself: a clean review gains no key, an absent/non-numeric total reconciles nothing rather than fabricating a shortfall, and a total SMALLER than the row count cannot render `unparsed: -1`. Reversion control: dropping the key turns the first red. * fix(#3829): pass --raw to the commit_docs config-get (#3763) Not from the review -- from a gate the base range added after it. #3763 lands `tests/config-get-raw-guard.test.cjs`, and this branch was its sole offender: a config-get command substitution without --raw feeds JSON.stringify output into a bash string comparison, where it silently never matches for string values. The consumer here is exactly that: if [ "$COMMIT_DOCS" = "true" ] Every other shipped call site in the tree already passes --raw (spike.md, fast.md, new-milestone.md, sketch-wrap-up.md, ...), so this is sibling convention, not a new posture. Worth recording because the two readings are both correct and they disagree: round 2's review cleared this exact line under ADR-3409 as "the safe member of that family", since `query config-get <key>` with no --pick exits 1 on absence and the fallback arm is reachable. That is still true -- --raw does not change it. The base then moved and added a gate that reads the same line for a different property. * fix(#3829): scope the count reads to the findings: mapping, not just the frontmatter (m1) `^[[:space:]]*total:` matches any indented key anywhere in the block, so a top-level key later named `total:`, `info:` or `critical:` was picked up ahead of the nested one. The block's own extensive comment is about scoping the FRONTMATTER, and the scoping stopped one level short of the mapping the values actually belong to. `status:` was never exposed -- it is anchored to column 0 because it IS top-level. The reads now run over the `findings:` block alone, selected by awk and cut at the next column-0 key. Block 2's REVIEW_TOTAL derivation (added with B4) already used that filter; this brings block 1 to it, so the two agree by construction rather than by coincidence. The mirror models the same scoping, and two fixtures drive it: a top-level `total: 999` ahead of a nested `total: 1`, and top-level `critical:`/`info:` ahead of theirs. Reversion control: unanchoring the shipped reads turns them red. * fix(#3829): severity comes from the section heading, not just the id prefix (M3) gsd-code-reviewer.md emits findings under '## Critical Issues' / '## Warnings' / '## Info', and that heading is the reviewer's own statement of a finding's severity. The walker already visits every line -- the fix-report path tracks '## ' sections -- so the signal was in hand and discarded in favour of the id prefix alone. A reviewer who mis-numbers a Critical as WR-04 while filing it under '## Critical Issues' produced a row reading 'warning'. The ledger's Severity column is the whole basis for triaging it, and it then disagreed both with the review it summarizes and with the frontmatter count line block 1 prints from findings.critical. Section first, prefix as fallback: a finding under no recognized section -- a review that does not use the documented headings, and every row carried from an earlier review -- keeps the prefix mapping, BL- included. Sections are matched WHOLE, exactly as the fix-report sections are, so '## Critical Issues Verification' does not re-tier what sits under it, and a heading inside a fenced example does not govern. Five tests: both mis-numbering directions, the prefix fallback across all four prefixes, the lookalike heading, and the fenced-example case. Reversion control: prefix-only turns the first two red. Sixth src.includes() assertion converted with it -- it pinned the exact source LINE of the enumeration loop, so it went red when that loop was reformatted while the property it names was strictly widened. It now asserts the property: every finding id, in order, once each. * fix(#3829): an untriaged row is carried too, not silently deleted (M1) The carry-forward kept a prior row only when its disposition was not 'open', so an untriaged row for a finding the current review no longer reports was dropped entirely. Combined with the reconciliation gap that left EVERY row open, a re-review deleted the whole ledger. The re-review loop rewrites REVIEW.md on every iteration, so REVIEW.md does not retain it either: run 1 records CR-01 open, the re-review renumbers it to CR-02, run 2's ledger contains neither. That is #3829's complaint verbatim -- "no trace of what happened to them" -- reproduced by the artifact built to prevent it. The old justification, "nothing was decided about it", is exactly the state #3829 says must leave a trace. Every prior row is now carried, and the carried marker is what keeps it honest: the row does not claim the finding is live, it records that it was seen and never triaged. Two costs, stated rather than discovered: a renumbered finding shows twice until the old row is triaged, and a carried untriaged row persists until decided. Both are bounded by the phase's own findings, both are legible from the marker, and both beat a silent delete. Five tests updated -- they encoded the dropped-untriaged behaviour as the contract -- plus one new test for the renumbering case M1 names. Reversion control: restoring the guard turns six red. Two self-inflicted defects caught while writing this, both by probes round 1 built: - Four unescaped backticks in a comment inside the double-quoted node -e argument, which bash ran as command substitution. The extractor-parity probe fired ("--auto: command not found"). Third time that trap has been sprung in this PR, third time the probe caught it. - The reworded ledger footer contained the literal carried-marker phrase, and the marker-accumulation assertion counts it across the whole file, so a doc line read as a second marker. The assertion was right. * test(#3829): cover the count-length threshold at limit-1, limit and limit+1 (M2) The guard is `?????????*` -- nine or more characters -- so the limit is 8 digits accepted, 9 rejected. The only cases were 'x', single digits and a 20-digit value, none of which pins the boundary. RULESET.TESTS boundary-coverage is a hard rule here and it was unmet. All three points asserted, with the sum kept consistent at each so the LENGTH rule is what decides the verdict rather than the sum check incidentally agreeing. Reversion control is the off-by-one M2 names: dropping one `?` moves the limit to 7 digits, which no test could previously notice, and now turns this one red. * feat(#3829): wire the disposition ledger into the fix path (B1c/B1d) REQ-REVIEW-09 was unreachable in every shipped path. execute-phase.md's code_review_gate invokes review with neither --fix nor --auto, so <NN>-REVIEW-FIX.md cannot exist when the gate runs and every row it writes is `open` by construction. The operator then runs /gsd:code-review N --fix by hand -- the very suggestion the step prints -- which writes REVIEW-FIX.md and never touched the ledger. A phase with 23 findings, all fixed, ended at `open: 23 / total: 23`: the artifact that exists to distinguish a triaged finding from a forgotten one asserted that 23 triaged findings were forgotten. Worse than recording nothing, because it looks authoritative and is inverted. Taking remedy (i), not (ii). Narrowing the docs to say the ledger reflects the previous phase execution is a legitimate choice, but it ships a feature whose central artifact is inert and then documents the inertness. ONE ADAPTATION, because the prescribed site does not exist. The review says to wire code-review.md's --fix/--auto path. code-review.md is not the writer (gsd-code-fixer writes the report, code-review-fix.md commits it), and more decisively it has no point that is AFTER the report exists: it delegates through code-review/steps/dispatch-fix.md, which calls Workflow(code-review-fix.md) and then exits the workflow. There is nothing downstream of that call to wire to. The site is code-review-fix.md, immediately after commit_fix_report. That is where the report is on disk and committed, it is the canonical implementation for all fix logic by dispatch-fix.md's own statement, and it additionally covers a direct invocation of that workflow -- which a wiring in code-review.md would have missed. The same step, not a second copy: it consumes PHASE_DIR and PHASE_NUMBER, both already parsed from the init JSON, and it is idempotent, so a phase that reaches the gate and then a fix run ends with one ledger reflecting both rather than two competing ones. Driven end to end: the gate writes `open: 2 of 2`, the fix path reconciles to fixed/skipped and `open: 0`. Two tests -- one pins the wiring and its ordering relative to commit_fix_report and present_results, one drives the two call sites in sequence. Reversion control: removing the step turns the first red; the second covers the reconciliation the wiring makes reachable rather than the wiring itself. * fix(#3829): a reflowed fix-report title is the same title (m2) The stale-fix-report guard compared titles with trim() equality. The strict instinct is right -- ids are reused across re-reviews, so a stale REVIEW-FIX.md must not mark a brand-new CR-01 as already fixed -- but gsd-code-fixer.md writes '### {finding_id}: {title}' under no contract that the title is copied byte-for-byte from REVIEW.md. A fixer that reflows a long title produced a spurious mismatch note, left a genuinely-fixed row 'open', and told the reader the report named a different finding. That false-positive mode was acknowledged nowhere. Whitespace is normalized, and only whitespace: a wrapped title is the same title, and it is the one divergence that carries no information. Case changes and truncation stay strict on purpose -- they are the shapes a genuinely DIFFERENT finding takes, and widening to them would trade a visible false positive for the silent false negative the strict match exists to prevent. The residual is now stated in the step rather than left to be rediscovered. The note's wording changed with it. It asserted the report "names a different finding"; both causes reach that branch and the step cannot tell them apart, so it now reports the observation -- "titles its finding differently from the review ... a stale report, or a re-titled one" -- rather than a conclusion it has not earned. Three tests: the reflow case reconciles cleanly, the re-cased case still reports, and the stale case still reports with the new wording. Reversion control: restoring the strict comparison turns the reflow test red. Seventh src.includes() converted -- it pinned the comparison EXPRESSION, so it went red when the comparison gained normalization while the property it names was unchanged. * docs(#3829): describe the flow that ships, not the one implied (m3) Both reference pages said "/gsd-code-review <N> --fix records fixed and skipped, which the gate reconciles from REVIEW-FIX.md" -- true in the abstract, materially misleading in practice, because no shipped path performed that reconciliation. With B1c/B1d wired it is now real, and the pages say WHERE it happens rather than leaving a reader to assume the in-phase gate does it: the gate runs before any fix report exists and writes all-open, and --fix is what records what happened. The round's other behaviour changes land here too, since a reference page that lags the artifact is worse than none: - the disposition column is a closed vocabulary, and a value outside it falls back to open rather than being treated as a decision - severity comes from the section heading when the review uses one, and from the ID prefix otherwise - an unparsed shortfall is stated rather than dropped - titles are compared ignoring whitespace, so a reflowed title still reconciles, and a mismatch is reported as an observation rather than as a claim that the report is stale - EVERY row is carried now, triaged or not, with the cost of the renumbered-finding double-entry stated rather than left to be found docs/FEATURES.md regenerated from the fragment; lint:generated-sync and lint:docs both exit 0. * chore(#3829): migrate the emitted-drift ack from a fragment to commit trailers ADR-3942 landed on next in #3954: the acknowledgment is a git commit trailer now, and tests/emitted-drift-acks/ no longer exists. Worth noting for anyone reading the rebase: this did NOT surface as the modify/delete conflict the migration guidance predicts. This branch ADDED its fragment rather than modifying an existing one, and the base deleted only the files that were already there, so the replay was clean and the fragment survived silently into a directory that no longer exists. Quieter than a conflict, and worse -- the gate is what catches it, not git. Two Growth keys rather than the fragment's one: round 2 wired the ledger into code-review-fix.md, so that file grew too. Both key on the bare filename, per the Growth namespace. Emitted-Drift-Ack-Growth: code-review-fix.md — #3829 review round 2, blocker 1c/1d: REQ-REVIEW-09 was unreachable in every shipped path because the in-phase gate runs before any REVIEW-FIX.md exists, so every ledger row it wrote was open and nothing ever reconciled them. This file gains one step, record_disposition, that reads and executes the same lazily-read step after commit_fix_report. It is the only point in the fix flow that is after the report is on disk: code-review.md delegates here through steps/dispatch-fix.md and exits, so it has no such point at all. Growth is one step of prose, no logic is duplicated, and the step is idempotent so the two call sites converge on one ledger. * chore(#3829): the changeset describes the round's behaviour, not round 1's It renders into CHANGELOG, so it carries the same misleading implication minor 3 was about: "the gate ... reconciling fixed/skipped from REVIEW-FIX.md" reads as though the in-phase gate does it, when the gate runs before any fix report exists. Says where it happens, and picks up the round's other user-visible changes -- carried untriaged rows, section-based severity, the disposition vocabulary, and the unparsed shortfall. * fix(#3829): a dotted phase number no longer aborts the step Found by this round's own adversarial review, in its MISSED section: no finding asked about it, and it is the most serious thing in the round after the two blockers. Both callers explicitly accept a dotted phase -- code-review.md:60 and code-review-fix.md:36 both validate ^[0-9]+(\.[0-9]+)?$ and name "03.1" in their own error text -- and both fences reconstructed the path with `printf "%02d" "${PHASE_NUMBER}"`, which cannot format one. Driven with PHASE_NUMBER=3.1: bash prints `invalid number` and exits 1, and under `set -euo pipefail` that aborts the step on its FIRST line. An advisory gate that promises never to block took the phase's entire review report down with it, and the newly wired fix-path call site inherited the same defect. Pad the integer part and carry the sub-number verbatim, so 3.1 -> 03.1 and 3 -> 03, with both arms falling back to the raw value rather than aborting. Driven: 3.1 now reads 03.1-REVIEW.md and writes 03.1-REVIEW-DISPOSITION.md; the integer path is unchanged. Two other findings from the same review, both about claims rather than code: MINOR 2's TEST WAS MIS-NAMED, and the reviewer was right to refute the claim. It called itself the "reflowed" case while substituting triple spaces, which is not a reflow. Driven: a genuinely WRAPPED heading is still not reconciled, because a `###` heading is one line by definition and the continuation is a separate paragraph. Not widened -- absorbing whatever follows a heading into the title would swallow arbitrary prose and make the stale-report check meaningless, and the kept failure mode is the safe one (a visible mismatch note, never a wrong "fixed"). The test is renamed to what it covers and the bound is now pinned by its own test. THE SHELL-SHARING GUARD DID NOT GUARD. Negative-controlling it -- rather than reading it -- showed that deleting block 2's real REVIEW_FILE derivation left it GREEN, on the exact defect it was written for. Block 2 prefixes its `node -e` with `REVIEW_FILE="${REVIEW_FILE}" ...` to put the values in the child's environment, and the detector counted that self-referential pass-through as a derivation. Pass-throughs are now excluded, and the control fires. Pre-existing, not introduced here: the original column-0 anchor matched that same line. Also worth recording: my first attempt at that control silently patched nothing and reported clean. Same lesson this PR already learned once. * fix(#3829): validate the phase number before formatting it, and make the shell guard executable Three findings from the round review's continuation pass, all confirmed by driving them. 1. MY OWN DOTTED-PHASE FIX WAS WRONG on the fallback path. `printf "%02d" abc` writes `00` to stdout BEFORE it fails, so `$(printf ... || printf %s ...)` CONCATENATES the two: `abc` became `00abc`, empty became `00`, and a legitimate `08.1` became `0008.1` because bash reads the leading zero as octal. An unset PHASE_NUMBER also aborted under `set -u` -- in the step that promises never to abort. Validate, then format: never format and fall back on failure. Driven across every edge the review named -- 3.1 -> 03.1, 3 -> 03, 08.1 -> 08.1, 09 -> 09, 1.2.3 -> 01.2.3, and abc / empty / -1 / unset carried verbatim with exit 0. 2. THE SHELL-SHARING GUARD STILL DID NOT GUARD. Excluding pass-throughs was not enough: a structural predicate recognises assignment TOKENS, never assignments that derive a usable value, so `REVIEW_FILE=`, `REVIEW_FILE=$REVIEW_FILE` and a commented-out assignment all evaded it. No regex closes that class. The authority moves to execution -- the third time this PR has learned that lesson. The real second fence now runs in a fresh shell with nothing but the step's two declared inputs and must write the ledger at the correct derived path. All four mutations are caught: empty assignment, self-reference, commented-out, and deletion. The textual check stays as a cheap fast-fail and is labelled as one. 3. THE TITLE-BOUND CORRECTION HAD NOT REACHED THE DOCS. The step comment and both docs pages still said a reflowed title reconciles, contradicting the bound pinned one commit earlier. Superseded prose left standing reads as current to anyone arriving cold, so all three surfaces are rewritten rather than annotated, and FEATURES.md regenerated. Also hoisted `HAS_BASH` to the file's other top-level constants. `const` is in the temporal dead zone until its declaration runs, and a `{ skip: !HAS_BASH }` option object is evaluated eagerly, so a bash-gated test added above the old mid-file declaration threw a ReferenceError that aborted its whole describe and CANCELLED its siblings -- while the summary line still read `fail 0`. It caught three separate additions in this round before I stopped moving tests and moved the constant. * fix(#3829): refuse an out-of-shape phase number instead of carrying it into a path Self-found while writing the prompt for the next review pass, which is the honest provenance: I asked the reviewer whether a path traversal was reachable through PHASE_NUMBER, then checked before dispatching. It was, and I had introduced it. The previous commit's fallback carried an unusable phase number VERBATIM, and PHASE_NUMBER is interpolated into a file path: PHASE_NUMBER='../../etc/passwd' -> REVIEW_FILE=/tmp/phase/../../etc/passwd-REVIEW.md The `printf "%02d"` it replaced had at least mangled that to `00`. A fix that makes a path more reachable than the bug it replaced is a regression, whatever it does for the case it was written for. Both callers already validate ^[0-9]+(\.[0-9]+)?$ (code-review.md:60, code-review-fix.md:36), so this is defense in depth rather than a live exploit -- but the step has two call sites now and should not take either caller's word for its own inputs. It validates the WHOLE value and, on failure, builds no path at all: PADDED is empty and each fence refuses by name rather than coercing. Block 1 declines to report counts read from a path made out of the bad value; block 2 declines to write, which also keeps it clear of the bare-name ledger defect round 1 closed. Driven across the shape boundary: 3.1 / 3 / 08.1 / 09 accepted; abc, empty, unset, 1.2.3, -1, 3., .1, +1, "3 1" and ../../etc/passwd all refused with exit 0 and a named diagnostic. Reversion control: restoring carry-verbatim turns the traversal test red. * fix(#3829): bound the phase number's length, and make the shell guard prove derivation Third adversarial pass. Two of its three refutations were already closed by the previous commit (the ../escape and 1/../../escape traversals, and the unset-input abort); these two were not. 1. A 54-DIGIT PHASE NUMBER WRAPPED SILENTLY. The validator accepted any all-digit value, so `$((10#$_int))` overflowed 64 bits and PADDED became `-7908320945662590977`. Length-bounded now at 8 digits, exactly as the counts already are and for the identical reason -- and the counts guard sitting twenty lines away is why this one is embarrassing rather than subtle. Driven at the boundary: 8 digits accepted, 9 rejected. The bare `${PHASE_NUMBER}` in the suggestion line is hardened to `${PHASE_NUMBER:-}` while here. The empty-PADDED guard makes it unreachable today, but it is one refactor away from an unbound-variable abort under `set -u`, in the step that promises not to abort. 2. THE EXECUTED SHELL GUARD PROVED THE FENCE WORKS, NOT THAT IT DERIVES. A single-phase probe is satisfied by a hardcode, and the review demonstrated exactly that: replacing the derivation with `case ... in 1) PADDED=01 ;; 7) PADDED=07 ;; *) PADDED=07 ;; esac` breaks every real phase and passed the entire suite. It now runs two distinct phases, 7 and 3.1 -- a hardcode cannot satisfy both, and the dotted one additionally pins the integer-part split. The claim "given only the declared inputs" was also overstated: the test spreads `...process.env` (it needs PATH and HOME). The DERIVED names are now explicitly deleted from that environment, so the claim is true rather than merely intended. Also rewrote a comment that had become false: it pinned a describe to the end of the file because of the HAS_BASH temporal-dead-zone constraint, which the hoist removed. Superseded prose left standing reads as current to anyone arriving cold. The changeset's "the gate stays advisory and never blocks" is now verified rather than asserted: both fences exit 0 under an unset PHASE_NUMBER and a traversal-shaped one. * fix(#3829): validate both inputs, refuse before building a path, and never write through a symlink Fourth adversarial pass. Four findings, all confirmed by driving them. 1. PHASE_DIR WAS NOT VALIDATED AT ALL. Unset, both fences died with `PHASE_DIR: unbound variable` under `set -u` -- the same class as PHASE_NUMBER, which I had just spent two commits fixing while its sibling input sat one line away. The step declares two inputs; it now validates two. 2. THE LENGTH BOUND WAS ON THE WRONG THING. The nine-character glob applied to the WHOLE value rather than the integer part, so it falsely rejected `12345678.1` (a legal 8-digit phase) while accepting `1.123456`. Each component is bounded on its own now; the sub-number is bounded too, since it is likewise interpolated into a filename. 3. REJECTED VALUES STILL HAD PATHS BUILT FROM THEM. The refusal guard sat AFTER the assignments, so an unusable input still assembled `${PHASE_DIR}/-REVIEW.md` and stat'ed it before refusing. The guard is now the first thing after validation, and both fences construct paths from validated locals rather than from the raw environment. 4. THE LEDGER WRITE FOLLOWED SYMLINKS. From the review's MISSED section, and the sharpest thing in it: `fs.writeFileSync` follows a symlink, so a pre-existing symlink at the ledger path replaced the contents of whatever it pointed at -- outside the phase directory, with the link left intact so nothing looked wrong. Driven, and the target's contents were gone. This PR introduces the artifact, so it owns the check: an existing ledger that is not a regular file is not a ledger, and the advisory gate says so and steps over. The executed shell guard now draws its phases AT RUN TIME. Fixed fixtures cannot establish derivation -- the review defeated the one-phase version with a hardcode, then defeated the two-phase version by adding one more arm to the same case. Any finite sample loses that race. A phase picked per run cannot be enumerated in advance; the drawn values print in every assertion message so a failure stays reproducible. Control: the review's three-value hardcode now fails on three consecutive runs. Eighth src.includes() converted -- it pinned the literal `${PHASE_DIR}` interpolation and went red when construction moved to a validated local, while "writes a REVIEW-DISPOSITION sibling" was untouched. It now asserts that property, and that REVIEW.md is not written. The changeset's "stays advisory and never blocks" is verified rather than asserted: 8 of 8 hostile-input cases across both fences exit 0 -- both inputs unset, PHASE_DIR unset, a traversal-shaped phase, and a missing phase directory. * fix(#3829): check the ledger path before reading it, and pin the write-safety behaviour Fifth adversarial pass, and the last one this round. Three fixes, three disclosed residuals. FIXED 1. A FIFO AT THE LEDGER PATH BLOCKED FOREVER. readFileSync on a FIFO never returns, so the step documented as "advisory, never blocks" blocked indefinitely -- the literal counterexample to its own headline claim. The non-regular-file check ran after that read. 2. THE UNCHANGED-RUN FAST PATH BYPASSED THE CHECK. A symlink whose target already matched the rendered ledger read through the link, reported `unchanged`, and never reached the refusal. Both fixed by the same move: the check is now the FIRST thing the script does, before any read or write of that path. Ordering was the defect, not the predicate. 3. THE COMMIT TEST FOLLOWED THE LINK the script had just refused. `[ -f ]` resolves symlinks, so the guard and its consumer disagreed about the same path and the helper could still be handed one. `[ ! -L ]` added. And the behaviour shipped with NO regression control -- I hand-drove it last commit and did not pin it, which the review caught by grepping for the words. Five tests now: symlink, symlink-with-matching-target, FIFO, directory, and an ordinary ledger as the negative control so the refusal is not a blanket one. mkfifo goes through the process seam like every other spawn here. DISCLOSED, NOT FIXED -- these are stated in the step rather than carried silently: - TOCTOU between the lstat and the write. Node exposes no portable O_NOFOLLOW write, and an attacker who can write into the phase directory mid-run already has what the check would protect. It narrows a real accident; it is not a security boundary and the docs claim none. - A hard link passes isFile() by construction. - The REVIEW.md and REVIEW-FIX.md reads still resolve symlinks. They are reads of files the operator owns, in their own phase directory. Also narrowed a comment that overclaimed. The randomized guard's domain is FINITE -- 88 integer and 792 dotted values -- so a mutation enumerating all 880 passes forever, and Math.random() is unseeded, so "reproducible" means only that the drawn values are printed on failure. Raising the bar is what it buys; proving derivation is not, and nothing short of reading the fence is. The previous comment claimed otherwise and was refuted. * test(#3829): make the write-safety controls portable to the Windows lane CI caught what neither the local suite nor five adversarial review passes could: every one of those ran on Linux. The FIFO test gated on `mkfifo`'s exit code. On the Windows lane mkfifo EXISTS and exits 0 while producing something that is not a FIFO, so the guard passed, the test ran against an ordinary path, the ledger wrote normally, and the assertion failed for a reason unrelated to the behaviour under test. It now gates on `lstatSync().isFIFO()` -- what was actually created, not what the command claimed. Control: with the shipped guard disabled the test still goes red on Linux, where the FIFO is real. The two symlink tests are skipped on win32, following this repo's existing convention for symlink-planting tests (tests/settings-jsonc.test.cjs:389 skips the same class; tests/unreachable-guard-drift.test.cjs:726 records the reason -- symlink creation requires elevated privileges on Windows CI). The privilege happened to be available on the lane this round, which is exactly why the convention is not "try it and see". * fix(#3829): a bare `|` in a deferral reason is prose, not a parse failure Review round 3, the one blocker. The Source cell is the one field this ledger asks a human to hand-edit, and "waiting on team A | team B to align" is an ordinary thing to type there. The prior-row capture admitted a pipe only when escaped, so a bare one failed the WHOLE line: prior.get() was undefined, the row fell through to `open` with an empty Source, and the console line read "1 of 1 finding(s) open" — a Critical a human explicitly deferred, with a documented reason, rendered indistinguishable from one never triaged, and the reason gone. The exact ambiguity #3829 exists to remove, reachable by one missing backslash. The Source cell is the LAST column, so it is now captured through to the end of the line, less an optional trailing pipe; a bare `|` inside it is prose. The render escapes a bare pipe on the next write so the table stays a table, and the escaped form re-parses to itself, so the second run reports `unchanged` — the fixed point holds. The ledger's own instruction line says so instead of asking the human to escape. Why the property never caught it: SOURCE_CELL only ever appended a PRE-ESCAPED pipe, so the arbitrary built to stress this cell could not reach the one input that broke it. It now also emits a bare pipe, and the round-trip expectation is the escaped form of what the human wrote. A fixed regression case drives the reviewer's exact input through two runs and asserts the decision, the reason, the headline count and convergence. Negative-controlled: both new tests fail against the previous capture. The src.includes() pin on the old capture text is retired for the behavioural case — it was pinning the defect. * fix(#3829): escape every bare pipe in one write, whatever precedes it Round 3, found by the adversarial pass over the round's own fix rather than by the review. The first escape used /(^|[^\\])\|/g, which CONSUMES the character before the pipe: adjacent bare pipes were escaped one per run (A||B -> A\||B -> A\|\|B, a third run to converge, breaking the advertised second-run fixed point), and an escaped backslash before a pipe (A\\|B) hid the pipe behind the wrong parity and left it bare in the rendered table. The property generator emits at most one bare pipe, which is the one case the old form got right, so no property reached either. Scan as pairs instead: an escaped pair (backslash + anything) is kept verbatim and only a pipe outside one is escaped. One write, then a fixed point. Regression case drives `A||B and C\\|D` through two runs; it fails against the previous escape. * fix(#3829): the script leaves by return, so an explicit exit cannot drop its verdict line Round 3, from the adversarial pass over the round's own fix. The embedded node script printed its verdict and then called process.exit(0) -- on the 'unchanged' branch only; the 'recorded' branch fell off the end. Node's "A note on process I/O" documents process.stdout writes to pipes and sockets as asynchronous on POSIX, and process.exit() as forcing exit before pending asynchronous stdout writes complete -- so on a POSIX lane the caller can see exit 0 with no verdict line. This is a hardening against that documented hazard, not a reproduced defect: the reviewer's empty-second-run stdout, which first pointed here, turned out to be its own sandbox -- a bare console.log child printed nothing there either -- and that attribution is withdrawn. The script now runs inside main() and leaves by return on all four early-exit paths, so the event loop drains stdout before the process ends. Same exit status either way, and the || echo fallback is unaffected. A structural test pins the absence of the call (comment-stripped; dotted, bracketed and whitespace-split spellings). The empty-review docs-parity pin that asserted the literal process.exit(0) line is retired -- the round-2 describe drives that property behaviourally. Also widens the property generator: SOURCE_CELL now reaches adjacent pipes and a backslash of either parity before a pipe, the two shapes the first render escape got wrong while passing every input the generator could then produce -- checked against an independent parity-walk oracle rather than a copy of the render's own scan. * fix(#3829): record what an --auto iteration fixed, instead of reporting it open Round 5's major. `record_disposition` runs once, after the whole capped-at-3 `--auto` loop converges — but this workflow keeps ONE final version of REVIEW.md and REVIEW-FIX.md rather than per-iteration copies, and deletes the .iterN.md backups on convergence. A finding fixed in iteration 1 was therefore absent from the final review (it was fixed, so the re-review stopped reporting it) AND from the final fix report (overwritten by the last iteration), so the row fell back to the gate's `open` and rendered `open ... (not in the current review)` — the same bytes a finding that vanished for an unrelated reason produces. That is the one distinction #3829 exists to make, undone by the artifact built to make it. The precise site was the two-arm `applied` construction: for an id the current review does not report, `sameTitle(undefined, h.title)` is false and `title.has(id)` is false too, so the entry entered NEITHER `applied` NOR `staleFix`. It was dropped in silence. Four changes, one defect: - A third arm. When the review does not report an id at all there is no title to disagree with, so this is not the stale-report case — it is what a finding looks like once it has been acted on. Record it. The id-reuse hazard stays closed by the arm below it: when the review DOES report the id, a title mismatch still goes to `staleFix` and is never applied, so a renumbered finding cannot inherit an earlier iteration's `fixed`. - Rows for decided ids the review no longer reports, carried and marked. A decision the ledger cannot render is a decision lost — the same silent drop the carry-forward loop already refuses for prior rows, one source over. - The .iterN.md fix-report backups are read alongside the final report, newest first, so the most recent statement about an id wins — the precedence a duplicate id already gets within one report. - The shell guard proceeds on a fix report, not only on an existing ledger. A direct `/gsd-code-review N --auto` writes no gate ledger, and a converged loop leaves `status: clean`, so a fully successful multi-iteration run recorded nothing at all. And the backups now go in `cleanup_iteration_backups`, after the ledger has read them. #3190's rule is untouched — spent scratch on convergence, retained on degradation — only the timing moved; deleting them inside the loop erased every early fix before anything read it. `CONVERGED` does not survive the loop's shell and is re-derived from the final review's status, which is exactly how the loop sets it; anything but a proven-clean review retains. Seven new regression tests plus an ordering test, all eight reversion-controlled against pre-fix code — every one fires. One is the negative control that matters: a reused id whose title differs must stay `open`, never inherit `fixed`. Residual, stated: an id appearing only in an iteration fix report takes its severity from the id prefix rather than a section heading, because `sectionSev` is built from the current review. That is the documented fallback for carried rows, not a new gap. * test(#3829): pin the two PADDED derivations against a silent desync Round 5's minor 1. Each fenced block runs in a fresh shell and must derive what it reads, so the PADDED derivation — the traversal fence between an attacker-influenceable phase number and a file path, plus the per-component length bound — is duplicated verbatim. Both copies were independently tested and nothing asserted they stay in step, which is the shared-parallel-surface shape CLAUDE.md requires a parity test for, on security-relevant validation logic rather than incidental repetition. Compared line by line rather than through a normalizing rewrite: a normalizer has to be told what may differ, and whatever it is told to tolerate stops being asserted. Exactly one line may differ — each block refuses by its own name — and the test names both forms. It also asserts the slice is substantial, since a parity test over an empty slice passes vacuously. Control: dropping one `?` from block 2's length bound, which moves that copy's limit to 7 digits while block 1 keeps 8, turns it red. That is the exact silent divergence the finding describes. One correction to the finding's own statement, since it is worth recording: the cited lines are :324 and ~:480, which are node-script lines; the derivations are at :48-83 and :211-246. And they are 35-of-36 identical rather than byte-identical — the refusal message differs, deliberately. * docs(#3829): state the PHASE_DIR trust boundary instead of carrying it Round 5's minor 2 asked that the assumption behind PHASE_DIR's validation be confirmed rather than silently carried forward at the two new call sites. It is confirmed, and the comment that stood here was wrong about it: "PHASE_DIR is the step's other declared input and gets the same treatment" describes something the code does not do. Both inputs have the SAME provenance — each caller binds them from `gsd_run query init.phase-op` (code-review-fix.md:7,17; execute-phase.md the same) — so neither is raw user input and neither is more trusted. The asymmetry is not about trust. It is that only one of them has a shape: PHASE_NUMBER carries a documented contract, `^[0-9]+(\.[0-9]+)?$`, asserted by both callers, so a value outside it is provably wrong and is refused. PHASE_DIR's contract is "a filesystem path", which admits `..`, absolute and relative forms and symlinked parents alike; no predicate separates a legitimate planning directory from an illegitimate one, so a shape check would reject working setups while proving nothing. So the emptiness check is adopted as what it actually is — the guard against `PHASE_DIR: unbound variable` aborting a step that promises never to block — and the shape check is declined, with the reason written where the next reader meets it rather than left to be re-derived. The residual is restated in place rather than left in a PR comment: PHASE_DIR may itself be a symlink and the ledger is then written through it, outside the phase directory, deterministically. Left alone deliberately — the write goes where the caller pointed. Not a security boundary, and nothing here claims one. * docs(#3829): record why HAS_BASH is a platform assumption, not a probe Round 5's minor 3 is DECLINED, and the reason is the repo's own contract rather than a judgement call — written at the constant so the next reader does not "fix" it and re-enable what the rule exists to prevent. The gap is real and confirmed: 22 tests carry `{ skip: !HAS_BASH }`, so block 1's bash severity-reporting path has no Windows-lane coverage. But `local/no-unguarded-nonportable-exec` (eslint-rules/no-unguarded-nonportable-exec.cjs, DEFECT.WINDOWS-TEST-PORTABILITY) REQUIRES this guard around `sh -c` / `bash -c` in tests, and its own remedy text names `if (process.platform !== 'win32')` as the sanctioned form, because these constructs fail under Windows Git Bash. So the constant is the repo's answer to this question, not an oversight in this PR. Swapping it for a runtime `bash` probe would light 22 tests up on a lane the rule has already determined they cannot pass — trading a legible, rule-encoded skip for a red matrix. Reversing that is the rule's decision; a change here belongs with a change there. * docs(#3829): describe how --auto's iterations reach the disposition ledger The reconciliation section described the `--fix` path accurately and said nothing about `--auto`, which is where round 5's major lived. It now states that the loop overwrites its fix report each pass, that the re-review drops a finding once it is fixed, that the gate therefore reads the per-iteration backups newest-first, and that the backups are removed after the ledger has read them rather than before. It also states the converged-with-no-ledger case: a fix report on disk is reason enough to record. FEATURES.md regenerated (176 features / 21 groups). Changeset extended to name the shipped behaviour rather than only the `--fix` half. * fix(#3829): clear lint-workflow-shellcheck, a gate the base range added Not from the review. The rebase onto `next` brought in `lint-workflow-shellcheck` (#4109), whose baseline was generated before this PR's new step file existed — so that file's findings are new by construction and `lint:ci` exited 1 on the rebased head before this round touched anything. The last green CI run predates the gate. Caught locally rather than by a red push. Three fixes and one baseline entry, split by whether the finding is real: - STRUCTURAL (not ShellCheck, not baselineable): the guard's `for _f in "…${PADDED}-REVIEW-FIX.iter"*.md` is the bare `for x in $VAR` shape that word-splits differently under bash and zsh. Wrapped in `$(printf '%s' "$PADDED")`, the linter's own prescribed remedy. - SC2097/SC2098, and this one was a genuine latent bug rather than a lint nit: `FIX_REPORT_FILE="${_pd}/${PADDED}-REVIEW-FIX.md"` sat in the same env-prefix list that sets `PADDED`, so its `${PADDED}` expanded the OUTER variable, not the one two entries earlier. Both happen to hold the same value here, which is exactly why it would have kept being wrong quietly. Built before the command now. - SC2317 ×3 is baselined, not fixed. It fires on `return 0 2>/dev/null || exit 0` — the deliberate idiom that lets a fence refuse whether it is sourced or executed — and the verdict is a false positive: the `exit 0` is reached precisely in the executed case. Rewriting a dual-mode refusal to satisfy a wrong unreachability claim trades a real behaviour for a clean report. Baseline 207 -> 210. `lint:ci` exits 0. 173 tests pass across the two touched files. * fix(#3829): a reused finding id no longer inherits the old finding's decision Found by this round's own adversarial review, which drove it rather than reasoned about it — and it refuted the arm I had named as my strongest suspicion, so it is recorded as a correction, not a discovery. Finding ids are reused across re-reviews: the --auto loop renumbers. `row()` inherited a prior decision on an id MATCH ALONE, with nothing checking it was the same finding. Driven: a prior `CR-01 fixed` row against a review reporting a brand-new CR-01 rendered the NEW finding `fixed`. A false decision in the artifact whose entire purpose is telling triaged from forgotten — the same failure mode round 4's blocker was, reached by the other door. I had argued this was closed by the stale-report arm. It is not: that arm guards the FIX-REPORT path only. The PRIOR-LEDGER path had no title check at all. - The ledger now records each finding's title, in the FRONTMATTER rather than a fifth table column: the Source cell is the field a human hand-edits and the one that must escape pipes, and a second free-text column doubles that surface for no reader benefit. - A prior decision is inherited only when the recorded title still matches. An ABSENT prior title inherits, deliberately — a ledger written before titles were recorded carries none, and refusing there would reset every decision in it, which is the loss this guard exists to prevent, caused by the guard. - A decision whose id has been reused is PRESERVED under a `superseded:` key rather than dropped. The review's driven refutation was precisely that the mismatch was surfaced while the decision was lost. It cannot keep a row — the id is taken, and two rows under one id is an ambiguity, not a record — so it is carried in the frontmatter, re-emitted every run, deduped by id+title, and named on the console. - And an iteration-derived decision now cites the report it actually came from. The Source cell hard-coded the unsuffixed `<NN>-REVIEW-FIX.md`, so a decision read out of an iteration backup cited a file that may not exist. A citation the reader cannot follow is worse than none. Also the review's finding. Five new tests. Four fail against the pre-fix step; the fifth — that a ledger with no recorded title still inherits — is a BACK-COMPAT guard and passes both ways by construction. It is not a reversion control and is not counted as one. * fix(#3829): follow the cleanup move through, and stop miscalling a converged run Three loose ends the earlier cleanup relocation left, two of them found by the round's own review and one by the suite. **#3190's own test still pinned the old placement.** T6 asserted the `.iterN.md` removal lives inside `auto_iteration_loop` — exactly what moving it broke. Its SEMANTICS are unchanged and still asserted: removed on convergence, retained on degradation, creation intact. What it now pins additionally is the ordering that forced the move — the ledger reads the backups BEFORE they are removed — and that the loop no longer removes what it just wrote. Rewritten rather than deleted: the assertion was superseded, the guarantee was not. **`CONVERGED` had become a decoy.** With the removal gone from the loop, the flag was set in two places and read in none. Deleted, and the prose that still said "the loop sets it" rewritten to what is true: the loop breaks on exactly one condition, a clean re-review, which leaves REVIEW.md at `status: clean` — and that is what `cleanup_iteration_backups` re-derives from. **A converged final iteration reported the opposite of what happened.** The post-loop message keyed on the iteration COUNTER alone, so a run that converged ON iteration 3 exited with `ITERATION == MAX_ITERATIONS` and printed "Reached maximum iterations. Remaining issues documented in REVIEW-FIX.md" over a run in which every finding was fixed. Convergence is re-derived from the review the loop left behind — the same signal the cleanup step reads, so the two cannot disagree. * docs(#3829): retract two claims this round made and could not support Both were caught by the round's own adversarial review, both were driven, and both would have reached the maintainer. Recording the retraction where the claim was made, rather than only in a PR comment. **The env-prefix "latent bug" does not exist.** An earlier commit in this round claimed that `FIX_REPORT_FILE="${_pd}/${PADDED}-REVIEW-FIX.md"`, sitting in the same `node -e` env-prefix list that sets `PADDED`, expanded the OUTER variable rather than the one two entries earlier — reading ShellCheck's SC2097/SC2098 as a defect report. Driven in bash and in dash: assignments in one prefix list take effect left to right, and the later entry DOES see the earlier one. The warning is a false positive here. The split is kept, but for readability only; the comment no longer describes it as a fix. **The HAS_BASH decline rested on a rule that does not govern these call sites.** It cited `local/no-unguarded-nonportable-exec` as REQUIRING the `process.platform !== 'win32'` guard. Checked, and wrong on both halves: the rule fires only on a file that also chmods an exec bit with an octal literal, and this file has none — so it never runs here — while `eslint-rules/lib/platform-guard.cjs` accepts four guard shapes plus `os.platform()`, not one. A constraint that exists is not a constraint that applies, and I did not check which. The decline stands on narrower and honest grounds: whether these fences PASS on the Windows lane is UNVERIFIED. What evidence there is points at divergence rather than absence — the rule's subject line is that `bash -c` constructs "fail on Windows Git Bash", and this PR already measured `mkfifo` existing on that runner, exiting 0, and creating no FIFO. So a probe would not be a clean win; it would light 22 tests on a lane whose shell semantics are known to differ and unknown in detail. That is a measurement to make deliberately, not a change to make in passing. The gap is real and is now stated as a gap. * fix(#3829): close four defects the review drove out of the first title fix The round's own adversarial review re-ran against the reworked tree and refuted two more claims. Every item below is its finding, verified before acting. **An iteration-only decision recorded no title, so the reuse guard leaked.** `applied` stored `{d, src}` and the row took its title from the current review — which does not report the finding at all. The row shipped with no title, and the next review reusing that id hit the title-ABSENT back-compat exception and inherited the old `fixed`. The exact defect the title machinery exists to close, surviving through the hole opened for legacy ledgers. `applied` now carries the title it was decided under. **A changed decision was dropped in favour of the obsolete one.** The dedupe was a has()-guard, so re-superseding a finding whose decision had since changed left the older record standing. It now replaces. **Re-spaced titles double-recorded.** The dedupe keyed on the raw title while `sameTitle()` collapses whitespace; the key now agrees with the comparison. **And the frontmatter was not valid YAML.** `title: Parser: loses data` is rejected outright by a real reader, and the `superseded:` line format was not YAML at all. Values are emitted as JSON scalars — YAML 1.2 is a JSON superset — and superseded records are properly nested. Round-tripped through js-yaml in the tests. One more, self-inflicted while fixing the above: the parse registered each carried superseded record TWICE, once at `- id:` under an empty-title key and again at `title:`. Records doubled on every run. They are collected during the walk and registered once, complete. **T6 was vacuous.** The review flipped `= "clean"` to `!=` in the cleanup and the rewritten T6 still passed — it greps for `FINAL_STATUS`, `rm` and "retained" occurring somewhere, never wiring them to a branch. T6b now EXECUTES the fence in both directions against real files. It fails on that exact mutation. **And a converged final iteration printed two success messages** — the loop's break already reported it. This branch now stays silent and exists only to withhold the degradation warning. Three CI gates the base range brought in, all tripped by this round's own text: - `/gsd-code-review` in a comment — runtime workflow artifacts take the colon form. Now `/gsd:code-review`. - The preamble-ordering parity test: my PHASE_DIR comment wrote the literal `gsd_run` before the shim preamble. Reworded. - Prompt-stuffing: the file passed 50K. I trimmed 5.8K of my own commentary first; even removing every added comment leaves the added CODE over the line, and the file entered this round at 44,523 — 89% of the budget. Added to SIZE_ONLY_WORKFLOWS with the same reasoning the two existing entries carry, and the same acknowledgement: splitting is the real fix. * test(#3829): extract the cleanup fence without an ad-hoc markdown regex T6b's helper used `/```bash\n([\s\S]*?)\n```/`, which trips two of the repo's own rules: `local/no-adhoc-markdown-parsing` (use the sectionizer, not a hand-rolled fence regex) and `local/no-crlf-fragile-split` (a bare `\n` against readFileSync content is wrong under Windows autocrlf). Line-scanned now, CRLF-normalized first — the same shape `bashFences()` in tests/code-review-pipeline-regression.test.cjs already uses, which solved this first. `npm run lint` is clean and T6b still fails on the inverted-branch mutation it exists to catch. * fix(#3829): withdraw the superseded-decision store; keep the identity guard Three adversarial passes over this round each found real defects, and passes 2 and 3 were entirely inside the `superseded:` block added in pass 1 — a second identity scheme, keyed on (id, title), living beside the row store keyed on id. Pass 3 refuted it on three separate counts: a legacy title that merely looked like JSON lost its quotes and fabricated a record; a finding that was deferred, superseded, then returned and fixed left an active row and an obsolete superseded record standing together, reporting `unchanged` forever; and my own test for the replacement path never passed the earlier ledger in, so it guarded nothing. The construct had no terminal state. It is withdrawn. **What survives is the safety property.** The ledger records each finding's title, and a recorded decision is carried forward only while the id still names the same finding. That is what stops a renumbered `CR-01` inheriting an earlier `CR-01`'s `fixed` — a false decision in the artifact whose purpose is telling triaged from forgotten, and the same class as round 4's blocker. **What is given up, and it is disclosed rather than hidden.** On a detected reuse the earlier decision loses its row. The drop is reported on the console naming the id and what had been decided, the previous ledger is committed so the row remains in git, and docs/features/code-review-pipeline.md states the limitation. Two defects from pass 3 are fixed rather than deleted, because they are in the guard and not the store: - **Known-empty and NOT-KNOWN were conflated.** `### CR-01:` yields an empty title; that is a title. While it emitted no `title:` key it read back as a pre-format ledger and inherited across a reused id — the same leak, three passes running. Emitted whenever the title is known, empty included; a carried row no source knows stays absent, which is the legacy-compatible read. Underneath it was a falsy fallback: `(act && act.t) || priorTitle.get(id)` discards `''`. Now a typeof check. - **JSON.parse ran on legacy values.** A pre-format ledger whose bare title was written `"quoted"` was parsed and lost its quotes, so the decision stopped matching. The frontmatter now declares `titles: json` and the parse is gated on it; a ledger without the marker keeps its scalars. One defect from pass 3 is NOT mine and is not fixed here: a converged run prints a success message from the loop break AND another from `present_results`. Both predate this round. My earlier claim that "the duplicate is gone" was true only of the pair I introduced; the pre-existing pair stands, and widening this round into `present_results` is not warranted. 188 tests pass. The three new tests fire against the pre-simplification step. `lint:ci` exits 0. The step file is 55,590 chars, down from a 62,220 peak. * docs(#3829): stop the ledger promising a preservation it no longer makes Fourth review pass. No machinery defects this time — both findings are claims in text this step SHIPS, which is the class this whole stack exists to prevent. **The rendered ledger still said "Re-running the gate preserves every row and every disposition."** That was true until the same round gave the step an intentional drop for a reused finding id, and then it was false in the artifact's own user-facing footer. It now states what the step does, including the one exception, where a reader actually meets it. **And the console asserted "the previous ledger is in git."** Committing the ledger is gated on `commit_docs`, and a failed commit is swallowed — so under `commit_docs=false` the overwritten decision may exist nowhere. The note reports the drop and stops there; asserting a recovery path that may not be there is the same overclaim in a smaller font. Two residuals from the same pass are DECLINED and documented rather than fixed, because both would need the second identity scheme just withdrawn: - A pre-titles ledger carries no titles, so its decisions inherit on the id alone. Refusing there resets every decision in every existing ledger, which is the loss the guard exists to prevent. - Two genuinely distinct findings sharing both an id and a title are indistinguishable to an (id, title) key. The pass also refuted the `titles: json` marker on a ledger written by `b86ea6065^`, which emitted JSON titles before the marker existed. Declined: that revision is an intermediate commit on this unpushed branch and has never been released. The PR's published head writes no titles at all, so a real ledger is either pre-titles (unmarked, bare — handled) or written by the shipped version (marked). The unmarked-JSON state cannot reach a user. Test pinned, and it fails against the pre-correction step. * docs(#3829): fix four wrong citations and one false size justification All four came out of a claim-audit of this round's own response comment — an audit of the text, not the code, which is where the remaining errors were. - **The caller citation was wrong.** The in-code note said both inputs bind from `gsd_run query init.phase-op`. `execute-phase.md:85` uses `init.execute-phase`; only `code-review-fix.md:22` uses `init.phase-op`. The substantive point is unchanged — both are orchestrator-derived, neither is raw user input — but the citation was not checked. - **A leftover "the prior row is in git."** Removed from the console note last commit, left standing in the comment two lines above it. - **The docs still carried the promise the ledger had just dropped.** The rendered footer was corrected; the same sentence in `docs/features/code-review-pipeline.md` was not. - **The SIZE_ONLY_WORKFLOWS justification was false.** It claimed the added CODE alone exceeded the threshold. Removing every round-added comment leaves 47,148 chars against a 50,000 limit, so the file CAN fit — the claim was wrong, and an exemption defended on a wrong premise is worse than no exemption. So the entry is re-justified on what is actually true, and earned first: another **10,188 chars** of this round's own commentary are cut (62,220 → 52,032, from a 44,523 baseline that was already 89% of the budget). Fitting under is possible only by stripping essentially all remaining explanation from logic three review passes found defects in. That is the wrong trade in a file whose house style is heavy in-fence documentation, and the entry says so rather than implying the file had no choice. One measurement corrected while checking: the Windows-lane skip count is **37**, not the 22 the review cited nor the 26 I first counted. Twenty-two and 26 count `{ skip: !HAS_BASH }` CALL SITES; a skip on a `describe` cancels its subtests. Forced the constant false and counted what actually skips. 236 tests pass. `lint:ci` exits 0. * fix(#3829): the drop report is conditional, and two published claims were not A fifth adversarial pass, run against the two commits that went out AFTER the fourth pass and were never reviewed, refuted three claims this round published. 1. The drop is NOT reported unconditionally. `row()` reports only a RECORDED decision (`was.d !== 'open'`); a prior row still at `open` is replaced in silence. The behaviour is right — `open` records no decision to lose — but the shipped ledger legend and BOTH feature docs asserted the report happens every time. Text corrected in all three places, which is the same defect class this round already corrected once for the preservation promise. 2. The test guarding that console wording was VACUOUS: it ran with no prior ledger, so no reuse occurred and its `is in git` assertion could not have failed however the console was worded. Driven through a real drop now, with the drop asserted as a precondition. A new test covers the `open` arm and fails on the pre-fix legend. 3. The HAS_BASH gap is now MEASURED rather than assumed, on native Windows with Git Bash 5.2.37 / MINGW64 first on PATH, node v25.2.1: HAS_BASH left alone: 179 tests, 127 pass, 0 fail, 52 skipped HAS_BASH forced true: 179 tests, 140 pass, 24 fail, 15 skipped So 37 of the skips are this guard's, confirming the count the round published — and unskipping is NOT a clean win: 24 fail, clustered on `bash -c` quoting and spawn failures, exactly the divergence the eslint rule's subject line names. The guard stays; it now documents a measured gap. The stale "the count is 22" comment is gone. 4. The size-exemption justification was wrong a second time. The overshoot is ~2.3K normalized chars, not "essentially all remaining explanation": the round's committed peak was 59,246 chars (not 62,220, which was never committed), and it entered at 44,466 chars, not 44,523 — both earlier figures mixed bytes into a character measurement. Rewritten to the numbers the scanner actually produces. Also: the shipped comment said both callers validate the phase shape without naming that they validate PADDED_PHASE, not the raw PHASE_NUMBER this step is handed. * fix(#3829): renumber this PR's two REQs, which #3661 took while the branch sat The rebase onto current `next` surfaced a REQ-number collision, not a text conflict. #3661 landed `REQ-REVIEW-08` (`workflow.code_review_point`) on `docs/features/code-review-pipeline.md` while this branch also claimed 08 and 09 for severity surfacing and the per-finding disposition. Two different requirements under one identifier is the kind of thing that reads as correct in both diffs and is wrong in the merged tree. Base numbering wins, because it shipped: `REQ-REVIEW-08` stays #3661's. This PR's two become **REQ-REVIEW-09** (severity surfacing) and **REQ-REVIEW-10** (per-finding disposition). Swept the whole tree rather than the conflict hunk — two references sat in files git merged cleanly and never flagged: - `gsd-core/workflows/code-review-fix.md:450`, the prose stating why `record_disposition` is the step's only reachable call site. - `tests/code-review-pipeline-regression.test.cjs:1782`, the comment on the test that pins that call site. `docs/FEATURES.md` is regenerated from the fragment rather than hand-edited; `node scripts/gen-features.cjs --check` is green (178 features, 21 groups) and `lint:generated-sync` exits 0. Two things stated rather than quietly carried. The `Emitted-Drift-Ack-Growth` trailer on the round-2 commit still reads `REQ-REVIEW-09` for what is now REQ-REVIEW-10 — it is a historical acknowledgment of that commit's growth, and its purpose is unaffected, so it is left rather than rewritten across 52 replayed commits. And `docs/INVENTORY-MANIFEST.json` appeared stale immediately after the replay, reporting two missing `cli_modules/` entries; that was the lane's pre-rebase build output, not manifest drift. Rebuilding in the replayed lane and re-checking shows it in sync and unmodified. Regenerating before the build would have committed the deletion of two base-added entries. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015mgqVNP3rqTVMgBNnBMnGH * test(#3829): reach the title round-trip with a generator that can break it Round 6's only finding. The round-5 title tracking introduced a fresh parser (the `titles: json` / ` - id:` / ` title:` frontmatter walk) and a fresh bijective contract (`JSON.stringify(oneLine(t))` out, `/^ title: (.*)$/` plus `JSON.parse` back in), and `tests/code-review-disposition.property.test.cjs` was untouched since round 4 with no reference to `title` at all. Every heading the generator built was `'### <id>: finding number <i>'` — never a colon, a quote, a backslash, or the empty string. You were right that this is the round-3 shape again, and I would rather demonstrate that than assert it. Two mutations to the shipped step, each a plausible edit rather than a contrived one: A. render `titles: raw` instead of `titles: json`, so the re-parser never JSON.parses and stores the quoted scalar as the title; B. `yv = (t) => oneLine(t)` — the bare scalar, no JSON at all. mutation A — new generator: FAIL old generator: pass (3/3) mutation B — new generator: FAIL old generator: pass (3/3) Both ship past the pre-round suite. The gap was reachable, not theoretical. What changed: - `TITLE`, a new arbitrary drawn from the class the render's own comments say the escaping is for — `:` (why `yv()` exists), `"` and `\` (what stringify/parse must round-trip), the empty string (the known-empty vs not-known distinction the render draws explicitly) — plus scalars that MIMIC the ledger's own frontmatter grammar (`findings:`, `titles: json`, a nested ` title: ` line, ` - id: CR-99`), unicode, surrounding whitespace, and one title long enough to outrun a scanner assuming short scalars. - `FINDINGS` now carries a title per id, so all four properties run the cycle over the title contract instead of over a constant. `IDS` keeps the old id-only shape it is built from. - A fourth property asserting the round trip in the two places it is observable: the stored scalar must `JSON.parse` back to the trimmed heading title, and a hand-recorded decision must survive the next run. The second half is the one that matters, and its construction is the point. The decision is made by EDITING THE RENDERED LEDGER IN PLACE, never by writing a bare row the way the existing properties do. A bare row carries no frontmatter, so `priorTitle` is empty, `sameFinding()` returns true through its `!priorTitle.has(id)` back-compat arm, and the title contract is never consulted — the property would pass over a completely broken round-trip. Both mutations above go green against the bare-row form. That collapse is why the property is written this way, and the comment says so in place. So the assertion is the consequence, not the JSON: a lossy round-trip does not corrupt a title, it makes `sameFinding()` false and resets a human's `deferred` to `open` with the reason gone — this PR's own founding failure mode, reached through the field the round-5 work added. BOUND, stated rather than quietly omitted: the generator emits no CR or LF. A `###` heading is one line by definition, so a newline is not an input the heading parser can be handed; `oneLine()` guards the value's other producers, not this one. Two things found while writing it, both corrected here rather than left: - `runOnce` now returns stdout. The reuse report is a CONSOLE note, not a ledger key, so my first draft's `assert.doesNotMatch(ledger, /^reused:/m)` was vacuously true forever — a test that cannot fail. - `expectedTitle` is a TRIM, not a `\s+` collapse. Collapsing is `sameTitle`'s COMPARISON rule; `oneLine()` is the STORAGE rule and preserves internal whitespace. The collapse form fails on an internal tab against entirely correct code, which is how a test gets weakened instead of believed the first time it goes red. The file header claimed "two properties" while three were running; it now states four, one line each. 239 tests pass across the four pipeline files, 0 skipped. `lint:ci` exits 0 (`lint-workflow-shellcheck`: 203 baseline findings, 0 new). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015mgqVNP3rqTVMgBNnBMnGH * test(#3829): the prefix census guard now says four sites, because round 5 added one Self-found, from re-deriving the round-1 finding-id census this round rather than carrying the round-1 verdict forward. The census guard's comment says the prefix set is "written out three times — the heading matcher, the ledger re-parser, and (by its keys) the severity map". That was true when it was written. Round 5's title tracking added a fourth copy: the frontmatter `- id: ((?:CR|BL|WR|IN)-\d+)` matcher that rebuilds `priorTitle`. The guard itself did not fall behind, and the reason is worth keeping visible: `idAlternations()` scans the extracted script by PATTERN rather than walking a fixed list of sites, so the new alternation was absorbed with no edit. Verified by running the extractor at this head — three alternations found, one distinct set, severity map keys `CR,BL,WR` with `IN` on the documented `info` default, 0 domain members not reached. Only the prose fell behind. Corrected, with the pattern-scan rationale stated in place so the next reader does not helpfully convert it into the hand-listed enumeration it deliberately is not — which would be exactly the defect this guard exists to catch, in the guard. Census discharge for this round: re-derived at the rebased head over the extracted shipped script, 3 enumeration sites reached, 0 not reached; the domain (the prefixes `gsd-code-reviewer.md` can emit, walked across both its heading template and its prose Label-equivalence paragraph) is unchanged since round 1 at 4 of 4. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015mgqVNP3rqTVMgBNnBMnGH * test(#3829): catch a duplicate REQ id in a fragment, since nothing did Not from your review — this is the test the round owed itself, and I would rather say why than let it look like scope creep. The renumber commit earlier in this round has no reversion control without it. I reverted that fix to check, and the first attempt LOOKED controlled: reverting only the fragment turned `gen-features --check` red. That is the generated-sync gate noticing the projection went stale, not anything noticing the collision. Reverting CONSISTENTLY — fragment plus a regenerated `docs/FEATURES.md` — is silent: gen-features --check rc=0 lint:ci rc=0 pipeline suite rc=0 with two `REQ-REVIEW-08` entries standing in one requirement list. Nothing in the repo reads REQ ids at all, so there was no second place for it to be caught. The failure this guards is a MERGE, not an edit, which is why review does not see it: two PRs open at once each append "the next" REQ number to the same list, and whichever lands second is rebased onto a list that already used it. git merges them as different lines of one file and reports nothing. Neither PR's diff shows a collision — each is correct against the tree it was written on. That is exactly how #3661 and this PR both ended up claiming REQ-REVIEW-08. Scope, stated because it is the part that could be wrong: the check is WITHIN a fragment, never across the corpus. Two different features legitimately both carry `REQ-REVIEW-01..07` — the cross-AI review feature and the code-review pipeline — so corpus-wide uniqueness would be false on the committed tree and would have to be weakened the day it first ran. A requirement list belongs to its feature; that is the scope of the identifier. It lives in `describe('the committed docs/features/ corpus')` because it is an invariant over the committed corpus, which is that block's stated job, and it pins no count — the file's own header rules out counts as shared mutable cells that every feature PR would have to edit. Control: green on the committed tree (no fragment carries a duplicate today); red on the restored collision, naming the file and the id. 85 tests pass in this file. Happy to drop this if you would rather the round stayed inside the review's four corners — but then the renumber ships uncontrolled, and I would rather put that choice in front of you than make it quietly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015mgqVNP3rqTVMgBNnBMnGH * test(#3829): finish the census comment correction, which stopped one line short Found by this round's own pre-push adversarial review, which refuted the claim the previous commit made about itself. `7f019d985` said the census comment correction was complete. It corrected one site and left two, both in the helper block twelve lines above the test it belongs to: - `severityMapKeys`' header still read "The THIRD copy: the severity map's keys". With three alternations the map is the FOURTH copy, and has been since round 5. - `idAlternations`' header said "adding a prefix to only two of them is silent", written when there were two alternations and never updated to three. This is the defect the original correction was ABOUT, committed inside the correction: a fragment of prose carries no supersession marker, so a reader landing on line 2810 gets the dead count stated as current fact, and the fixed comment eighty lines down does not reach them. Fixing one surface and leaving its neighbour is not a partial fix, it is the same fix not done. The region is now consistent end to end, and both headers say the thing that actually matters — the scan is by PATTERN, not a fixed list of sites, which is why round 5's new matcher needed no edit here and why converting it to an enumeration would reintroduce exactly the drift it guards. WHILE HERE, a disclosure that was narrower than the truth. `7a6680e8f` said the `Emitted-Drift-Ack-Growth` trailer still names REQ-REVIEW-09 for what is now REQ-REVIEW-10, and left it deliberately rather than rewrite 52 replayed commits. That is right, but it is not the whole set: the message BODIES of `c94106568` ("wire the disposition ledger into the fix path") and `06282f668` ("migrate the emitted-drift ack") both state "REQ-REVIEW-09 was unreachable in every shipped path", meaning the disposition requirement, which is now REQ-REVIEW-10. Same decision, stated at its real size: three historical references, not one. They are commit history rather than living documentation — git is the record of what was believed when — and rewriting the branch to correct a number in a message would cost every review round its correspondence to the commits it reviewed. The TREE carries no stale reference; `docs/`, the workflows and the tests all read REQ-REVIEW-09 for severity surfacing and REQ-REVIEW-10 for the disposition. Regression file: 181 tests pass, 0 skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015mgqVNP3rqTVMgBNnBMnGH * test(#3829): the third stale count, and a disclosure that over-counted itself Both found by re-running this round's pre-push review after the last fix. It refuted the commit that claimed the region was consistent — for the second time in a row — and it was right again. **The third site.** `:2917` said "And the third copy, which is not an alternation" and `:2919` said "Without this, both regexes can gain a prefix". Written when there were two alternations; there are three, so the map is the fourth copy and it is three regexes that can drift. Worth saying how it survived two passes, because the mechanism is the point and it is the same one this PR keeps re-learning. Both earlier passes VERIFIED with a grep built from the strings I had just fixed — `THIRD copy`, case-sensitive, plus a handful of phrasings I expected. `the third copy` in lowercase matched none of them, and `both regexes` was not a phrasing I thought to look for. A grep returns what you already thought of; that is not a verification of prose, it is a re-statement of your own assumption. The region is now checked by reading it end to end, and all four count statements agree: three alternations (heading matcher, ledger row re-parser, frontmatter `- id:` matcher), with the severity map as the fourth copy. **And the disclosure over-counted.** The previous commit widened the historical REQ-REVIEW-09 references from one to three. Three is wrong. There are TWO underlying statements: - `c94106568`'s message body, and - the `Emitted-Drift-Ack-Growth` trailer on `06282f668`. I counted `06282f668` twice — once as "the trailer" and once as "a body" — when its only mention IS that trailer (`git show -s --format=%B 06282f668 | grep -c REQ-REVIEW-09` outside the trailer line: 0). Over-counting is the safe direction and it is still a wrong number in a message, which is the thing this round has been correcting all along. The decision is unchanged: both are commit history rather than living documentation, and rewriting the branch to fix a number in a message would cost every review round its correspondence to the commits it reviewed. The TREE carries no stale reference — 08 is #3661's `workflow.code_review_point`, 09 is severity surfacing, 10 is the per-finding disposition. Comment-only in one test file; no assertion, regex or extracted-script expectation moved. Regression file: 181 tests pass, 0 skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015mgqVNP3rqTVMgBNnBMnGH * fix(#3829): join the disposition-step dispatch so REQ-LANG-04 inheritance is provable `lint-response-language-coverage` (#2529, which landed on `next` after this PR was approved) reported `execute-phase/steps/code-review-disposition.md` as having no response-language coverage. The step does inherit it: `execute-phase.md` imports `references/execute-phase-response-language.md` and dispatches the step with `Read and execute`. The dispatch stub wrapped, leaving the verb at the end of one line and the path at the start of the next, and `namesFragmentAsEntryPoint` matches within a single line — so a genuine inheritance was unprovable to the linter. Rejoining the verb and the path restores it: `namesFragmentAsEntryPoint` goes false -> true and the lint reports `OK (165 workflows covered)`. Only line breaks move — the word stream is identical to the previous revision, and the file is unchanged at 93,390 bytes, so no growth acknowledgment is owed. This takes the third coverage form the lint documents — inheritance — rather than the inline directive the CI message names first. Where inheritance is provable the lint's own comments say a second copy "buys no coverage and adds a sentence that can drift", and the step file already sits over the prompt-stuffing threshold. Swept all 76 fragments in the catalog: this is the only one whose parent's previous line ends with a dispatch verb. The 17 others that are mentioned without a provable entry point are table-routed or bare prose references carrying no dispatch verb at all, and correctly hold the pinned inline directive instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JgX6QQmygeZnQqbc3o8RNC * chore(#3829): regenerate derived artifacts after rebase onto next The rebase onto current `next` conflicted on the 19 install-tree goldens and `docs/FEATURES.md`. Those are generated, so the conflicts were resolved arbitrarily and the generators re-run (`npm run regen:derived`) rather than hand-merged — a clean textual merge of a generated file attests the merge, never the content. Reconciled per artifact against the base's own committed copy rather than against the pre-regen tree, because the pre-regen tree is the arbitrary resolution: - all 19 `tests/fixtures/install-tree/*.json` now differ from `upstream/next` by exactly one key, `gsd-core/workflows/execute-phase/steps/code-review-disposition.md`; - `docs/FEATURES.md` differs by exactly REQ-REVIEW-09/10 and this PR's own reference section; - `docs/INVENTORY-MANIFEST.json` differs by exactly the same one step file, and needed no regeneration to get there. Nothing the base added was dropped by the arbitrary resolution: the restored entries (the `gsd-core/agents/` and `gsd-core/commands/gsd/` families, the compact templates, the `detail/elaboration.md` files, `gsd-secret-read-guard.js`) are all base-owned and came back through the generator, which is what the resolve-arbitrarily-then-regenerate discipline is for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBjyHFtRTtHDD2tM6V6aUV * fix(#3829): repair the rebase's conflict resolution in the regression suite The rebase onto current `next` hit one add/add conflict in this file: #4209's external-reviewer-evidence describe and this PR's #3829 block were added at the same insertion point. Resolving it by keeping both sides was correct in substance and wrong in mechanics — the conflict boundary cuts through two open blocks that the SHARED trailing ` });\n});` closes, so each side carries +2 unbalanced braces on its own and concatenating them left the file with 683 `{` against 680 `}`. `node --check` fails outright, so the whole file deregistered rather than failing a test — 188 tests silently stopped existing. Rebuilt the region as a real three-way merge (ancestora262ad6b6, ours upstream/next, theirs 77ee739c3) and closed the first side explicitly before the second begins. Both feature blocks are present exactly once, braces balance 683/683, and the file runs 188/188 locally. The sibling markdown file resolved the same way is unaffected and was checked rather than assumed: prose has no block structure to unbalance, and it differs from the base by 112 added lines with zero removed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBjyHFtRTtHDD2tM6V6aUV * test(#3829): inject the unreadable-review failure in a way root cannot bypass Round 9 finding 1. `runShippedGateCounts({ mode: 0o000 })` does not simulate an unreadable review under root: root bypasses POSIX read permission bits, so the fence's `[ -f "$REVIEW_FILE" ] && [ -r "$REVIEW_FILE" ]` guard stays true, the fixture is read, and the assertion sees a real breakdown where it expects silence. Reproduced as reported — `node:24-slim`, euid 0: not ok 18 - an unreadable REVIEW.md leaves the counts empty and does not abort actual: 'Code review: 4 findings — 1 critical, 2 warning, 1 info.\n...' **The prescribed remedy does not reach this site, so this adapts it rather than applying it.** Stubbing `fs.readFileSync` to throw EACCES is the right fix where the read happens in-process; here the read is performed by a spawned `bash`, so node's `fs` is not on the code path and the stub would change nothing. What the guard actually has is two legs, and only `-r` is defeated by root: - the `-r` leg keeps the mode-bit fixture and declares the lanes it cannot bind on (`win32`, `euid 0`), which is exactly what tests/plan-review-convergence.test.cjs:2326 does for its own shell-side `-r` arm — the repo's existing precedent for this shape; - the `-f` leg is new and root-immune: a DIRECTORY at the review path fails `-f` for every euid, reaching the same non-reporting arm with the same observable. It binds on the bench lane where the first test is skipped. Skipping the first without adding the second would have traded a false failure for lost coverage on the only lane that found this. Reversion control, run as root: reverting this commit fails exactly `an unreadable REVIEW.md leaves the counts empty and does not abort` and its enclosing describe `#3861 round 1 — the counts mirror is asserted against the shipped shell`, with no other change to the failure set. **That answers the round's open question** — the review flagged the describe as possibly a second root cause; it is the first one's rollup, and there is no second. Local (euid 1000): 189/189, both tests run. Root: 179 pass / 1 skip, the skip naming its reason, the directory test running. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBjyHFtRTtHDD2tM6V6aUV * chore(#3829): refresh the compact-content benchmark baseline for the gate's edit Self-found in this round; not raised in review. The base range landed #4139's compact-content benchmark, whose committed baseline records per-workflow token counts. This PR replaces a 12-line bash block in `execute-phase.md`'s code_review_gate with a 5-line dispatch paragraph, which moves that workflow's measured counts by 17 tokens — so the baseline the base just added drifts against a tree it was measured before. DRIFT: split "execute-phase": off 25631 -> 25614 (-17), on 23380 -> 23363 (-17) DRIFT: aggregate: off 106923 -> 106906, on 90275 -> 90258 Refreshed with the remedy the script itself names (`node scripts/benchmark-compact-content.cjs --write`). The regenerated diff touches only the `execute-phase` entry and the aggregate — every other workflow's numbers are byte-identical, which is the reconcile this PR's edit predicts. Attributed rather than assumed: `tests/benchmark-compact-content.test.cjs` is 27/27 at `upstream/next` with no PR content, and was 26/27 on this head. So the drift is this PR's, not base noise — and it is invisible to a diff-scoped sweep, because the PR never touches the baseline file and the base range is what created it. The sibling `benchmark:compact-content-variants` was checked in the same pass and reports up to date, so this is the only one of the pair affected. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBjyHFtRTtHDD2tM6V6aUV * test(#3829): cover an EMPTY REVIEW.md, a case the body claimed and no test reached Found by this round's own adversarial audit of the PR body, not by review. The body has said since round 1 that the suite covers "a REVIEW.md that is missing, empty, or a directory". Two of those three were true. The empty one was not. Every `reviewText: ''` call in this file also passes `writeReview: false`, which makes the file MISSING, not empty — so the arm the body named had no test at all. They are genuinely different paths through the shipped fence: a missing file never gets past `[ -f ]`, while an empty one passes both `[ -f ]` and `[ -r ]` and is actually opened and read. Probed the shipped fence directly against a real empty file before asserting anything: exit 0, empty stdout. So the behaviour was already correct and only the coverage claim was false — which is the same "documented as covered, not covered" shape this PR exists to make visible in the review gate, found in its own body. The explanatory comment is deliberately precise about WHY the scan yields nothing, because the plausible reading is wrong and a later reader would inherit it: it is not the `NR==1{if($0!="---") exit}` guard. A zero-byte file gives awk no record, so that action never runs (NR stays 0); the output is empty because `closed` is never set. The comment also states what the test does not prove on its own — its observable is identical to the missing-file case, so "the file was read" rests on the harness and the fence, not on the assertions. 189 -> 190 tests in this file, all passing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBjyHFtRTtHDD2tM6V6aUV * chore(#3829): regenerate derived artifacts after rebase onto next The rebase onto current `next` conflicted in the 19 install-tree goldens, `docs/INVENTORY-MANIFEST.json` and the compact-content benchmark baseline. Those are generated, so they were resolved arbitrarily and regenerated with their own producers rather than hand-merged: every golden now differs from `next`'s committed copy by exactly the one PR-owned entry (`gsd-core/workflows/execute-phase/steps/code-review-disposition.md`), the manifest by the same entry, and the benchmark baseline by the `execute-phase` split plus the aggregate. * chore(#3829): regenerate the platform-conformance tier for the added property test `next` gained the conformance-tier classifier (#4591) and its CI gate after this branch was cut. The branch adds `tests/code-review-disposition.property.test.cjs`, so the generated tier list was one file short (546 != 547). Regenerated with `node scripts/gen-platform-conformance-tier.cjs --write`; the macOS tier (`--target macos --check`) already matched. * chore(#3829): regenerate the two conflicted generated artifacts after the rebase `next` moved 6 commits past the previous base and conflicted in exactly two files, both generated: - `tests/fixtures/compact-content-benchmark-baseline.json` — #4208 (`4cc2a466b`) and #4619 (`db4d8a9ba`) both moved the measured token counts, and this branch moves the `execute-phase` split too. - `scripts/lib/platform-conformance-tier.generated.cjs` — #4641 (`4d65c248e`) made test-conformance the sole Windows selector and narrowed the tier to 28.5%, and #4568/#4619 re-ran it after. Both were resolved arbitrarily during the replay and then regenerated with their own producers rather than hand-merged, per the generated-artifact rule: `node scripts/benchmark-compact-content.cjs --write` and `npm run regen:derived` (which runs `gen-platform-conformance-tier.cjs --write` for both the default and the macOS target). Reconciled against `next`'s own committed copies rather than the pre-regen tree: - the benchmark baseline differs from `next` by exactly the `execute-phase` split (`offTokens` 25827 -> 25810, `onTokens` 23576 -> 23559 — the 17-token delta this PR's step-file extraction has carried since round 5) plus the `aggregate` that sums it; - the conformance tier differs from `next` by exactly one added entry, `tests/code-review-fix-pipeline-regression.test.cjs`. Under the narrowed 28.5% selector that is the file the classifier now picks from this PR's test set. The arbitrary resolution had carried 282 stale lines computed under the pre-#4641 selector (`--numstat` on this commit: 3 insertions, 282 deletions), and regeneration collapsed them. The full derived sweep was run, not just the two named producers: all 19 install-tree goldens, `docs/INVENTORY-MANIFEST.json`, `docs/FEATURES.md`, the macOS conformance tier and the exit-code registries regenerated byte-identical, so nothing else drifted under the new base. * fix(#3829): accept N-segment phase ids, and bound length per component The base range added `scanMarkdownSingleSegmentPhaseRegex` (#4568, `a2331c01f`), which refuses the single-optional-segment phase regex on phase-carrying markdown lines under three roots — `gsd-core/workflows/`, `gsd-core/references/` and `agents/` (`lint-phase-id-drift.cjs:301`, `:373-387`). It flagged two lines in this step file. Chasing the flag turned up two real defects behind it, so this commit is those rather than the comment edit the flag literally asked for. ## Defect 1 — the step refused ids both its callers accept The comments asserted that both callers validate `^[0-9]+(\.[0-9]+)?$`. #4568 had widened those two call sites to `^[0-9]+(\.[0-9]+)*$`, so the prose was stale. Correcting only the prose would have shipped a comment promising N-segment support over code that refused it, because the step carried a third `case` arm: *.*.*) _ok=0 ;; # more than one dot: not the documented shape `23.1.2` took the refusal arm, `PADDED` came back empty, and the step printed `Code review reporting skipped (unusable phase number ...)` and wrote **no ledger** — for a phase id both of its callers accept. It degraded loudly rather than silently; there is a diagnostic on stdout. The traversal-fence test asserted that refusal as *correct*, listing `1.2.3` among the values that must be rejected, so an arity bound and a shape bound sat folded into one `case` arm with a test pinning the pair. The arity arm is gone. Deleting it alone would have left the step **wider** than its callers in one direction — `1..2` has an empty segment, which `^[0-9]+(\.[0-9]+)*$` refuses and the retired arm had been masking — so a third arm replaces it: *..*) _ok=0 ;; # EMPTY SEGMENT ## Defect 2 — the length bound was not per-component, though its comment said so Removing the arity arm made a second defect reachable. The bound read: case "$_pn" in *.*) case "${_pn#*.}" in ?????????*) _ok=0 ;; esac ;; esac `${_pn#*.}` is the whole tail after the first dot — one component only while an id has at most two. With N-segment ids accepted, that form rejects `1.1234567.1`, whose every component is a legal 7 digits, purely because the tail measures 9 characters. The comment directly above it has read **"LENGTH-BOUND EACH COMPONENT SEPARATELY"** since before this PR, and had itself named the composite bound as "too strict" — the same mistake, surviving one level up. Both fences now walk the segments and bound each: _rest="$_pn" while [ -n "$_rest" ]; do case "$_rest" in *.*) _seg="${_rest%%.*}"; _rest="${_rest#*.}" ;; *) _seg="$_rest"; _rest="" ;; esac case "$_seg" in ?????????*) _ok=0 ;; esac done The `$((10#...))` overflow guard is preserved, per component: bash integers wrap at 2^64, so an unbounded integer segment would silently become a negative padded phase. **The remaining divergence from the callers is a CLASS, not a list:** any id carrying a component of nine or more characters is caller-accepted and fence-refused — `123456789`, `1.999999999`, `1.123456789.1`, `123456789.1`, `1.1.123456789` and so on. That narrowing is deliberate and is the overflow guard. An earlier draft named two examples as though they were exhaustive; that wording is withdrawn. ## What is NOT claimed - The canonical grammar is `PHASE_NUMBER_TOKEN_SOURCE` in `src/phase-id.cts:65`, `\d+[A-Z]?(?:\.\d+)*`, added by **#2128** (`09be501eb`, 2026-07-10). An earlier draft dated it to #865 (2026-06-08); that was the first commit to touch the *file*, not the one that added the constant, and it is withdrawn. - #4568 gave the six shell sites **segment-count** parity with that grammar, not textual parity: the canonical source permits an optional `[A-Z]`, and the shell literals remain digit-only. Driven: this step and both callers all refuse `23A.1`, so they agree with each other and are jointly narrower than `src/phase-id.cts`. That is a question about the six sites rather than about this step, and it is not touched here. - **#4619 does not produce N-segment ids.** It only transforms an already-supplied `{phase_number}` so `$((10#...))` does not abort on one. An earlier draft cited it as the producer; that is withdrawn, and is stated rather than silently swapped so a reader can see it was corrected. - That the folded `case` arm is *why* nothing caught this is an observation about the test's shape, not an established cause. ## Tests - `an N-SEGMENT phase number reports counts, exactly as its callers accept it` — drives `23.1.2` **and** `1.2.3.4`: the retired guard was arity-shaped, so a bound merely moved from two dots to three would pass a three-segment-only test. - `the length bound is PER COMPONENT, not over the whole tail after the first dot` — drives an 8-char and a 9-char **middle** segment, the position the old form got wrong. - `the fence agrees with its callers across a probed set spanning both boundaries` — example-based, and says so: a finite probe cannot prove congruence over an infinite language, and one review pass demonstrated that by injecting a `2) _ok=0` arm this test still passed. It is a regression pin over the values that actually broke. - The traversal list loses `1.2.3` (legal at this base) and gains `1..2` and `1.2.` — the malformed-dot cases the arity guard had masked. **Negative controls, re-measured against reconstructed fences:** fence state N-seg probed per-comp fully pre-fix FAIL FAIL FAIL shape-fix only PASS FAIL FAIL this tree PASS PASS PASS Two tests, not one, catch Defect 2: the caller-agreement probe includes `1.1234567.1`, so the whole-tail bound breaks it too. An earlier draft claimed the per-component test failed alone — that table was written before `1.1234567.1` was added to the probe and was not re-measured afterwards. It is corrected here from a fresh run. The N-segment test correctly does not fire on Defect 2; it predates the bound work and is insensitive to it. Found by this round's own adversarial review passes. * docs(#3829): name this step's two dispatchers correctly, in code as well as in the PR body `code-review.md` is not a call site of this step. It carries an identical `^[0-9]+(\.[0-9]+)*$` validator, which is why it kept getting cited as one, but it never dispatches `code-review-disposition.md`. The two dispatchers are `execute-phase.md` (`code_review_gate`) and `code-review-fix.md` (`record_disposition`) -- and only the second validates anything. This round corrected that in the PR body and simultaneously wrote the old conflation into the shipped comments, so the file asserted at line 24 what the body denied in public, and contradicted its own line 48. Four false assertions, each duplicated because the fenced block is emitted twice: - "Both callers explicitly accept ... (code-review.md:63, code-review-fix.md:39)" - "#4568 widened both of this step's callers" -- it widened the one that validates; the other has no validator to widen - "Both callers already validate ... (code-review.md:63, code-review-fix.md:39)" - "a SHAPE (..., asserted by both callers)" -- asserted by one The same conflation had propagated into three comments in `code-review-pipeline-regression.test.cjs`; corrected there too. Adds the one fact that follows from naming the dispatchers correctly and that nothing else in the tree records: `execute-phase.md` applies NO shape gate, so this fence is not mirroring an upstream guarantee -- it IS the guarantee. A later reader who believes the caller validates will "simplify" it away. Comments only. The executable shell is byte-identical to 03adf9474 (verified by stripping comment lines and diffing). 200/200 regression + property, 47/47 prompt-injection security scan, eslint and lint:generated-sync clean. The wider [A-Z]-axis divergence between these sites and the canonical `PHASE_NUMBER_TOKEN_SOURCE` is tracked separately as #4660 and deliberately not restated here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xdw628PpLYveWfJu7kDyvZ * chore(#3829): regenerate the two conflicted generated artifacts after the rebase onto next Both conflicted during the replay onto `eb49ff98d` and were resolved arbitrarily, then regenerated with their own producers (`npm run regen:derived`, `node scripts/benchmark-compact-content.cjs --write`) rather than hand-merged. Reconciled against next's committed copies: the conformance tier differs by the one entry this PR adds, the benchmark baseline by the `execute-phase` split (the same 17-token delta this PR's step-file extraction has carried since round 5) plus the aggregate that sums it. The rest of the derived sweep — 19 install-tree goldens, INVENTORY-MANIFEST, FEATURES, the macOS tier, the exit-code registries — regenerated byte-identical. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9FANs6AXuXNa7fCSahTQe * fix(#3829): a carried row keeps the severity the ledger recorded, instead of re-inferring it from the prefix The ledger always wrote a severity for every row (table cell and frontmatter key) and nothing read either back: the prior-row regex skipped the cell as `[^|]*`, the frontmatter walk collected only titles, and a carried row was rebuilt through sev() from the id prefix, because sectionSev holds only the findings the CURRENT review reports. So a WR-04 the reviewer filed under `## Critical Issues` was recorded critical, a human deferred it, and the next run -- the review no longer reporting it -- silently re-recorded it warning. The one artifact whose purpose is remembering a finding's severity lost it on the second run, in the unsafe direction (round 11, reproduced by executing the shipped script twice). Both persisted copies are now read back, enum-validated (ADR-227, as the disposition column already is): the table cell first, the frontmatter `severity:` as the fallback for a hand-mangled cell. Severity precedence is the current review's SECTION, then the RECORDED value, then the id PREFIX, and the recorded value is inherited only while the id still names the same finding -- the identity rule the disposition already obeys -- so a reused id starts from its own review. sev() moves below sameFinding() because it now depends on it. Tests: a new describe drives the reviewer's exact case (WR-04 under `## Critical Issues`, deferred by hand, dropped by the next review -> stays critical) plus five controls: recorded outranks prefix under no recognized section; the current section still outranks recorded; a REUSED id does not inherit; a mangled cell falls back to the frontmatter and a mangled pair to the prefix; a bare pre-severity row still infers. A fast-check property assigns each finding a section independent of its prefix, carries every row through an empty review, and asserts the section severity survives and the third run reports unchanged. Negative control, measured against the pre-fix step: the two carry tests, the mangled-cell test and the property fail; the three precedence/back-compat controls pass at both ends, as they pin behaviour that predates the fix. Every prior carried-row test used CR-01/IN-01, whose prefix already matched, so the lossy path had returned the right answer by coincidence. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9FANs6AXuXNa7fCSahTQe * fix(#3829): a malformed REVIEW.md is reported as unparsed, not passed over as clean A REVIEW.md with three criticals and an unterminated frontmatter yielded REVIEW_STATUS='', and the counting arm then printed nothing -- byte-identical to a clean review. The guard that scopes the frontmatter scan was right to yield no values from an unterminated block; the reporting arm was wrong to treat 'no status' as 'no review'. Block 2 said `status: none` rather than `clean`, which is why a careful reader could still separate them (round 11, Minor). Both fences now record whether the file was actually READ, separately from what it yielded. A read file with no parseable status -- unterminated frontmatter, no frontmatter, no `status:` key, a zero-byte file -- prints `Code review status unparsed: ...` with no breakdown (there is none to trust) and no --fix suggestion (nothing proves there are findings). Absent, directory and unreadable stay silent: nothing was read, so nothing is described. Block 2's skip line names the same distinction, `status: unparsed` vs `none`. The counts mirror follows the shell: a mirror is always handed a text, so its empty-status arm is the unparsed one, and the existing 'unterminated frontmatter' and 'no frontmatter at all' parity fixtures now bind the new message on both sides. The EMPTY-file test from round 9 changes its assertion deliberately: its observable is no longer identical to the missing-file case, which is the point. Five new tests drive the arm, its three shapes, the three shapes that stay silent, and block 2's wording. Negative control, against the previous step: the unterminated, no-status, no-frontmatter and empty-file tests fail, both parity fixtures fail (the mirror moved and the shell had not), and block 2's `unparsed` assertion fails; the stays-silent controls pass at both ends. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9FANs6AXuXNa7fCSahTQe * docs(#3829): name the unlocked read-modify-write and reference #3780 rather than solving it The ledger is rendered whole from a prior read with nothing serializing two writers, and this step has two dispatchers plus an invited hand-edit, so the window is real. It is the shape #3780 reported for WINDOWS.md under parallel executors, which #4681 closed with a cross-process lock in src/broken-windows.cts. Not taken here, deliberately: the step is a shell-embedded script with no dependency on the compiled tree, and adopting the lock module is its own change. Stated at the write site and as a residual in the feature doc; no lost update has been reproduced (round 11, Minor). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9FANs6AXuXNa7fCSahTQe * docs(#3829): cross-reference the two "review disposition" ledgers in both directions ADR-3806 canonizes a `## Review Dispositions Ledger` section inside PLAN.md for reviews-mode planning: append-only per round, over REVIEWS.md findings. This PR's `<NN>-REVIEW-DISPOSITION.md` is a sibling file beside REVIEW.md for the code-review pipeline, rewritten idempotently with rows carried. Adjacent names, opposite durability rules, and neither document mentioned the other -- the round-11 review checked the ADR gate against 3806, cleared it, and flagged exactly that mis-read hazard. An in-place dated amendment section on ADR-3806 (contributor-standards "Amending an accepted ADR", pattern 1) and a paragraph in the pipeline feature doc, each naming the other and the axis on which they differ. docs/FEATURES.md regenerated. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9FANs6AXuXNa7fCSahTQe * chore(#3829): regenerate the compact-content benchmark baseline after the rebase onto next `next` moved three commits while the round was in flight and the baseline conflicted again; resolved arbitrarily during the replay and regenerated with its own producer. It differs from next's copy by the `execute-phase` split this PR has carried since round 5, plus the aggregate. The rest of the derived sweep regenerated byte-identical. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9FANs6AXuXNa7fCSahTQe * fix(#3829): accept letter-variant phase ids, matching the canonical grammar #4744 widened the dispatchers to #4744 (#4660) landed on `next` while this round was in flight: it widened the six shell/markdown phase-number mirrors -- `code-review-fix.md:39`, this step's validating dispatcher, among them -- to the canonical grammar's letter axis (`12A`, `3A`, `23A.1.2`), and added a `lint-phase-id-drift` ratchet that flags any digit-only mirror left in the workflow tree. Rebased onto that base, this step was the one it flagged (two fences, two sites): `12A` was refused by name and wrote no ledger, for a phase id its own dispatcher now accepts -- the round-10 class ("the step refused phase ids its validating dispatcher accepts") re-opened by the base. Found by running the base range's modified gates against the rebased tree, not by the review. Both fences now admit an uppercase letter in the character class and pin WHERE it may sit -- only as the last character of the integer part, at most once -- so `23a`, `A23`, `2A3`, `23AB` and `23.1A` stay refused. The per-component length bound is on the DIGITS (the letter is one character the `$((10#...))` overflow guard has no stake in, so `12345678A` is within it exactly as `12345678` is), and the letter is carried verbatim after the padded digits, `3A` -> `03A`, as `src/phase-id.cts` pads it. The two fences stay line-identical except for their refusal message (the parity test holds), and every comment literal of the old shape reads the canonical one. Tests: a new fixture drives `12A`, `3A`, `23A.1.2` and `12345678A` through the shipped fence to the padded path; the traversal-fence list gains the five wrong placements; the caller-agreement probe's regex gains the letter axis with both-direction cases, and `123456789A` joins the deliberate over-bound narrowing. Negative control against the pre-widening step: the letter-variant test, the caller-agreement probe and the base's `scanMarkdownLetterlessPhaseMirror` gate all fail; the traversal-fence test passes at both ends (the five new placements were already refused, by the narrower class). Also re-anchors the fence and test comments' `code-review-fix.md` / `code-review.md` citations by content (the validator, not a line number): the line numbers had drifted by one against the rebased base, and drift again on every rebase. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9FANs6AXuXNa7fCSahTQe * chore(#3829): regenerate the two conflicted generated artifacts after the rebase onto next Both files conflicted during the replay and were resolved arbitrarily rather than hand-merged, then regenerated with their own producers — `npm run regen:derived` and `node scripts/benchmark-compact-content.cjs --write`. Reconciled against next's own committed copies rather than against the pre-regen tree, because a clean textual merge of a pinned-number file attests the merge and not the numbers: - `tests/fixtures/compact-content-benchmark-baseline.json` differs from next by exactly the `execute-phase` split (offTokens 26264 -> 26200, onTokens 24013 -> 23949) and the `aggregate` that sums it. That is the step-file extraction this PR has carried since round 5, re-measured against the new base; no other entry moved. - `scripts/lib/platform-conformance-tier.generated.cjs` differs from next by exactly one added entry, `tests/code-review-fix-pipeline-regression.test.cjs` — the file the classifier picks from this PR's test set. The full derived sweep was run, not just the two named producers: all 19 install-tree goldens, docs/FEATURES.md, docs/INVENTORY-MANIFEST.json, the macOS tier and the exit-code registries regenerate byte-identical under the new base, so nothing else drifted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * fix(#3829): stop block 2 computing an unparsed shortfall from a self-contradicting findings block Round 12, Minor. Confirmed, and the premise is slightly stronger than stated: block 2 does not merely skip block 1's `critical + warning + info == total` cross-check — it never derived the three severity counts at all, so the check's inputs were absent. It bounded `total` for digits and length only and handed it to the `unparsed:` reconciliation. So a REVIEW.md whose `findings:` block disagrees with itself (`total: 10` beside `critical: 1, warning: 1, info: 1`) made block 1 print the countless form — breakdown suppressed as untrustworthy — while block 2 still computed a shortfall from that same untrusted number. Two trust models for one field, one fence apart, with the weaker one downstream. It fails in the safe direction, which is why the review did not raise it as a blocker; it is still a real inconsistency. Block 2 now derives `critical`/`blocker`, `warning` and `info` through the same `findings:`-anchored filter block 1 uses, with the same digit-and-length bound and the same `10#` on every operand, and blanks `total` when the three disagree with it. **Adapted, not applied verbatim — and the divergence is the point.** The finding says to re-apply block 1's cross-check. Block 1's gate is `REVIEW_COUNTS_OK`, which demands all four counts be numeric, because block 1 DISPLAYS all four and `6 findings — critical` is the half-filled line that rule exists to prevent. Block 2 displays none of them; it uses `total` alone, against the number of headings the row parser matched. Applied verbatim, the all-four rule blanks a perfectly usable `total: 5` on a review carrying no severity keys and SILENTLY DROPS an `unparsed:` shortfall this step reports correctly today — trading a safe-direction over-report for a silent under-report, which is the wrong way round and is the exact failure class the `unparsed:` key was added to close. Only the CONTRADICTION ports: absent counts are not a disagreement, because there is nothing to disagree with. Driven against the shipped fence, not a mirror: consistent 1+1+1=3 -> total 3 CONTRADICTION total:10 -> withheld blocker: alternation -> total 2 counts absent -> total 5 (kept) leading zeros 01+01+01=03 -> total 03 one count absent -> total 5 (kept) no findings block -> withheld non-numeric count -> total 5 (kept) Six regression tests drive the second markdown fence end to end through `runHook` under bash, asserting on the rendered ledger. Negative controls fire in OPPOSITE directions, which is what pins the narrowing rather than only the fix: - revert the fence fix -> `a contradicting findings block yields no shortfall` and the `blocker:` twin go red - apply the VERBATIM all-four -> `a total with NO severity keys still reconciles` prescription instead and the partial/non-numeric case go red Restored tree: 214/214. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * docs(#3829): state the one input that produces no unparsed shortfall The reference page said the shortfall "is stated" whenever `total:` exceeds the parsed headings. After the round-12 fix that is conditional, and a doc asserting the unconditional form describes behaviour the step no longer has. Names the boundary in both directions, because the narrowing is the part a reader would otherwise get wrong: a `findings:` block whose three severities are all present, numeric and do not sum to `total` produces no key — the same input on which the console line already withholds the breakdown — while counts that are merely absent, partial or non-numeric are not a disagreement and still reconcile from `total` alone. `docs/FEATURES.md` regenerated; `gen-features --check` green (182 features, 21 groups). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * fix(#3829): close two holes the round's own adversarial pass found in its first attempt Neither is from the maintainer's review. Both were found by the pre-push adversarial pass over this round's own claims, which refuted them by execution. **1. A malformed severity could suppress a real shortfall.** The sibling frontmatter reads use `cut -d: -f2 | tr -d ' '`, and `tr -d` deletes INTERNAL spaces, so `critical: 1 0` arrives as the perfectly numeric `10`. That is long-standing in those reads — its mirror is pinned as a fixture from round 1 — and it was INERT in block 2 until this round made that block read the severities at all. At that point a repaired number could satisfy the new sum test and suppress an `unparsed:` shortfall that is genuinely owed. Driven, pre-fix: `critical: 1 0 / warning: 0 / info: 0 / total: 5` against three parsed headings emitted no `unparsed:` key where `unparsed: 2` was correct. The three severity reads now trim the ends only, so an internal space survives into the digit check and fails it — `_sum_ok=0`, nothing is suppressed. Fail-safe in the only direction that matters: when the frontmatter is malformed the step declines to suppress rather than trusting a repaired number. **Scope, stated:** only the SUPPRESSION inputs are strict. `REVIEW_TOTAL`'s own read still uses `tr -d ' '`, unchanged and identical to block 1's — narrowing it would change the `unparsed:` computation itself, which is pre-existing behaviour and wider than this round. So `total: 1 0` is still read as `10` by both blocks, as before. **2. The repointed #4748 gate could not see a later rebinding.** Its derivation slices stop AT the first anchored assignment, so inserting the canonical lookup and then overriding it with `REVIEW_FILE="${_pd}/WRONG-REVIEW.md"` left every assertion green — the slice pins a line, not the path the fence actually consumes. A new test pins the whole file instead: the only `REVIEW_FILE=` bindings permitted are the canonical lookup (exactly twice, once per fence, each being a fresh shell) and the identity pass-through that hands it to the embedded node script as an env prefix. Negative controls, both the adversarial pass's own mutations, against the restored tree at 215/215 and 164/164: - restore `tr -d ' '` on the severity reads -> the internal-space test reds - insert the WRONG-REVIEW override after the lookup -> the rebinding test reds Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * fix(#3829): one parser for every count block 2 reads, and widen the rebinding guard A second adversarial pass, run against the first pass's own fixes, refuted three of them by execution. Fixes to review findings are the class most likely to carry a new defect, which is why that pass exists; all three were real. **1. `cut -d: -f2` takes the SECOND FIELD, not the scalar.** So `critical: 1: junk` arrived as the perfectly numeric `1`, and `1+0+0 != 5` was read as a contradiction that SUPPRESSED a shortfall genuinely owed. The previous fix trimmed the ends but still cut at the wrong place, so it closed the internal-space shape and left this one open. `-f2-` keeps everything after the first colon; the malformed scalar stays malformed and `total: 5` still reconciles. **2. The deliberate asymmetry was wrong, and it FABRICATED.** The previous fix parsed the severities strictly and left `total` lenient, on the reasoning that narrowing `total` was out of scope. Driven: `critical: 5 0` with `total: 1 0` repaired only the total to `10`, rejected the severity, skipped the contradiction check, and invented `unparsed: 7` against three parsed headings. Both uniform policies behave sanely — strict rejects the malformed total, lenient detects `50 != 10`. A field is either trustworthy or it is not; parsing one leniently and its sibling strictly is the shape that fabricates. Every count this block reads now goes through one parser. **Scope, restated because it moved:** the previous commit said `REVIEW_TOTAL`'s read was deliberately unchanged. That is no longer true and the reasoning behind it did not survive contact — the asymmetry it protected is what produced the fabrication. Block 1's reads are still untouched; its own all-four gate runs over consistently-parsed values, so it has no equivalent split. **3. The rebinding guard missed an indented or exported assignment.** `^REVIEW_FILE=` let both ` REVIEW_FILE=...` and `export REVIEW_FILE=...` through, and each executes exactly like a bare one. The predicate now absorbs leading whitespace and an optional `export` before the accept-list decides. Driven after the fix, against three parsed headings: critical: '1: junk' total: 5 -> total 5 kept, unparsed: 2 reported critical: '5 0' total: '1 0' -> total rejected, no unparsed key critical: '1 0' total: 5 -> total 5 kept (unchanged) consistent / contradiction / blocker / leading-zero / absent — all unchanged Negative controls, each the adversarial pass's own mutation, against 381/381: - `-f2-` back to `-f2` -> the second-colon test reds - `total` back to lenient `tr -d` -> the fabricated-shortfall test reds - an INDENTED rebinding -> the rebinding guard reds - an `export` rebinding -> the rebinding guard reds Residual, disclosed: a duplicate `critical:`/`blocker:` key is still resolved by `grep -m1` taking the first match. Duplicate keys are invalid YAML and the same first-match rule is long-standing in the sibling reads; detecting them is a wider change than this round. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * fix(#3829): one parser for the whole step, and prove a contradiction from a partial sum A third adversarial pass, run against the second pass's fixes. Three findings, plus one this round's own negative control caught afterwards. **1. An absent severity still bounds the sum from below.** Counts are non-negative, so a missing one can only ADD: when the severities that ARE present already sum to MORE than `total`, the block disagrees with itself whatever the absent value is. Requiring all three before comparing missed that — driven: `critical: 4`, `warning: 4`, no `info:`, `total: 5` reconciled against a total the present counts had already refuted. The comparison is two-armed now: EQUALITY when all three are known, a LOWER BOUND when they are not. An UNDERshoot stays reconcilable, because that is exactly what the absent count explains. **2. Block 1 now uses the same parser, so the console and the ledger cannot contradict each other.** Tightening block 2 first left the two fences disagreeing about the same bytes. Driven: `critical: 1 0` with `total: 1 0` repairs to 10 and 10, which SUM — so block 1 reported `10 findings — 10 critical, 0 warning, 0 info.` from a `findings:` block containing no such numbers, while the ledger recorded three rows and no shortfall. Block 1's reads move to `cut -d: -f2-` plus an end-trim; both fences now take the countless arm on that input. The counts mirror moves with them — its whole job is modelling the shipped pipeline, and it modelled the retired one. This is wider than the review's finding and I want that visible: the finding was about block 2 alone. But a disclosed divergence between a console line and a ledger is the confusion this PR exists to remove, so it is fixed rather than documented. **3. `REVIEW_FILE+=-wrong` executes and was missed.** The rebinding guard matched only `=`; `+=` appends (driven: `REVIEW_FILE=good; REVIEW_FILE+=-wrong` prints `good-wrong`). **4. My first negative control for (2) was VACUOUS, and that is the reason for the new `BLOCK 1 withholds a breakdown built from REPAIRED counts` test.** Reverting block 1's parser left the suite green: on every fixture that existed both parsers landed on the same arm, so parity could not see the difference. A SELF-CONSISTENT repaired breakdown separates them, and the test pins it directly rather than through parity. **Correction to the previous commit's claim.** It said moving `total` to a strict read "changes nothing for a well-formed review". That is false: `total:\t5\t` is valid YAML (`yaml.parse` returns 5) which the old `tr -d ' '` rejected and the new trim accepts. The change is an improvement, not a no-op, and the claim was the wrong shape. Also from the third pass's MISSED: the fixtures exercised malformed `critical` and `total` only, so they did not pin the four-field symmetry the fix claims. Every field now gets every malformed shape. Negative controls, against the restored tree at 383/383 (220 in the pipeline file): - revert block 1's parser -> the repaired-counts test reds (was vacuous; now fires) - revert the overshoot arm -> the absent-severity contradiction test reds - a `+=` rebinding -> the rebinding guard reds Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * fix(#3829): finish the mirror update, and give status the same parser as the counts A fourth adversarial pass. The important finding is that the PREVIOUS commit's mirror update was HALF APPLIED, and the suite could not see it. **1. The counts mirror was still on the retired parser.** That file carries TWO helpers: `first`, used for `status:`, and `firstIn`, used for ALL FOUR counts. The previous commit updated `first` and the comment above it, and left `firstIn` on `split(':')[1].replace(/ /g,'')` — so the shipped block had moved to `-f2-` + end-trim and the mirror had not, while the parity assertion stayed green. It stayed green for the same reason this round's earlier negative control was vacuous: on every fixture that existed, both parsers reach the COUNTLESS arm, so the rendered message is identical and parity cannot see the divergence. Two fixtures now separate them — `a self-consistent repaired breakdown` (10 == 10+0+0, so the retired parser renders a full breakdown from a `findings:` block containing no such numbers) and `tab-separated counts` (valid YAML the retired `tr -d ' '` made non-numeric). Reverting `firstIn` reds both. This is the same shape this PR's round-3 reply already recorded about itself: a fix verified with a grep built from the strings just fixed. The region is checked by reading it end to end now. **2. `status:` kept the retired parser after the counts moved off it, and it is the read where truncation costs most.** `cut -d: -f2` turned the valid YAML scalar `status: clean:junk` into the bare `clean`, so an unusable status took the CLEAN arm and suppressed BOTH the console report and the ledger. Driven, both parsers side by side. The whole scalar matches no arm now, so the step reports. One parser for every scalar this step reads, in both fences. **Two claim corrections, no code change:** - The previous commit implied block 1's console output was preserved for every well-formed review. It is not: `critical:\t1` is valid YAML that the retired `tr -d ' '` left non-numeric (countless form) and the trim now reads (full breakdown). That is an improvement, and the claim was the wrong shape. The `tab-separated counts` fixture pins it. - "Block 1 and block 2 can no longer contradict each other about counts" was overstated. It is true of the PARSER, which is what changed. They can still differ when the body carries MORE findings than `total:` declares: the reconciliation reports a shortfall only, and the excess direction is deliberately clamped so a review under-declaring its own total cannot render `unparsed: -1` — pinned by the round-2 test `a total SMALLER than the rows is not reported as a negative shortfall`. That is pre-existing and out of this round's scope; stating it rather than widening scope again. Negative controls, against the restored tree at 223/223 (387 across both files): - revert the mirror's `firstIn` -> both new parity fixtures red - revert the `status:` parser -> the clean-arm suppression test reds `npm run lint:ci` exits 0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * fix(#3829): pin the reads to LC_ALL=C, so the parser cannot depend on the machine A fifth adversarial pass. It refuted the claim that the shipped reads and their JS mirror are equivalent, and the counterexample is a locale. **The POSIX character classes are locale-defined, and glibc's C.UTF-8 disagrees with both C and en_US.UTF-8.** Driven, same sed, same input, three locales: LC_ALL=C clean<U+2003> -> clean<U+2003> (kept) LC_ALL=C.UTF-8 clean<U+2003> -> clean (trimmed) LC_ALL=en_US.UTF-8 clean<U+2003> -> clean<U+2003> (kept) C.UTF-8 classifies U+2003 — and U+1680, U+2000-U+200A, U+205F, U+3000 — as BOTH [[:space:]] and [[:blank:]]. So `status: clean<U+2003>` trimmed to the bare `clean`, took the CLEAN arm, and silently suppressed both the console report and the ledger — but only on machines whose locale said so. That is the same suppression the previous commit fixed for `clean:junk`, with a machine-dependent trigger instead of a parse one. `[[:blank:]]` is NOT the fix — it is locale-defined too, and C.UTF-8 puts U+2003 in it as well. Nor is `[ \t]`: POSIX bracket expressions provide no escape at all, so `\t` there is a backslash and a `t`. GNU sed's default reading of it as TAB is an extension, and the same GNU sed asked for conformance shows the other reading on this host: sed -E 's/[ \t]+$//' draft -> draft sed --posix -E 's/[ \t]+$//' draft -> draf A POSIX-conforming sed is therefore expected to truncate `status: draft` to `draf`. That expectation is derived from POSIX plus the `--posix` demonstration above; it was NOT driven against a BSD/macOS sed, because this host has none. The portable fix is to pin the locale: under C the class is exactly {space, tab, NL, VT, FF, CR}, which is precisely what the mirror already spells out literally. The two now agree by construction rather than by coincidence of the machine. All 20 read sites (10 `grep`, 10 `sed`, both fences) are pinned. The mirror's four anchors move from JS `\s` to the same literal class, closing the divergence in the other direction — `\s` matches a U+2003 indent that the pinned `grep` does not. **A second gap, found by this round's own control rather than by the reviewer.** The mirror has two helpers, and the previous commit proved `firstIn` (the counts) was pinned by a fixture. `first` (the status) was NOT: reverting it left the suite green. Every pre-existing status fixture left both parsers on the SAME arm — `issues:found` truncates to `issues`, which is no more `clean` than `issues:found` is — so the status mirror could drift unseen, exactly as `firstIn` had. The fixture that separates them is one where truncation FLIPS the arm: `status: clean:junk`. That is the third time this round a mirror edit was invisible to the fixtures that existed, and the question that finds it every time is: what input actually separates the two versions? **Two prose corrections in the step**, which had gone stale rather than wrong-headed: the block-2 comment still said "the sibling reads use `tr -d`" after they had all been moved off it, and the mirror's class comment claimed an equivalence it did not yet have. Negative controls, each driven against the committed tree: - drop LC_ALL=C from the shipped seds -> 5 red, incl. both locale-invariance tests - revert the `first` status mirror -> `a status whose truncation would flip the arm` reds - revert the mirror anchors to `\s` -> `locale-invariant on a unicode-space indented count key` reds The locale-invariance tests are the durable guard: the parity fixtures only run under whatever locale the suite inherits, so they can catch this only on a machine that already has the bug. These drive the same input under both locales and assert the shipped fence does not care. 238/238 across the two pipeline files. `npm run lint:ci` exits 0, with lint-workflow-shellcheck reporting 212 pre-existing findings and 0 new. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * fix(#3829): pin the awk selectors too, and assert the invariant instead of claiming it A sixth adversarial pass, and it refuted the previous commit's central claim. That commit pinned all 10 `grep` and all 10 `sed` reads to LC_ALL=C and then said the parser no longer depends on the machine. It does: the `findings:` MAPPING SELECTOR is an `awk`, and both copies of it were left unpinned. `awk '/^findings:[[:space:]]*$/{f=1; next} f&&/^[^[:space:]]/{exit} f'` resolves its two character classes through the ambient locale exactly as grep's and sed's did. Driven, on `findings:<U+2003>`: fence 1, LC_ALL=C Code review found issues. fence 1, LC_ALL=C.UTF-8 Code review: 1 findings — 1 critical, 0 warning, 0 info. fence 2, LC_ALL=C TOTAL='' fence 2, LC_ALL=C.UTF-8 TOTAL=1 Under C.UTF-8 the opener matched and the mapping opened; under C it did not. The same review rendered a breakdown on one machine and the countless message on another, with every grep and sed already pinned. **Why it was missed is the more useful part.** The previous commit's census counted `grep` and `sed` sites and reported zero unpinned — because it SEARCHED FOR THE TOOLS IT HAD JUST EDITED rather than for the tools that were there. That is the same shape as this round's other three misses: a check built from the thing just changed cannot see what the change forgot. So this commit does not just add the fourth and fifth pins; it replaces the claim with an assertion the next edit cannot fool: `every locale-sensitive tool in the step is pinned to LC_ALL=C` walks the step file and fails on ANY unpinned `grep`/`sed`/`awk`, naming line and call. `cut -d: -f2-` and `tr -d '\r'` stay exempt, and the exemption is principled rather than residual: neither resolves a character class or a collation — one splits on a single ASCII byte, the other deletes one literal byte. The mirror's block boundary moves to the same literal classes, for the same reason the anchors did last commit — `/^findings:\s*$/` and `/^\S/` model neither pinned side. **A correction to the previous commit's message, made in place.** It asserted that BSD sed reads `[ \t]` as a literal backslash and `t`, stated as driven fact. It was not driven — this host has no BSD sed. The claim is now stated as what it is: POSIX bracket expressions provide no escape, GNU's TAB reading is an extension, and GNU sed asked for conformance demonstrates the other reading here (`sed --posix -E 's/[ \t]+$//'` turns `draft` into `draf`). The conclusion is unchanged; the evidence class was overstated. Also measured while establishing that LC_ALL=C is safe for non-ASCII, and worth recording because it makes the pin a strict improvement rather than a wash: on a REVIEW.md carrying a single invalid UTF-8 byte, GNU grep under C.UTF-8 reports `binary file matches` and emits nothing, blanking EVERY read; under C the value parses and is rejected on its merits. Valid UTF-8 is untouched either way — the C space class is entirely bytes < 0x80, which no UTF-8 multibyte sequence contains, so the trim cannot split a character. Negative controls, each driven and restored: - unpin the four `awk` selectors -> 3 red, incl. the new invariant test naming both lines - revert the mirror block boundary to `\s`/`\S` -> both `findings:` opener tests red 241/241 across the two pipeline files. `npm run lint:ci` exits 0 — after it caught a real defect in the new test itself: `split('\n')` on readFileSync content is banned here (DEFECT.WINDOWS-CRLF-TEST-PORTABILITY), and it now uses `splitLines()`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * test(#3829): make the pin invariant see calls that are not piped The invariant added in the previous commit keyed on `| grep|sed|awk`, which is true of every call in the step today and is exactly the wrong thing to rely on. A guard written around the shapes that happen to exist cannot see the shape a later edit introduces — `awk '...' < "$f"` or `$(grep ...)` would have walked straight past it, which is the same property that let the two awk selectors sit unpinned through a commit claiming the parser was locale-independent. It now blanks the PINNED calls and treats anything still naming one of the three tools on a non-comment line as an offender, so the check is "every call is pinned" rather than "every piped call is pinned". Comment lines stay exempt: the step's prose names unpinned forms while explaining why they were retired. Driven both ways against the invariant alone: - inject a NON-PIPED unpinned `awk '...' < "$REVIEW_FILE"` -> reds (the old form did not) - unpin the four piped `awk` selectors -> still reds (no regression) - unmodified tree -> green 241/241 across the two pipeline files, `npm run lint:ci` exits 0. No shipped behaviour changes in this commit; it only widens what the test can see. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * test(#3829): close the invariant's path-qualified hole, and state the limit it keeps A seventh adversarial pass. It confirmed the shipped fix — census clean at 24 pinned calls, whole-fence output identical under C and C.UTF-8 on every input built to separate them, and both fences byte-identical on a well-formed review carrying `café 東京` and `naïve résumé` — and then refuted the claim I made about the GUARD, not the feature. `/usr/bin/awk '/[[:space:]]/{exit}' < "$REVIEW_FILE"` passed the invariant. The preceding- character class shielded any match preceded by `/` or `.`, so a path-qualified call was invisible. A path-qualified call is still a call; the class no longer shields either. The substrings that motivated the exclusion are unaffected — `parsed`, `passed` and `awkward` have a word character on one side or the other, so the boundary still rejects them. **The rest of that finding is disclosed rather than fixed, deliberately.** `$AWK "$f"` and a command name computed inside the embedded `node -e` block also evade the check, and they are not closable by this mechanism: it scans text, not shell or JavaScript command structure. The same pass that found them showed that widening the regex further only trades those false negatives for false positives on quoted strings and awk program text. So the test now STATES its boundary instead of implying it has none — the previous comment claimed a census "a future edit cannot fool", which was exactly the kind of overclaim this round has been correcting. What it catches is enumerated there, driven, along with which direction its false answers go. Driven against the invariant alone, each mutation reporting its own substitution count: - `/usr/bin/awk ... < "$f"` (the exact evasion) -> reds; before this commit it did NOT - `env awk ... < "$f"` -> reds - `LC_ALL=C.UTF-8 awk ... < "$f"` (wrong pin) -> reds - unmodified tree -> green 241/241 across the two pipeline files, `npm run lint:ci` exits 0. No shipped behaviour changes in this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * test(#3829): stop the guard's comment promising a closed list of what it misses An eighth adversarial pass. It confirmed the delta was test-only and that both fences are byte-identical across it — exit, stdout, stderr and rendered ledger — and then refuted the comment again, with two more evasions: a command name fragmented in shell (`a''wk`), and an executable command substitution on a physical line starting with `#` inside a multiline quoted argument, which the comment exemption skips. Both are real. Neither is the point. Three passes running have each found one more evasion of a TEXT scan, which is the actual finding: **the list cannot be closed.** A comment that enumerates residuals is false the moment someone is cleverer than the enumeration, and fixing it by appending the newest example just resets the clock. So the comment no longer claims an inventory. It says what this is — a regression guard against the accident that has now happened twice in this round, a read added or edited without its pin in a file where every other read has one — and what it is not: a proof. The examples are marked as illustrations. The operative instruction is the one that survives any future evasion: treat anything it reports as real, and never treat its silence as proof a new read is pinned. No logic changed; the guard catches exactly what it caught before. 241/241 across the two pipeline files. `npm run lint:ci` exits 0 — after it caught this commit twice over, which is worth recording because both were in prose I had just written to be careful: - the previous message's example path `docs/grep.md` read as a genuine docs reference from this file, and lint-docs-guard-registration demanded a baseline entry for a path that does not exist. The illustration is now `bin/grep-wrapper`, and the reason is stated inline. - an earlier commit's `split('\n')` on readFileSync content tripped the CRLF-portability rule. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * test(#3829): the guard's two directions are not symmetric, so stop saying they are A ninth adversarial pass. It confirmed the delta before it was comment-only with the guard's logic byte-identical, and that all six advertised forms are still caught — and then found the one absolute the rewrite left behind. The comment said "treat anything this guard reports as real" three lines above admitting the guard produces loud false positives. Driven: `echo ok # grep is discussed` is reported, and labelled `(unpinned)`, though it is prose and no unpinned read exists. Both sentences were mine, in the same comment, written in the same edit that was supposed to remove overclaiming. The instruction is now the accurate one, which is that the two directions are NOT symmetric: a REPORT is cheap to adjudicate — read the line, a trailing comment or a path is obvious — while SILENCE proves nothing, because the known evasions are silent and so is any evasion nobody has thought of yet. Investigate every report; never read silence as proof a new read is pinned. Comment-only. Guard logic untouched, `gsd-core/` byte-identical to cac648aab — three consecutive passes have now confirmed the shipped behaviour unchanged. 241/241 across the two pipeline files, `npm run lint:ci` exits 0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * test(#3829): a report needs its context to adjudicate, not just its own line A tenth adversarial pass, and the last one this round runs. It confirmed `gsd-core/` is the SAME TREE OBJECT as at cac648aab (105b5ed9b) with the guard's caught and silent sets unchanged, and refuted one more sentence of the same comment. "A report is cheap to adjudicate (read the line)" is false, driven: the identical reported physical line ` grep` is a COMMAND after `:` and an ARGUMENT after `printf '%s\n' \`. The guard reports both, and the reported line alone does not distinguish them — the preceding line is what settles it. The comment now says so, with that counterexample in it. This is the fourth consecutive pass to find a defect in this one comment and none in the shipped code, which is itself the result worth recording: the shipped fix has been frozen since cac648aab and confirmed byte-identical by four passes, while the prose describing a best-effort text scanner took four attempts to stop overclaiming. Writing an accurate description of what a heuristic does NOT do turns out to be harder than the heuristic. Comment-only; guard logic untouched. 241/241 across the two pipeline files, `npm run lint:ci` exits 0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * test(#3829): re-home the lookup's phase-id gate beside the step, not in a block upstream removed #4781 (#4628) removed #4748's letter-axis work from `tests/nsegment-phase-grammar.test.cjs`, including the `#4748 — the REVIEW.md lookup` describe block. This PR had four tests living in that block, because that is where the gate was when #3829 moved the lookup out of `execute-phase.md` and into the lazily-read step file. Those four tests assert properties of THIS PR's step file, not of #4748's sites. Rebasing onto the removal would have deleted them silently — the branch would still be green, with its own coverage quietly gone. They move here instead, unchanged in substance, beside the step they guard: an unrelated upstream revert can no longer take this PR's coverage with it. One assertion did NOT come along. The old block also checked that `execute-phase.md`'s init parse list names `padded_phase`; #4781 removed that field from the list, and the assertion is a property of #4748's site rather than of this step. Carrying it here would only have pinned someone else's revert to this PR. The step never depended on that field in the first place — it computes PADDED itself, validating PHASE_NUMBER for shape and traversal and padding the digit run through `10#` while carrying an optional letter verbatim. That self-containment is why the removal costs this PR nothing but the tests' address. 5 pass, 0 fail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * chore(#3829): regenerate the derived artifacts the round-12 rebase invalidated The base moved from092d9256bto003d982c8(six merges) while this round was in flight, so the branch was rebased and the derived state had to be re-derived rather than hand-merged. `platform-conformance-tier.generated.cjs` regains `tests/configured-entrypoint-validation.test.cjs`, added upstream by #4249. Resolving the conflict hunk-by-hunk in favour of this branch had dropped that entry; `lint:generated-sync` caught it, which is what that check is for. `compact-content-benchmark-baseline.json` carries the measured values at the new base rather than this branch's stale pair: split "execute-phase" off 26200 -> 26242, on 23949 -> 23952 (8.59% -> 8.73%); aggregate off 108243 -> 108285, on 91595 -> 91598 (15.38% -> 15.41%). The benchmark reports drift and exits 0 either way, so a stale baseline does not announce itself here — it announces itself in CI. **The growth acknowledgment is back, and the reason is worth stating.** Against the previous base this PR left `execute-phase.md` a net -103 bytes: the extraction removed more than the dispatch paragraph added, so the file ended up smaller than the base's copy and the `Emitted-Drift-Ack-Growth` trailer became false and was dropped. #4781 then rewrote that file upstream, and against the new base the same extraction nets +36 bytes (93421 -> 93457) — which is the figure this PR originally reported at round 2. The size delta was never a property of this change alone; it is a property of this change against whichever base it sits on, and it has now been both signs in one round. The trailer was restored then. Round 14 rebased onto `029acd915`, where #4830's re-land moved `execute-phase.md` again and the same extraction is -103 once more (93564 -> 93461), so the trailer is false a second time and this commit no longer carries it. Third sign flip, same reason each time. `lint:generated-sync` and `benchmark-compact-content --check` both clean afterwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9qJPShuor4FqtZSX25jks * chore(#3829): regenerate derived artifacts after rebase onto next The rebase onto `c9a5cc3e1` conflicted in the 19 install-tree goldens. Those are generated, so they were resolved arbitrarily and regenerated with their own producers (`npm run regen:derived`, then `benchmark-compact-content.cjs --write`) rather than hand-merged — a clean textual merge of a generated file attests the merge, never the content. Reconciled per artifact against the base's own committed copy rather than against the pre-regen tree, because the pre-regen tree is the arbitrary resolution: - every install-tree golden now differs from `c9a5cc3e1`'s copy by exactly one entry, `gsd-core/workflows/execute-phase/steps/code-review-disposition.md`, which is this PR's own new step file; - the compact-content benchmark baseline by the `execute-phase` entry (offTokens 26184 -> 26167) and the aggregate that sums it. `docs/INVENTORY-MANIFEST.json` was in the at-risk set but regenerated byte-identical, so it carries no change here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJPv9LNaPV3Cd3NCpfFKGb * chore(#3829): regenerate derived artifacts after rebase onto029acd915The rebase onto current `next` conflicted in two generated files — the compact-content benchmark baseline and the platform conformance tier. Both were resolved arbitrarily and regenerated with their own producers (`npm run regen:derived`, then `benchmark-compact-content.cjs --write`) rather than hand-merged: a clean textual merge of a generated file attests the merge, never the content. Reconciled per artifact against the base's own committed copy rather than against the pre-regen tree, because the pre-regen tree is the arbitrary resolution. Every differing key belongs to a file this PR actually touches: - `tests/fixtures/install-tree/claude.json` differs from `029acd915`'s copy by exactly one entry, `gsd-core/workflows/execute-phase/steps/code-review-disposition.md`, this PR's own new step file; - `scripts/lib/platform-conformance-tier.generated.cjs` by exactly one entry, `tests/code-review-fix-pipeline-regression.test.cjs`, a test this PR adds; - `tests/fixtures/compact-content-benchmark-baseline.json` by the `execute-phase` entry (offTokens 26344 -> 26280) and the aggregate that sums it, which this PR moves by editing `execute-phase.md`. The other 18 install-tree goldens, `docs/FEATURES.md` and `docs/INVENTORY-MANIFEST.json` were regenerated too and came back byte-identical, so they carry no change here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nAJFVZcCZHtSgYmWM5WNP * test(#3829): follow #4748's REVIEW.md-lookup gate to the step that now owns the lookup Self-found while rebasing onto `029acd915`, not raised in review. #4830 (`8a5166598c`) re-landed #4768's letter-suffix work on `next`, restoring the `#4748 — execute-phase.md resolves the REVIEW.md path from init's padded_phase` block in `tests/nsegment-phase-grammar.test.cjs`. That block had been removed by #4781, which is why round 13 re-homed this PR's own four tests out of it. The restored block anchors on a line this PR deletes: expected 1 line(s) containing "REVIEW_FILE=\"${PHASE_DIR}/${PADDED}-REVIEW.md\"", found 0 It fails at the describe level, so all four of its tests go with it. It was green before this rebase only because the base did not carry the block yet. Putting the line back is not available. #3829 moved the lookup into the lazily-read step file because `execute-phase.md` did not fit under ADR-857's frozen pre-phase-6 ceiling (93600); the parent is at 93461, and the three lines this gate anchors on cost 183 (measured, not computed: `git show 029acd915:... | sed -n '1168,1170p' | wc -c`). The block would also be dead code — the step performs the lookup. So the gate follows the lookup. Two of its four assertions are properties of the lookup and are re-pointed at the step file: that no fence hands PHASE_NUMBER to `printf "%02d"`, and that both lookups are preceded by a PADDED binding that pads the digit run through `10#` and carries the letter verbatim. The regression control on the lookup line itself comes along, now over both fences. The init-parse-list assertion stays on `execute-phase.md`, which still names `padded_phase`. Two assertions do NOT come along, and they are the two that were properties of the INLINE site rather than of the lookup: the `PADDED="{padded_phase}"` literal binding (the step derives PADDED itself, validating PHASE_NUMBER for shape and traversal first), and the composition run over the three live lines. The step's executable coverage — a composition run plus a padding-agrees-with-the-canonical-normalizer matrix over letter ids — already exists in `tests/code-review-pipeline-regression.test.cjs` under "#3829 — the step's REVIEW.md lookup resolves a letter-suffixed phase without a shell re-pad". Mirroring it here would be a second implementation of one grammar. That coverage is NOT equivalent, and the difference is worth stating rather than glossing. At its original site #4748's gate was a DATAFLOW pin: `execute-phase.md` bound init's own `{padded_phase}`, so the lookup could not disagree with the canonical normalizer because it never computed anything. The step reconstructs the value in shell, so that pin is not available at this address and AGREEMENT with the normalizer is what replaces it. A follow-on commit adds a fast-check property asserting that agreement over generated ids, because the existing 13-shape matrix samples 2 of 26 letters and cannot see a divergence outside its own points. One consequence is disclosed rather than absorbed: `padded_phase` is now parsed but unused in `execute-phase.md` (`:95`). Removing it from that parse list is #4830's call on its own site, not this PR's, so the assertion that it is still named stays. #4748's property is unchanged: a letter-suffixed phase resolves its own REVIEW.md, and an already-padded `08` does not read as octal. Negative-controlled rather than asserted. Against the shipped step: 162 pass, 0 fail. Dropping `$_let` from both PADDED bindings reds "every lookup is preceded by a PADDED binding that carries the letter run"; dropping `10#` reds it too. The step file was restored byte-identical after each control. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nAJFVZcCZHtSgYmWM5WNP * test(#3829): assert the step's padding against the canonical normalizer by property, not by 13 points From this round's own pre-push adversarial review, not from the maintainer's. The prior commit re-points #4748's REVIEW.md-lookup gate at the step that now owns the lookup. The review's finding was that this is not coverage-equivalent, and it is right: at the original site the gate was a DATAFLOW pin — `execute-phase.md` bound init's own `{padded_phase}`, so the lookup could not disagree with the canonical normalizer because it never computed anything. The step reconstructs the value in shell, so agreement with the normalizer is what has to replace the pin. That agreement was already asserted, but over a 13-shape matrix. Its words: "future canonical grammar changes could therefore diverge without this gate detecting them." Correct — the matrix samples 2 of 26 letters and a bounded set of segment shapes, and this PR has twice been told that a generator which cannot reach the interesting input is a fixture with extra steps (round 3's SOURCE_CELL, round 5's title generator). Same defect, third address. So the agreement is now a property over generated ids: a digit run inside the step's own 8-digit bound, an optional single A-Z, and up to two dot segments, asserted equal to `normalizePhaseName(id)` through the shipped shell derivation of BOTH fences. Milestone `N-N` forms are outside the step's accepted domain and are asserted nowhere here rather than silently passed. Negative-controlled on two mutations, and the second is the one that justifies the property rather than the matrix: %02d -> %03d matrix RED, property RED drop the letter when outside {A,B} matrix GREEN, property RED The second is the added coverage, demonstrated rather than argued: the matrix is structurally unable to reach a letter it does not enumerate. The step file was restored byte-identical after each control. numRuns is 25 — each case spawns bash twice through the process seam, once per fence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nAJFVZcCZHtSgYmWM5WNP * fix(#3829): pad the phase id as a string, so the step agrees with the canonical normalizer Found by the property the previous commit added, on its second adversarial pass. This is a real divergence in shipped behaviour, not a test-only correction. `normalizePhaseName` (src/init.cts, via gsd-core/bin/lib/phase-id.cjs) left-pads a phase id's digit run to a MINIMUM of two and otherwise PRESERVES it — `padStart(2, '0')`. The step re-derived the same value arithmetically, `printf "%02d" "$((10#$_dig))"`, which does not preserve: it collapses every leading-zero run longer than two. id normalizePhaseName the step (before) 8 08 08 08 08 08 008 008 08 <-- diverges 0008 0008 08 <-- diverges 00000008 00000008 08 <-- diverges 0008A 0008A 08A <-- diverges Consequence: for such an id the gate resolves `08-REVIEW.md` while init emits `008-REVIEW.md`, so it finds no review and says so — advisory, and therefore silent. That is the failure class #4748 exists to close, reached by a different road: not a letter this time, but a leading-zero run. The fix is a string pad that implements `padStart(2, '0')` exactly, at both fences: case "${#_dig}" in 1) PADDED="0${_dig}${_let}${_sub}" ;; *) PADDED="${_dig}${_let}${_sub}" ;; esac It is strictly less machinery than what it replaces. `10#` existed only to stop bash reading a leading zero as octal inside `$(( ))`; with no arithmetic there is no octal hazard to guard, so the remedy is retired rather than kept. `scripts/lint-phase-id-drift.cjs` — which exists to flag unsanctioned `printf "%02d"` re-pads of phase-carrying variables — is green, and now has one less re-pad to tolerate. Two dependent assertions move with it, and both are now stated as the PROPERTY rather than as one spelling of the remedy: the round-14 gate in `tests/nsegment-phase-grammar.test.cjs` asserts the binding does no arithmetic and carries both `${_dig}` and `${_let}`, and the regression pin in `tests/code-review-pipeline-regression.test.cjs` follows the new form. The property's generator is widened in the same commit, because its first cut could not have found this: it built the digit run with `String(fc.integer(...))`, which can never produce a leading zero, so it had silently LOST the `08`/`09` coverage the 13-shape matrix beside it already had. The run is now generated as a digit string, and segment depth goes to four (the repo exercises `1.2.3.4`). The step's grammar is unbounded in depth; four is a stated bound, and it is this property's residual. Negative-controlled, and the matrix is the control's control — it stays GREEN on both: revert to the arithmetic pad matrix GREEN, property RED drop the letter when outside {A,B} matrix GREEN, property RED The step file was restored byte-identical after each. 407 pass / 0 fail across both test files; lint:ci, gen-features --check, gen-platform-conformance-tier --check, benchmark-compact-content --check and gen-install-tree-fixtures all clean, with no regenerated artifact moving. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nAJFVZcCZHtSgYmWM5WNP * test(#3829): hold #4748's gate by execution, and retire the comments the string pad made false Third adversarial pass on this round. Two findings, both fair, neither a correctness defect. FIRST — the gate pinned a SPELLING, not the property. Its objection was concrete: an equivalent multi-line string pad would have failed a regex that matches one `case ... esac` line. That is a false-positive generator, and a guard that false-fires is a guard that gets deleted. The split is now honest about what each layer can hold. A STATIC gate can hold the DEFECT SHAPE — no arithmetic in the binding above each lookup — and that is all it asserts. Correctness is held by EXECUTION: the base gate regains a composition test that runs the shipped derivation slice of both fences against `normalizePhaseName`, over `3A 8 9 08 008 0008A 23A.1.2`. That composition test is the one I removed two commits ago, and removing it was the weaker call. At #4748's ORIGINAL site the gate could be static because the property was a literal binding of init's own `{padded_phase}`; nothing could disagree, because nothing computed. At this site the step derives the value, so the property is behavioural and only execution holds it. `008` is in the list because it is the case the arithmetic pad got wrong and no prior fixture covered. Controlled three ways, and the middle one is the finding being answered: arithmetic pad restored 4 fail caught EQUIVALENT multi-line string pad 0 fail no false positive drop the letter outside {A,B} 1 fail semantic drift caught SECOND — the step carried comments the fix had made false, in four places. Two explained `10#` as part of the live phase derivation; two justified the eight-digit bound by bash integer overflow. Neither described the code any more. They are rewritten to current truth rather than annotated, because a fragment carries no supersession marker and overturned prose reads as canon: - the octal rationale now says the pad performs no arithmetic and needs no `10#`, and notes that `10#` survives in this step only on the severity COUNTS, which really are numbers being added; - the length bound now states that overflow is unreachable since the pad stopped converting, and that the bound stays for the reason it always also had — every component is interpolated into a filename, and filesystem components are finite. 408 pass / 0 fail across both files. lint:ci, lint-phase-id-drift, gen-features --check, gen-platform-conformance-tier --check, benchmark-compact-content --check and the prompt-injection-scan security suite are all clean, and no regenerated artifact moved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nAJFVZcCZHtSgYmWM5WNP * docs(#3829): correct four comments, including one this round's own rewrite got wrong Fourth adversarial pass. Comment-only; no code, no test logic, no regenerated artifact moves. ONE OF THESE IS MY OWN ERROR, introduced two commits ago. Rewriting the length-bound rationale, I replaced the dead integer-overflow justification with "the bound stays because every component is interpolated into a filename and filesystem components are finite". That is false, and it was driven false: the bound is PER SEGMENT, every segment is joined into ONE filename component, and depth is unbounded. Thirty 8-digit segments yield a 278-character PADDED and a 294-character name against a NAME_MAX of 255. Replacing a dead rationale with a wrong one is worse than leaving the dead one, so the comment now states what the bound actually does and names the composite-length gap as a residual of this validator that predates the pad change. It is not fixed here; it is stated. The other three are stale rather than wrong: - `overflow guard` named the length check in two places. Nothing overflows any more -- the pad does no arithmetic -- so it is the digit bound, and is called that. - The `#4748` block header in `tests/nsegment-phase-grammar.test.cjs` still said the step pads through `10#`, still said the composition run did not survive the move, and still said the executable coverage was "cited rather than copied" -- while the composition test sat twenty lines below it. All three were true when written and none survived this round. The header now records why a STATIC assertion cannot hold a BEHAVIOURAL property, and that the PR's fast-check property is a different instrument over the same contract rather than the same test twice. - The severity-count comment said a base-inference failure "takes the whole advisory step down under `set -e`". It does not: the arithmetic sits inside an `if` condition, a TESTED context, where `set -e` is inert, and the consistency check is SKIPPED instead -- which the regression suite already records. `10#` stays; only the account of what it prevents is corrected. This one predates the round and is corrected because it is adjacent and factually wrong, not because it blocked anything. 408 pass / 0 fail across both files; lint:ci, lint-phase-id-drift, gen-features --check, benchmark-compact-content --check and the prompt-injection-scan security suite all clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nAJFVZcCZHtSgYmWM5WNP * chore(#3829): regenerate the compact-content benchmark baseline after the rebase ontofac0e9de8The rebase onto current `next` conflicted on this generated fixture, as it has in every recent round: the base regenerates it for its own token deltas and this branch regenerates it for `execute-phase.md`'s, so both sides rewrite the same keys. Resolved arbitrarily during the replay and regenerated with its own producer (`scripts/benchmark-compact-content.cjs --write`), never hand-merged. Key-level drift against the base's committed copy is exactly two entries and both are this PR's own: `splits.execute-phase` (the workflow this PR edits) and `aggregate`, which is the sum over the splits and therefore moves whenever any split does. Zero foreign keys moved. The full generator sweep was re-run after the replay -- gen-features, gen-inventory-manifest, gen-platform-conformance-tier (both targets), gen-install-tree-fixtures and the benchmark -- and this fixture is the only artifact that moved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V5xnzzipRHPHq8Z3doQvn3 * chore(#3829): regenerate the compact-content benchmark baseline after the rebase ontob956bb7c6`next` moved again while this round was running -- #4902 landed at 06:27Z and touches this same generated fixture -- so the branch went back to CONFLICTING within minutes of the previous push. This is the second rebase of the round, not a correction of the first. Resolved arbitrarily during the replay and regenerated with its own producer (`scripts/benchmark-compact-content.cjs --write`), never hand-merged. Key-level drift against the new base's committed copy is again exactly `splits.execute-phase` and `aggregate` (the sum over splits) -- zero foreign keys. The full generator sweep was re-run after this replay as well; this fixture is the only artifact that moved. Build inputs were untouched by the base range, so the lane's existing build stands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V5xnzzipRHPHq8Z3doQvn3 * fix(#3829): refresh the launcher preamble in place, without hoisting it above the guard Found by this round's own post-rebase validity gate, not by review: a reader flip-test over the 85 tests that read the two at-risk workflow files was clean before the replay and failed after it, on `runtime-launcher-parity (#373)` invariant (B). The cause is a real interaction. #4902 landed on `next` mid-round and rewrote the canonical launcher preamble; invariant (B) counts occurrences of that exact snippet, so this step's older copy matched zero times even though it sat in the right place. The remedy the invariant names -- `node scripts/sync-runtime-launcher.cjs` -- fixes the count but also HOISTS the preamble to the top of the block, and that is wrong here: it moved the shim ahead of the status guard, and six of this PR's own tests exist to pin that ordering (`runDispositionGuard` asserts the block opens with its guard, then the shim). Running the tool verbatim turned one red into seven. So the preamble text is refreshed to the current canonical snippet IN PLACE, at the offset it already occupied. Both constraints hold at once, verified by execution rather than by reading: invariant (B) sees exactly one canonical occurrence and it precedes the first `gsd_run` call, while the guard still opens the block (shim at offset 19897 of the second fence, and the test wants > 0). `runtime-launcher-parity` + `code-review-pipeline-regression` together: 282 tests, 281 pass. Not fixed here, and not ours: `(K2) end-to-end: the resolved local tool honors git.allow_default_branch_commits (#4834)` -- the one remaining failure -- fails identically on a detached worktree at pristine `b956bb7c6` carrying none of this PR's content (37 tests, 36 pass, same single failure). Reported rather than chased. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V5xnzzipRHPHq8Z3doQvn3 * fix(#3829): record the shortfall when NO finding in a review parses Found by this round's own pre-push adversarial review, not by the maintainer -- and it is the same defect class round 2 raised as Blocker 4, surviving in the one corner that round's fix did not reach. The unparsed reconciliation exists so a finding the CR|BL|WR|IN heading parser cannot match is SURFACED rather than dropped. It reported faithfully whenever SOME findings parsed. It reported nothing at all when NONE did, on a phase with no prior ledger and no fix report: a REVIEW.md declaring two Criticals, both written under a prefix the alternation does not carry, produced no ledger, no console line and no diagnostic. That is precisely the silent drop this reconciliation was added to close, reachable exactly where the evidence is weakest -- the run in which not one finding was understood. Two exits discarded it, and the first one is the one that actually fired. The shortfall was derived beside the render, while the exit that stands down for "nothing to record" keys on order.length and sits ~200 lines earlier; it returned before the value existed. The later rows.length exit had the same hole but was unreachable for this input. So the derivation moves above the earlier exit -- order is final from the heading walk and never grows again, so the value is unchanged -- and both exits now decline to fire while a shortfall is outstanding. The result is a zero-row ledger carrying an unparsed key: an honest record that the review declared findings and none of them were understood, which is strictly better than the file not existing. Scoped, not removed. A genuinely clean review is untouched: a declared total of 0 is not greater than order.length, so unparsed is 0 and both returns still fire exactly as before. The new test's companion pins that, and it is why the exit was relaxed conditionally rather than deleted. Driven at every step rather than reasoned about. Before the fix, three cases through the shipped script: two unmatched findings on a first run wrote NOTHING; two unmatched plus one matched reported unparsed: 1; two unmatched against an existing ledger reported unparsed: 2. Only the first was silent, which is why the mechanism read as covered. After the fix the first renders a ledger with unparsed: 2 and names it on the console, and the other two are byte-unchanged. The new regression test was negative-controlled against the pre-fix step file and goes red there (1 pass / 1 fail over the pair); post-fix both pass. Its companion clean-review control is green on both sides, so the pair is not passing by accident. The PR's six test files: 554 tests, 554 pass, 0 fail, 0 skipped. lint:ci exits 0. The generator sweep still produces no drift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfaJkgoq87837ZqWtTxqqn * test(#3829): pin the SECOND exit that discarded the shortfall, and prove the pair kills it Self-found by the round review of the previous commit, not by the maintainer: that commit added the !unparsed conjunct to BOTH exits but tested only one of them. Deleting the later one left every new test green -- a surviving mutant, which is coverage in name only. The two exits are reached by different inputs, which is why one fixture cannot pin both. The earlier exit stands down the moment a fix report exists, so an input carrying one sails past it and lands on the later rows.length return. The fixture therefore needs a fix report that contributes NO row: an id the alternation CAN match becomes a carried row, rows.length is 1, and the later guard never decides. The first draft of this test used CR-99 and was vacuous for exactly that reason -- it passed with the guard deleted. It names SEC-03 now. Mutation-controlled in all three directions, since a test that kills no mutant pins nothing: earlier exit loses !unparsed -> test 1 RED, test 2 green, test 3 green later exit loses !unparsed -> test 1 RED, test 2 RED, test 3 green both exits neutered (over-fire)-> test 1 green,test 2 green, test 3 RED unmutated -> all three green Every test kills at least one mutant and no mutant survives all three, so the pair covers both roads to the drop and the clean-review control covers the over-fire the relaxation could have introduced. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfaJkgoq87837ZqWtTxqqn * test(#3829): close the fourth cell — the later exit's own over-fire Self-found again by the round review, which drove the mutant set rather than trusting the matrix the previous commit asserted: neutering ONLY the later exit survived all three tests. The previous commit's matrix was accurate and incomplete, which is the more dangerous shape -- it reads as a closed argument. The guards form a 2x2 and only three cells were pinned. T1 pins the earlier exit's under-fire, T2 the later exit's under-fire, T3 the earlier exit's over-fire. Nothing pinned the LATER exit's own over-fire, and it is reachable: a fix report -- even one naming no matchable id -- makes the earlier exit stand down, so control arrives at the later exit carrying a genuinely clean review and no shortfall. Neuter that exit and a phase with nothing to report grows a zero-row ledger reading "0 of 0 finding(s) open", with all three earlier tests green through it. T4 is that case. Five mutants driven over the four tests: earlier exit loses !unparsed -> T1 RED later exit loses !unparsed -> T1 RED, T2 RED both exits -> if(false) -> T3 RED, T4 RED ONLY later exit -> if(false) -> T4 RED (the survivor this commit kills) ONLY earlier exit -> if(false) -> all four green The last one is reported as an EQUIVALENT mutant rather than an open cell, and the distinction is the point of stating it: the earlier exit's over-fire condition is a strict subset of the later exit's -- it adds only fixReports.length === 0 -- so removing it is subsumed and changes no observable behaviour. A test cannot kill a mutant that does not alter output, and pretending otherwise would mean writing one that asserts on internals. The PR's six test files: 556 tests, 556 pass, 0 fail, 0 skipped. lint:ci exits 0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfaJkgoq87837ZqWtTxqqn * fix(#3829): keep the embedded record-builder inside a Windows command line Block 2 runs the disposition record-builder as `node -e "<script>"`, so the entire script is a single argv entry. Windows caps a command line at 32767 characters (CreateProcess) and Node surfaces the overflow as ENAMETOOLONG from spawn -- the process never starts. Linux's ~2 MB ARG_MAX cannot see that cliff at all. The previous fix (bd83bc88e, hoisting the shortfall derivation above the earlier exit) grew the extracted script from 31941 to 33353 characters. There were 826 characters of headroom; it spent 1412. On the next CI run ubuntu and macOS stayed green and `conformance test (windows-latest, 24, shard 1/3)` went red with 83 failures -- 79 reporting `spawn_failed` out of runShippedDisposition, the other 4 asserting on a ledger that was never written. That same shard was SUCCESS at 596968aa0, the head before that commit. Measured on native Windows (node v25.2.1), bisected: the largest `-e` argument that still spawns is 32728 characters; 32729 fails. Both payloads driven directly: pre-fix 33353 chars -> SPAWN-FAIL ENAMETOOLONG post-fix 15916 chars -> SPAWN-OK Note the shape of it: the fix that makes this gate report a silently-dropped finding was itself silently dropped on Windows, because the whole script stopped launching. What changes here is placement -- not content, not behaviour. 17 long rationale comment blocks move out of the quoted payload into a new "Design notes for the embedded record-builder" section in this file's prose, each anchored to the code line it preceded so the pairing survives the move. Comment runs shorter than five lines stay inline, where adjacency is cheap. Nothing is deleted. extracted script 33353 -> 15916 chars (16812 under the measured limit) executable code byte-identical at 10853 bytes, verified by diffing the payload with all comment lines stripped from both sides this file 78542 -> 79538 bytes -- the prose moved, it did not grow Verified green: this PR's own test file at 250 tests across all 36 suites, 0 fail; changeset-lint, docs-lint, default-flip-documentation, lint:ci, gen-emitted-baseline, workflow-size-budget (133 tests), and lint-workflow-shellcheck (204 pre-existing findings, 0 new). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfaJkgoq87837ZqWtTxqqn * test(#3829): pin the embedded script under the Windows command-line budget Nothing guarded the size of the `node -e` payload, so the regression the previous commit fixes was invisible to every Linux gate and surfaced only as 83 Windows failures that said `spawn_failed` and never mentioned length. Without a guard the next addition to the script re-breaks Windows exactly the same way, and finds out the same expensive way. The test asserts the extracted script stays under a 24 KiB budget -- the 32767 CreateProcess cap less roughly 8 KiB of deliberate headroom, so the script has somewhere to grow before this fires. It is bounded from BELOW as well, and that half is the point: a pure length assertion passes when the extractor returns '', which is exactly what a moved fence or a renamed delimiter would produce. A guard that reports a comfortable 0 bytes is the vacuous-oracle shape. The lower bound makes a broken extractor fail loudly here instead of reporting success. Negative-controlled rather than assumed. Against the PRE-fix step file the test goes red on the real payload (33353 > 24576); against the fixed file it passes at 15916. A new test that has only ever been run against fixed code can be green because it hit a branch the bug never lived on. This PR's own test file: 250 tests, 250 pass, 0 fail, 0 skipped, across all 36 suites. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfaJkgoq87837ZqWtTxqqn * test(#3829): say what the command-line guard does not prove The round review's MISSED, adopted. The guard counts the extracted JavaScript, but the 32767 cap applies to the whole serialized command line -- executable path, quoting and backslash escaping included -- so a quote-heavy payload expands on the way out, and the 32728 figure it cites is one host's measured threshold rather than the CI runner's. The budget is unchanged and still correct; only the claim around it moves. 24576 leaves roughly 8 KiB for both effects, which is a practical margin, not a proof that everything the guard admits will spawn. Stating that in the test is cheaper than having a future reader infer a guarantee the assertion cannot make. Comment-only. No assertion, no budget and no behaviour changes. This PR's own test file: 221 tests, 0 fail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfaJkgoq87837ZqWtTxqqn --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Tom Boucher <trekkie@nomorestars.com>
713 lines
32 KiB
JSON
713 lines
32 KiB
JSON
[
|
|
".gsd-profile",
|
|
"agents/gsd-advisor-researcher.compact.md",
|
|
"agents/gsd-advisor-researcher.md",
|
|
"agents/gsd-ai-researcher.compact.md",
|
|
"agents/gsd-ai-researcher.md",
|
|
"agents/gsd-assumptions-analyzer.compact.md",
|
|
"agents/gsd-assumptions-analyzer.md",
|
|
"agents/gsd-code-fixer.compact.md",
|
|
"agents/gsd-code-fixer.md",
|
|
"agents/gsd-code-reviewer.compact.md",
|
|
"agents/gsd-code-reviewer.md",
|
|
"agents/gsd-codebase-mapper.compact.md",
|
|
"agents/gsd-codebase-mapper.md",
|
|
"agents/gsd-debug-session-manager.compact.md",
|
|
"agents/gsd-debug-session-manager.md",
|
|
"agents/gsd-debugger.md",
|
|
"agents/gsd-doc-classifier.compact.md",
|
|
"agents/gsd-doc-classifier.md",
|
|
"agents/gsd-doc-synthesizer.compact.md",
|
|
"agents/gsd-doc-synthesizer.md",
|
|
"agents/gsd-doc-verifier.compact.md",
|
|
"agents/gsd-doc-verifier.md",
|
|
"agents/gsd-doc-writer.compact.md",
|
|
"agents/gsd-doc-writer.md",
|
|
"agents/gsd-dom-verifier.compact.md",
|
|
"agents/gsd-dom-verifier.md",
|
|
"agents/gsd-domain-researcher.compact.md",
|
|
"agents/gsd-domain-researcher.md",
|
|
"agents/gsd-eval-auditor.compact.md",
|
|
"agents/gsd-eval-auditor.md",
|
|
"agents/gsd-eval-planner.compact.md",
|
|
"agents/gsd-eval-planner.md",
|
|
"agents/gsd-executor.md",
|
|
"agents/gsd-framework-selector.compact.md",
|
|
"agents/gsd-framework-selector.md",
|
|
"agents/gsd-integration-checker.compact.md",
|
|
"agents/gsd-integration-checker.md",
|
|
"agents/gsd-intel-updater.compact.md",
|
|
"agents/gsd-intel-updater.md",
|
|
"agents/gsd-mempalace-curator.compact.md",
|
|
"agents/gsd-mempalace-curator.md",
|
|
"agents/gsd-nyquist-auditor.compact.md",
|
|
"agents/gsd-nyquist-auditor.md",
|
|
"agents/gsd-pattern-mapper.compact.md",
|
|
"agents/gsd-pattern-mapper.md",
|
|
"agents/gsd-phase-researcher.md",
|
|
"agents/gsd-plan-checker.md",
|
|
"agents/gsd-planner.md",
|
|
"agents/gsd-project-researcher.compact.md",
|
|
"agents/gsd-project-researcher.md",
|
|
"agents/gsd-research-synthesizer.compact.md",
|
|
"agents/gsd-research-synthesizer.md",
|
|
"agents/gsd-roadmapper.compact.md",
|
|
"agents/gsd-roadmapper.md",
|
|
"agents/gsd-security-auditor.compact.md",
|
|
"agents/gsd-security-auditor.md",
|
|
"agents/gsd-ui-auditor.compact.md",
|
|
"agents/gsd-ui-auditor.md",
|
|
"agents/gsd-ui-checker.compact.md",
|
|
"agents/gsd-ui-checker.md",
|
|
"agents/gsd-ui-researcher.compact.md",
|
|
"agents/gsd-ui-researcher.md",
|
|
"agents/gsd-user-profiler.compact.md",
|
|
"agents/gsd-user-profiler.md",
|
|
"agents/gsd-verifier.md",
|
|
"gsd-core/.gsd-runtime",
|
|
"gsd-core/VERSION",
|
|
"gsd-core/agents/gsd-advisor-researcher.compact.md",
|
|
"gsd-core/agents/gsd-advisor-researcher.md",
|
|
"gsd-core/agents/gsd-ai-researcher.compact.md",
|
|
"gsd-core/agents/gsd-ai-researcher.md",
|
|
"gsd-core/agents/gsd-assumptions-analyzer.compact.md",
|
|
"gsd-core/agents/gsd-assumptions-analyzer.md",
|
|
"gsd-core/agents/gsd-code-fixer.compact.md",
|
|
"gsd-core/agents/gsd-code-fixer.md",
|
|
"gsd-core/agents/gsd-code-reviewer.compact.md",
|
|
"gsd-core/agents/gsd-code-reviewer.md",
|
|
"gsd-core/agents/gsd-codebase-mapper.compact.md",
|
|
"gsd-core/agents/gsd-codebase-mapper.md",
|
|
"gsd-core/agents/gsd-debug-session-manager.compact.md",
|
|
"gsd-core/agents/gsd-debug-session-manager.md",
|
|
"gsd-core/agents/gsd-debugger.md",
|
|
"gsd-core/agents/gsd-doc-classifier.compact.md",
|
|
"gsd-core/agents/gsd-doc-classifier.md",
|
|
"gsd-core/agents/gsd-doc-synthesizer.compact.md",
|
|
"gsd-core/agents/gsd-doc-synthesizer.md",
|
|
"gsd-core/agents/gsd-doc-verifier.compact.md",
|
|
"gsd-core/agents/gsd-doc-verifier.md",
|
|
"gsd-core/agents/gsd-doc-writer.compact.md",
|
|
"gsd-core/agents/gsd-doc-writer.md",
|
|
"gsd-core/agents/gsd-dom-verifier.compact.md",
|
|
"gsd-core/agents/gsd-dom-verifier.md",
|
|
"gsd-core/agents/gsd-domain-researcher.compact.md",
|
|
"gsd-core/agents/gsd-domain-researcher.md",
|
|
"gsd-core/agents/gsd-eval-auditor.compact.md",
|
|
"gsd-core/agents/gsd-eval-auditor.md",
|
|
"gsd-core/agents/gsd-eval-planner.compact.md",
|
|
"gsd-core/agents/gsd-eval-planner.md",
|
|
"gsd-core/agents/gsd-executor.md",
|
|
"gsd-core/agents/gsd-framework-selector.compact.md",
|
|
"gsd-core/agents/gsd-framework-selector.md",
|
|
"gsd-core/agents/gsd-integration-checker.compact.md",
|
|
"gsd-core/agents/gsd-integration-checker.md",
|
|
"gsd-core/agents/gsd-intel-updater.compact.md",
|
|
"gsd-core/agents/gsd-intel-updater.md",
|
|
"gsd-core/agents/gsd-mempalace-curator.compact.md",
|
|
"gsd-core/agents/gsd-mempalace-curator.md",
|
|
"gsd-core/agents/gsd-nyquist-auditor.compact.md",
|
|
"gsd-core/agents/gsd-nyquist-auditor.md",
|
|
"gsd-core/agents/gsd-pattern-mapper.compact.md",
|
|
"gsd-core/agents/gsd-pattern-mapper.md",
|
|
"gsd-core/agents/gsd-phase-researcher.md",
|
|
"gsd-core/agents/gsd-plan-checker.md",
|
|
"gsd-core/agents/gsd-planner.md",
|
|
"gsd-core/agents/gsd-project-researcher.compact.md",
|
|
"gsd-core/agents/gsd-project-researcher.md",
|
|
"gsd-core/agents/gsd-research-synthesizer.compact.md",
|
|
"gsd-core/agents/gsd-research-synthesizer.md",
|
|
"gsd-core/agents/gsd-roadmapper.compact.md",
|
|
"gsd-core/agents/gsd-roadmapper.md",
|
|
"gsd-core/agents/gsd-security-auditor.compact.md",
|
|
"gsd-core/agents/gsd-security-auditor.md",
|
|
"gsd-core/agents/gsd-ui-auditor.compact.md",
|
|
"gsd-core/agents/gsd-ui-auditor.md",
|
|
"gsd-core/agents/gsd-ui-checker.compact.md",
|
|
"gsd-core/agents/gsd-ui-checker.md",
|
|
"gsd-core/agents/gsd-ui-researcher.compact.md",
|
|
"gsd-core/agents/gsd-ui-researcher.md",
|
|
"gsd-core/agents/gsd-user-profiler.compact.md",
|
|
"gsd-core/agents/gsd-user-profiler.md",
|
|
"gsd-core/agents/gsd-verifier.md",
|
|
"gsd-core/bin/check-latest-version.cjs",
|
|
"gsd-core/bin/ensure-runtime-build.cjs",
|
|
"gsd-core/bin/gsd-tools.cjs",
|
|
"gsd-core/bin/gsd_run",
|
|
"gsd-core/bin/shared/config-defaults.manifest.json",
|
|
"gsd-core/bin/shared/config-schema.manifest.json",
|
|
"gsd-core/bin/shared/exit-codes.json",
|
|
"gsd-core/bin/shared/exit-codes.sh",
|
|
"gsd-core/bin/shared/model-catalog.json",
|
|
"gsd-core/bin/shared/runtime-aliases.manifest.json",
|
|
"gsd-core/bin/verify-reapply-patches.cjs",
|
|
"gsd-core/commands/gsd/add-tests.md",
|
|
"gsd-core/commands/gsd/ai-integration-phase.md",
|
|
"gsd-core/commands/gsd/audit-fix.md",
|
|
"gsd-core/commands/gsd/audit-milestone.md",
|
|
"gsd-core/commands/gsd/audit-uat.md",
|
|
"gsd-core/commands/gsd/autonomous.md",
|
|
"gsd-core/commands/gsd/capture.md",
|
|
"gsd-core/commands/gsd/cleanup.md",
|
|
"gsd-core/commands/gsd/code-review.md",
|
|
"gsd-core/commands/gsd/complete-milestone.md",
|
|
"gsd-core/commands/gsd/config.md",
|
|
"gsd-core/commands/gsd/debug.md",
|
|
"gsd-core/commands/gsd/discuss-phase.md",
|
|
"gsd-core/commands/gsd/docs-update.md",
|
|
"gsd-core/commands/gsd/eval-review.md",
|
|
"gsd-core/commands/gsd/execute-phase.md",
|
|
"gsd-core/commands/gsd/explore.md",
|
|
"gsd-core/commands/gsd/extract-learnings.md",
|
|
"gsd-core/commands/gsd/fast.md",
|
|
"gsd-core/commands/gsd/forensics.md",
|
|
"gsd-core/commands/gsd/graphify.md",
|
|
"gsd-core/commands/gsd/health.md",
|
|
"gsd-core/commands/gsd/help.md",
|
|
"gsd-core/commands/gsd/import.md",
|
|
"gsd-core/commands/gsd/inbox.md",
|
|
"gsd-core/commands/gsd/ingest-docs.md",
|
|
"gsd-core/commands/gsd/manager.md",
|
|
"gsd-core/commands/gsd/map-codebase.md",
|
|
"gsd-core/commands/gsd/mempalace-capture.md",
|
|
"gsd-core/commands/gsd/mempalace-recall.md",
|
|
"gsd-core/commands/gsd/milestone-summary.md",
|
|
"gsd-core/commands/gsd/mvp-phase.md",
|
|
"gsd-core/commands/gsd/new-milestone.md",
|
|
"gsd-core/commands/gsd/new-project.md",
|
|
"gsd-core/commands/gsd/next.md",
|
|
"gsd-core/commands/gsd/ns-context.md",
|
|
"gsd-core/commands/gsd/ns-ideate.md",
|
|
"gsd-core/commands/gsd/ns-manage.md",
|
|
"gsd-core/commands/gsd/ns-project.md",
|
|
"gsd-core/commands/gsd/ns-review.md",
|
|
"gsd-core/commands/gsd/ns-workflow.md",
|
|
"gsd-core/commands/gsd/onboard.md",
|
|
"gsd-core/commands/gsd/pause-work.md",
|
|
"gsd-core/commands/gsd/phase.md",
|
|
"gsd-core/commands/gsd/plan-phase.md",
|
|
"gsd-core/commands/gsd/plan-review-convergence.md",
|
|
"gsd-core/commands/gsd/pr-branch.md",
|
|
"gsd-core/commands/gsd/profile-user.md",
|
|
"gsd-core/commands/gsd/progress.md",
|
|
"gsd-core/commands/gsd/quick-batch.md",
|
|
"gsd-core/commands/gsd/quick.md",
|
|
"gsd-core/commands/gsd/resume-work.md",
|
|
"gsd-core/commands/gsd/review-backlog.md",
|
|
"gsd-core/commands/gsd/review.md",
|
|
"gsd-core/commands/gsd/secure-phase.md",
|
|
"gsd-core/commands/gsd/settings.md",
|
|
"gsd-core/commands/gsd/ship.md",
|
|
"gsd-core/commands/gsd/sketch.md",
|
|
"gsd-core/commands/gsd/spec-phase.md",
|
|
"gsd-core/commands/gsd/spike.md",
|
|
"gsd-core/commands/gsd/stats.md",
|
|
"gsd-core/commands/gsd/surface.md",
|
|
"gsd-core/commands/gsd/thread.md",
|
|
"gsd-core/commands/gsd/ui-phase.md",
|
|
"gsd-core/commands/gsd/ui-review.md",
|
|
"gsd-core/commands/gsd/ultraplan-phase.md",
|
|
"gsd-core/commands/gsd/undo.md",
|
|
"gsd-core/commands/gsd/update.md",
|
|
"gsd-core/commands/gsd/validate-phase.md",
|
|
"gsd-core/commands/gsd/verify-work.md",
|
|
"gsd-core/commands/gsd/workspace.md",
|
|
"gsd-core/commands/gsd/workstreams.md",
|
|
"gsd-core/contexts/dev.md",
|
|
"gsd-core/contexts/research.md",
|
|
"gsd-core/contexts/review.md",
|
|
"gsd-core/references/agent-contracts.md",
|
|
"gsd-core/references/agent-skills-bootstrap.md",
|
|
"gsd-core/references/ai-evals.md",
|
|
"gsd-core/references/ai-frameworks.md",
|
|
"gsd-core/references/api-coverage.md",
|
|
"gsd-core/references/artifact-types.md",
|
|
"gsd-core/references/autonomous-smart-discuss.md",
|
|
"gsd-core/references/autonomous-ui-design-contract.md",
|
|
"gsd-core/references/checkpoints.md",
|
|
"gsd-core/references/common-bug-patterns.md",
|
|
"gsd-core/references/compact-content-gate.md",
|
|
"gsd-core/references/context-budget.md",
|
|
"gsd-core/references/continuation-format.md",
|
|
"gsd-core/references/debugger-bug-taxonomy.md",
|
|
"gsd-core/references/debugger-fix-acceptance.md",
|
|
"gsd-core/references/debugger-philosophy.md",
|
|
"gsd-core/references/debugger-prevention.md",
|
|
"gsd-core/references/debugger-rca-branching.md",
|
|
"gsd-core/references/debugger-repro-hardening.md",
|
|
"gsd-core/references/debugger-sbfl.md",
|
|
"gsd-core/references/debugger-semantic-recall.md",
|
|
"gsd-core/references/debugger-techniques.md",
|
|
"gsd-core/references/decimal-phase-calculation.md",
|
|
"gsd-core/references/dispatch-isolation-gate.md",
|
|
"gsd-core/references/doc-conflict-engine.md",
|
|
"gsd-core/references/domain-probes.md",
|
|
"gsd-core/references/edge-probe-fixtures/01-round-half-even/expected-coverage.json",
|
|
"gsd-core/references/edge-probe-fixtures/01-round-half-even/requirements.json",
|
|
"gsd-core/references/edge-probe-fixtures/02-merge-intervals/expected-coverage.json",
|
|
"gsd-core/references/edge-probe-fixtures/02-merge-intervals/requirements.json",
|
|
"gsd-core/references/edge-probe-fixtures/03-truncate-graphemes/expected-coverage.json",
|
|
"gsd-core/references/edge-probe-fixtures/03-truncate-graphemes/requirements.json",
|
|
"gsd-core/references/edge-probe-fixtures/04-money-rounding/expected-coverage.json",
|
|
"gsd-core/references/edge-probe-fixtures/04-money-rounding/requirements.json",
|
|
"gsd-core/references/edge-probe-fixtures/05-list-dedupe/expected-coverage.json",
|
|
"gsd-core/references/edge-probe-fixtures/05-list-dedupe/requirements.json",
|
|
"gsd-core/references/edge-probe-fixtures/06-resolved-mixed/expected-coverage.json",
|
|
"gsd-core/references/edge-probe-fixtures/06-resolved-mixed/requirements.json",
|
|
"gsd-core/references/edge-probe-fixtures/06-resolved-mixed/resolutions.json",
|
|
"gsd-core/references/edge-probe.md",
|
|
"gsd-core/references/execute-mvp-tdd.md",
|
|
"gsd-core/references/execute-phase-between-wave-reset.md",
|
|
"gsd-core/references/execute-phase-context-guard.md",
|
|
"gsd-core/references/execute-phase-quota-recovery.md",
|
|
"gsd-core/references/execute-phase-requirement-revert.md",
|
|
"gsd-core/references/execute-phase-response-language.md",
|
|
"gsd-core/references/execute-phase-wave-guard.md",
|
|
"gsd-core/references/executor-examples.md",
|
|
"gsd-core/references/failing-direction.md",
|
|
"gsd-core/references/few-shot-examples/plan-checker.md",
|
|
"gsd-core/references/few-shot-examples/verifier.md",
|
|
"gsd-core/references/gate-prompts.md",
|
|
"gsd-core/references/gates.md",
|
|
"gsd-core/references/git-integration.md",
|
|
"gsd-core/references/git-planning-commit.md",
|
|
"gsd-core/references/gsd-run-resolver.md",
|
|
"gsd-core/references/honest-verifier.md",
|
|
"gsd-core/references/ios-scaffold.md",
|
|
"gsd-core/references/loop-hook-dispatch.md",
|
|
"gsd-core/references/mandatory-initial-read.md",
|
|
"gsd-core/references/model-profile-resolution.md",
|
|
"gsd-core/references/model-profiles.md",
|
|
"gsd-core/references/mvp-concepts.md",
|
|
"gsd-core/references/nyquist-compliance.md",
|
|
"gsd-core/references/offer-next.md",
|
|
"gsd-core/references/phase-argument-parsing.md",
|
|
"gsd-core/references/phase-id-convention.md",
|
|
"gsd-core/references/plan-checker-examples.md",
|
|
"gsd-core/references/planner-antipatterns.md",
|
|
"gsd-core/references/planner-chunked.md",
|
|
"gsd-core/references/planner-coupling.md",
|
|
"gsd-core/references/planner-failing-direction.md",
|
|
"gsd-core/references/planner-gap-closure.md",
|
|
"gsd-core/references/planner-graphify-auto-update.md",
|
|
"gsd-core/references/planner-guidance.md",
|
|
"gsd-core/references/planner-human-verify-mode.md",
|
|
"gsd-core/references/planner-interface-context.md",
|
|
"gsd-core/references/planner-load-graph-context.md",
|
|
"gsd-core/references/planner-mvp-mode.md",
|
|
"gsd-core/references/planner-preconditions.md",
|
|
"gsd-core/references/planner-quick-batch.md",
|
|
"gsd-core/references/planner-reversibility.md",
|
|
"gsd-core/references/planner-reviews.md",
|
|
"gsd-core/references/planner-revision.md",
|
|
"gsd-core/references/planner-source-audit.md",
|
|
"gsd-core/references/planner-verify-command-grounding.md",
|
|
"gsd-core/references/planning-config.md",
|
|
"gsd-core/references/prohibition-probe-fixtures/01-streak-reminder/expected.json",
|
|
"gsd-core/references/prohibition-probe-fixtures/02-clean-utility/expected.json",
|
|
"gsd-core/references/prohibition-probe-fixtures/03-multi-prohibition/expected.json",
|
|
"gsd-core/references/prohibition-probe.md",
|
|
"gsd-core/references/project-skills-discovery.md",
|
|
"gsd-core/references/questioning.md",
|
|
"gsd-core/references/research-documentation-lookup.md",
|
|
"gsd-core/references/research-philosophy.md",
|
|
"gsd-core/references/research-verification-protocol.md",
|
|
"gsd-core/references/response-language-directive.md",
|
|
"gsd-core/references/reviewer-instances.md",
|
|
"gsd-core/references/revision-loop.md",
|
|
"gsd-core/references/runtime-aware-dispatch.md",
|
|
"gsd-core/references/scout-codebase.md",
|
|
"gsd-core/references/security-asvs-levels.md",
|
|
"gsd-core/references/skeleton-template.md",
|
|
"gsd-core/references/sketch-interactivity.md",
|
|
"gsd-core/references/sketch-theme-system.md",
|
|
"gsd-core/references/sketch-tooling.md",
|
|
"gsd-core/references/sketch-variant-patterns.md",
|
|
"gsd-core/references/specless-probe-fallback.md",
|
|
"gsd-core/references/spidr-splitting.md",
|
|
"gsd-core/references/tdd.md",
|
|
"gsd-core/references/thinking-models-debug.md",
|
|
"gsd-core/references/thinking-models-execution.md",
|
|
"gsd-core/references/thinking-models-planning.md",
|
|
"gsd-core/references/thinking-models-research.md",
|
|
"gsd-core/references/thinking-models-verification.md",
|
|
"gsd-core/references/thinking-partner.md",
|
|
"gsd-core/references/ui-brand.md",
|
|
"gsd-core/references/ui-consideration-probe.md",
|
|
"gsd-core/references/universal-anti-patterns.md",
|
|
"gsd-core/references/untrusted-input-boundary.md",
|
|
"gsd-core/references/user-profiling.md",
|
|
"gsd-core/references/user-story-template.md",
|
|
"gsd-core/references/verification-overrides.md",
|
|
"gsd-core/references/verification-patterns.md",
|
|
"gsd-core/references/verifier-evidence-gate.md",
|
|
"gsd-core/references/verifier-phase-gates.md",
|
|
"gsd-core/references/verifier-wiring-patterns.md",
|
|
"gsd-core/references/verify-command-path-resolvability.md",
|
|
"gsd-core/references/verify-mvp-mode.md",
|
|
"gsd-core/references/workstream-flag.md",
|
|
"gsd-core/references/worktree-branch-check.md",
|
|
"gsd-core/references/worktree-path-safety.md",
|
|
"gsd-core/templates/AI-SPEC.md",
|
|
"gsd-core/templates/DEBUG.md",
|
|
"gsd-core/templates/README.md",
|
|
"gsd-core/templates/SECURITY.md",
|
|
"gsd-core/templates/UAT.md",
|
|
"gsd-core/templates/UI-SPEC.md",
|
|
"gsd-core/templates/VALIDATION.md",
|
|
"gsd-core/templates/codebase/architecture.md",
|
|
"gsd-core/templates/codebase/stack.md",
|
|
"gsd-core/templates/config.json",
|
|
"gsd-core/templates/context.md",
|
|
"gsd-core/templates/continue-here.md",
|
|
"gsd-core/templates/copilot-instructions.md",
|
|
"gsd-core/templates/dev-preferences.md",
|
|
"gsd-core/templates/discussion-log.md",
|
|
"gsd-core/templates/milestone-archive.md",
|
|
"gsd-core/templates/milestone.md",
|
|
"gsd-core/templates/phase-prompt.md",
|
|
"gsd-core/templates/planner-subagent-prompt.md",
|
|
"gsd-core/templates/project.md",
|
|
"gsd-core/templates/requirements.md",
|
|
"gsd-core/templates/research-project/ARCHITECTURE.md",
|
|
"gsd-core/templates/research-project/FEATURES.md",
|
|
"gsd-core/templates/research-project/PITFALLS.md",
|
|
"gsd-core/templates/research-project/STACK.md",
|
|
"gsd-core/templates/research-project/SUMMARY.md",
|
|
"gsd-core/templates/research.md",
|
|
"gsd-core/templates/retrospective.md",
|
|
"gsd-core/templates/roadmap.md",
|
|
"gsd-core/templates/spec.md",
|
|
"gsd-core/templates/state.md",
|
|
"gsd-core/templates/summary-complex.md",
|
|
"gsd-core/templates/summary-minimal.md",
|
|
"gsd-core/templates/summary-standard.md",
|
|
"gsd-core/templates/summary.compact.md",
|
|
"gsd-core/templates/summary.md",
|
|
"gsd-core/templates/user-profile.md",
|
|
"gsd-core/templates/user-setup.compact.md",
|
|
"gsd-core/templates/user-setup.md",
|
|
"gsd-core/templates/verification-report.md",
|
|
"gsd-core/workflows/_runtime-launcher.snippet.sh",
|
|
"gsd-core/workflows/add-backlog.md",
|
|
"gsd-core/workflows/add-phase.md",
|
|
"gsd-core/workflows/add-tests.md",
|
|
"gsd-core/workflows/add-todo.md",
|
|
"gsd-core/workflows/ai-integration-phase.md",
|
|
"gsd-core/workflows/analyze-dependencies.md",
|
|
"gsd-core/workflows/audit-fix.md",
|
|
"gsd-core/workflows/audit-milestone.md",
|
|
"gsd-core/workflows/audit-uat.md",
|
|
"gsd-core/workflows/autonomous.md",
|
|
"gsd-core/workflows/autonomous/steps/converge-banner.md",
|
|
"gsd-core/workflows/autonomous/steps/converge-dispatch-bg.md",
|
|
"gsd-core/workflows/autonomous/steps/converge-dispatch-inline.md",
|
|
"gsd-core/workflows/autonomous/steps/converge-fail-fast.md",
|
|
"gsd-core/workflows/autonomous/steps/converge-loop.md",
|
|
"gsd-core/workflows/check-todos.md",
|
|
"gsd-core/workflows/cleanup.md",
|
|
"gsd-core/workflows/code-review-fix.md",
|
|
"gsd-core/workflows/code-review.md",
|
|
"gsd-core/workflows/code-review/steps/dispatch-fix.md",
|
|
"gsd-core/workflows/code-review/steps/structural-pre-pass.md",
|
|
"gsd-core/workflows/complete-milestone.md",
|
|
"gsd-core/workflows/complete-milestone/detail/elaboration.md",
|
|
"gsd-core/workflows/complete-milestone/steps/git-tag.md",
|
|
"gsd-core/workflows/debug.md",
|
|
"gsd-core/workflows/diagnose-issues.md",
|
|
"gsd-core/workflows/discuss-phase-assumptions.md",
|
|
"gsd-core/workflows/discuss-phase-assumptions/steps/auto-advance-dispatch.md",
|
|
"gsd-core/workflows/discuss-phase-power.md",
|
|
"gsd-core/workflows/discuss-phase.md",
|
|
"gsd-core/workflows/discuss-phase/modes/advisor.md",
|
|
"gsd-core/workflows/discuss-phase/modes/all.md",
|
|
"gsd-core/workflows/discuss-phase/modes/analyze.md",
|
|
"gsd-core/workflows/discuss-phase/modes/auto.md",
|
|
"gsd-core/workflows/discuss-phase/modes/batch.md",
|
|
"gsd-core/workflows/discuss-phase/modes/chain.md",
|
|
"gsd-core/workflows/discuss-phase/modes/default.md",
|
|
"gsd-core/workflows/discuss-phase/modes/power.md",
|
|
"gsd-core/workflows/discuss-phase/modes/text.md",
|
|
"gsd-core/workflows/discuss-phase/templates/checkpoint.json",
|
|
"gsd-core/workflows/discuss-phase/templates/context.md",
|
|
"gsd-core/workflows/discuss-phase/templates/discussion-log.md",
|
|
"gsd-core/workflows/do.md",
|
|
"gsd-core/workflows/docs-update.md",
|
|
"gsd-core/workflows/docs-update/detail/elaboration.md",
|
|
"gsd-core/workflows/docs-update/steps/dispatch-monorepo-packages.md",
|
|
"gsd-core/workflows/edit-phase.md",
|
|
"gsd-core/workflows/eval-review.md",
|
|
"gsd-core/workflows/execute-phase.md",
|
|
"gsd-core/workflows/execute-phase/detail/elaboration.md",
|
|
"gsd-core/workflows/execute-phase/steps/code-review-disposition.md",
|
|
"gsd-core/workflows/execute-phase/steps/codebase-drift-gate.md",
|
|
"gsd-core/workflows/execute-phase/steps/completion-reconciliation.md",
|
|
"gsd-core/workflows/execute-phase/steps/executor-isolation-dispatch.md",
|
|
"gsd-core/workflows/execute-phase/steps/executor-progress-policy.md",
|
|
"gsd-core/workflows/execute-phase/steps/gap-closure-artifacts.md",
|
|
"gsd-core/workflows/execute-phase/steps/partial-wave.md",
|
|
"gsd-core/workflows/execute-phase/steps/per-plan-executor-routing.md",
|
|
"gsd-core/workflows/execute-phase/steps/per-plan-worktree-gate.md",
|
|
"gsd-core/workflows/execute-phase/steps/post-merge-gate.md",
|
|
"gsd-core/workflows/execute-phase/steps/protected-branch.md",
|
|
"gsd-core/workflows/execute-phase/steps/ready-wave-gate.md",
|
|
"gsd-core/workflows/execute-phase/steps/regression-gate-run.md",
|
|
"gsd-core/workflows/execute-phase/steps/regression-gate.md",
|
|
"gsd-core/workflows/execute-phase/steps/sequential-root-pin.md",
|
|
"gsd-core/workflows/execute-phase/steps/stale-reverification.md",
|
|
"gsd-core/workflows/execute-phase/steps/tdd-applicability-resolution.md",
|
|
"gsd-core/workflows/execute-phase/steps/threat-id-gate.md",
|
|
"gsd-core/workflows/execute-phase/steps/wave-post-gate-hooks.md",
|
|
"gsd-core/workflows/execute-phase/steps/worktree-base-check.md",
|
|
"gsd-core/workflows/execute-phase/steps/worktree-recovery-policy.md",
|
|
"gsd-core/workflows/execute-plan.md",
|
|
"gsd-core/workflows/explore.md",
|
|
"gsd-core/workflows/extract-learnings.md",
|
|
"gsd-core/workflows/fast.md",
|
|
"gsd-core/workflows/forensics.md",
|
|
"gsd-core/workflows/graduation.md",
|
|
"gsd-core/workflows/health.md",
|
|
"gsd-core/workflows/help.md",
|
|
"gsd-core/workflows/help/modes/brief.md",
|
|
"gsd-core/workflows/help/modes/default.md",
|
|
"gsd-core/workflows/help/modes/full.compact.md",
|
|
"gsd-core/workflows/help/modes/full.md",
|
|
"gsd-core/workflows/help/modes/topic.md",
|
|
"gsd-core/workflows/import.md",
|
|
"gsd-core/workflows/inbox.md",
|
|
"gsd-core/workflows/ingest-docs.md",
|
|
"gsd-core/workflows/insert-phase.md",
|
|
"gsd-core/workflows/list-phase-assumptions.md",
|
|
"gsd-core/workflows/list-seeds.md",
|
|
"gsd-core/workflows/list-workspaces.md",
|
|
"gsd-core/workflows/manager.md",
|
|
"gsd-core/workflows/map-codebase.md",
|
|
"gsd-core/workflows/milestone-summary.md",
|
|
"gsd-core/workflows/mvp-phase.md",
|
|
"gsd-core/workflows/new-milestone.md",
|
|
"gsd-core/workflows/new-milestone/steps/project-md-milestone-write.md",
|
|
"gsd-core/workflows/new-milestone/steps/reset-phase-safety.md",
|
|
"gsd-core/workflows/new-project.md",
|
|
"gsd-core/workflows/new-project/detail/elaboration.md",
|
|
"gsd-core/workflows/new-project/steps/auto-mode-config.md",
|
|
"gsd-core/workflows/new-project/steps/auto-mode-detection.md",
|
|
"gsd-core/workflows/new-project/steps/codebase-map-offer.md",
|
|
"gsd-core/workflows/new-workspace.md",
|
|
"gsd-core/workflows/next.md",
|
|
"gsd-core/workflows/node-repair.md",
|
|
"gsd-core/workflows/note.md",
|
|
"gsd-core/workflows/onboard.md",
|
|
"gsd-core/workflows/pause-work.md",
|
|
"gsd-core/workflows/plan-phase.md",
|
|
"gsd-core/workflows/plan-phase/detail/elaboration.md",
|
|
"gsd-core/workflows/plan-phase/steps/adr-ingest-express-path.md",
|
|
"gsd-core/workflows/plan-phase/steps/chunked-planning-mode.md",
|
|
"gsd-core/workflows/plan-phase/steps/closed-phase-gate.md",
|
|
"gsd-core/workflows/plan-phase/steps/prd-express-gate.md",
|
|
"gsd-core/workflows/plan-phase/steps/prd-express-path.md",
|
|
"gsd-core/workflows/plan-phase/steps/research-only-early-exit.md",
|
|
"gsd-core/workflows/plan-phase/steps/research-only-modifiers.md",
|
|
"gsd-core/workflows/plan-phase/steps/reviews-prerequisite.md",
|
|
"gsd-core/workflows/plan-phase/steps/stall-detection-helpers.md",
|
|
"gsd-core/workflows/plan-phase/steps/windows-troubleshooting.md",
|
|
"gsd-core/workflows/plan-review-convergence.md",
|
|
"gsd-core/workflows/plant-seed.md",
|
|
"gsd-core/workflows/pr-branch.md",
|
|
"gsd-core/workflows/profile-user.md",
|
|
"gsd-core/workflows/progress.md",
|
|
"gsd-core/workflows/progress/steps/forensic-audit.md",
|
|
"gsd-core/workflows/progress/steps/mvp-display.md",
|
|
"gsd-core/workflows/quick-batch.md",
|
|
"gsd-core/workflows/quick-batch/steps/batch-init.md",
|
|
"gsd-core/workflows/quick-batch/steps/completion.md",
|
|
"gsd-core/workflows/quick-batch/steps/merge-wave.md",
|
|
"gsd-core/workflows/quick-batch/steps/plan-checker-loop.md",
|
|
"gsd-core/workflows/quick-batch/steps/planner-wave.md",
|
|
"gsd-core/workflows/quick-batch/steps/research-phase.md",
|
|
"gsd-core/workflows/quick-batch/steps/resume-mode.md",
|
|
"gsd-core/workflows/quick-batch/steps/verification-wave.md",
|
|
"gsd-core/workflows/quick-batch/steps/worktree-dispatch.md",
|
|
"gsd-core/workflows/quick.md",
|
|
"gsd-core/workflows/quick/steps/discussion-phase.md",
|
|
"gsd-core/workflows/quick/steps/plan-checker-loop.md",
|
|
"gsd-core/workflows/quick/steps/quick-verification.md",
|
|
"gsd-core/workflows/quick/steps/research-phase.md",
|
|
"gsd-core/workflows/quick/steps/worktree-pre-dispatch-commit.md",
|
|
"gsd-core/workflows/reapply-patches.md",
|
|
"gsd-core/workflows/remove-phase.md",
|
|
"gsd-core/workflows/remove-workspace.md",
|
|
"gsd-core/workflows/resume-project.md",
|
|
"gsd-core/workflows/review.md",
|
|
"gsd-core/workflows/review/steps/reviewer-instances-note-1.md",
|
|
"gsd-core/workflows/review/steps/reviewer-instances-note-2.md",
|
|
"gsd-core/workflows/scan.md",
|
|
"gsd-core/workflows/section-manifest.json",
|
|
"gsd-core/workflows/secure-phase.md",
|
|
"gsd-core/workflows/session-report.md",
|
|
"gsd-core/workflows/settings-advanced.md",
|
|
"gsd-core/workflows/settings-integrations.md",
|
|
"gsd-core/workflows/settings.md",
|
|
"gsd-core/workflows/ship.md",
|
|
"gsd-core/workflows/sketch-wrap-up.md",
|
|
"gsd-core/workflows/sketch.md",
|
|
"gsd-core/workflows/smart-entry.md",
|
|
"gsd-core/workflows/spec-phase.md",
|
|
"gsd-core/workflows/spike-wrap-up.md",
|
|
"gsd-core/workflows/spike.md",
|
|
"gsd-core/workflows/stats.md",
|
|
"gsd-core/workflows/sync-skills.md",
|
|
"gsd-core/workflows/thread.md",
|
|
"gsd-core/workflows/transition.md",
|
|
"gsd-core/workflows/transition/steps/workstream-collision-check.md",
|
|
"gsd-core/workflows/ui-phase.md",
|
|
"gsd-core/workflows/ui-review.md",
|
|
"gsd-core/workflows/ultraplan-phase.md",
|
|
"gsd-core/workflows/undo.md",
|
|
"gsd-core/workflows/update.md",
|
|
"gsd-core/workflows/update/steps/channel-banner.md",
|
|
"gsd-core/workflows/validate-phase.md",
|
|
"gsd-core/workflows/verify-work.md",
|
|
"gsd-core/workflows/verify-work/detail/elaboration.md",
|
|
"gsd-core/workflows/verify-work/steps/automated-ui-verification.md",
|
|
"gsd-core/workflows/verify-work/steps/mvp-uat-framing.md",
|
|
"hooks/gsd-agent-isolation-guard.js",
|
|
"hooks/gsd-check-update-worker.js",
|
|
"hooks/gsd-check-update.js",
|
|
"hooks/gsd-config-reload.js",
|
|
"hooks/gsd-context-monitor.js",
|
|
"hooks/gsd-cursor-post-tool.js",
|
|
"hooks/gsd-cursor-pre-tool.js",
|
|
"hooks/gsd-cursor-session-start.js",
|
|
"hooks/gsd-cursor-stop.js",
|
|
"hooks/gsd-cursor-subagent-start.js",
|
|
"hooks/gsd-cursor-subagent-stop.js",
|
|
"hooks/gsd-ensure-canonical-path.js",
|
|
"hooks/gsd-graphify-update.sh",
|
|
"hooks/gsd-node-runner.sh",
|
|
"hooks/gsd-phase-boundary.sh",
|
|
"hooks/gsd-prompt-guard.js",
|
|
"hooks/gsd-read-guard.js",
|
|
"hooks/gsd-read-injection-scanner.js",
|
|
"hooks/gsd-secret-read-guard.js",
|
|
"hooks/gsd-session-state.sh",
|
|
"hooks/gsd-statusline.js",
|
|
"hooks/gsd-update-banner.js",
|
|
"hooks/gsd-validate-commit.sh",
|
|
"hooks/gsd-windsurf-pre-command.js",
|
|
"hooks/gsd-windsurf-pre-write.js",
|
|
"hooks/gsd-workflow-guard.js",
|
|
"hooks/gsd-worktree-path-guard.js",
|
|
"hooks/gsd-write-guard.js",
|
|
"hooks/lib/cli-exit.js",
|
|
"hooks/lib/cursor-workspace.js",
|
|
"hooks/lib/dispatch-identity.js",
|
|
"hooks/lib/exit-code-registry.js",
|
|
"hooks/lib/filename-classification.js",
|
|
"hooks/lib/git-cmd.js",
|
|
"hooks/lib/git-probe.js",
|
|
"hooks/lib/gsd-graphify-rebuild.sh",
|
|
"hooks/lib/hook-exit.js",
|
|
"hooks/lib/injection-patterns.js",
|
|
"hooks/lib/isolation-deny-reason.js",
|
|
"hooks/lib/isolation-sentinel.js",
|
|
"hooks/managed-hooks-registry.cjs",
|
|
"hooks/package.json",
|
|
"scripts/changeset/README.md",
|
|
"scripts/changeset/cli.cjs",
|
|
"scripts/changeset/github-release-notes.cjs",
|
|
"scripts/changeset/lint.cjs",
|
|
"scripts/changeset/new.cjs",
|
|
"scripts/changeset/parse.cjs",
|
|
"scripts/changeset/render.cjs",
|
|
"scripts/changeset/serialize.cjs",
|
|
"scripts/fix-slash-commands.cjs",
|
|
"scripts/gen-capability-registry.cjs",
|
|
"scripts/gen-loop-host-contract.cjs",
|
|
"scripts/lib/alias-drift-families.cjs",
|
|
"scripts/lib/allowlist-ratchet.cjs",
|
|
"scripts/lib/ci-job-timing.cjs",
|
|
"scripts/lib/cli-exit.cjs",
|
|
"scripts/lib/drift-scan.cjs",
|
|
"scripts/lib/exit-code-registry.cjs",
|
|
"scripts/lib/macos-conformance-tier.generated.cjs",
|
|
"scripts/lib/ndjson-reporter.cjs",
|
|
"scripts/lib/npm-version-check-diagnosis.cjs",
|
|
"scripts/lib/platform-conformance-tier.generated.cjs",
|
|
"scripts/lib/shellcheck-fetch.cjs",
|
|
"scripts/lib/suite-detection.cjs",
|
|
"skills/gsd/DESCRIPTION.md",
|
|
"skills/gsd/gsd-ns-context/SKILL.md",
|
|
"skills/gsd/gsd-ns-context/skills/docs-update/SKILL.md",
|
|
"skills/gsd/gsd-ns-context/skills/extract-learnings/SKILL.md",
|
|
"skills/gsd/gsd-ns-context/skills/graphify/SKILL.md",
|
|
"skills/gsd/gsd-ns-context/skills/map-codebase/SKILL.md",
|
|
"skills/gsd/gsd-ns-context/skills/mempalace-capture/SKILL.md",
|
|
"skills/gsd/gsd-ns-context/skills/mempalace-recall/SKILL.md",
|
|
"skills/gsd/gsd-ns-ideate/SKILL.md",
|
|
"skills/gsd/gsd-ns-ideate/skills/capture/SKILL.md",
|
|
"skills/gsd/gsd-ns-ideate/skills/explore/SKILL.md",
|
|
"skills/gsd/gsd-ns-ideate/skills/sketch/SKILL.md",
|
|
"skills/gsd/gsd-ns-ideate/skills/spec-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-ideate/skills/spike/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/cleanup/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/config/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/health/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/help/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/inbox/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/manager/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/pause-work/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/pr-branch/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/resume-work/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/settings/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/ship/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/stats/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/surface/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/thread/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/undo/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/update/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/workspace/SKILL.md",
|
|
"skills/gsd/gsd-ns-manage/skills/workstreams/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/audit-milestone/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/complete-milestone/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/import/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/ingest-docs/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/milestone-summary/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/new-milestone/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/new-project/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/onboard/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/profile-user/SKILL.md",
|
|
"skills/gsd/gsd-ns-project/skills/review-backlog/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/audit-fix/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/audit-uat/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/code-review/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/debug/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/eval-review/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/forensics/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/review/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/secure-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/ui-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/ui-review/SKILL.md",
|
|
"skills/gsd/gsd-ns-review/skills/validate-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/add-tests/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/ai-integration-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/autonomous/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/discuss-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/execute-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/fast/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/mvp-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/next/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/plan-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/plan-review-convergence/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/progress/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/quick-batch/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/quick/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/spec-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/ultraplan-phase/SKILL.md",
|
|
"skills/gsd/gsd-ns-workflow/skills/verify-work/SKILL.md"
|
|
]
|