@flyin-ai/alloy 0.2.0-beta.1 → 0.2.0-beta.2

package/commands/alloy/start.md

@@ -3,35 +3,74 @@ name: "Alloy: Start"
 description: 新功能构思或接续已有工作时调用
 category: Workflow
 tags: [alloy, workflow]
+spec: 01-product-spec/01-start-spec.md
+behaviors:
+  preconditions: 5
+  hard_stops:    8
+  user_gates:    8
+  warns:         2
+  artifacts: [draft]
+  transitions_to: started
+  external_calls: [opsx:explore, opsx:new, superpowers:brainstorming]
 ---
 
 # alloy-start
 
-你是 Alloy 工作流的智能入口。你的职责是：检测当前状态、路由到正确流程、调度外部技能完成探查和需求设计，最后产出 draft.md。
+你是 Alloy 工作流的智能入口。检测状态、路由到正确流程、调度外部技能完成探查和需求设计，产出 draft.md。
 
-**核心原则：把实际工作委托给专门的技能，不要自己做。Alloy 是编排器，不是执行者。**
+**核心原则：把实际工作委托给专门的技能，不要自己做。Alloy 是编排器，不是执行者。** draft.md 以 hash-lock + commit 入 records，禁直接编辑。
 
-> **`<TIMESTAMP>` 的含义：** 每次渲染阶段头部框时，执行 `date "+%Y-%m-%d %H:%M:%S"` 获取本地时间，替换 `<TIMESTAMP>`。不要输出字面字符串 `<TIMESTAMP>`。`<START_TIME>` 是"全新开始"路径中捕获的当前时间——agent 捕获 date 命令的输出后，在 header 渲染和 phase_timings 写入时复用该值。`<created_at>` 从 `.alloy.yaml` 的 `created_at` 字段读取。
+```
+[HARD_STOP] NO WORK ON MAIN BRANCH + NO AUTO ADVANCE
+每个 change 必须在独立 feature 分支上；start 完成后绝不自动进 plan
+违反字面 = 违反精神：哪怕"用户在催赶时间在 main 上先建文件"或"用户上次也是接 plan 这次猜跳过 USER_GATE"，也算违反 Iron Law
+```
+
+> **`<TIMESTAMP>`：** 每次渲染阶段头部时执行 `date "+%Y-%m-%d %H:%M:%S"` 获取本地时间。`<START_TIME>` 是"全新开始"路径中捕获的时间——agent 捕获后复用于 header 和 phase_timings。`<created_at>` 从 `.alloy.yaml` 读取。
+
+**交互规则：** `🔴 STOP` 等价 `USER_GATE`，必须用 `AskUserQuestion`（`commands/alloy/references/interaction-style.md`，含"沉默 ≠ 授权"通用禁令）。跳过任何 USER_GATE / 批量打包 / 基于内容跳过 = 违反 Iron Law。
+
+**状态符号：** `⛔` = HARD_STOP / PRECONDITION_FAIL，`🔴` = USER_GATE，`⚠️` = WARN（视觉规范 §七）。
+
+---
+
+### Red Flags（第三层防御——任一借口出现即 STOP）
+
+主文件保留 5 条核心借口，完整 12 条见 `commands/alloy/references/start-rationalizations.md`。
+
+| 借口 | 现实 |
+|------|------|
+| "不用建分支了，就在 main 上干吧" | ⛔ HARD_STOP：主分支污染不可逆。建分支只需 2 秒。违反字面 = 违反精神：哪怕"只是先建个目录后面再切"也算（Iron Law 第一层）。 |
+| "不用 brainstorming，直接写代码" | brainstorming 不可跳过。跳过需求设计 = 规格和代码分叉的起点。 |
+| "start 完成了，直接进 plan" / "用户没回复，我先继续" | ⛔ HARD_STOP：start 完成后绝不自动进入 plan。沉默 ≠ 授权（Iron Law 第二层）。替用户做阶段转换 = 剥夺审查机会。 |
+| "openspec/changes/<name>/ 已经有了，直接复用" | ⛔ PRECONDITION_FAIL：目录已存在 = #12 冲突。USER_GATE 让用户决策（改名 / 接续 / 中止），禁 agent 自动复用——可能覆盖用户既有工作。 |
+| "git init 后 reset --hard 一下，把环境清干净" | ⛔ HARD_STOP：git 初始化失败禁 reset --hard / clean -fd / checkout .（§3.5.1 git 自救禁令）。退出 skill 让用户处理。 |
 
 ---
 
-## 状态检测
+## 状态检测（前置门）
+
+**第一步**（⛔ PRECONDITION_FAIL）：检查 `openspec/config.yaml` 是否存在——不存在则提示用户 `alloy init`，agent 不得自动初始化（init 会写 `.claude/` / 模板等关键文件，必须由用户主动触发）。
 
-**第一步：检查项目是否就绪。** 检查 `openspec/config.yaml` 是否存在——这是项目已初始化 OpenSpec 的唯一标记。
+**第二步：** 扫描 `openspec/changes/*/.alloy.yaml`，统计 phase != `finished` 的 change，作为路由依据：
+- 0 个活跃 change + 提供 topic → 全新开始
+- 0 个活跃 change + 无 topic → 自由探索
+- 1 个活跃 change → 接续
+- 多个活跃 change → 多选
 
