@devcxl/opencode-cabbage 0.3.2 → 1.1.0

package/assets/skills/flow-requirements/SKILL.md

@@ -1,249 +1,84 @@
 ---
 name: flow-requirements
-description: 渐进式需求澄清 → PRD 输出 → GitHub Issue 创建
+description: 渐进式需求澄清 → PRD → Flow Record（flow_control）
 ---
 
 # flow-requirements
 
-通过 Decision Map 驱动的渐进式需求澄清，将松散想法逐步凝固为 PRD 并创建 GitHub Issue。
+通过渐进式需求澄清将松散想法凝固为 PRD，并用 `flow_control{op:"create-flow"}` 创建 Flow Record（Parent Issue）。
 
 ## 核心理念：战争迷雾（Fog of War）
 
-需求澄清不是一次性穷举——你无法在动手前预测所有问题。正确的方式是：
-
-- 只定义**前沿**（当前可见的待决策问题）
-- 逐个解决前沿问题，每解决一个，迷雾推开一层，新问题浮现
-- 直到前沿推至足够远，所有关键决策已定，PRD 自然成形
-
-## Prerequisites
-
-- `/setup` 已完成（gh CLI 可用，docs 目录就绪）
-
----
+需求澄清不是一次性穷举——只定义**前沿**（当前可见的待决策问题），逐个解决，每解决一个迷雾推开一层，直到所有关键决策已定，PRD 自然成形。
 
 ## Phase A：创建决策映射
 
-**目标**：把用户的松散想法转化为结构化的待决策问题清单。
-
-### A1. 锚定核心问题
-
-先问第一个问题，锁定需求的核心：
-
-> "这个需求最终要解决什么问题？不做会怎样？"
-
-不要同时问多个问题。得到回答后再继续。
-
-### A2. 构建 Decision Map
-
-根据回答，在 `docs/dev/decision-map.md` 创建决策映射。映射是一个紧凑的 Markdown 文件，用于追踪所有待决策问题。
-
-**映射结构：**
-
-```markdown
-# Decision Map: <需求标题>
-
-## <ticket-slug>: <问题简述>
-
-Blocked by: <slug>, <slug>  （无依赖则省略此行）
-Status: open
-Type: Grilling | Research | Prototype
-
-### Question
-<一句话描述需要决策的问题>
+在 `docs/dev/decision-map.md` 创建映射，追踪所有待决策问题（Ticket 含 slug / Blocked by / Status / Type / Question / Answer）。初始只创建 2–4 个前沿 Ticket，不试图穷举。
 
-### Answer
-<解决后填写>
-```
-
-**规则：**
-- `slug` 是 dash-case 短标识符，在映射内唯一，读起来像微型标题（如 `core-scenario`、`data-model`、`auth-strategy`）
-- 初始只创建 2–4 个**前沿 Ticket**——即当前能直接开始解决的，不要试图穷举
-- 前沿之外的问题暂时不写，等迷雾推开后再添加
-- 有依赖关系的 Ticket，用 `Blocked by` 声明前置条件
-
-**Ticket 类型：**
-
-| Type | 用途 | 执行方式 |
-|------|------|----------|
-| **Grilling**（默认） | 需要和用户对话澄清的决策 | 见 Phase B - Grilling 方法 |
-| **Research** | 需要查阅文档、API、代码库 | 调研 → 输出摘要 → 记录答案 |
-| **Prototype** | 需要低保真原型来验证方案 | 创建原型 → 确认 → 记录答案 |
-
----
+Ticket 类型：Grilling（与用户对话澄清）/ Research（查文档）/ Prototype（低保真验证）。
 
 ## Phase B：渐进式解决
 
-**规则：**
-- 每次只处理**一个**已解除阻塞的 Ticket（`Status: open` 且所有 `Blocked by` 的 Ticket 已 `resolved`）
-- 处理前先 **Claim**：将 `Status` 设为 `in-progress`，保存映射
-- 根据 Ticket 的 `Type` 选择执行方式
-- 解决后将 `Status` 设为 `resolved`，在 `Answer` 中记录结论
-- 每解决一个 Ticket，检查是否有新问题浮现 → 插入新 Ticket（标注 `Blocked by`）
+- 每次只处理**一个**已解除阻塞的 Ticket；处理前 Claim（`Status: in-progress`）
+- Grilling 型：**一次只问一个问题**，每个问题给出推荐答案，沿决策树分支深入
+- 追问技巧："然后呢？"（第 3 层才触及本质）、"如果不做这个会怎样？"（验证优先级）、"谁来判断做对了？"（明确验收）
+- 解决后 `Status: resolved` 并记录 Answer；检查是否有新问题浮现 → 追加 Ticket
 - 循环直到所有前沿 Ticket 已 resolved
 
