Repair a claim that was true when written and false for months after - #198
Merged
Conversation
artifacts/aspice-vmodel.yaml said "the dev REQ-* carry no verifies link by construction". Measured today: 15 of 21 dev requirements carry an incoming `verifies`, every one of them from a `verification` artifact. The statement is simply false. It was TRUE when FEAT-033 landed (bea3ddf) — no artifact type could source a `verifies` link onto a dev REQ-*, which is the gap FEAT-033 existed to close. Commit 6be7359 then added artifacts/verifications.yaml ("wire the dev V's right side — 15/21 REQs verified, 6 honestly open"), whose `verification` artifacts link straight at the dev REQ-*. Nothing revisited this comment. It stayed checked in, false, for months. THE REPLACEMENT CARRIES NO COUNT. Writing "15 of 21" would drift exactly the same way, just more slowly. The comment now states the STRUCTURE — dev REQ-* are verified by `verification` artifacts in verifications.yaml, whose DELIBERATELY UNCOVERED block names each gap with what evidence would close it — and points at `rivet coverage` for the current split rather than restating it. HOW IT SURVIVED ME YESTERDAY, which is the reusable part. FEAT-097 (#196) repaired a corrupted sentence one line above this one. I was editing for a different defect and treated the surrounding prose as given, so I rewrote its neighbour and propagated it verbatim. Proximity to a thing you are fixing is not evidence that a claim is true; a false statement adjacent to a repair is likelier to be re-blessed than one nobody is looking at. Checked for other copies before fixing the one I happened to be reading: `carry no verifies link` appears exactly once in the repo, and FEAT-033's own description states it in the PAST tense ("requirements had no verifies backlinks"), which is still historically accurate. The residuals added yesterday to FEAT-033 and FEAT-097 do not repeat it. NO GATE ADDED, and that is a decision. The six uncovered requirements are already declared individually in verifications.yaml with a "Would verify" for each — the best artifact in this repo for its purpose — and it sits directly above the data it describes. Binding it mechanically would mean scraping `^#\s+(REQ-\d+)` out of a YAML comment, which is this repo's dominant documented failure class (four instances of text-matching when the question is discrimination) deployed to guard a block its own editor is already looking at. `rivet coverage --fail-under` was also considered and rejected: below the current value it is scry#117's loose floor, at it any legitimate artifact addition that shifts the denominator fails. Refs: FEAT-097 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc
📐 rivet artifact deltaPR: #198 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
Sep 3, 2026
#206) Version bump moves the workspace version AND every pinned inter-crate dependency together — 19 sites. They have to move as one: `cargo publish` resolves each leaf from the crates.io index, so a stale `version = "3.2.7"` pin would publish a 3.3.0 core depending on the previous release. 1 workspace version (Cargo.toml) 13 pinned inter-crate deps (analyze-core x10, viz, segment, mcp) 1 Bazel CARGO_PKG_VERSION pin (scry#152 — the shipped component announced `scry 0.0.0` when this was missed) 1 README shipped-claim 3 claims.yaml (2 claim texts + 2 count-min patterns, minus overlap) THE CLAIM-CHECK GATE DID ITS JOB AGAIN, UNPROMPTED. The bump script failed partway through claims.yaml on a regex-escaping bug, leaving Cargo.toml and README moved but claims.yaml stale — and claim-check immediately went 7/7 -> 5/7. That is exactly the drift it exists for, caught within one command of being introduced. Back to 7/7 after. The HISTORICAL "what v3.2.7 did" note in claims.yaml is deliberately NOT bumped — it refers to the shipped-0.0.0 bug of that release, and a guard in the bump script asserts it survives. Also fixed two things the bump exposed rather than shipping them: * README said "the full v0.1 -> v3.2 arc is done" while announcing v3.3.0 — the same tense-of-a-claim drift repaired in #198. * crates/scry-mcdc/Cargo.lock still pinned scry-sai-core 3.2.7; the MC/DC gate builds scry_mcdc.wasm from it. CHANGELOG carries the release's falsification statement per methodology, with the weakest of the four criteria flagged as such: the before/after is not corpus-wide, and #126's reporter has offered theirs. It also states what this release does NOT give you, because both are things a consumer would otherwise assume: * obligation identity is NOT stable across builds — FEAT-073 measured 43-45% churn per build (#123). Anchors and the feed schema ship; the guarantee behind them does not. Treat an obligation_id as stable WITHIN a build only. * the MCP `verify` tool is structurally absent — FEAT-065 was refuted pre-ship with six wrong-verdict paths (#122). NOTE: `scry-sai-mcp` is a FIRST-TIME publish. v3.2.7's tree contained no crates/scry-mcp. It is already wired into scripts/publish.rs in leaf-after-core position. Verified: cargo test 160 + 12 pass, fmt clean, rivet validate PASS, claim-check 7/7, release-ordering PASS, required-checks PASS, `rivet release status v3.3.0` = cuttable (7 accepted / 0 proposed). Refs: FEAT-066 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.
The drift
artifacts/aspice-vmodel.yamlsaid:Measured today: 15 of 21 dev requirements carry an incoming
verifies, every one from averificationartifact (VER-001..VER-015). The statement is false.It was true when written. At
bea3ddf(FEAT-033) no artifact type could source averifieslink onto a dev REQ-* — that was precisely the gap FEAT-033 existed to close. Then6be7359addedartifacts/verifications.yaml— "wire the dev V's right side — 15/21 REQs verified, 6 honestly open" — whose artifacts link straight at the dev REQ-*. Nothing revisited this comment. It stayed checked in, false, for months.The replacement carries no count
Writing "15 of 21" would drift the same way, just more slowly. The comment now states the structure — dev REQ-* are verified by
verificationartifacts inverifications.yaml, whoseDELIBERATELY UNCOVEREDblock names each gap with what evidence would close it — and points atrivet coveragefor the current split rather than restating it.How it survived me yesterday
FEAT-097 (#196) repaired a corrupted sentence one line above this one. I was editing for a different defect and treated the surrounding prose as given, so I rewrote its neighbour and propagated this verbatim.
Proximity to a thing you are fixing is not evidence that a claim is true. A false statement adjacent to a repair is likelier to be re-blessed than one nobody is looking at.
Checked for other copies first
Fixing only the copy I happened to be reading would be the same failure shape as the one being corrected:
carry no verifies link— appears exactly once in the repoNo gate added — and that is a decision, not an omission
The six uncovered requirements (REQ-003/004/005/007/020/021) are already declared individually in
verifications.yaml, each with a "Would verify:" naming the evidence that would close it. That block sits directly above the data it describes.Binding it mechanically would mean scraping
^#\s+(REQ-\d+)out of a YAML comment — this repo's dominant documented failure class (four instances of text-matching when the question is discrimination) — deployed to guard a block whose own editor is already looking at it. Bad trade.rivet coverage --fail-underwas also considered and rejected: set below the current value it is #117's loose floor; set at it, any legitimate artifact addition that shifts the denominator fails.Refs: FEAT-097
🤖 Generated with Claude Code
https://claude.ai/code/session_01KkNzkNYzPh7366DkNijeNc