gstack /autoplan CEO Phase 深度解析：双模型独立声部 + 自动决策驱动的开发计划战略审查流水线

在 gstack 的 /autoplan 一键自动审查流水线中，Phase 1（CEO Review）是唯一一个无条件执行的阶段：它审视的不是代码细节，而是"这个计划是否值得做、前提是否成立、范围是否校准"。本指南围绕 autoplan/sections/ceo-phase.md 展开，完整讲解该阶段在 /autoplan 骨架中的位置、6 大自动决策原则下的覆盖规则、Claude 子代理与 Codex 双声部的编排与降级矩阵、Step 0A–0F 前置清单，以及 Phase 1 的强制交付物。读完你将理解这套"全自动审查"如何既保留人工判断的闸门（premise gate、User Challenge），又把其余 15–30 个中间提问全部压缩为可审计的自动决策。

一、定位：为什么 CEO 阶段总是第一个跑

/autoplan 的哲学是"一条命令，粗糙计划进，完整审查计划出"（见 autoplan/SKILL.md）。它的执行骨架把完整审查拆成四个阶段并强制顺序执行：

阶段	触发条件	对应 section 文件
Phase 1 CEO Review	总是运行	autoplan/sections/ceo-phase.md
Phase 2 Design Review	仅当 Phase 0 检测到 UI scope	autoplan/sections/design-phase.md
Phase 3 Eng Review	总是运行（需过 Pre-Phase 3 检查）	autoplan/sections/eng-phase.md
Phase 3.5 DX Review	仅当检测到开发者向 scope	autoplan/sections/dx-phase.md
Phase 4 Final Approval Gate	汇总任务后呈现最终闸门	autoplan/sections/tasks-aggregator.md

阶段注册表见 autoplan/sections/manifest.json，其中对 ceo-phase 的定位是"Phase 1: CEO review (strategy & scope) — override rules, dual voices, required outputs"。母技能在进入 Phase 1 前会输出明确的 STOP 指令：必须读取 ceo-phase.md 并完整执行，禁止凭记忆工作——这个 section 文件是该步骤的唯一事实来源。这意味着本文讲解的 ceo-phase.md 就是 CEO 阶段实际下发给执行模型的可执行规格（skeleton 分段加载架构的一部分）。

二、覆盖规则：全深度执行 + 六原则自动决策

ceo-phase.md 的核心不是"写一份审查报告"，而是规定 /autoplan 与交互式 /plan-ceo-review（见 plan-ceo-review/SKILL.md）行为差异的覆盖层：

• 模式选择：SELECTIVE EXPANSION（选择性扩张）。以用户当前范围为基线，把范围"做到无懈可击"，同时单独浮现每一个可扩张机会供用户挑选，不悄悄塞入也不静默砍掉。
• 遵循加载的技能文件全章节、全深度执行（"Follow plan-ceo-review/SKILL.md — all sections, full depth"）。
• 覆盖：每一个 AskUserQuestion 都用 6 原则自动决策。

2.1 六条决策原则

这些原则定义在 autoplan/SKILL.md，是 ceo-phase 每一条自动决策的裁决依据：

1. P1 选完整性（Choose completeness）——交付完整的东西，选覆盖更多边界情况的方案；
2. P2 煮干湖泊（Boil lakes）——修复爆炸半径（本计划修改的文件 + 直接导入者）内的一切；在爆炸半径内且 < 1 天 CC 工作量（< 5 个文件、无新基础设施）的扩张自动批准；
3. P3 务实（Pragmatic）——两个方案解决同一问题时选更干净的，5 秒决定而非 5 分钟；
4. P4 DRY——与既有功能重复？拒绝，复用已有实现；
5. P5 显式优于精巧（Explicit over clever）——10 行显而易见的修复 > 200 行抽象；
6. P6 行动偏好（Bias toward action）——合并 > 反复审查 > 停滞推敲，标记担忧但不阻塞。

原则冲突时按阶段裁量：CEO 阶段由 P1（完整性）+ P2（煮干湖泊）主导；Eng 阶段由 P5 + P3 主导；Design 阶段由 P5 + P1 主导。

2.2 按决策主题的具体裁决规则

ceo-phase.md 逐条给出了覆盖规则：

