gru-ai 0.2.0 → 0.3.0

package/.claude/skills/directive/SKILL.md

@@ -35,7 +35,7 @@ DO NOT read source code. DO NOT edit files. DO NOT start solving the problem. Th
 
 Your FIRST action must be: Read the triage doc, classify the directive weight, output the triage block, and create directive.json. Only then proceed to the next pipeline step.
 
-If you catch yourself wanting to "just fix it quickly" — STOP. That impulse is exactly what the pipeline prevents. Even lightweight directives have a defined process (triage → context → plan → audit → build → review → digest → completion). The COO plans for ALL weights.
+If you catch yourself wanting to "just fix it quickly" — STOP. That impulse is exactly what the pipeline prevents. Even lightweight directives have a defined process (triage → context → audit → plan → build → review → digest → completion). The COO plans for ALL weights.
 
 ---
 
@@ -54,12 +54,24 @@ This file is a routing table. Each row points to a modular doc containing full i
 3. Set `updated_at` to the current ISO timestamp
 4. Use the Write tool to overwrite the full directive.json
 
-**When starting a step**, set `pipeline.{stepId}.status` to `"active"`.
+**When starting a step**, set `pipeline.{stepId}.status` to `"active"` and `pipeline.{stepId}.agent` to the array of participating agent first names (lowercase, e.g. `["sarah", "marcus", "morgan"]`). This is critical for the dashboard game view — the game reads step agents to route characters to the meeting room during brainstorm/plan/clarification steps. Without this, characters won't move.
 
 > **Why output is mandatory:** The dashboard renders pipeline step details directly from directive.json. Without `output.summary`, the UI shows empty steps — the CEO can't see what happened. Every step must leave a trace.
 
 The server's directive-watcher reads `directive.json` directly (NOT `current.json`) and pushes pipeline state to the dashboard via WebSocket. Keeping `pipeline` updated is what makes the stepper UI show real-time progress.
 
+### Step Execution Loop
+
+After completing a step and updating directive.json, **immediately** read the next step's doc from the routing table below and execute it. Do NOT stop, do NOT pause, do NOT ask for confirmation between steps. The pipeline is designed to run end-to-end in a single pass.
+
+**STOP gates — the only points where you must stop and wait for the CEO:**
+
+1. **`clarification`** — heavyweight/strategic: STOP and present synthesized intent for CEO verification. Lightweight/medium: **still run the step** (synthesize intent) but auto-approve without stopping. Do NOT skip this step — the verified_intent output feeds the COO planner.
+2. **`approve`** — heavyweight/strategic: STOP and present plan for CEO approval. Lightweight/medium: auto-approve without stopping.
+3. **`completion`** — all weights. The CEO must approve, amend, extend, or redirect the directive.
+
+At every other step, transition directly to the next step without delay. If a step is skipped for the current weight class (brainstorm for lightweight/medium), set its status to "skipped" in directive.json and advance to the next step.
+
 ### Pipeline Steps
 
 | # | Step ID | Doc | Purpose | Depends On |
@@ -68,16 +80,17 @@ The server's directive-watcher reads `directive.json` directly (NOT `current.jso
 | 2 | checkpoint | [01-checkpoint.md](docs/pipeline/01-checkpoint.md) | Check for existing checkpoint, resume if found | — |
 | 3 | read | [02-read-directive.md](docs/pipeline/02-read-directive.md) | Read directive file + create directive.json | triage |
 | 4 | context | [03-read-context.md](docs/pipeline/03-read-context.md) | Read all context files before planning | read |
