gstack-plan: Full Review Gauntlet

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

两个关键约束值得注意：

1. **注入时机**：当用户表达"帮我为一个 Claude Code 项目做规划"（例如 "Help me plan a Claude Code project"）时，由编排器注入；
2. **注入方式**：`Append to existing CLAUDE.md`——追加而非替换。这一点与 [docs/OPENCLAW.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/docs/OPENCLAW.md?utm_source=gitcode_repo_files) 中 "CLAUDE.md collision handling" 一节的规则一致：当目标仓库已有 CLAUDE.md 时，必须把 gstack-plan 作为新章节**追加**到现有指令之后，绝不覆盖仓库既有的项目约定。

从集成设计看（[docs/OPENCLAW.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/docs/OPENCLAW.md?utm_source=gitcode_repo_files) "Architecture" 一节），gstack 与 OpenClaw 之间**没有守护进程、没有 JSON-RPC、没有协议版本化**，"prompt is the bridge"——一段纯文本提示词就是整个集成协议。OpenClaw 的 ACP runtime 负责原生 spawn Claude Code 会话，gstack 则提供让会话更可靠的规划纪律与方法论。gstack-plan 正是这套"提示词即协议"思路在 Plan 层的具象化产物。

## 二、Planning Pipeline：五步完整规划流水线

模板的核心是 `## Planning Pipeline` 一节，共五步。以下完整继承模板原文并逐步展开。

### 步骤 1：读取 CLAUDE.md，理解项目上下文

> 1. Read CLAUDE.md and understand the project context.

规划不能凭空开始。Claude Code 会话启动后首先阅读目标仓库的 CLAUDE.md（其中已追加了 gstack-plan 段），从而继承项目的既有约定、技术栈与领域上下文。这一步保证后续设计文档与评审讨论都建立在"项目真实状态"而非模型臆想之上。

### 步骤 2：运行 /office-hours 产出设计文档

> 2. Run /office-hours to produce a design doc (problem statement, premises, alternatives).

`/office-hours` 是 gstack 的产品拷问（product interrogation）技能，负责产出一份设计文档，必须包含三个要素：

- **problem statement**（问题陈述）——到底要解决什么问题；
- **premises**（前提假设）——方案依赖哪些未经证实的假设；
- **alternatives**（备选方案）——还存在哪些替代路径。

这一设计文档是后续所有评审的评审对象（review target），也是最终计划文件的第一部分原料。

### 步骤 3：运行 /autoplan 对设计文档做完整评审

> 3. Run /autoplan to review the design (CEO + eng + design + DX reviews + codex adversarial).

`/autoplan` 是 gstack 的自动规划评审技能，模板明确要求其跑完**完整评审阵容**（这也是标题 "Full Review Gauntlet" 的由来）：

| 评审角色 | 关注点 |
|---|---|
| CEO review | 战略价值、范围取舍（是否值得做、边界在哪） |
| Eng review | 架构合理性、技术风险、实现顺序 |
| Design review | 交互与信息架构 |
| DX review | 开发者体验、API 表面 |
| codex adversarial | 由 Codex 模型充当"对抗评审者"，专门挑战上述结论 |

从源码结构看，gstack 仓库对这些评审的产出质量有严格的回归测试约束：例如 [test/codex-e2e-plan-format.test.ts](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/test/codex-e2e-plan-format.test.ts?utm_source=gitcode_repo_files) 就专门固定了 `/plan-ceo-review` 与 `/plan-eng-review` 在 Codex CLI 下发起 AskUserQuestion 时的输出格式（必须含 RECOMMENDATION 推荐行、ELI10 通俗解释段、kind/coverage 差异化判定等），确保评审环节在真实会话中不会退化成"裸选项列表"。

### 步骤 4：把评审后的最终计划落盘为文件

