gstack/plan-ceo-review/SKILL.md.tmpl

---
name: plan-ceo-review
preamble-tier: 3
interactive: true
version: 1.0.0
description: |
  CEO/founder-mode plan review. Rethink the problem, find the 10-star product,
  challenge premises, expand scope when it creates a better product. Four modes:
  SCOPE EXPANSION (dream big), SELECTIVE EXPANSION (hold scope + cherry-pick
  expansions), HOLD SCOPE (maximum rigor), SCOPE REDUCTION (strip to essentials).
  Use when asked to "think bigger", "expand scope", "strategy review", "rethink this",
  or "is this ambitious enough".
  Proactively suggest when the user is questioning scope or ambition of a plan,
  or when the plan feels like it could be thinking bigger. (gstack)
benefits-from: [office-hours]
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash
  - AskUserQuestion
  - WebSearch
triggers:
  - think bigger
  - expand scope
  - strategy review
  - rethink this plan
gbrain:
  schema: 1
  context_queries:
    - id: prior-ceo-plans
      kind: filesystem
      glob: "{gstack_state_root}/projects/{repo_slug}/ceo-plans/*.md"
      sort: mtime_desc
      limit: 5
      render_as: "## Prior CEO plans for this project"
    - id: recent-design-docs
      kind: filesystem
      glob: "~/.gstack/projects/{repo_slug}/*-design-*.md"
      sort: mtime_desc
      limit: 3
      render_as: "## Recent design docs for this project"
    - id: recent-reviews
      kind: list
      filter:
        type: timeline
        tags_contains: "repo:{repo_slug}"
        content_contains: "plan-ceo-review"
      sort: updated_at_desc
      limit: 5
      render_as: "## Recent CEO review activity"
---

{{PREAMBLE}}

{{BASE_BRANCH_DETECT}}

# Mega Plan Review Mode

## Philosophy
Make this plan extraordinary. Match posture:
* SCOPE EXPANSION: Build the platonic ideal, 10x better for 2x effort. Recommend expansions enthusiastically.
* SELECTIVE EXPANSION: Harden current scope; neutrally offer each expansion's opportunity, effort and risk. Accepted items govern later sections; rejected ones go to "NOT in scope."
* HOLD SCOPE: Preserve scope; trace failures, edge cases, error paths, tests and observability.
* SCOPE REDUCTION: Propose the minimum viable core; cut only with approval.
* COMPLETENESS IS CHEAP: AI makes 70 LOC seconds. Prefer complete ~150 LOC over 90% ~80 LOC. Boil the ocean.
Approval is required for each scope change. Raise concerns in Step 0, then commit: no arguing for less in EXPANSION, silent SELECTIVE additions/cuts, or scope restored to REDUCTION.
Review only. Do not change code or implement.

## Prime Directives
1. Zero silent failures: surface every failure to system, team and user.
2. Name each error's class, trigger, handler, user result and test; flag catch-alls.
3. Trace happy, nil, empty/zero and upstream-error paths.
4. Map double-clicks, navigation, slow links, stale state and back button.
5. Dashboards, alerts and runbooks are launch scope.
6. Require ASCII diagrams for new flows, state, pipelines, deps and decisions.
7. Record every deferral in TODOS.md or chat per storage policy.
8. Optimize for the 6-month future; flag future harm.
9. Propose better approaches now, including "scrap it and do this instead."

## Engineering Preferences (use these to guide every recommendation)
* DRY: flag repetition aggressively.
* Tests are required; prefer too many to too few.
* Avoid fragile hacks, premature abstractions and unnecessary complexity.
* Favor more edge cases and thoughtfulness over speed; explicit over clever.
* Prefer the smallest clear diff; broken foundations may need a rewrite under directive #9.
* New codepaths need logs, metrics or traces and threat modeling.
* Plan partial deploys, rollbacks and feature flags.
* Add and maintain ASCII comments for complex state, pipelines, requests, mixins and test setup.

## Priority Hierarchy Under Context Pressure
Step 0 > System audit > Error/rescue map > Test diagram > Failure modes > Opinionated recommendations > Everything else.
Never skip Step 0, system audit, error/rescue map or failure modes.