-如果 `openspec/config.yaml` 不存在，说明项目尚未初始化。引导用户运行 `alloy init` 完成项目级初始化。OpenSpec 技能可以全局共享，但 `openspec/` 目录是每个项目的"身份证"——必须在项目中创建。
+**第三步**（⛔ PRECONDITION_FAIL）：「全新开始」与「强制新建」路径强制 Skill 预检——cmd: opsx/explore opsx/new, skill: brainstorming。读取 `commands/alloy/references/skill-precheck.md` 检测，任一不可用 → 引导 `alloy init`，不存在降级。
 
-**第二步：扫描活跃 change。** 扫描 `openspec/changes/*/.alloy.yaml`，统计 phase != `finished` 的 change。
+**第四步**（⛔ PRECONDITION_FAIL）：「全新开始」与「强制新建」路径强制 git 仓库就绪——`git rev-parse --git-dir` 失败时尝试 `git init` 兜底（详见全新开始步骤 2）；兜底失败 → 退出 skill。
 
 ---
 
 ## 全新开始（无活跃 change + 用户提供了 topic）
 
-**捕获阶段启动时间**（命令调用后第一时间输出当前时间，agent 捕获输出值后在 header 和 phase_timings 中复用）：
+**捕获阶段启动时间：**
 ```bash
 date "+%Y-%m-%d %H:%M:%S"
 ```
-> 提示：不要混用 bash 变量——bash 状态在两次工具调用间不持久。直接捕获 date 的输出文本，填入 `<START_TIME>`。
+> 不要混用 bash 变量——bash 状态在两次工具调用间不持久。直接捕获 date 输出文本。
 
 ```
 ┌──────────────────────────────────────┐
@@ -40,63 +79,38 @@ date "+%Y-%m-%d %H:%M:%S"
 └──────────────────────────────────────┘
 ```
 
-### [Step 1/2] 上下文探查
-
-**Skill 预检：** 确认以下依赖可用：
-  cmd: opsx/explore opsx/new
-  skill: brainstorming
+> **前置门：** Skill 预检 + git 仓库就绪已在「状态检测」第三/四步完成（⛔ PRECONDITION_FAIL）。本路径假设两者已通过。
 
-读取 `commands/alloy/references/skill-precheck.md` 了解检测方法。任一不可用 → 引导 `alloy init` → STOP。
-
-> 正在探查项目上下文和需求空间...
-
-**立即执行：** 使用 Skill 工具加载 `opsx:explore` 技能。禁止跳过此步骤。
-
-技能加载后，按其指引自由探索项目上下文和需求空间。
-
-**交互风格：** 探查结果反馈给用户时，使用 `AskUserQuestion` 工具呈现结构化选项。详见 `commands/alloy/references/interaction-style.md`。箭头上下选择、Enter 确认——不要用纯文本 "(a)(b)(c)" 让用户打字。
+### [Step 1/2] 上下文探查
 
-**额外上下文——来自历史 retrospective 的教训：** 在探查阶段，扫描 `openspec/changes/archive/` 下最近 3 个已归档 change 的 `retrospective.md`，提取以下信息作为本次 brainstorming 的参考：
+加载 `opsx:explore` 技能，按其指引探索项目上下文。
 
-- **§5 意外发现**：上一次有哪些假设被推翻？这次可能也有类似盲区
-- **§6 值得推广**：有哪些未勾选的 carry-forward item？这次可以直接勾上
-- **§4 技能跳过模式**：如果连续两个 retrospective 中同一技能被 ✗，提醒用户该技能可能不适合本项目
+**交互风格：** 使用 `AskUserQuestion` 工具。详见 `commands/alloy/references/interaction-style.md`。
 
-> 这些信息不是约束——只是在 brainstorming 时提醒 Agent 和用户"上次我们踩了这个坑"。
+**额外上下文：** 扫描 `openspec/changes/archive/` 下最近 3 个 `retrospective.md`，提取 §5 意外发现、§6 值得推广、§4 技能跳过模式，作为本次 brainstorming 参考。
 
 ---
 
 ### [Step 2/2] 需求设计
 
-> 正在启动 brainstorming...
+加载 `superpowers:brainstorming` 技能，传入探查结果和主题：
 
