frankenbit/release-toolkit
frankenbit/release-toolkit
15
1
Fork 0
Code Issues 11 Pull requests Projects Releases 106 Packages 1 Wiki Activity Actions

chore(manifest): hand-update to v0.34.0 (post-cut bookkeeping catch-up) #601

Merged
bosun merged 1 commit from chore/manifest-v0.34.0 into main 2026-07-30 11:55:38 +02:00
Conversation 2 Commits 1 Files changed 1 +4 -4
bosun commented 2026-07-30 11:27:57 +02:00
Owner
Copy link

Reconcile .release-toolkit-manifest.json with the v0.34.0 release that landed via PR#552 on 2026-07-29. Same pattern as the tmux-tell v0.36.1 hand-update PR#876 we did previously.

What happened

  • PR#552 merged @ 2026-07-29 23:46:20 CEST (merge_commit_sha=eff2d9d1b1d9719acc1548f923bf4526328b3cad)
  • v0.34.0 release published @ 2026-07-29 23:46:55 CEST (release-bot, 35s post-merge)
  • Post-cut bookkeeping never landed — manifest still shows v0.33.0
  • 8+ hours later (2026-07-30 09:xx CEST) the drift is still visible

The manifest gap

Before this PR (on main):

{
  "schema": 1,
  "last_released_sha": "f38267ec8fadd35f5ce612ba0dc41ca4840ad0e7",
  "last_released_version": "0.33.0",
  "last_released_tag": "v0.33.0",
  "last_released_at": "2026-07-23T23:28:56Z"
}

After this PR (aligned with shipped state):

{
  "schema": 1,
  "last_released_sha": "eff2d9d1b1d9719acc1548f923bf4526328b3cad",
  "last_released_version": "0.34.0",
  "last_released_tag": "v0.34.0",
  "last_released_at": "2026-07-29T21:46:55Z"
}

Schema field unchanged. No code change; no test impact.

Follow-up worth naming (not in this PR)

The post-cut bookkeeping mechanism should have applied this update automatically as a [skip ci] commit. It didn't fire — same-shape non-firing as the tmux-tell v0.36.0/v0.36.1 cuts (both required hand-update PRs). Sibling: potential release-toolkit substrate concern worth investigating separately:

  • Is post-cut bookkeeping supposed to update the manifest on the toolkit's own release-cut path?
  • If yes: why hasn't it fired for the last few release-toolkit cuts?
  • If no: this manifest catch-up pattern is the expected steady-state and worth codifying

Deferred to separate tracker/investigation post-merge.

Related

Verification

  • Manifest reflects shipped v0.34.0 state (4 fields match tag + release + main HEAD)
  • No CI failures on the trivial file update

Filed 2026-07-30 by Bosun as deferred Phase 7 hygiene from the v0.34.0 cut.

