docs: declare PR delivery shape in every OpenSpec proposal

[thecodedrift]

Every OpenSpec proposal now has to say how it intends to land: a single PR, a stack that merges forward, or a stack that merges down. The point is to decide it while writing the proposal, when the change is still an outline, rather than discovering at review time that the diff is 900 lines and nobody wants to read it.

The distinction between the two stacked shapes is one question, and it is a question about behavior rather than intent: can each unit reach production on its own without breaking anything? If yes, the PRs merge forward to main one at a time. If landing unit 1 alone would leave check broken, tests failing, or a migration half-applied, the answer is no and the stack merges down into its bottom branch to reach main atomically.

We already have a worked example. partition-rules-by-engine's first task group is implemented and leaves 20 tests failing — migration 0004 moves rules out from under readers that later groups update. Nothing is wrong with that work; it simply cannot be a forward stack, and the proposal should have said so before the code existed rather than after.

The guidance is to prefer stacking and aim under ~300 lines per diff, with the caveat that tests count toward the total but never get split from the code they cover — a unit that is oversized because of its tests is usually a unit that should have been smaller.

Also removes "stacks are optional" from the section opening, which contradicted the preference now stated a few lines below it.

Nothing here changes the mechanics of landing a stack; the existing merge-down instructions and the archive-gate interaction are unchanged, and the new section points at both.

[thecodedrift]

@claude /review

[claude]

Claude finished @thecodedrift's task in 3m 1s —— View job

---

Review complete

• Gather context (diff, CLAUDE.md, related sections)
• Understand the request
• Review diff for correctness, clarity, consistency
• Post inline comments if issues found
• Post final summary

Overall assessment

This is a clean, well-scoped documentation change (docs-only, correctly labeled skip-changeset). The new "Every OpenSpec proposal declares its delivery shape" subsection (CLAUDE.md:73-86) reads well and is internally consistent:

• The three-shape table (Single PR / Stacked-forward / Stacked-down) matches the PR body's description exactly.
• The forward-vs-down deciding question ("can each unit reach production on its own without breaking anything?") is phrased in terms of observable behavior, not intent — matches the stated rationale and the partition-rules-by-engine example given in the PR description.
• The cross-reference to "the OpenSpec archive check below" correctly points at the existing Stack-aware OpenSpec archive check bullet under ### Other gotchas (CLAUDE.md:114) further down in the same section — I verified that bullet already exists and says what this new text claims it says.
• Removing "stacks are optional" from the section's opening sentence is justified — I checked the rest of the committed file and confirmed no other passage still asserts that stacking is optional or that direct-to-main is the norm, so there's no leftover contradiction.
• Table markdown is well-formed (3 consistent columns, matching diff structure).

Two non-blocking nits posted inline:

1. CLAUDE.md:73 — the new heading's phrasing ("Every OpenSpec proposal declares…") is a standing-fact statement, while every sibling ### heading in this section names an action ("Landing a stack…", "Never --delete-branch…", "Use merge-commit…"). Consider Declare the delivery shape for voice consistency.
2. CLAUDE.md:69-73 — the subsection is filed under ## Stacked PRs, but one of its three options (Single PR) is explicitly not stacking, and its purpose is really "decide whether to stack" rather than a stacking mechanic. Reads fine given the stacking instructions sit right below it, but worth a thought if this grows further.

No correctness, security, or test-adequacy issues — this is a pure prose/policy change with no executable surface.

[claude]

Nit: every sibling ### heading in this section names an action or scenario the reader is doing (Landing a stack…, Never --delete-branch mid-stack, Use merge-commit, not squash…, Recovery if a child PR gets closed…). This one is phrased as a standing fact about proposals instead (Every OpenSpec proposal declares…). Not wrong, just a slightly different register — something like Declare the delivery shape would match the surrounding headings' voice. Non-blocking.

[claude]

Minor structural point: this new subsection is filed under ## Stacked PRs, but its first table row (Single PR) and its whole purpose (deciding whether to stack) are logically prior to that heading rather than a subtopic of it. Reads fine as-is since the stacking mechanics live right below it, but if this section grows it might read more naturally as its own top-level heading. Not a blocker.