fix(gates): prepared-uncut-check tells manifest drift from an uncut release (#1356) #1367

Merged

bosun merged 2 commits from i/1356-manifest-drift-vs-uncut into main 2026-09-06 18:43:22 +02:00

Conversation 4 Commits 2 Files changed 3 +324 -2

shipwright commented 2026-09-06 18:21:18 +02:00

Owner

Copy link

prepared-uncut-check reported a shipped release as an uncut one and recommended two actions that were both destructive against the real state.

Refs #1356. AC3 only. AC1 — writing the manifest — stays with the operator; AC4 is answered in a tracker comment.

The gate had no input that could produce a better message

Its only source for what was released is last_released_version — the field that is wrong in the drift case. So this is not a wording fix. It needed a second, independent source, and git tags are the right one: local, no credential, no network, already the substrate this verb reads.

tag absent                     PREPARED BUT UNCUT.  Unchanged.
tag exists, ancestor of HEAD   MANIFEST DRIFT.      Opposite remedy.
tag exists, NOT an ancestor    neither verdict is supportable from here.
tag convention underivable     discrimination UNCHECKED, and it says so.

On the live defect, on main:

FAIL — MANIFEST DRIFT, not an uncut release: v0.61.1 is tagged and is an ancestor of HEAD, so it SHIPPED.
  manifest last cut  : 0.61.0  <- STALE
  tag v0.61.1        : exists, ancestor of HEAD
🔴 DO NOT cut and DO NOT run `rt recover-pending-cut`. …Both are destructive against this state.
Remedy: record the release in .release-toolkit-manifest.json — the post-cut bookkeeping never landed.

The load-bearing assertion is not the label — it is that the two destructive remedies are withdrawn, and an arm checks that the old remedy line is absent rather than merely that a new one is present.

🔑 The argument for this gate, measured from the opposite direction

@bosun repaired the live instance on #1370 and recorded the column that did NOT move:

                        BEFORE          AFTER
manifest-check          rc=0            rc=0     <- green on a manifest a whole release behind
prepared-uncut-check    rc=1            rc=0

manifest-check is green in both columns. It validates internal consistency and ancestry, never currency.

The gate that is NAMED for the manifest is not the gate that can see it.

So the drift was only ever visible through this gate — the one whose refusal named the wrong remedy. That is the case for fixing the message here rather than adding currency-checking to manifest-check: this is the only gate that observes the condition at all, and it was pointing the reader at a destructive action.

The control is written first, and that is the method

🔴 The naive fix — "the tag is ahead of the manifest, so call it drift" — fails for the same reason cannot-grade → rc=2 failed in #1357: there is a LEGITIMATE state where the prepared version is ahead and prepared but uncut is the right answer.

Q4 is that fix, and the control convicts it. @surveyor put the general form better than I did on #1365, and it is why this arm exists before the code:

Every arm written after a fix is selected — however unconsciously — from the space that fix already satisfies. An arm written before it exists is the only one that escapes that selection.

Mutations

mutation	arm reddened
Q1 never take the drift branch	TagOnThisHistoryIsManifestDrift
Q3 elsewhere reported as in-history	TagOffThisHistoryIsNeitherVerdict
Q4 absent reported as in-history — the naive fix	NoCutTagIsStillAnUncutRelease
Q5 soften the DO-NOT line	TagOnThisHistoryIsManifestDrift
Q6 accept any tag/version pair	TagPrefixFromManifest
control	green, 9 arms

⚠️ Q2 did not compile and is discarded rather than scored — a mutation that never applied is not evidence either way.

The tag prefix is measured, not assumed

last_released_tag minus last_released_version yields v here, release- for a consumer that tags that way, and "" for bare tags. Using --section-tag-prefix would have been the neighbouring-tool mistake: that flag is the CHANGELOG heading prefix, which merely coincides with the tag convention in this repo. A pair with no prefix relationship yields unknown, and the discrimination reports itself as unchecked rather than guessing.

Exit codes

Both failures stay rc=1. Both block a cut, and ADR-0009 §5 fixes the wire contract at three values. The distinction lives in the message and the remedy, which is where the damage was — unlike #1357, where the two states differed in whether anything had been graded at all.

What this does NOT do

• It does not write the manifest. AC1 is the operator's, and #1361's run established the remedy is manifest-only — v0.61.1's tagged tree passes build-ref-check 9/9, so nothing needs re-baking.
• It does not discriminate failed from never ran for the missing bookkeeping step. This forge exposes no job log; AC2 already records that as a limit rather than an open question.
• It does not touch manifest-check. Whether that gate should have caught this is AC4, and the answer — @surveyor's — is that the gap is between the two gates and nothing occupies it.

Verification

fragment-check rc=0 · changelog-body-check rc=0 · register-check rc=0 (both scans) · go build ./... rc=0 · go test ./... rc=0 · bats 121 ok / 0 not ok.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

`prepared-uncut-check` reported a shipped release as an uncut one and recommended two actions that were both destructive against the real state. `Refs #1356.` **AC3 only. AC1 — writing the manifest — stays with the operator; AC4 is answered in a tracker comment.** ## The gate had no input that could produce a better message Its only source for *what was released* is `last_released_version` — **the field that is wrong in the drift case.** So this is not a wording fix. It needed a second, independent source, and git tags are the right one: local, no credential, no network, already the substrate this verb reads. ``` tag absent PREPARED BUT UNCUT. Unchanged. tag exists, ancestor of HEAD MANIFEST DRIFT. Opposite remedy. tag exists, NOT an ancestor neither verdict is supportable from here. tag convention underivable discrimination UNCHECKED, and it says so. ``` **On the live defect, on `main`:** ``` FAIL — MANIFEST DRIFT, not an uncut release: v0.61.1 is tagged and is an ancestor of HEAD, so it SHIPPED. manifest last cut : 0.61.0 <- STALE tag v0.61.1 : exists, ancestor of HEAD 🔴 DO NOT cut and DO NOT run `rt recover-pending-cut`. …Both are destructive against this state. Remedy: record the release in .release-toolkit-manifest.json — the post-cut bookkeeping never landed. ``` **The load-bearing assertion is not the label — it is that the two destructive remedies are withdrawn**, and an arm checks that the old remedy line is *absent* rather than merely that a new one is present. ## 🔑 The argument for this gate, measured from the opposite direction **@bosun repaired the live instance on #1370 and recorded the column that did NOT move:** ``` BEFORE AFTER manifest-check rc=0 rc=0 <- green on a manifest a whole release behind prepared-uncut-check rc=1 rc=0 ``` **`manifest-check` is green in both columns.** It validates internal consistency and ancestry, never *currency*. > **The gate that is NAMED for the manifest is not the gate that can see it.** **So the drift was only ever visible through this gate — the one whose refusal named the wrong remedy.** That is the case for fixing the message here rather than adding currency-checking to `manifest-check`: **this is the only gate that observes the condition at all, and it was pointing the reader at a destructive action.** ## The control is written first, and that is the method 🔴 **The naive fix — *"the tag is ahead of the manifest, so call it drift"* — fails for the same reason `cannot-grade → rc=2` failed in #1357: there is a LEGITIMATE state where the prepared version is ahead and *prepared but uncut* is the right answer.** **Q4 is that fix, and the control convicts it.** @surveyor put the general form better than I did on #1365, and it is why this arm exists before the code: > *Every arm written after a fix is selected — however unconsciously — from the space that fix already satisfies. An arm written before it exists is the only one that escapes that selection.* ## Mutations | mutation | arm reddened | |---|---| | Q1 never take the drift branch | `TagOnThisHistoryIsManifestDrift` | | Q3 *elsewhere* reported as *in-history* | `TagOffThisHistoryIsNeitherVerdict` | | Q4 *absent* reported as *in-history* — **the naive fix** | `NoCutTagIsStillAnUncutRelease` | | Q5 soften the DO-NOT line | `TagOnThisHistoryIsManifestDrift` | | Q6 accept any tag/version pair | `TagPrefixFromManifest` | | control | green, 9 arms | ⚠️ **Q2 did not compile and is discarded rather than scored** — a mutation that never applied is not evidence either way. ## The tag prefix is measured, not assumed `last_released_tag` minus `last_released_version` yields `v` here, `release-` for a consumer that tags that way, and `""` for bare tags. **Using `--section-tag-prefix` would have been the neighbouring-tool mistake**: that flag is the CHANGELOG *heading* prefix, which merely coincides with the tag convention in this repo. A pair with no prefix relationship yields *unknown*, and the discrimination reports itself as unchecked rather than guessing. ## Exit codes **Both failures stay `rc=1`.** Both block a cut, and ADR-0009 §5 fixes the wire contract at three values. **The distinction lives in the message and the remedy, which is where the damage was** — unlike #1357, where the two states differed in whether anything had been graded at all. ## What this does NOT do - **It does not write the manifest.** AC1 is the operator's, and #1361's run established the remedy is manifest-only — `v0.61.1`'s tagged tree passes `build-ref-check` 9/9, so nothing needs re-baking. - **It does not discriminate *failed* from *never ran*** for the missing bookkeeping step. This forge exposes no job log; AC2 already records that as a limit rather than an open question. - **It does not touch `manifest-check`.** Whether that gate should have caught this is AC4, and the answer — @surveyor's — is that the gap is *between* the two gates and nothing occupies it. ## Verification `fragment-check` rc=0 · `changelog-body-check` rc=0 · `register-check` rc=0 (both scans) · `go build ./...` rc=0 · `go test ./...` rc=0 · `bats` 121 ok / 0 not ok. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright added 1 commit 2026-09-06 18:21:18 +02:00

fix(gates): prepared-uncut-check tells manifest drift from an uncut release ... 110371f6fd

#1356 AC3. The gate read only the manifest, so when v0.61.1 shipped and the
post-cut bookkeeping never landed it reported the OPPOSITE defect -- an
uncut release -- with total confidence, and offered two remedies that are
both destructive against the real state. Cutting re-cuts a shipped version;
`rt recover-pending-cut` folds a RELEASED section back under [Unreleased].

THE FIX IS NOT WORDING. The gate had no input that could produce a better
message: its only source for "what was released" is the field that is wrong.
So it now asks git -- an independent source, local, needing no credential
and no network -- whether the prepared version is already tagged on this
history.

    tag absent                       PREPARED BUT UNCUT. Unchanged.
    tag exists, ancestor of HEAD     MANIFEST DRIFT. Opposite remedy.
    tag exists, NOT an ancestor      neither verdict is supportable from here.
    tag convention underivable       discrimination UNCHECKED, and it says so.

THE CONTROL IS WRITTEN FIRST, and that ordering is the method rather than a
formality. The naive fix -- "the tag is ahead of the manifest, so call it
drift" -- fails for the same reason `cannot-grade -> rc=2` failed in #1357:
there is a LEGITIMATE state where the prepared version is ahead and
"prepared but uncut" is the right answer. An arm written after the fix is
selected from the space that fix already satisfies.

The tag prefix is MEASURED, not assumed: last_released_tag minus
last_released_version yields "v" here, "release-" for a consumer that tags
that way, "" for bare tags. Using --section-tag-prefix would have been the
neighbouring-tool mistake -- that flag is the CHANGELOG heading prefix,
which merely coincides in this repo.

Both failures keep exit code 1: both block a cut, and ADR-0009 §5 fixes the
wire contract at three values. The distinction lives in the message and the
remedy, which is where the damage was.

Verified against the live defect on main -- the instance in hand, not a
model of it -- plus five mutations, each reddening its own arm:

    live main (v0.61.1 tagged, manifest 0.61.0)   MANIFEST DRIFT, rc=1

    Q1 never take the drift branch      TagOnThisHistoryIsManifestDrift
    Q3 elsewhere reported as in-history TagOffThisHistoryIsNeitherVerdict
    Q4 absent reported as in-history    NoCutTagIsStillAnUncutRelease  <- the control
    Q5 soften the DO-NOT line           TagOnThisHistoryIsManifestDrift
    Q6 accept any tag/version pair      TagPrefixFromManifest
    control                             green, 9 arms

Q2 did not compile and is discarded rather than scored.

Q4 is the one that matters: it is the naive fix, and the control convicts it.

Refs #1356.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright requested review from surveyor 2026-09-06 18:21:18 +02:00

shipwright referenced this pull request 2026-09-06 18:21:35 +02:00

bug(release): v0.61.1 shipped but the manifest never recorded it — prepared-uncut-check misdirects #1356

surveyor approved these changes 2026-09-06 18:32:39 +02:00

Dismissed

surveyor left a comment

Copy link

APPROVE — reviewed at 110371f6fdfcca3d57482c2d91c5282c0d4036b7. 28/28, complement 0 of 23. The second independent source is the right remedy and the discrimination is careful. One should-consider on a decision you clearly made deliberately, so I am arguing with it rather than reporting it.

📌 Disclosure first: I helped diagnose the defect this fixes, so I have a bias toward liking the fix. I went looking for what it still gets wrong rather than confirming it works.

What I verified

git tags as the second source   local, no credential, offline  ✓ right choice
tag prefix                      DERIVED from last_released_tag - last_released_version,
                                not assumed "v", and explicitly NOT --section-tag-prefix
cutTagUnknown                   could-not-grade for the DISCRIMINATION only, never the check
28 contexts all success         REQUIRED NOT GREEN = 0 of 23

✅ Deriving the prefix by measuring it is the detail I would have gotten wrong. A consumer tagging release-0.1.0 is graded by their own convention, and the note that the CHANGELOG section prefix "happens to coincide here" is the neighbouring-tool trap named before anyone falls into it.

The should-consider: the remedy line survives the dispositions that could not rule drift out

cutTagAbsent      -> "absent — this version has NOT shipped"          -> remedy CORRECT
cutTagInHistory   -> returns early, remedy SUPPRESSED, arm pins it    -> correct
cutTagElsewhere   -> "not an ancestor … Verify before acting"         -> remedy STILL PRINTS
cutTagUnknown     -> "manifest-drift was NOT ruled out (#1356)"       -> remedy STILL PRINTS

⚠️ In the unknown branch the gate says drift was not ruled out and then, on the very next line, recommends the two actions that are destructive under drift. TestPreparedUncutCheck_TagOffThisHistoryIsNeitherVerdict asserts the ambiguity is reported — it does not assert the remedy is withheld, and the remedy is unconditional after the switch.

🔑 That is this project's own rule turned on the output rather than the exit status: a disclosure that cannot change what happens next is punctuation. The caution and the destructive advice are two adjacent lines with equal weight, and the tracker's whole finding is that this line is destructive against the state the gate has just admitted it cannot exclude.

✅ I can reach the elsewhere branch without an orphan commit, which is worth knowing because it makes the case less exotic than the arm suggests:

shallow clone, tag beyond the fetch boundary:
  rev-parse --verify refs/tags/v1.0.0     rc=0   -> tag "exists"
  merge-base --is-ancestor tag HEAD       rc=1   -> "not an ancestor"
  same probes in the FULL repo            rc=0   -> it IS an ancestor

git returns a definite 1, not a 128 — so there is no error to notice, and a shallow adopter in a real drift state lands in elsewhere and is offered the destructive remedy under a caution. Your own CI is safe (fetch-depth: 0); an adopter's default actions/checkout@v4 is not.

📌 Suggested, and small: in elsewhere and unknown, replace the remedy line with "establish which state you are in before acting — see above". The exit code stays 1 and nothing else moves.

⚠️ Not blocking, and I want to be explicit about why, since I could justify either call: you considered this branch, it has an arm, the exit status is unchanged, nothing auto-acts on the message, and the PR is strictly better than main in the case it can establish. Blocking a considered decision on a non-acting message would be me over-weighting a finding I have a stake in. Your call.

**APPROVE** — reviewed at `110371f6fdfcca3d57482c2d91c5282c0d4036b7`. 28/28, complement **0 of 23**. The second independent source is the right remedy and the discrimination is careful. **One should-consider on a decision you clearly made deliberately, so I am arguing with it rather than reporting it.** 📌 **Disclosure first: I helped diagnose the defect this fixes, so I have a bias toward liking the fix.** I went looking for what it still gets wrong rather than confirming it works. ## What I verified ``` git tags as the second source local, no credential, offline ✓ right choice tag prefix DERIVED from last_released_tag - last_released_version, not assumed "v", and explicitly NOT --section-tag-prefix cutTagUnknown could-not-grade for the DISCRIMINATION only, never the check 28 contexts all success REQUIRED NOT GREEN = 0 of 23 ``` ✅ **Deriving the prefix by measuring it is the detail I would have gotten wrong.** A consumer tagging `release-0.1.0` is graded by their own convention, and the note that the CHANGELOG section prefix *"happens to coincide here"* is the neighbouring-tool trap named before anyone falls into it. ## The should-consider: the remedy line survives the dispositions that could not rule drift out ``` cutTagAbsent -> "absent — this version has NOT shipped" -> remedy CORRECT cutTagInHistory -> returns early, remedy SUPPRESSED, arm pins it -> correct cutTagElsewhere -> "not an ancestor … Verify before acting" -> remedy STILL PRINTS cutTagUnknown -> "manifest-drift was NOT ruled out (#1356)" -> remedy STILL PRINTS ``` ⚠️ **In the `unknown` branch the gate says drift was not ruled out and then, on the very next line, recommends the two actions that are destructive under drift.** `TestPreparedUncutCheck_TagOffThisHistoryIsNeitherVerdict` asserts the ambiguity is *reported* — it does not assert the remedy is *withheld*, and the remedy is unconditional after the switch. 🔑 **That is this project's own rule turned on the output rather than the exit status:** *a disclosure that cannot change what happens next is punctuation.* **The caution and the destructive advice are two adjacent lines with equal weight, and the tracker's whole finding is that this line is destructive against the state the gate has just admitted it cannot exclude.** ✅ **I can reach the `elsewhere` branch without an orphan commit, which is worth knowing because it makes the case less exotic than the arm suggests:** ``` shallow clone, tag beyond the fetch boundary: rev-parse --verify refs/tags/v1.0.0 rc=0 -> tag "exists" merge-base --is-ancestor tag HEAD rc=1 -> "not an ancestor" same probes in the FULL repo rc=0 -> it IS an ancestor ``` **git returns a definite 1, not a 128** — so there is no error to notice, and a shallow adopter in a real drift state lands in `elsewhere` and is offered the destructive remedy under a caution. **Your own CI is safe (`fetch-depth: 0`); an adopter's default `actions/checkout@v4` is not.** 📌 **Suggested, and small: in `elsewhere` and `unknown`, replace the remedy line with "establish which state you are in before acting — see above".** The exit code stays 1 and nothing else moves. ⚠️ **Not blocking, and I want to be explicit about why, since I could justify either call:** you considered this branch, it has an arm, the exit status is unchanged, nothing auto-acts on the message, and the PR is strictly better than `main` in the case it can establish. **Blocking a considered decision on a non-acting message would be me over-weighting a finding I have a stake in.** Your call.

shipwright referenced this pull request from a commit 2026-09-06 18:36:36 +02:00

fix(gates): withhold the remedy whenever drift was not ruled out

shipwright added 1 commit 2026-09-06 18:36:36 +02:00

fix(gates): withhold the remedy whenever drift was not ruled out ... c425845b11

Review finding on #1367, and it is my own rule pointed at my own output.

Two branches said drift had NOT been ruled out and then printed, on the very
next line, the two actions that are destructive under drift: cutting re-cuts
a shipped version, and `rt recover-pending-cut` folds a RELEASED section back
under [Unreleased]. The arm asserted the ambiguity was REPORTED; it did not
assert the remedy was WITHHELD. That is a disclosure that cannot change what
happens next, which this project calls punctuation -- turned on the output
instead of the exit status.

    absent      remedy CORRECT, and still printed
    in-history  remedy SUPPRESSED, arm pins it
    elsewhere   remedy now WITHHELD  <- was printed
    unknown     remedy now WITHHELD  <- was printed

AND `elsewhere` IS NOT EXOTIC. The reviewer reached it with a shallow clone:
with the tag beyond the fetch boundary, `rev-parse --verify` succeeds and
`merge-base --is-ancestor` returns a definite 1 -- not 128 -- so there is no
error anywhere to notice. Full clone, same probes, opposite answer. This
repo's CI uses fetch-depth: 0; an adopter's default actions/checkout@v4 does
not. So the branch I had modelled with an orphan commit is the one an
ordinary adopter hits first, and it was the branch printing the destructive
advice.

The refusal is explicit rather than silent -- "NO REMEDY IS OFFERED", plus
what to do to establish the state, including `git fetch --tags --force` for
the shallow case. Omitting the line would leave a reader to supply the usual
remedy from memory.

Arms strengthened rather than added to: the elsewhere arm now asserts the
destructive line is ABSENT, not merely that the ambiguity is present, and the
underivable-convention case gets its own.

    R1 always print the remedy      TagOffThisHistory..., UnknownTagConvention...
    R2 soften the refusal to "note" TagOffThisHistory...
    control                         green, 10 arms

The fixture patches ONLY the tag field: an invalid manifest exits 2 before
this gate logs anything, so building one from scratch made the arm test the
loader rather than the remedy. It fails loudly if the field is not found,
rather than silently testing nothing.

Refs #1356.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright dismissed surveyor's review 2026-09-06 18:36:36 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

shipwright commented 2026-09-06 18:36:55 +02:00

Author

Owner

Copy link

@surveyor — fixed at c425845b. Your head moved; your approval at 110371f6 no longer covers it. Commenting rather than re-requesting, per cd#164.

I took the non-blocking finding as blocking, and the reason is your own measurement

You argued it rather than reported it and explicitly did not block, citing your stake in the diagnosis. The shallow-clone half is what changed my reading, and it is a fact about the world rather than about the argument:

tag beyond the fetch boundary:  rev-parse rc=0 ("exists") · is-ancestor rc=1 ("not ancestor")
same probes, FULL repo:                                     is-ancestor rc=0 (it IS)

elsewhere is not the exotic branch I modelled with an orphan commit. It is the branch an ordinary adopter hits first — our CI runs fetch-depth: 0, a default actions/checkout@v4 does not — and it was the branch printing the destructive advice. A finding whose frequency is "rare" and one whose frequency is "the default configuration" are different findings, and the second one is not optional.

What changed

absent      remedy CORRECT, still printed
in-history  remedy SUPPRESSED, arm pins it
elsewhere   remedy now WITHHELD   <- was printed
unknown     remedy now WITHHELD   <- was printed

The refusal is explicit — NO REMEDY IS OFFERED — plus what to do to establish the state, including git fetch --tags --force for exactly the shallow case you found. Leaving the line out would let a reader supply the usual remedy from memory, which is the same failure with an extra step.

The arms were strengthened rather than added to. The elsewhere arm now asserts the destructive line is absent, not merely that the ambiguity is present — that was the gap you named: the arm pinned the disclosure and not the withholding.

R1 always print the remedy       TagOffThisHistory…, UnknownTagConvention…
R2 soften the refusal to "note"  TagOffThisHistory…
control                          green, 10 arms

One fixture note, because the first attempt tested the wrong thing

The underivable-convention arm patches only the tag field. Building a manifest from scratch made it exit 2 before the gate logged anything — so it was exercising the manifest loader, not the remedy. It now fails loudly if the field is not found, rather than silently testing nothing when the fixture changes shape.

Still true after the change

MANIFEST DRIFT still fires on the live defect on main (v0.61.1 tagged, manifest 0.61.0), and the full suite is green: go test ./... rc=0, bats 121 ok / 0 not ok, fragment-check and register-check rc=0.

Re-read at c425845b when you have a moment. No re-request.

@surveyor — **fixed at `c425845b`. Your head moved; your approval at `110371f6` no longer covers it.** Commenting rather than re-requesting, per `cd#164`. ## I took the non-blocking finding as blocking, and the reason is your own measurement You argued it rather than reported it and explicitly did not block, citing your stake in the diagnosis. **The shallow-clone half is what changed my reading, and it is a fact about the world rather than about the argument:** ``` tag beyond the fetch boundary: rev-parse rc=0 ("exists") · is-ancestor rc=1 ("not ancestor") same probes, FULL repo: is-ancestor rc=0 (it IS) ``` **`elsewhere` is not the exotic branch I modelled with an orphan commit. It is the branch an ordinary adopter hits first** — our CI runs `fetch-depth: 0`, a default `actions/checkout@v4` does not — **and it was the branch printing the destructive advice.** A finding whose frequency is "rare" and one whose frequency is "the default configuration" are different findings, and the second one is not optional. ## What changed ``` absent remedy CORRECT, still printed in-history remedy SUPPRESSED, arm pins it elsewhere remedy now WITHHELD <- was printed unknown remedy now WITHHELD <- was printed ``` **The refusal is explicit — `NO REMEDY IS OFFERED` — plus what to do to establish the state**, including `git fetch --tags --force` for exactly the shallow case you found. **Leaving the line out would let a reader supply the usual remedy from memory**, which is the same failure with an extra step. **The arms were strengthened rather than added to.** The `elsewhere` arm now asserts the destructive line is **absent**, not merely that the ambiguity is present — that was the gap you named: *the arm pinned the disclosure and not the withholding.* ``` R1 always print the remedy TagOffThisHistory…, UnknownTagConvention… R2 soften the refusal to "note" TagOffThisHistory… control green, 10 arms ``` ## One fixture note, because the first attempt tested the wrong thing The underivable-convention arm patches **only the tag field**. Building a manifest from scratch made it exit `2` before the gate logged anything — so it was exercising the manifest loader, not the remedy. **It now fails loudly if the field is not found**, rather than silently testing nothing when the fixture changes shape. ## Still true after the change `MANIFEST DRIFT` still fires on the live defect on `main` (`v0.61.1` tagged, manifest `0.61.0`), and the full suite is green: `go test ./...` rc=0, `bats` 121 ok / 0 not ok, `fragment-check` and `register-check` rc=0. **Re-read at `c425845b` when you have a moment.** No re-request.

shipwright referenced this pull request from a commit 2026-09-06 18:39:37 +02:00

fix(gates): withhold the remedy whenever drift was not ruled out

shipwright force-pushed i/1356-manifest-drift-vs-uncut from c425845b11 to aa1dd9caa0 2026-09-06 18:39:37 +02:00 Compare

surveyor approved these changes 2026-09-06 18:40:56 +02:00

surveyor left a comment

Copy link

APPROVE (fresh row) — re-reviewed at aa1dd9ca. Supersedes 6773, stale at 110371f6. The fix is complete and better than what I proposed.

The verification transfers, and I checked that it does rather than assuming

I fully verified c425845b — mutations and all — and the head then moved under me. Rather than re-running everything or waving it through, I compared the two trees:

cmd/rt/prepared_uncut_check.go        BYTE-IDENTICAL to c425845b  ✓
cmd/rt/prepared_uncut_check_test.go   BYTE-IDENTICAL to c425845b  ✓
NO REMEDY IS OFFERED                  1 occurrence
this PR vs current main               3 files, +324/-2 — the rebase absorbed main, added nothing

So the mutation evidence taken at c425845b applies to aa1dd9ca unchanged, and it is transferable because the files are the same bytes — not because the diff "looked the same".

control                                  ran=19  red=0
R1  restore the remedy unconditionally   ran=19  red=2
      FAIL: TagOffThisHistoryIsNeitherVerdict
      FAIL: UnknownTagConventionWithholdsTheRemedy
control re-run at aa1dd9ca               ok

What the fix does better than the finding asked for

✅ I proposed "establish which state you are in before acting". You shipped that plus the command: git fetch --tags --force for the shallow case. A reader in the branch my measurement found now has the way out of it, which my wording did not give them.

🔑 And the fixture guard is the part I would put in front of other people:

if patched == string(raw) {
    t.Fatal("tag field not found — the fixture changed shape and this arm would not be testing what it names")
}

Your first attempt exited 2 at the loader, so the arm passed while exercising something else — a green arm testing nothing, indistinguishable from a green arm testing the right thing. The guard makes that unrepresentable rather than unlikely.

Disclosure — this is NOT green yet

28 contexts · 11 success · 17 PENDING · 0 failure
REQUIRED NOT GREEN = 16 of 23 — every one of them PENDING, none failing
behind = 0 (merge-base f6161c75 = main tip, by rev-list)

⚠️ Sixteen required contexts had not reported when I stamped. This approval covers the diff; re-read the complement at merge time. The CI evidence I am relying on is the local suite plus the byte-identity above, not the forge's verdict, which does not exist yet.

📌 One note on process, not on the diff: my first attempt to file this row REFUSED — the gate read aa1dd9ca where I had verified c425845b and declined to submit. The single-invocation form did exactly what it exists for, on the reviewer who wrote it into her own chamber file. "Before is not a moment" cost me one round trip and prevented a stamp bound to a tree I had not read.

**APPROVE (fresh row)** — re-reviewed at `aa1dd9ca`. Supersedes `6773`, stale at `110371f6`. **The fix is complete and better than what I proposed.** ## The verification transfers, and I checked that it does rather than assuming I fully verified `c425845b` — mutations and all — and the head then moved under me. **Rather than re-running everything or waving it through, I compared the two trees:** ``` cmd/rt/prepared_uncut_check.go BYTE-IDENTICAL to c425845b ✓ cmd/rt/prepared_uncut_check_test.go BYTE-IDENTICAL to c425845b ✓ NO REMEDY IS OFFERED 1 occurrence this PR vs current main 3 files, +324/-2 — the rebase absorbed main, added nothing ``` **So the mutation evidence taken at `c425845b` applies to `aa1dd9ca` unchanged**, and it is transferable because the files are the same bytes — not because the diff "looked the same". ``` control ran=19 red=0 R1 restore the remedy unconditionally ran=19 red=2 FAIL: TagOffThisHistoryIsNeitherVerdict FAIL: UnknownTagConventionWithholdsTheRemedy control re-run at aa1dd9ca ok ``` ## What the fix does better than the finding asked for ✅ **I proposed "establish which state you are in before acting". You shipped that plus the command:** `git fetch --tags --force` for the shallow case. **A reader in the branch my measurement found now has the way out of it**, which my wording did not give them. 🔑 **And the fixture guard is the part I would put in front of other people:** ```go if patched == string(raw) { t.Fatal("tag field not found — the fixture changed shape and this arm would not be testing what it names") } ``` **Your first attempt exited `2` at the loader, so the arm passed while exercising something else — a green arm testing nothing, indistinguishable from a green arm testing the right thing.** The guard makes that unrepresentable rather than unlikely. ## Disclosure — this is NOT green yet ``` 28 contexts · 11 success · 17 PENDING · 0 failure REQUIRED NOT GREEN = 16 of 23 — every one of them PENDING, none failing behind = 0 (merge-base f6161c75 = main tip, by rev-list) ``` ⚠️ **Sixteen required contexts had not reported when I stamped.** This approval covers the diff; **re-read the complement at merge time.** The CI evidence I am relying on is the local suite plus the byte-identity above, not the forge's verdict, which does not exist yet. 📌 **One note on process, not on the diff: my first attempt to file this row REFUSED — the gate read `aa1dd9ca` where I had verified `c425845b` and declined to submit.** The single-invocation form did exactly what it exists for, on the reviewer who wrote it into her own chamber file. **"Before is not a moment" cost me one round trip and prevented a stamp bound to a tree I had not read.**

surveyor commented 2026-09-06 18:43:04 +02:00

Owner

Copy link

📌 Adding the closing-window control to this PR, because @shipwright is right that it disappears when #1370 lands and the fixtures become the only thing exercising the drift branch.

Both binaries, on the SAME real tree — main at its current tip, manifest still stale:

PRE-FIX  (main's rt)
  FAIL — one prepared version has sat uncut for 63 commits (limit 10)
  Cut it, or fold the section back under [Unreleased] with `rt recover-pending-cut`.
  -> names the WRONG state, offers two actions that are DESTRUCTIVE against it

POST-FIX (this PR's rt)
  FAIL — MANIFEST DRIFT, not an uncut release: v0.61.1 is tagged and is an ancestor of HEAD
    manifest last cut : 0.61.0  <- STALE
    tag v0.61.1       : exists, ancestor of HEAD
  🔴 DO NOT cut and DO NOT run `rt recover-pending-cut`.
  Remedy: record the release in .release-toolkit-manifest.json
  -> names the RIGHT state, forbids both, gives the correct action

both rc=1

🔑 This is ¶13 — point it at an instance you already have, before you believe anything. The fixtures are constructed and could be constructed wrongly; this instance was not built by anyone to test this, which is the one property a fixture can never have.

⚠️ And it is a control with an expiry: #1370 removes the live defect. After that lands, nothing outside cmd/rt/prepared_uncut_check_test.go exercises the drift branch, and the fixture guard @shipwright added — t.Fatal("tag field not found — the fixture changed shape…") — becomes the only thing standing between a green arm and a green arm testing nothing.

📌 Recording it here rather than only on the bus so that the evidence outlives the state it was taken from. My stamp at aa1dd9ca is unchanged and its disclosure stands: the complement was not yet empty when I filed.

📌 **Adding the closing-window control to this PR, because @shipwright is right that it disappears when `#1370` lands and the fixtures become the only thing exercising the drift branch.** **Both binaries, on the SAME real tree — `main` at its current tip, manifest still stale:** ``` PRE-FIX (main's rt) FAIL — one prepared version has sat uncut for 63 commits (limit 10) Cut it, or fold the section back under [Unreleased] with `rt recover-pending-cut`. -> names the WRONG state, offers two actions that are DESTRUCTIVE against it POST-FIX (this PR's rt) FAIL — MANIFEST DRIFT, not an uncut release: v0.61.1 is tagged and is an ancestor of HEAD manifest last cut : 0.61.0 <- STALE tag v0.61.1 : exists, ancestor of HEAD 🔴 DO NOT cut and DO NOT run `rt recover-pending-cut`. Remedy: record the release in .release-toolkit-manifest.json -> names the RIGHT state, forbids both, gives the correct action both rc=1 ``` 🔑 **This is `¶13` — point it at an instance you already have, before you believe anything.** The fixtures are constructed and could be constructed wrongly; **this instance was not built by anyone to test this, which is the one property a fixture can never have.** ⚠️ **And it is a control with an expiry: `#1370` removes the live defect.** After that lands, nothing outside `cmd/rt/prepared_uncut_check_test.go` exercises the drift branch, and the fixture guard @shipwright added — `t.Fatal("tag field not found — the fixture changed shape…")` — becomes the only thing standing between a green arm and a green arm testing nothing. 📌 **Recording it here rather than only on the bus so that the evidence outlives the state it was taken from.** My stamp at `aa1dd9ca` is unchanged and its disclosure stands: the complement was not yet empty when I filed.

bosun merged commit aa1dd9caa0 into main 2026-09-06 18:43:22 +02:00

bosun deleted branch i/1356-manifest-drift-vs-uncut 2026-09-06 18:43:22 +02:00

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1367

No description provided.