rivet: file FEAT-086 after the fact, promote FEAT-083 — v3.2.7 cuttable - #160
Merged
Conversation
… cuttable FEAT-086 did not exist. PR #159 merged with a commit and PR both titled "FEAT-086 (scry#157)" referencing an artifact I never created. That is untracked work — the anti-pattern the issue-hunt skill names explicitly, because it is invisible to the release plan and resurfaces as a gate surprise. `rivet validate` cannot catch it. It validates artifacts that EXIST; nothing checks that an id named in a commit message or PR title resolves to one. I found it by grepping for the id while promoting something else. Recorded as the feature's own residual, and worth a rivet-side check. FEAT-086 now carries what actually shipped, including the part worth keeping: the guard took FOUR attempts, and three of them were vacuous in ways that looked like they worked. The awk-range version is the instructive one — its two lists came out IDENTICAL, so it could not detect the drift it existed for, and it printed "FIRES" under mutation with the WRONG attribution, which nearly passed review. FEAT-083 promoted to accepted: merged, CI-green, and its end-to-end AC discharged on the BUILT artifact (the CI-built scry.wasm contains 3.2.6 and not the rules_rust 0.0.0 default, against the shipped v3.2.6 component which is the exact inverse). rivet release status v3.2.7: Cuttable, 2/2. NOT CUTTING — tagging publishes to crates.io and is irreversible. tests=0 fmt=0 rivet=0 claim-check=0 gate-coverage=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc
📐 rivet artifact deltaPR: #160 Base SHA: Validationhead — `rivet validate` resultbase — `rivet validate` result (for comparison)Artifact stats
full stats — headDiff (base → head)AADL model — headPosted by the |
avrabe
added a commit
that referenced
this pull request
Aug 27, 2026
…eck drift gate (FEAT-093, #130) (#167) * FEAT-091 (scry#161): connect the code side to the artifact side rivet ships commit-to-artifact traceability and it shipped here unconfigured, so `Broken refs` read 0 for want of any reference to check. That counter is what would have caught PR #159 merging with a commit naming FEAT-086 before the artifact existed (#160) -- found by grepping, not by a gate. TWO MEASUREMENTS CORRECT #161's PREMISE, and both changed the design. (1) #161 says "zero of 125 commits carry an artifact trailer". Configure a `Verifies` mapping and rivet instead reports linked:4, broken_refs:4 AND malformed_refs:4 -- the SAME four commits inflating three counters. None carry a trailer. All four are the prose line Verified: bazel build //:scry green + wasm-tools validate ok. which rivet's FUZZY trailer-key matcher reads as a malformed `Verifies:`. Five commits in this history carry such a line. A/B measured: with `Verifies` mapped the counters read 4/4/4; unmapped they read 0/0/0 and orphans rises 81 -> 85. So `linked: 4` was never real, and the honest baseline is linked:0 orphans:85 broken_refs:0. The mapping is kept to `Refs: traces-to` ALONE -- a finding, not laziness: a gate that fails on a normal English sentence gets switched off, and "Verified:" is an entirely natural thing to write. Reported upstream. (2) `rivet commits --strict` cannot BE the gate. It also promotes the repo-wide unimplemented-artifacts warning -- `Artifact coverage: 1/257 (0.4%)` -- which no pull request can satisfy. Measured: a range with one correctly-linked commit, zero orphans and zero broken refs STILL exits 1 under --strict. A gate no PR can pass is not a gate. So tools/check-commit-trailers.py reads the JSON summary and fails on only the three counters a PR owns -- orphans, broken_refs, malformed_refs -- ignoring unimplemented and artifact_coverage. Forward-only by construction: scoped to origin/main..HEAD, so the 85 pre-existing orphans never enter it and no history rewrite is needed. Its own CI job, so a traceability failure is legible in the checks list rather than buried behind artifact validation. VERIFIED END-TO-END on the real repo, three directions: crates/ commit, no trailer -> orphans=1, exit 1 same commit, `Refs: REQ-005` -> linked=1, exit 0 `Refs: FEAT-99999` (the #160 bug) -> broken_refs=1, exit 1 Plus: parse the JSON even when rivet exits non-zero (bailing on the exit code alone degraded an informative failure to "rivet exited 1"), and fail CLOSED when rivet is absent. Self-test of 6 cases runs BEFORE the real check. tests=0 fmt=0 rivet=0 claim-check=0 gate-coverage=0 trailers-self-test=0. Refs: FEAT-091 Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com> * scry#130: the required-check comment was claiming a gate that did not exist ci.yml said "Required-status-check names that temper's branch protection expects: Format, Clippy, Test". The ruleset required NOTHING -- so the file documented a gate the repo did not have, and every "merged green" rested on whoever merged remembering to check by hand. Now accurate: all ten CI jobs are required as of 2026-08-27, verified by every open PR flipping to mergeStateStatus=BLOCKED. Also records the constraint that decides which checks may be required at all: `Rivet artifact delta` lives in the PATH-FILTERED rivet-delta.yml, so it never reports on a code-only PR. Requiring it would block such PRs forever. Same trap applies to any job added to this file -- require it only after its name exists on every PR, i.e. after it has merged to main. Refs: FEAT-091 Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com> * FEAT-093 (scry#130): the required-check set cannot silently rot back scry#130 was enforced on 2026-08-27 -- all ten ci.yml jobs are now required. Verified in BOTH directions, which is what separates a gate from a setting: every open PR flipped to mergeStateStatus=BLOCKED on apply, and #164 merged CLEAN once its ten checks passed. A setting that was wrong for months can be wrong again, and it would be invisible -- CI still runs, PRs still go green, nothing announces that a job stopped being enforced. Three ways it rots: 1. a job is ADDED and never required -- scry#130 one job at a time, no symptom 2. a job is RENAMED -- the stale context never reports, every PR deadlocks 3. the ruleset is RESET -- it is named `temper-`, so something may regenerate it, and required_status_checks would simply vanish THE DEADLOCK RULE is why this is not set-equality. A check may be required only if it reports on EVERY PR. rivet-delta.yml is PATH-FILTERED, so `Rivet artifact delta` never runs on a code-only PR and requiring it would block such PRs forever. The gate fails if a path-filtered or `if:`-conditional job is ever required, and carries that exclusion WITH its reason so it is auditable rather than folklore. NEW JOBS ARE NOT FAILURES. A job added in the current PR does not exist on main and cannot be required yet. The gate reads ci.yml from BOTH origin/main and the PR and reports such jobs as PENDING -- without which it would fail on the very PR that introduces it. This PR introduces two and still exits 0. MUTATION-CHECKED AGAINST THE LIVE RULESET, not a fixture: `Format` was removed from the real required set (asserted 10 -> 9 before applying), the gate failed naming exactly that job, and restoring returned 10 contexts and exit 0. Also corrects ci.yml, which claimed "temper's branch protection expects Format, Clippy, Test" while the ruleset required NOTHING -- the repo was documenting a gate it did not have. rivet=0 claim-check=0 fmt=0 drift-self-test=0 trailer-self-test=0. Refs: FEAT-093 Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc Co-authored-by: Claude Opus 5 <noreply@anthropic.com> * Fix the broken CI workflow: GITHUB_TOKEN cannot read rulesets I broke CI on this branch. The required-checks drift gate ran the LIVE-ruleset check in CI under `permissions: administration: read`. That is not a grantable Actions scope, and a workflow requesting it is REJECTED WHOLESALE -- the run completed as `failure` with ZERO jobs and no log, which reads like a queue outage rather than a syntax error. It was caught only by noticing the PR showed 1 registered check instead of 12. A workflow's GITHUB_TOKEN cannot read rulesets at all, so the original design could never have worked in CI. Two modes now: --against-file compares jobs to .github/required-checks.txt. No API, so CI can run it. Catches the rot WE cause in our own PRs -- a job added or renamed without updating the file. (default) compares jobs to the LIVE ruleset AND cross-checks the file against it, because CI gates on the file and a drifted file means CI is gating on a fiction. Needs admin credentials. MUTATION-CHECKED, and the two modes fail DIFFERENTLY, which is the point: deleting `Clippy` from the file gives file mode: "job 'Clippy' exists on main and runs on every PR, but is NOT required" live mode: "'Clippy' is required LIVE but missing from .github/required-checks.txt" Both exit 1; both restore to 0. HONEST LIMIT, now in the artifact residual: a ruleset RESET is still not caught by CI and cannot be, since no workflow can see the live setting. It is caught the next time the live mode is run by hand. Closing that needs a PAT secret, which is a repo-owner decision. rivet=0 claim-check=0 gate-coverage=0 drift-self-test=0 drift-file=0 trailer-self-test=0 fmt=0. Refs: FEAT-093 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>
avrabe
added a commit
that referenced
this pull request
Aug 28, 2026
…191) FEAT-066 -> accepted. Merged in #190 with 13/13 CI green; its 10 tests re-run on main, gate-coverage reports 13 publishable crates in BOTH gates. Both ACs met, and AC2's structural guarantee was mutation-verified independently: appending a third tool object turns it red with ["analyze", "query", "verify"]. BUT PROMOTING IT ALONE WOULD HAVE DELETED WORK FROM THE PLAN. FEAT-066's title promises `analyze / query / verify`; its description defers `verify` to v3.4.0; and NOTHING carried the deferred half -- grepping every artifact for MCP returns FEAT-066 and nothing else. Mark it accepted and the verify tool stops existing anywhere in the plan. That is exactly scry#157/#160: an implementation with no artifact, invisible to the release plan, resurfacing later as a surprise. Here it would have been the inverse -- a plan item quietly evaporating on promotion. So FEAT-094 is filed first, in v3.4.0, `depends-on REQ-021`. Its deferral is measured, not cautious: REQ-021 measured `discharged` = 0 on every real commit pair, gate failing on all of them, ~47% uncertain, and `discharged` unreachable by construction on a stripped module. An always- uncertain verdict in an agent's tool loop is worse than an absent tool -- an absent tool is a fact an agent plans around; a useless one is noise it must learn to ignore. FEAT-094's AC3 is the part worth keeping: when `verify` is eventually added, FEAT-066's AC2 test must be UPDATED, not deleted. The structural guarantee moves from "verify is absent" to "verify is present and its verdict set is complete". A guard removed is a guard that stops being checked. v3.3.0 accepted 7/proposed 3; v3.4.0 accepted 9/proposed 3. rivet=0 claim-check=0 fmt=0 drift-gate=0 gate-coverage=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.
FEAT-086 did not exist
PR #159 merged with a commit and PR both titled
FEAT-086 (scry#157)— referencing an artifact I never created. That is untracked work, the anti-pattern the issue-hunt skill names explicitly: invisible to the release plan, resurfaces as a gate surprise.rivet validatecannot catch it. It validates artifacts that exist; nothing checks that an id named in a commit message or PR title resolves to one. I found it by grepping for the id while promoting something else — i.e. by luck, not by a gate. Recorded as the feature's own residual and worth a rivet-side check.The artifact now carries what actually shipped, including the part worth keeping: the guard took four attempts, three of them vacuous in ways that looked like they worked. The awk-range version is the instructive one — its two lists came out identical, so it could not detect the drift it existed for, and it printed
FIRESunder mutation with the wrong attribution.FEAT-083 promoted
Merged, CI-green, and its end-to-end AC discharged on the built artifact: the CI-built
scry.wasmcontains3.2.6and not therules_rust0.0.0default — the exact inverse of the shipped v3.2.6 component.Not cutting. Tagging publishes to crates.io and is irreversible.
tests 0 · fmt 0 ·
rivet validate0 · claim-check 0 · gate-coverage 0.