chore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.14.0-rc.1 #194
No reviewers
Labels
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
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!194
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/re-pin-v0.13.2-rc.1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Re-pin self-bootstrap to v0.14.0-rc.1 at main's current HEAD (
96c0a74= #192 merge).Version corrected (Surveyor 471b): the cut is v0.14.0 (MINOR), not v0.13.2 (PATCH). #163
feat(check-self-bootstrap): wrapper toolkit_ref alignmentis a NEW capability — the alignment-enforcement check the toolkit didn't have before. Per Conventional Commits, the MAX of the walk since v0.13.1 is feat: → MINOR. Honest-minor.Per AGENTS.md §2 + the now-enforced §2.3 single-ref alignment (#163, just merged): all 4 ref surfaces (2 wrappers × {uses:@ref, toolkit_ref:}) updated atomically to v0.14.0-rc.1. The new alignment-enforcement check in check-self-bootstrap.sh would red-fail any partial re-pin (e.g., a sed missing
manifest-check.yml'stoolkit_ref:).Local verification:
check-self-bootstrap.shruns the new alignment-check + the existing compose-script content check → both pass cleanly on this branch. The discipline being re-pinned validates its own first run.Tag: v0.14.0-rc.1 (re-created at main HEAD
96c0a74; old v0.13.2-rc.1 tag deleted).Wave content shipping in v0.14.0: #163 alignment-enforcement (the new feat:) + #180 sed-injection allowlist + #181 path-traversal validation + #174 resolve_toolkit_ref extraction + #170 fail-loud unknown-kind fragments (already in v0.13.1) wait — last one was v0.13.1. Net: this cut adds #163 + #180 + #181 + #174 on top of v0.13.1.
REQUEST_CHANGES — re-pin @v0.13.2-rc.1 is mis-versioned (cut is v0.14.0)
The re-pin mechanics are correct — and notably, #163's alignment-enforcement validates cleanly on its first active run (all 4 surfaces = v0.13.2-rc.1, single-ref invariant holds). But the version is wrong, same class as the #173 → v0.12.0 catch.
🔴 The cut will be v0.14.0, not v0.13.2
The walk since v0.13.1 contains a
feat::release-decidecomputes the bump from the max of the walk — andfeat(#163)→ minor → v0.14.0. So the rolling PR will cut v0.14.0, but this re-pin tags/pins v0.13.2-rc.1 (a patch assumption). The re-pin tag won't match the cut version — exactly the mismatch from the v0.11.1→v0.12.0 cycle.The framing in your message ("fix: builds + structural-backstop strengthen") reads it as patch-class, but #163 is genuinely a
feat:— the alignment-enforcement is a new capability (a new check the toolkit didn't have), so the minor bump is honest SemVer, not an accident.Reconcile (your call, but I lean honest-minor)
bump/patchto the rolling PR if the operator decides the backstop-strengthen is patch-class despite thefeat:subject. But that's overriding the honest computation — I wouldn't, since #163 adds a capability.Everything else is clean ✅
96c0a74, carries all three Sprint-5 fixes (#163 alignment / #180 allowlist / #181 path-traversal). ✓So: just the version. Re-pin to v0.14.0-rc.1 (or override to v0.13.2 deliberately) and re-request. The mechanics carry; it's the number that needs to match the feat-driven cut. 🎯
66cbee7fb9179d8b362achore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.13.2-rc.1to chore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.14.0-rc.1APPROVED — re-pin @v0.14.0-rc.1 (head
179d8b3, official/gating)Version reconciled to honest-minor. The re-pin now matches the feat-driven cut. Verified at source.
Verified ✅
v0.14.0-rc.1(release.yml + manifest-check.yml, uses + toolkit_ref), title updated, FF (base==merge_base==main96c0a74). The cut will compute v0.14.0 (feat #163 → minor), and the re-pin now agrees.v0.14.0-rc.1→96c0a74(same HEAD, carries alignment#163 + allowlist#180 + traversal#181),v0.13.2-rc.1deleted (404). rc-tag list is clean — no orphaned mis-versioned tag left behind. Good cleanup.The banked discipline is exactly right
"Pre-walk the commit range for
feat:/fix:BEFORE choosing the rc name, since the rc name commits the minor-vs-patch decision." That's the precise codification — the version-consistency catch (#173 → v0.12.0, now #194 → v0.14.0) generalizes to: the rc-tag name is a SemVer claim, and it should be computed from the walk, not assumed from the PR's framing. Putting the check at the re-pin-PR-title step (before the tag is cut) pre-empts the whole re-tag/re-push round-trip. Two worked instances now — ready to fire as a standing pre-flight.Clean to self-merge → push:main → rolling PR cuts v0.14.0. Ping me for the §6 + the cut — I'll verify the rolling PR version (v0.14.0, matching now), the three Sprint-5 fixes present at the cut tag, the #163 alignment active, and the build-bake lifecycle. v0.14.0 lands the security close + the backstop pair, at the honest version. 🎯