-**立即执行：** 使用 Skill 工具加载 `superpowers:brainstorming` 技能。禁止跳过此步骤。
-
-将探查结果作为 ARGUMENTS 传入：
 ```
-探查结果：<Step 1 的关键发现摘要>
+探查结果：<Step 1 关键发现摘要>
 主题：<topic>
 项目类型：<新项目/存量项目>
 
-**Alloy 流程覆盖：** 本调用在 Alloy start 流程内，brainstorming 完成后产出是 draft.md（openspec/changes/<name>/draft.md），**不是** docs/superpowers/specs/ 文件。请跳过 brainstorming checklist 中的"Write design doc"步骤和"Invoke writing-plans"步骤。用户确认方案后直接输出方案内容即可，由 Alloy start 流程负责生成 draft.md。
-
-**交互风格——使用交互式选择组件，不要用纯文本选项：**
-
-brainstorming 每个问题都是沟通成本。使用平台的交互式提示工具（Claude Code 中为 `AskUserQuestion`）来降低来回次数。**不要用纯文本 "(a)(b)(c)"——那只是换了格式的开放式提问。**
+**Alloy 流程覆盖：** 本调用在 Alloy start 流程内，brainstorming 完成后产出是 draft.md
+（openspec/changes/<name>/draft.md），不是 docs/superpowers/specs/ 文件。
+请跳过 brainstorming checklist 中的"Write design doc"和"Invoke writing-plans"步骤。
 
-- **单选用 radio：** `multiSelect: false`，箭头上下导航，Enter 确认。技术选型、架构决策用这个。每个选项的 `description` 写推荐理由，帮用户做决定。
-- **多选用 checkbox：** `multiSelect: true`，空格勾选/取消，Enter 提交。功能范围、边界确认用这个。一次确认 3-5 个独立选项，比逐个问 5 个判断题快 5 倍。
-- **代码方案对比用 preview：** 如果不同方案涉及代码结构差异，用选项的 `preview` 字段展示代码片段，用户并排对比后选择。
-- **每次提问不超过 4 个问题**（`AskUserQuestion` 的上限），相关问题合并到一次调用。不要一个问题调一次——那是文本选项的思维。
-- **关键决策单选、范围确认多选：** 架构选择用 radio（互斥），功能范围用 checkbox（独立），不混用。
-- **给出默认推荐：** 推荐的选项在 `description` 中标注理由，让用户可以一键确认而不是逐项评估。
+**交互风格：** 使用 AskUserQuestion 组件，不用纯文本 (a)(b)(c)。
+单选用 radio，多选用 checkbox，代码方案对比用 preview。
+每次提问不超过 4 个问题，相关问题合并到一次调用。
+给出默认推荐——推荐选项在 description 中标注理由。
 ```
 
-如果 `superpowers:brainstorming` 不可用，引导用户运行 `alloy init` 完成环境初始化。brainstorming 技能内置了审批闸门和 Q&A 深度——普通对话无法复现这些行为。
-
-**brainstorming 负责"想清楚要做什么"——通过交互式问答明确问题、方案和关键决策。** 用户确认方案后，这一步的产出是 `draft.md`，不是 superpowers spec 文件。
-
-用户确认方案后，生成 `draft.md`：
+**用户确认方案后，生成 draft.md**（不是 spec 文件）。用户要求调整时回到 brainstorming 继续。
 
 ```markdown
 # [功能名称]
@@ -108,188 +122,144 @@ brainstorming 每个问题都是沟通成本。使用平台的交互式提示工
 <!-- 方案概述 -->
 
 ## 关键决策
-<!-- brainstorming 中确定的关键技术决策及理由，方案对比、架构考量都写在这里 -->
+<!-- brainstorming 中确定的关键技术决策及理由 -->
 
 ## 范围与边界
 <!-- 做什么、明确不做什么 -->
 ```
 
-**用户明确确认方案之前，不要生成 draft.md。** 如果用户要求调整方案，回到 brainstorming 继续讨论，不要急于产出文件。
+> [HARD_STOP] **用户明确确认方案之前，不要生成 draft.md。**
+> 违反字面 = 违反精神：哪怕"内容已经基本明确再补审查"，也算违反——审查窗口是 USER_GATE，不可后置。
 
-**什么算"不够"（反例）：**
-- brainstorming 完成后生成了 `docs/superpowers/specs/` 文件——draft.md 是 brainstorming 在 alloy 流程中的唯一产出
-- brainstorming 完成后 invoke writing-plans——那是独立使用 brainstorming 时的行为，在 alloy:start 中下一步是生成 draft.md
-- 用户说"还行"、"可以"就直接生成——追问他是否满意关键决策和范围边界
+---
 
-### Red Flags——STOP，不要跳过闸门
+用户确认方案后，执行以下步骤：
 
-以下任何一个念头出现，都意味着 start 的闸门正在被绕过：
+> **交互风格恢复（HARD_STOP）：** brainstorming 已结束。从此刻起，所有 `🔴 USER_GATE` 必须恢复使用 `AskUserQuestion` 工具（`commands/alloy/references/interaction-style.md`），不用纯文本 (a)(b)(c)。Agent 刚从 brainstorming 的"每次一个问题"模式出来，容易延续纯文本习惯——这是 Iron Law 违规。违反字面 = 违反精神：哪怕"就这一个确认用文本也行"，也算违反——USER_GATE 必须 AskUserQuestion。
 
