Record That a Disproof About Carried Text Has Nowhere to Live - #659
Merged
Conversation
A reviewer raised the same false claim twice about the same canonical, once against the hub's section 6 snippet and once against a downstream repository's carried copy of it. The hub had already disproved it by running both builtins on a jq 1.5 build, and the downstream repository could not cite that, because the record's own preamble says the entries are the hub's own and a repository carrying the file keeps the shape and the rules rather than the findings. That rule is right about what it governs. Carrying the hub's findings downstream would carry claims about files a repository does not have, each naming a revision it never had. It has no category for a finding whose subject is a canonical every repository holds a copy of, which is the case here. Recorded as a decision rather than a defect, because the second disproof came from the jq manual where the first came from a binary, so the independent re-derivation covered intent as well as behavior and a rule that suppressed it would have lost that. Doing nothing is a legitimate outcome. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a new backlog/decision entry documenting a governance gap: where to record disproved claims that apply to carried fleet text (so downstream repos can cite the disproof without importing hub-only “Disproved Claims” entries verbatim).
Changes:
- Adds a new
decisioncluster describing the “carried text disproof has nowhere fleet-wide to live” problem, with context, current state, and open questions. - References existing link targets (
copilot-instructions,section-model) to anchor the follow-up work without introducing new link definitions.
💡 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.
ptr727 added a commit
that referenced
this pull request
Aug 11, 2026
Two squashes. **Merge with a merge commit, never a squash, and never with `--delete-branch`** — this PR's head *is* `develop`. | PR | What | |---|---| | [#659](#659) | A backlog entry recording that a disproof about carried text has nowhere fleet-wide to live, after the same false claim was disproved twice about one canonical | | [#660](#660) | The deletion sweep now says a path grep finds *uses* of a file and misses *descriptions* of it | ## Why [#660](#660) wants promoting rather than waiting It corrects a rule that is actively being followed. Blog's resync ran the sweep correctly, merged, and still left `GOVERNANCE.md` "Repository Layout" describing `repo-config/` as holding *"the apply script"* — a file it had just deleted. The ESPHome-Config agent has since confirmed the identical wording sits unswept in its own `Repository Layout`, **ahead of its own `configure.sh` retirement**. Its eleven grep hits across five files are a floor rather than a count. Promoting this puts the corrected rule in front of that work rather than behind it. ## Verification on the merged head `spec/validate.py` OK, `spec/audit.py --selftest` PASS, 557 script tests OK, `editorconfig-checker` clean, `repo_gate --check eol` clean, working tree clean. One defect of my own was found and fixed inside [#660](#660): a Python `read_text`/`write_text` rewrite silently converted `RESYNC.md` to LF against this repo's CRLF. Restored in `a12cd33` and verified content-identical with `git diff --ignore-cr-at-eol`. `editorconfig-checker` is the only gate that sees that class. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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.
A backlog entry, not a fix. TODO disposition: New entry, per
TODO.mdrule 8.What happened
A reviewer raised the same false claim twice about the same canonical:
AUDIT.mdsection 6 snippet, where it was disproved by execution — running both builtins onjq-1.5-1-a5b5cbeshowedkeys_unsortedevaluates there whilewalk(.)answers a compile error. Recorded in.github/copilot-instructions.md.The downstream repository could not cite the first disproof. The record's own preamble says so:
Why this is a decision and not a defect
The existing rule is right about what it governs. Carrying the hub's findings downstream would carry claims about files a repository does not have, each naming a revision it never had. That is exactly the staleness the per-repository rule prevents, so the answer cannot be to relax it. Any fix has to distinguish the subject of a finding from the repository that filed it.
And the independent re-derivation was not wasted. The second disproof came from the manual where the first came from a binary, so together they cover intent and behavior rather than repeating each other. A rule that suppressed the second would have lost that.
The cost is bounded: once per repository per finding, on carried text only, and only when a reviewer raises the same point twice. Small enough that doing nothing is a legitimate outcome, which is why it is recorded as
decisionrather than acted on.Provenance
Found by the ESPHome-Config agent, which declined the finding on its own repository with a manual citation and a verified
keys ≡ keys_unsorted|sortequivalence check, then reported it upward because the finding was aimed at carried fleet text and would have been a fleet-wide defect had it held. It noted the citation would be "ready rather than relitigating it" for the next repository. I checked, and under the current rule it will not be, which is the gap this entry records.I verified the claim myself against the hub's record rather than adopting the peer's verdict. Both disproofs stand.
Verification
prose_lint --diff HEAD,repo_gate --check eol,markdownlint-cli2,editorconfig-checker: clean. Both reference names used (copilot-instructions,section-model) already resolve inTODO.md.🤖 Generated with Claude Code