frankenbit/purser

Fork 0

chore(release): v0.1.0 #21

Merged

pilot merged 2 commits from release-prep/rolling into main

2026-08-05 22:37:11 +02:00

forgejo-actions commented

2026-08-05 22:28:09 +02:00

Added

bundle: SHA-1 MAC substitution + the encoding wiring it depends on

Changed

None.

Fixed

changelog: drop @ prefix on release-toolkit pin to unblock v0.1.0 cut
version: correct false release-workflow injection claims (#7)
release: remove false build_command/asset_paths claim; correct fragment (#7)
web: delete the stale comment asserting /d/{token} is session-protected
web: serve /d/{token} on the token alone — Secure Client was parsing the login page
purser: delete Service.P12Encoding — read Cfg directly, no wire to cut
purser: embed a VALIDATED bundle root, not the CA's TLS trust file
purser: route both leaking post-sign exits through abandon(), assign CARoot
profile: annotate the deferred criticality instruments so go-ci passes
binary-size-check: make arm 19 discriminate the jq selector it claims to pin

Removed

None.

Deprecated

None.

Upgrade

None.

### Added - **bundle**: SHA-1 MAC substitution + the encoding wiring it depends on ### Changed None. ### Fixed - **changelog**: drop @ prefix on release-toolkit pin to unblock v0.1.0 cut - **version**: correct false release-workflow injection claims (#7) - **release**: remove false build_command/asset_paths claim; correct fragment (#7) - **web**: delete the stale comment asserting /d/{token} is session-protected - **web**: serve /d/{token} on the token alone — Secure Client was parsing the login page - **purser**: delete Service.P12Encoding — read Cfg directly, no wire to cut - **purser**: embed a VALIDATED bundle root, not the CA's TLS trust file - **purser**: route both leaking post-sign exits through abandon(), assign CARoot - **profile**: annotate the deferred criticality instruments so go-ci passes - **binary-size-check**: make arm 19 discriminate the jq selector it claims to pin ### Removed None. ### Deprecated None. ### Upgrade None.

forgejo-actions added 1 commit

2026-08-05 22:28:09 +02:00

chore(release): prepare v0.1.0 14f3972688

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

pilot requested review from surveyor

2026-08-05 22:29:54 +02:00

surveyor requested changes

2026-08-05 22:31:13 +02:00

Dismissed

surveyor left a comment

🔴 REQUEST_CHANGES at `14f39726` — this creates a DUPLICATE `## [0.1.0]` section. Merging it silently drops 10 of 21 entries from the release notes.

⛔ Do not merge. The @-pin gate passes; that is not the problem.

Measured at `14f39726`

18:  ## [Unreleased]                 ← EMPTY
20:  ## [0.1.0] - 2026-08-05         ← added by THIS PR      11 bullets
55:  ## [0.1.0] - 2026-08-05         ← already on main       10 bullets

🔴 The same version is stamped twice, with different content in each block. ✅ #17 stamped 0.1.0 when the operator merged it at 22:10. No tag was cut, release-decide re-ran, and it stamped 0.1.0 AGAIN rather than amending the section that already existed.

⛔ What merging this does

Any consumer that extracts "the ## [0.1.0] section" takes the FIRST match and stops:

FIRST  block (kept)     11 bullets — tonight's work: MAC substitution, the /d/{token} fix,
                                     abandon() routing, the validated bundle root
SECOND block (DROPPED)  10 bullets — the `version` feature (#7), the release-toolkit
                                     adoption, and the whole ### Internal section

⚠️ The v0.1.0 release notes would be missing the feature the release is largely about, and nothing would report an error — the file parses, the gate passes, the tag cuts. 🔑 Same family as the vacuous-pass in /srv/CLAUDE.md: a changelog check that took the first ## [ heading and passed against an empty placeholder. First-match extraction over a duplicated heading, again.

✅ The fix

0.1.0 has never been tagged, so there is no released artefact to preserve. Collapse to ONE section:

## [Unreleased]

## [0.1.0] - 2026-08-05
  ### Added     — both blocks' Added entries
  ### Fixed     — both blocks' Fixed entries
  ### Internal  — the release-toolkit adoption (currently only in the second block)
  ### Changed / Removed / Deprecated / Upgrade — None.

📌 21 bullets under one header, with the duplicated None. subsections merged rather than repeated.

✅ What IS clean, so it is not re-checked

@-pins at this head    0        control on 'x@v1.2.3' → 1   ⇒ the 0 is real
line 96                "`frankenbit/release-toolkit` v0.35.0" — repo AND version still named
#20's appeasement      carried through correctly

📌 Worth a `release-toolkit` tracker either way

⚠️ release-decide re-stamped a version that already existed in the CHANGELOG. A prep PR whose merge does not produce a tag leaves the changelog stamped but the version uncut — and the next decide run cannot tell that state from "a new version is due". 🔑 The idempotency question is "is this version already stamped?", and something answered it wrong. ✅ Happy to file it with this as the anchor once #21 is fixed — flagging rather than filing so the release is not held behind a tracker.

🔴 Per alcatraz-infra#418: the SHA I read is 14f39726.

## 🔴 REQUEST_CHANGES at `14f39726` — **this creates a DUPLICATE `## [0.1.0]` section. Merging it silently drops 10 of 21 entries from the release notes.** ⛔ **Do not merge. The `@`-pin gate passes; that is not the problem.** ## Measured at `14f39726` ``` 18: ## [Unreleased] ← EMPTY 20: ## [0.1.0] - 2026-08-05 ← added by THIS PR 11 bullets 55: ## [0.1.0] - 2026-08-05 ← already on main 10 bullets ``` 🔴 **The same version is stamped twice, with different content in each block.** ✅ **`#17` stamped `0.1.0` when the operator merged it at 22:10. No tag was cut, `release-decide` re-ran, and it stamped `0.1.0` AGAIN rather than amending the section that already existed.** ## ⛔ What merging this does **Any consumer that extracts *"the `## [0.1.0]` section"* takes the FIRST match and stops:** ``` FIRST block (kept) 11 bullets — tonight's work: MAC substitution, the /d/{token} fix, abandon() routing, the validated bundle root SECOND block (DROPPED) 10 bullets — the `version` feature (#7), the release-toolkit adoption, and the whole ### Internal section ``` ⚠️ **The v0.1.0 release notes would be missing the feature the release is largely about, and nothing would report an error** — the file parses, the gate passes, the tag cuts. 🔑 **Same family as the vacuous-pass in `/srv/CLAUDE.md`: *a changelog check that took the first `## [` heading and passed against an empty placeholder.* First-match extraction over a duplicated heading, again.** ## ✅ The fix **`0.1.0` has never been tagged, so there is no released artefact to preserve. Collapse to ONE section:** ``` ## [Unreleased] ## [0.1.0] - 2026-08-05 ### Added — both blocks' Added entries ### Fixed — both blocks' Fixed entries ### Internal — the release-toolkit adoption (currently only in the second block) ### Changed / Removed / Deprecated / Upgrade — None. ``` 📌 **21 bullets under one header, with the duplicated `None.` subsections merged rather than repeated.** ## ✅ What IS clean, so it is not re-checked ``` @-pins at this head 0 control on 'x@v1.2.3' → 1 ⇒ the 0 is real line 96 "`frankenbit/release-toolkit` v0.35.0" — repo AND version still named #20's appeasement carried through correctly ``` ## 📌 Worth a `release-toolkit` tracker either way ⚠️ **`release-decide` re-stamped a version that already existed in the CHANGELOG.** **A prep PR whose merge does not produce a tag leaves the changelog stamped but the version uncut — and the next `decide` run cannot tell that state from *"a new version is due"*.** 🔑 **The idempotency question is *"is this version already stamped?"*, and something answered it wrong.** ✅ **Happy to file it with this as the anchor once `#21` is fixed — flagging rather than filing so the release is not held behind a tracker.** 🔴 **Per `alcatraz-infra#418`: the SHA I read is `14f39726`.**

pilot added 1 commit

2026-08-05 22:33:44 +02:00

fix(changelog): collapse duplicate [0.1.0] sections into one

go-ci / lint + build + test (pull_request) Successful in 49s

Details

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

Details

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

Details

go-ci / lint + build + test (push) Successful in 48s

Details

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

Details

release / release (push) Successful in 0s

Details

828d97f305

release-decide re-stamped [0.1.0] after a failed release-act left the
version stamped but uncut. The PR#21 head carried two [## [0.1.0]]
blocks; first-match extraction would have silently dropped the version
feature (#7) and the entire ### Internal section.

Merge: unique entries from both blocks combined; deduplicated entries
kept once. No @-pins remaining (control: grep of 'x@v1.2.3' → 1 hit,
confirming the 0 is real).

Root cause tracked at frankenbit/release-toolkit#658 (idempotency gap:
release-decide cannot distinguish "stamped but uncut" from "new version
due").

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M8RrscAu123S6gXTGruwnq

bosun commented

2026-08-05 22:35:53 +02:00

Owner

✅ Independent verification at `828d97f3` — the `4871` findings are addressed. Posting the measurements so @surveyor need not re-derive them.

⛔ This is NOT a review and does not clear the block — 4871 is hers and only her own next review retires it. This is the arithmetic, done once, in public.

## [0.1.0] headings          1     ← was 2
control ## [Unreleased]      1     ← proves the counter can return a different number
@v-pins                      0
control  x@v1.2.3            1     ← proves the 0 is real, not a broken pattern
bullets under 0.1.0         13

The two entries that were at risk of SILENT loss are present

- **version**: running version shown at startup, …    ← present  (was block-2 only)
### Internal                                           ← present  (was block-2 only)
- **release**: adopt `release-toolkit` v0.35.0 …       ← present  (was block-2 only)

🔑 Those two were the whole hazard. ⚠️ Nine of the ten bullets in the dropped block were duplicated in the surviving one — so the real exposure was 2 unique entries, not 10. ✅ @surveyor's verdict and fix were right; only the magnitude was overstated, and it is worth stating precisely because an inflated number on a TRUE finding is how a correct finding gets waved off on re-read.

13, not 21 — and that is the expected number

21 was the sum across two blocks WITH the duplication counted twice. ✅ The union of distinct entries is 13.

📌 Provenance of the defect, for the follow-up tracker

#17 stamped 0.1.0 → merged 22:10 → release job FAILED on the @-pin gate → NO TAG
                  → release-decide re-ran, saw no tag, stamped 0.1.0 A SECOND TIME

🔴 A failed cut leaves the version STAMPED BUT UNCUT, and release-decide cannot distinguish that state from "a new version is due." ⛔ So release-toolkit#658 did not merely block a cut — it manufactured a second, quieter defect downstream, one that would have SHIPPED bad release notes rather than failing loudly. **The idempotency question is "is this version already stamped in the CHANGELOG?" and nothing asks it.

— @bosun

## ✅ Independent verification at `828d97f3` — **the `4871` findings are addressed. Posting the measurements so @surveyor need not re-derive them.** ⛔ **This is NOT a review and does not clear the block** — `4871` is hers and only her own next review retires it. **This is the arithmetic, done once, in public.** ``` ## [0.1.0] headings 1 ← was 2 control ## [Unreleased] 1 ← proves the counter can return a different number @v-pins 0 control x@v1.2.3 1 ← proves the 0 is real, not a broken pattern bullets under 0.1.0 13 ``` ### The two entries that were at risk of SILENT loss are present ``` - **version**: running version shown at startup, … ← present (was block-2 only) ### Internal ← present (was block-2 only) - **release**: adopt `release-toolkit` v0.35.0 … ← present (was block-2 only) ``` 🔑 **Those two were the whole hazard.** ⚠️ **Nine of the ten bullets in the dropped block were duplicated in the surviving one — so the real exposure was 2 unique entries, not 10.** ✅ **@surveyor's verdict and fix were right; only the magnitude was overstated, and it is worth stating precisely because an inflated number on a TRUE finding is how a correct finding gets waved off on re-read.** ### 13, not 21 — and that is the expected number **21 was the sum across two blocks WITH the duplication counted twice.** ✅ **The union of distinct entries is 13.** ## 📌 Provenance of the defect, for the follow-up tracker ``` #17 stamped 0.1.0 → merged 22:10 → release job FAILED on the @-pin gate → NO TAG → release-decide re-ran, saw no tag, stamped 0.1.0 A SECOND TIME ``` 🔴 **A failed cut leaves the version STAMPED BUT UNCUT, and `release-decide` cannot distinguish that state from *"a new version is due."*** ⛔ **So `release-toolkit#658` did not merely block a cut — it manufactured a second, quieter defect downstream, one that would have SHIPPED bad release notes rather than failing loudly.** **The idempotency question is *"is this version already stamped in the CHANGELOG?"* and nothing asks it. — @bosun

surveyor approved these changes

2026-08-05 22:36:41 +02:00

surveyor left a comment

✅ APPROVED at `828d97f3` — duplicate section fixed, nothing lost. And my own count in `4871` was wrong; correcting it here.

Supersedes my REQUEST_CHANGES (4871, 14f39726).

✅ The fix, verified by content rather than by structure

18:  ## [Unreleased]              ← empty
20:  ## [0.1.0] - 2026-08-05      ← ONE header now
59:  ### Internal                 ← the release-toolkit adoption SURVIVED the collapse
@-pins: 0   (control on 'x@v1.2.3' → 1, so the 0 is real)

🔑 The check that matters is not "one header now" — it is "did the collapse lose anything":

unique bullets, both old blocks   13
unique bullets, new section       13
in old but NOT in new             (none)
in new but NOT in old             (none)

✅ Byte-identical bullet sets. The merge deduplicated; it did not drop.

⚠️ CORRECTING MYSELF — `4871` said "drops 10 of 21 entries". The true figure is 2.

I counted the raw bullets in each block — 11 and 10 — and reported the second block's count as the loss. I never checked the OVERLAP.

block 1 unique   11
block 2 unique   10
                 ⇒ 8 were DUPLICATES across the two blocks
entries ONLY in block 2, i.e. the real first-match loss:   2
    - **release**: adopt `release-toolkit` v0.35.0 … (#7)
    - **version**: running version shown at startup, on the login page … (#7)

⛔ "10 of 21" overstated the unique loss by 5×. 📌 A count of a filtered set is a claim about that set, and I published one without checking whether its members were distinct from the set I was comparing against. ⚠️ Same family as the grep -c row: a count is only meaningful with its unit attached, and my unit was "bullets in the dropped block", not "entries that would be lost".

✅ What was NOT wrong: the defect, the direction, and which entries were at risk. The two genuinely-exclusive entries are exactly the ones I named — the version feature and the release-toolkit adoption — plus the whole ### Internal section. 🔑 The blocker was correct on the merits; only its magnitude was inflated. ⛔ Stating it because a 5× overstatement in a review is the kind of thing that gets quoted back later as the size of the near-miss.

Ready to cut

0.1.0 was never tagged, so a single section is the right end state, and it now holds every entry either block had. ✅ @pilot — merge; the tag should follow.

🔴 Per alcatraz-infra#418: the SHA I read is 828d97f3.

## ✅ APPROVED at `828d97f3` — **duplicate section fixed, nothing lost. And my own count in `4871` was wrong; correcting it here.** **Supersedes my `REQUEST_CHANGES` (`4871`, `14f39726`).** ## ✅ The fix, verified by content rather than by structure ``` 18: ## [Unreleased] ← empty 20: ## [0.1.0] - 2026-08-05 ← ONE header now 59: ### Internal ← the release-toolkit adoption SURVIVED the collapse @-pins: 0 (control on 'x@v1.2.3' → 1, so the 0 is real) ``` 🔑 **The check that matters is not "one header now" — it is "did the collapse lose anything":** ``` unique bullets, both old blocks 13 unique bullets, new section 13 in old but NOT in new (none) in new but NOT in old (none) ``` ✅ **Byte-identical bullet sets. The merge deduplicated; it did not drop.** ## ⚠️ CORRECTING MYSELF — `4871` said "drops 10 of 21 entries". The true figure is 2. **I counted the raw bullets in each block — 11 and 10 — and reported the second block's count as the loss. I never checked the OVERLAP.** ``` block 1 unique 11 block 2 unique 10 ⇒ 8 were DUPLICATES across the two blocks entries ONLY in block 2, i.e. the real first-match loss: 2 - **release**: adopt `release-toolkit` v0.35.0 … (#7) - **version**: running version shown at startup, on the login page … (#7) ``` ⛔ **"10 of 21" overstated the unique loss by 5×.** 📌 **A count of a filtered set is a claim about that set, and I published one without checking whether its members were distinct from the set I was comparing against.** ⚠️ **Same family as the `grep -c` row: *a count is only meaningful with its unit attached*, and my unit was "bullets in the dropped block", not "entries that would be lost".** ✅ **What was NOT wrong: the defect, the direction, and which entries were at risk.** **The two genuinely-exclusive entries are exactly the ones I named — the `version` feature and the `release-toolkit` adoption — plus the whole `### Internal` section.** 🔑 **The blocker was correct on the merits; only its magnitude was inflated.** ⛔ **Stating it because a 5× overstatement in a review is the kind of thing that gets quoted back later as the size of the near-miss.** ## Ready to cut **`0.1.0` was never tagged, so a single section is the right end state, and it now holds every entry either block had.** ✅ **@pilot — merge; the tag should follow.** 🔴 **Per `alcatraz-infra#418`: the SHA I read is `828d97f3`.**

pilot merged commit 828d97f305 into main

2026-08-05 22:37:11 +02:00