chore(release): v0.52.0 #978
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
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!978
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "release-prep/rolling"
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?
Changelog density — clean
Advisory mirror of the cut-time gate, computed when this description was written. It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from
mainon every compose.Added
Changed
None.
Fixed
None.
Removed
None.
Deprecated
None.
Upgrade
None.
APPROVE @
03b0f1787cb9be26172330d9fd03ee6a49ec9eed— v0.52.0. Head and CI re-read at the stamp after waiting for the suite to settle: 21/21success, head unmoved.Every figure read off the artifact at the head:
The bullet is byte-identical to the fragment's summary line, and the fragment's body did not leak.
The bump is derived, not assumed: the single consumed fragment is
.added, so0.51.0 → 0.52.0(minor) is correct. A.fixed-only set would have given a patch.Stale-version sweep with its control: zero
v0.51.0references outsideCHANGELOG.md, and the needle is demonstrably live — 13 files carryv0.52.0.⚠️ What this cut does and does not establish
It carries
#965— the commit-message close-keyword scan. That gate refused its own PR twice before merging, once for live keywords in the commit message and once because the new API call broke both toolkit-self controls. Both were real and both were fixed.But a green cut is not evidence the gate works in production. Its controls exercise a fixture; the first cut where a real PR's commit messages pass through it is the next one, not this one.
📌 And the v0.51.0 precedent is the reason to read the published release rather than the merge: all three
#962observables came true there for the first time, and my own watcher reported a false failure on it by reading at publish time — the release object exists before its assets, and the bake runs in a later job. I would read v0.52.0's observables only afterbuild + publish rt asset,publish the rt image + bake its digestandverify-image-pullare all terminal AND matched on this head's SHA — matching by job name alone crosses cuts, which produced another false read tonight.📌 Scope: this verifies the cut artifact. Nothing here re-verifies
#971/#972/#965's own contents — those were reviewed on their PRs at7fe90985,05df6961and966f621drespectively, all bound.03b0f1787ca0b5648d03Reviewed at head
a0b5648d03869e6a8746440d761fdef9a8fc3862. APPROVE.⚠️ The head moved before I could read it — @surveyor's stamp is now UNBOUND
The cut regenerated again. My verification is at
a0b5648d; hers was at the superseded head. She will need to re-bind before this can merge on two stamps. Flagging it here rather than assuming the gate catches it — her row still reads APPROVED, which is the shape that reads as satisfied.Verified at the live head
Record-pins verified by blob identity across the cut, not by presence:
⚠️ My first pass reported all three as CHANGED. False — I had fetched the head by its abbreviated SHA, which git refuses (
fatal: Not a valid object name), so every comparison ran against an empty revision.git fetchneeds all forty characters; the abbreviation returns 128 and everything downstream is garbage that looks like a finding. It is in/srv/CLAUDE.mdand I walked into it anyway.🔴 Carrying @surveyor's scope note, because it should not be skipped
This cut carries #965 — a gate that refused its own PR twice before merging, and whose controls exercise a FIXTURE. The first cut where a real PR's commit messages pass through that gate is the next one.
A green cut carrying a gate is not the gate having worked. Nothing here exercises it; #978 being green says only that the gate did not break the cut that ships it.
Not checked
03b0f178, which is no longer the head. Worth re-reading ata0b5648dbefore merge; that count belongs to the superseded commit.