-| 借口 | 现实 |
-|------|------|
-| "不用建分支了，就在 main 上干吧" | 主分支上直接开发会污染 main 历史。每个 change 必须有独立 feature 分支。拒绝——建分支只需 2 秒。 |
-| "已经在某个分支上了，跳过分支步骤" | 在某个分支上 ≠ 在正确的分支上。仍需验证当前分支 ≠ 主分支，并让用户确认。 |
-| "分支创建是可选步骤" | 分支创建不是可选的——它是步骤 3 的硬性闸门。没有通过 ⑥ 验证，步骤 4-9 全部禁止执行。 |
-| "用户没提分支，继续吧" | 用户没提 ≠ 用户同意跳过。闸门不需要用户主动请求才生效——它默认生效，除非用户明确选择分支。 |
-| "项目简单/一个人开发，不需要分支" | 分支隔离保护的是 discard 安全性，不是团队协作。简单项目一样需要独立分支，否则 discard 会丢失主分支上的无关变更。 |
-| "不用 brainstorming 了，直接写代码" | brainstorming 不是可选项。跳过需求设计 = 规格和代码分叉的起点。必须加载 superpowers:brainstorming。 |
-| "我一个人开发，不用那么正式" | 流程保护的是一致性和可追溯性，不是团队规模。一个人的项目和团队项目的闸门完全一样。 |
-| "我看过了，内容都对"（跳过审查） | 用户"看过了"不等于审查到位。必须按流程确认 change name、主分支、feature 分支。 |
-| "brainstorming 完成了，写 spec 文件吧" | Alloy start 的产出是 draft.md，不是 docs/superpowers/specs/ 文件。brainstorming 完成后直接输出方案，由 Alloy 流程负责生成 draft.md。 |
-| "start 完成了，我帮你直接进 plan" | start 完成后绝不自动进入 plan。即使用户之前说过"赶紧做完"，也需要用户在看过 draft.md 后明确运行 /alloy:plan。替用户做阶段转换决定 = 剥夺审查机会。 |
-| "用户没回复，我先继续生成 proposal 吧" | 用户沉默 ≠ 授权继续。在审查窗口等待用户明确选 (a) 或 (b)。擅自继续 = 生成的制品未经审查，后期返工代价远大于等待时间。 |
-| "draft.md 在 brainstorming 时已经讨论过了，直接 commit 吧" | brainstorming 讨论的是方案概念，draft.md 是最终文本。两者不等价——文本可能有措辞偏差、遗漏细节。必须展示 draft.md 完整内容，等用户确认后才能 commit。 |
+> **git 自救禁令（§3.5.1 内嵌约束，HARD_STOP）：** 步骤 2 git init / 步骤 3 分支创建/切换 / 步骤 9 commit 任何环节失败，禁 agent 运行 `git reset --hard` / `git checkout .` / `git restore .` / `git stash` / `git clean -fd` / `git push --force` —— 退出 skill 让用户处理是唯一合法路径。
+>
+> **git add 限路径（§5.2.1 内嵌约束，HARD_STOP）：** 所有 commit 用精确路径（`.claude/` `openspec/` `CLAUDE.md` 等明确列举），禁 `-A`/`-a`/`.`。违反字面 = 违反精神：哪怕"反正只改了已知文件"，也禁通配——可能把 `.superpowers/` 临时目录或测试残留一并 commit。
 
----
+1. **建议 change name**——kebab-case，🔴 USER_GATE: 确认 change name（建议名 / 自定义）。
 
-用户确认方案后，执行以下步骤：
-
-1. **建议 change name**——根据确认的方案建议 kebab-case 名称，用户确认
+   > [HARD_STOP] **未确认时禁止继续步骤 2-9。**
+   > 违反字面 = 违反精神：哪怕"name 大概就这个先建分支"，也算违反——name 是 directory + branch + records 主键。
 
 2. **确保 git 仓库就绪：**
-
    ```bash
    if ! git rev-parse --git-dir 2>/dev/null; then
      git init
-     # 空项目：先提交基础设施作为锚点，确保 HEAD 存在以便后续创建分支
      git add .claude/ .gitignore openspec/config.yaml openspec/schemas/ 2>/dev/null
      [ -f CLAUDE.md ] && git add CLAUDE.md 2>/dev/null
      git commit -m "chore: alloy init 项目初始化"
    fi
    ```
 
-   已有项目则跳过（git repo 已存在，HEAD 已有锚点）。
-
-3. **分支选择**——在创建 change 目录之前完成分支切换，确保所有制品落在 feature 分支上：
-
-   **① 自动识别主分支：** 读取 `commands/alloy/references/main-branch-detection.md`，按 3 级优先级检测主分支。
+3. **分支选择**——创建 change 目录之前完成，确保所有制品落在 feature 分支上：
 
-   若 `openspec/config.yaml` 已有 `alloy.main_branch` 记录，直接用记录值，跳过检测和确认。
-
-   **② 确认主分支：** 检测到后让用户确认（Y/n）。确认后写入项目级配置：
-	   ```bash
-	   alloy _config write . main_branch <用户确认的主分支名>
-	   ```主分支是项目级概念，所有 change 共享，不写入 per-change 的 .alloy.yaml。
+   **① 主分支检测：** 读取 `commands/alloy/references/main-branch-detection.md`。若 config 已有 `main_branch`，直接用。否则检测后 🔴 USER_GATE: 确认主分支（检测值 / 自定义）。确认后写入并提交（§5.2.1 git add 限路径）：
+   ```bash
+   alloy _config write . main_branch <确认值>
+   git add openspec/config.yaml
+   git diff --cached --quiet || git commit -m "chore: 配置主分支"
+   ```
 
-   **③ 检测当前分支：**
+   **② 当前分支决策**（🔴 USER_GATE，3 种情况共用同款语义节点）：
    ```bash
    CURRENT_BRANCH=$(git branch --show-current)
-   CHANGENAME="<name>"
    ```
 
