You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chore(D0142): cut 5.0.1, and re-baseline the corpus figure from a measurement instead of a memory
Version 5.0.1 across the authoritative locations, the changelog section cut from its
fragment, and hand-authored notes for a reader outside this repository.
The release gate's verify lane reports 52 red criteria against a recorded baseline of 50,
and the baseline blocks in BOTH directions, so that had to be explained rather than waved
through: a count above the line is supposed to mean a new dead selector nobody guarded.
It is not one here, and that was settled by execution. `git diff v5.0.0..HEAD -- sdlc-studio/`
shows no story file changed at all - the only artefact diffs are derived indexes and the three
specs. The delivered commit touches one skill test, and only to wrap a call in
`redirect_stdout`. A red criterion is a story `Verify:` line failing against a test file, and
neither side of that moved.
What moved is the denominator: 1,906 criteria across 670 stories now, against a recorded 1,918
across 673. Two runs that disagree on how many criteria EXIST were not measuring the same set,
so the gap between their red counts carries no information about regression. The recorded
figure is treated as unreproducible rather than as a bar that has been breached.
This is the failure the baseline file was written about, happening to the baseline file. Its
header records the number being wrong four times - 106, 53, 58, 50 - and states the argument
outright: a number nobody re-measures is a number that is wrong. Carrying 50 forward a fifth
time because it is what is written down would be that mistake again, so the baseline is set
from this run's own measurement and D0142 records why.
Stated as the weakness it is: 52 rests on one reading, which is the standing 50 had. It is
better only in being current and in naming the tree it was taken on. The scheduled corpus
lane is what makes it a series.
The release proceeds with that lane red, on the same footing as v5.0.0 under D0137: the
stale selectors are disclosed v5.1 debt, and repairing them in bulk would convert a visible
stale selector into an invisible vacuous one.
Also corrected: the runbook's `record-green` row documented a `--gate <which>` flag that does
not exist on the command. Written from the intent of D0141 rather than from the CLI, and found
by trying to run it. The `dead-flags` lane does not reach `reference-*.md`, so nothing caught
it - which matters more than the typo, because the runbook is the document every session is
told to read before acting.
Also fixed, and it blocked this commit twice: `test_the_guard_reddens_on_a_mutated_cell` wrote
the LIVE `.claude/skills/sdlc-studio/SKILL.md` and restored it byte-for-byte in a `finally`. That
reads as safe and is not. `repo_writes` reports a restored path deliberately, because a run that
edits a tracked file and puts it back has raced every concurrent reader of it - and it left the
skill's own entry point one interrupted run away from being what a fixture destroyed.
The mutation now lands on a symlinked copy: every child of the skill tree is symlinked and only
`SKILL.md` is a real file, so path resolution behaves as it does live at no copying cost, and a
positive control asserts the UNmutated guide resolves through that root. Killed by mutating
`check_loading_guide` to return `[]`.
This is `repo-writes` catching a PRE-EXISTING writer rather than a fresh mistake - its first such
catch since it shipped. The lane earned its place at a release boundary, which is where the four
incidents it was built after were each found by something unrelated.
Refs: D0142, BG0575
| Stamp the commit the gate passed on |`release_cut.py record-green --commit <sha> --gate <which>`| a green claim naming no gate|
79
+
| Stamp the commit the gate passed on |`release_cut.py record-green --commit <sha>`|tagging on a green nobody recorded|
80
80
| Refuse a tag the gate never covered |`release_cut.py tag-check --version <v>`| tagging on memory |
81
81
| Publish the release and its artefacts | your project's release automation, triggered by the tag | a hand-uploaded artefact, which is the step that gets skipped |
Copy file name to clipboardExpand all lines: sdlc-studio/decisions.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -153,6 +153,7 @@ agents read, so a decision is referenced once, not pasted N times.
153
153
| D0139 | v5.0.0's release notes are HAND-AUTHORED for a reader outside this repository: what v5 is, the upgrade path from v4.1, what changed, and the known issues with their ids and v5.1 target. `changelog.py compose` still runs, because the release gate refuses on the 34 uncomposed fragments, but its output ships as the linked CHANGELOG rather than as the notes themselves. | Operator ruling, 2026-08-11. The composed draft is 4,001 lines and carries unit ids on essentially every bullet - D0135 already recorded that this is what compose produces and that it is the reason the notes could not simply be the composed body. What that ruling deferred to this charter, this one settles: both artefacts ship, with distinct jobs. The composed log is the per-unit record and an adopter auditing a specific change needs it, so dropping it would lose real evidence; it is simply not something a person deciding whether to upgrade can read. The hand-authored page is the thing that decides an upgrade, and it is the only place the 38 deferred bugs from D0136 can be disclosed in a form that means anything - a bug id inside a 4,001-line log is disclosed in the same sense that a rule stated in AGENTS.md with no gate behind it is enforced. | accepted | -- | 2026-08-11 |
154
154
| D0140 | US0469, US0474 and US0475 are OUT of the v5.0.0 release scope and stay at Ready. SC0007's scope rule listed them beside the eight units awaiting sign-off, as though they were delivered work needing only a signature. They are not: none carries a changelog fragment, and one names a test file that has never existed. They are planned, unbuilt EP0171 stories, and they are not defects, so they hold no release bar. They are carried to v5.1 as ordinary backlog. | Checked rather than assumed, which is the whole point of recording it. `git log -S` against each id returns only planning commits; `changelog.d/US0469.md`, `US0474.md` and `US0475.md` do not exist; `.claude/skills/sdlc-studio/scripts/tests/test_close_review_record.py`, named in US0475's Affects, is absent from the tree. A charter that lists unbuilt work in the same breath as work awaiting a signature invites exactly the error this repository filed as a High bug - a unit's status read from its neighbours rather than from itself. The alternative was to build three stories inside a release cut, which is scope the tag does not need and review capacity the run does not have. Naming them here means the next reader finds them carried deliberately rather than dropped quietly. | accepted | -- | 2026-08-11 |
155
155
| D0141 | v5.0.0 is tagged on a commit whose `gate.py --boundary release` is GREEN, with `gate.py --release`'s verify lane RED at 50 criteria. `release_cut.py record-green` stamps the boundary gate, not the whole-workspace one, and this decision records which gate was stamped so the stamp cannot be read as more than it is. | An independent review of the release plan established that `record_green` performs no gate at all - it writes the commit id to a file - so nothing mechanical distinguishes a stamp made after a green run from one made after none. That makes the choice of gate a judgement, and a judgement belongs on the record rather than in a command's silence. The boundary gate is the one doctrine names for a release, and it passed: conformance 0 non-conformant, reconcile 0 drift, duplicate-id clean, and release-rehearsal walking greenfield init and a v4-era upgrade end to end. The whole-workspace gate additionally executes every acceptance criterion in the corpus, and 50 of 1,918 fail. D0137 already ruled those into v5.1 as their own sweep, for reasons that still hold: they are stale selectors rather than broken features, and a repair that merely makes a criterion pass converts a visible stale selector into an invisible vacuous one. Repairing 50 of them inside a release cut, without a review each, is precisely the trade that ruling refused. The cost is stated rather than hidden. v5.0.0 ships with 50 executable criteria that fail when run, the release notes say so with the number, `tools/verify-corpus-baseline.txt` records it as the figure the scheduled lane holds against in both directions, and the write-time guard means the set is closed and draining rather than open and growing. What this decision buys is that the next reader can tell which gate was green, instead of inferring it from a stamp that would look identical either way. | accepted | -- | 2026-08-12 |
156
+
| D0142 | The corpus verification baseline is re-set from this run's own measurement: 52 red criteria of 1,906 across 670 stories, measured by `gate.py --release` at 2588384b on 2026-08-12. The recorded 50 of 1,918 across 673 could not be reproduced and is not carried forward. v5.0.1 is tagged with the verify lane red at that figure, on the same footing as v5.0.0 under D0137. | The baseline demands NO WORSE and blocks in both directions, so 52 against a recorded 50 had to be explained rather than waved through - a count above the line is supposed to mean a new dead selector nobody guarded. It is not that here, established by execution rather than impression. `git diff v5.0.0..HEAD -- sdlc-studio/` shows no story file changed at all; the only artefact diffs are derived index files and the three specs. The delivered commit touches exactly one skill test, `test_sprint.py`, and only to wrap a call in `redirect_stdout`; that test passes and no story selects it in a way the wrapper could affect. A red criterion is a story `Verify:` line failing against a test file, and neither side of that moved. What did move is the DENOMINATOR: 1,906 executable criteria across 670 stories now, against the recorded 1,918 across 673. Two measurements that disagree on how many criteria exist were not measuring the same thing, so the delta between their red counts carries no information about regression. The recorded figure is therefore treated as unreproducible rather than as a lower bar that has been breached. This is the failure the baseline file was written about, happening to the baseline file. Its own header records the number being wrong four times - 106, then 53, then 58, then 50 - and states the argument plainly: a number nobody re-measures is a number that is wrong. Carrying 50 forward a fifth time because it is what is written down would repeat exactly that, and re-baselining to a figure this run actually measured is what the file asks for. Stated as a weakness rather than left implicit: 52 rests on ONE measurement, which is the same standing the 50 had. It is better only in being current and in naming the tree it was taken on. The scheduled corpus-verify lane is what turns a single reading into a series, and it now has a figure to move from. The release proceeds because the lane's redness is the disclosed v5.1 stale-selector debt ruled by D0137, already named in the v5.0.0 notes and shipped over once. Nothing about the count's provenance changes what a consumer of v5.0.1 gets: the repairs are still a v5.1 sweep, because a repair that merely makes a criterion pass converts a visible stale selector into an invisible vacuous one. | accepted | -- | 2026-08-12 |
0 commit comments