{{ASIDE_RESEARCH}}

{{ANTI_SHORTCUT_CLAUSE}}

## PRE-REVIEW SYSTEM AUDIT (before Step 0)
Before anything else, audit the system for review context. Run:
```
git log --oneline -30                          # Recent history
git diff <base> --stat                           # What's already changed
git stash list                                 # Any stashed work
grep -r "TODO\|FIXME\|HACK\|XXX" -l --exclude-dir=node_modules --exclude-dir=vendor --exclude-dir=.git . | head -30
git log --since=30.days --name-only --format="" | sort | uniq -c | sort -rn | head -20  # Recently touched files
```
Then read CLAUDE.md, TODOS.md, and any existing architecture docs.

**Design doc check:**
```bash
setopt +o nomatch 2>/dev/null || true  # zsh compat
SLUG=$(~/.claude/skills/gstack/browse/bin/remote-slug 2>/dev/null || basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo 'no-branch')
{{DESIGN_DOC_DISCOVERY}}
```
Read any `/office-hours` design doc as the problem, constraints and approach source of truth. `Supersedes:` marks a revised design.

**Handoff note check** (reuses $SLUG and $BRANCH from the design doc check above):
```bash
setopt +o nomatch 2>/dev/null || true  # zsh compat
HANDOFF=$(ls -t ~/.gstack/projects/$SLUG/*-$BRANCH-ceo-handoff-*.md 2>/dev/null | head -1)
[ -n "$HANDOFF" ] && echo "HANDOFF_FOUND: $HANDOFF" || echo "NO_HANDOFF"
```
In a separate shell, first recompute $SLUG and $BRANCH with the design-doc commands.
Read any paused CEO `/office-hours` handoff alongside the design doc; reuse its audit
and discussion without repeating questions or skipping review steps. Tell the user:
"Found a handoff note from your prior CEO review session. I'll use that context to pick up where we left off."

{{BENEFITS_FROM}}

**Mid-session detection (0A):** If the user cannot articulate a stable problem, says "I'm not sure"
or is exploring rather than reviewing, offer `/office-hours`:

> "It sounds like you're still figuring out what to build — that's totally fine, but
> that's what /office-hours is designed for. Want to run /office-hours right now?
> We'll pick up right where we left off."

Options: A) Yes, run /office-hours now. B) No, keep going.
If they keep going, proceed normally — no guilt, no re-asking.

If they choose A:

{{INVOKE_SKILL:office-hours}}

Note current Step 0A progress so you don't re-ask questions already answered.
After completion, re-run the design doc check and resume the review.

Map current system state, in-flight PRs/branches/stashes, relevant pain points and
FIXME/TODOs in touched files. From TODOS.md, record related prior deferrals and
work this plan touches, blocks, unlocks or depends on.

### Retrospective Check
Record earlier review refactors/reverts and overlap with this plan. Scrutinize prior problem areas; flag recurring problems as architectural concerns.

### Frontend/UI Scope Detection
Note DESIGN_SCOPE for Section 11 if the plan changes UI screens/components, user interactions, frontend frameworks, user-visible states, mobile/responsive behavior or design systems.

### Taste Calibration (EXPANSION and SELECTIVE EXPANSION modes)
Choose 2-3 good files/patterns as references and 1-2 poor ones to avoid. Report before Step 0.

### Landscape Check

Read ETHOS.md at the preamble's Search Before Building path. Before challenging scope, research through Aside (readiness above), one read-only request per query:
- "[product category] landscape {current year}"
- "[key feature] alternatives"
- "why [incumbent/conventional approach] [succeeds/fails]"

```bash
{{ASIDE_EXEC_PRELUDE}}
_aside_exec "Search the web for [product category] landscape {current year} and [key feature] alternatives. Read-only: do not sign in, submit, or change anything. Reply with up to 8 bullets, each with its source URL, then stop."
```

If the Aside check did not print `READY`, run the same queries with the WebSearch tool when the host provides it; with neither, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only."

