@gordon.gan/specflow 1.8.0-beta → 1.8.2-beta

package/prompts/approval/multi-repo-guidance.md

@@ -1,263 +0,0 @@
-# Approval · Multi-Repo (多仓) Guidance
-
-> Used by `/specflow:approval` when the user **自然语言指定多仓**、workset 含多个规划根、或
-> design/tasks 明确跨 `talos` / `talos-web` / `talos-worker` 等仓库。
->
-> **目的**:按各仓四件套与锚点生成技术审批文档,并 **询问用户** 产出 **一份合订** 还是 **多份分仓**;
-> 合订时 **必须** 指定 **主仓** 存放 `approval.md` 与 `approval/` 工作区。
-
----
-
-## 0. When to run
-
-| 信号 | 动作 |
-|------|------|
-| 用户说「三仓 / talos+web+worker / 多仓合订 / 前后端一体」 | 启用 `multi_repo.enabled=true` |
-| `specflow workset` / 会话上下文含多个 git 规划根 | 列出候选仓,请用户确认 |
-| 仅单仓 change,无跨仓表述 | `multi_repo.enabled=false`,走单仓流程 |
-| Hub + Spoke 联邦 | 见 §5;各 Spoke 可有不同 change id |
-
-Announce:
-
-```text
-Multi-repo approval: enabled | single-repo
-Repos in scope: talos(scenario-job-compile), talos-web(web-scenario-cases), …
-Document mode: (pending user) unified | per_repo
-Primary repo (if unified): (pending user)
-```
-
----
-
-## 1. Resolve repos (硬顺序)
-
-1. **Parse user natural language** — 仓名、别名(平台/控制台/Worker)、change 名。
-2. **Cross-check workset** — `specflow workset list` / 用户给出的绝对路径;成员顺序 **不** 等于主仓。
-3. **Per repo, verify** (Read-only):
-   - `specflow/changes/<change>/.specflow.yaml` → `phase: refined`
-   - 四件套:`proposal.md`, `specs/**`, `design.md`, `tasks.md`
-4. **Record** in `approval/index.yaml` → `multi_repo.repos[]`:
-
-```yaml
-multi_repo:
-  enabled: true
-  document_mode: unified   # unified | per_repo — 用户确认后写入
-  primary_repo: talos      # unified 时必填
-  repos:
-    - id: talos
-      label: 平台
-      role: platform
-      change: scenario-job-compile
-      root_hint: /path/to/talos    #  agent 读取用,可选
-    - id: talos-web
-      label: 控制台
-      role: web
-      change: web-scenario-cases
-    - id: talos-worker
-      label: Worker
-      role: worker
-      change: scenario-execution
-```
-
-**禁止**在未 Read 各仓四件套前假设内容一致;change id **可以** 各仓不同。
-
----
-
-## 2. User gate — 一份还是多份 (硬)
-
-在 Pass 1 之前或 Stage 12a 之前,**必须** 询问:
-
-```text
-本需求跨 N 个仓库,审批技术文档如何产出?
-
-A) 一份合订视图 (bundle) — 各仓 per_repo 真源 + CLI bundle 只读合订 (**推荐**)
-B) 多份分仓 (per_repo) — 每仓各自 approval.md（默认 Map 模式）
-C) 一份 LLM 合订 (legacy unified) — 仅当用户明确要求且无 bundle；不推荐
-
-请选择 A、B 或 C。
-```
-
-### 2.1 Bundle（推荐 — A）
-
-**真源**: 各仓 **per_repo** `approval.md` + `approval/parts/`（ACP Map 分片）。
-
-**只读合订**: 主仓 `approval-playbook.yaml` + `specflow approval bundle <primary.change>` → `approval-unified.md`（**无 LLM 合并**）。
-
-再询问主仓:
-
-```text
-合订 playbook 与 bundle 输出存放在哪个主仓?
-1) talos (平台)
-2) talos-web (控制台)
-…
-```
-
-**硬规则**:
-
-- `multi_repo.document_mode: per_repo`
-- `multi_repo.bundle.enabled: true`
-- `multi_repo.primary_repo: <id>` — playbook 与 bundle 输出路径
-- 各仓独立 Stage 12 + assemble；**全部 assemble 通过后** 在主仓执行 bundle
-- `acp.pipeline: acp/v2` 写入 `index.yaml`
-
-```yaml
-multi_repo:
-  document_mode: per_repo
-  primary_repo: talos
-  bundle:
-    enabled: true
-    output: approval-unified.md
-outputs:
-  per_repo: [ …各仓路径… ]
-  bundle:
-    repo: talos
-    change: scenario-job-compile
-    path: specflow/changes/scenario-job-compile/approval-unified.md
-```
-
-### 2.2 Per-repo only（B）
-
-见 §2.3；`bundle.enabled: false`。
-
-### 2.3 Legacy unified LLM 合订（C — 不推荐）
-
-仅在用户 **明确要求** 且拒绝 bundle 时使用。再询问主仓:
-
-```text
-合订文档存放在哪个主仓?(approval.md 与 approval/ 工作区写在该仓 change 目录下)
-```
-
-**硬规则**:
-
-- `multi_repo.document_mode: unified`
-- `multi_repo.primary_repo: <id>` **必填**
-- **工作区路径**(分片模式):
-  - `specflow/changes/<primary.change>/approval/index.yaml`
-  - `specflow/changes/<primary.change>/approval/parts/*.md`
-  - 产出:`specflow/changes/<primary.change>/approval.md`
-- CLI:`specflow approval assemble <primary.change>` **在主仓规划根**执行
-- 文档 §1.2 / §2.3 / 附录 B **必须** 按仓分表;Pass 6 锚点 **分仓列举**
-- 合订 **不是** 只写主仓 design;须合并各仓 specs/design/tasks 的跨端语义
-
-写入 `multi_repo.outputs.unified`:
-
-```yaml
-outputs:
-  unified:
-    repo: talos
-    change: scenario-job-compile
-    path: specflow/changes/scenario-job-compile/approval.md
-```
-
-### 2.4 Per-repo（B 详情）
-
-**硬规则**:
-
-- `multi_repo.document_mode: per_repo`
-- **每个** `repos[]` 条目独立:
-  - 在该仓 `specflow/changes/<repo.change>/approval/`(分片)或 `approval.md`(单体)
-  - 内容 **仅** 本仓 scope;交叉引用用「见 `<other-repo>` approval §x」
-- 各仓分别 `specflow approval assemble <repo.change>`(若在主仓 CLI,需 `--store` 或 cd 到该根)
-- **禁止**只在主仓写一份然后复制到其它仓
-
-写入 `multi_repo.outputs.per_repo[]`:
-
-```yaml
-outputs:
-  per_repo:
-    - repo: talos
-      change: scenario-job-compile
-      path: specflow/changes/scenario-job-compile/approval.md
-    - repo: talos-web
-      change: web-scenario-cases
-      path: specflow/changes/web-scenario-cases/approval.md
-```
-
----
-
-## 3. Analysis & Map 上下文
-
-| 模式 | Read 范围 | index 库存 |
-|------|-----------|------------|
-| unified | 各仓四件套 + 各仓锚点 + 各仓约定 | `interfaces/pages/tables` 带 `repo` 字段(推荐) |
-| per_repo | **当前仓**四件套 + 本仓锚点 | 仅本仓实体 |
-
-**Unified 分片建议**:
-
-- `02-design-review` — 三仓决策表
-- `04.5-api` — 按 `repo` 或 L1/L2/L3/L4 分批;Worker 切片须 Read `api-guidance.md` + worker OpenAPI 路径
-- `04.6-*` — 仅 `ui_in_scope` 且 web 仓
-- 附录 B — 按仓允许/禁止路径
-
-**Inventory 扩展**(可选列):
-
-```yaml
-interfaces:
-  - id: I4
-    short: 逐步上报
-    change: scenario-job-compile
-    part: 04.5-api-worker
-    repo: talos-worker
-```
-
----
-
-## 4. Document header (unified)
-
-合订 `approval.md` 头部 **必须** 声明:
-
-```markdown
-> **覆盖变更（多仓合订,主仓: talos）**:
-> - 平台 `talos/scenario-job-compile`
-> - 控制台 `talos-web/web-scenario-cases`
-> - Worker `talos-worker/scenario-execution`
-> **存放路径**: `specflow/changes/scenario-job-compile/approval.md`
-```
-
----
-
-## 5. Hub / Federated 注意
-
-- Hub change id 可与 Spoke change id **同名或不同**;`multi_repo.repos[].change` 用 **各规划根内真实目录名**。
-- Hub 合同摘要可读 `--store`;Spoke approval **不**替代 Hub archive。
-- `coordination.yaml`(若有)可 Read;无则 chat 列出各仓 phase。
-
----
-
-## 6. 自检
-
-- [ ] 用户已选 unified **或** per_repo
-- [ ] unified → `primary_repo` 已选且工作区在该仓
-- [ ] per_repo → 每仓输出路径已写入 `outputs.per_repo`
-- [ ] 各仓四件套已 Read;非主仓内容已进合订正文或分仓文档
-- [ ] Gate 摘要中列出 **所有** 将写入的 `approval.md` 路径
-
----
-
-## 7. 与单仓关系
-
-`multi_repo.enabled=false` 时忽略本章;`change` 字段为当前规划根 change,行为与旧版一致。
-
----
-
-## 8. 主仓一键 · Subagent 并行 (mode A/B)
-
-> Router: `prompts/approval/multi-repo-spoke-subagent.md` · Orchestrator: `skills/specflow-approval/SKILL.md` **Stage 1c**
-
-当用户在 **主仓** 发起 `/specflow:approval` 且已选 **A (bundle)** 或 **B (per_repo)**:
-
-| 角色 | 职责 |
-|------|------|
-| **主 Agent（主仓）** | intake、playbook、scope 拆分、闭环 Pass 1–11、主仓 Map、等待子仓、主仓 finalize、bundle |
-| **Subagent × 子仓** | 各子仓独立 `approval/` → Map → 12e → `finalize <spoke.change>`（**禁止** `--bundle`） |
-
-**硬顺序**:
-
-1. 主仓写好 `approval-playbook.yaml` + `multi_repo.repos[].root_hint`
-2. **并行**派发子仓 subagent（web / worker / …）
-3. **等待**全部 `finalize_ok: true`
-4. 主仓 Map + finalize
-5. 主仓 `finalize --bundle --workspace-root <主仓规划根>`
-
-**禁止**: 仅在主仓 unified 合订而不拆仓；子仓未 finalize 就 bundle；让用户手动 cd 子仓跑 CLI（除非 subagent 不可用）。
-
-**从 unified 迁移**: 将 `04.6-ui`、Worker L2 接口等 **搬迁** 到对应子仓 parts；主仓留 cross-ref + 平台/L3 正文。示例 playbook: `templates/approval-playbook-talos-scenario-job-compile.yaml`。

