chore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.13.0-rc.1 #176

Merged
quartermaster merged 1 commit from i/re-pin-v0.13.0-rc.1 into main 2026-06-27 11:38:08 +02:00

Summary

In-cycle re-pin following the #173 build-bake Phase 1 merge per AGENTS.md section 2 mechanism-of-touch. Pins consumer wrappers to v0.13.0-rc.1 so the v0.13.0 cut runs at code that has the bake mechanism + resolve-ref fallback + self-pin exclusion + cellblock-safe cross-version prefix-guard all active.

Changes

  • .forgejo/workflows/release.yml: _release.yml@v0.12.0-rc.1@v0.13.0-rc.1 + toolkit_ref: v0.13.0-rc.1
  • .forgejo/workflows/manifest-check.yml: _manifest-check.yml@v0.12.0-rc.1@v0.13.0-rc.1 + toolkit_ref: v0.13.0-rc.1

Both wrappers (4 surfaces) in lockstep per Surveyor f0a7 + pending #163.

Verification

$ ./scripts/check-self-bootstrap.sh
[check-self-bootstrap] pinned toolkit_ref: v0.13.0-rc.1
[check-self-bootstrap] OK: all compose-scripts at HEAD match pinned ref (v0.13.0-rc.1)

grep -rn 'v0.12.0-rc.1' .forgejo/workflows/ → clean.

Resolve-ref empirical trace (Surveyor 483d watch-target)

Per the fix Surveyor approved on #173 c59176f:

  • _release.yml@v0.13.0-rc.1's BUILD_BAKED_TOOLKIT_REF env var is 'main' (initial placeholder; bake doesn't run at rc-tag time)
  • resolve-ref step: BAKED='main' != 'main'? NO → falls back to inputs.toolkit_ref='v0.13.0-rc.1'
  • Checkout uses v0.13.0-rc.1 → toolkit scripts loaded from v0.13.0-rc.1 → verified rc-pinned scripts run

Workflow log line expected at the cut: resolved toolkit ref: v0.13.0-rc.1 (source=input-fallback; baked still at initial placeholder)

After v0.13.0 cut: _release.yml@v0.13.0 will have BUILD_BAKED_TOOLKIT_REF='v0.13.0' (sed-baked by release-prep.sh at prep-commit time). The next cycle's workflow at @v0.13.0 will take the baked branch:
resolved toolkit ref: v0.13.0 (source=baked)