Run the three-layer synthesis:
- **[Layer 1]** What's the tried-and-true approach in this space?
- **[Layer 2]** What are the search results saying?
- **[Layer 3]** First-principles reasoning — where might the conventional wisdom be wrong?

Use this in 0A and 0C. Surface any eureka as differentiation at Expansion opt-in; log it per the preamble.

{{LEARNINGS_SEARCH}}

{{GBRAIN_CONTEXT_LOAD}}

{{BRAIN_PREFLIGHT}}

{{SECTION_INDEX:plan-ceo-review}}

## Step 0: Nuclear Scope Challenge + Mode Selection

Startup:
1. Choose the review depth and artifact destinations, then open the ledger below.
2. Record 0A–0C evidence; call 0D only for a required approach choice.
3. Select the mode in 0E and follow its route table.
4. Complete Review Sections and its closing sequence; return to Section self-check.

0D is reusable, not an unconditional question. Observations do not approve changes.

**Set review depth from the user's request.** Default to implementation-ready.
Use strategy-only only when the user asks for strategy, scope, or prioritization
without implementation design. Use one narrow decision only when the user names a
single choice. To expand strategy-only into implementation design, use 0D with
**A)** Keep this review strategy-only **B)** Add implementation design for the
named capability. Recommend A unless a concrete blocker requires B; wait for the
answer. B permits design detail for that capability only.

Plain terms:
- **Required choice:** unanswered. Resolve a choice only when continuing would
  change scope, hide a blocker or produce the wrong output.
- **Pending:** unapproved; keep in Proposed, not tasks or accepted work. Status is
  `unresolved` or `reopened`.
- **Settled:** an answer, direct instruction or authorized auto-decision resolves
  this exact choice and scope; a recommendation does not.

Review depth controls the detail within each section. Review Sections 1–10 in every depth;
run Section 11 only for UI. Strategy-only uses capability-level rows and
"implementation owner must prove ___" notes, including the Error & Rescue map.
Implementation-ready names interfaces, codepaths, rescue behavior and tests.
For one narrow decision, apply every section to that choice and its dependencies.

**Keep the stated limits.** Record each measure, value, unit and prerequisite.
Count all deliverables, including reused code, against scope limits. Separately,
0E counts changed files, excluding unchanged reuse, to recommend a mode.
Neither count approves changes. Changing a limit needs evidence and user approval.

**Storage policy: choose before writing.** Honor user/host write and cleanup limits.
Use one working plan: requested output, else reviewed plan, else host active plan.
Use native Write for a missing file and scoped Edit for checkpoints;
retain all current content, ledger rows and comparisons.

**Artifact outcomes:** Never claim an unconfirmed save, read-back or log.
When writing is forbidden, continue analysis and decisions without writing.
Present complete artifacts as **not persisted**. At finalization, an unsaved
plan/report means **completion blocked**: no completion log, success telemetry,
ExitPlanMode or next-skill handoff.

| Permitted write | On failure |
|---|---|
| Plan/report, CEO summary, approved TODOs and tasks | Stop with the cause; chat cannot replace a failed save. Missing jq may omit only task JSONL, as the task instructions explain. |
| 0H spec-review metrics | Stop with the cause; reviewer availability does not waive this write. |
| Review, decision and question history logs | Report cause and unsaved fields; continue. The plan's ledger is still required. |

Paths differ: 0H resolves `CEO_PLANS`; tasks use `~/.gstack/projects/`, metrics
use `~/.gstack/analytics/`, and log helpers choose their paths. Never substitute
the CEO archive root for task, metric or log paths.

Keep one decision ledger through Step 0, Spec Review Loop and Outside Voice:

| ID and owner | Contract and evidence | Current | Proposed | Status | Exact approval and scope |
|---|---|---|---|---|---|

Name owners; cite evidence, conventions and tests; mark unknowns. Current holds approved values; Proposed holds alternatives. Status: unresolved, approved, reopened, deferred or declined. Cite actual instructions/answers and exact scope.

### 0A. Premise Challenge
Name the real problem, target outcome and do-nothing cost. Say whether the plan
solves the pain directly or only a proxy.

### 0B. Existing Code Leverage
Map each sub-problem to reusable code. For any rebuild, explain why refactoring
the existing path is worse.

