gstack OpenClaw Plan 层详解：用 gstack-plan 流水线为 Claude Code 项目产出全量评审过的实施计划

gstack 与 OpenClaw 的集成把「方法论」当作注入式提示词文本，而不是移植代码库。其中 openclaw/gstack-plan-CLAUDE.md 定义了五档分发路由中的 Plan 层：当用户只想「规划一个 Claude Code 项目」而先不写代码时，编排器（orchestrator）会把这份模板追加到目标仓库的 CLAUDE.md，驱动 Claude Code 依次跑 /office-hours 设计文档与 /autoplan 全量评审流水线，最终产出一个落盘的计划文件并回报编排器。读完本文，你能完整理解这条「只规划、不实现」流水线的每一步契约、它依赖的两个核心技能的内部机制，以及计划如何交接给后续的实现会话。

一、gstack 的 OpenClaw 集成：一份轻量协议，五档分发路由

gstack 对 OpenClaw 的定位是「方法论来源」（a methodology source），不是移植的代码库。OpenClaw 的 ACP runtime 原生负责派生（spawn）Claude Code 会话，gstack 则提供让会话更可靠的规划纪律与方法论。按 docs/OPENCLAW.md 的说法，这是一份「编码为提示词文本的轻量协议。没有守护进程，没有 JSON-RPC，没有兼容矩阵——提示词本身就是桥」。

集成架构如下（引自 docs/OPENCLAW.md）：

  OpenClaw                               gstack repo
  ─────────────────────                    ──────────────
  Orchestrator: messaging,                 Source of truth for
  calendar, memory, EA                     methodology + planning
       │                                        │
       ├── Native skills (conversational)       ├── Generates native skills
       │   office-hours, ceo-review,            │   via gen-skill-docs pipeline
       │   investigate, retro                   │
       │                                        ├── Generates gstack-lite
       ├── sessions_spawn(runtime: "acp")       │   (planning discipline)
       │       │                                │
       │       └── Claude Code                  ├── Generates gstack-full
       │           └── gstack installed at      │   (complete pipeline)
       │               ~/.claude/skills/gstack  │
       │                                        └── docs/OPENCLAW.md (this file)
       └── Dispatch routing (AGENTS.md)

OpenClaw 在派生会话时决定使用哪一档 gstack 支持。完整的五档路由表（见 docs/OPENCLAW.md 与 openclaw/agents-gstack-section.md）：

档位	适用场景	注入内容
Simple	单文件修改、错别字、配置变更	不注入 gstack 上下文
Medium	多文件功能、重构	追加 gstack-lite CLAUDE.md
Heavy	需要特定 gstack 技能	Load gstack. Run /X
Full	完整功能、目标级项目	追加 gstack-full 流水线
Plan	「帮我规划一个 Claude Code 项目」	追加 gstack-plan 流水线

对应的决策启发式（decision heuristic）：

• 改动小于 10 行代码？→ Simple
• 涉及多文件但方案显而易见？→ Medium
• 用户点名了某个技能（/cso、/review、/qa）？→ Heavy
• 是功能、项目或目标（而非单个任务）？→ Full
• 用户想在实现之前先做规划（PLAN something without implementing yet）？→ Plan

Plan 档的派生动作在 openclaw/agents-gstack-section.md 中给出：

**PLAN:** user wants to plan a Claude Code project, spec out a feature, or design
  something before any code is written
→ sessions_spawn(runtime: "acp", prompt: "<gstack-plan content>\n\n<task>")
  Claude Code runs: /office-hours → /autoplan → saves plan file → reports back
  Persist the plan link to memory/knowledge store.
  When the user is ready to implement, spawn a new FULL session pointing at the plan.

三条不可协商的行为规则也写在分发路由之前：永远派生、永不转介（不要让用户自己去开 Claude Code）、先解析仓库（用户点名仓库就设置工作目录，不知道就问）、Autoplan 端到端跑完（派生后让它跑完整条流水线，再在聊天里回报结果，用户永远不需要离开 Telegram）。

二、gstack-plan 流水线全解：原文五步契约

openclaw/gstack-plan-CLAUDE.md 全文仅约 20 行，但每一步都是硬性契约。模板开头声明了它的注入时机与方式：

Injected by the orchestrator when the user wants to plan a Claude Code project. Append to existing CLAUDE.md.

注意「Append」——这与 docs/OPENCLAW.md 中的 CLAUDE.md 冲突处理规则一致：当目标仓库已有 CLAUDE.md 时，以新增小节的形式追加，绝不替换仓库既有的项目说明。

Step 1：读取 CLAUDE.md，理解项目上下文

