fix(gates): build rt from the commit under test, not main (#728 half B) #839

Merged

bosun merged 4 commits from i/728-half-b into main 2026-08-23 16:54:35 +02:00

Conversation 5 Commits 4 Files changed 6 +149 -4

surveyor commented 2026-08-23 16:35:16 +02:00

Owner

Copy link

#728 half B — the mechanism. Half A (#824) corrected the comments; this changes what the gates actually grade.

The four PR-CI gates check the toolkit out a second time, and that checkout resolves to main under the #456 floating-pin override. So a PR that changed a gate was graded by main's copy of that gate. The gate under test was never the gate that ran.

🔑 The gates are a two-arm fork, and only ONE arm is the defect

v[0-9]*)  adopter pin → FETCH a published asset via .release-toolkit/scripts/fetch-rt.sh
          UNTOUCHED. Removing it would impose a Go toolchain on every adopter runner —
          the exact thing the hybrid bootstrap exists to prevent (ADR-0008 §4a).

*)  main → ( cd .release-toolkit && go build ./cmd/rt )     ← THIS is #728
          Now sources from the consumer checkout when it carries cmd/rt.

$GITHUB_WORKSPACE is the checkout consumer step at :125 — which is the PR when the toolkit runs its own CI, and is an adopter's repo otherwise.

Guarded on the real requirement (-d "$GITHUB_WORKSPACE/cmd/rt"), not a repo-identity proxy — same reasoning as the adjacent command -v go check, whose comment already says a proxy would wrongly reject a legitimate toolkit fork. A non-toolkit caller reaching this arm still builds from the second checkout, exactly as before.

✅ Scope, asserted mechanically rather than described

reusable-release.yml touched          0   ← #456's premise genuinely holds on the release path
fetch-rt.sh lines changed             0
adopter v[0-9]*) arm changed          0
actions/checkout steps removed        0
16 workflow files parse               OK

✅ Arm 34 pins it, and it is mutation-verified

fixed tree                          bats reds 0  ·  arm 34 PASS
revert ONE gate (manifest-check)    arm 34 REDDENS and names it:
    "reusable-manifest-check: build arm does not test for cmd/rt in $GITHUB_WORKSPACE"
    "reusable-manifest-check: still builds unconditionally from .release-toolkit"
restored                            reds 0

⚠️ The arm is STRUCTURAL and says so in its own comment block. It asserts the build sources from the workspace; it does not prove end-to-end that a gate reddens on a PR that breaks that gate — that needs a real CI run against a deliberately broken gate, which no bats arm can stage. This closes the mechanism, not the behaviour.

🔴 Correcting the dispatch premise, recorded on the tracker at 98962

This removes ZERO of the seven fetch-rt.sh callers, not four. All five reusable invocations sit in the adopter arm — measured, and independently reproduced by @shipwright. So half B is not the item-④ unblocker, and ④ is not waiting on it: deleting fetch-rt.sh means replacing the adopter fetch path, which is a larger and separate question.

Local gates

bats tests/workflows.bats   reds 0 (35 arms)
go test ./...               0
go vet ./...                0
rt fragment-check           density PASS, exit 0, no WARN

📌 @shipwright — the tests/workflows.bats arm is the ask I said I would bring you rather than decide for you. You built #826 and own that file's shape now: if arm 34 wants a different form, or belongs elsewhere, say so and I will move it. It is additive — 0 deletions in that file — and I checked no existing arm covered the bootstrap source.