### 0C. Dream State Mapping
Describe the 12-month ideal and whether this plan moves toward it.
```
  CURRENT STATE                  THIS PLAN                  12-MONTH IDEAL
  [describe]          --->       [describe delta]    --->    [describe target]
```

Before 0E, call 0D for unresolved approaches: A) current/requested plan,
B) smallest scoped alternative, C) larger approach/rewrite only with evidence.
With no required choice, or after those choices settle, go to 0E.

### 0D. Alternatives (reusable decision procedure)

**Choose the question's route first:**
- **Admin question:** mode, setup, navigation, document approval or promotion.
  Use its listed menu and the preamble question transport, then wait and record
  the answer. Skip steps 1–4; this approves no plan changes. Resume that menu's
  next step. 0E owns mode selection; 0H owns document approval. Neither needs
  a plan-decision row or comparison grid.
- **Plan decision:** review-depth expansion, scope additions/cuts, approach
  choices, TODOs, specs and review/outside findings. Start at step 1. Reuse exact
  prior approvals; run steps 2–4 only when a new answer is needed, even for one option.

If an admin answer requests a plan change, use the Plan decision route for that
change before resuming. 0G proposals and section findings use this route even
with prescribed menus. 0D returns to its caller, not to mode selection.
For mode changes, follow 0E's **Mode change** instruction.

**1. Check sources and prior answers.**
Compare input, source and answers; correct facts, flag conflicts and preserve unknowns.
Reuse exact approvals. Reopen only for contradictions, changed assumptions or
user instructions, never speculation or reviewer agreement. With no new answer
needed, cite settled answers and return; invent no alternatives or approval.

**2. Record the pending choice.**
Give independent changes separate ledger rows; explain necessary coupling. Record
owner, behavior, limits, test method and coverage in Current/Proposed. Cite the
source filename/message and section/lines when available.

| Test choice | Treatment |
|---|---|
| Code change and required regressions | Keep together; carry both forward once approved. |
| Approved change with open test method/coverage | Decide once; every option preserves required behavior and approved tests. |
| Tests for existing behavior | Separate independently selectable additions. Tests for undecided behavior stay pending. |

Record pending rows before comparisons; never prewrite approval or tasks.

**3. Compare and save that row's options.**
Build one `currentDecision` using these fields and the preamble format:

| Field | Required content |
|---|---|
| `question` | Full brief: `D<N> — <ROW-ID>: <one-line question>`, Project, ELI10, Stakes, Recommendation and applicable completeness/net text. D counts questions; ROW-ID identifies the pending choice. |
| `header` and option labels | Final native text within host limits; exactly one label includes `(recommended)`. |
| Each option's `description` | A 1–2 sentence summary; S/M/L/XL effort, low/medium/high risk, reuse, verification coverage, at least 2 ✅ pros and 1 ❌ con. Apply the preamble's minimum lengths and destructive-choice exception. |

Without a prescribed menu, offer 2–3 options (prefer 3 for non-trivial plans).
For an option with no implementation, use effort S and state zero implementation
work, never effort 0. Weigh diff size and long-term architecture equally,
including rewrites: compare immediate changed-file cost and future maintenance
cost for each option; explain both in the recommendation.

In Proposed, compare every commitment in the labels, descriptions and pros/cons:

```text
Commitment | Source/approval or pending | Current | A | B | C
```

Include one column per option (add D for a four-option menu). Show unchanged,
shared and pending values. Keep independent changes separate even within one
framework; other rows stay fixed or pending. Preserve requirements, tests and fixes.

Choose scoring before saving:
- **Same work, different coverage:** Score this row's coverage differences:
  10 = all edge cases, 7 = happy path, 3 = shortcut. Score each option.
- **Different work:** For different kinds of work (including mode selection and
  Add/Defer/Skip or Defer/Keep), write:
  "Note: options differ in kind, not coverage — no completeness score."
  No score does not waive approval checkpoints.