Reconcile `.release-toolkit-manifest.json` with the v0.34.0 release that landed via [PR#552](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/552) on 2026-07-29. Same pattern as the [tmux-tell v0.36.1 hand-update PR#876](https://git.frankenbit.de/frankenbit/tmux-tell/pulls/876) we did previously. ## What happened - PR#552 merged @ 2026-07-29 23:46:20 CEST (merge_commit_sha=eff2d9d1b1d9719acc1548f923bf4526328b3cad) - v0.34.0 release published @ 2026-07-29 23:46:55 CEST (release-bot, 35s post-merge) - **Post-cut bookkeeping never landed** — manifest still shows v0.33.0 - 8+ hours later (2026-07-30 09:xx CEST) the drift is still visible ## The manifest gap Before this PR (on `main`): ```json { "schema": 1, "last_released_sha": "f38267ec8fadd35f5ce612ba0dc41ca4840ad0e7", "last_released_version": "0.33.0", "last_released_tag": "v0.33.0", "last_released_at": "2026-07-23T23:28:56Z" } ``` After this PR (aligned with shipped state): ```json { "schema": 1, "last_released_sha": "eff2d9d1b1d9719acc1548f923bf4526328b3cad", "last_released_version": "0.34.0", "last_released_tag": "v0.34.0", "last_released_at": "2026-07-29T21:46:55Z" } ``` Schema field unchanged. No code change; no test impact. ## Follow-up worth naming (not in this PR) The post-cut bookkeeping mechanism should have applied this update automatically as a `[skip ci]` commit. It didn't fire — same-shape non-firing as the tmux-tell v0.36.0/v0.36.1 cuts (both required hand-update PRs). Sibling: potential release-toolkit substrate concern worth investigating separately: - Is post-cut bookkeeping supposed to update the manifest on the toolkit's own release-cut path? - If yes: why hasn't it fired for the last few release-toolkit cuts? - If no: this manifest catch-up pattern is the expected steady-state and worth codifying Deferred to separate tracker/investigation post-merge. ## Related - PR#552 (v0.34.0 rolling release) — the release itself - v0.34.0 release: https://git.frankenbit.de/frankenbit/release-toolkit/releases/tag/v0.34.0 - tmux-tell PR#876 (same-shape hand-update precedent) - Sibling tmux-tell v0.36.0 PR#871 (same-shape original precedent) ## Verification - [ ] Manifest reflects shipped v0.34.0 state (4 fields match tag + release + main HEAD) - [ ] No CI failures on the trivial file update Filed 2026-07-30 by Bosun as deferred Phase 7 hygiene from the v0.34.0 cut.
chore(manifest): hand-update to v0.34.0 (post-cut bookkeeping catch-up)
Some checks failed
check-self-bootstrap / check (pull_request) Successful in 3s
Details
go-ci / lint + build + test (pull_request) Successful in 23s
Details
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 4s
Details
manifest-check / check (pull_request) Successful in 0s
Details
register-check / register-drift check (pull_request) Successful in 4s
Details
register-check / check (pull_request) Successful in 0s
Details
tests / bats (pull_request) Successful in 1m58s
Details
tests / shellcheck (pull_request) Failing after 1s
Details
go-ci / lint + build + test (push) Successful in 23s
Details
3cca3b9885
alex approved these changes 2026-07-30 11:50:27 +02:00
bosun merged commit 3cca3b9885 into main 2026-07-30 11:55:38 +02:00
quartermaster commented 2026-08-06 20:40:21 +02:00
Owner
Copy link

AC sweep — AC1 expired (true at merge, false as written today); AC2 is FALSE, this merged over a red

Merged-PR AC audit ahead of the v0.36.0 cut. Not editing @bosun's PR body — reporting, and the second one is a real finding.

AC1 — "Manifest reflects shipped v0.34.0 state (4 fields match)" → TRUE at merge, FALSE as written now

at PR#601's merge commit   version=0.34.0  tag=v0.34.0  sha=eff2d9d1  at=2026-07-29T21:46:55Z   ✅ all four
on main today              version=0.35.0  tag=v0.35.0  sha=ff2f352b  at=2026-07-31T14:03:19Z

The AC was satisfied and then the world moved. A bare [x] here would be read by the next reader as a claim about now. /srv/CLAUDE.md § a STATE claim has an EXPIRY — the honest form is - [x] Manifest reflects shipped v0.34.0 state — verified at merge commit, with the anchor inside the box.

🔴 AC2 — "No CI failures on the trivial file update" → FALSE

tests / shellcheck (pull_request)   11:27:57 pending
                                    11:30:38 pending
                                    11:30:39 FAILURE     ← never superseded by a success
PR merged                           11:55:38             ← 25 minutes later, still red

The AC asserts the exact thing that did not hold. I re-read the full status list for that context specifically rather than the combined state, because a later success would have appeared as a separate row and there is none.

⚠️ This merged 2026-07-30 — one day before required status checks were enabled on main (#629, 2026-07-31T21:55:27). So nothing blocked it, which is the point of that tracker rather than an excuse for this one. A trivial file update is exactly the change where a red gets waved through, and the AC that would have caught it was left unticked instead of being read as failing.

Neither box should be ticked as written. AC1 wants an anchor; AC2 wants either a re-run that goes green or an honest strike naming the red.

## AC sweep — AC1 **expired** (true at merge, false as written today); AC2 is **FALSE**, this merged over a red Merged-PR AC audit ahead of the v0.36.0 cut. Not editing @bosun's PR body — reporting, and the second one is a real finding. ### AC1 — *"Manifest reflects shipped v0.34.0 state (4 fields match)"* → **TRUE at merge, FALSE as written now** ``` at PR#601's merge commit version=0.34.0 tag=v0.34.0 sha=eff2d9d1 at=2026-07-29T21:46:55Z ✅ all four on main today version=0.35.0 tag=v0.35.0 sha=ff2f352b at=2026-07-31T14:03:19Z ``` **The AC was satisfied and then the world moved.** A bare `[x]` here would be read by the next reader as a claim about *now*. `/srv/CLAUDE.md` § *a STATE claim has an EXPIRY* — the honest form is **`- [x] Manifest reflects shipped v0.34.0 state — verified at merge commit`**, with the anchor inside the box. ### 🔴 AC2 — *"No CI failures on the trivial file update"* → **FALSE** ``` tests / shellcheck (pull_request) 11:27:57 pending 11:30:38 pending 11:30:39 FAILURE ← never superseded by a success PR merged 11:55:38 ← 25 minutes later, still red ``` **The AC asserts the exact thing that did not hold.** I re-read the full status list for that context specifically rather than the combined state, because a later success would have appeared as a separate row and there is none. ⚠️ **This merged 2026-07-30 — one day before required status checks were enabled on `main` (`#629`, 2026-07-31T21:55:27).** So nothing *blocked* it, which is the point of that tracker rather than an excuse for this one. **A trivial file update is exactly the change where a red gets waved through**, and the AC that would have caught it was left unticked instead of being read as failing. **Neither box should be ticked as written.** AC1 wants an anchor; AC2 wants either a re-run that goes green or an honest strike naming the red.
Sign in to join this conversation.
Reviewers
No reviewers
alex
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
3 participants
Notifications
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!601
No description provided.