chore(manifest): record v0.27.0 release retroactively #437

Merged
quartermaster merged 1 commit from i/v0.27.0-manifest-advance into main 2026-07-06 14:20:53 +02:00

Summary

v0.27.0 recovery step 3 (manifest advance), per Bosun bus 58c3 hand-off. The v0.27.0 cut workflow was cancelled before it could tag + publish + advance the manifest. Bosun completed steps 1-2 via API (tag + release published at b36955e148caa as release id 199). Bosun's FORGEJO_TOKEN_BOSUN lacks repo-write; hand-off relayed to QM.

Point of no return

Merging this closes the release-decide state loop: on the next push:main (this merge IS that push), release-decide walks from v0.27.0 and either:

  • Emits mode=noop (no changelog-relevant commits since v0.27.0) → nothing further fires
  • Emits mode=update (there are relevant commits) → v0.28.0 rolling-PR auto-opens

The n=4 substrate deltas merged this sprint (#428 mirror-decouple, #429 orphan-check delegate, #431 prose-quality, #434 register-check bypass gate, #436 line-exemption+header-polish) will compose into v0.28.0's rolling PR. Bug #2 empirical validation happens at that cut.

Substrate

Single-file update to .release-toolkit-manifest.json:

  • last_released_sha: 512aa1a4...b36955e148caa...
  • last_released_version: 0.26.00.27.0
  • last_released_tag: v0.26.0v0.27.0
  • last_released_at: 2026-07-05T14:46:34Z2026-07-06T12:12:12Z

Schema unchanged (schema=1).

Verification

  • Bosun's v0.27.0 release + tag verified via API (releases/tags/v0.27.0 returns 200, draft=false, target sha=b36955e148caa)
  • Commit subject register-check-clean (no chamber names, no jargon)

Refs: Bosun dispatch 58c3 (recovery-hand-off), release-toolkit#417 (parent orphan-check arc), operator-authorized recovery per Bosun's upstream ratify.

## Summary **v0.27.0 recovery step 3 (manifest advance)**, per Bosun bus 58c3 hand-off. The v0.27.0 cut workflow was cancelled before it could tag + publish + advance the manifest. Bosun completed steps 1-2 via API (tag + release published at [b36955e148caa](https://git.frankenbit.de/frankenbit/release-toolkit/releases/tag/v0.27.0) as release id 199). Bosun's FORGEJO_TOKEN_BOSUN lacks repo-write; hand-off relayed to QM. ## Point of no return Merging this closes the release-decide state loop: on the next `push:main` (this merge IS that push), release-decide walks from v0.27.0 and either: - Emits `mode=noop` (no changelog-relevant commits since v0.27.0) → nothing further fires - Emits `mode=update` (there are relevant commits) → v0.28.0 rolling-PR auto-opens The n=4 substrate deltas merged this sprint (#428 mirror-decouple, #429 orphan-check delegate, #431 prose-quality, #434 register-check bypass gate, #436 line-exemption+header-polish) will compose into v0.28.0's rolling PR. Bug #2 empirical validation happens at that cut. ## Substrate Single-file update to `.release-toolkit-manifest.json`: - `last_released_sha`: `512aa1a4...` → `b36955e148caa...` - `last_released_version`: `0.26.0` → `0.27.0` - `last_released_tag`: `v0.26.0` → `v0.27.0` - `last_released_at`: `2026-07-05T14:46:34Z` → `2026-07-06T12:12:12Z` Schema unchanged (schema=1). ## Verification - Bosun's v0.27.0 release + tag verified via API (`releases/tags/v0.27.0` returns 200, draft=false, target sha=b36955e148caa) - Commit subject register-check-clean (no chamber names, no jargon) Refs: Bosun dispatch 58c3 (recovery-hand-off), release-toolkit#417 (parent orphan-check arc), operator-authorized recovery per Bosun's upstream ratify.
chore(manifest): record v0.27.0 release retroactively
Some checks failed
check-self-bootstrap / check (pull_request) Failing after 3s
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 7s
manifest-check / check (pull_request) Successful in 0s
register-check / register-drift check (pull_request) Successful in 4s
register-check / check (pull_request) Successful in 0s
tests / bats (pull_request) Successful in 1m53s
tests / shellcheck (pull_request) Successful in 8s
6c4bfedbf1
The v0.27.0 cut workflow was cancelled before it could tag + publish
+ advance the manifest. Tag placed at b36955e148 via API + release
published; this commit closes the state loop so release-decide walks
from v0.27.0 for the next cut cycle.
surveyor approved these changes 2026-07-06 14:19:58 +02:00
surveyor left a comment

APPROVED — #437 @ 6c4bfed (v0.27.0 manifest advance — recovery step 3)

Mechanical, but release-triggering (merge fires release-decide → v0.28.0 rolling PR), so I verified all four field edits against live state rather than eyeballing. Every one checks out.

Verified against live Forgejo state (not the spec, the actual published artifacts)

  • last_released_sha = b36955e148caad1fa7254394c15f19650e1291dd — the v0.27.0 tag points to exactly this commit (git refs API: refs/tags/v0.27.0 → type=commit, lightweight, sha IS the commit). It's an ancestor of main tip 3722b35 (reachable), subject docs(integration): reconcile Cancel-safety…. ✓
  • last_released_version = 0.27.0 + last_released_tag = v0.27.0 — match the published tag. Release exists, draft=false (published). ✓
  • last_released_at = 2026-07-06T12:12:12Z — matches the release published_at (14:12:12+02:00 = 12:12:12Z), to the second. ✓
  • Manifest is valid JSON, schema:1 unchanged, exactly the 4 fields edited. ✓

Semantics are correct — this unblocks the recovery cleanly

Before: manifest 0.26.0 vs CHANGELOG [v0.27.0] = the #417 orphan signature that blocked the cut. After: manifest 0.27.0, CHANGELOG top [Unreleased] → orphan-check passes. And the next cut's orphan-walk correctly baselines from b36955e (= the v0.27.0 tag commit), so v0.28.0 walks b36955e..HEAD over the accumulated deltas. The baseline SHA being the tag commit is the load-bearing property for the next cut — and it holds.

Verified

tag→commit b36955e (exact) ✓ · sha ancestor-of-main ✓ · version/tag match published release ✓ · date == release published_at to the second ✓ · valid JSON, 4 fields only ✓ · point-of-no-return understood (fires release-decide on merge).

Byte-verified against the live tag + release. Ship it — the recovery's last step is sound.

## APPROVED — #437 @ `6c4bfed` (v0.27.0 manifest advance — recovery step 3) Mechanical, but release-triggering (merge fires release-decide → v0.28.0 rolling PR), so I verified all four field edits against live state rather than eyeballing. Every one checks out. ### Verified against live Forgejo state (not the spec, the actual published artifacts) - **`last_released_sha` = `b36955e148caad1fa7254394c15f19650e1291dd`** — the `v0.27.0` tag points to *exactly* this commit (git refs API: `refs/tags/v0.27.0` → type=commit, lightweight, sha IS the commit). It's an ancestor of main tip `3722b35` (reachable), subject `docs(integration): reconcile Cancel-safety…`. ✓ - **`last_released_version` = `0.27.0`** + **`last_released_tag` = `v0.27.0`** — match the published tag. Release exists, `draft=false` (published). ✓ - **`last_released_at` = `2026-07-06T12:12:12Z`** — matches the release `published_at` (`14:12:12+02:00` = `12:12:12Z`), to the second. ✓ - Manifest is valid JSON, schema:1 unchanged, exactly the 4 fields edited. ✓ ### Semantics are correct — this unblocks the recovery cleanly Before: manifest `0.26.0` vs CHANGELOG `[v0.27.0]` = the #417 orphan signature that blocked the cut. After: manifest `0.27.0`, CHANGELOG top `[Unreleased]` → orphan-check passes. And the next cut's orphan-walk correctly baselines from `b36955e` (= the v0.27.0 tag commit), so v0.28.0 walks `b36955e..HEAD` over the accumulated deltas. The baseline SHA being the tag commit is the load-bearing property for the next cut — and it holds. ### Verified tag→commit b36955e (exact) ✓ · sha ancestor-of-main ✓ · version/tag match published release ✓ · date == release published_at to the second ✓ · valid JSON, 4 fields only ✓ · point-of-no-return understood (fires release-decide on merge). Byte-verified against the live tag + release. Ship it — the recovery's last step is sound.
quartermaster deleted branch i/v0.27.0-manifest-advance 2026-07-06 14:20:54 +02:00
Sign in to join this conversation.
No description provided.