Draft: docs(process): make plan MRs optional, allow stacking, split LOC budgets

I started looking into writing S06 stubs and discovered that if I were to follow our process to the letter, it would take me 4-5 days to merge all changes with significant context-switching involved.

I believe this contradicts Act 2 principles and wanted to propose three concrete changes in this MR that could address the issue and let me ship faster:

1. Make the plan MR optional - Required when the spec does not pin the public surface, or when the work spans multiple impl MRs with parallel authors. Operator/implementer owns the decision. Otherwise the operator and the reviewer proceed directly to implementation. Architectural decisions that need to survive the MR cycle move into the spec; everything else lives in the pairing context.
2. Lift the no-stacking rule - Stacked impl MRs may open before their predecessor merges, with the base branch named in the MR description; the author owns the rebase when an earlier stack member changes. Two specific stacking cases this enables:
   • If the combined size of tests and impl would exceed the LOC budget: tests could land async either before or after implementation - the operator owns the decision.
   • Dev docs in a same-day follow-up MR stacked on the impl MR: the spirit of the existing rule (no dev docs for code that doesn't exist yet) is preserved because the impl MR is approved before the docs MR opens.
3. Count production and test LOC separately against the 400/500 threshold - production carries the bound from Cohen's defect-detection limit. Test LOC carries a softer threshold (for example 800 warn) because test review is structural — "does this case map to a spec row?" — not line-by-line. The harness already excludes generated code; this is the same principle.

Related issue: #77 (closed)

Details

There's a tension between the requirement to write implementation plans and the ask to ship small MRs with quality at a high velocity. This becomes particularly important in the context of our CEO's Act 2 memo

Plans assume we understand the implementation upfront and that the reviewer reviews the whole thing before any MR opens. If significant issues surface during an MR review, in theory we go back and amend the plan. That serializes the work and puts extra load on the reviewer. Trading reviewer attention is exactly the trade Act 2 says we cannot make: quality is non-negotiable, so the process around it has to give.

Concretely: merging the S06 storage stub would take 4-5 days — plan MR plus 3 implementation MRs — assuming no design iteration and a responsive reviewer. Each merge is a calendar wait. The plan itself is mostly restatement of the spec. A four-day calendar for plan-as-restatement is the bureaucracy Act 2 calls out by name — zero tolerance, and the memo is explicit.

Reviewer cognitive load is the scarcest resource we have. The CTO memo on agentic development locks in L3 human review on every production MR — the human reads and approves agent-generated code. That makes review capacity a hard cap on throughput. Small MRs is the load-bearing constraint, not the negotiable one. Everything else has to accommodate it to meet the quality bar from Act 2.

In human-paced authoring, the 200-400 LOC target aligned naturally with the other rules: a day of work = one unit of thought = one mergeable MR. Serial gating between MRs cost roughly nothing because each MR took a day to write anyway — the merge latency hid inside authoring time. In agentic authoring, that alignment breaks. Code is produced in minutes; review takes hours; merge takes a day or two. Serial gating now dominates end-to-end latency — N small MRs cost N × review-cycle of calendar time. The system optimized for per-MR review tractability starves on inter-MR serialization. This contradicts the speed half of Act 2.

There's also an Ownership Mindset angle. Act 2's principle is to push decisions to those closest to the work. The plan model does the opposite: it asks the reviewer to approve architectural decisions ahead of any code, locking them in before the operator has had to make them concrete. The reviewer is the pairing counterpart on the impl MRs anyway — consolidating to a single review against code, in context, is where their judgment is most load-bearing.

For me as a reviewer, abstract decisions in a plan carry real cognitive overhead. I was trained to review code; seeing the code that implements the spec helps me make reviewer choices better than a markdown file that interleaves load-bearing facts with trivial restatement. Programming languages constrain meaning in ways markdown doesn't. And writing "process-checkmark" plans is cheap. A gate that AI can satisfy fluently is no longer a gate — it's ceremony. Act 2's prescription is smaller teams in tighter cycles, not more artifacts.

Plans were instituted to catch architectural drift, surface decisions (package layout, datastore boundaries, exported types), and create a decision record. The reviewer's instinct is that markdown is cheaper to rewrite than code, so catching architecture in a plan beats catching it in an impl MR.

That's true mechanically but skips the deeper question: most of what the plan was catching — package layout, datastore boundaries, exported types — belongs in the spec. The plan was a second-pass review of decisions the spec under-specified. ADR-023 pins top-level package paths; specs pin protos, data models, and acceptance criteria. The residual — internal types, helper signatures, fixture shapes — is trivia that the impl MR reviews in context. Architectural decisions load-bearing enough to want a pre-code review pass need to live where every future reader (operator, reviewer, test-author, agent) finds them: the spec.

An impl rewrite under the plan-then-implement model is signal that the spec needs to be tighter next time, not signal to bring the plan back. This creates a feedback loop on spec quality — harder than letting weak specs hide behind a second gate, but it keeps specs tight and up to date. Moreover - when the spec already pins the public surface, requiring a plan asks for ceremony — the opposite of pushing decisions to those closest to the work.

The split for the residual once plan is removed is then clear: load-bearing decisions that need to survive the MR cycle move into the spec; trivia and details live in the pairing context. This is a corollary of MR !147 (merged): shared architectural context moves into the operator-reviewer counterpart relationship. Same goal — alignment before code lands — different medium.

Plans also decay. They duplicate spec content, and as the impl iterates during review the plan drifts from the merged code. AI agents working on future changes do better with terse, focused context — the spec, not a partially-stale companion file alongside it. The smaller and tighter the context an agent gets, the better the result. Commit messages and the git log already capture decision history; the plan duplicates that with extra ceremony.

For everything between, the cost of a separate plan MR is probably not worth a day or two of calendar latency. If it is, plans remain available — they just shouldn't be the mandatory default.

There's also a practical question: our deadlines do not leave room for a slow process. A 4-5 day calendar for an S06 stub is hard to defend when feature work is queued behind it.

The three changes proposed at the top of this MR address each of these.