> 4. 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`（当前仓库内，如 `plans/my-project-plan-2026-09-06.md`）；
- **必须包含三部分**：
  1. 设计文档（步骤 2 的产物）；
  2. 所有评审决策（步骤 3 各角色评审的结论与取舍）；
  3. 实现顺序（implementation sequence）。

落盘的意义在于：计划从"会话内的一次性上下文"变成"仓库中可被后续会话引用的持久资产"。编排器之后可以按这个路径直接引用它，而不必依赖任何会话记忆。

### 步骤 5：向编排器汇报

> 5. Report back to the orchestrator:
>    - Plan file path
>    - One-paragraph summary of what was designed and the key decisions
>    - List of accepted scope expansions (if any)
>    - Recommended next step (usually: spawn a new session with gstack-full to implement)

汇报内容固定为四项，每一项都有明确的下游用途：

| 汇报项 | 用途 |
|---|---|
| 计划文件路径 | 供编排器持久化到其记忆/知识库（brain repo 或 AGENTS.md 中配置的知识存储） |
| 一段话摘要（设计了什么 + 关键决策） | 让用户无需打开计划文件即可在聊天窗口（如 Telegram）里理解全貌 |
| 已接受的扩围清单（scope expansions） | 透明化：评审过程中被批准纳入范围的扩张项，避免"计划悄悄变大" |
| 建议的下一步 | 通常是：**spawn 一个带 gstack-full 的新会话去实现** |

## 三、"只规划、不实现"的硬边界与 FULL 层交接

模板末尾有两条收尾约束，是整个 Plan 层的设计红线：

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

**Plan 层会话绝对不写实现代码。** 它的工作在"保存计划文件 + 向编排器汇报"时即告终结。实现发生在下一次会话，通过 gstack-full 模板完成。对照 [openclaw/templates/gstack-full-CLAUDE.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/openclaw/templates/gstack-full-CLAUDE.md?utm_source=gitcode_repo_files) 可以看到两个模板的分工边界非常清晰：

- **gstack-plan**：`/office-hours` → `/autoplan` → 保存计划文件 → 汇报；不含 `/ship`，不实现；
- **gstack-full**：`/autoplan` → **implement the approved plan** → `/ship`（产出带测试、changelog、版本号递增的 PR）→ 汇报 PR URL 与决策。

[openclaw/agents-gstack-section.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/openclaw/agents-gstack-section.md?utm_source=gitcode_repo_files) 中 PLAN 分派段明确描述了这条交接链：

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.

即：编排器把计划链接持久化后，等用户准备好动手时，再 spawn 一个**新的 FULL 会话并指向该计划文件**——计划与实现在两个独立会话中解耦，各自拥有干净的上下文预算。

## 四、Plan 层如何被触发：分派路由与注入机制

### 4.1 五级分派路由

[docs/OPENCLAW.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/docs/OPENCLAW.md?utm_source=gitcode_repo_files) 给出了 OpenClaw 在 spawn 时决定注入哪一层 gstack 支持的分派表，gstack-plan 处于其中的 **Plan 层**：

| 层级 | 触发场景 | 注入内容 |
|---|---|---|
| Simple | 单文件修改、错别字、配置变更 | 不注入任何 gstack 上下文 |
| Medium | 多文件功能、重构 | 追加 gstack-lite CLAUDE.md |
| Heavy | 需要特定 gstack 技能（/cso、/review、/qa） | "Load gstack. Run /X" |
| Full | 完整功能、目标、项目 | 追加 gstack-full 流水线 |
| **Plan** | **"Help me plan a Claude Code project"** | **追加 gstack-plan 流水线** |

配套的判定启发式（Decision heuristic）中，Plan 层对应一条规则：**"用户想为 Claude Code 规划某事、但还不实现"（Does the user want to PLAN something for Claude Code without implementing yet?）→ Plan**。它与 Full 层的区分点在于用户意图是"先设计"还是"直接建"：Full 是 feature/project/objective 的执行，Plan 是执行前的规划。

### 4.2 具体 spawn 方式

[openclaw/agents-gstack-section.md](https://gitcode.com/GitHub_Trending/gs/gstack/blob/9da6692930db209e8632e8da3d5e5b5995d8af9c/openclaw/agents-gstack-section.md?utm_source=gitcode_repo_files) 给出了可直接照做的 spawn 指令形态：

sessions_spawn(runtime: "acp", prompt: "\n\n")