流水线第一步是读 CLAUDE.md 并理解项目上下文。这一步与 gstack-full 的第一步完全一致（见 openclaw/gstack-full-CLAUDE.md），体现了 gstack 的基本假设：项目根的 CLAUDE.md 是会话的首要上下文来源，规划必须建立在项目既有约定之上，而不是凭空设计。

Step 2：运行 /office-hours 产出设计文档

第二步要求运行 /office-hours，产出一份包含**问题陈述（problem statement）、前提假设（premises）、备选方案（alternatives）**的设计文档。

/office-hours 技能的完整定义在 office-hours/SKILL.md，值得注意的实现细节：

• 它自我定位为一个「YC office hours partner」，职责是在提出任何解决方案之前确保问题被真正理解，并根据构建者类型切换风格——创业公司创始人得到尖锐的追问，个人开发者得到热情的协作者；
• 它有一条硬性门（HARD GATE）：不得调用任何实现类技能、不得写任何代码、不得搭建任何脚手架——「你唯一的产出是一份设计文档」；
• Startup 模式使用「六个强问题」（six forcing questions）暴露需求现实、现状、绝望的具体性、最窄切入点、观察与未来适配性；Builder 模式则做设计思维头脑风暴；
• 它的 frontmatter 中声明了 gbrain 上下文查询（prior office-hours sessions、builder profile、design-doc-history、prior eureka moments），即如果配置了 gbrain 记忆库，提问前会先加载项目相关的结构化上下文，避免重复提问已知答案。

gstack 还为 OpenClaw 提供了对话端的原生适配版本 openclaw/skills/gstack-openclaw-office-hours/SKILL.md（「Product interrogation, 6 forcing questions」），但 Plan 档真正驱动的是 Claude Code 里的完整版 /office-hours。

Step 3：运行 /autoplan 做全量评审

第三步是运行 /autoplan 评审设计，评审构成是 CEO + 工程 + 设计 + DX 四轮评审外加 Codex 对抗（codex adversarial）。

/autoplan 的完整实现见 autoplan/SKILL.md，它是 gstack 的「自动评审流水线」：从磁盘读取 CEO、设计、工程、DX 四份评审技能文件并逐个以完整深度执行，唯一区别是中间的 AskUserQuestion 由 6 条决策原则自动裁决，而品味型决策（taste decisions）留到最终审批门（Final Approval Gate）一次性呈现。理解 Plan 档的第三步，关键在于理解 /autoplan 的这几个机制：

1. 严格串行执行：阶段必须按 CEO → Design → Eng → DX 顺序执行，前一阶段完整产出（写盘）后才能进入下一阶段，禁止并行——每个阶段都构建在前一个阶段之上。各阶段的完整定义分别位于 autoplan/sections/ceo-phase.md、autoplan/sections/design-phase.md、autoplan/sections/eng-phase.md、autoplan/sections/dx-phase.md。其中 Design 阶段仅在 Phase 0 检测到 UI 范围时运行，DX 阶段仅在检测到面向开发者的范围时运行。

2. 6 条决策原则（The 6 Decision Principles），这是「自动裁决」的裁决依据：

   • 选择完整性（Choose completeness）——做完整的东西，选覆盖更多边界情况的方案；
   • 烧干湖泊（Boil lakes）——修复「爆炸半径」内（本计划修改的文件 + 直接 importer）的所有问题；在爆炸半径内且小于 1 天 CC 工作量（< 5 个文件、无新基础设施）的扩张自动批准；
   • 务实（Pragmatic）——两个方案解决同一问题时选更干净的，5 秒决策而非 5 分钟；
   • DRY——与既有功能重复就拒绝，复用已存在的；
   • 显式优于巧妙（Explicit over clever）——10 行显而易见的修复优于 200 行抽象；
   • 偏向行动（Bias toward action）——合并 > 评审循环 > 陈旧 deliberation；标记顾虑但不阻塞。
   • 冲突时有上下文相关的裁定：CEO 阶段由 P1 + P2 主导，Eng 阶段由 P5 + P3 主导，Design 阶段由 P5 + P1 主导。

3. 决策分类与双声（Dual Voices）：每个自动决策都被分类为 Mechanical（显然只有一个正确答案，静默自动裁决）、Taste（合理的人会意见分歧，自动裁决带推荐但上移到最终门）、或 User Challenge（两个模型一致认为用户陈述的方向应当改变——这类永不自动裁决）。每个阶段的评审都由「Codex + Claude subagent」双声并行跑，产出共识表（consensus table）；这正是 Plan 档文档中「codex adversarial」的出处。Phase 0.5 还会做 Codex 认证与版本预检，Codex 不可用时降级为仅 Claude 单声并在产物中标注。

