ums(post-merge): the same-repo citation trap, as a fifth occurrence - #2212
Conversation
…occurrence Post-merge UMS top-up. #2207's own claude-review found that its prose described COMMENT_FLAG_RE in the present tense while the construct exists only on unmerged #2185. That is a fifth occurrence of the trap challenge-ambiguous-terminology.md already documents (gha#151 twice, #208, #217), and CLAUDE.md already says that section covers a same-repo sibling PR unchanged -- so this records the recurrence rather than opening a new shape, which a first draft wrongly did in verify-the-right-artifact.md. - The increment is why thorough review misses it: every reviewer verifies the claim against the branch it is ABOUT, which is correct for its truth, so it passes -- and the more carefully that branch is checked, the more settled the sentence looks. Nobody asks which artifact the READER lands on. - Corrected the section's own 404 claim at source. It read as though a link checker catches a premature cross-repo citation; on all four measured cases it could not, for two different reasons -- a backticked path is not a link, and the repo-root link resolves. - The Do bullet settles merge state from the PR's own state or an empty path-scoped git diff, per pr-on-claim. NOT git merge-base --is-ancestor: a review round demonstrated it exits 1 for #2205, #2202 and #2201, all merged, because this repo squash-merges and the squash commit excludes the branch's commits. pr-on-claim documents exactly that, and a first draft prescribed the broken check anyway. - least-flexible-tool.md: dropped a self-refuting clause #2207 shipped, which said `git grep` finds the constant nowhere on main while itself putting the string on main. Deferred to #2210: broadening reorganize-prose.md's content-preservation check, which is gated on a MOVE and so never fires on a scripted whole-file rewrite that drops the tail. A first draft of that entry was cut in review; the issue records what it got wrong.
|
Working on this --- paws off until I'm done. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| or construct in another repo is itself unverifiable --- and will 404 a link | ||
| checker --- if the PR that adds it hasn't merged yet. | ||
| **Cross-repo citations have a merge-order trap.** | ||
| Citing a specific file path or construct in another repo is itself unverifiable if the PR that adds it hasn't merged yet --- and a link checker will not save you, as the measured cases below show: a backticked path is not a link, so nothing crawls it. |
There was a problem hiding this comment.
Minor: "as the measured cases below show" is a forward reference — it points the reader at content (the case parentheticals) they haven't reached yet. Per this repo's own forward-references.md, pointing accurately is what qualifies a phrase under the rule, not what exempts it ("Direction is not the test" section) — so this isn't excused by the target genuinely being further down. Since the nearby (Caught by this very guideline four times now...) parenthetical already carries the referenced cases, consider dropping "below" (e.g. "a link checker will not save you: a backticked path is not a link...") rather than pointing forward to it.
Not blocking — this is exactly the class of nit fix-forward-references/ffr is meant to catch, worth a quick pass since this file is itself part of the corpus that defines the rule.
There was a problem hiding this comment.
Addressed in 7b52990b. Dropped the forward pointer: the clause now reads "on any case measured here" rather than "as the measured cases below show", so it makes its claim without asking the reader to go looking.
| (Measured on [ai-config#2207](https://github.com/Morrison-Lab/ai-config/pull/2207), whose prose described a constant in `hooks/require-agent-disclosure.py` in the present tense. | ||
| That constant exists only on [#2185](https://github.com/Morrison-Lab/ai-config/pull/2185), open at the time, and its introducing commit was an ancestor of neither `main` nor the citing branch. | ||
| Twelve pre-push adversarial rounds ran on that PR without raising it, and the round that did raise it had itself executed the regex, the commit ancestry, and the timestamps against `#2185` --- all correct, and all about the wrong branch. | ||
| Two separately-dispatched same-vendor passes then raised it nine minutes apart, once the diff was read as something about to become `main`.) |
There was a problem hiding this comment.
This sentence doesn't name which two passes it means, and the most plausible reading doesn't match the PR #2207 record.
The two claude-review comments on #2207 are ~9m55s apart (05:36:44Z and 05:46:39Z) — close enough to "nine minutes" to be the pair meant. But only the first one raised the COMMENT_FLAG_RE finding; the second explicitly says "This round's findings: none" and "Ready for merge" — it confirmed the fix, it didn't raise anything. So as worded, "raised it nine minutes apart" doesn't match either round's actual content (only one round raised it).
If instead this means the two parallel CLAUDE.md-compliance subagents within round 1 (both flagging the same finding, per that comment's own "the two CLAUDE.md-compliance passes surfaced two findings"), "nine minutes apart" seems like the wrong figure for two subagents dispatched in parallel within one job.
Could you clarify/name which two passes are meant? As it stands this reads as an inaccurate or at least ambiguous factual claim about #2207's review history (worth double-checking per this PR's own "watch for hallucinations" review instruction).
There was a problem hiding this comment.
Addressed in 7b52990b, and your uncertainty was well placed --- the claim was true but unnameable, so there was no way for you to check it.
The two passes are a session verification pass at 05:27:25Z (comment 5405924657) and claude-review at 05:36:44Z, 9m19s apart, both raising COMMENT_FLAG_RE. The sentence now names both.
Your reconstruction was the natural one and it is why the sentence needed fixing: comparing the two claude-review comments gives ~9m55s, which is close enough to "nine minutes" to look like the right pair, but the later one at 05:46:39Z reports zero findings and Ready for merge --- it confirmed the fix rather than raising anything. The entry now says that explicitly, so the next reader does not repeat the same reconstruction.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…e finding claude-review round 1 on 4112c6c, both findings addressed: - "as the measured cases below show" pointed forward, which forward-references.md says is not excused by pointing accurately. Now "on any case measured here". - "Two separately-dispatched same-vendor passes then raised it nine minutes apart" was accurate but unnameable, so the reviewer could not check it and flagged it as a possible inaccuracy. The two are a session verification pass at 05:27:25Z (comment 5405924657) and claude-review at 05:36:44Z -- 9m19s apart, both raising COMMENT_FLAG_RE. Named both, and said why the count looks wrong from the outside: the LATER claude-review round at 05:46:39Z reports zero findings and Ready for merge, so a reader comparing only the two claude-review comments sees one raise rather than two. That is exactly the reconstruction the reviewer attempted.
|
|
||
| On [ai-config#2185](https://github.com/Morrison-Lab/ai-config/pull/2185) --- unmerged as of 2026-08-24, so `git grep COMMENT_FLAG_RE` finds nothing on `main` until it lands --- `COMMENT_FLAG_RE` in `hooks/require-agent-disclosure.py` decides whether a `gh issue|pr close|reopen` segment posts a comment, which it does only when `--comment` or its shorthand `-c` is present. | ||
| On [ai-config#2185](https://github.com/Morrison-Lab/ai-config/pull/2185) --- open as of 2026-08-24, so the constant below is defined on that branch only --- `COMMENT_FLAG_RE` in `hooks/require-agent-disclosure.py` decides whether a `gh issue|pr close|reopen` segment posts a comment, which it does only when `--comment` or its shorthand `-c` is present. | ||
| Its short-flag alternative was edited four times on that branch, through five forms. |
There was a problem hiding this comment.
Minor: "so the constant below is defined on that branch only" is itself a forward reference — COMMENT_FLAG_RE isn't named until later in the very same sentence (after the next em-dash aside). Per this repo's own forward-references.md, pointing accurately doesn't exempt a phrase from the rule.
This is the same class of issue this PR already fixed once in challenge-ambiguous-terminology.md:22 (dropping "below" there) — it just wasn't caught in this file in round 1. Not blocking, but worth a consistent fix since this file is part of the same corpus.
| On [ai-config#2185](https://github.com/Morrison-Lab/ai-config/pull/2185) --- unmerged as of 2026-08-24, so `git grep COMMENT_FLAG_RE` finds nothing on `main` until it lands --- `COMMENT_FLAG_RE` in `hooks/require-agent-disclosure.py` decides whether a `gh issue|pr close|reopen` segment posts a comment, which it does only when `--comment` or its shorthand `-c` is present. | |
| On [ai-config#2185](https://github.com/Morrison-Lab/ai-config/pull/2185) --- open as of 2026-08-24, so the constant below is defined on that branch only --- `COMMENT_FLAG_RE` in `hooks/require-agent-disclosure.py` decides whether a `gh issue|pr close|reopen` segment posts a comment, which it does only when `--comment` or its shorthand `-c` is present. | |
| Its short-flag alternative was edited four times on that branch, through five forms. | |
| On [ai-config#2185](https://github.com/Morrison-Lab/ai-config/pull/2185) --- open as of 2026-08-24 --- `COMMENT_FLAG_RE` in `hooks/require-agent-disclosure.py`, defined only on that branch, decides whether a `gh issue|pr close|reopen` segment posts a comment, which it does only when `--comment` or its shorthand `-c` is present. |
There was a problem hiding this comment.
Addressed in 54607dc7. Split into two sentences so the constant is named first and its provenance second, rather than pointing ahead across an em-dashed aside.
Worth noting for the record: this is the third pass over that one clause --- self-refuting first (it claimed git grep finds the constant nowhere on main, in a sentence that put the string on main), then forward-pointing once that was fixed. Your framing is right that it is the same class introduced alongside the fix for it, which is exactly the "a later round can find a defect in the fix rather than the original" shape learn-from-review-findings.md documents --- here running three deep on a single sentence.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
claude-review round 2 on 7b52990. The round-1 fix for a self-refuting clause introduced a forward reference in the same slot: "so the constant below is defined on that branch only" pointed ahead to COMMENT_FLAG_RE, which the sentence did not name until after the em-dashed aside. Split into two sentences so the constant is named first and its provenance second. Third pass over this one clause -- self-refuting, then forward-pointing, now neither -- which is the corpus's own "a later round can find a defect in the fix" running on a single sentence.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Claude finished review — View run No matches found (grep exited 1, meaning no non-ASCII punctuation) — confirmed clean, and the link checker passes. Everything checks out. This confirms the state already established across three prior review rounds. Review: PR #2212Confirming review — no new findings. The PR's diff against its current merge-base ( I verified this directly: I independently re-checked substance rather than relying only on the diff-empty result:
No new issues found in this round. No hallucinated APIs, paths, or citations; no CLAUDE.md violations; no redundant content. VerdictReady for merge. No content changes since the prior "Ready for merge" verdict at commit Reviewed commit: 3e0b84d |
1 participant
Post-merge UMS top-up for #2207, covering what the merge itself taught.
What happened
#2207's own
claude-reviewfound that its prose describedCOMMENT_FLAG_REinhooks/require-agent-disclosure.pyin the present tense, while the construct exists only on #2185, still open. Twelve pre-push adversarial rounds had executed that regex, its sibling forms, the commit ancestry and the timestamps --- all correct, and all against#2185.What this records
A fifth occurrence, not a new rule.
challenge-ambiguous-terminology.mdalready documents this trap (gha#151 twice, #208, #217), andCLAUDE.mdalready says that section applies to a same-repo sibling PR unchanged. A first draft opened a new shape inverify-the-right-artifact.mdand was cut in review as a duplicate.The increment is why thorough review misses it. Every reviewer verifies the claim against the branch the claim is about, which is the correct artifact for its truth --- so it passes, and the more carefully that branch is checked, the more settled the sentence looks. Nobody asks which artifact the reader will be standing on, because that is a question about the claim's audience rather than its truth. This is the one trap in that section where verification effort runs the wrong way.
Two corrections to the section itself
The 404 claim was wrong at source. It read as though a link checker catches a premature cross-repo citation. On all four measured cases it could not, for two different reasons: a backticked path is not a link so nothing crawls it, and the repo-root link resolves fine. Fixed where the claim is made, not by appending a rebuttal.
The Do bullet does not use
git merge-base --is-ancestor. A first draft prescribed it. A review round ran the negative control and found it exits1for #2205, #2202 and #2201 --- all merged --- because this repo squash-merges and the squash commit excludes the branch's own commits. So it trades the grep's false positive for a permanent false negative.pr-on-claim.mddocuments exactly this ("abase..branchcommit range cannot answer 'is this merged' in a squash-merging repo, at any freshness"), and the bullet now uses the instruments that fragment prescribes: the PR's own state, or an empty path-scopedgit diff.Also
least-flexible-tool.mddrops a self-refuting clause #2207 shipped, which claimedgit grepfinds the constant nowhere onmainin a sentence that itself put the string onmain.Deferred
#2210 ---
reorganize-prose.md's content-preservation check is gated on a move, so a scripted whole-file rewrite that drops the tail never trips it. Hit live in this session. A first draft of that entry was cut in review with five findings against it; the issue records what it got wrong so the eventual entry does not repeat them.Prose only, no code.
check-links.py,markdownlint-cli2,semantic-line-breaks.py, CI's clause-break rule,git diff --checkand a non-ASCII scan are green, and a bidirectional word diff confirms nothing was lost.