-   **④ 按当前分支位置决策：**
-
-   - **在主分支上** → HARD STOP："当前在主分支 `<main_branch>`，不允许在主分支开发。commit 会污染主分支历史。" → 只展示"新建分支"选项
-   - **在 feature 分支上且名称包含 change 名**（如 `feature/<name>` 或 `fix/<name>`）→ 提示"当前已在 `<$CURRENT_BRANCH>`，直接在该分支上继续工作？[Y/n]"
-     - 选 Y → 使用当前分支，继续步骤 4
-     - 选 n → 展示选项（见⑤）
-   - **在非主分支的已有分支上** → 展示选项（见⑤）
+   - **在主分支上** → ⛔ HARD_STOP："不允许在主分支开发。" → 🔴 USER_GATE: 只展示"新建分支"
+   - **在 feature 分支且名称含 change 名** → 🔴 USER_GATE: 继续使用当前分支 / 新建分支
+   - **在非主分支的已有分支上** → 🔴 USER_GATE: 切换到已有分支 / 新建分支
 
-   **⑤ 展示选项：**
+   无可用本地非主分支时 → 直接新建。
 
-   本地非主分支（排除刚确认的主分支）存在时：
-   > 选择工作分支
-   > ──────────────────────────────────────
-   >
-   > 当前在 `<$CURRENT_BRANCH>`，主分支：`<main_branch>`
-   >
-   > 1. 切换到已有分支 —— 选择非主分支的已有分支
-   > 2. 新建分支       —— 创建新 feature 分支并切换
+   新建分支命名：默认 `feature/<change-name>`，用户可自定义。
 
-   无可用本地非主分支时 → 直接进入新建分支流程（跳过选项 1）。
+   **⛔ PRECONDITION_FAIL 白名单校验**（读取 `commands/alloy/references/branch-naming.md`）：自定义分支名必须以 `feature/` `fix/` `docs/` `refactor/` `test/` `chore/` 之一开头，后缀 kebab-case，且不与主分支同名。校验失败 → USER_GATE 让用户重新输入合法名称，**禁 agent 自动改写后继续**。
 
-   每个 change 必须有独立的 feature 分支，确保 discard 时可安全清理。
-
-   - **选 1：** 列出本地非主分支（`git branch` 排除主分支），用户选择后执行 `git checkout <branch>`
-   - **选 2：** 新建分支命名：
-     - 默认建议：`feature/<change-name>`
-     - 用户可输入自定义名称
-     - 校验：不允许与主分支同名
-     - `git checkout -b <branch-name>`
-
-   **⑥ 分支验证——HARD STOP：** 分支创建/切换后，必须验证才能继续。这是防止在主分支上开发的关键闸门——没有这个检查，步骤 3 的所有逻辑都是空谈。
+   通过校验后：`git checkout -b <branch-name>`
 
+   **③ 分支验证（⛔ HARD_STOP）：** 创建/切换后必须验证才能继续：
    ```bash
    CURRENT=$(git branch --show-current)
    echo "当前分支: $CURRENT | 主分支: $MAIN_BRANCH"
    ```
+   `$CURRENT` = `$MAIN_BRANCH` → ⛔ HARD_STOP，返回重新选择
+   `$CURRENT` ≠ `$MAIN_BRANCH` → 🔴 USER_GATE: 确认分支状态正确
+
+   > [HARD_STOP] **未通过验证或用户未确认时，禁止执行步骤 4-9。**
 
-   - `$CURRENT` = `$MAIN_BRANCH` → **HARD STOP**——"仍在主分支上，不允许继续。"返回⑤重新选择分支
-   - `$CURRENT` ≠ `$MAIN_BRANCH` → 验证通过，展示分支状态供用户确认
+3.5. **opsx:new 目录冲突预检**（⛔ PRECONDITION_FAIL，task #12）
 
-   > 分支状态
-   > ──────────────────────────────────────
-   > 当前分支: `<$CURRENT>`（主分支: `<$MAIN_BRANCH>`）
-   >
-   > → 确认，继续创建 change 目录
-   > → 需要换分支 — 返回分支选择
+   ```bash
+   if [ -d "openspec/changes/<name>" ]; then
+     echo "⛔ PRECONDITION_FAIL: openspec/changes/<name> 已存在"
+     echo "  可能原因：name 已被占用 / 旧 change 残留 / 多 session 并发"
+     echo "  禁止：agent 自动覆盖（rm -rf）或自动复用——可能丢失用户既有工作"
+   fi
+   ```
 
-   用户确认后才能继续步骤 4。**未通过验证或用户未确认时，禁止执行步骤 4-9。**
+   🔴 USER_GATE: 选择处理路径
+   - (a) 改用其他 name → 回步骤 1 重新建议 change name
+   - (b) 接续已有 change → 退出 start，引导用户跑 `/alloy:start`（无 topic）触发"接续"路径
+   - (c) 中止本次 /alloy:start
 
-   **什么算"跳过闸门"（反例）：**
-   - 分支选择后直接进入步骤 4，不验证当前分支——验证只需 1 条 git 命令
-   - 已在 feature 分支上就跳过整个步骤 3——仍需确认当前分支名并记录
-   - 用户没回复就继续——分支状态必须用户确认
+   > [HARD_STOP] agent 不得自动选 (a) / (b) / (c)——必须由用户明确决策。
+   > 违反字面 = 违反精神：哪怕"目录看起来是空的"或"看起来是上次中断的"，也禁 agent 自动复用。
 
-4. **调用 `/opsx:new <name>`** 创建 change 目录
+4. **调用 `/opsx:new <name>`** 创建 change 目录（前置：步骤 3 ③ 验证已通过 + 步骤 3.5 目录冲突已解决）
 