-### B1. Grilling 型 Ticket 的执行方法
-
-对 Grilling 型 Ticket，采用逐层拷问方法：
-
-**核心原则：**
-- **一次只问一个问题**。同时问多个问题会让人困惑。
-- 沿决策树的每条分支逐一深入，逐个解决决策之间的依赖关系。
-- **每个问题必须给出推荐答案**，不能只提问不表态。
-- 得到用户反馈后再继续下一个问题。
-
-**追问技巧：**
-1. **"然后呢？"** — 前 2 个回答通常只是表面，追问到第 3 层才触及本质
-2. **"如果不做这个会怎样？"** — 验证真实优先级
-3. **"谁来判断这个做对了？"** — 明确决策者和验收标准
-4. **"和现有功能的关系？"** — 发现隐藏的依赖和冲突
-5. **"这个简单"或"这个以后再说"** — 标记为 out-of-scope，避免遗漏
-
-**覆盖维度：**
-每个 Grilling Ticket 在拷问过程中应覆盖以下维度（按需，不是每个都要问完）：
-- 用户故事与业务价值
-- 边界条件与异常场景
-- 验收标准（追问到可验证的程度）
-- 技术约束（语言/框架、部署环境、性能要求）
-- 优先级：P0（必须）/ P1（重要）/ P2（锦上添花）
-
-**结束条件：**
-当用户对某个决策分支的回答不再引出新问题时，该分支已澄清完毕。标记 `Status: resolved`，填写 `Answer`。
-
-### B2. Research 型 Ticket 的执行方法
-
-1. 明确调研目标：需要回答什么问题？
-2. 查阅相关文档、API 参考、代码库
-3. 输出简短摘要到 `Answer`
-4. 标记 `Status: resolved`
-
-### B3. Prototype 型 Ticket 的执行方法
-
-1. 明确验证目标：这个原型要证明什么？
-2. 创建低保真原型（提纲、草图、桩代码）
-3. 和用户确认方案是否符合预期
-4. 结论写入 `Answer`，标记 `Status: resolved`
-
-### B4. 迷雾检查
-
-每解决一个 Ticket 后，检查是否推开迷雾：
-
-- **有新问题浮现？** → 在映射末尾追加新 Ticket，标注正确的 `Blocked by` 边
-- **之前的决策因此变更？** → 更新或标记相关 Ticket
-- **前沿是否已推至足够远？** → 所有关键决策已定 → 进入 Phase C
-
----
-
 ## Phase C：凝固为 PRD
 
-当所有前沿 Ticket 均已 `resolved`，且没有新的关键问题浮现时，将 Decision Map 凝固为 PRD。
-
-### PRD 生成规则
-
-不是凭空编写，而是从 Decision Map 的 `Answer` 中提炼：
-
-1. 将每个 Ticket 的 `Question` + `Answer` 映射为 PRD 的对应章节
-2. 补充：背景、非功能性需求、风险
-3. 从 Grilling 过程中标记的 out-of-scope 项，记录到 `docs/dev/out-of-scope.md`
-
-### PRD 文档路径
-
-保存到 `docs/prd/<title>.md`。
-
-### Out-of-Scope 记录
-
-将在澄清过程中明确排除的需求记入 `docs/dev/out-of-scope.md`：
-- 说明排除原因
-- 便于后续回顾，避免重复讨论
-
----
-
-## Phase D：创建 GitHub Issue
-
-```bash
-mkdir -p tmp
-gh issue create \
-  --title "<PRD Title>" \
-  --label "enhancement" \
-  --body-file docs/prd/<title>.md
-```
-
----
-
-## 多会话协作
+从 Decision Map 的 Answer 提炼为 PRD，保存到 `docs/prd/<title>.md`。
 
-如果需求澄清跨越多个会话，Decision Map 已持久化在 `docs/dev/decision-map.md`。后续会话：
+## Phase D：创建 Flow Record
 
