docs: record how the duplicate-count rule's own arithmetic was caught - #333
Conversation
The rule was written wrong first — "subtract each parent's own duplicate count" double-counts a baseline both parents share, so a correct merge scores -1 and three headers where the parents had two score 0, which is the case the check exists to catch. Worth recording rather than quietly fixing because of WHERE the error was: the script that resolved the merge compared against the parents' maximum and was right; only the prose was wrong. A rule and its implementation drifted apart inside the paragraph warning about drift, and a reviewer reading the sentence against its own arithmetic is what caught it (#330).
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 31 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Comment |
There was a problem hiding this comment.
Pull request overview
Updates project process documentation in AGENTS.md to record how the “duplicate-count” merge-conflict rule’s arithmetic error was originally caught, clarifying the difference between the (correct) script behavior and the (previously incorrect) prose.
Changes:
- Adds a paragraph explaining why “subtract each parent’s duplicate count” double-counts shared baselines and can mask real duplicates.
- Documents the key lesson: validate written rules against the behavior of the tooling you actually ran (with PR #330 as the concrete example).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Line 268 still called the mechanism "the subtraction" — three lines below a bullet that now says in bold not to subtract both parents' counts. A reader taking it at face value would implement the arithmetic the passage exists to correct, so it is the defect surviving its own correction rather than a wording nit. Replaced with the comparison the bullet actually prescribes, and the recurrence is now recorded in the paragraph itself: it survived the rewrite that forbade it, in the same paragraph, and was caught only on a second reading. Naming a failure mode confers no immunity to it, and "re-read the whole enclosing unit, not the sentence you changed" has now failed on the unit teaching it.
Summary
One paragraph in
AGENTS.md, closing out changedocs/changes/0042-tall-tile-control-geometry.md's documentation work. No source changes, no task list touched, 0042 stays complete.The merge-conflict duplicate-count rule was written wrong first: "subtract each parent's own duplicate count" double-counts a baseline both parents share, so a correct merge scores −1 and a genuinely duplicated row — three headers where the parents had two — scores 0, which is exactly the case the check exists to catch. That arithmetic was corrected in #330; this records how it was found, which the note itself did not say.
Why it is worth a paragraph rather than a quiet fix
The error was in the prose, and the script that actually resolved the merge was right — it compared each row's multiplicity against the parents' maximum, which is the correct form. So a rule and the tool implementing it had drifted apart inside the paragraph warning about exactly that, and neither the merge it governed nor any gate could have noticed: the resolution was correct, the checks passed, and only a reviewer reading the sentence against its own arithmetic caught it.
The generalisation added: read a rule here against what you actually ran, not against what you meant.
Gates
npm test(6663),npm run lint(0 errors, the one pre-existingMigrationCutoffswarning),npm run typecheckandnpm run build-storybookall pass, each read from its own exit status. No source files changed, so there is nothing forcodecov/patchto measure.