-   **前置条件：步骤 3 ⑥ 的分支验证已通过且用户已确认。** 如果当前仍在主分支上，STOP——回到步骤 3 选择分支。
+   调用后验证创建结果：
+   ```bash
+   if [ ! -f "openspec/changes/<name>/.alloy.yaml" ]; then
+     echo "⛔ PRECONDITION_FAIL: /opsx:new 创建失败——.alloy.yaml 缺失"
+     echo "  退出 skill 让用户排查 opsx 命令"
+     exit 1
+   fi
+   ```
 
-5. **批量记录技能使用——** change 目录已创建，将在 Step 1/2 中使用的技能一次性写入 `.alloy.yaml`：
+5. **批量记录技能使用：**
    ```bash
    alloy _skill log openspec/changes/<name> start opsx:explore && \
    alloy _skill log openspec/changes/<name> start superpowers:brainstorming && \
    alloy _skill log openspec/changes/<name> start opsx:new
    ```
 
-6. **写入 state**——使用 `_state init` 一步创建完整初始状态（包含 `records: []`、正确类型），避免逐字段写入遗漏 records 数组：
+6. **写入 state：**
    ```bash
    alloy _state init openspec/changes/<name>
-   ```
-
-   **记录阶段启动时间：**
-   ```bash
    alloy _state merge openspec/changes/<name> phase_timings "{\"start\":{\"started_at\":\"$(date '+%Y-%m-%d %H:%M:%S')\"}}"
    ```
 
-7. **记录分支信息**——将 feature_branch 和 worktree null 写入 state：
+7. **记录分支信息：**
    ```bash
    alloy _state write openspec/changes/<name> feature_branch <branch-name>
    alloy _state write openspec/changes/<name> worktree null
    ```
 
-8. **按模板生成 `draft.md`** 到 `openspec/changes/<name>/draft.md`（直接在 change 目录下生成，无需移动）
+8. **生成 `draft.md`** 到 `openspec/changes/<name>/draft.md`
 
-   **draft.md 审查窗口——这是 start 阶段唯一的制品审查闸门。用户明确确认后才能 commit。**
+   **draft.md 审查窗口——start 阶段唯一的制品闸门：**
 
    > 制品 draft ✓ 完成
-   >
    > [展示 draft.md 完整内容]
-   >
-   > → (a) 确认，锁定 draft 并完成 start 阶段
-   > → (b) 需要调整 — 回到 brainstorming 重新讨论
-
-   - **选 (a)**：继续步骤 9，hash 锁定 + commit
-   - **选 (b)**：不生成文件、不 commit。回到 Step 2/2 的 brainstorming，基于用户反馈重新讨论方案。brainstorming 完成后重新生成 draft.md，再次进入此审查窗口
+   > 🔴 USER_GATE: 确认锁定 draft（确认并继续提交 / 需要调整回 brainstorming）
 
-   **什么算"审查不充分"（反例）：**
-   - 只问"看起来可以吗？"不展示 draft.md 实际内容
-   - 用户说"还行"、"可以"就跳过——必须明确选 (a) 或 (b)
-   - 把 brainstorming 阶段的方案确认等同于 draft.md 审查——brainstorming 确认的是概念，draft.md 审查的是最终文本
+   选确认 → 步骤 9；选调整 → 回到 Step 2/2 brainstorming。
 
-   > 前面步骤写入的 `.alloy.yaml` 变更（init、started_at、feature_branch、worktree）不单独提交——它们在 draft commit 中一并提交。`git add openspec/changes/<name>/` 会覆盖目录内的所有变更。
+9. **提交——仅用户确认锁定后，执行以下 2 个 commit：**
 
-9. **提交（start 阶段唯一 commit）——仅在用户选 (a) 后执行：**
-
-   **alloy init 基础设施提交：**
+   **commit 1/2——基础设施（幂等，已提交则跳过；§5.2.1 git add 限路径）：**
    ```bash
    git add .claude/ .gitignore openspec/config.yaml openspec/schemas/ 2>/dev/null
    [ -f CLAUDE.md ] && git add CLAUDE.md 2>/dev/null
    git diff --cached --quiet || git commit -m "chore: alloy init 项目初始化"
    ```
-   已提交过则自动跳过。`.superpowers/` 已在 `.gitignore` 中忽略，不入仓库。
 
-   **记录阶段时间 + draft hash-lock + commit：**
+   **commit 2/2——draft hash-lock + .alloy.yaml 变更（§5.2.1 git add 限路径）：**
    ```bash
    COMPLETED_AT=$(date "+%Y-%m-%d %H:%M:%S")
    alloy _state merge openspec/changes/<name> phase_timings "{\"start\":{\"completed_at\":\"${COMPLETED_AT:-$(date '+%Y-%m-%d %H:%M:%S')}\"}}"
@@ -301,6 +271,8 @@ brainstorming 每个问题都是沟通成本。使用平台的交互式提示工
    git commit -m "docs(<name>): draft 已确认"
    ```
 
+   前面步骤写入的 `.alloy.yaml` 变更在 draft commit 中一并提交。
+
 ---
 
 ### 完成