-1. 加载整个映射作为上下文
-2. 找到第一个 `Status: open` 且已解除阻塞的 Ticket
-3. Claim → 解决 → 迷雾检查 → 重复
-4. 每个会话最多解决一个 Ticket，结束时输出下一步指令
+调用 `flow_control{op:"create-flow", title:"<英文功能标题>"}` 创建 Draft Parent Issue（Flow Record）。
+内核负责 slug 派生与校验、Profile 门禁、双 session 检查、legacy 检测——创建动作全部收敛到工具内。
 
-**会话结束时的 Handoff 格式：**
+## CONTEXT.md 术语发现
 
-> **Next steps** — N 个 Ticket 已解除阻塞: `<slug>`, `<slug>`
->
-> 继续解决下一个已解除阻塞的 Ticket：
-> ```
-> /requirements ，继续推进 Decision Map（docs/dev/decision-map.md）
-> ```
-
----
+需求澄清中发现的领域术语写入根 `CONTEXT.md`（术语权威）。发现新术语或冲突时暂停提问，用户确认后由 `flow_control` 更新。
 
 ## Output
-
-- `docs/dev/decision-map.md` — 决策映射（需求阶段临时文件，PRD 生成后可删除）
-- `docs/prd/<title>.md` — PRD 文档
-- `docs/dev/out-of-scope.md` — 排除范围记录
-- GitHub Parent Issue
+- `docs/dev/decision-map.md` — 决策映射（PRD 生成后可删除）
+- `docs/prd/<title>.md` — PRD
+- Flow Record（Parent Issue，由 flow_control 创建）
 
 ## 下一阶段
-
-- **/design** — 基于此 PRD 进行技术设计
-
----
+- **/design** — 基于 PRD 进行技术设计
 
 ## Contract
 
 ### Trigger
-
-由 `/requirements` 命令或 `@dev-lifecycle` Phase 0 触发。
+由 `/requirements` 命令或 `@dev-lifecycle` 触发。
 
 ### Inputs
-
 - 用户提供的功能描述（来自消息文本）
 
 ### Preconditions
-
-- `/setup` 已完成（gh CLI 可用，docs 目录就绪）
+- `/setup` 已完成（Profile 已确认，gh CLI 可用）
 
 ### Procedure
-
 1. 锚定核心问题，创建 Decision Map
 2. 渐进式解决所有前沿 Ticket（Grilling / Research / Prototype）
 3. 迷雾推至足够远 → 凝固为 PRD
-4. 记录 Out of Scope
-5. 创建 Parent GitHub Issue
+4. 记录领域术语到 CONTEXT.md
+5. 调用 `flow_control{op:"create-flow"}` 创建 Flow Record
 
 ### Outputs
-
-- `docs/dev/decision-map.md` — 决策映射
-- `docs/prd/<title>.md` — PRD 文档
-- `docs/dev/out-of-scope.md` — 排除范围记录
-- GitHub Parent Issue
+- `docs/dev/decision-map.md`
+- `docs/prd/<title>.md`
+- Flow Record（Parent Issue）
 
 ### Failure
-
-- gh CLI 不可用 → 提示先执行 /setup
+- Profile 未确认 → flow_control 返回 `SETUP_REQUIRED`，提示先执行 `/setup`
 - Issue 创建失败 → 记录错误，不阻塞 PRD 写入
 
 ### Idempotency
-
-- 如果 Decision Map 已存在 → 从中断点继续，不重新创建
-- 如果 PRD 文件已存在 → 更新而非覆盖
-- 如果 Parent Issue 已创建 → 追加评论而非重复创建
+- Decision Map 已存在 → 从中断点继续
+- PRD 文件已存在 → 更新而非覆盖
+- Flow Record 已创建 → 绑定已有 Issue（`parent_issue_number`）而非重复创建
 
 ### Prohibited Actions
-
 - 不跳过 Phase A 和 Phase B 直接输出 PRD
 - 不一次问多个问题
-- 不省略 Out of Scope 记录
+- 不绕过 flow_control 手工创建 Issue（由 create-flow 完成）

package/assets/skills/flow-review/SKILL.md

@@ -1,140 +1,44 @@
 ---
 name: flow-review
-description: 双轴审查（规范 + 规格）→ 自动合并
+description: 双轴审查（规范 + 规格）→ task_control submit-review / merge-task
 ---
 
 # flow-review
 
 沿两条轴线审查 PR 代码：规范（是否符合编码标准）和规格（是否实现了原始需求）。
+审查结果由 primary 通过 `task_control` 提交与合并，reviewer 本身只读。
 
