docs: raise the per-PR diff target to ~1200 hand-written lines - #192
Merged
Conversation
The ~300-line target did not fit the normal shape of a change here: an OpenSpec proposal, design, spec deltas and tasks, plus the implementation and its tests. Since the guidance elsewhere forbids splitting tests from the code they cover, a number that only fits the code half pushed people to cut along a seam the rest of the file tells them not to. Generated files no longer count. PR #182 was 515 lines of which 346 was pnpm-lock.yaml and a regenerated schema, none of which a reviewer reads. Fixes #191
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
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.
Raises the per-PR diff target in
CLAUDE.mdfrom ~300 lines to ~1200, and excludes generated files from the count.Why 300 did not hold
The rule spent its own budget. It counted tests toward the total while forbidding you to split them from the code they cover, and changes here are majority test code. #190 was roughly two thirds tests; #182 was 181 of 308 hand-written insertions.
Generated files inflated the count with nothing to review. #182 measured 515 lines, of which 346 was
pnpm-lock.yamland a regenerated schema. Against 300 that reads as a 1.7x overrun; against what a human actually reviews it is comfortably inside. The old rule did not say to discount them, so every judgement call began with an argument about what counts.Prose changes have no natural 300-line seam. Agent recipes,
CLAUDE.md, and OpenSpec artifacts routinely move several hundred lines in one coherent edit.Why 1200 rather than 1000
The threshold has to be comfortable for a change carrying task changes, code, and tests together, which is the normal shape here. OpenSpec work adds proposal, design, spec deltas and tasks on top of the implementation, and the guidance elsewhere forbids splitting tests from their code. A number that only fits the code half pushes people to split along the exact seam the rest of the rules tell them not to cut.
Measured against recent work, 1200 sits above the coherent units and below the point where a diff stops being readable in one sitting:
#190 is the useful case: it really was four independently-safe units and could have been a stack, so a signal there is right. At 300 it was a 4.6x overrun, which is no signal at all.
One correction to the original rationale
The failure that motivated 300 was depth, not size. #103 reached "ready for review" as a ~93-file change never linted, typechecked, or tested, because a
branches:filter silently stopped matching seven hops frommain. That is a CI-coverage bug, separately fixed, and a 300-line target would not have caught it.Note on the wording
The old sentence "a 900-line PR does not get reviewed, it gets approved" is kept in substance but re-anchored. At a 1200-line ceiling, 900 sits under the target, so naming it as the cautionary example would contradict the rule in the same breath. It now reads "a PR far past that".
Not changed
The preference for stacking, the merge-down rules, and changeset placement all stand. Only the size target and the generated-file exclusion move.
No changeset
CLAUDE.mdis repo-root contributor guidance. It is not inpackages/cliand ships in no artifact, so there is no user-facing behavior to describe.changeset.ymlwarns rather than fails.Fixes #191