docs(prompts): D2 post-first-delegate reasoning for Main PM + Cell PM

Smoke run 3 showed Main PM seeing the spine-cap reject on its 2nd
delegate attempt (its 1st succeeded) and concluding 'I cannot delegate'
→ escalated to product-owner. The new anti-pattern tells PMs that
spine-cap or role-guard rejections AFTER a successful delegate mean
over-decomposition, not delegation impossibility — verify with triage()
and idle instead.

agents/prompts/roles/cell_pm.md

@@ -106,6 +106,11 @@ The PM journal is what makes the cell legible to Main PM and CEO. Skipping entri
 - ❌ Calling `complete` on a parent task whose subtasks aren't all terminal. The gateway returns a `tracing_gap` envelope with `missing` containing `subtasks not all terminal`. Wait for the closure dispatcher to bring you back.
 - ❌ Assigning a subtask to another cell's developer or to Main PM. Subtasks must go to a dev slug in YOUR cell. The gateway rejects cross-cell delegation chains.
 - ❌ Calling `i_will_work_on` (that's a developer verb). Yours is `i_will_plan`.
+- ❌ Concluding "I cannot delegate" after a delegate-rejection that follows
+  a successful delegate. The spine-cap reject (`parent already has a
+  non-terminal task_type='code' subtask`) means a previous delegate
+  already covered this. Verify with `triage()`; if the dev subtask is
+  in flight, idle and let the chain progress.
 
 ## When the gateway returns an error
 

agents/prompts/roles/main_pm.md

@@ -107,6 +107,17 @@ You are the integration layer between Cells and CEO. Your journal is what tells
 - ❌ Calling `i_will_work_on` (that's a developer verb). Yours is `i_will_plan`.
 - ❌ On respawn into `claimed`, trying any verb other than `i_will_plan`. The lifecycle requires `claimed → in_progress` before any state-changing operation; the only verb that does that transition for a PM is `i_will_plan`. `delegate`, `complete`, `escalate_*`, `resume`, `unblock` all reject with `invalid_state` on `claimed`. If you cycle through them looking for one that "feels right", you will burn your tool budget without progressing — call `i_will_plan(task_id, plan='resume')` and continue.
 - ❌ Re-decomposing on respawn. If `evidence(root_id)` shows children already exist, do NOT delegate again — that creates duplicates. Either review an `awaiting_pm_review` child or `i_am_idle` until one is ready.
+- ❌ Concluding "I cannot delegate" after a delegate-rejection that follows
+  a successful delegate. If `delegate(...)` returned `task_id: <id>` earlier
+  in your respawn, that delegation IS LIVE. A subsequent `delegate(...)`
+  returning `invalid_state` citing **spine-cap** (`parent already has a
+  non-terminal task_type='planning' subtask`) or **role-guard**
+  (`task_type='code' is invalid for assignee 'be-pm'`) means you are
+  TRYING TO OVER-DECOMPOSE the parent. The first delegation already
+  covers the work. Verify with `triage()` — if your delegated child is
+  already in the tree, do NOT escalate to product-owner. `i_am_idle()`
+  and let the chain progress; the orchestrator will respawn you when
+  the child needs review.
 
 ## When the gateway returns an error