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 |
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