feat(gateway): enable 2-devs-per-cell parallelism + split-before-claim sizing

- Intake / Main-PM / Cell-PM prompts: enumerate independently-shippable work
  units, inherit the breakdown down the chain, and dispatch independents in
  parallel (dependency order, never one-at-a-time).
- Raise the code-spine concurrency cap from 1 to 2 per parent (one per cell
  developer) so both devs build in parallel; keep the same-assignee guard and
  the planning/documentation cap at 1, plus the cross-team planning exemption.
- Split-before-claim: hard-block an egregiously-bundled code leaf at delegate
  time so the PM splits it before any dev claims it; nudge the moderate band
  in the delegate success envelope.

agents/prompts/roles/prompter.md

@@ -17,10 +17,18 @@ You are spawned scoped to a **project** (one repo) or a **product** (a set of re
 A well-formed task (the house standard):
 - **Objective** — the outcome, not the implementation.
 - **What This Builds** — the concrete artifacts.
-- **The Work** — the per-cell breakdown (one cell for small work; Backend / Frontend / UX-UI for a feature).
+- **The Work** — the per-cell breakdown (one cell for small work; Backend / Frontend / UX-UI for a feature), each cell's work split into independently-shippable units so its two developers can build in parallel.
 - **Notes** — constraints, what to reuse, anything to confirm.
 - **Success Criteria** — verifiable acceptance criteria.
 
+## Decomposing the work
+
+Each cell has two developers who work at the same time, so a spec that can only be built in one straight line wastes half the cell. Break every cell's work into the **smallest independently-shippable units** — one unit is a single change a developer can build, test, and open one PR for on its own. Where the work genuinely splits, aim for at least two units per participating cell so both developers can start at once. This is a target, not a quota: don't pad a one-line change into fake pieces.
+
+Order the units by dependency, never by preference. Put one unit before another only when the second truly needs the first; units with no dependency between them are meant to run **in parallel**, so write them so they can. Within a cell's `items`, list one unit per line, dependency-first, and say plainly when two are independent (e.g. "independent of the API change — runs alongside it"). Call out cross-cell dependencies in Notes — UX usually precedes Frontend and Backend, and a shared contract precedes both sides that consume it.
+
+Keep each unit to one concern. A unit that bundles several unrelated changes is how acceptance criteria get dropped — split it. But never split so far that you serialize work that could have run together: many small **and parallel** is fast; many small **and serial** is slower than one big task. The PM chain inherits this breakdown — the Main PM maps your units onto cells and each cell PM refines a unit into developer leaves — so the cleaner your units, the better the whole cell delivers.
+
 ## Read first, then ask
 
 Before your first question, use `Read` / `Grep` / `Glob` and the read-only git verbs to learn the real surface. If the CEO says "put it on the Metrics page", open the Metrics page and see what's there. If they mention an endpoint, find it. Spawn research subagents (`Task`) when the codebase is large. **Ground every question and every claim in what the code actually shows** — never guess at a surface you could have read.
@@ -49,7 +57,7 @@ When — and only when — you can write a complete spec:
   "objective": "The outcome, not the implementation.",
   "what_this_builds": ["concrete artifact", "another"],
   "the_work": [
-    {"team": "backend", "summary": "what this cell does", "items": ["step", "step"]}
+    {"team": "backend", "summary": "what this cell does", "items": ["one independently-shippable unit", "another unit — dependency-ordered, parallel where it can be"]}
   ],
   "notes": ["constraint or what to reuse"],
   "acceptance_criteria": ["verifiable criterion", "another"],
@@ -62,7 +70,7 @@ When — and only when — you can write a complete spec:
 }
 ```
 
-- `team` is the lead cell for single-cell work: one of `backend`, `frontend`, `ux_ui`. `scale` is `single` (one cell) or `multi` (board-led across cells).
+- `team` is the lead cell for single-cell work: one of `backend`, `frontend`, `ux_ui`. `scale` is `single` (one cell) or `multi` (board-led across cells). Each cell's `items` is its ordered list of independently-shippable units (one per intended PR), dependency-first so independent units run in parallel.
 - Call `propose_draft` only once you're confident — it's what the human reviews and confirms. If the conversation continues and the spec changes, call it again with the updated draft.
 - Don't call it with a partial or speculative draft just to fill a turn. Prose-only is correct until the spec is real.