package/prompts/approval/multi-repo-spoke-subagent.md

@@ -1,94 +0,0 @@
-# Approval · Multi-Repo Spoke Subagent Brief
-
-> **Invoked by** primary `/specflow:approval` orchestrator via **Task** subagent (one per non-primary repo).
-> Primary repo Map/Review/Finalize stays on the **orchestrator** unless user explicitly runs approval from a spoke root.
-
----
-
-## Mission
-
-Run **full ACP approval for ONE spoke repo only** — Index → Map → Stage 12e AI Review → `specflow approval finalize <spoke.change>` — scoped to that repo's four artifacts and **only** entities assigned to this repo in the shared playbook / primary `index.yaml`.
-
-**Do NOT** write into the primary repo. **Do NOT** LLM-merge cross-repo content into one file.
-
-**Spoke index rule**: only **`primary_repo`** sets `multi_repo.bundle.enabled: true` + hosts `approval-playbook.yaml`. Spoke repos set `bundle.enabled: false` — they **never** run `--bundle`.
-
----
-
-## Inputs (primary must pass all)
-
-| Field | Example |
-|-------|---------|
-| `repo_id` | `talos-web` |
-| `planning_root` | `/Users/gankang/TALOS-WORK/talos-web` |
-| `change` | `web-scenario-cases` |
-| `role` | `web` |
-| `primary_change` | `scenario-job-compile` |
-| `primary_repo_id` | `talos` |
-| `workset_root` | `/Users/gankang/TALOS-WORK` |
-| `scope` | Which parts/capabilities/interfaces/pages belong to this spoke (from playbook or primary index) |
-| `cross_ref_policy` | Cross-repo refs: `见 talos approval §4.5 I8` — never duplicate platform DDL/RPC bodies |
-
-Read before writing:
-
-1. `specflow/changes/<change>/` four artifacts (phase must be `refined`)
-2. `prompts/approval/generate.md` (Part E/F), `acp-pipeline.md`, `ai-review.md`
-3. Role packs: `frontend-guidance.md` (web), `api-guidance.md` (worker), etc.
-4. Primary `approval/index.yaml` `multi_repo.repos[]` entry for this repo
-
----
-
-## Hard scope rules
-
-| Role | Own in approval/parts | Cross-ref only (do not copy bodies) |
-|------|----------------------|-------------------------------------|
-| `platform` | compile, scheduler RPC/L4, DDL, gateway, ingest | Worker L2 HTTP, console pages |
-| `web` | §4.6 UI, web APIs (I5/I6), nav/routes | Platform scheduler/result RPC details |
-| `worker` | L2 Worker HTTP (I7/I9), executor logic, Pack | Platform L3 SubmitStepResult, Web UI |
-
-Each spoke document is **standalone per repo**: `01-intro` … `10-signoff` with **repo-scoped** §1–§3 and detailed §4 batches for that repo only.
-
----
-
-## Execution order (spoke)
-
-```text
-cd <planning_root>
-→ Write approval/index.yaml (multi_repo.enabled=false OR spoke-local block only)
-→ Write approval/analysis.json (Passes scoped to this repo)
-→ 12a skeleton parts
-→ 12b Map batches (repo scope only)
-→ 12e: specflow approval finalize <change>  # may pause → review-packet
-→ Fix parts; write review-result.json + part_hashes (specflow approval review-hashes --json)
-→ specflow approval finalize <change>       # must exit ok
-```
-
-**Never** run `--bundle` on a spoke. Bundle is **primary only**, after all spokes report success.
-
----
-
-## Return payload to orchestrator (required)
-
-Report in final message:
-
-```yaml
-repo_id: talos-web
-change: web-scenario-cases
-finalize_ok: true
-output_path: specflow/changes/web-scenario-cases/approval.md
-review_result: specflow/changes/web-scenario-cases/approval/review-result.json
-lint_errors: []
-blocked: false
-notes: ""
-```
-
-If `finalize_ok: false`, set `blocked: true` and paste diagnostics — orchestrator **must not** bundle.
-
----
-
-## Anti-patterns
-
-- Writing `04.6-ui` into platform repo when web spoke exists
-- Running bundle from spoke cwd
-- Skipping finalize and pasting assembled markdown
-- Unified LLM merge (mode C) when mode A was chosen