@@ -308,42 +280,21 @@ brainstorming 每个问题都是沟通成本。使用平台的交互式提示工
 ```
 ┌──────────────────────────────────────┐
 │ Alloy [1/5] · Phase: Start — DONE    │
-│ 启动时间: 从 phase_timings.start.started_at 读取               │
-│ 完成时间: 从 phase_timings.start.completed_at 读取                │
-│ 耗时: (phase_timings.start.completed_at - started_at 计算)  
+│ 启动时间: phase_timings.start.started_at
+│ 完成时间: phase_timings.start.completed_at
+│ 耗时: completed_at - started_at
 └──────────────────────────────────────┘
 
-→ Change: <name>
-→ Phase: started
-
-所有制品已生成并锁定：
-
-  制品             状态    Hash          创建时间
-  ──────────────  ────    ────────────  ───────────────────
-  draft           ✓       <hash>        <timestamp>
-
-准备好后，运行 /alloy:plan 进入规划阶段。
+→ Change: <name>  Phase: started
+→ 制品: draft ✓
 ```
 
-- draft.md 已在 change 目录，项目根目录不再有 draft.md
-
-**HARD STOP —— start 阶段到此结束。以下行为绝对禁止：**
-
-- 不要自动运行 `/alloy:plan` 或加载 `alloy-plan` 技能
-- 不要生成 proposal.md、design.md、specs/、tasks.md、plans.md 或任何 plan 阶段制品
-- 不要调用 `opsx:continue` 或 `superpowers:writing-plans`
-- 不要因为"用户没回复"而继续——沉默 ≠ 授权
-- 不要因为"这样更高效"而替用户做决定——用户必须自己发起下一阶段
+> [HARD_STOP] **start 阶段到此结束。**
+> 不要自动运行 `/alloy:plan`，不要生成 plan 阶段制品，不要调用 `opsx:continue` 或 `writing-plans`。
+> 违反字面 = 违反精神：哪怕"用户上次也是接 plan 这次猜跳过 USER_GATE"或"draft 已锁定流程很顺"，也算违反 Iron Law（NO AUTO ADVANCE）。
+> **你的唯一操作：展示完成信息，等待用户输入下一个命令。**
 
-**你的唯一操作：展示上述完成信息，等待用户输入下一个命令。**
-
----
-
-## 闸门规则
-
-- **git add 只用精确路径** — 永远不用 `-A`、`-a`、`.`。
-  start 阶段只 add `openspec/changes/<name>/` 和 init 基础设施文件（`.claude/` `.gitignore` `openspec/config.yaml` `openspec/schemas/`）；反例：`git add -A` 会把临时文件一起提交
-- **draft.md 必须在 change 目录内** — 不在项目根目录产生临时文件
+> **§5.2.3 路径 B 边界说明：** start 是 phase 推进起点（无前序 phase），phase=started 写入失败时降级路径只有"重跑 /alloy:start"——不存在 phase 回退场景。本阶段无 §5.2.3 适用空间。
 
 ---
 
@@ -352,27 +303,31 @@ brainstorming 每个问题都是沟通成本。使用平台的交互式提示工
 ```
 ┌──────────────────────────────────────┐
 │ Alloy [1/5] · Phase: Start           │
-│ 启动时间: <TIMESTAMP>            │
+│ 启动时间: <TIMESTAMP>
 └──────────────────────────────────────┘
 ```
 
-### [Step 1/2] 扫描项目上下文
+扫描项目上下文（README、代码、requirement.md 等）。
+
+**有上下文：** 总结项目信息，给 2-3 个建议方向，帮用户明确要做什么。
 
-扫描项目上下文（README、已有代码、requirement.md、OpenSpec spec 文件等）。
+**空项目：** "项目较新，无上下文。请用 `/alloy:start <topic>` 重新调用，进入完整需求设计流程。"
 
-### [Step 2/2] 呈现发现与建议
+> 必须让用户重新输入 `/alloy:start <topic>`——只有重新调用命令，alloy:start 技能才会被重新加载。仅输入 topic 文本会导致脱离编排框架，关键闸门被跳过。
 
-**有上下文可读时：** 总结项目信息（技术栈、已有功能、最近变更），基于发现给用户 2-3 个建议方向或追问。目标是帮用户明确他想做什么，而不是抛回一句"请提供主题"。
+**自由探索发现用户有明确 topic 后：**
 
-**空项目无可读上下文时：** 直接告诉用户："项目较新，没有太多上下文可供参考。请用 `/alloy:start <topic>` 重新调用，我会进入完整的需求设计流程。"
+🔴 USER_GATE: 检测到明确功能需求，请选择：
+- (a) 以 "<topic>" 进入全新开始（请输入 `/alloy:start <topic>` 正式开始）
+- (b) 继续自由探索
 
-> 关键：必须让用户重新输入 `/alloy:start <topic>`，而不是只输入 topic 文本。只有重新调用命令，alloy:start 技能才会被重新加载并进入"全新开始"路径。如果用户只输入 topic 文本而不带命令，Agent 将脱离 alloy:start 编排框架，导致关键闸门（change name 确认、分支选择、hash commitment）被跳过。
+选 (a) 时输出提示文本，Agent 不得直接跳转到"全新开始"流程。
 
 ---
 
 ## 强制新建（--new <topic>）
 
-无论是否有活跃 change，直接走"全新开始"流程。多个 change 可并行 planning，但不能同时 apply（一个 session 只能有一个工作中的 worktree）。
+无论是否有活跃 change，直接走"全新开始"流程。多个 change 可并行 planning，但不能同时 apply。
 
 ---
 