-| 5 | challenge | [04-challenge.md](docs/pipeline/04-challenge.md) | C-suite challenge (heavyweight only) | context |
-| 6 | plan | [05-planning.md](docs/pipeline/05-planning.md) | COO strategic planning | context |
-| 7 | audit | [06-technical-audit.md](docs/pipeline/06-technical-audit.md) | Technical codebase audit | plan |
-| 8 | approve | [07-plan-approval.md](docs/pipeline/07-plan-approval.md) | Present plan to CEO for approval | audit |
-| 9 | project-brainstorm | [07b-project-brainstorm.md](docs/pipeline/07b-project-brainstorm.md) | CTO + builder decompose projects into tasks with DOD | approve |
-| 10 | setup | [08-worktree-and-state.md](docs/pipeline/08-worktree-and-state.md) | Worktree isolation + directive state init | project-brainstorm |
-| 11 | execute | [09-execute-projects.md](docs/pipeline/09-execute-projects.md) | Execute all tasks (phases, agents, UX) | setup |
-| 12 | review-gate | [09-execute-projects.md](docs/pipeline/09-execute-projects.md) | Review verification gate (end of doc) | execute |
-| 13 | wrapup | [10-wrapup.md](docs/pipeline/10-wrapup.md) | OKRs, follow-ups, stale doc detection, digest, lessons, report | review-gate |
-| 14 | completion | [11-completion-gate.md](docs/pipeline/11-completion-gate.md) | CEO completion gate -- approve or reopen | wrapup |
+| 5 | audit | [06-technical-audit.md](docs/pipeline/06-technical-audit.md) | Technical codebase audit | context |
+| 6 | brainstorm | [04-brainstorm.md](docs/pipeline/04-brainstorm.md) | Approach brainstorm (includes challenge for heavyweight/strategic) | audit |
+| 7 | clarification | [04b-clarification.md](docs/pipeline/04b-clarification.md) | Synthesize verified intent (auto-approve for lightweight/medium) | audit |
+| 8 | plan | [05-planning.md](docs/pipeline/05-planning.md) | COO strategic planning | clarification |
+| 9 | approve | [07-plan-approval.md](docs/pipeline/07-plan-approval.md) | Present plan to CEO for approval | plan |
+| 10 | project-brainstorm | [07b-project-brainstorm.md](docs/pipeline/07b-project-brainstorm.md) | CTO + builder decompose projects into tasks with DOD | approve |
+| 11 | setup | [08-worktree-and-state.md](docs/pipeline/08-worktree-and-state.md) | Worktree isolation + directive state init | project-brainstorm |
+| 12 | execute | [09-execute-projects.md](docs/pipeline/09-execute-projects.md) | Execute all tasks (phases, agents, UX) | setup |
+| 13 | review-gate | [09-execute-projects.md](docs/pipeline/09-execute-projects.md) | Review verification gate (end of doc) | execute |
+| 14 | wrapup | [10-wrapup.md](docs/pipeline/10-wrapup.md) | OKRs, follow-ups, stale doc detection, digest, lessons, report | review-gate |
+| 15 | completion | [11-completion-gate.md](docs/pipeline/11-completion-gate.md) | CEO completion gate -- approve, amend, extend, or redirect | wrapup |
 
 ### Reference Docs — Schemas
 
@@ -86,10 +99,9 @@ The server's directive-watcher reads `directive.json` directly (NOT `current.jso
 | [plan-schema.md](docs/reference/schemas/plan-schema.md) | COO plan output JSON schema |
 | [audit-output.md](docs/reference/schemas/audit-output.md) | Architect output JSON schema (design recommendations — second phase of two-agent audit) |
 | [investigation-output.md](docs/reference/schemas/investigation-output.md) | QA Engineer's investigation output JSON schema (pure data — first phase of two-agent audit) |
-| [checkpoint.md](docs/reference/schemas/checkpoint.md) | Checkpoint JSON schema (includes dod_verification field) |
+| [checkpoint.md](docs/reference/schemas/checkpoint.md) | Checkpoint JSON schema (deprecated — merged into directive-json.md) |
 | [directive-json.md](docs/reference/schemas/directive-json.md) | Directive JSON schema (THE source of truth — includes pipeline progress for dashboard) |
-| [challenger-output.md](docs/reference/schemas/challenger-output.md) | Challenger output JSON schema |
-| [brainstorm-output.md](docs/reference/schemas/brainstorm-output.md) | Brainstorm output JSON schema (proposals + rebuttals) |
+| [brainstorm-output.md](docs/reference/schemas/brainstorm-output.md) | Brainstorm output JSON schema (proposals + rebuttals + challenge) |
 
 ### Reference Docs — Templates
 
@@ -99,8 +111,7 @@ The server's directive-watcher reads `directive.json` directly (NOT `current.jso
 | [investigator-prompt.md](docs/reference/templates/investigator-prompt.md) | Investigation prompt template for the QA Engineer (pure data gathering — first phase of audit) |
 | [architect-prompt.md](docs/reference/templates/architect-prompt.md) | Architect prompt template (design recommendations — second phase of audit) |
 | [auditor-prompt.md](docs/reference/templates/auditor-prompt.md) | Combined audit prompt for the CTO (single-agent path for simple tasks) |