package/prompts/approval/project-conventions-guidance.md

@@ -1,171 +0,0 @@
-# Approval · Project Conventions Router
-
-> Used by `/specflow:approval` before drafting **§3 架构 / §4.4 数据 / §4.5 接口 / §4.6 前端**
-> (frontend when `uiInScope=yes`).  
-> **目的**:让方案贴合**本仓库**的 skill / rule / 工程约定，而不是只套 SpecFlow 通用 guidance。  
-> **懒加载**:按主题按需 `Read`，禁止一次灌入全部 IDE rules。  
-> **Not** an MCP tool; **禁止** `invoke /xxx skill` —— 一律解析路径后 `Read`。
-
----
-
-## 0. Priority (冲突时必须遵守)
-
-```text
-① 项目约定 + 现网代码/DDL/OpenAPI   >   ② SpecFlow Guidance Pack   >   ③ LLM 常识
-```
-
-- ① 决定「能不能做、禁令、现网形状」。
-- ② 只补强「怎么写清楚」(如完整 CREATE TABLE、接口失败示例骨架)。
-- ②/③ **不得**覆盖 ①(例:项目约定「本迭代禁止迁移」时,不得按通用 skill 发明 `ALTER`)。
-
-Announce after resolve:
-
-```text
-Project conventions (architecture|api|database|frontend): <paths…> | none
-Conflict policy: project > SpecFlow guidance > LLM
-```
-
----
-
-## 1. Topics (何时加载)
-
-| 主题 `topic` | 何时 **必须**跑本路由 | 典型要找的内容 |
-|--------------|----------------------|----------------|
-| `architecture` | 起草 **§3** 前 | 分层、模块边界、目录约定、禁止直连 |
-| `database` | 起草 **§4.4** 前(且有持久化) | 迁移工具禁令、命名、字符集、现网表规范 |
-| `api` | 起草 **§4.5** 前(且有对外/跨端接口) | 错误码、鉴权、契约/OpenAPI、通道;然后 **`api-guidance.md`**(分层、RPC 锁名、proto 可生成包) |
-| `frontend` | 起草 **§4.6** 前(且 `uiInScope=yes`) | 组件/状态/路由/API client/设计系统/**表单/测试/a11y** 等落地约定;须含 IDE skills/rules 扫描(见 `frontend-guidance.md` §3) |
-
-每个主题 **最多 Read 5 个文件**(配置列出的优先;自动探测时取最相关的前 5 个)。细节 references 仅在入口文件点名时再读(禁止 reference 链式跳转)。
-
----
-
-## 2. Resolve paths (跨 IDE)
-
-### 2.1 显式配置(最高优先)
-
-读 `specflow/config.yaml` → `conventions.<topic>`(字符串路径数组,相对项目根)。  
-有配置则 **只 Read 这些路径**(仍受「最多 5 个」限制);缺文件 → WARNING。
-
-```yaml
-conventions:
-  architecture:
-    - docs/engineering/architecture.md
-  api:
-    - docs/api/guidelines.md
-  database:
-    - docs/db/conventions.md
-  frontend:
-    - docs/frontend/conventions.md
-```
-
-### 2.2 自动探测(无配置时)
-
-1. 判定 `activeIde`(本会话 IDE):Cursor / Claude / Codex。  
-2. **先**扫 activeIde 候选。  
-3. 若无命中:按 `cursor → claude → agents` 回退扫同主题候选。  
-4. 再扫**仓根中立**路径。  
-5. 仍无 → `none`(允许继续,但总则/架构说明须写「未发现项目级约定」)。
-
-#### 候选路径表
-
-**仓根中立(跨 IDE 推荐真相源)**
-
-| topic | 候选(存在则纳入) |
-|-------|------------------|
-| `architecture` | `docs/engineering/architecture.md`, `.specflow/conventions/architecture.md`, `ARCHITECTURE.md` |
-| `api` | `docs/api/guidelines.md`, `docs/engineering/api.md`, `.specflow/conventions/api.md` |
-| `database` | `docs/db/conventions.md`, `docs/engineering/database.md`, `.specflow/conventions/database.md` |
-| `frontend` | `docs/frontend/conventions.md`, `docs/frontend/patterns.md`, `docs/frontend/testing.md`, `docs/engineering/frontend.md`, `.specflow/conventions/frontend.md`, `agent_docs/tech_stack.md`, `agent_docs/code_patterns.md`, `agent_docs/testing.md` |
-
-**Cursor**
-
-| topic | 候选 |
-|-------|------|
-| 通用 | `.cursor/rules/**/*.mdc` 中文件名/标题含 architecture\|api\|database\|db\|frontend\|backend\|ui\|react\|vue\|component\|tailwind\|a11y\|playwright 的条目(每主题最多 2) |
-| skill | `.cursor/skills/**/SKILL.md` 目录名或 frontmatter `name`/`description` 匹配主题关键词 |
-
-**Claude**
-
-| topic | 候选 |
-|-------|------|
-| 通用 | `CLAUDE.md`, `.claude/CLAUDE.md`(整文件较大时只提取与主题相关章节) |
-| skill | `.claude/skills/**/SKILL.md`(主题关键词匹配) |
-| rules | `.claude/rules/**/*`(若存在;同名过滤) |
-
-**Codex**
-
-| topic | 候选 |
-|-------|------|
-| 通用 | `AGENTS.md`(提取与主题相关段落) |
-| skill | `.agents/skills/**/SKILL.md`(主题关键词匹配) |
-
-关键词提示:
-
-- `architecture|arch|分层|模块`
-- `api|openapi|rpc|接口|错误码`
-- `database|db|sql|迁移|schema`
-- `frontend|ui|react|vue|next|svelte|tailwind|component|控制台|页面|组件|表单|路由|a11y|playwright|vitest|样式|design.?system`
-
-> **前端专题**:`topic=frontend` 时 **必须**按 `frontend-guidance.md` §3 扩扫 IDE skills/rules
-> 与落地文档(状态/表单/测试/a11y 等);不要只命中一个泛化的「frontend」文件名就停。
-
----
-
-## 3. How to apply (写入方案时)
-
-1. **用可读中文**把约定写进 §2.1 / §3 图要点 / §4.4 / §4.5 / §4.6(禁止代码腔堆砌)。
-2. **硬禁令**原样保留语义(例:「本迭代禁止 goose 迁移」)。  
-3. 与 SpecFlow DB/API 硬门槛同时满足:项目禁令优先;表达骨架用 SpecFlow 规则。  
-4. 在对应章节**标明来源路径**(总则「项目约定」列,或架构图要点首条)。  
-5. 若探测到约定文件但正文未体现关键禁令 → 确认摘要 / §8(若有)记 `WARNING`:  
-   `发现项目约定 <path> 但方案未采纳关键约束`。
-
----
-
-## 4. Interaction with SpecFlow database guidance
-
-写 §4.4 时顺序固定:
-
-1. 本路由 `topic=database`(项目约定)  
-2. `prompts/approval/database-guidance.md`(SpecFlow pack + dbStack)  
-3. 现网 DDL / 迁移 / 锚点文件(Pass 6)  
-4. 起草:表形状与禁令 ← ①+③;DDL 完整度与类型惯例 ← ②  
-
-§4.4.1 总则必须同时填写:
-
-| 项 | 说明 |
-|----|------|
-| 项目约定 | 实际 Read 到的路径,或 **未发现** |
-| DB 技能 | SpecFlow guidance 路径或 `LLM-fallback` |
-| DDL 来源 | 迁移/基线路径或本迭代新增 |
-
----
-
-## 4b. Interaction with frontend guidance
-
-写 §4.6 时顺序固定:
-
-1. 本路由 `topic=frontend`(项目约定 docs + IDE skills/rules 关键词匹配)  
-2. **强制**再跑 `prompts/approval/frontend-guidance.md` §3 —— 补扫开发落地维
-   (组件/路由/状态/表单/API client/样式/a11y/测试/lint);与步骤 1 **去重**,合计 ≤5 文件  
-3. 现网路由/布局/API client 锚点(Pass 6)  
-4. 起草:页面/组件边界与禁令 ← ①+②+③;章节骨架与 G5/G6 ← `frontend-guidance` 其余条款  
-
-§4.6.1 总则必须填写:
-
-| 项 | 说明 |
-|----|------|
-| 项目约定 | config + 中立 docs 路径,或 **未发现** |
-| IDE skills/rules | 实际 Read 的 `.cursor/.claude/.agents` skill/rule 路径,或 **未发现** |
-| FE 栈 | 五元组 |
-
-无 UI → 整章省略。发现约定但方案未采纳 → WARNING。
-
----
-
-## 5. Why this shape
-
-- IDE 目录不同 → 用 **activeIde + 回退 + 中立 docs** 统一发现,不强迫业务仓只选一个 IDE。  
-- 上下文有限 → **按主题懒加载**,最多 3 文件。  
-- 贴合项目 → **优先级写死**,并要求总则可核对来源。

package/prompts/approval/runtime-guidance.md

@@ -1,64 +0,0 @@
-# Approval · Runtime Semantics Guidance (optional domain pack)
-
-> **Optional** — load only when the change design touches async execution, leases, retries,
-> cancellation, LWW/idempotency keys, or result-ingest validation.
->
-> **Not** part of default Stage 12e checklist. Use when analysis/design mentions these topics;
-> then add checks from §2 to AI review findings for **this change only**.
-
----
-
-## 1. When to load
-
-| Signal in design/analysis | Action |
-|---------------------------|--------|
-| Job lease, reclaim, retry, duplicate execution | §1.1 |
-| User/system cancel, abort, teardown | §1.2 |
-| Step/job status enum vs ingest validator | §1.3 |
-| None of the above | **Skip this file** |
-
----
-
-## 2. Mandatory decisions (pick one per topic — when in scope)
-
-### 2.1 Retry / reclaim vs accumulated state
-
-When the same execution key can run again, document how prior partial state is handled:
-
-| Option | Write in approval |
-|--------|-------------------|
-| **A wipe** | Clear prior results before re-run |
-| **B epoch/version** | Reads/writes scoped by epoch or version |
-| **C no retry** | Disable retry for this execution type |
-
-**Hard**: add decision row + §4 scenario + testable AC. **Forbidden**: leave unspecified when retry exists in design.
-
-### 2.2 Cancel / abort
-
-When cancel is in scope:
-
-- Document abort behavior (in-flight work, teardown, partial commit)
-- Terminal status for cancelled runs
-- §4.3 sequence for cancel path
-
-### 2.3 Status ingest / validator alignment
-
-When external ingest validates status values:
-
-- Document the **closed** allowed set
-- **Forbidden**: doc lists values outside validator unless same iteration changes validator
-
----
-
-## 3. AI review hook (when loaded)
-
-Add targeted findings (category `runtime_semantics`) — do not apply to changes without these topics.
-
-```yaml
-design_points: [P<n>-retry-policy, P<n>-cancel]
-acp:
-  review:
-    enabled: true
-```
-
-Cross-links: `api-guidance.md` (contract layers), `ai-review.md` (generic R9 unclosed branches).