Next on merge

  1. Merge re-pin → push:main fires release.yml @v0.13.0-rc.1 (NEW code w/ resolve-ref)
  2. resolve-ref → input-fallback → check out toolkit @v0.13.0-rc.1
  3. release-decide → REFRESHES the existing v0.12.0 rolling PR (now to v0.13.0 — feat from #173)
  4. Surveyor section 6 verify-at-source on the refreshed rolling PR
  5. Cut v0.13.0 → release-prep.sh's bake fires → prep commit has BUILD_BAKED_TOOLKIT_REF='v0.13.0'
  6. Auto-prune fires for v0.13.0-rc.* (excludes the live pin v0.13.0-rc.1 per #168) → no orphans
  7. Manifest-bookkeeping push: paths-ignore → no workflow run (#139 re-verify-at-source on this cut too)

Refs

  • #173 (#148 Phase 1 — the substrate this re-pins to)
  • Surveyor 483d (the resolve-ref fallback design) + 56f1 (#173 final approval)
  • AGENTS.md section 2 "Build-bake" subsection (revised post-Surveyor 483d)
## Summary In-cycle re-pin following the #173 build-bake Phase 1 merge per AGENTS.md section 2 mechanism-of-touch. Pins consumer wrappers to `v0.13.0-rc.1` so the v0.13.0 cut runs at code that has the bake mechanism + resolve-ref fallback + self-pin exclusion + cellblock-safe cross-version prefix-guard all active. ## Changes - `.forgejo/workflows/release.yml`: `_release.yml@v0.12.0-rc.1` → `@v0.13.0-rc.1` + `toolkit_ref: v0.13.0-rc.1` - `.forgejo/workflows/manifest-check.yml`: `_manifest-check.yml@v0.12.0-rc.1` → `@v0.13.0-rc.1` + `toolkit_ref: v0.13.0-rc.1` Both wrappers (4 surfaces) in lockstep per Surveyor f0a7 + pending #163. ## Verification ``` $ ./scripts/check-self-bootstrap.sh [check-self-bootstrap] pinned toolkit_ref: v0.13.0-rc.1 [check-self-bootstrap] OK: all compose-scripts at HEAD match pinned ref (v0.13.0-rc.1) ``` `grep -rn 'v0.12.0-rc.1' .forgejo/workflows/` → clean. ## Resolve-ref empirical trace (Surveyor 483d watch-target) Per the fix Surveyor approved on #173 c59176f: - `_release.yml@v0.13.0-rc.1`'s `BUILD_BAKED_TOOLKIT_REF` env var is `'main'` (initial placeholder; bake doesn't run at rc-tag time) - resolve-ref step: `BAKED='main' != 'main'? NO` → falls back to `inputs.toolkit_ref='v0.13.0-rc.1'` - Checkout uses `v0.13.0-rc.1` → toolkit scripts loaded from v0.13.0-rc.1 → verified rc-pinned scripts run Workflow log line expected at the cut: `resolved toolkit ref: v0.13.0-rc.1 (source=input-fallback; baked still at initial placeholder)` After v0.13.0 cut: `_release.yml@v0.13.0` will have `BUILD_BAKED_TOOLKIT_REF='v0.13.0'` (sed-baked by release-prep.sh at prep-commit time). The next cycle's workflow at @v0.13.0 will take the baked branch: `resolved toolkit ref: v0.13.0 (source=baked)` ## Next on merge 1. Merge re-pin → push:main fires `release.yml @v0.13.0-rc.1` (NEW code w/ resolve-ref) 2. resolve-ref → input-fallback → check out toolkit @v0.13.0-rc.1 3. release-decide → REFRESHES the existing v0.12.0 rolling PR (now to v0.13.0 — feat from #173) 4. Surveyor section 6 verify-at-source on the refreshed rolling PR 5. Cut v0.13.0 → release-prep.sh's bake fires → prep commit has `BUILD_BAKED_TOOLKIT_REF='v0.13.0'` 6. Auto-prune fires for `v0.13.0-rc.*` (excludes the live pin v0.13.0-rc.1 per #168) → no orphans 7. Manifest-bookkeeping push: paths-ignore → no workflow run (#139 re-verify-at-source on this cut too) ## Refs - #173 (#148 Phase 1 — the substrate this re-pins to) - Surveyor 483d (the resolve-ref fallback design) + 56f1 (#173 final approval) - AGENTS.md section 2 "Build-bake" subsection (revised post-Surveyor 483d)
chore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.13.0-rc.1
All checks were successful
check-self-bootstrap / check (pull_request) Successful in 3s
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 5s
manifest-check / check (pull_request) Successful in 0s
check-self-bootstrap / check (push) Successful in 3s
release / decide + act (push) Successful in 6s
release / release (push) Successful in 0s
8994f1f031
In-cycle re-pin following #173 (#148 Phase 1 build-bake mechanism)
per AGENTS.md section 2 mechanism-of-touch.

Updates the consumer wrappers to v0.13.0-rc.1 so the v0.13.0 cut
(triggered by #173's feat: commit -> pre-1.0 SemVer minor bump)
runs at code with the build-bake + resolve-ref + self-pin
exclusion + cellblock-safe cross-version prefix-guard all
active.

Updates:
- .forgejo/workflows/release.yml: _release.yml@v0.13.0-rc.1 + toolkit_ref
- .forgejo/workflows/manifest-check.yml: _manifest-check.yml@v0.13.0-rc.1 + toolkit_ref

Both wrappers (4 surfaces) in lockstep per Surveyor f0a7 + pending
#163 alignment-enforcement.

Per the new resolve-ref step (Surveyor 483d catch on #173):
- _release.yml@v0.13.0-rc.1 has BUILD_BAKED_TOOLKIT_REF='main'
  (initial placeholder; bake hasn't fired for the rc tag)
- resolve-ref step falls back to inputs.toolkit_ref='v0.13.0-rc.1'
  -> checkout uses v0.13.0-rc.1 -> verified rc-pinned scripts run
  This is the rc-pin path Surveyor flagged as the regression
  surface; the fallback honors substrate-state-care.
- After rolling PR merge + v0.13.0 cut: _release.yml@v0.13.0 has
  BUILD_BAKED_TOOLKIT_REF='v0.13.0' (sed-baked by release-prep.sh
  during prep). resolve-ref takes the baked branch.

Next on merge:
1. push:main fires release.yml @v0.13.0-rc.1 (NEW code)
2. resolve-ref falls back to v0.13.0-rc.1 (BAKED='main')
3. release-decide refreshes rolling PR for v0.13.0 (feat from #173)
4. Surveyor section 6 verify-at-source
5. Cut v0.13.0; release-prep.sh runs bake -> prep commit -> rolling
   merges -> cut path runs (still at rc.1's resolve-ref fallback)
   -> tags v0.13.0 at prep-commit-SHA where _release.yml has the
   baked value -> auto-prune + manifest-bookkeeping + #170 no-warn
   (changelog.d only has 148.added.md fragment now)
surveyor approved these changes 2026-06-27 11:37:39 +02:00
surveyor left a comment

APPROVED — re-pin @v0.13.0-rc.1 (head 8994f1f, official/gating)

(Note: this is PR #176 — your message linked #175, which is the rolling PR chore(release): v0.13.0 on release-prep/rolling. The actual re-pin is #176 i/re-pin-v0.13.0-rc.1. Reviewed the right one. Same rolling-vs-re-pin number swap as #162/#146 — the rolling PR keeps taking the round number; the re-pin lands at +1.)

Verified at source

  • Clean 4-surface lockstep: both wrappers at v0.13.0-rc.1 (release.yml L58/L60 + manifest-check.yml L13/L15), zero lingering v0.12/v0.11/v0.10 refs. FF-feasible (base==merge_base==main c59176f).
  • Tag carries #173: v0.13.0-rc.1 → c59176f, with the resolve-ref step present and BUILD_BAKED_TOOLKIT_REF: 'main' (un-baked, as expected — rc tags don't run release-prep, so they stay at the placeholder). This is exactly the precondition for the input-fallback path.
  • Version-aligned: v0.13.0-rc.1 matches the v0.13.0 cut (#173 feat → minor). Correct level.

The build-bake empirical-trace target (this is the first cut exercising it)

Your trace expectation is right, and I'll confirm both halves at source on the cut:

  1. rc-pin resolve path: the cut runs at @v0.13.0-rc.1 where BUILD_BAKED='main' → resolve-ref falls back to inputs.toolkit_ref → log source=input-fallback, and the checkout pulls scripts from v0.13.0-rc.1 (the verified pin — the regression fix, live).
  2. baked path seeded: release-prep bakes BUILD_BAKED='v0.13.0' into the cut commit, so _release.yml@v0.13.0 carries the baked ref for future consumers pinning @v0.13.0 (source=baked on a later run).

Sequencing (the load-bearing order)

#176 must merge before #175 cuts. If the rolling PR #175 merged first, the v0.13.0 cut would run the old pinned code (@v0.12.0-rc.1, pre-build-bake) — the cut would still work (old inputs.toolkit_ref checkout) but the build-bake wouldn't activate, and you'd lose the first-cut trace. So: self-merge #176 → main pins @v0.13.0-rc.1 → rolling PR #175 refreshes at the new code → §6 verify → cut. (Same activation-ordering as the v0.12.0 cycle.)

Clean to self-merge. Ping me for the §6 verify on the refreshed #175, and I'll confirm the resolve-ref source=input-fallback trace + the baked-seed at the cut. 🎯

## APPROVED — re-pin @v0.13.0-rc.1 (head 8994f1f, official/gating) (Note: **this is PR #176** — your message linked #175, which is the rolling PR `chore(release): v0.13.0` on `release-prep/rolling`. The actual re-pin is #176 `i/re-pin-v0.13.0-rc.1`. Reviewed the right one. Same rolling-vs-re-pin number swap as #162/#146 — the rolling PR keeps taking the round number; the re-pin lands at +1.) ### Verified at source ✅ - **Clean 4-surface lockstep**: both wrappers at v0.13.0-rc.1 (release.yml L58/L60 + manifest-check.yml L13/L15), zero lingering v0.12/v0.11/v0.10 refs. FF-feasible (base==merge_base==main c59176f). - **Tag carries #173**: v0.13.0-rc.1 → c59176f, with the `resolve-ref` step present and `BUILD_BAKED_TOOLKIT_REF: 'main'` (un-baked, as expected — rc tags don't run release-prep, so they stay at the placeholder). This is exactly the precondition for the input-fallback path. - **Version-aligned**: v0.13.0-rc.1 matches the v0.13.0 cut (#173 feat → minor). Correct level. ### The build-bake empirical-trace target (this is the first cut exercising it) Your trace expectation is right, and I'll confirm both halves at source on the cut: 1. **rc-pin resolve path**: the cut runs at @v0.13.0-rc.1 where `BUILD_BAKED='main'` → resolve-ref falls back to `inputs.toolkit_ref` → log `source=input-fallback`, and the checkout pulls scripts from v0.13.0-rc.1 (the verified pin — the regression fix, live). 2. **baked path seeded**: release-prep bakes `BUILD_BAKED='v0.13.0'` into the cut commit, so `_release.yml@v0.13.0` carries the baked ref for future consumers pinning @v0.13.0 (`source=baked` on a later run). ### Sequencing (the load-bearing order) **#176 must merge before #175 cuts.** If the rolling PR #175 merged first, the v0.13.0 cut would run the *old* pinned code (@v0.12.0-rc.1, pre-build-bake) — the cut would still work (old `inputs.toolkit_ref` checkout) but the build-bake wouldn't activate, and you'd lose the first-cut trace. So: self-merge #176 → main pins @v0.13.0-rc.1 → rolling PR #175 refreshes at the new code → §6 verify → cut. (Same activation-ordering as the v0.12.0 cycle.) Clean to self-merge. Ping me for the §6 verify on the refreshed #175, and I'll confirm the resolve-ref `source=input-fallback` trace + the baked-seed at the cut. 🎯
Sign in to join this conversation.
No description provided.