**Pre-question checkpoint:** Validate every field above before saving.
Find exactly one row by its assigned ID; verify owner, Current/Proposed, Status
and Exact approval and scope. Repair missing/duplicate rows in step 2.
Effort/risk must each be one listed value, never a range. Correct missing or
invalid fields and host-limit violations before saving.

- **Save.** Under the storage policy, save/present the complete current plan,
  pending rows and comparisons. Copy the grid and all exact fields below
  (omit the fence delimiters):

  ```text
  ## currentDecision (ROW-ID)
  Commitment comparison: <complete grid>

  Question: <complete currentDecision.question>
  Header: <exact currentDecision.header>
  A) <exact first option label>
  <full first option description>
  B) <exact second option label>
  <full second option description; repeat for all offered options>
  ```

  Replace the whole payload on revision; keep answered decisions under separate headings.
- **Read-back.** After the latest successful Write/Edit, Read the ledger row and
  full payload through the last option's description; fetch continuations.
  Verify IDs and fields against `currentDecision`, citations against source.
  Read despite Edit's current-in-context hint. For chat, verify the complete text
  labeled **not persisted**, not a grid, summary or pointer.

A failed save stops the review. Correct mismatches, save and Read again before dispatch.

**4. Ask, record the answer, and amend.**
Copy the verified Read or chat text into one native arguments object:
`{questions: [{question, header, options: [{label, description}, ...]}]}`.
Compare its question, header, labels and full descriptions literally with the
verified fields, ignoring only saved selector prefixes such as `A)` or `B)`.
Compare strings, not format/scores. Changes repeat step 3's save and Read-back.
Ask one row per call with that object unchanged, without recomposing.
Only the preamble can authorize prose or auto-decision transport.

**STOP for the actual answer, even for a lone option.** Only a preamble-authorized
auto-decision resolves this wait; record its authority. Save the answer reference
and scope in Exact approval and scope, update Status and amend only authorized
work. A recommendation is not approval; do not edit code.

**Post-answer checkpoint:** Save or present the complete amended plan under the
storage policy before taking another row.

If all options are declined, continue only if the answer retains a viable current
approach; otherwise leave the row unresolved and stop for direction.

Return to the calling step with the saved answer; do not ask it again.
Record findings even after resolution; say "No issues, moving on." only with none.

### 0E. Mode Selection
Follow the preamble's session rules; `CONDUCTOR_SESSION: true` changes transport only.

1. An explicit choice skips steps 2–3. "Go big", "ambitious" or "cathedral" means SCOPE EXPANSION; "hold scope but tempt me", "show me options" or "cherry-pick" means SELECTIVE EXPANSION.
2. Recommend without selecting. Count distinct planned file additions, edits and
   deletions; mark estimated counts as estimates. Apply the first matching rule:
   - For >15 planned changed files, recommend SCOPE REDUCTION.
   - If categories overlap or are unclear, explain why and recommend HOLD SCOPE.
   - Otherwise: a new product/system (greenfield) → SCOPE EXPANSION;
     added capability → SELECTIVE EXPANSION; fix/refactor → HOLD SCOPE.
   In the Recommendation's `because` clause, connect a concrete plan fact or
   constraint to this mode's actual benefit or tradeoff, not just its count/category.
3. Resolve that recommendation. When `QUESTION_TUNING: true`, first check `question_id=plan-ceo-review-mode` through the preamble.
   A check that exits 0 with `AUTO_DECIDE` selects the recommendation; go to the automatic handoff in
   step 4. When tuning is false, omit the lookup.
   Without that successful check, offer all four modes in one AskUserQuestion,
   using step 2's recommendation. **STOP for the answer**; the user's choice
   wins. When `QUESTION_TUNING: true`, include `<gstack-qid:plan-ceo-review-mode>`.
   These modes differ in kind, not coverage; do NOT score completeness.

4. **Mode handoff:** After selection, send brief chat before tools or further questions: the mode's application and rationale; every governing approved row's ID, answer reference and accepted scope. Keep rows separate.
- `plan-ceo-review-mode: AUTO_DECIDE`: `Auto-decided review mode → <selected mode> (your preference). Change with /plan-tune. Approved decisions: <rows or none>. <Application and rationale>.`
- Other selections: `Mode: <selected mode>; approved decisions: <rows or none>. <Application and rationale>.`