-## Prerequisites
-- PR 已创建
-- 可选的 `/test` 已完成
+## 核心：调用 task_control
 
-## Workflow
+1. `task_control{op:"submit-review", pr_number, verdict:"approve"|"request-changes", ...}` — 发布审查结果
+2. `task_control{op:"merge-task", pr_number, ...}` — 合并（CI + 分支保护 + 风险分级 + 高风险人类 approval）
+3. `task_control{op:"status-task", task_id}` — 查看 Task/PR 状态
 
-### 1. 获取审查材料
+reviewer 只读：不直接 `gh pr review` / `gh pr merge`（写操作由 primary 经 task_control 执行）。
 
-**代码审查必须在本地分支/worktree 中进行，禁止通过 WebFetch 或浏览器访问远程 PR 页面获取代码。**
-
-```bash
-# 切换到对应分支（如非 worktree 模式）
-git checkout feat/<task-slug>
-
-# 或在 worktree 模式下，直接进入 worktree 目录
-cd .worktree/<task-slug>
-
-# 获取 PR diff 和元数据
-gh pr diff <pr-number>
-gh pr view <pr-number> --json title,body,files
-```
-
-### 2. 阅读约束来源
-- 检查相关 ADR（`docs/adr/`）— 确认代码是否遵循架构决策
-- 确认规格来源：commit 消息中的 Issue 引用或 `docs/prd/` / `docs/dev/specs/`
-
-### 3. 文档同步确认
-确认 PR 中是否包含文档同步：
-- 检查 PR body 是否列出已同步的文档
-- 检查 `docs/guides/` 和 `docs/dev/guides/` 是否有相应变更
-- 如涉及配置/API 变更但文档未同步 → 标记为阻断性问题
-
-### 4. 双轴审查
-并行检查两个维度：
+## 双轴审查
 
 **规范轴（Normative）** — 代码是否符合文档化的编码标准？
 参考 `references/smell-baseline.md` 中的代码气味基线。
 
 **规格轴（Specification）** — 代码是否忠实实现了需求？
 对照 PRD（`docs/prd/`）和设计方案（`docs/dev/specs/`）验证。
-- 如发现实现与设计偏差 → 追加到 `docs/dev/changelog/<YYYY-MM-DD-NNN-slug>.md`
+- 如发现实现与设计偏差 → 追加到 changelog
 
 **TDD Criterion Coverage** — 检查 Task 的 `acceptance_criteria` 是否被 PR 覆盖：
 - 对照 Task frontmatter 中的 `acceptance` 数组，逐条核查
 - 检查 PR 是否包含每条 criterion 对应的测试或验证
 - 检查 `tdd` 配置块中的 `mode` 和 `min_cycles` 是否被遵循
-- **明确不检查 commit order** — TDD cycle 的 RED→GREEN 顺序是编码过程约束，
-  reviewer 不审查 commit 历史是否呈现 RED-first 模式
-
-### 5. 合并前检查
-在合并前确认以下项：
-- 文档同步已完成（`docs/guides/` 已更新或无需更新）
-- changelog 已记录偏差（如有）
-- CI 已通过
-
-### 6. 发表审查意见
-发现阻断性问题：
-```bash
-gh pr review <pr-number> --request-changes --body "..."
-```
-无问题或非阻断性建议：
-```bash
-gh pr review <pr-number> --approve --body "..."
-```
-
-### 7. 等待 CI + 自动合并
-```bash
-gh pr checks <pr-number> --watch
-gh pr merge <pr-number> --squash --delete-branch
-```
-
-### 8. 关闭关联 Sub Issue
-如果 PR body 未包含 `Closes #<num>`（或 PR 合并后 GitHub 未自动关闭），手动关闭：
-```bash
-gh issue close <issue-num> --comment "已完成，已合并至 main"
-```
-
-### 9. 清理 Worktree
-PR 合并后，安全清理对应的 worktree 和分支：
-
-```bash
-WORKTREE=".worktree/<task-slug>"
-BRANCH="feat/<task-slug>"
-
-# Preflight 检查
-echo "=== Worktree 清理 Preflight ==="
-
-# 1. 确认 PR 已合并
-PR_NUM=<pr-number>
-if ! gh pr view "$PR_NUM" --json merged --jq '.merged' 2>/dev/null | grep -q true; then
-  echo "ERROR: PR #$PR_NUM 未合并，跳过清理"
-  exit 1
-fi
-
-# 2. 确认分支已推送到远程
-if git ls-remote --exit-code origin "$BRANCH" >/dev/null 2>&1; then
-  echo "分支 $BRANCH 已推送到远程"
-else
-  echo "WARNING: 分支 $BRANCH 未推送到远程，但 PR 已合并，继续清理"
-fi
-
-# 3. 检查 worktree 是否干净
-if [ -d "$WORKTREE" ]; then
-  DIRTY=$(git -C "$WORKTREE" status --porcelain)
-  if [ -n "$DIRTY" ]; then
-    echo "WARNING: Worktree 有未提交变更："
-    echo "$DIRTY"
-    echo "暂停。如需强制清理请手动执行 --force"
-    exit 1
-  fi
-
-  # 4. 全部通过 → 清理
-  git worktree remove "$WORKTREE"
-  git branch -D "$BRANCH" 2>/dev/null || true
-  echo "Worktree 已清理：$WORKTREE"
-else
-  echo "Worktree 不存在，跳过清理"
-fi
-```
-
-> 清理前必须验证 PR 已合并、worktree 干净。只有在所有 preflight 检查通过后才删除。
-> 如果 PR 已合并但 worktree 仍有未提交变更，暂停并通知用户，不自动 --force。
+- **明确不检查 commit order** — RED→GREEN 顺序是编码过程约束，reviewer 不审查 commit 历史
+
+## 审查材料获取
+
+代码审查必须在本地分支/worktree 中进行，禁止通过 WebFetch 或浏览器访问远程 PR 页面获取代码。
 
 ## Output
