Conversation
…for stat-source citations
A real, correctly-cited PR can still be a false positive if it's cited as
the source of a supporting fact ("documented in-code by PR #NN as 13
verified against prod") rather than as the fix for the blocker. Distinct
shape from precedent-citation (that class isn't naming a blocker at all).
Bit the same task twice, two days apart (task_1786902033624, 2026-08-20
then 2026-08-22), both times resolved manually by the same peer -- the
tool has no memory of a prior resolution, so it re-litigates indefinitely.
Reuses the existing exclude-list mechanism (PRECEDENT_CITATION_CUE_REGEX,
2026-08-12) rather than new persisted state -- same failure shape, same
fix technique.
5cb4c57 to
4ba9974
Compare
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Rebased onto current main (isolated worktree, per the shared-checkout discipline). Real conflict in tests/unit/bus/system.test.ts -- both this branch and main independently grew the same describe block with new, non-overlapping test cases (this PR's stat-source-citation tests; main's negation/dismissal tests from #167 in the interim). Merged both sets in, nothing dropped from either side. Verified: 45/45 tests pass in the merged file, tsc --noEmit clean. No longer conflicted -- mergeable=true, just needs review. |
1 participant
Summary
check-stale-blockersflagged the same false positive on the same task twice, two days apart(
task_1786902033624, 2026-08-20 then 2026-08-22) — a real, correctly-cited PR (conduit#1424)cited as the source of a supporting statistic ("documented in-code by conduit PR #1424 as 13
verified against prod"), not as the fix for the task's blocker. Both times a peer had to manually
re-trace and correct it, because the tool has no memory of a prior resolution.
This is a different shape from the existing precedent-citation false-positive class (2026-08-12,
PRECEDENT_CITATION_CUE_REGEX) — that class isn't naming a blocker at all ("same shape as theaction1 precedent, PR grandamenium#306"). This one names a real, relevant PR, just not as the fix.
Fix
Widens the existing exclude-list mechanism with a second cue category (
documented ... by,verified against,sourced from,per PR #NN's own data/finding/...) rather than adding newpersisted state (no resolved-citations file to keep in sync). Reuses the exact regex-window
technique already proven in production for the precedent-citation class.
Known limitation, found and documented rather than silently fixed
Writing the "mixed citation" regression test surfaced a pre-existing architecture gap: a cue
phrase sitting in the textual GAP between two close PR references can leak into the next
reference's before-window, because the existing prev-match-end clamp only protects against
reaching before/into the previous match's own span, not the prose after it. Not fixed here (out
of scope for this diff) — documented in the test file as a known limitation for follow-up if a
real case is ever reported. Scoped test uses well-separated sentences to avoid it.
Verification
git worktree.tests/unit/bus/system.test.ts), including 3 newcases for the real incident text, a mixed-citation case, and two more cue phrasings.
tests/unit/bus/+tests/integration/: 857 passed, 3 failed — all 3 arephase5-performance.test.tscron-startup timing thresholds, already documented in this repo'sown CLAUDE.md as environment-flaky under load, unrelated to this change (confirmed: no code
touched here is anywhere near cron-startup timing).
npm run buildsucceeds.Not merging/self-approving
Opened for review per normal process.
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is enabled.