4. 决策审计跟踪（Decision Audit Trail）：每次自动裁决都以一行记录增量追加到计划文件（## Decision Audit Trail 表格：Phase / Decision / Classification / Principle / Rationale / Rejected），让审计落在磁盘上而不是堆积在对话上下文里。

5. Pre-Gate 校验与最终审批门：进入最终门之前有一份按阶段划分的输出校验清单（前提挑战、错误与救援登记表、失败模式登记表、「NOT in scope」章节、架构 ASCII 图、测试计划落盘产物、各阶段共识表等），缺任何一项都要回补；最终门呈现「计划摘要、决策统计、User Challenges、品味型选择、各评审得分、跨阶段主题、被推迟到 TODOS.md 的项、聚合后的实现任务列表」，用户可在「按现状批准 / 带覆写批准 / 追问 / 修订 / 拒绝」五个选项中裁决。

6. Codex 文件系统边界：所有发给 Codex 的提示词都必须前缀一段边界指令，禁止它读取或执行磁盘上的 SKILL.md 文件——防止 Codex 发现 gstack 技能定义后去执行其指令，而不是评审计划。

Step 4：把最终评审过的计划落盘

第四步是 Plan 档最具体的产物契约：

Save the final reviewed plan to a file the orchestrator can reference later. Write it to: plans/<project-slug>-plan-<date>.md in the current repo. Include the design doc, all review decisions, and the implementation sequence.

三个要点：

• 命名规范：plans/<project-slug>-plan-<date>.md，写在当前仓库内（而不是 ~/.gstack/ 私有目录）——这是有意为之：计划要成为编排器之后可以引用、且团队可见的产物，落在仓库里才能被 git 跟踪、被后续会话和队友读取；
• 内容下限：文件必须同时包含设计文档（来自 Step 2）、全部评审决策（来自 Step 3 的各阶段共识表与审计跟踪）以及实现顺序（implementation sequence，即 /autoplan 最终门聚合出的任务列表）。三者缺一，落盘文件就无法支撑后续实现会话；
• 可引用性：「a file the orchestrator can reference later」——文件路径本身就是下一步的交接句柄。

Step 5：向编排器回报四件事

第五步规定了回报给编排器的四项固定内容：

1. 计划文件路径（Plan file path）；
2. 一段话总结设计内容以及关键决策（one-paragraph summary of what was designed and the key decisions）；
3. 已接受的 scope 扩张列表（List of accepted scope expansions, if any）——对应 /autoplan 中「Boil lakes」原则自动批准的爆炸半径内扩张；
4. 推荐下一步（Recommended next step），通常是：派生一个新的 gstack-full 会话去实现。

这四项回报与 docs/OPENCLAW.md 中对 Plan 档的描述一一对应：「Report back: plan path, summary, key decisions, recommended next step」。

三、两条硬约束：只规划、不实现 + 编排器负责持久化

模板最后两行是整个 Plan 档的护栏：

Do not implement anything. This is planning only. The orchestrator will persist the plan link to its own memory/knowledge store.

第一行把 Plan 会话的输出边界钉死：这个会话的交付物只有计划文件与回报，任何代码实现都属于越界。这与它调用的两个技能的自约束是自洽的——/office-hours 有 HARD GATE（只产出设计文档），/autoplan 在 plan mode 下的唯一合法编辑就是写计划文件。

第二行定义了跨系统责任边界：计划链接的持久化不是 Claude Code 会话的职责，而是编排器的职责。docs/OPENCLAW.md 进一步说明：编排器把计划链接存进它自己的记忆存储（brain repo、知识库，或 AGENTS.md 中配置的任意存储）；「当用户准备好构建时，派生一个指向已保存计划的 FULL 会话」。也就是说，Plan 档刻意把「规划」与「实现」拆成两个生命周期独立的会话，中间靠落盘的计划文件 + 编排器记忆解耦。

四、与 gstack-lite / gstack-full 的对照：三档模板的分工

Plan 档模板与另外两份注入模板构成递进关系，对照阅读能快速理解每档的边界：

模板	档位	内容	交付物
openclaw/gstack-lite-CLAUDE.md	Medium	约 15 行的规划纪律：改前必读每个文件、写 5 行计划（what/why/files/test/risk）、歧义裁决原则、完成前自审、完成报告	直接完成的多文件修改
openclaw/gstack-full-CLAUDE.md	Full	完整功能流水线：读 CLAUDE.md → /autoplan 评审方案 → 实现 → /ship 出 PR → 回报 PR URL 与决策	带测试、changelog、版本号的 PR
openclaw/gstack-plan-CLAUDE.md	Plan	全量评审关卡（Full Review Gauntlet）：/office-hours → /autoplan → 落盘计划 → 回报	计划文件 + 四项回报，零实现