-- PR 已审查
-- PR 已合并（条件满足时）
-- 关联 Sub Issue 已关闭
-- changelog 已记录偏差（如有）
+- 结构化审查报告（APPROVED / CHANGES_REQUESTED）
+- PR 已合并（task_control merge-task，条件满足时）
+- Worktree 已清理（task_control merge-task 后 preflight 销毁）
 
 ## 后续
 - **/release** — 发布（如所有 PR 已合并）
@@ -145,26 +49,25 @@ fi
 由 `/review` 命令或 `@dev-lifecycle` Phase 3 审查步骤触发。
 
 ### Inputs
-- PR 编号（来源：`/code` 产出）
+- PR 编号与 Task Record（来源：`/code` 产出）
 
 ### Preconditions
 - `/code` 已完成 → PR 已创建
 
 ### Procedure
-1. 获取 PR diff 和元数据
-2. 双轴审查（规范轴 + 规格轴）
+1. 在本地 worktree/分支获取 PR diff 与元数据
+2. 双轴审查（规范轴 + 规格轴）+ TDD criterion coverage
 3. 输出结构化审查报告
-4. 编排器发布审查结果
-5. 等待 CI 通过后合并
-6. 关闭关联 Sub Issue
-7. 安全清理 Worktree（Preflight）
+4. primary 调用 `task_control{op:"submit-review"}` 发布结果
+5. CI 通过后 `task_control{op:"merge-task"}` 合并（工具执行清理）
 
 ### Outputs
 - 结构化审查报告（APPROVED / CHANGES_REQUESTED）
 - PR 已合并（条件满足时）
+- Worktree 已清理
 
 ### Failure
-- Critical/High → Request Changes
+- Critical/High → request-changes
 - Worktree 清理失败 → 记录警告，不阻塞
 
 ### Idempotency
@@ -172,6 +75,6 @@ fi
 - 已审查的 PR → 更新结论
 
 ### Prohibited Actions
-- **禁止使用 WebFetch 或任何 Web 工具获取远程 PR 代码** — 审查代码时必须在已 checkout 的本地分支或 worktree 中直接读取源码文件
+- **禁止使用 WebFetch 或任何 Web 工具获取远程 PR 代码** — 审查代码时必须本地读取源码文件
+- reviewer 不直接执行 `gh pr review` / `gh pr merge`（由 task_control 完成）
 - 不使用默认 --force 清理
-- 不直接执行 gh pr merge（Orchestrator 执行）

package/assets/skills/flow-setup/SKILL.md

@@ -1,46 +1,42 @@
 ---
 name: flow-setup
-description: 初始化项目文档结构，验证开发环境
+description: 初始化 — 探测环境 → 生成 workflow → 确认 Profile
 ---
 
 # flow-setup
 