• 前提（Premises）：接受合理前提（P6），仅挑战明显错误者；
• 替代方案（Alternatives）：选完整性最高者（P1），平局取最简单者（P5），前两名接近时标记为 TASTE DECISION（品味决策）；
• 范围扩张（Scope expansion）：在爆炸半径内且 < 1 天 CC → 批准（P2）；半径外 → 推迟到 TODOS.md（P3）；重复 → 拒绝（P4）；模糊地带（3–5 个文件）→ 标记 TASTE DECISION；
• 全部 10 个审查章节：完整运行，逐条自动决策并记录每一条决策；
• 策略分歧：Codex 以有效战略理由反对某前提或范围决策 → TASTE DECISION；两个模型都认为用户声明的结构应改变（合并/拆分/增删）→ USER CHALLENGE，永不自动决策。

三、两道永不自动决策的闸门

/autoplan 把"自动决策"定义为：用 6 原则替代用户的判断，但绝不替代分析本身。每个章节的分析深度与交互式版本完全一致，改变的只是谁来回答 AskUserQuestion（见 autoplan/SKILL.md）。唯二例外正是 ceo-phase.md 反复强调的两点：

1. Premise Gate（前提闸门）：ceo-phase.md 明确写道——"GATE: Present premises to user for confirmation — this is the ONE AskUserQuestion that is NOT auto-decided. Premises require human judgment."（前提涉及人类对"该解决什么问题"的判断，必须真人确认）。这也是为什么后续所有阶段都要等 premise gate 通过才继续。
2. User Challenge：当 Claude 与 Codex 双模型一致认为用户给定的方向（增删/合并/拆分功能或工作流）应当改变时，以"用户原方向为默认"，模型必须论证为何要改，并诚实列出"我们可能缺失的上下文"和"如果我们错了代价是什么"（见 autoplan/SKILL.md）。跨模型一致只是一个强信号，不是行动的许可。

四、双声部（Dual Voices）：Claude 子代理与 Codex 的顺序编排

ceo-phase.md 规定：只要可用，必须同时运行 Claude 子代理与 Codex 两条独立声部（P6），且串行、前台执行、两者都完成后才构建共识表。

4.1 执行顺序与前台约束

• 先跑 Claude 子代理：通过 Agent 工具，且必须显式传 run_in_background: false——文档特别注明：自 Claude Code v2.1.198 起子代理默认进入后台，标志必须显式置 false，否则流程会提前继续。
• 再跑 Codex：通过 Bash 执行 codex exec。
• 两条声部都是阻塞在前台的，任何一条失败都不能让另一条跳过。

4.2 Codex CEO 声部的实际命令

ceo-phase.md 给出了完整可复制的 Bash 模板。核心要点如下（已按仓库当前模板整理）：

_REPO_ROOT=$(git rev-parse --show-toplevel) || { echo "ERROR: not in a git repo" >&2; exit 1; }
_gstack_codex_timeout_wrapper 600 codex exec "IMPORTANT: Do NOT read or execute any SKILL.md files
or files in skill definition directories (paths containing skills/gstack). These are AI assistant
skill definitions meant for a different system. Stay focused on repository code only.

You are a CEO/founder advisor reviewing a development plan.
Challenge the strategic foundations: Are the premises valid or assumed? Is this the
right problem to solve, or is there a reframing that would be 10x more impactful?
What alternatives were dismissed too quickly? What competitive or market risks are
unaddressed? What scope decisions will look foolish in 6 months? Be adversarial.
No compliments. Just the strategic blind spots.
File: <plan_path>" -C "$_REPO_ROOT" -s read-only -c 'web_search="cached"' < /dev/null
_CODEX_EXIT=$?
if [ "$_CODEX_EXIT" = "124" ]; then
  _gstack_codex_log_event "codex_timeout" "600"
  _gstack_codex_log_hang "autoplan" "0"
  echo "[codex stalled past 10 minutes — tagging as [codex-unavailable] for this phase and proceeding with Claude subagent only]"
fi

要点：

