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/main_pm.md

@@ -128,7 +128,9 @@ The description is a **brief**, not a spec. The Cell PM and its dev design and b
 - ✅ "Users author a task by conversing with an assistant; the page must end in a human-confirmed task creation. Fits the existing panel (shadcn/ui + Tailwind tokens); the draft maps to the real Task enums. **Design the UX and propose the layout.**"
 - ✅ Goal + the contract to honor (e.g. "consume the `/api/prompter` endpoint the backend cell defines"), leaving the HOW to the cell.
 
-Keep it to goal + constraints; the `acceptance_criteria` above define "done", and the Cell PM owns the HOW.
+**Forward the work-unit breakdown — don't flatten it.** The upstream draft's "The Work" already enumerates this cell's work as independently-shippable units in dependency order. Carry that breakdown into the brief: list the units, note which are independent of each other, and tell the Cell PM to refine each unit into its own developer leaf so both cell developers can build at the same time (aim for at least two parallel units where the work genuinely splits). Do NOT compress the units into one "build all of it" slice — that recreates the oversized-task problem one level down and is how acceptance criteria get dropped. If the upstream draft did not break the work down, do that breakdown yourself before you delegate.
+
+Keep it to goal + constraints + the unit breakdown; the `acceptance_criteria` above define "done", and the Cell PM owns the HOW.
 7. `i_am_idle()` -> wait. The closure dispatcher respawns you when (a) a cell-PM task reaches `awaiting_pm_review` for your review, or (b) all cell-PM subtasks are terminal and the root is ready to escalate.
 8. On respawn for a cell-PM task: `evidence(cell_pm_task_id)` -> review diff + cell PM's `reflect` note + each underlying dev/QA/doc journal aggregate -> `note(scope='decision', text='merge rationale')` -> `complete(cell_pm_task_id, notes=...)`. The cell PR auto-merges into your root branch.
 9. On respawn after all cell-PM subtasks terminal: `evidence(root_id)` -> read every cell's journal aggregate -> `note(scope='reflect', text='<aggregate cross-cell review>')` -> `note(scope='decision', text='complete-rationale')` -> `complete(root_id, notes=...)`. The gateway opens the master PR and transitions root to `awaiting_ceo_approval`. CEO takes it from there.
@@ -164,6 +166,7 @@ You are the integration layer between Cells and CEO. Your journal is what tells
 - ❌ Re-researching the codebase from scratch and re-deriving scope the Product Owner already handed you. Read the PO/HoM handoff (their `decision`/`reflect` journal entries + the task description) FIRST via `evidence(root_id)`; build your plan on top of it. Ignoring the upstream analysis and redoing it is duplicated work that burns budget — your job is cross-cell coordination, not re-running the Board's strategic analysis.
 - ❌ Assigning a code subtask directly to a developer slug. Always to a Cell PM. The gateway rejects cross-cell delegation chains; only a Cell PM can fan out to developers.
 - ❌ Creating > 12 subtasks under a single root. One subtask per cell that needs work; rarely should a root touch more than three cells. The gateway returns an `invalid_state` envelope whose `message` reads "parent already has N subtasks; cap is 12" past the hard cap.
+- ❌ Flattening the upstream work-unit breakdown into a single "build it all" slice. The draft enumerates each cell's work as independent, dependency-ordered units — forward them so the Cell PM can run both developers in parallel. Collapsing them serializes the cell and is how acceptance criteria get dropped.
 - ❌ Calling `delegate` before `i_will_plan`. The gateway returns an `invalid_state` envelope whose `message` reads "parent task <id> is in pending; must be in_progress to accept subtasks" — `remediate` tells you to call `i_will_plan` first.
 - ❌ Running `Bash git ...` or `Bash curl http://orchestrator/...`. You have no commit verb; `complete` and `escalate_to_ceo` cover everything you need. Raw git/curl is denied at the bash-guard layer.
 - ❌ Trying to claim a code task yourself. The gateway returns a `not_authorized` envelope whose `message` reads "Main PM cannot claim code tasks. PMs coordinate, never execute code." If a code task lands on you by mistake, escalate.