Record mode provenance after the handoff:
- **Explicit user choice:** instruction and mode; no question log because none was asked.
- **Successful preference check:** result and recommendation; log `plan-ceo-review-mode`, `auto_decided: true`.
- **Actual question answer:** question, answer reference and mode; log `auto_decided: false`, including the question ID only when `QUESTION_TUNING: true`.

If 0D needed no approach choice, say "No new approach decision was needed" after
the mode handoff.
**Mode change:** Pause and ask with the four-mode menu; keep the mode until
answered. If changed, repeat the handoff/provenance record and complete newly
applicable Step 0 work in route order, reusing completed work and scope answers.
Then resume the paused step. If unchanged, resume directly.

Selecting a mode does not approve changes. Preserve 0D approvals and ask about
each proposed addition or cut, including those prompted by file-count thresholds.

Follow the selected mode's route:

| Mode | Remaining Step 0 work |
|------|----------------------|
| SCOPE EXPANSION / SELECTIVE EXPANSION | 0F → 0G → 0H (including its spec review loop) → 0I |
| HOLD SCOPE | 0G → 0I |
| SCOPE REDUCTION | 0G |

Continue to Review Sections, outputs and report.

### 0F. Expansion Framing (shared by EXPANSION and SELECTIVE EXPANSION)

Prepare 0G candidates: user experience, addition, S/M/L/XL effort, risk and impact.
SCOPE EXPANSION is enthusiastic; SELECTIVE EXPANSION balances benefits and
tradeoffs without unsupported promises. Mark one option `(recommended)`;
the user still decides each proposal in 0G.

### 0G. Mode-Specific Analysis
In expansion modes, extend 0F's pending list.

**For SCOPE EXPANSION:**
1. **10x check:** Describe 10x value for 2x effort.
2. **Platonic ideal:** What would the best engineer with unlimited time and perfect taste build? Start with the user's experience.
3. **Delight scan:** List at least 5 adjacent 30-minute improvements that would delight the user.
4. **Expansion opt-in ceremony:** Present visions and individual proposals; enthusiastically explain each one's value. The user decides.

**For SELECTIVE EXPANSION:**
1. Run all three HOLD SCOPE checks below, including their defer/keep decisions.
2. Describe 10x ambition, run the delight scan and assess platform potential. Candidates stay pending until scope answers.
3. **Cherry-pick ceremony:** Use 0F with S/M/L/XL effort and risk. For more than 8, present the top 5–6; offer the rest on request.

For both expansion modes, ask separately for each addition: **A)** Add to this plan's scope **B)** Defer to TODOS.md **C)** Skip. Accepted items govern the remaining sections.

**For HOLD SCOPE** — run this:
1. Complexity check: at more than 8 files or more than 2 new classes/services, challenge whether fewer moving parts achieve the same goal.
2. Find the minimum changes for the goal; flag work deferrable without blocking it.
3. Keep stated invariants and acceptance criteria; repairs needed to meet them are in scope.

**For SCOPE REDUCTION:** propose minimum scope and resolve each proposed deferral
with the defer/keep menu below; retain the rest.

**Deferring current scope** (REDUCTION, HOLD and SELECTIVE's HOLD checks): ask
separately per item: **A)** Defer this item to TODOS.md **B)** Keep it in scope.

Run all four 0D steps for each unanswered addition or deferral, using its menu.
Omit completeness scores per 0D. Keep other scope fixed or pending; wait for the
answer before applying it.
A deferral changes only delivery scope: record its answer/reason beside the prior
approval. Keep other approvals and limits unchanged. Review retained work and
accepted additions; exclude deferred or rejected work.

Save dispositions under the storage policy:
- **Add / Keep:** accepted working-plan scope.
- **Defer:** TODOS.md with context and NOT in scope with the deferral reason. This postpones work; it does not reject it.
- **Skip / Cut:** NOT in scope with the rejection reason; no TODO.

Reuse answered scope decisions without another question or comparison.
Implementation choices remain pending until answered.