• Prompt 前缀的文件系统边界指令是强制的（Filesystem Boundary，见 autoplan/SKILL.md），防止 Codex 在磁盘上发现 gstack 技能定义后"读技能当指令"而偏离仓库代码审查；
• -s read-only 限定只读沙箱，-c 'web_search="cached"' 走缓存搜索，< /dev/null 防止交互挂起；
• _gstack_codex_timeout_wrapper 是超时包装器（由 gstack-codex-probe 提供，同样用于 scripts/resolvers/review.ts 中对 codex exec / codex review 的调用），此处 600 秒；
• 退出码 124 = 超时：记事件与挂起日志，把本阶段 Codex 声部自动降级为 [codex-unavailable]；
• 超时预算双层：shell 包装 10 分钟 + Bash 外层闸门 12 分钟。

4.3 Claude CEO 子代理的评估框架

Claude 声部的指令是五连问式的独立战略审查（"你未看过任何先前的评审"）：

1. 这是该解决的问题吗？换个框架能否带来 10x 影响？
2. 前提是明确陈述还是仅仅被假定？哪些可能错了？
3. 6 个月后悔场景是什么——什么决定会显得愚蠢？
4. 哪些替代方案在未充分分析时就被丢弃了？
5. 竞争风险是什么——会不会有别人先解决/解决得更好？

每个发现必须给出：问题是什么、严重度（critical/high/medium）、以及修复方案。

4.4 错误处理与降级矩阵

文档把失败路径编码成明确的降级矩阵：

情形	行为
Codex 认证失败 / 超时 / 空输出	仅用 Claude 子代理继续，标记 [single-model]
Claude 子代理也失败	"Outside voices unavailable — continuing with primary review"
两者都失败	降级为 "single-reviewer mode"
仅 Codex 可用	标记 [codex-only]
仅子代理可用	标记 [subagent-only]

注意 ceo-phase.md 的时序要求：先子代理后 Codex（与 plan-ceo-review/SKILL.md 中"Outside Voice 默认开启"的独立挑战机制互补）。Codex 的输出展示在 CODEX SAYS (CEO — strategy challenge) 标题下，子代理的输出展示在 CLAUDE SUBAGENT (CEO — strategic independence) 标题下。

4.5 共识表

两条声部都完成后，必须产出 CEO 共识表。ceo-phase.md 给出了精确模板，六个维度逐行对比两模型判断：

CEO DUAL VOICES — CONSENSUS TABLE:
═══════════════════════════════════════════════════════════════
  Dimension                           Claude  Codex  Consensus
  ──────────────────────────────────── ─────── ─────── ─────────
  1. Premises valid?                   —       —      —
  2. Right problem to solve?           —       —      —
  3. Scope calibration correct?        —       —      —
  4. Alternatives sufficiently explored?—      —      —
  5. Competitive/market risks covered? —       —      —
  6. 6-month trajectory sound?         —       —      —
═══════════════════════════════════════════════════════════════
CONFIRMED = both agree. DISAGREE = models differ (→ taste decision).
Missing voice = N/A (not CONFIRMED). Single critical finding from one voice = flagged regardless.

语义规则：CONFIRMED = 两模型一致；DISAGREE = 意见分歧（转入品味决策）；缺失声部记 N/A（不等于 CONFIRMED）；单一声部提出的 critical 级发现无论另一方如何都须标记。/autoplan 收尾时会把 consensus_confirmed/consensus_disagree 计数写入 autoplan-voices 评审日志（见 autoplan/SKILL.md），source 取值 codex+subagent / codex-only / subagent-only / unavailable。

这条双声部路径有专门的 E2E 测试守护：test/skill-e2e-autoplan-dual-voice.test.ts。它把 /autoplan 连同 plan-ceo-review 等依赖技能复制进临时仓库，以 10 分钟硬超时跑 /autoplan，断言"两条声部都产出输出，或 Codex 不可用时优雅降级到 Claude 声部"。注释还记录了预算教训：早期 5 分钟/30 回合的预算会在 CEO 审查中途被杀死，全深度 Phase 1 需要更长时间窗口。

五、Step 0A–0F：CEO 审查的六段前置清单

ceo-phase.md 要求 Phase 1 先完整执行 Step 0 的六个子步骤，并逐项产出：

