fix(post-cut): log the precheck INPUTS beside its decision #923
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!923
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/914-precheck-inputs"
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?
Refs #914. Does not close it — AC2 asks which of the two candidate causes fired on v0.46.0, and that needs a cut with this logging in place.
The defect
On the v0.46.0 cut an idempotent skip fired 150ms before a surface read that contradicted it, and the log carried the decision and none of its premises. A wrong skip and a right one rendered identically — which is why a cut could fail this way with nothing naming it.
The four states render DISTINCTLY, which is the AC clause doing the work
"Could not resolve a branch" and "read main, got X" are different facts about the world; collapsing them rebuilds the blindness. ⚠️ Two pre-existing failure branches already did exactly that — a byte-identical
unreadable on origin/%sfor a failed fetch and a failed read. They now name which step failed.🔑 The sha is the predicate's own, not a re-derivation
gates.LenientLastReleasedSHAis exported for this and used verbatim. A premise that can disagree with the decision it explains is worse than no premise — it reads as evidence. Same reasoning asresolvePostCutPublishState's existing comment about not re-deriving layered precedence.🔴 Mutation-verified — and the third mutation found a gap in my own arms
The first four arms construct
precheckInputsdirectly, so they pin the type's RENDERING and not the WIRING that fills it. That is this tracker's own shape one level down: a check that looks like it covers the thing it names. Added a fifth arm callingpostCutPrecheckitself on the branch-unset path, which now reddens when the log line is removed:⚠️ Disclosed rather than left to be found: the remote-READ path's wiring is still uncovered, because it needs
FetchAuthedagainst a real remote. A brokenremoteSHAassignment on that path is caught by nothing in this package.Scope
fragment-check0 ·register-check0 ·manifest-check0 ·changelog-body-check0 ·go vet0 ·go test0 ·workflows.bats0.Measured by @engineer, who named the contradiction and deliberately stopped short of a cause; implemented by @surveyor.
Official exact-head review for release-toolkit#923 at
089ad5fdbd.The implementation satisfies the acceptance contract: postCutPrecheck logs the branch, fetch/read outcome, extracted remote SHA, and the decision together; the decision and log use the same gates.LenientLastReleasedSHA extractor. The first four arms pin rendering, while the fifth calls postCutPrecheck on the unset-branch path and catches removal of the inputs log. The PR explicitly discloses that no arm reaches the remote fetch/read wiring; that disclosure accurately matches the tests and is not being treated as covered.
Mutation evidence is meaningful: collapsing states and dropping the SHA redden their arms, and the unset-path wiring arm reddens when the inputs log is removed. Verified locally: go test ./..., go vet ./..., all 77 Bats, gofmt/diff check; Forgejo reports 17/17 success.
Non-blocking documentation correction: the body, changelog fragment, and source comment say “four states,” but the implementation, examples, and test map contain five distinct renderings (unset, fetch failed, read failed, read-ok without SHA, read-ok with SHA). The five-state behavior is correct; the count should be corrected when convenient.
Official exact-head review for release-toolkit#923 at
089ad5fdbd.The implementation satisfies the acceptance contract: postCutPrecheck logs the branch, fetch/read outcome, extracted remote SHA, and the decision together; the decision and log use the same gates.LenientLastReleasedSHA extractor. The first four arms pin rendering, while the fifth calls postCutPrecheck on the unset-branch path and catches removal of the inputs log. The PR explicitly discloses that no arm reaches the remote fetch/read wiring; that disclosure accurately matches the tests and is not being treated as covered.
Mutation evidence is meaningful: collapsing states and dropping the SHA redden their arms, and the unset-path wiring arm reddens when the inputs log is removed. Verified locally: go test ./..., go vet ./..., all 77 Bats, gofmt/diff check; Forgejo reports 17/17 success.
Non-blocking documentation correction: the body, changelog fragment, and source comment say “four states,” but the implementation, examples, and test map contain five distinct renderings (unset, fetch failed, read failed, read-ok without SHA, read-ok with SHA). The five-state behavior is correct; the count should be corrected when convenient.