### 0H. Persist CEO Plan (EXPANSION and SELECTIVE EXPANSION only)

Prepare the full amended working plan and a separate, consistent CEO scope
summary; the summary cannot serve as the plan.

**Save or present both inputs under the storage policy.** For permitted storage:

```bash
eval "$(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)"
eval "$(~/.claude/skills/gstack/bin/gstack-paths)"
CEO_PLANS="$GSTACK_STATE_ROOT/projects/$SLUG/ceo-plans"
mkdir -p "$CEO_PLANS"
echo "CEO_PLANS=$CEO_PLANS"
```

Use `{printed CEO_PLANS}/{YYYY-MM-DD}-{feature-slug}.md`. Archiving old (>30 days) or merged/deleted-branch plans requires approval.

**Otherwise:** Present both inputs in full as not persisted.

**CEO summary format — use for both saved and chat output:**

```markdown
---
status: ACTIVE
---
# CEO Plan: {Feature Name}
Generated by /plan-ceo-review on {date}
Branch: {branch} | Mode: {EXPANSION / SELECTIVE EXPANSION}
Repo: {owner/repo}

## Plan under review
{working plan path, or "Working plan — complete text in chat; not persisted"}

## Vision

### 10x Check
{10x vision description}

### Platonic Ideal
{platonic ideal description — EXPANSION mode only}

## Scope Decisions

| # | Proposal | Effort | Decision | Reasoning |
|---|----------|--------|----------|-----------|
| 1 | {proposal} | S/M/L/XL | ACCEPTED / DEFERRED / SKIPPED | {why} |

## Accepted Scope (added to this plan)
- {bullet list of what's now in scope}

## Deferred to TODOS.md
- {items with context}

## Reviewer Concerns
- {unresolved spec-review issues with their owning input, or "None"}
```

{{SPEC_REVIEW_LOOP}}

After the loop completes or reports unavailable, present both inputs for final
scope-document approval. Ask with the preamble question transport:
**A)** Approve these documents and continue to 0I **B)** Revise these documents
**C)** Pause this review. Recommend A only if both reflect the exact decisions.
Wait and record the answer. A accepts these document versions only; unresolved
amendments and implementation remain unapproved. For B, resolve the requested
changes through 0D, update both inputs and repeat document approval. C stops.
After A, run 0I before Review Sections.

### 0I. Temporal Interrogation (EXPANSION, SELECTIVE EXPANSION, and HOLD modes)
Resolve scope and feasibility blockers through 0D now. Keep other design choices
pending unless the user requested implementation planning.
```
  HOUR 1 (foundations):     What does the implementer need to know?
  HOUR 2-3 (core logic):   What ambiguities will they hit?
  HOUR 4-5 (integration):  What will surprise them?
  HOUR 6+ (polish/tests):  What will they wish they'd planned for?
```
Save the sequence, feasibility blockers and pending choices in the plan, with human-team and CC + gstack effort.

Carry the ledger and each answer's exact scope into the review sections.

## Continue after Step 0 (all modes)

{{SECTION:review-sections}}

## Section self-check (before you finish)

Confirm you Read `sections/review-sections.md` and executed Sections 1–10,
Section 11's findings or no-UI skip, required outputs and report from that file.
If the Summary or report preceded that Read, stop, Read and redo the review.

{{EXIT_PLAN_MODE_GATE}}

**Gate outcome:**
- **Pass with log-only gaps:** A verified report plus forbidden metadata or
  failed best-effort history can pass. Mark unsaved fields **not persisted**.
  Failed required writes still block.
- **Blocked:** Return the failed check and complete plan, report and summary.
  Label only unwritten artifacts **not persisted**; missing logs do not unsave
  a verified report. State **completion blocked**; end without success telemetry,
  ExitPlanMode or the queued handoff. Resume when the blocker is resolved.
- **Passed with a verified persisted report:** finish the cache refresh below,
  then run telemetry as the last review operation.

{{BRAIN_CACHE_REFRESH}}

After the refresh, run the preamble's **Telemetry (run last)** once. The review
is now finished. Call ExitPlanMode where required or return to the caller;
the chosen next-skill handoff starts a separate workflow.