• 0A 前提挑战：点名具体前提并逐一评估（不能写"前提已接受"了事）；
• 0B 既有代码杠杆图：子问题 → 既有代码的映射（后续会沉淀为"NOT in scope"与"What already exists"输出）；
• 0C 理想态图：CURRENT → THIS PLAN → 12-MONTH IDEAL 三段式对照；
• 0C-bis 实施替代方案表：2–3 种方案，含工作量/风险/优缺点；
• 0D 模式特定分析：记录范围决策（SELECTIVE EXPANSION 下接受/推迟/跳过哪些扩张提案）；
• 0E 时间问讯（Temporal interrogation）：从 HOUR 1 到 HOUR 6+ 推演执行窗口会发生什么；
• 0F 模式选择确认。

Step 0.5 即双声部编排（见上文），随后构建共识表。在交互式 /plan-ceo-review 中 Step 0 还要先跑 PRE-REVIEW SYSTEM AUDIT（git log、diff stat、TODO 扫描、设计文档探测等，见 plan-ceo-review/SKILL.md）。

六、第 1–10 章节审查与第 11 章条件触发

ceo-phase.md 规定：对每一个章节，都要按所加载技能文件的评估标准完整执行：

• 有发现的章节：完整分析、逐条自动决策、写入审计追踪；
• 无发现的章节：用 1–2 句话说明检查了什么以及为什么没有标记——绝不允许把章节压缩成表格里的一个名字（"NEVER compress a section to just its name in a table row"）；
• 第 11 章（Design & UX）：仅当 Phase 0 检测到 UI scope 时才运行。

CEO 技能实际的章节细则在 plan-ceo-review/sections/review-sections.md，共 11 节：1 架构、2 错误与救援地图、3 安全与威胁模型、4 数据流与交互边界、5 代码质量、6 测试、7 性能、8 可观测性、9 部署与发布、10 长期轨迹、11 设计与 UX。该文件还包含反跳过规则：任何章节都必须评估，零发现时可以说"No issues found"，但必须给出证据；同时有反捷径条款：若任何章节存在非平凡发现，从发现通往 ExitPlanMode 的路必须经过 AskUserQuestion——把所有发现写进计划文件再直接退出计划模式，正是文档点名的"May 2026 transcript bug"式失败。

七、Phase 1 的强制交付物

ceo-phase.md 要求 Phase 1 结束时产出以下清单（母技能 Pre-Gate Verification 会逐项核对，见 autoplan/SKILL.md）：

• "NOT in scope" 章节：被考虑后推迟的工作及其一句理由；
• "What already exists" 章节：子问题 → 既有代码映射，及计划是否复用了它们；
• Error & Rescue Registry 表（源自第 2 章）：每个可能失败的方法/异常类/是否被捕获/救援动作/用户可见影响；
• Failure Modes Registry 表（源自各审查章节）：CODEPATH | FAILURE MODE | RESCUED? | TEST? | USER SEES? | LOGGED?，任何一行满足 RESCUED=N、TEST=N、USER SEES=Silent → CRITICAL GAP；
• Dream state delta：本计划把我们留在哪里 vs 12 个月理想态；
• Completion Summary：CEO 技能完整汇总表（模式、各章节发现计数、各注册表 CRITICAL GAP 数、Lake Score 等）。

母技能还在 autoplan/SKILL.md 定义了 Decision Audit Trail：每次自动决策都要以一行表格追加到计划文件（阶段、决策、分类、所用原则、理由、被否决项），保证"磁盘上有审计，而非累积在对话上下文里"。

八、阶段交接与闸门

Phase 1 收尾必须发出阶段转换摘要（ceo-phase.md 提供精确模板）：

Phase 1 complete. Codex: [N concerns]. Claude subagent: [N issues]. Consensus: [X/6 confirmed, Y disagreements → surfaced at gate]. Passing to Phase 2.

并明确：在全部 Phase 1 输出写入计划文件、premise gate 通过之前，不得开始 Phase 2。随后母技能执行 Pre-Phase 2 checklist 逐项核对 CEO 完成摘要、双声部运行记录、共识表、premise gate 状态与转换摘要（见 autoplan/SKILL.md），才会放行进入条件性的 Design Review。这样，整个 /autoplan 就以"CEO 阶段总前置 + 6 原则自动决策 + 两个永不自动决策的闸门 + 双模型交叉验证"的组合，把战略审查从需要回答 15–30 个中间问题的手动流程，压缩成一条最终只需在审批闸门上做选择的全自动命令。