gstack-full 的完整流水线为：读 CLAUDE.md → 跑 /autoplan 评审方案 → 实现已批准的计划 → 跑 /ship 创建 PR → 回报 PR URL、交付内容与不确定项，并且「在 PR 准备好评审之前不向人要输入」。可以看到 Plan 档恰好是 Full 档的「前置半场」：Plan 会话把设计与评审做完并落盘，Full 会话从「实现已批准的计划」开始，两者共享同一套评审基础设施，但生命周期分离。

五、模板的生成与维护方式

三份 CLAUDE.md 模板都不是手维护的终点。从源码结构看：

• 源模板位于 openclaw/templates/gstack-plan-CLAUDE.md（以及 gstack-full、gstack-lite 对应文件），openclaw/ 目录下的成品文件由生成管线产出；
• docs/OPENCLAW.md 明确说明：「所有产物都位于 openclaw/ 目录，由 bun run gen:skill-docs --host openclaw 生成」；对 gstack 开发者而言，./setup --host openclaw 会输出这份集成文档；
• OpenClaw 用户侧的安装路径则是：告诉 OpenClaw agent 「install gstack for openclaw」，agent 会依次完成——把 gstack-lite CLAUDE.md 装入编码会话模板、安装 4 个原生方法论技能、把分发路由加入 AGENTS.md、用一次测试派生验证；
• 派生会话检测：当 Claude Code 运行在 OpenClaw 派生的会话中时，OPENCLAW_SESSION 环境变量会被设置（在 sessions_spawn 中通过 env: { OPENCLAW_SESSION: "1" } 传入）。gstack 检测到它后自动调整行为：跳过交互式提示（自动选择推荐项）、跳过升级检查与遥测提示、聚焦任务完成与文字回报——这正是 Plan 档能在无人值守的派生会话中端到端跑完的前提。office-hours/SKILL.md 的前置脚本中就有 [ -n "$OPENCLAW_SESSION" ] && echo "SPAWNED_SESSION: true" 的检测逻辑。

此外，docs/OPENCLAW.md 还列出了「我们不做的事」清单，划清了这条轻量协议的边界：不做分发守护进程（ACP 负责派生）、不做 Clawvisor 中继、不做双向 learnings 桥（brain repo 即知识存储）、不做 JSON schema 或协议版本化、不从 gstack 输出 SOUL.md、不做完整技能移植（编码技能保持 Claude Code 原生）。

六、小结：Plan 档的完整数据流

把以上证据串起来，gstack-plan 档端到端的数据流是：

1. 触发：用户在 Telegram/聊天中说「帮我规划一个项目」，OpenClaw 编排器按决策启发式判定为 Plan 档；
2. 派生：sessions_spawn(runtime: "acp")，prompt 为 gstack-plan 模板全文 + 任务描述，环境带 OPENCLAW_SESSION: "1"；
3. 注入：模板追加到目标仓库 CLAUDE.md（已有内容保留）；
4. 执行：Claude Code 读 CLAUDE.md → /office-hours 产出含问题陈述、前提、备选方案的设计文档（HARD GATE：不写代码）→ /autoplan 以 CEO/Design/Eng/DX 串行阶段 + Codex/Claude 双声做全量评审，中间问题由 6 决策原则自动裁决，品味型决策与 User Challenge 上移到最终门；
5. 落盘：评审过的最终计划写入仓库内 plans/<project-slug>-plan-<date>.md，含设计文档、全部评审决策、实现顺序；
6. 回报：会话回报计划路径、一段话总结、已接受的 scope 扩张、推荐下一步；
7. 持久化：编排器把计划链接存入自己的记忆/知识存储；
8. 交接：用户准备实现时，编排器派生一个新的 Full 档会话（注入 gstack-full），指向已保存的计划执行「/autoplan（增量）→ 实现 → /ship」，形成 Plan → Full 的两段式闭环。

整套设计的核心取舍是用「会话拆分 + 磁盘计划文件 + 编排器记忆」替代了任何守护进程、协议版本化或双向同步机制：提示词文本即协议，git 仓库即交接介质，五档路由即复杂度分级。对想在 OpenClaw（或任何 ACP 风格编排器）上复用 gstack 规划纪律的开发者，openclaw/agents-gstack-section.md 中「Copy it into your OpenClaw AGENTS.md」的即用片段与本文所述的五档契约，就是全部需要接入的内容。