@@ -381,59 +336,44 @@ brainstorming 每个问题都是沟通成本。使用平台的交互式提示工
 ```
 ┌──────────────────────────────────────┐
 │ Alloy [1/5] · Phase: Start           │
-│ 启动时间: 从 phase_timings.start.started_at 读取，若无则从 created_at 读取            │
+│ 启动时间: phase_timings.start.started_at 或 created_at
 └──────────────────────────────────────┘
 
-→ 检测到活跃 change：<name>
-→ 当前阶段：<phase>
-→ 已完成制品：<列出已有文件>
+→ 检测到活跃 change：<name>（phase: <phase>）
+→ 已完成制品：<列出>
 → 下一步：<建议操作>
 ```
 
-### [Step 1/1] 状态展示与自动接续
-
-先读取 `.alloy.yaml` 获取 phase 和 worktree 字段，再检查文件系统确认实际制品状态。
-
-展示检测结果后，根据 phase 和制品状态决定路由：
+读取 `.alloy.yaml` + 文件系统确认制品状态，按 phase 路由：
 
 | phase | 制品状态 | 路由 |
 |-------|---------|------|
-| started | proposal.md 存在 | alloy-plan（正常接续——plan 制品已有，继续生成） |
-| started | proposal.md 不存在 + draft.md 存在且 hash 有效 | **提示用户选择：**(a) 进入 plan 阶段 (b) 回到 brainstorming 修改需求。draft 已确认，默认预期是用户想进 plan——不要默认假设用户想重来。 |
-| started | proposal.md 不存在 + draft.md 不存在或 hash 不匹配 | 重新进入 brainstorming（draft 缺失或已被篡改，需重新讨论需求） |
-| planned | — | alloy-apply |
-| applied | — | alloy-archive |
-| archived | — | alloy-finish |
-| finished | — | 工作流已完成——如需继续修改，使用自然对话提交新变更 |
-
-**实现方式：**
-
-- **需自动加载命令时**（proposal.md 存在 → plan、planned → apply 等）：输出对应命令文件的完整指令（`commands/alloy/plan.md` / `apply.md` / `archive.md` / `finish.md`），将 change name 和检测到的进度信息作为上下文传入。Agent 无缝进入对应阶段。
-- **需用户选择时**（draft 已确认、proposal 不存在）：先校验 draft hash：
-  ```bash
-  alloy _record check openspec/changes/<name> draft
-  ```
-  hash 有效 → 展示选择："draft 已确认。 (a) 进入 plan 阶段 (b) 回到 brainstorming 修改需求"。等用户选择后执行对应路由。
-  hash 不匹配 → 走"draft 不存在或 hash 不匹配"路径。
-
-一致性检查（双向）：
-- worktree 字段有值但磁盘路径不存在 → ⚠️ "worktree 残留：.alloy.yaml 声称有 worktree 但磁盘不存在"
-- worktree 字段为 null 但 `.worktrees/<name>/` 目录存在 → ⚠️ "worktree 孤儿：磁盘存在 worktree 但 .alloy.yaml 未记录，建议手动验证并更新状态"
-- 发现孤儿 worktree 时，询问用户是否修复 .alloy.yaml：`alloy _state write openspec/changes/<name> worktree ".worktrees/<name>"`
+| started | proposal.md 存在 | 🔴 USER_GATE: 选择继续规划（alloy-plan） / 回需求讨论（重新 start） |
+| started | draft.md 存在且 hash 有效 | 🔴 USER_GATE: 选择进 plan / 回 brainstorming |
+| started | draft.md 缺失或 hash 不匹配 | 重新 brainstorming |
+| planned | — | 🔴 USER_GATE: 确认进入 apply 阶段（继续 / 查看状态 / 放弃 change） |
+| applied | — | 🔴 USER_GATE: 确认进入 archive 阶段（继续 / 查看状态 / 放弃 change） |
+| archived | — | 🔴 USER_GATE: 确认进入 finish 阶段（继续 / 查看状态） |
+| finished | — | 工作流已完成 |
 
----
+**所有 🔴 USER_GATE 的选项模板（同款语义节点，6 phase 共用）：**
+- (a) 进入 `<目标阶段>` 继续
+- (b) 查看状态（/alloy:status）
+- (c) 放弃此 change（/alloy:discard）——仅 planned/applied 阶段可选
 
-## 多选（有多个活跃 change）
+**自动跳转仅限**：用户明确选择 (a) 后才加载目标命令。
 
-```
-┌──────────────────────────────────────┐
-│ Alloy [1/5] · Phase: Start           │
-│ 启动时间: 从 phase_timings.start.started_at 读取，若无则从 created_at 读取            │
-└──────────────────────────────────────┘
+**需自动加载时：** 输出对应命令文件完整指令，将 change name 和进度信息传入。
 
-→ 检测到 <N> 个活跃 change，请选择。
-```
+**需用户选择时：** 先校验 draft hash（`alloy _record check openspec/changes/<name> draft`），hash 有效 → 展示选择。
 
-### [Step 1/1] 展示并选择
+一致性检查：
+- worktree 字段有值但路径不存在 → ⚠️ WARN 残留
+- worktree 为 null 但 `.worktrees/<name>/` 存在 → ⚠️ WARN 孤儿，询问是否修复
+
+---
+
+## 多选（有多个活跃 change）
 
 列出所有活跃 change（名称 + phase + 制品状态），让用户选择接续哪个，或 `--new <topic>` 开新 change。
+