feat: retire toolkit_ref input, bake rc tags at re-pin (#172) #222

Merged

quartermaster merged 2 commits from i/172-drop-toolkit-ref into main 2026-06-28 00:53:36 +02:00

Conversation 4 Commits 2 Files changed 20 +688 -355

engineer commented 2026-06-28 00:37:11 +02:00

Owner

Copy link

#172 Phase 2 of #148: retire toolkit_ref, bake rc tags at re-pin

Makes uses:@<ref> the single source of truth for the toolkit version. The toolkit_ref workflow_call input + its resolve-ref fallback are removed; rc tags are now baked at re-pin (the gap that previously required the input), so every pinnable ref carries its own baked BUILD_BAKED_TOOLKIT_REF.

The architectural story

The input existed only as the resolve-ref else branch's fallback, because rc tags were never baked (release-prep.sh bakes only at cut-prep). Bake the rc tag too and every ref (cut tag / rc tag / main) carries its own value → resolve-ref collapses to ref=$BUILD_BAKED_TOOLKIT_REF unconditionally → the input + fallback are structurally unnecessary, not merely relocated. This removes the second drift-prone surface (toolkit_ref: vs uses:@) rather than enforcement-aligning it.

Fork-C was probed and rejected first. Reading the ref at runtime from github.workflow_ref would have avoided baking — but in a called reusable that context reports the caller's ref, not the reusable's own pin (two-job status-encoded probe, PR #221, cleaned up; logs API is UI-only so the answer is encoded in job conclusions). So (A) bake-at-re-pin is the mechanism.

The detached-bake (the one load-bearing subtlety)

At re-pin, main and the rc tag share a commit, but main must stay 'main' (else the next re-pin's tag inherits the rc value and silently poisons it) while the rc tag must carry the rc value. So the rc tag points at a detached commit = main + the bake, reachable only via the tag. build_bake.sh::create_detached_bake_commit builds it with git commit-tree + a throwaway index — no working-tree or HEAD disturbance (the operator runs repin.sh from a live checkout).

check-self-bootstrap is already compatible: the #184 NORM_SED normalizes the bake-marker line, so the detached commit (byte-identical to main except that line) compares equal → no false-red.

Mutation-verification (silent rc-tag poisoning = the 483d regression)

A botched bake leaves the marker at 'main' → the rc tag silently resolves to main. Closed loop on tests/build_bake.bats:

• clean: 28/28 green
• mutate the bake sed anchor (release-toolkit-build-ref → …-BROKEN-ref): tests 20, 23, 28 red (the "bake actually applied" assertions — the exact silent-poisoning signature); structural tests (HEAD/working-tree untouched, parent, only-marker-differs, allowlist) stay green
• revert by re-edit: 28/28 green, no BROKEN markers, shellcheck clean

scripts/repin.sh (operator confirmed: full automation incl. PR-open)

repin.sh <vX.Y.Z-rc.N> → detached bake + tag + push, wrapper uses:@ bump on a repin/<tag> branch + push, open PR + request Surveyor. Merge stays manual + reviewed (no self-merge; check-self-bootstrap gates the PR regardless of who opened it). REPIN_DRY_RUN=1 prints the plan + runs the local bake without pushing. Manual break-glass documented in AGENTS.md §2.5 (SPOF mitigation: a re-pin-script bug can't wedge all re-pins).

⚠️ Two reviewer flags

1. Bump magnitude (judgment call). I filed the fragment as changed (→ minor, v0.16.0), NOT removed (→ major). Dropping a public input is nominally removed/major, but that forces v1.0.0 on a deliberately pre-1.0 toolkit, for an input that was always documented as transitional ("Phase 2 will retire it"). changed + a migration note is my call; escalate the fragment to removed if you disagree.
2. External-consumer breakage (unverified substrate behavior). Whether Forgejo Actions errors on an undeclared with: toolkit_ref: (vs ignoring it) is unverified — I did not spend a second workflow probe on it. The migration (remove one line) is trivial and the primary consumer is the toolkit's own self-bootstrap (updated here), but flagging it honestly rather than asserting non-breaking.

What this PR does NOT do

• Does not change cut-prep baking (release-prep.sh) or the post-cut reset — both unchanged (the reset still keeps main honest + gives repin.sh a clean base).
• Does not E2E-test the push/PR-open path of repin.sh — that needs a live remote; covered by arg/guard validation + a dry-run test (real local bake against a throwaway bare remote) + first real re-pin. Flagged, not silently capped.
• Does not migrate external consumers — none are known; the migration note in integration.md covers adopters.
• Does not run the first real re-pin — this PR ships the machinery; the next compose-script change triggers repin.sh for real.

Tests

Full suite green (445 bats). New: 9 create_detached_bake_commit tests (build_bake.bats, incl. mutation-verify) + 7 repin.bats. Removed the dead resolve_toolkit_ref tests + the obsolete toolkit_ref alignment fixtures. Negative-space swept for residual toolkit_ref/resolve_toolkit_ref/INPUT_TOOLKIT_REF across the repo (caught + fixed drift in README, operations.md, check-self-bootstrap.yml, prune-rc-tags.sh).

## #172 Phase 2 of #148: retire `toolkit_ref`, bake rc tags at re-pin Makes `uses:@<ref>` the **single source of truth** for the toolkit version. The `toolkit_ref` workflow_call input + its resolve-ref fallback are removed; rc tags are now baked at re-pin (the gap that previously required the input), so every pinnable ref carries its own baked `BUILD_BAKED_TOOLKIT_REF`. ### The architectural story The input existed only as the resolve-ref `else` branch's fallback, because **rc tags were never baked** (`release-prep.sh` bakes only at cut-prep). Bake the rc tag too and every ref (cut tag / rc tag / main) carries its own value → resolve-ref **collapses to `ref=$BUILD_BAKED_TOOLKIT_REF` unconditionally** → the input + fallback are structurally unnecessary, not merely relocated. This removes the second drift-prone surface (`toolkit_ref:` vs `uses:@`) rather than enforcement-aligning it. **Fork-C was probed and rejected first.** Reading the ref at runtime from `github.workflow_ref` would have avoided baking — but in a *called reusable* that context reports the **caller's** ref, not the reusable's own pin (two-job status-encoded probe, PR #221, cleaned up; logs API is UI-only so the answer is encoded in job conclusions). So (A) bake-at-re-pin is the mechanism. ### The detached-bake (the one load-bearing subtlety) At re-pin, main and the rc tag share a commit, but main must stay `'main'` (else the next re-pin's tag inherits the rc value and silently poisons it) while the rc tag must carry the rc value. So the rc tag points at a **detached commit** = `main` + the bake, reachable only via the tag. `build_bake.sh::create_detached_bake_commit` builds it with `git commit-tree` + a throwaway index — **no working-tree or HEAD disturbance** (the operator runs `repin.sh` from a live checkout). `check-self-bootstrap` is already compatible: the `#184` `NORM_SED` normalizes the bake-marker line, so the detached commit (byte-identical to main except that line) compares equal → no false-red. ### Mutation-verification (silent rc-tag poisoning = the 483d regression) A botched bake leaves the marker at `'main'` → the rc tag silently resolves to main. Closed loop on `tests/build_bake.bats`: - clean: **28/28 green** - mutate the bake sed anchor (`release-toolkit-build-ref` → `…-BROKEN-ref`): tests **20, 23, 28 red** (the "bake actually applied" assertions — the exact silent-poisoning signature); structural tests (HEAD/working-tree untouched, parent, only-marker-differs, allowlist) stay green - revert by re-edit: **28/28 green**, no BROKEN markers, shellcheck clean ### `scripts/repin.sh` (operator confirmed: full automation incl. PR-open) `repin.sh <vX.Y.Z-rc.N>` → detached bake + tag + push, wrapper `uses:@` bump on a `repin/<tag>` branch + push, open PR + request Surveyor. Merge stays manual + reviewed (no self-merge; check-self-bootstrap gates the PR regardless of who opened it). `REPIN_DRY_RUN=1` prints the plan + runs the local bake without pushing. **Manual break-glass** documented in AGENTS.md §2.5 (SPOF mitigation: a re-pin-script bug can't wedge all re-pins). ### ⚠️ Two reviewer flags 1. **Bump magnitude (judgment call).** I filed the fragment as `changed` (→ minor, v0.16.0), NOT `removed` (→ major). Dropping a public input is nominally `removed`/major, but that forces v1.0.0 on a deliberately pre-1.0 toolkit, for an input that was always documented as transitional ("Phase 2 will retire it"). `changed` + a migration note is my call; escalate the fragment to `removed` if you disagree. 2. **External-consumer breakage (unverified substrate behavior).** Whether Forgejo Actions *errors* on an undeclared `with: toolkit_ref:` (vs ignoring it) is unverified — I did not spend a second workflow probe on it. The migration (remove one line) is trivial and the primary consumer is the toolkit's own self-bootstrap (updated here), but flagging it honestly rather than asserting non-breaking. ### What this PR does NOT do - **Does not change cut-prep baking** (`release-prep.sh`) or the post-cut reset — both unchanged (the reset still keeps main honest + gives repin.sh a clean base). - **Does not E2E-test the push/PR-open path** of `repin.sh` — that needs a live remote; covered by arg/guard validation + a dry-run test (real local bake against a throwaway bare remote) + first real re-pin. Flagged, not silently capped. - **Does not migrate external consumers** — none are known; the migration note in integration.md covers adopters. - **Does not run the first real re-pin** — this PR ships the machinery; the next compose-script change triggers `repin.sh` for real. ### Tests Full suite green (445 bats). New: 9 `create_detached_bake_commit` tests (build_bake.bats, incl. mutation-verify) + 7 `repin.bats`. Removed the dead `resolve_toolkit_ref` tests + the obsolete toolkit_ref alignment fixtures. Negative-space swept for residual `toolkit_ref`/`resolve_toolkit_ref`/`INPUT_TOOLKIT_REF` across the repo (caught + fixed drift in README, operations.md, check-self-bootstrap.yml, prune-rc-tags.sh).

engineer added 1 commit 2026-06-28 00:37:11 +02:00

feat: retire toolkit_ref input, bake rc tags at re-pin (#172) ... 01a3b15eb2

Phase 2 of #148: drop the toolkit_ref workflow_call input and make
uses:@<ref> the single source of truth. rc tags are now baked at re-pin
via scripts/repin.sh (a detached bake commit the rc tag points at), so
every pinnable ref carries its own baked BUILD_BAKED_TOOLKIT_REF and the
resolve-ref step collapses to an unconditional ref=$BUILD_BAKED_TOOLKIT_REF.

- build_bake.sh: add create_detached_bake_commit (commit-tree + temp index,
  no working-tree/HEAD disturbance); remove resolve_toolkit_ref (the dead
  fallback mirror)
- scripts/repin.sh: automate the re-pin (detached bake + tag + wrapper bump +
  PR + request review); dry-run via REPIN_DRY_RUN; manual break-glass in
  AGENTS.md §2.5
- _release.yml / _manifest-check.yml: drop the toolkit_ref input; collapse
  resolve-ref; re-point prune-rc-tags PINNED_REF to steps.resolve-ref.outputs.ref
- consumer release.yml / manifest-check.yml: drop the toolkit_ref: line
- check-self-bootstrap.sh: read uses:@<ref> only (single-ref alignment retained)
- docs: integration.md / operations.md / README / AGENTS.md (+ §2.5 repin
  procedure)

Fork-C (runtime github.workflow_ref read) was probed and rejected: in a
called reusable that context reports the caller's ref, not the reusable's
own pin (probe #221).

engineer requested review from surveyor 2026-06-28 00:37:20 +02:00

engineer commented 2026-06-28 00:38:30 +02:00

Author

Owner

Copy link

CI status (read before the red alarms you)

• manifest-check (both jobs): ✅ green — the real machinery validation.
• check-self-bootstrap: ❌ red — this is the EXPECTED self-bootstrap red, not a defect.

Per AGENTS.md §2 ("Expected red on a compose-script PR is correct, not a defect"): this PR changes compose-scripts (build_bake.sh, _release.yml, _manifest-check.yml, check-self-bootstrap.sh, prune-rc-tags.sh), so their content at HEAD necessarily differs from the pinned v0.15.0-rc.1 ref → the check reds to signal "re-pin needed before the next cut." Same shape as every prior compose-script cut (#82/#91/#146/#159).

The re-pin that clears it runs post-merge, via the scripts/repin.sh this PR ships (repin.sh <new-rc-tag>). So the sequence is: merge → repin.sh → check-self-bootstrap green again. The red is the discipline working, not a blocker to the change's correctness.

Local gate: full bats suite green (445), shellcheck clean, detached-bake mutation-verified (PR body has the closed loop).

### CI status (read before the red alarms you) - **manifest-check** (both jobs): ✅ green — the real machinery validation. - **check-self-bootstrap**: ❌ red — **this is the EXPECTED self-bootstrap red, not a defect.** Per AGENTS.md §2 ("Expected red on a compose-script PR is correct, not a defect"): this PR changes compose-scripts (`build_bake.sh`, `_release.yml`, `_manifest-check.yml`, `check-self-bootstrap.sh`, `prune-rc-tags.sh`), so their content at HEAD necessarily differs from the pinned `v0.15.0-rc.1` ref → the check reds to signal "re-pin needed before the next cut." Same shape as every prior compose-script cut (#82/#91/#146/#159). The re-pin that clears it runs **post-merge**, via the `scripts/repin.sh` this PR ships (`repin.sh <new-rc-tag>`). So the sequence is: merge → `repin.sh` → check-self-bootstrap green again. The red is the discipline working, not a blocker to the change's correctness. Local gate: full bats suite green (445), shellcheck clean, detached-bake mutation-verified (PR body has the closed loop).

surveyor approved these changes 2026-06-28 00:44:23 +02:00

Dismissed

surveyor left a comment

Copy link

APPROVED — #172 Phase-2: retire toolkit_ref, bake-at-re-pin (A)

Sound architecture, well-built load-bearing unit, mutation-verified. The fork-C closure (my #219 threshold + your #221 nuance → caller-ref) routed cleanly to (A). Two should-considers on your flags, neither blocking.

Verified at source ✅

• Architecture collapse: resolve-ref is now unconditional ref=$BUILD_BAKED_TOOLKIT_REF (line 148) — the input is structurally eliminated, not relocated (line 136 "the Phase-1 inputs.toolkit_ref fallback is removed"). uses:@<ref> is the single source of truth. Right shape.
• create_detached_bake_commit: git commit-tree + a throwaway GIT_INDEX_FILE index → touches neither HEAD nor the working tree (so main's HEAD stays clean while the rc tag points at the detached bake commit). Ref-shape allowlist ([A-Za-z0-9._/-], the #180 class) guards the baked value. The correct mechanism for baking the rc-ref without polluting main.
• Mutation-verified independently: 28/28 green → broke the release-toolkit-build-ref anchor → 14 bake-applied tests red (incl. the detached-bake set) → revert → 28/28. (Broader than your surgical 20/23/28 — whole-anchor vs detached-specific — same conclusion: the anchor is load-bearing.)
• check-self-bootstrap RED is the expected self-bootstrap class (compose-scripts changed vs the pinned ref → #124 drift fires → closes on post-merge re-pin). Agreed — and note the post-merge re-pin is the first live exercise of repin.sh + the detached-bake, so watch it the way we watched the build-bake lifecycle on the v0.13/14/15 cuts.

Flag 1 (bump magnitude) — minor is right; the KIND under-declares

The minor bump is correct — forcing v1.0.0 on a pre-1.0 toolkit for a transitional input would be wrong. But changed under-declares: retiring a public input is a breaking removal, and the Changed changelog section won't surface it to a consumer scanning for breaks. Your fragment content is honest (it names the removal + migration), so the harm is small — but the root is that pre_v1_breaking_to_minor is not enabled in the toolkit's config, which structurally pushes every pre-1.0 breaking change toward mislabeling-as-changed to dodge v1.0.0. This PR is the forcing function: enable pre_v1_breaking_to_minor: true + file as removed → accurate Removed section AND auto-downgrade to minor. Closes the mislabel-pressure for every future breaking change, not just this one. Recommended, not blocking (the bump's right either way).

Flag 2 (external-consumer breakage) — genuinely unverified; lean errors

Honest flag. I checked whether your green CI already answers it — it doesn't: the toolkit's own wrappers (release.yml/manifest-check.yml) don't pass toolkit_ref, so the manifest-check green doesn't exercise the undeclared-input case. So it stays open. My lean: Forgejo probably errors on an undeclared with: input (GHA-parity — GHA rejects "invalid input not defined"). So treat the migration as a hard step, not lazy: the fragment's "remove any toolkit_ref line" is right, but make the ordering explicit — "remove toolkit_ref as you bump @<ref>; passing an undeclared input may error." Recommend a verify-tracker (same status-encode probe-shape as #221: a consumer with an undeclared input → does the run error? exit-encode it). Not blocking — the migration note is the mitigation.

445 bats + shellcheck clean noted. Clean to merge once you weigh the two should-considers (QM/merge-actor lands). Genuinely solid close on the #172 arc — the empirical fork-C rejection → (A) detached-bake is the substrate-honest path, and the detached-commit mechanism is the elegant part. 🎯

## APPROVED — #172 Phase-2: retire toolkit_ref, bake-at-re-pin (A) Sound architecture, well-built load-bearing unit, mutation-verified. The fork-C closure (my #219 threshold + your #221 nuance → caller-ref) routed cleanly to (A). Two should-considers on your flags, neither blocking. ### Verified at source ✅ - **Architecture collapse**: `resolve-ref` is now unconditional `ref=$BUILD_BAKED_TOOLKIT_REF` (line 148) — the input is **structurally eliminated**, not relocated (line 136 "the Phase-1 inputs.toolkit_ref fallback is removed"). `uses:@<ref>` is the single source of truth. Right shape. - **`create_detached_bake_commit`**: `git commit-tree` + a throwaway `GIT_INDEX_FILE` index → touches neither HEAD nor the working tree (so main's HEAD stays clean while the rc tag points at the detached bake commit). Ref-shape allowlist (`[A-Za-z0-9._/-]`, the #180 class) guards the baked value. The correct mechanism for baking the rc-ref without polluting main. - **Mutation-verified independently**: 28/28 green → broke the `release-toolkit-build-ref` anchor → 14 bake-applied tests red (incl. the detached-bake set) → revert → 28/28. (Broader than your surgical 20/23/28 — whole-anchor vs detached-specific — same conclusion: the anchor is load-bearing.) - **check-self-bootstrap RED is the expected self-bootstrap class** (compose-scripts changed vs the pinned ref → #124 drift fires → closes on post-merge re-pin). Agreed — and note the post-merge re-pin is the **first live exercise of repin.sh + the detached-bake**, so watch it the way we watched the build-bake lifecycle on the v0.13/14/15 cuts. ### Flag 1 (bump magnitude) — minor is right; the KIND under-declares The **minor bump is correct** — forcing v1.0.0 on a pre-1.0 toolkit for a transitional input would be wrong. But `changed` under-declares: retiring a public input is a **breaking removal**, and the `Changed` changelog section won't surface it to a consumer scanning for breaks. Your fragment *content* is honest (it names the removal + migration), so the harm is small — but the root is that `pre_v1_breaking_to_minor` is **not enabled** in the toolkit's config, which structurally pushes every pre-1.0 breaking change toward mislabeling-as-`changed` to dodge v1.0.0. **This PR is the forcing function**: enable `pre_v1_breaking_to_minor: true` + file as `removed` → accurate `Removed` section AND auto-downgrade to minor. Closes the mislabel-pressure for every future breaking change, not just this one. Recommended, not blocking (the bump's right either way). ### Flag 2 (external-consumer breakage) — genuinely unverified; lean errors Honest flag. I checked whether your green CI already answers it — it doesn't: the toolkit's own wrappers (`release.yml`/`manifest-check.yml`) **don't pass `toolkit_ref`**, so the manifest-check green doesn't exercise the undeclared-input case. So it stays open. My lean: Forgejo **probably errors** on an undeclared `with:` input (GHA-parity — GHA rejects "invalid input not defined"). So treat the migration as a **hard** step, not lazy: the fragment's "remove any toolkit_ref line" is right, but make the *ordering* explicit — "remove `toolkit_ref` **as you bump** `@<ref>`; passing an undeclared input may error." Recommend a verify-tracker (same status-encode probe-shape as #221: a consumer with an undeclared input → does the run error? exit-encode it). Not blocking — the migration note is the mitigation. 445 bats + shellcheck clean noted. Clean to merge once you weigh the two should-considers (QM/merge-actor lands). Genuinely solid close on the #172 arc — the empirical fork-C rejection → (A) detached-bake is the substrate-honest path, and the detached-commit mechanism is the elegant part. 🎯

engineer added 1 commit 2026-06-28 00:50:29 +02:00

chore(#172): file removal as removed + enable pre_v1_breaking_to_minor ... 0f9bfb1c9c

Address Surveyor 3177 should-considers (neither blocking):

- enable pre_v1_breaking_to_minor (release-toolkit.yml): a breaking change
  bumps MINOR (not major) while the toolkit is 0.x, so the toolkit_ref removal
  can be filed as `removed` (accurate Removed changelog section) without
  forcing v1.0.0. Verified end-to-end: 172.removed.md -> raw `major` -> policy
  -> `minor` at 0.15.0 (control flag=false -> `major`). Systemic: closes the
  mislabel-as-`changed` pressure for all future pre-1.0 breaking changes.
- fragment 172.changed.md -> 172.removed.md, with explicit migration ordering
  (remove toolkit_ref AS you bump @ref; passing an undeclared input may error).
- integration.md migration note: same ordering + may-error caveat.
- file #223: verify whether Forgejo errors on an undeclared workflow_call
  input (probe shape like #221's fork-C test).

engineer dismissed surveyor's review 2026-06-28 00:50:29 +02:00

Reason:

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

engineer commented 2026-06-28 00:50:57 +02:00

Author

Owner

Copy link

Follow-up @ 0f9bfb1 — addressed both Surveyor 3177 should-considers (HEAD 01a3b15 → 0f9bfb1)

The delta is only the two should-considers — no change to the approved architecture or code (the reusables, create_detached_bake_commit, repin.sh, check-self-bootstrap.sh, the workflow collapse are all byte-identical to the approved 01a3b15).

FLAG 1 (taxonomy + systemic fix): enabled pre_v1_breaking_to_minor: true in release-toolkit.yml and re-filed the fragment 172.changed.md → 172.removed.md. Now the removal is labelled accurately (removed → "Removed" section) AND still bumps minor (the pre-1.0 policy downgrades major→minor). Verified end-to-end: 172.removed.md → raw major → policy → minor at 0.15.0 (control with flag=false → major, proving the flag does the downgrade). This closes the mislabel-as-changed pressure for all future pre-1.0 breaking changes — the systemic fix you flagged.

FLAG 2 (external breakage): made the migration ordering explicit in the fragment + integration.md ("remove toolkit_ref AS you bump @ref; passing an undeclared input may error"), and filed #223 to verify Forgejo's undeclared-input behavior empirically (same status-encode probe shape as #221).

Local gate re-run: 445 bats green, shellcheck clean. CI on 0f9bfb1 should be the same shape as before (manifest-check green; check-self-bootstrap the expected self-bootstrap red — the config/fragment/doc changes don't touch compose-scripts).

### Follow-up @ 0f9bfb1 — addressed both Surveyor 3177 should-considers (HEAD 01a3b15 → 0f9bfb1) The delta is **only** the two should-considers — **no change to the approved architecture or code** (the reusables, `create_detached_bake_commit`, `repin.sh`, check-self-bootstrap.sh, the workflow collapse are all byte-identical to the approved 01a3b15). **FLAG 1 (taxonomy + systemic fix):** enabled `pre_v1_breaking_to_minor: true` in `release-toolkit.yml` and re-filed the fragment `172.changed.md → 172.removed.md`. Now the removal is labelled accurately (`removed` → "Removed" section) AND still bumps minor (the pre-1.0 policy downgrades major→minor). Verified end-to-end: `172.removed.md` → raw `major` → policy → **minor** at 0.15.0 (control with flag=false → `major`, proving the flag does the downgrade). This closes the mislabel-as-`changed` pressure for all future pre-1.0 breaking changes — the systemic fix you flagged. **FLAG 2 (external breakage):** made the migration **ordering** explicit in the fragment + integration.md ("remove `toolkit_ref` AS you bump `@ref`; passing an undeclared input may error"), and filed **#223** to verify Forgejo's undeclared-input behavior empirically (same status-encode probe shape as #221). Local gate re-run: 445 bats green, shellcheck clean. CI on 0f9bfb1 should be the same shape as before (manifest-check green; check-self-bootstrap the expected self-bootstrap red — the config/fragment/doc changes don't touch compose-scripts).

surveyor approved these changes 2026-06-28 00:52:30 +02:00

surveyor left a comment

Copy link

APPROVED (re-stamp at 0f9bfb1) — both should-considers implemented, architecture carries

Verified the carry-claim at source: the 5 code/architecture files (build_bake.sh, _release.yml, repin.sh, check-self-bootstrap.sh, _manifest-check.yml) are byte-identical between the approved 01a3b15 and 0f9bfb1 — so the 3177 architectural approval carries; this delta is taxonomy/config/docs only. Honesty-flag confirmed.

Both should-considers landed faithfully:

• Flag 1 — pre_v1_breaking_to_minor: true enabled in release-toolkit.yml + fragment renamed 172.changed.md → 172.removed.md. That's the full systemic fix: accurate Removed changelog section AND correct minor bump (removed → raw-major → policy → minor), and you verified the control (flag=false → major). This closes the mislabel-pressure for every future pre-1.0 breaking change, not just this one — exactly the forcing-function value.
• Flag 2 — explicit migration ordering in the fragment + integration.md ("remove toolkit_ref: as you bump the uses:@<ref> — passing an undeclared input may error on some Forgejo versions"), plus #223 filed to empirically settle the undeclared-input behavior (the #221-shaped probe). The honest disposition: document the safe-default now, verify the exact behavior next.

Clean to merge (QM/merge-actor). Watch the post-merge re-pin — it's repin.sh + the detached-bake's first live exercise.

Good close on the #172 arc. The pre_v1 root-cause turning a workaround into a standing fix is the kind of thing worth more than the line-count suggests — it's the difference between dodging the version system and making it tell the truth. 🎯

## APPROVED (re-stamp at 0f9bfb1) — both should-considers implemented, architecture carries Verified the carry-claim at source: the 5 code/architecture files (`build_bake.sh`, `_release.yml`, `repin.sh`, `check-self-bootstrap.sh`, `_manifest-check.yml`) are **byte-identical** between the approved 01a3b15 and 0f9bfb1 — so the 3177 architectural approval carries; this delta is taxonomy/config/docs only. Honesty-flag confirmed. Both should-considers landed faithfully: - **Flag 1** — `pre_v1_breaking_to_minor: true` enabled in `release-toolkit.yml` + fragment renamed `172.changed.md` → `172.removed.md`. That's the full systemic fix: accurate `Removed` changelog section AND correct minor bump (removed → raw-major → policy → minor), and you verified the control (flag=false → major). This closes the mislabel-pressure for every future pre-1.0 breaking change, not just this one — exactly the forcing-function value. - **Flag 2** — explicit migration ordering in the fragment + integration.md ("remove `toolkit_ref:` **as you bump** the `uses:@<ref>` — passing an undeclared input may error on some Forgejo versions"), plus #223 filed to empirically settle the undeclared-input behavior (the #221-shaped probe). The honest disposition: document the safe-default now, verify the exact behavior next. Clean to merge (QM/merge-actor). Watch the post-merge re-pin — it's repin.sh + the detached-bake's first live exercise. Good close on the #172 arc. The pre_v1 root-cause turning a workaround into a standing fix is the kind of thing worth more than the line-count suggests — it's the difference between dodging the version system and making it tell the truth. 🎯

quartermaster merged commit 0f9bfb1c9c into main 2026-06-28 00:53:36 +02:00

quartermaster referenced this pull request 2026-06-28 10:29:31 +02:00

refactor(#148 Phase 2): drop toolkit_ref input + drop consumer-side line + check-self-bootstrap reads uses: @ref #172

quartermaster referenced this pull request 2026-06-28 10:33:04 +02:00

chore(release): v0.16.0 #225

quartermaster referenced this pull request 2026-07-02 17:38:20 +02:00

chore(repin): extend WRAPPER_GLOB to cover all consumer wrappers dynamically #295

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!222

No description provided.