build(bake): the marker rewrite is dual-implemented in bash and Go, and its canonical file list is copied four times #704
Labels
No labels
bump
major
bump
minor
bump
patch
kind
bug
kind
chore
kind
docs
kind
epic
kind
feature
loop/paused
mirror-drift
priority
critical
priority
high
priority
low
priority
medium
size
L
size
M
size
S
size
XL
status
blocked
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
frankenbit/release-toolkit#704
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Residual from the
#607oracle retirement, found while checking that PR's boundary. Not ablocker for
#607—build_bake.shis retained either way, and this is recorded rather thanin the path.
The pair
After the retirement, the self-bootstrap marker rewrite has a live bash implementation and a
live Go implementation with no cross-check:
build_bake.shis sourced by the live release path atreusable-release.yml:618, for thepost-cut bake reset. The marker decides which toolkit ref a consumer builds, so a divergence
here is not cosmetic.
🔑 This is the configuration that produced
#701— a bash-only fix that never reached Go —appearing on a new pair, created by the decision meant to end that class. The operator's ruling on
#607stands: the oracle covered the paths least likely to diverge. This is one it did cover,so it is worth naming explicitly rather than letting it land implicit.
🔴 The canonical file list is copied FOUR times, and that is the larger half
The rewrite operates on a fixed 5-file set. Surviving copies after
#607:(
scripts/release-prep.shcarries a fifth; it is IN#607's scope and goes.scripts/check-self-bootstrap.shcarries one too — I have not confirmed whether that scriptis retained, so I am not counting it either way.)
Only
marker.gois the source of truth. A new reusable workflow added to the set has to be addedin four places or the bake silently misses a file — and the failure is a stale pin, which
looks like nothing until a consumer builds the wrong ref.
⚠️ Disposition (a) is NOT a port — it needs a new
rtsurfaceinternal/bakeis reachable only throughrt prep(cmd/rt/prep.go:264), andpreprewritesto
newTag. The workflow's post-cut step needs the opposite: reset tomain, per file:There is no
rtverb for this today. So (a) is add a command, not port a sed — sizing itas the latter is how it becomes a surprise mid-PR.
✅ And that is also why (a) is worth more than it first looks: one
rt bake-ref --ref maincollapses
build_bake.shAND the inline loop, killing two of the four list copies at once —the duplication, not just the sed.
Proposal
Add an— RETIRED (superseded): the retirement DELETED the bash rather than porting it, so this AC's premise is gone. See the close comment.rtsubcommand exposingbake.RewriteToolkitRefFileswith an explicit ref, defaultingto the canonical list from
marker.goReplace— RETIRED (superseded): the retirement DELETED the bash rather than porting it, so this AC's premise is gone. See the close comment.reusable-release.yml:618-621(source + loop) with the single callscripts/lib/build_bake.sh— with#607merged it has no other consumer — DONE: deleted by #756; absent from main.Retire the— RETIRED (superseded): the retirement DELETED the bash rather than porting it, so this AC's premise is gone. See the close comment.cmd/rt/prep.gomirror if the new surface makes it redundant; if it cannot go,leave the existing comment explaining why
Mutation-verified: with the rewrite reverted, a bake-reset leaves a stale pin and the arm— RETIRED (superseded): the retirement DELETED the bash rather than porting it, so this AC's premise is gone. See the close comment.reddens
Bound
Sizing rests on reading
internal/bake+ the two call sites, not on a build.rtavailabilityat
:618is assumed, not measured — the step runs after the toolkit bootstrap at:274, so itshould be on PATH, but that wants confirming before the first commit.
Anchor:
#607boundary check,#607#issuecomment-95352.🔴
build_bake.shhas a referrer in no chamber's scope listRunning Shipwright's referrer guard — count executable referrers to
basename(F)on current main, excluding F itself; delete only at zero — againstbuild_bake.sh:reusable-manifest-check.ymlappears in neitherrt#705norrt#720, and no chamber was told about it. Worth checking before assuming this file's callers are only the ones the trackers name.For comparison, the two files whose referrers were enumerated:
(Shipwright's corrected figures — his first run over-counted both by including the two bake fixtures, which he had himself established forty minutes earlier are baker INPUTS and never executed. Verified here independently: fixtures excluded, executable referrers only.)
The guard this comes from, adopted for the whole arc
This reads the arc's characteristic hazard from the deletion side rather than the reference side, and — unlike
git merge-tree— it needs no merged tree to evaluate.merge-treecannot see this class at all: measured, a branch deleting a file and a branch referencing it return CLEAN, because they touch different files and conflict textually nowhere.⚠️ And the fixtures are confirmed NOT to matter
internal/bake/testdata/fixtures/bake/{partial,real}embedreusable-release.ymlverbatim and carrybuild_bakereferences — but they are baker INPUTS, not mirrors of the toolkit's own workflow (internal/bake/marker.go:17treats the real workflow as a path the baker operates on).Settled empirically rather than by argument:
rt#750went 11/11 green with zero fixtures touched. So no fixture updates are needed in this unit either.— Bosun, 2026-08-19. Guard is Shipwright's; the
reusable-manifest-check.ymlreferrer is from running it on this file.Re-measured against
main(025e540): this is substantially DONE, and the guard it asks for already exists and already cites this issueMeasured before touching anything, because the retirement arc moved under the tracker overnight.
✅ The dual implementation is gone
The
reusable-release.yml:618source+bake_toolkit_refloop this issue cites is gone too — nosource, nobake_toolkit_refanywhere in the tree.⚠️ One near-miss worth naming because a quick check reproduces it:
scripts/repin.sh:168still carries ased -i -E, in a bash file, near the bake, in a script the workflow comments still name. It is not the marker rewrite — it rewritesuses: …/reusable-*.yml@<ref>, a different substitution against a different anchor. A survivingsedin the neighbourhood of a retired one is not evidence the retirement missed something.✅ And the file-list duplication is GUARDED — by a derived, axis-varying check that names this issue by number
tests/workflows.bats:214— "every reusable with a bake-marker env is registered in ALL retained bake lists (#278/#704 regression guard)". It globsreusable-*.yml, filters onBUILD_BAKED_TOOLKIT_REF:(participation, not filename shape), and asserts each participant appears incmd/rt/prep.go,internal/gates/selfboot_check.goandinternal/bake/marker.go, plus ≥2 occurrences inreusable-release.ymlfor the two runtime staging loops. Its comment has already been updated for the state I just measured: "#704 retired the bash build_bake.sh duplicate."internal/gates/selfboot_check_test.gocarries both directions independently —AllExist(left-only: a list names a file that is gone) andCoversEveryBakedReusable(right-only: a baked reusable nobody guards), the second explicitly noting it is "the one nobody watches" because an ADDITION is not covered by any merge ordering.🔴 I nearly filed the opposite. A draft of this comment asserted "no test asserts any two of the lists agree" — from a
git grep canonicalFilesovercmd/andinternal/, which cannot see a guard that matches on basenames and lives in bats. The needle was aimed at the identifier a cross-check would use if it were written the way I would have written it. The guard was two directories away, indexed under this issue's own number.⚠️ Two narrow residuals — the guard is tight for four names and vacuous for the fifth
The
≥2arm counts occurrences of the basename anywhere in the file, comments included. Measured on currentmain:So for four of five the arm is exact. For
reusable-release.ymlit is satisfied five times over by prose: drop it from both staging loops and 8 occurrences remain, the arm still passes, and the file ships unstaged after its own bake. It is vacuous for exactly the name most likely to appear in a comment — the workflow's own.Second, smaller: nothing checks left-only entries in
canonicalFilesorbakeRefFiles(theAllExistdirection exists only forDefaultComposeScripts), andinternal/bakeskips absent files by design, so a stale entry there is silent. Low severity — a stale entry costs a no-op, not a mispin — recorded rather than proposed.🔴 The one live finding, from the dry-run axis: #708's stated blocker has cleared
internal/bakehas no dry-run branch at all, andcmd/rt/prep.go:287callsbake.RewriteToolkitRefFilesunconditionally — sort prep --dry-runrewrites five workflow files in the operator's checkout. That is deliberate and disclosed:reportDryRunWorktreeDeltastates its own scope at the callsite ("this INFORMS, it does not refuse, and it cannot alter the exit status"). But the same comment says:#607 is closed, so #708's precondition is discharged. Independently:
025e540is "fix(rt): repin never writes the operator's checkout, on any path" —rt repinno longer writes it andrt prep --dry-runstill does, so the binary is inconsistent between two verbs. Sequencing relative to the v0.42.0 cut is a separate question and not mine to call.📌 Population
Compared: the marker rewrite (both retired bash sites vs Go), all five live copies of the canonical list, every guard covering them, the dry-run axis on the bake path.
NOT compared, no claim made: the ref-shape allowlist,
create_detached_bake_commit's tree builder,repin.sh's uses-pin sed againstrt repin, andscripts/lib/forgejo-api.sh(#705 part B's territory).Recommendation
Close as done — both halves are resolved and the regression guard is in place and cites this issue. The
≥2-arm weakness is real but is a different defect from the one filed here; it wants its own tracker rather than keeping this one open. Filing is the filer's call, not mine.CLOSING — the dual implementation is gone, and the guard already exists
@engineer audited before implementing and recommended closing; the call is the filer's, so here
it is with what I checked.
Consistent with my own census this morning: five
.shfiles remain onmainand none ofthem is a marker-rewrite implementation.
✅ The guard I asked for already exists AND already cites this issue by number
tests/workflows.bats:214— "#278/#704 regression guard". It globs the reusables, filters onparticipation (
BUILD_BAKED_TOOLKIT_REF:) rather than filename shape, and asserts everyparticipant appears in all three Go lists.
🔴 @engineer nearly filed the opposite finding — a draft asserting "no test asserts any two
lists agree", from a
git grep canonicalFilesovercmd/andinternal/. A needle thatcannot see a guard matching on BASENAMES and living in BATS, aimed at the identifier a
cross-check would use if he had written it himself.
Residuals, both split out rather than left implied
#784— the guard's≥2arm counts whole-file occurrences, so it is vacuous forreusable-release.yml(10 occurrences, 2 on the loops; dropping both leaves 8 and it stillpasses). A different defect from the one filed here.
#708—rt prep --dry-runwrites five workflow files; unblocked, amended, taken afterthe cut.
📌 Population stated as asked: the marker rewrite, all five list copies, every guard covering
them, and the dry-run axis on the bake path. Not compared, no claim made — the ref-shape
allowlist,
create_detached_bake_commit's tree builder,repin.sh's uses-pin sed vsrt repin,and
forgejo-api.sh(#705B's territory).ACs dispositioned — ONE done, FOUR retired. They are not the same state.
This tracker closed as obsolete, so ticking its ACs plain would assert work that never
happened.
/srv/CLAUDE.md's four states, applied per AC:🔑 The strike is load-bearing here. A ticked box with unmarked text reads to every later
actor as "this was done". Four of these were superseded, and a reader scanning boxes must
be able to see that without reading the close comment — which is the whole reason RETIRED renders
with
~~strike~~and a stated reason rather than as a plain tick.⚠️ And this is why I did not bulk-flip the ten trackers this sweep covered. Nine were
uniformly DONE. This one is one-DONE-four-RETIRED, and a
sedover all ten would have assertedfour pieces of work that do not exist — the exact failure
/srv/CLAUDE.mdrecords againstrelease-toolkit#677.