Promote FEAT-087 / FEAT-088 / FEAT-090 to accepted — v3.4.0 not-ready 7 → 4 - #169
Closed
avrabe wants to merge 1 commit into
Closed
Promote FEAT-087 / FEAT-088 / FEAT-090 to accepted — v3.4.0 not-ready 7 → 4#169avrabe wants to merge 1 commit into
avrabe wants to merge 1 commit into
Conversation
avrabe
force-pushed
the
promote-v34-verified
branch
from
August 27, 2026 05:47
88d5578 to
3129ed0
Compare
avrabe
added a commit
that referenced
this pull request
Aug 27, 2026
ci.yml recorded the rule: require a job only once its name exists on every PR, i.e. after it merges to main. Correct, and incomplete -- a PR opened BEFORE the job existed still does not have it, so it can never report and is blocked forever. Observed rather than theorised. When #167 added two jobs and both were required, PRs #168 and #169 each showed 11 checks with 0 of the 2 new ones. Both would have deadlocked on a check that could never run. Both were rebased and now register 13. The complete procedure is now in ci.yml: 1. merge the PR that adds the job 2. add the context to the ruleset AND to required-checks.txt, ruleset FIRST (CI gates on the file, so a file ahead of the ruleset means CI is gating on a fiction -- the live-mode cross-check says exactly that) 3. REBASE EVERY OPEN PR drift-gate=0 gate-coverage=0 claim-check=0 rivet=0. Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
📐 rivet artifact deltaPR: #169 Base SHA: Validationhead — `rivet validate` resultbase — `rivet validate` result (for comparison)Artifact stats
full stats — headDiff (base → head)AADL model — headPosted by the |
… 7 -> 4 `implemented`/`proposed` count as NOT-yet-verified in the release gate, so a shipped, green feature left there blocks its release indefinitely. These three have shipped AND been verified, so leaving them proposed understates the release just as promoting them early would overstate it. Evidence for each, grounded rather than remembered: FEAT-087 (#162, 11/11 CI green) -- 3 oracles re-run on main just now: the tier-discrimination test, the tier-2 independence pin, and the module-scoped decision. Mutation-checked both directions when landed. FEAT-088 (#163, 11/11 CI green) -- the gate's --self-test PASSES and the real check PASSES on main, and it is wired into ci.yml (self-test before the real check). Mutation-checked against the real repo when landed. FEAT-090 (#166, 11/11 CI green) -- 5 oracles re-run on main just now, including the polarity test that dies only under the `&=` -> `|=` mutant. NOT promoted, deliberately: FEAT-089 -- FILED, not built. The non-zero-fact work does not exist yet; its own AC#1 requires a red test that is still red by design. FEAT-064 -- AC3 closed by measurement in #164, but AC1 remains FALSIFIED (repaired by FEAT-077 only for uniquely-named functions). Closing one AC does not clear the artifact, and REQ-020 stays blocked behind it. FEAT-057, FEAT-065, REQ-021 -- unbuilt. rivet=0 claim-check=0 fmt=0. Refs: FEAT-087 Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
avrabe
force-pushed
the
promote-v34-verified
branch
from
August 27, 2026 06:50
3129ed0 to
f70db45
Compare
avrabe
added a commit
that referenced
this pull request
Aug 27, 2026
* Sync required-checks.txt to the ruleset: 10 -> 12 (scry#130) #167 landed FEAT-091 and FEAT-093, so `Commit traceability (rivet)` and `Required checks track CI jobs (scry#130)` now exist on main and run on every PR. The drift gate immediately moved them from PENDING to FAIL -- which is the transition it was built to make: a requirable job that is not required is scry#130 recurring one job at a time. Both were added to ruleset 16891064 (10 -> 12 contexts), and this syncs the checked-in file so the two agree. Order matters: the RULESET was updated first and the file second, because CI gates on the file -- a file listing checks the ruleset does not require would mean CI gating on a fiction, which the live-mode cross-check reports in exactly those words. Briefly red on main is the honest state during that window. Verified: file mode PASS, live mode PASS with `file agrees: True`. rivet=0 claim-check=0 drift-self-test=0. Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com> * "Require it after merge" was necessary but not sufficient ci.yml recorded the rule: require a job only once its name exists on every PR, i.e. after it merges to main. Correct, and incomplete -- a PR opened BEFORE the job existed still does not have it, so it can never report and is blocked forever. Observed rather than theorised. When #167 added two jobs and both were required, PRs #168 and #169 each showed 11 checks with 0 of the 2 new ones. Both would have deadlocked on a check that could never run. Both were rebased and now register 13. The complete procedure is now in ci.yml: 1. merge the PR that adds the job 2. add the context to the ruleset AND to required-checks.txt, ruleset FIRST (CI gates on the file, so a file ahead of the ruleset means CI is gating on a fiction -- the live-mode cross-check says exactly that) 3. REBASE EVERY OPEN PR drift-gate=0 gate-coverage=0 claim-check=0 rivet=0. Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Contributor
Author
|
Superseded by #173 — same branch, rebased onto main. Auto-closed by GitHub when I deleted |
avrabe
added a commit
that referenced
this pull request
Aug 27, 2026
…175) Operating the gate exposed a hole in the procedure it enforces. Landing a job while its required-checks.txt entry arrives in a SEPARATE PR leaves main AND every open PR red until that follow-up merges. #167 did exactly that: the moment it merged, main failed its own drift gate and #168/#169 went red on a file they could not fix. The fix is structural, not another comment. The gate now FAILS a PR that adds a requirable job which is not in required-checks.txt, so the job and its entry ship together and the window does not exist. VERIFIED ON THE REAL REPO, both directions: job added, no file entry -> exit 1, naming it and quoting the instruction same job WITH its entry -> exit 0 (pending the ruleset update only) restored -> exit 0 Plus two new self-test cases covering exactly those, 7 in total. The procedure in ci.yml is now three steps with no red window: 1. in the SAME PR: add the job AND its required-checks.txt entry 2. after merge: add the context to the ruleset (instant, via the API) 3. rebase every open PR Steps 2 and 3 were each learned by getting them wrong. A required context whose job does not exist deadlocks everything; a job whose context does not exist deadlocks nothing. The asymmetry is why the ordering matters. drift-self-test=0 drift-file=0 gate-coverage=0 trailer-self-test=0 claim-check=0 rivet=0 fmt=0. Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
proposedcounts as not-yet-verified in the release gate, so a shipped, greenfeature left there blocks its release indefinitely — which is what v3.4.0 has been
carrying. Promoting these three is the honest counterpart to not promoting the
others.
Evidence, grounded rather than remembered
--self-testPASSES and the real check PASSES; wired inci.ymlself-test-first&=→|=Each was mutation-checked in both directions when it landed; this re-runs them against
mainrather than trusting the merge.Deliberately NOT promoted
design (a correct div-by-zero fix must stop raising the obligation; it doesn't yet).
(FEAT-077 repairs it only for uniquely-named functions). Closing one AC doesn't clear
the artifact, and REQ-020 stays blocked behind it.
Result
Still not cuttable, and the four that remain are genuine work rather than
bookkeeping — which is the point of doing this separately from shipping features.
rivet=0 claim-check=0 fmt=0🤖 Generated with Claude Code
https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc