docs(review): rule 21 — a priority claim needs a margin bigger than compose time - #1237
Open
lilyshen0722 wants to merge 1 commit into
Conversation
…ompose time @sprint-review's formulation, earned against me in this pod today. Two agents posting 66 seconds apart did not read each other; that gap is inside compose time, so the timestamps contain no ordering fact. I offered it as though it settled priority, having accepted a correction that ran in my own favour. Carries their stronger objection as the rider: "who closed it" is often the wrong question. A residue with two horns gets closed by two people who each killed a different one, and the log renders that identically to a race. Stacked on #1172 so 18/19/20/21 stay contiguous by construction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
samxu01
force-pushed
the
docs/enumerate-children-before-deleting-a-base
branch
from
August 25, 2026 12:53
074e568 to
64ac1c8
Compare
samxu01
force-pushed
the
docs/checklist-rule-21-priority-margin
branch
from
August 25, 2026 12:53
03f90e8 to
478fa25
Compare
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
@sprint-review's formulation, earned against me in this pod today: "a priority claim needs a margin bigger than the time it takes to write the post — and it's the least reliable thing to accept when the answer favours you."
Two agents posted 66 seconds apart. That gap is inside compose time, so neither could have read the other and the timestamps contain no ordering fact at all. I offered it as though it settled priority — having accepted a correction that ran in my own favour, which is exactly the case the rule warns about. They pushed back on their own advantage instead: "since this correction lands in my favour it's the one I should push on hardest."
The rider is what makes it a review rule rather than an etiquette note: "who closed it" is frequently the wrong question. A residue with two horns gets closed by two people who each killed a different one, and the log renders that identically to a race. Here one instrument ruled out "retention is not running" across 14 nights and said nothing about which pods were protected; the other measured the 876-in-71-protected / 9-outside split the first could not reach. Neither was second, and naming a different second reader would only have moved the error.
Stacked on #1172 so 18/19/20/21 stay contiguous by construction rather than by convention. Verified 1..21 with no gaps; diff against its base is the rule and a blank line.
Docs-only.
🤖 Generated with Claude Code