-| [challenger-prompt.md](docs/reference/templates/challenger-prompt.md) | Challenger prompt template |
-| [brainstorm-prompt.md](docs/reference/templates/brainstorm-prompt.md) | Brainstorm agent prompt template (Phase 1 proposals + Phase 2 deliberation) |
+| [brainstorm-prompt.md](docs/reference/templates/brainstorm-prompt.md) | Brainstorm agent prompt template (Phase 1 proposals + challenge + Phase 2 deliberation) |
 | [digest.md](docs/reference/templates/digest.md) | Digest report template |
 
 ### Reference Docs — Rules
@@ -116,6 +127,8 @@ The server's directive-watcher reads `directive.json` directly (NOT `current.jso
 
 | Script | Content |
 |--------|---------|
-| [validate-cast.sh](../../hooks/validate-cast.sh) | Mechanical casting validation — checks auditor present, builder != reviewer, complex has C-suite reviewer |
+| [validate-cast.sh](../../hooks/validate-cast.sh) | Mechanical casting validation — checks reviewer present, builder != reviewer, complex/moderate has C-suite reviewer, no self-review of own prompts, depends_on valid, no circular deps |
 | [validate-project-json.sh](../../hooks/validate-project-json.sh) | Pre-execution gate — blocks execute step if project.json missing or incomplete (no tasks, no DOD, no scope) |
 | [detect-stale-docs.sh](../../hooks/detect-stale-docs.sh) | Post-directive — scans docs for references to modified files, flags potentially stale docs |
+| [validate-gate.sh](../../hooks/validate-gate.sh) | Pipeline step gate — validates prerequisites before advancing to next step |
+| [validate-reviews.sh](../../hooks/validate-reviews.sh) | Review-gate hard gate — blocks completion if reviews missing, detects self-review and self-certification |

package/.claude/skills/directive/docs/pipeline/00-delegation-and-triage.md

@@ -8,15 +8,17 @@ Before doing anything else, kill orphaned CLI agents from prior runs. These accu
 
 ```bash
 # Kill orphaned CLI agent processes from prior runs
-ps aux | grep "claude.*--agent.*-p" | grep -v grep | awk '{print $2}' | xargs kill 2>/dev/null
-# Also kill any orphaned -p (print mode) processes without --agent
-ps aux | grep "claude -p" | grep -v grep | awk '{print $2}' | xargs kill 2>/dev/null
-# Kill orphaned spawn-agent.ts processes
+# ONLY target --agent processes (spawned workers), NOT plain "claude -p" processes.
+# Reason: this directive session itself runs inside a "claude -p" process.
+# Killing all "claude -p" matches would kill our own parent process (the session
+# running this pipeline). Orphans are always --agent child processes, never the
+# parent session.
+ps aux | grep "claude.*--agent" | grep -v grep | awk '{print $2}' | xargs kill 2>/dev/null
 ps aux | grep "spawn-agent" | grep -v grep | awk '{print $2}' | xargs kill 2>/dev/null
 echo "Pre-flight cleanup: killed orphaned agent processes"
 ```
 
-This is safe — active CLI agents for the current directive haven't been spawned yet, so there's nothing to accidentally kill.
+This is safe — active CLI agents for the current directive haven't been spawned yet, and we only target `--agent` child processes (not the parent `claude -p` session).
 
 ### Classify the Directive
 
