State the negative-result trap as a demand for evidence - #82
Merged
Conversation
The trap said a query matching nothing reads as a clean result, which is true and names no action. The host side put the general form better: before believing a negative, establish that the check could have produced a positive. That is the same rule with a step in it, and the step is what was missing every time this cost something. Four costumes are now listed under it, because seeing them as one failure is the whole value: a query that cannot see its target, including a journal grep run from an account not in adm or systemd-journal, where the lines exist and are simply not shown to it a rule naming a target that does not exist, which is the .gitattributes pin for two files this repository has never carried a filter whose precondition is unstated, which is reading an absent X-Blog-Check as a visitor when the field exists only because the edge is configured to log it a tool reporting success having done nothing, which is git restore-mtime v2022.12 printing a count and processing none of it No count is claimed for them. An earlier draft said six false passes and the list does not add to six, some were near-misses caught in time, and one has not happened at all. Two State rows are re-measured while here, since both had gone false today. Production serves a new release and the hard-linking result now exists, 1,052 of 3,275 with every linked media file at 644. The backup timer fired unattended at 09:11:01 UTC, proven by both halves of the standard rather than either alone. The serving release id is no longer repeated outside the State table. A value that moves with every deploy should exist in one place, and that duplicate had already gone stale twice in a day. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the operational backlog/state tracking in TODO.md to (1) record the latest production/staging measurements and (2) reframe the “negative-result trap” as an actionable requirement to prove a check could have produced a positive result.
Changes:
- Refresh the State table entries for production (new serving release + hard-linking measurements) and operations (first unattended timer run evidence).
- Remove duplication of the moving production release ID outside the State table to avoid staleness.
- Replace the prior “empty result reads as clean” note with a more actionable rule: before believing a negative, prove the check could have produced a positive, with enumerated failure “costumes”.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The file mode was plain text beside literals the same table wraps in code, and the tool was named by its subcommand invocation where the two nearby mentions use the binary name. Both now read the same way throughout. The distinction is worth keeping straight rather than merely consistent: git-restore-mtime is the tool, and git restore-mtime is one of the two ways it resolves. This sentence is about the tool. Found by Copilot review on #82. Co-Authored-By: Claude Opus 5 (1M context) <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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Honours a commitment made in the agent channel: the host side generalised two of this repo's findings into one rule, and I said I would bring it back here rather than leave it in a file this repository does not carry.
The change
The trap said a query that matches nothing reads as a clean result. True, and it names no action.
Same rule with a step in it, and the step is what was missing every time this cost something. Be careful has nothing to perform; prove the check can fire does.
Four costumes are listed under it, because seeing them as one failure is the whole value:
admorsystemd-journal— the lines exist and are simply not shown to it.gitattributespinning two files this repository has never carriedX-Blog-Checkas a visitor, when the field exists only because the edge is configured to log itgit restore-mtimev2022.12 printing a count and processing none of itNo count is claimed. An earlier draft of this said "six separate false passes" — the list does not add to six, some were near-misses caught in time, and one has not happened at all. Asserting a number I could not defend, in a trap about unverified claims, was not a great look.
Two State rows re-measured while here
Both had gone false today:
644, and 11.4 MB incremental against 585 MB.LASToff-— rather than either alone.One durable fix
The serving release id is no longer repeated outside the State table. It moves with every deploy, and that duplicate had already gone stale twice in a day. A moving value gets one home.