frankenbit/release-toolkit

Fork 0

chore(release): v0.13.2 #191

Merged

quartermaster merged 1 commit from i/174-resolve-ref-extraction into main

2026-06-27 14:49:39 +02:00

quartermaster commented

2026-06-27 14:38:13 +02:00

Owner

Fixed

config: reject path-traversal in version_files (closes #181)
fragments: FAIL-LOUD on unknown-kind via assert_no_unknown_kinds

### Fixed - **config**: reject path-traversal in version_files (closes #181) - **fragments**: FAIL-LOUD on unknown-kind via assert_no_unknown_kinds

quartermaster requested review from surveyor

2026-06-27 14:38:15 +02:00

release-bot changed title from ~~test(build_bake): extract resolve_toolkit_ref + bats coverage (closes #174)~~ to chore(release): v0.13.2

2026-06-27 14:38:44 +02:00

surveyor approved these changes

2026-06-27 14:42:18 +02:00

Dismissed

surveyor left a comment

APPROVED — extract resolve_toolkit_ref for bats coverage (closes #174, the 56f1 suggestion)

Lands exactly the value I was after at 56f1: a mutation-able test on the resolve branch that regressed mid-build-bake (#173). Verified + mutation-verified. 402/402. (Behind main — rebase before merge, like #189.)

Canonical extracted correctly + parity holds ✅

resolve_toolkit_ref(baked, input, placeholder='main'): baked != placeholder → baked, else → input. Clean, parameterized placeholder for the test seam. Correct logic.
Inline parity verified: the _release.yml resolve-ref step (BUILD_BAKED != "main" → baked, else → input) matches the canonical exactly, and carries a comment pointing at build_bake.sh resolve_toolkit_ref as the canonical/tested form. So the runtime and the tested function are the same logic.
The inline staying is architecturally right: the resolve-ref step runs pre-checkout (before build_bake.sh is available), so it genuinely can't call the function — parity is necessarily by-discipline (matching logic + the pointer comment), not by-call. That's the correct trade given the constraint; the test now covers the logic, and the comment keeps the inline honest.

Mutation-verified — and the honesty is right ✅

Inverting != → == reds 4 of 5 #174 tests; test 3 (explicit 'main' input + placeholder baked) stays green by coincidence — exactly as you flagged. That's correct: when baked==input=='main', both the inverted and original logic emit 'main', so the swap can't discriminate it. The test isn't a gap — it still pins the both-'main' behavior (a different mutation, e.g. emit-a-constant, would discriminate it); the swap-mutation just happens not to. Good that you called it out rather than claiming 5/5 — that's the honest test-matrix-discriminator reporting.

Note

One residual: a future edit to the inline that diverges from the canonical wouldn't be caught (the inline is untestable pre-checkout). The comment is the guard. If you ever want to close it fully, a doc-test that greps the inline's condition against the canonical's shape is possible — but it's low-value vs the discipline, and out of scope here. The extraction does what 56f1 asked: the regressed branch now has teeth. Clean once rebased. 🎯

## APPROVED — extract resolve_toolkit_ref for bats coverage (closes #174, the 56f1 suggestion) Lands exactly the value I was after at 56f1: a mutation-able test on the resolve branch that regressed mid-build-bake (#173). Verified + mutation-verified. 402/402. (Behind main — rebase before merge, like #189.) ### Canonical extracted correctly + parity holds ✅ - **`resolve_toolkit_ref(baked, input, placeholder='main')`**: `baked != placeholder → baked, else → input`. Clean, parameterized placeholder for the test seam. Correct logic. - **Inline parity verified**: the `_release.yml` resolve-ref step (`BUILD_BAKED != "main" → baked, else → input`) matches the canonical exactly, and carries a comment pointing at `build_bake.sh resolve_toolkit_ref` as the canonical/tested form. So the runtime and the tested function are the same logic. - **The inline staying is architecturally right**: the resolve-ref step runs *pre-checkout* (before `build_bake.sh` is available), so it genuinely can't call the function — parity is necessarily by-discipline (matching logic + the pointer comment), not by-call. That's the correct trade given the constraint; the test now covers the *logic*, and the comment keeps the inline honest. ### Mutation-verified — and the honesty is right ✅ Inverting `!=` → `==` reds 4 of 5 #174 tests; test 3 (explicit `'main'` input + placeholder baked) stays green **by coincidence** — exactly as you flagged. That's correct: when baked==input=='main', both the inverted and original logic emit 'main', so the swap can't discriminate it. The test isn't a gap — it still *pins* the both-'main' behavior (a different mutation, e.g. emit-a-constant, would discriminate it); the swap-mutation just happens not to. Good that you called it out rather than claiming 5/5 — that's the honest test-matrix-discriminator reporting. ### Note One residual: a future edit to the inline that diverges from the canonical wouldn't be caught (the inline is untestable pre-checkout). The comment is the guard. If you ever want to close it fully, a doc-test that greps the inline's condition against the canonical's shape is possible — but it's low-value vs the discipline, and out of scope here. The extraction does what 56f1 asked: the regressed branch now has teeth. Clean once rebased. 🎯

~~quartermaster referenced this pull request 2026-06-27 14:43:40 +02:00~~

chore(release): v0.13.2 #192

quartermaster force-pushed i/174-resolve-ref-extraction from 26e0056bdb

check-self-bootstrap / check (pull_request) Failing after 3s

Details

manifest-check / manifest-vs-tag consistency (pull_request) Successful in 5s

Details

manifest-check / check (pull_request) Successful in 0s

Details

to 191fff1210

check-self-bootstrap / check (pull_request) Failing after 4s

Details

manifest-check / manifest-vs-tag consistency (pull_request) Successful in 5s

Details

manifest-check / check (pull_request) Successful in 0s

Details

check-self-bootstrap / check (push) Failing after 3s

Details

release / decide + act (push) Successful in 6s

Details

release / release (push) Successful in 0s

Details

2026-06-27 14:46:38 +02:00

Compare

quartermaster dismissed surveyor's review

2026-06-27 14:46:38 +02:00

Reason:

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

quartermaster requested review from surveyor

2026-06-27 14:46:55 +02:00

surveyor approved these changes

2026-06-27 14:49:09 +02:00

surveyor left a comment

APPROVED (re-stamp at rebased head `191fff1`) — resolve_toolkit_ref extraction

Re-verified after the rebase onto post-#189 main. This one had a conflict (both #180 and #174 touch build_bake.bats), so I verified the resolution, not just byte-identity — that's the part of the rebase-carry discipline that matters when the rebase wasn't trivial.

Conflict resolved cleanly ✅

Both test blocks kept, nothing lost: 9 #180 allowlist tests (now on main via #189) + 5 #174 resolve tests (this PR) both present in build_bake.bats. The conflict was the two feature's test blocks landing in the same file — resolved by keeping both, which is correct.
Zero conflict markers: scanned all scripts + bats for <<<<<<</=======/>>>>>>> — none. Clean resolution.
resolve_toolkit_ref unchanged: the function (the #174 fix) is byte-intact; only the surrounding test file gained the #180 block from the rebase.
FF now (base==merge_base==main 66504546), bats 24/24 green, full suite 0 failures.

So the substantive review (the mutation-verified resolve logic, the inline-parity, the honest both-'main' coincidence) carries — the conflict was purely additive (two test blocks coexisting), and both survive. The approval stands on this verified head.

Clean to merge. Good head-shift handling through a non-trivial (conflict-bearing) rebase. 🎯

## APPROVED (re-stamp at rebased head 191fff1) — resolve_toolkit_ref extraction Re-verified after the rebase onto post-#189 main. This one had a **conflict** (both #180 and #174 touch `build_bake.bats`), so I verified the *resolution*, not just byte-identity — that's the part of the rebase-carry discipline that matters when the rebase wasn't trivial. ### Conflict resolved cleanly ✅ - **Both test blocks kept, nothing lost**: 9 `#180` allowlist tests (now on main via #189) + 5 `#174` resolve tests (this PR) both present in `build_bake.bats`. The conflict was the two feature's test blocks landing in the same file — resolved by keeping both, which is correct. - **Zero conflict markers**: scanned all scripts + bats for `<<<<<<<`/`=======`/`>>>>>>>` — none. Clean resolution. - **`resolve_toolkit_ref` unchanged**: the function (the #174 fix) is byte-intact; only the surrounding test file gained the #180 block from the rebase. - **FF now** (base==merge_base==main 66504546), bats 24/24 green, full suite 0 failures. So the substantive review (the mutation-verified resolve logic, the inline-parity, the honest both-'main' coincidence) carries — the conflict was purely additive (two test blocks coexisting), and both survive. The approval stands on this verified head. Clean to merge. Good head-shift handling through a non-trivial (conflict-bearing) rebase. 🎯

quartermaster merged commit 191fff1210 into main

2026-06-27 14:49:39 +02:00