-初始化项目文档结构，验证开发环境。
+初始化阶段：探测开发环境、生成缺失的 CI/release workflow、确认 AGENTS.md Project Profile。
+所有探测与写入由内核工具 `setup_control` 完成，本 skill 只定义流程，不复制工具实现。
 
-## Workflow
+## 核心：调用 setup_control
 
-### 1. 创建文档目录
-确保以下目录结构存在：
-```
-docs/
-├── prd/              # 产品需求文档
-├── adr/              # 架构决策记录
-└── dev/
-    ├── specs/        # 技术方案
-    ├── tasks/        # DAG 任务定义
-    ├── api/          # API 设计文档
-    ├── db/           # 数据库设计
-    ├── guides/       # 开发指南
-    └── handoff/      # 上下文交接
-```
+调用 `setup_control` 完成三个阶段：
 
-### 2. 验证环境
-```bash
-gh auth status
-git remote get-url origin
-```
-确保 gh CLI 已认证、项目已关联 GitHub 远程。
+1. `setup_control{op:"probe"}` — 探测 git/gh/CI/Profile，输出 readiness 报告
+2. `setup_control{op:"generate-workflows"}` — 缺失时生成 CI/release workflow 草案 + Setup PR（人工合入）
+3. `setup_control{op:"confirm-profile"}` — 用户确认后将 Profile 区块写入根 AGENTS.md
 
-### 3. 完成标记
-```bash
-mkdir -p .opencode/opencode-cabbage
-echo "setup-complete" > .opencode/opencode-cabbage/setup-complete
+Profile 区块格式（内核解析白名单，§9.1）：
+
+```markdown
+## Project Profile
+
+- test command: `npm test -- run`
+- test file patterns: `test/**/*.test.ts`
+- implementation file patterns: `src/**/*.ts`
+- tdd default mode: `strict`
+- version bump rule: `breaking→major, feature→minor, fix→patch`
+- version file: `package.json`
+- tag format: `v{version}`
+- release workflow: `.github/workflows/release.yml`
 ```
 
+未确认 Profile 时 `flow_control{op:"create-flow"}` 会阻断并提示先执行 `/setup`。
+
 ## Output
-- `docs/` 目录已就绪
-- 开发环境已验证
-- 可开始 `/requirements`
+- readiness 报告（development-ready / release-ready 逐项布尔）
+- `.github/workflows/` 草案（缺失时，经 Setup PR 人工合入）
+- 根 AGENTS.md `## Project Profile` 区块
 
 ## Contract
 
@@ -48,28 +44,29 @@ echo "setup-complete" > .opencode/opencode-cabbage/setup-complete
 由 `/setup` 命令触发。首次使用插件或切换新项目时执行。
 
 ### Inputs
-无外部输入。从当前工作目录检测项目状态。
+- 用户对 readiness 报告 / Profile 覆盖项的确认
 
 ### Preconditions
-无。不要求任何前置阶段。
+- gh CLI 已认证（宿主 `gh auth`）
 
 ### Procedure
-1. 创建 docs 目录结构
-2. 验证 gh CLI 和 GitHub 远程
-3. 写入完成标记
+1. 调用 `setup_control{op:"probe"}` 读取 readiness 报告
+2. 缺失 workflow 时调用 `setup_control{op:"generate-workflows"}` 生成草案
+3. 用户确认后调用 `setup_control{op:"confirm-profile"}` 写入 Profile
 
 ### Outputs
-- `docs/` 目录树（prd, adr, dev/specs, dev/tasks, dev/api, dev/db, dev/guides, dev/handoff）
-- `.opencode/opencode-cabbage/setup-complete` 标记文件
+- readiness 报告
+- workflow 草案（可选）
+- 根 AGENTS.md Profile 区块
 
 ### Failure
-- 目录创建失败 → 报告错误并退出
-- gh auth 失败 → 提示用户执行 `gh auth login`
+- gh auth 失败 → 提示用户执行 `gh auth login` 后重试
+- workflow 生成失败 → 报告错误并停止
 
 ### Idempotency
-- 已存在的目录跳过
-- 已存在 `setup-complete` 标记则跳过全部步骤
+- Profile 已确认 → 重复 confirm 覆盖写入（工具内读后写）
+- workflow 已存在 → 跳过生成
 
 ### Prohibited Actions
-- 不删除已有目录或文件
-- 不修改项目代码
+- 不手工编辑 AGENTS.md Profile 区块（由 setup_control 写回）
+- 不直接 push 或创建 Setup PR（工具内部执行）