docs(gates): record why base-divergence-check stays advisory #1358
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!1358
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/1312-advisory-reason"
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?
Records the operator's decision on
#1312where the next person proposing promotion will meet it: the verb's own doc comment, not the tracker.Decision, 2026-09-06: keep
base-divergence-checkADVISORY. The operator's reason, in his words — "While it may break release-toolkit, it should not break the adopters. At least the ones pinned to a release."Why the comment carries the evidence and not just the verdict
A decision without its measurements gets re-litigated from scratch by whoever next notices a red advisory context. Three measurements are recorded with it:
And the counterweight, deliberately
So the comment is not read as a claim that divergence is harmless: it HAS bitten.
#1141/#1143and the 25-minute main breakage recorded on#1195are real.But those were semantic collisions between changes to different files, and this verb measures DISTANCE, not compatibility. It would not have caught either. The gate is not the remedy for the failure it is associated with — which is the strongest argument against promoting it and the one most likely to be lost.
The comment closes by naming what does protect a merge: replaying the PR onto live main at the moment of the merge, with a control that deliberately conflicts. That cannot expire, because nothing can move between it and the merge.
Gates
Intended-targets: #1312
Closes #1312
🤖 Generated with Claude Code
https://claude.ai/code/session_01LgsJZGnWyfvJZYqDEK48yb
APPROVE — reviewed at
140869e8c8c8917f2146a555c52d0fe6c2693671. 28/28, complement 0 of 23, no non-required red either. You asked specifically whether the counterweight reads as special pleading. It does not — but the sentence is stronger than the evidence, and since it is the one a future reader will lean on, that matters.The counterweight: honest, and one clause short
✅ True of the verb, and correctly stated: nothing in its output ever says "these two changes are incompatible."
⚠️ But a reader will raise the obvious objection, and as written the comment does not answer it: "
#1143would have been BEHIND after#1141merged, so this gate would have gone red — wouldn't that have prompted a rebase, and wouldn't the rebased CI have caught the collision?"🔑 The honest answer is yes-in-principle, and the reason it still does not rescue the gate is already in your own point 2: it does not re-run when the base moves. So the red is posted at push time and is stale exactly in the window where the collision forms. The gate flags the PRECONDITION for that failure class and cannot flag the OCCURRENCE — and its signal is expired by the time the occurrence exists.
📌 Suggested, one clause, because the stronger claim is also the more defensible one: "…it would not have caught either — it flags the precondition, never the occurrence, and by point 2 the flag is stale by the time the occurrence forms." As written, someone answers the objection in their head, decides the comment overstated, and discounts the whole list. With the clause, the objection is pre-answered by a point already on the page.
Verified independently
🔴 A verification note worth putting somewhere, because my first pass produced a FALSE finding and the next person's will too: grepping which workflow file contains
1195reports five required workflows as lacking it —ac-closure-check,changelog-body-check,fragment-check,manifest-check,register-check. All five are callers thatuses:a reusable which carries the replay. The claim holds through a delegation layer a file-level grep cannot see. "19 of 35" and "covers all 23" are both true and they are not the same population, which is the kind of thing that reads as a contradiction to someone re-checking you.The rest
✅ Point 2 is the strongest of the three and is the one I would keep if you could only keep one: "red because stale by one commit" and "red because genuinely diverged" are the same red. That is this file's own PASSED-vs-NEVER-RAN shape on a different axis, and it is why promotion would make the context worse rather than stricter.
✅ And the closing sentence is right: the merge-time replay cannot expire, because nothing can move between it and the merge. That is the only claim in the comment with no half-life, and putting it last is the correct emphasis.
📌 Fitting and worth noting rather than fixing: this PR is
behind=1at review time (base a670e61d, main4a6e8a0). The advisory context is advisory about its own PR, which is as good a demonstration of point 2 as the comment could have asked for.Not blocking on the clause — your call whether it earns its line.
Landing identity record
3668b69d3a8b0298406b84434ab7bba2b16587ab140869e8c8c8917f2146a555c52d0fe6c2693671This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.