@@ -90,7 +92,7 @@ No C-suite challenges. No brainstorm. No plan-approval gate. No worktree (unless
 ### Medium Process
 
 1. Read full context (read + context steps)
-2. Spawn the COO to plan projects (plan) -- the COO's inline challenge is always included, but skip separate C-suite challengers (challenge step)
+2. Spawn the COO to plan projects (plan) -- the COO's inline challenge is always included, but skip the brainstorm step (no separate brainstorm agents)
 3. Spawn auditor for technical baseline (audit)
 4. **No plan-approval gate** -- auto-approve the plan based on directive scope and guardrails
 5. Create branch (setup) — worktree only if working directory is dirty
@@ -153,7 +155,7 @@ Same as heavyweight but with an additional deliberation round during brainstorm.
 
 ### Heavyweight Process
 
-Full pipeline: triage → read → context → challenge → **Brainstorm** → plan → audit → approve → project-brainstorm → setup → execute → review-gate → wrapup → completion.
+Full pipeline: triage → checkpoint → read → context → audit → **brainstorm** → clarification → plan → approve → project-brainstorm → setup → execute → review-gate → wrapup → completion.
 
 **Brainstorm phase (mandatory for heavyweight):** Before the COO plans, spawn the brainstorm team in parallel using `run_in_background: true`. The brainstorm team includes:
 - **2-3 relevant C-suite agents** (the CTO for architecture, the CPO for product, the CMO for growth — pick based on directive domain)
@@ -181,3 +183,7 @@ Agent tool call (per brainstorm agent):
 > See [docs/reference/schemas/brainstorm-output.md](../reference/schemas/brainstorm-output.md) for the brainstorm agent output JSON schema.
 
 For the CEO approval gate (approve step): write the plan to `.context/directives/{directive-id}/plan-for-approval.md` and STOP. Output a summary asking the CEO to approve. Include brainstorm synthesis and any clarifying questions alongside the COO's plan. After CEO approval, continue execution from the setup step.
+
+### Test Mode
+
+Directives with `test_mode: true` in directive.json are automated smoke tests created by the `/smoke-test` skill. The pipeline runs normally but the completion gate auto-approves instead of waiting for CEO sign-off. Do NOT set `test_mode` on real directives.

package/.claude/skills/directive/docs/pipeline/01-checkpoint.md

@@ -2,7 +2,7 @@
 
 ## Step 0: Check for Existing Progress
 
-Check if `.context/directives/$ARGUMENTS.json` exists AND has a `current_step` field (indicating previous execution progress).
+Check if `.context/directives/$ARGUMENTS/directive.json` exists AND has a `current_step` field (indicating previous execution progress).
 
 **If not found or no `current_step`:** Proceed to the read step normally.
 

package/.claude/skills/directive/docs/pipeline/02-read-directive.md

@@ -26,7 +26,30 @@ Create `.context/directives/$ARGUMENTS/directive.json` if it doesn't already exi
   "weight": "{classification from triage: lightweight | medium | heavyweight | strategic}",
   "produced_features": [],
   "report": null,
-  "backlog_sources": []
+  "backlog_sources": [],
+  "dod": {
+    "success_looks_like": [],
+    "failure_looks_like": [],
+    "quality_bar": "",
+    "examples": []
+  }
 }
 ```
 
+### Extract directive-level DOD from the CEO brief
+
+After creating directive.json, scan the CEO brief (directive.md) and extract a best-effort definition of done into `directive.json.dod`. This is the CEO's intent translated into structured acceptance criteria.
+
+**How to extract each field:**
+
+1. **success_looks_like** -- Look for phrases describing desired outcomes, goals, or "I want X to happen." Convert each into a concrete, verifiable statement. One array entry per distinct outcome.
+2. **failure_looks_like** -- Look for complaints about the current state, phrases like "the problem is...", "this doesn't work because...", or "stop doing X." Invert these into failure conditions. If the brief says "agents ignore the brainstorm output", the failure condition is "Builder output diverges from brainstorm without documented rationale."
+3. **quality_bar** -- Synthesize the brief's overall standard into one sentence. If the brief mentions specific metrics, thresholds, or comparisons ("better than X", "zero regressions", "passes on first review"), use those. If no explicit bar exists, leave empty -- the clarification step will ask.
+4. **examples** -- Extract any before/after scenarios, reference implementations, or concrete illustrations the CEO provides. Format as "Before: ... / After: ..." strings. If the brief has none, leave the array empty.
+
+**Important:** This extraction is best-effort. The clarification step will present the extracted DOD back to the CEO for verification. Do not block on incomplete extraction -- empty fields are acceptable at this stage.
+
+### Update directive.json
+
+Set `current_step: "context"` (the next step). Update `pipeline.read.status` to `"completed"` with output summary including the directive title, weight, and DOD extraction status.
+

package/.claude/skills/directive/docs/pipeline/03-read-context.md

@@ -9,5 +9,10 @@ Read ALL of these before spawning the COO:
 - `.context/lessons/*.md` — project gotchas and patterns (read topic files as needed per agent role)
 - `.context/lessons/orchestration.md` — for the COO and orchestration
 - `.context/lessons/agent-behavior.md` — for all agents
+- `.context/design/*.md` — system design rationale (why the system works the way it does). Read all design docs — they are short and high-signal. Pass relevant ones to agents based on task domain.
 - All `.context/directives/*/projects/*/project.json` — current project states and task status
 - The C-suite agent personality files (resolve names from `.claude/agent-registry.json`)
+
+### Update directive.json
+
+Set `current_step: "audit"` (the next step). Update `pipeline.context.status` to `"completed"` with output summary listing what was read.

package/.claude/skills/directive/docs/pipeline/04-brainstorm.md

@@ -0,0 +1,77 @@
+<!-- Pipeline doc: 04-brainstorm.md | Step: brainstorm -->
+
+## Brainstorm: Approach Exploration (Heavyweight/Strategic Only)
+
+**Lightweight and medium directives skip this step entirely.** Advance to the next step.
+
+For heavyweight and strategic directives, this step spawns brainstorm agents to explore approaches before the COO plans. The audit has already run -- audit findings feed into every proposal so approaches are grounded in codebase reality.
+
+### Participants
+
+Spawn 2-3 C-suite agents + the auditor (CTO or architect) from the agent registry. Select participants based on the directive's domain:
+
+- **Technical / architecture / debt** -- CTO + relevant builder
+- **User-facing / product** -- CPO + CTO
+- **Growth / SEO / marketing** -- CMO + CPO
+- **Cross-domain** -- CTO + CPO + the most relevant third (CMO or a domain specialist)
+
+The auditor who ran the technical audit step always participates -- they ground proposals in codebase reality.
+
+### Step Entry — Update directive.json immediately
+
+Before spawning any agents, write `pipeline.brainstorm` to directive.json with `"status": "active"` and `"agent"` set to the array of selected participant first names (lowercase). The agent list must match whoever you chose from the Participants section above — it is NOT a fixed set. This update triggers the dashboard game to route those characters to the meeting room.
+
+### Process
+
+**Phase 1 -- Proposals (+ Challenge)**
+
+Spawn each participant in parallel using `run_in_background: true` with the brainstorm prompt template.
+
+> See [brainstorm-prompt.md](../reference/templates/brainstorm-prompt.md) for the full prompt template. The template includes a `{challenge_instruction}` block that fires for heavyweight/strategic -- each agent critically evaluates the directive before proposing their approach.
+
+> See [brainstorm-output.md](../reference/schemas/brainstorm-output.md) for the output JSON schema.
+
+Each agent produces:
+- A concrete approach proposal (3-5 sentences)
+- Tradeoffs and what to avoid
+- A **challenge assessment** (heavyweight/strategic only) -- risks, scope concerns, alternatives
+- Feasibility flags grounded in audit findings (auditor agent)
+
+**Phase 2 -- Deliberation (Strategic ONLY)**
+
+For strategic directives only: after collecting all Phase 1 proposals, share them with each agent for one rebuttal round. Each agent sees all proposals and writes one targeted critique. See the brainstorm-prompt.md Phase 2 section for the rebuttal prompt.
+
+Heavyweight directives skip Phase 2 -- proposals and challenge assessments are sufficient.
+
+**Synthesis**
+
+After collecting all outputs, synthesize into a brainstorm artifact:
+- Identify convergence points across proposals
+- Surface key disagreements and unresolved concerns from challenge assessments
+- For strategic: note which critiques landed and which proposals survived challenge
+- Extract 1-3 CEO clarification questions from unresolved concerns (used in the clarification step)
+
+Write the synthesis to `.context/directives/{id}/brainstorm.md`.
+
+### Spawn Pattern
+
+```
+Agent tool call (per participant):
+  subagent_type: "{agent_id from registry}"
+  model: "sonnet"
+  run_in_background: true
+  prompt: |
+    {brainstorm prompt from brainstorm-prompt.md, with challenge_instruction included}
+```
+
+Collect results using TaskOutput for each agent ID. Wait for all to return.
+
+### Error Handling
+
+If a background agent fails or times out, log the error and continue. Brainstorm is advisory -- a failed participant does not block the pipeline. If ALL agents fail, note "brainstorm phase unavailable" and proceed.
+
+### Update directive.json
+
+Set `current_step: "clarification"` (the next step). Update `pipeline.brainstorm.status` to `"completed"` with `agent` (the participant first names array, same as the step entry), output summary including the brainstorm synthesis and any challenge assessments, and `artifacts: [".context/directives/{id}/brainstorm.md"]` if a brainstorm artifact was written.
+
+**Next step:** Proceed to [04b-clarification.md](04b-clarification.md) (clarification) to verify directive intent with the CEO before the COO plans.

package/.claude/skills/directive/docs/pipeline/04b-clarification.md

@@ -0,0 +1,222 @@
+<!-- Pipeline doc: 04b-clarification.md | Source: enrich-agent-behaviors directive -->
+
+## Clarification: Verify Directive Intent with CEO
+
+After the brainstorm completes, the pipeline has three sources of intent:
+the CEO brief (directive.md), audit findings, and brainstorm proposals.
+These sources often conflict or leave gaps. This step synthesizes them
+into a structured intent block and verifies it with the CEO before the
+COO plans against it.
+
+**Why this exists:** The COO plans against whatever intent it receives.
+If intent is ambiguous, the COO guesses -- and the entire downstream
+pipeline (tasks, DOD, builds, reviews) inherits that guess. Catching
+misalignment here costs one CEO interaction. Catching it after execution
+costs a full reopen cycle.
+
+---
+
+### Step Entry — Update directive.json immediately
+
+Before reading inputs, write `pipeline.clarification` to directive.json with `"status": "active"` and `"agent"` set to the participants. For heavyweight/strategic, include the brainstorm participants who contributed to the synthesis alongside the CEO. For lightweight/medium, set to `["pipeline"]` (auto-approved). This triggers the dashboard game to route characters to the meeting room.
+
+### Inputs
+
+| Source | File | What to extract |
+|--------|------|-----------------|
+| CEO brief | `.context/directives/{id}/directive.md` | Original goals, constraints, quality expectations |
+| Directive DOD | `.context/directives/{id}/directive.json` → `dod` | Best-effort DOD extracted in the read step |
+| Audit findings | `.context/directives/{id}/audit.md` | Technical constraints, complexity flags, dead code |
+| Brainstorm output | `.context/directives/{id}/brainstorm.md` | Approach proposals, trade-offs, feasibility flags |
+
+Read all four sources. If any file is missing (e.g., audit skipped for
+lightweight), proceed with what is available.
+
+---
+
+### Step 1: Synthesize Intent
+
+Extract a `verified_intent` object from the combined sources:
+
+```json
+{
+  "goal": "One sentence: what the directive achieves when done",
+  "constraints": [
+    "Technical or process constraint derived from brief + audit",
+    "e.g., 'Must not break existing session scanner detection'",
+    "e.g., 'Budget: no new dependencies'"
+  ],
+  "quality_bar": "The minimum acceptable standard in one sentence -- derived from brief + audit baseline",
+  "acceptance_scenarios": [
+    {
+      "scenario": "Short label for the scenario",
+      "given": "Starting state or precondition",
+      "when": "Action or trigger",
+      "then": "Observable outcome that proves success"
+    }
+  ],
+  "out_of_scope": [
+    "Explicitly excluded work -- derived from brief + brainstorm 'avoid' fields",
+    "e.g., 'Schema changes in work-item-types.ts (handled by separate directive)'"
+  ]
+}
+```
+
+**Extraction rules:**
+
+1. **goal** -- Synthesize from the CEO brief's first paragraph + brainstorm
+   convergence points. One sentence, active voice, concrete outcome.
+2. **constraints** -- Merge technical constraints from the audit (active file
+   counts, dependency limits, pattern requirements) with process constraints
+   from the brief ("no regressions", "backward compatible"). One entry per
+   constraint.
+3. **quality_bar** -- Use `directive.json.dod.quality_bar` if populated. If
+   empty, derive from the brief's language about acceptable outcomes. If the
+   brief gives no quality signal, set to `""` and flag for CEO input.
+4. **acceptance_scenarios** -- Convert `directive.json.dod.success_looks_like`
+   entries into given/when/then format. Add scenarios from the brainstorm's
+   feasibility flags (negative cases the audit surfaced). Aim for 2-5
+   scenarios.
+5. **out_of_scope** -- Collect from brainstorm `avoid` fields, audit dead code
+   flags, and any explicit exclusions in the brief. One entry per exclusion.
+
+---
+
+### Step 2: CEO Verification (weight-dependent)
+
+#### Test Mode Auto-Approve
+
+If `directive.json` has `test_mode: true`, skip the weight-dependent CEO verification
+and auto-approve immediately:
+
+1. Step 1 (Synthesize Intent) MUST have already run fully -- this is the whole point
+   of Option B gate simulation
+2. Auto-approve the synthesized `verified_intent` as-is, regardless of directive weight
+3. Log: `[TEST_MODE] Auto-approved clarification for {directive-name}`
+4. Continue directly to Step 3 (Store Verified Intent) -- set `"agent": "pipeline"`,
+   `"auto_approved": true`, `"modifications": []`
+
+This is used by the `/smoke-test` skill for pipeline E2E testing. **NEVER** set
+`test_mode: true` on a real directive -- it bypasses the CEO's intent verification.
+
+If `test_mode` is not set, proceed to the weight-dependent logic below.
+
+#### Heavyweight / Strategic: STOP gate -- CEO must verify
+
+Present each field of the `verified_intent` to the CEO for piece-by-piece
+confirmation. Use this format:
+
+```
+## Intent Verification
+
+I've synthesized the directive intent from your brief, the technical
+audit, and the team brainstorm. Please verify each item.
+
+### Goal
+> {goal}
+Confirm / Modify?
+
+### Constraints
+1. {constraint_1} -- Confirm / Modify / Remove?
+2. {constraint_2} -- Confirm / Modify / Remove?
+   ...
+
+### Quality Bar
+> {quality_bar}
+Confirm / Modify?
+
+### Acceptance Scenarios
+1. **{scenario}**: Given {given}, when {when}, then {then}
+   Confirm / Modify / Remove?
+2. ...
+
+### Out of Scope
+1. {item_1} -- Confirm / Modify / Remove?
+2. ...
+
+### Anything Missing?
+Are there constraints, scenarios, or exclusions not captured above?
+```
+
+Wait for the CEO to respond. Process each response:
+
+- **Confirm** -- keep the item as-is
+- **Modify** -- replace with the CEO's revised text
+- **Remove** -- delete from the intent block
+- **Add** -- append new items the CEO provides
+
+If the CEO modifies the goal or quality bar, re-check whether existing
+acceptance scenarios still align. Flag any that no longer match.
+
+If the quality_bar was empty and the CEO does not provide one, set a
+default: `"All DOD criteria met; code review passes on first cycle"` and
+note it in the output summary.
+
+#### Lightweight / Medium: Auto-approve with log
+
+Do NOT present to the CEO. Instead:
+
+1. Synthesize the `verified_intent` as described in Step 1
+2. Log: `[CLARIFICATION] Auto-approved intent for {weight} directive`
+3. Log the synthesized goal and constraint count for traceability
+4. Continue to the next step immediately
+
+---
+
+### Step 3: Store Verified Intent
+
+Write the verified intent into directive.json at
+`pipeline.clarification.output.verified_intent`:
+
+```json
+{
+  "pipeline": {
+    "clarification": {
+      "status": "completed",
+      "agent": "CEO",
+      "output": {
+        "summary": "CEO verified intent: {1-sentence summary of changes}",
+        "verified_intent": {
+          "goal": "...",
+          "constraints": ["..."],
+          "quality_bar": "...",
+          "acceptance_scenarios": [
+            { "scenario": "...", "given": "...", "when": "...", "then": "..." }
+          ],
+          "out_of_scope": ["..."]
+        },
+        "modifications": ["List of items the CEO modified, if any"],
+        "auto_approved": false
+      }
+    }
+  }
+}
+```
+
+For auto-approved (lightweight/medium), set `"agent": "pipeline"`,
+`"auto_approved": true`, and `"modifications": []`.
+
+Also update `directive.json.dod` with the verified values:
+- `dod.quality_bar` = `verified_intent.quality_bar`
+- `dod.success_looks_like` = one entry per acceptance scenario's `then` field
+- `dod.failure_looks_like` = inverse of each constraint (if constraint is
+  "no regressions", failure is "regressions introduced")
+
+This keeps `dod` in sync with verified intent for downstream consumers
+(project-brainstorm, review-gate) that read `dod` directly.
+
+---
+
+### Update directive.json
+
+Set `current_step: "plan"` (the next step).
+
+Set `pipeline.clarification.status` to `"completed"` with the output
+block described above. Include `artifacts: []` (no separate file -- the
+verified intent lives inside directive.json).
+
+Update `updated_at` to the current ISO timestamp.
+
+**Next step:** Proceed to [05-planning.md](05-planning.md) (plan). The
+COO receives `pipeline.clarification.output.verified_intent` as a
+primary input for planning.

package/.claude/skills/directive/docs/pipeline/05-planning.md

@@ -1,12 +1,19 @@
 <!-- Pipeline doc: 05-planning.md | Source: SKILL.md restructure -->
 
-## Step 3: Spawn the COO (Strategic Planning)
+## Plan: Spawn the COO (Strategic Planning)
 
 Spawn the COO as an Agent (model: opus, subagent_type: COO's ID from registry).
 
+### Step Entry — Update directive.json immediately
+
+Before spawning the COO, write `pipeline.plan` to directive.json with `"status": "active"` and `"agent"` set to the COO's first name (lowercase). This triggers the dashboard game to route the COO character to the meeting room.
+
 **The COO's prompt must include:**
 - The CEO directive text (personality is auto-loaded via the `subagent_type`)
 - The goals index, lessons, and agent summaries from the context step
+- **Audit findings** (from the audit step) -- the COO receives these as input. If the audit reveals complexity exceeding the triage estimate, the COO should flag it in `challenges.risks` and adjust project decomposition accordingly.
+- **Brainstorm synthesis** from `.context/directives/{directive-id}/brainstorm.md` -- the team's approach proposals, trade-offs, and (for heavyweight/strategic) challenge critiques. The COO should use this to inform project decomposition rather than re-deriving the approach from scratch.
+- **Verified intent** from the clarification step (`pipeline.clarification.output.verified_intent` in directive.json) -- this is the CEO-confirmed goal, constraints, quality bar, acceptance scenarios, and out-of-scope items. Inject it into the planner prompt at the `{verified_intent}` placeholder. If the clarification step was auto-approved or skipped, pass the synthesized intent (which still contains extracted constraints and scenarios).
 - These explicit instructions:
 
 > See [docs/reference/templates/planner-prompt.md](../reference/templates/planner-prompt.md) for the full COO planning prompt.
@@ -19,10 +26,7 @@ Spawn the COO as an Agent (model: opus, subagent_type: COO's ID from registry).
 
 > See [docs/reference/rules/scope-and-dod.md](../reference/rules/scope-and-dod.md) for scope format rules, Definition of Done rules, and user scenario rules.
 
-**If this directive was classified as strategic**, also include in the COO's prompt:
-- The brainstorm synthesis from `.context/directives/{directive-id}/brainstorm.md`
-- CEO's clarification answers
-- Additional instruction to the COO: "The team has brainstormed approach options for this directive. Use the brainstorm synthesis and CEO's answers to inform your plan — you don't need to re-derive the approach from scratch. Focus on execution planning, not strategy."
+**Additional instruction for the COO:** "The team has brainstormed approach options and the CTO has audited the codebase. Use the brainstorm synthesis, CEO's clarification answers, and audit findings to inform your plan -- focus on execution planning, not strategy re-derivation."
 
 **Parse the COO's response** as JSON. Extract the JSON object from the response (find the first `{` and last `}`). If it fails to parse, show the error and stop.
 
@@ -36,7 +40,7 @@ Save the COO's parsed JSON plan to `.context/directives/{directive-id}/plan.json
 
 If the COO's plan contains a `projects` array (triggered when genuinely complex work can't be decomposed into simple tasks):
 
-1. **Verify projects are independent** — if project B depends on project A's output (shared code, shared data structures, one builds on the other), they MUST be merged into a single project with ordered tasks. Task array ordering IS the dependency mechanism. There is no cross-project dependency field.
+1. **Verify projects are independent or use depends_on** — if project B depends on project A's output (shared code, shared data structures, one builds on the other), either merge into a single project with ordered tasks, or set `depends_on: ["project-a"]` in the COO plan to enforce execution order. For tightly coupled work sharing code dependencies, prefer merging into ONE project.
 2. **Create a separate project directory and project.json for each independent project** in the approve step (after CEO approval)
 3. **Each project gets its own brainstorm** (2-3 agents + deliberation) before build
 4. **Each project gets its own execution cycle** in the execute step: brainstorm -> audit -> build -> review -> verify
@@ -52,13 +56,21 @@ echo "$PLAN_JSON" | .claude/hooks/validate-cast.sh
 ```
 
 The script checks:
-1. Every task has an auditor assigned
-2. Builder is not in the reviewers array (conflict of interest)
-3. Complex tasks (5+ phases) have at least one C-suite reviewer
+1. Every project has at least one reviewer assigned
+2. Builder (agent[]) is not in the reviewers array (conflict of interest)
+3. Complex or moderate projects have at least one C-suite reviewer
 4. Agents don't review changes to their own behavior/prompts
+5. `depends_on` references point to existing project IDs
+6. No circular dependencies in the `depends_on` graph
 
 If validation fails (`valid: false`), log the violations and either:
 - **Auto-fix** if the violation is clear (e.g., swap a conflicting reviewer for the next-best match per casting rules)
 - **Block** and re-prompt the COO with the violations if auto-fix isn't possible
 
 > See `.claude/hooks/validate-cast.sh` for the validation script (copied to consumer project by `/gruai-config`).
+
+### Update directive.json
+
+Set `current_step: "approve"` (the next step). Update `pipeline.plan.status` to `"completed"` with `agent: ["morgan"]`, output summary including the plan goal and project count, and `artifacts: [".context/directives/{id}/plan.json"]`.
+
+**Next step:** Proceed to [07-plan-approval.md](07-plan-approval.md) (approve) to present the combined plan to the CEO.