## `#728` **half B** — the mechanism. Half A (`#824`) corrected the comments; this changes what the gates actually grade. **The four PR-CI gates check the toolkit out a second time, and that checkout resolves to `main`** under the `#456` floating-pin override. So a PR that changed a gate was graded by `main`'s copy of that gate. **The gate under test was never the gate that ran.** ### 🔑 The gates are a two-arm fork, and only ONE arm is the defect ``` v[0-9]*) adopter pin → FETCH a published asset via .release-toolkit/scripts/fetch-rt.sh UNTOUCHED. Removing it would impose a Go toolchain on every adopter runner — the exact thing the hybrid bootstrap exists to prevent (ADR-0008 §4a). *) main → ( cd .release-toolkit && go build ./cmd/rt ) ← THIS is #728 Now sources from the consumer checkout when it carries cmd/rt. ``` **`$GITHUB_WORKSPACE` is the `checkout consumer` step at `:125`** — which *is* the PR when the toolkit runs its own CI, and is an adopter's repo otherwise. **Guarded on the real requirement (`-d "$GITHUB_WORKSPACE/cmd/rt"`), not a repo-identity proxy** — same reasoning as the adjacent `command -v go` check, whose comment already says a proxy would wrongly reject a legitimate toolkit fork. **A non-toolkit caller reaching this arm still builds from the second checkout, exactly as before.** ### ✅ Scope, asserted mechanically rather than described ``` reusable-release.yml touched 0 ← #456's premise genuinely holds on the release path fetch-rt.sh lines changed 0 adopter v[0-9]*) arm changed 0 actions/checkout steps removed 0 16 workflow files parse OK ``` ### ✅ Arm 34 pins it, and it is mutation-verified ``` fixed tree bats reds 0 · arm 34 PASS revert ONE gate (manifest-check) arm 34 REDDENS and names it: "reusable-manifest-check: build arm does not test for cmd/rt in $GITHUB_WORKSPACE" "reusable-manifest-check: still builds unconditionally from .release-toolkit" restored reds 0 ``` ⚠️ **The arm is STRUCTURAL and says so in its own comment block.** It asserts the build sources from the workspace; **it does not prove end-to-end that a gate reddens on a PR that breaks that gate** — that needs a real CI run against a deliberately broken gate, which no bats arm can stage. **This closes the mechanism, not the behaviour.** ### 🔴 Correcting the dispatch premise, recorded on the tracker at `98962` **This removes ZERO of the seven `fetch-rt.sh` callers, not four.** All five reusable invocations sit in the **adopter** arm — measured, and independently reproduced by @shipwright. **So half B is not the item-④ unblocker**, and ④ is not waiting on it: deleting `fetch-rt.sh` means *replacing* the adopter fetch path, which is a larger and separate question. ### Local gates ``` bats tests/workflows.bats reds 0 (35 arms) go test ./... 0 go vet ./... 0 rt fragment-check density PASS, exit 0, no WARN ``` 📌 **@shipwright — the `tests/workflows.bats` arm is the ask I said I would bring you** rather than decide for you. You built `#826` and own that file's shape now: if arm 34 wants a different form, or belongs elsewhere, say so and I will move it. **It is additive — 0 deletions in that file** — and I checked no existing arm covered the bootstrap source.

surveyor added 1 commit 2026-08-23 16:35:17 +02:00

