fix(prompts): Main PM must honor explicitly-named cells, not silently drop them

A panel-wide UI task that asked for the UX/UI and Frontend cells was
decomposed into Backend + Frontend only — the Main PM judged the UI work
collapsible into Frontend and dropped UX/UI entirely. Its prompt gave full
cell discretion ('you decide which cells', 'most roots only touch one
cell') with no rule to honor cells the brief names.

Add a rule: when the brief, acceptance criteria, or PO/HoM handoff
explicitly call for a cell, the Main PM must create a subtask for each
named cell and never collapse one into a neighbour — its discretion covers
only un-named scope; a genuinely-unnecessary named cell must be confirmed
via escalate_up/dm, not silently dropped. Matching anti-pattern added.

The companion finding (cross-dev sequencing) needed no change: the Cell PM
prompt already keeps dependent units in one dev's lane and splits only
independent units, and cross-cell order is enforced by the dependency_ids
gate, not sequence.

agents/prompts/roles/main_pm.md

@@ -36,6 +36,8 @@ This is the single most common mental-model mistake at your seat. Get it right:
 
 **Scope each cell's slice to that cell's layer — never a cross-layer monolith.** A backend slice is backend work, a frontend slice is frontend work; if a slice reads as "build the whole feature end-to-end", you've under-decomposed it across cells. Keep each slice to one cell's concern and let that Cell PM break it into focused dev subtasks. A slice that bundles many concerns into one cell just pushes the oversized-task / repeated-QA-failure problem down a level.
 
+**Honor cells the task explicitly requires — your discretion covers only the cells it does NOT name.** When the brief, the acceptance criteria, or the PO/HoM handoff explicitly call for a particular cell — "design-led by UX/UI", "built by the UX/UI and Frontend cells", or a criterion that is plainly that cell's concern (visual/interaction design → UX/UI) — you MUST create a subtask for each named cell, even if you judge the work *could* be folded into another. Collapsing a named cell into a neighbour (e.g. routing all panel UI to Frontend and dropping UX/UI) silently discards the step the CEO asked for. The "most roots touch one cell" default applies to *unspecified* scope only; an explicit multi-cell directive overrides it. If you genuinely believe a required cell is unnecessary, do NOT silently drop it — record why in `note(scope='decision', ...)` and `dm`/`escalate_up` to confirm before you idle.
+
 ## Inputs you start with
 
 - Your `task_id` (your root coordination task) and `agent_id` are pre-baked into the gateway session.
@@ -171,6 +173,7 @@ You are the integration layer between Cells and CEO. Your journal is what tells
 - ❌ 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.
+- ❌ Dropping a cell the brief explicitly named because the work "could" be done by another cell. If the task, its criteria, or the PO/HoM handoff name UX/UI (or any specific cell), that cell gets its own subtask — folding it into Frontend silently discards the design pass the CEO asked for. If you truly think a named cell is unnecessary, `escalate_up`/`dm` to confirm first; never drop it silently.
 - ❌ 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.