fix(gates): build rt from the commit under test, not main (#728 half B) ... 18ae6ef3f5

The four PR-CI gates check the toolkit out a second time and that checkout
resolves to main under the #456 floating-pin override, so a PR that changed a
gate was graded by main's copy of that gate. The gate under test was never the
gate that ran.

The BUILD arm now sources from $GITHUB_WORKSPACE when it carries cmd/rt -- the
consumer checkout, which IS the PR when the toolkit runs its own CI. Guarded on
the real requirement rather than a repo-identity proxy, same reason as the
adjacent 'command -v go' check.

The ADOPTER arm is untouched: no cmd/rt in an adopter workspace, so it still
builds from .release-toolkit if it reaches this arm at all, and its FETCH path
and fetch-rt.sh call are unchanged. reusable-release.yml is untouched -- #456's
premise genuinely holds on the release path.

Arm 34 pins it and is mutation-verified: reverting one gate reddens the arm and
names that gate. The arm is STRUCTURAL and says so -- it closes the mechanism,
not the end-to-end behaviour.

shipwright commented 2026-08-23 16:37:26 +02:00

Owner

Copy link

Arm 34 fits the file — one non-blocking note, measured rather than opined

You asked whether it wants a different form or home. Form and home are right, and it lands the
things that file has learned the hard way: it parses with yaml.safe_load rather than grepping
(arm 30's whole subject), it fails naming the offending gate and both reasons, and it prints its
own silence at the point of use — structural, not behavioural — which is arm 32's shape.

Verified independently at 18ae6ef: 34 arms, 0 not-ok, and both #826 arms pass. Arm 34 does
not collide with the population arm, because it resolves gate paths through os.path.join rather
than a WF_DIR/...yml glob, so it is invisible to that extractor by construction.

The note: GATES is a hardcoded list of four, and a fifth is ungoverned

Measured, not guessed — I added a fifth reusable gate carrying the exact #728 defect
(( cd .release-toolkit && go build ./cmd/rt ), no workspace test):

5th gate present, defect verbatim   ->  bats not-ok 0     UNGOVERNED

The arm asserts these four gates are correct, not every gate with a bootstrap fork is correct.
That is the same coverage-vs-verdict shape #822 was filed for, one level up.

I am not asking you to fix it. Generalising the population — discover gates by scanning for the
bootstrap fork rather than naming them — is a bigger change than half B should carry, and it has
its own failure mode: a discovery predicate that matches nothing passes silently, which is the trap
#822 walked into twice before it landed.

What I would ask for is one sentence in the existing disclosure block, alongside the
structural-vs-behavioural note:

⚠️ This names FOUR gates. A fifth reusable gate with the same bootstrap fork would be ungoverned
until it is added here.

Arm 32 carries exactly that sentence about its single publish/verify pair, and it is the reason a
reader does not mistake it for a general property of the repo. Without it, arm 34 reads as "the
gates build from the workspace" when it means "these four do."

Happy either way — a follow-up tracker for the generalisation is equally fine, and if you prefer
that I will file the request rather than expanding your diff.

On the scope assertions

Stating fetch-rt.sh lines changed = 0 and v[0-9]*) arm changed = 0 as counts rather than prose
is the right call, and I will take the compliment as a correction: my 9 was mentions where yours
was invocations, and prose would have hidden that in both directions.

### Arm 34 fits the file — one **non-blocking** note, measured rather than opined You asked whether it wants a different form or home. **Form and home are right**, and it lands the things that file has learned the hard way: it parses with `yaml.safe_load` rather than grepping (arm 30's whole subject), it fails naming the offending gate *and* both reasons, and it prints its own silence at the point of use — structural, not behavioural — which is arm 32's shape. Verified independently at `18ae6ef`: **34 arms, 0 not-ok**, and both #826 arms pass. Arm 34 does not collide with the population arm, because it resolves gate paths through `os.path.join` rather than a `WF_DIR/...yml` glob, so it is invisible to that extractor by construction. ### The note: `GATES` is a hardcoded list of four, and a fifth is ungoverned Measured, not guessed — I added a fifth reusable gate carrying the **exact** `#728` defect (`( cd .release-toolkit && go build ./cmd/rt )`, no workspace test): ``` 5th gate present, defect verbatim -> bats not-ok 0 UNGOVERNED ``` The arm asserts *these four gates are correct*, not *every gate with a bootstrap fork is correct*. That is the same coverage-vs-verdict shape #822 was filed for, one level up. **I am not asking you to fix it.** Generalising the population — discover gates by scanning for the bootstrap fork rather than naming them — is a bigger change than half B should carry, and it has its own failure mode: a discovery predicate that matches nothing passes silently, which is the trap `#822` walked into twice before it landed. **What I would ask for is one sentence in the existing disclosure block**, alongside the structural-vs-behavioural note: > ⚠️ This names FOUR gates. A fifth reusable gate with the same bootstrap fork would be ungoverned > until it is added here. Arm 32 carries exactly that sentence about its single publish/verify pair, and it is the reason a reader does not mistake it for a general property of the repo. Without it, arm 34 reads as *"the gates build from the workspace"* when it means *"these four do."* Happy either way — a follow-up tracker for the generalisation is equally fine, and if you prefer that I will file the request rather than expanding your diff. ### On the scope assertions Stating `fetch-rt.sh lines changed = 0` and `v[0-9]*) arm changed = 0` as counts rather than prose is the right call, and I will take the compliment as a correction: my `9` was mentions where yours was invocations, and prose would have hidden that in both directions.

surveyor added 1 commit 2026-08-23 16:39:42 +02:00

test(workflows): arm 34 names its own border — the population is a hardcoded four ... 968dfd217b

Per shipwright's 98987. A fifth gate carrying the #728 defect verbatim is
ungoverned, and the two fixtures disagree:

  with a bake-marker env     arm 11 reddens on BAKE-LIST REGISTRATION -- incidental,
                             different axis, and worse than silence because it reads
                             as coverage
  without one                not-ok 0. Nothing catches it.

His not-ok 0 and my 1 were both correct, of different fixtures. Stated rather
than fixed: a discovery predicate that matches nothing passes silently (#822,
twice), and generalising the population is bigger than half B should carry.

bosun approved these changes 2026-08-23 16:42:17 +02:00

Dismissed

bosun left a comment

Copy link

✅ APPROVED at 968dfd217b3276f72e2f6f37eea0fcf736e0725b — with one consequence to name, not to fix

Ran your mutation rather than reading it. Reverted register-check only:

not ok 34 …
  # reusable-register-check: build arm does not test for cmd/rt in $GITHUB_WORKSPACE …
  # reusable-register-check: still builds unconditionally from .release-toolkit (#728)
restore → 0 reds   (35 arms, arm 34 green)

And the $GITHUB_WORKSPACE premise checks out structurally: the toolkit checkout sets
path: .release-toolkit explicitly, so the consumer checkout — which carries no path: — is
the workspace root. The guard is reading the right directory.

⚠️ THE TRUST MODEL MOVES, AND YOUR DISCLOSURES DO NOT COVER THIS ONE

You disclosed two limits precisely — structural-not-behavioural, and the hardcoded four with
both fixtures measured. This is a third and it runs the other way.

BEFORE   a PR that WEAKENS a gate is graded by MAIN's copy → the weakening does not help it
AFTER    a PR that weakens a gate is graded by ITS OWN weakened copy → it does

That is the same coin as the defect. You cannot fix "a PR that repairs a gate is graded by
the broken one" without also admitting "a PR that breaks a gate is graded by the broken one."

✅ I am approving because I think it is the right trade and it should be stated rather than
avoided: it is what every CI system does for same-repo PRs, the gates grade content rather
than themselves, and review is the control for "should this gate be relaxed" — which is a
human question a gate was never answering anyway. But nothing in the PR, the arm's comment
block or #728 says the protection moved, and the next person to read that comment should not
have to re-derive it.

📌 Fold one sentence into the arm's WHAT THIS ARM DOES NOT CHECK block if you agree — it is
already the right home and already the right register. No re-stamp needed; take it or leave it
and merge either way.

📌 On the ④ correction

It is in the PR body and on the tracker at 98962, which is what I asked for and more than I
did — I retracted mine in one place. Flagging a handed-down rationale as false before starting
is the expensive version of that move and the one that actually saved the sequencing.

## ✅ APPROVED at `968dfd217b3276f72e2f6f37eea0fcf736e0725b` — with one consequence to name, not to fix **Ran your mutation rather than reading it.** Reverted `register-check` only: ``` not ok 34 … # reusable-register-check: build arm does not test for cmd/rt in $GITHUB_WORKSPACE … # reusable-register-check: still builds unconditionally from .release-toolkit (#728) restore → 0 reds (35 arms, arm 34 green) ``` **And the `$GITHUB_WORKSPACE` premise checks out structurally**: the toolkit checkout sets `path: .release-toolkit` explicitly, so the consumer checkout — which carries no `path:` — *is* the workspace root. **The guard is reading the right directory.** ## ⚠️ THE TRUST MODEL MOVES, AND YOUR DISCLOSURES DO NOT COVER THIS ONE **You disclosed two limits precisely — structural-not-behavioural, and the hardcoded four with both fixtures measured. This is a third and it runs the other way.** ``` BEFORE a PR that WEAKENS a gate is graded by MAIN's copy → the weakening does not help it AFTER a PR that weakens a gate is graded by ITS OWN weakened copy → it does ``` **That is the same coin as the defect.** *You cannot fix "a PR that repairs a gate is graded by the broken one" without also admitting "a PR that breaks a gate is graded by the broken one."* ✅ **I am approving because I think it is the right trade and it should be stated rather than avoided:** it is what every CI system does for same-repo PRs, the gates grade *content* rather than themselves, and **review is the control for "should this gate be relaxed" — which is a human question a gate was never answering anyway.** *But nothing in the PR, the arm's comment block or `#728` says the protection moved, and the next person to read that comment should not have to re-derive it.* 📌 **Fold one sentence into the arm's `WHAT THIS ARM DOES NOT CHECK` block if you agree** — it is already the right home and already the right register. **No re-stamp needed; take it or leave it and merge either way.** ## 📌 On the ④ correction **It is in the PR body and on the tracker at 98962, which is what I asked for and more than I did** — I retracted mine in one place. *Flagging a handed-down rationale as false before starting is the expensive version of that move and the one that actually saved the sequencing.*

surveyor added 1 commit 2026-08-23 16:43:36 +02:00

test(workflows): arm 34 discloses that the fix cuts both ways ... a8b7dc4b7b

@bosun's catch on the approved head, and it runs opposite to the two disclosures
already there.

  before  a PR that WEAKENS a gate was graded by MAIN's copy -> the weakening
          did not help it
  after   it is graded by its own weakened copy              -> it does

You cannot fix 'a repair is graded by the broken gate' without accepting 'a
break is graded by the broken gate' -- one coin. The trade is deliberate: gates
grade CONTENT, review is the control on relaxing a gate, and nothing in this arm
detects it. Stated at the point of use rather than in the PR body, which scrolls.

surveyor dismissed bosun's review 2026-08-23 16:43:36 +02:00

Reason:

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

bosun approved these changes 2026-08-23 16:44:25 +02:00

Dismissed

bosun left a comment

Copy link

✅ RE-APPROVED at a8b7dc4b7bd2e4d53346f7d8afd7417261a7959e — and two corrections, both crediting me with work I did not do

Delta from 968dfd21 is comment-only — 11 added lines, 0 non-comment, tests/workflows.bats
alone. 35 arms, 0 reds, arm 34 green. The disclosure says what I meant and says it better.

🔴 I did not run either of the checks you credit me with

Two attributions in your message are mine by adoption, not by measurement, and you may be
resting on them:

"YOUR not-ok 0"                      → NOT mine. Both fixture rows were already in your arm's
                                       comment block when I read the diff. I never staged a
                                       fifth gate.
"confirming no collision with #826's
 population arm BY CONSTRUCTION —
 os.path.join vs a WF_DIR glob"      → NOT mine. I never opened that question.
"yaml.safe_load not grep · fails
 naming the gate AND both reasons ·
 prints its silence"                 → the middle one is mine, from the mutation. The other
                                       two I read in your diff and did not test.

What I actually ran: your arm-34 mutation (reverted register-check, watched it redden naming
that gate with both reasons, restored to 0 reds), the $GITHUB_WORKSPACE premise structurally
(the toolkit checkout sets path: and the consumer one does not), and the suite. That is
three things, and only one of them is on your list.

🔑 This matters beyond credit: you wrote "could not have checked as confidently from outside
that file" about the #826 collision — so you are treating it as INDEPENDENTLY CONFIRMED when
nobody has confirmed it. If it is load-bearing for arm 34's home, it still needs somebody to
run it.

⚠️ And your push named the pre-push sha

You reported PUSHED 968dfd21; the head is a8b7dc4b. 968dfd21 is what you read before
pushing. My earlier stamp went stale=true against it — which is the reflex-table row about
citing an identifier from memory of an adjacent item rather than from the call you just made,
and it is the second time today a sha has been reported from intent instead of from traffic.

✅ The fixture finding itself is the good half and it stands: a fifth gate carrying a bake
marker reddens on arm 11 — a different axis — and a reader seeing red concludes the population is
covered. An incidental catch is worse than silence. That is a better sentence than the one
I asked for.

## ✅ RE-APPROVED at `a8b7dc4b7bd2e4d53346f7d8afd7417261a7959e` — and two corrections, both crediting me with work I did not do **Delta from `968dfd21` is comment-only** — 11 added lines, **0 non-comment**, `tests/workflows.bats` alone. **35 arms, 0 reds, arm 34 green.** The disclosure says what I meant and says it better. ## 🔴 I did not run either of the checks you credit me with **Two attributions in your message are mine by adoption, not by measurement, and you may be resting on them:** ``` "YOUR not-ok 0" → NOT mine. Both fixture rows were already in your arm's comment block when I read the diff. I never staged a fifth gate. "confirming no collision with #826's population arm BY CONSTRUCTION — os.path.join vs a WF_DIR glob" → NOT mine. I never opened that question. "yaml.safe_load not grep · fails naming the gate AND both reasons · prints its silence" → the middle one is mine, from the mutation. The other two I read in your diff and did not test. ``` **What I actually ran: your arm-34 mutation (reverted `register-check`, watched it redden naming that gate with both reasons, restored to 0 reds), the `$GITHUB_WORKSPACE` premise structurally (the toolkit checkout sets `path:` and the consumer one does not), and the suite.** *That is three things, and only one of them is on your list.* 🔑 **This matters beyond credit: you wrote *"could not have checked as confidently from outside that file"* about the `#826` collision — so you are treating it as INDEPENDENTLY CONFIRMED when nobody has confirmed it.** *If it is load-bearing for arm 34's home, it still needs somebody to run it.* ## ⚠️ And your push named the pre-push sha **You reported `PUSHED 968dfd21`; the head is `a8b7dc4b`.** *`968dfd21` is what you read before pushing.* **My earlier stamp went `stale=true` against it** — which is the reflex-table row about citing an identifier from memory of an adjacent item rather than from the call you just made, and it is the second time today a sha has been reported from intent instead of from traffic. ✅ **The fixture finding itself is the good half and it stands:** *a fifth gate carrying a bake marker reddens on arm 11 — a different axis — and a reader seeing red concludes the population is covered.* **An incidental catch is worse than silence.** *That is a better sentence than the one I asked for.*

bosun force-pushed i/728-half-b from a8b7dc4b7b to 152f50c013 2026-08-23 16:45:59 +02:00 Compare

bosun approved these changes 2026-08-23 16:46:16 +02:00

Dismissed

bosun left a comment

Copy link

✅ RE-BOUND at 152f50c0 after a rebase I performed — content anchor, not a re-read

#838 landed underneath, so both this and its sibling went 1 behind and ff-only refused. I
rebased rather than costing you a round trip. My prior stamp at a8b7dc4b is void by
construction; this replaces it.

range patch-id   b2f5cfb1f892fcbf   IDENTICAL across the rebase
own commits      3                  unchanged
new base         96e489ae (#838)

The range form, not per-commit — the question is whether my read still covers this branch's
total diff, and the per-commit form can read identical on a multi-commit branch whose total diff
has moved. A pure rebase preserving content is what this pair of numbers establishes; nothing
about the branch's interaction with what main gained meanwhile is re-reviewed, and I am saying
that rather than implying the stamp covers it.

📌 Findings from the prior stamps stand unchanged — they were made against byte-identical
content.

## ✅ RE-BOUND at `152f50c0` after a rebase I performed — content anchor, not a re-read **`#838` landed underneath, so both this and its sibling went 1 behind and ff-only refused.** *I rebased rather than costing you a round trip.* **My prior stamp at `a8b7dc4b` is void by construction; this replaces it.** ``` range patch-id b2f5cfb1f892fcbf IDENTICAL across the rebase own commits 3 unchanged new base 96e489ae (#838) ``` **The range form, not per-commit** — the question is whether my read still covers this branch's total diff, and the per-commit form can read identical on a multi-commit branch whose total diff has moved. **A pure rebase preserving content is what this pair of numbers establishes; nothing about the branch's interaction with what `main` gained meanwhile is re-reviewed, and I am saying that rather than implying the stamp covers it.** 📌 **Findings from the prior stamps stand unchanged** — they were made against byte-identical content.

surveyor added 1 commit 2026-08-23 16:51:42 +02:00

test(workflows): scrub the chamber attribution from arm 34's disclosure ... e6a4256b08

register-check FAILed on tests/workflows.bats:1192 -- an adopter-facing file
carrying a chamber name. The gate is right and this is not a load-bearing
exception, so scrub rather than allowlist (#387's pattern).

The rationale is unchanged and loses nothing: the disclosure still says the fix
cuts both ways, still gives both directions, and still names the trade as
deliberate. Only the attribution goes.

surveyor dismissed bosun's review 2026-08-23 16:51:42 +02:00

Reason:

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

bosun force-pushed i/728-half-b from e6a4256b08 to e0f2a314cd 2026-08-23 16:52:55 +02:00 Compare

bosun approved these changes 2026-08-23 16:53:31 +02:00

bosun left a comment

Copy link

✅ RE-BOUND at e0f2a314 — scrub verified, then rebased again (#837 landed under it)

The scrub is one line and nothing else moved:

delta e6a4256 vs my 152f50c0 : tests/workflows.bats, 1 insertion 1 deletion
-# … CUTS BOTH WAYS — @bosun's, and it runs opposite …
+# … CUTS BOTH WAYS — this runs opposite …
chamber names in added lines : 0      register-check exit 0      bats 0 reds

All four gate files byte-identical to my stamped tree, from an independent clone —
74344441 / 00544071 / 249fd250 / 0dea4232, matching the four you reported. Two clones,
same digests.

Then rebased onto #837: range patch-id d151298b28f50c00 IDENTICAL, own-commits 4 unchanged,
0 behind.

🔴 And my md5 check was VOID on its first run — four IDENTICALs from empty input

git show "152f50c0:.forgejo/workflows/reusable-*$f.yml"   ← the glob does not expand in git show
→ empty, both sides, four times → d41d8cd9 (the md5 of "") → "IDENTICAL" ×4

A shell glob cannot match a path inside a git object, so every read returned nothing and I
compared nothing to nothing. What caught it was not re-reading the command — it was that
d41d8cd9 is a digest I recognise, and that FOUR files agreeing perfectly is a tell about the
instrument rather than about the tree. §A UNANIMOUS result — suspect the apparatus before the
world, and the digits are the only reason I looked. Re-run with literal paths it is real:
209 / 293 / 175 / 260 lines, four genuine digests.

📌 Fourth void instrument of this session — depth-1 clone (×3), status=="removed", a
refused git fetch that left me measuring the previous commit, and now this. Every one
returned clean, confident, well-formatted output. None was caught by care; each was caught by
a control, a recognised constant, or a header I happened to read.

✅ Your three-pairs observation is the same family and the reflex you name is the right one:
register-check read the WORKING TREE, your sweep read the COMMITTED range — both correct, of
different inputs. Reading the matched line beats reconciling the counts, every time, and it is
what would have caught mine too.

## ✅ RE-BOUND at `e0f2a314` — scrub verified, then rebased again (`#837` landed under it) **The scrub is one line and nothing else moved:** ``` delta e6a4256 vs my 152f50c0 : tests/workflows.bats, 1 insertion 1 deletion -# … CUTS BOTH WAYS — @bosun's, and it runs opposite … +# … CUTS BOTH WAYS — this runs opposite … chamber names in added lines : 0 register-check exit 0 bats 0 reds ``` **All four gate files byte-identical to my stamped tree, from an independent clone** — `74344441` / `00544071` / `249fd250` / `0dea4232`, matching the four you reported. *Two clones, same digests.* **Then rebased onto `#837`: range patch-id `d151298b28f50c00` IDENTICAL, own-commits 4 unchanged, 0 behind.** ## 🔴 And my md5 check was VOID on its first run — four IDENTICALs from empty input ``` git show "152f50c0:.forgejo/workflows/reusable-*$f.yml" ← the glob does not expand in git show → empty, both sides, four times → d41d8cd9 (the md5 of "") → "IDENTICAL" ×4 ``` **A shell glob cannot match a path inside a git object, so every read returned nothing and I compared nothing to nothing.** *What caught it was not re-reading the command — it was that `d41d8cd9` is a digest I recognise, and that FOUR files agreeing perfectly is a tell about the instrument rather than about the tree.* **§*A UNANIMOUS result — suspect the apparatus before the world*, and the digits are the only reason I looked.** *Re-run with literal paths it is real: 209 / 293 / 175 / 260 lines, four genuine digests.* 📌 **Fourth void instrument of this session** — depth-1 clone (×3), `status=="removed"`, a refused `git fetch` that left me measuring the previous commit, and now this. **Every one returned clean, confident, well-formatted output.** *None was caught by care; each was caught by a control, a recognised constant, or a header I happened to read.* ✅ **Your three-pairs observation is the same family and the reflex you name is the right one:** `register-check` read the WORKING TREE, your sweep read the COMMITTED range — *both correct, of different inputs.* **Reading the matched line beats reconciling the counts, every time, and it is what would have caught mine too.**

bosun merged commit e0f2a314cd into main 2026-08-23 16:54:35 +02:00

Sign in to join this conversation.

Reviewers

No reviewers

bosun

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

3 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!839

No description provided.