@aipper/aiws-spec 0.0.33 → 0.0.34

package/docs/aiws-bootstrap-routing-design.md

@@ -2,75 +2,33 @@
 
 ## 目标
 
-把 `aiws` 从“提供一组可显式调用的 `ws-*` 入口”推进到“默认先接管 workflow，再决定进入哪个入口”的治理系统，并先把 `Codex / Claude Code / OpenCode` 的目录真值固定下来，避免后续 bootstrap / router / 安装器继续建立在错误路径假设上。
+把 `aiws` 从“提供一组可显式调用的 `ws-*` 入口”推进到“默认先接管 workflow，再决定进入哪个入口”的治理系统，并先把  的目录真值固定下来，避免后续 bootstrap / router / 安装器继续建立在错误路径假设上。
 
 ## 本次查档结论（2026-03-30）
 
-### Claude Code
-
-- 官方文档公开说明的项目级 / 全局级入口是：
-  - skills：`.claude/skills/<skill-name>/SKILL.md` / `~/.claude/skills/<skill-name>/SKILL.md`
-  - 自定义 slash commands（legacy compatible）：`.claude/commands/` / `~/.claude/commands/`
-  - subagents：`.claude/agents/` / `~/.claude/agents/`
-- 官方文档同时说明：`.claude/commands/*.md` 仍然可用，但若 skill 与 command 同名，skill 优先。
-
 ### OpenCode
 
 - 官方文档公开说明的 native 目录是：
   - skills：`.opencode/skills/` / `~/.config/opencode/skills/`
   - commands：`.opencode/commands/` / `~/.config/opencode/commands/`
-- OpenCode 官方文档同时说明会检测其它 agent 生态目录，包括：
-  - `.agents/skills/`
-  - `.claude/commands/`
-  - `.claude/skills/`
-
-### Codex
-
-- 本次检索到的 OpenAI 官方公开页面没有明确给出 “Codex skills 全局目录”的公开路径说明。
-- 因此，`Codex` 的目录结论需要明确标记为**推断**：
-  - repo-local：`.agents/skills/`
-  - global：`~/.agents/skills/`
-- 这个推断依据是：
-  - 当前 Codex 运行环境与生态使用习惯都以 `.agents/skills/` 为项目内 skills 目录
-  - OpenCode 官方文档也把 `.agents/skills/` 视为兼容可发现目录
-- 在找到 OpenAI 官方公开页面直接写明路径前，不再把 `~/.codex/skills/` 当成长期目录真值。
 
 ## 固定下来的目录决策
 
 ### 1. repo 内 workflow skill 的目标投影
 
-- `Codex` / agent-compatible：
-  - `.agents/skills/<skill-name>/SKILL.md`
-- `Claude Code` native：
-  - `.claude/skills/<skill-name>/SKILL.md`
 - `OpenCode` native：
   - `.opencode/skills/<skill-name>/SKILL.md`
 - 设计原则：
   - workflow instruction 的单一真值仍然留在 `packages/spec/`
-  - 目标仓库可以投影到多个 tool-native 目录
-  - 不能再把 `.agents/skills/` 单独当成覆盖所有工具的唯一目标目录
-
-### 2. Codex 全局 skills 安装目标
-
-- 设计真值改为：`~/.agents/skills/<skill-name>/SKILL.md`
-- 不再把 `~/.codex/skills/` 作为长期默认目录
-- 当前实现若仍写入 `~/.codex/skills/`，视为第一版实现遗留；后续通过单独实现条目迁移
+  - 目标仓库投影到 OpenCode native 目录
 
-### 3. Claude Code 入口策略
-
-- native workflow skill 目录：
-  - `.claude/skills/<skill-name>/SKILL.md`
-- 如后续确有必要引入 agent 角色：
-  - `.claude/agents/*.md`
-- `.claude/commands/*.md` 继续保留为 legacy compatibility / command-style entrypoint，但不再作为唯一长期真值
-
-### 4. OpenCode 入口策略
+### 2. OpenCode 入口策略
 
 - native 真值应记录为：
   - skills：`.opencode/skills/`
   - commands：`.opencode/commands/`
 - 由于当前仓库仍有 `.opencode/command/`（单数）遗留，先明确它是**legacy compatibility path**，不再把它当未来默认路径
-- 由于 OpenCode 可兼容读取 `.agents/skills/`，repo 共享 workflow skills 仍保持在 `.agents/skills/`
+
 
 ## Bootstrap / Router 设计
 
@@ -106,9 +64,7 @@
 
 ### 需要被后续实现修正的点
 
-- `aiws codex install-skills` 的默认全局目录应从 `~/.codex/skills` 调整为 `~/.agents/skills`
-- 若后续增加 Claude 全局 skills 安装，目标应是 `~/.claude/skills/`，不是继续只投递到 `~/.claude/commands/`
-- 若后续增加 OpenCode 全局 skills 安装，目标应是 `~/.config/opencode/skills/`
+- 后续增加 OpenCode 全局 skills 安装，目标应是 `~/.config/opencode/skills/`
 - OpenCode 的 native commands 路径长期应对齐到 `.opencode/commands`，不再把 `.opencode/command` 当默认真值
 - 需要新增 bootstrap / router 入口，而不是继续完全依赖使用者手工显式调用 `$ws-plan` / `$ws-dev` / `$ws-review`
 
@@ -121,7 +77,6 @@
 ## 条目拆分与当前状态
 
 1. 目录对齐实现：
-   - Codex 全局 skills 目录迁移
    - OpenCode native commands 目录迁移
    - 当前已由 `TOOLING-002G` 落地
 2. workflow bootstrap / router：

package/docs/aiws-governance-positioning.md

@@ -2,7 +2,7 @@
 
 ## 一句话定位
 
-`aiws` 不是“把模板分发到 Claude Code / OpenCode / Codex 的 CLI 薄封装”，而是以 `packages/spec/` 为单一真值，通过 workflow contracts 统一约束、门禁、协同和证据的 AI workspace 工作流治理系统。
+`aiws` 不是“把模板分发到 OpenCode 的 CLI 薄封装”，而是以 `packages/spec/` 为单一真值，通过 workflow contracts 统一约束、门禁、协同和证据的 AI workspace 工作流治理系统。
 
 CLI 分发能力依然重要，但它只是治理内核的一层实现，不是产品的全部定义。
 

package/docs/cli-interface.md

@@ -33,9 +33,7 @@
 语义：
 - 在目标仓库根目录写入/补齐模板（默认 `workspace`）。
 - 默认生成 required + optional 文件/目录。
-- 写入/更新 tool-native 文件（默认覆盖 Claude/OpenCode/Codex）：
-  - Codex repo skills：`.agents/skills/`
-  - Claude Code native skills + compatibility commands：`.claude/skills/` + `.claude/commands/`
+- 写入/更新 tool-native 文件：
   - OpenCode native skills + native commands + legacy compatibility commands：`.opencode/skills/` + `.opencode/commands/` + `.opencode/command/`
 - 写入/更新 `.gitignore` 的 aiws 托管块（其余内容保留）。
 - 生成并写入 `.aiws/manifest.json`：
@@ -99,90 +97,32 @@
 接口（仅定义）：
 - `aiws validate [path] [--stamp]`
 
-## `aiws codex install-skills`
-
-背景：
-- Codex 推荐使用 repo skills（`.agents/skills/`）；但对于“未初始化的任意仓库”，用户可能仍希望能直接调用一组通用 skills（如 `$ws-dev`、`$ws-preflight`）来引导回 AIWS 工作流。
-- 因此提供**全局 skills 安装**：把模板内的 repo skills 安装到 Codex 的全局 skills 目录中，使其在任意仓库都可显式调用（是否自动发现/是否需要重启由 Codex 实现决定；aiws 不做保证）。
+## `aiws opencode install-skills`
 
 语义：
-- 将模板内的 skills（`templates/<template_id>/.agents/skills/*/SKILL.md`）安装到 Codex 的全局 skills 目录：
-  - 默认：`~/.agents/skills/`
-  - 若设置了 `CODEX_HOME`：`$CODEX_HOME/.agents/skills/`（仅作为 compatibility/test override）
-- 幂等：重复执行应只更新 AIWS 托管块，不破坏用户在文件托管块外追加的说明。
-- 若目标文件已存在但不含 AIWS 托管块：默认失败（退出码 `2`）；需用户显式 `--force` 才允许覆盖（覆盖前应备份）。
-- 支持预演：`--dry-run` 仅输出将创建/更新/覆盖的 skills 清单，不写入任何文件。
+- 将模板内的 repo skills 安装到全局 skills 目录中，使其在任意仓库都可显式调用。
 
 接口（仅定义）：
-- `aiws codex install-skills [--template <template_id>] [--dir <path>] [--force] [--dry-run]`
-
-> `--dir` 可覆盖默认全局 skills 目录（用于 CI/沙箱验证，避免写入真实 home）。
+- `aiws opencode install-skills [--template <template_id>] [--dir <path>] [--force] [--dry-run]`
 
-## `aiws codex status-skills`
+## `aiws opencode status-skills`
 
 语义：
-- 检查 Codex 全局 skills 目录中，模板期望的 skills 是否就绪，并输出每个 skill 的状态：
-  - `ok`：存在且 AIWS 托管块与模板一致
+- 检查 OpenCode 全局 skills 目录中，模板期望的 skills 是否就绪，并输出每个 skill 的状态：
+  - `ok`：存在且与模板一致
   - `missing`：不存在
-  - `unmanaged`：存在但不含 AIWS 托管块（aiws 不会自动覆盖）
-  - `outdated`：存在且含 AIWS 托管块，但块内内容与模板不一致（建议重新 `install-skills`）
 - 默认只做信息输出（不修改任何文件；退出码 `0` 表示命令执行成功，不代表全部为 `ok`）。
 
 接口（仅定义）：
-- `aiws codex status-skills [--template <template_id>] [--dir <path>]`
-
-## `aiws codex uninstall-skills`
-
-语义：
-- 从 Codex 全局 skills 目录卸载 AIWS 托管的 skills：
-  - 仅处理“含 AIWS 托管块”的文件（避免误删用户自建 skills）
-  - 移除前必须备份到：`<skillsDir>/.aiws/backups/codex-skills/<timestamp>/`
-
-接口（仅定义）：
-- `aiws codex uninstall-skills [--template <template_id>] [--dir <path>]`
-
----
-
-## `aiws codex install-prompts`
-
-背景（legacy）：
-- prompts 为遗留机制（deprecated）；优先使用 repo skills（`.agents/skills/`）或全局 skills（`aiws codex install-skills`）。
-- Codex 的自定义 prompts 主要从全局目录发现（通常为 `~/.codex/prompts/`）。
-- 因此项目内的 `.codex/prompts/*.md` 不能保证会被 Codex 自动加载；需要显式安装到全局目录。
-
-语义：
-- 将模板内的 Codex prompt 文件（`templates/<template_id>/.codex/prompts/*.md`）安装到 Codex 的全局 prompts 目录：
-  - 默认：`~/.codex/prompts/`
-  - 若设置了 `CODEX_HOME`：`$CODEX_HOME/prompts/`
-- 幂等：重复执行应只更新 AIWS 托管块，不破坏用户在文件托管块外追加的说明。
-- 若目标文件已存在但不含 AIWS 托管块：默认失败（退出码 `2`）；需用户显式 `--force` 才允许覆盖（覆盖前应备份）。
-- 支持预演：`--dry-run` 仅输出将创建/更新/覆盖的文件清单，不写入任何文件。
-
-接口（仅定义）：
-- `aiws codex install-prompts [--template <template_id>] [--dir <path>] [--force] [--dry-run]`
-
-## `aiws codex status`
-
-语义：
-- 检查 Codex 全局 prompts 目录中，模板期望的 prompts 文件是否就绪，并输出每个文件的状态：
-  - `ok`：存在且 AIWS 托管块与模板一致
-  - `missing`：不存在
-  - `unmanaged`：存在但不含 AIWS 托管块（aiws 不会自动覆盖）
-  - `outdated`：存在且含 AIWS 托管块，但块内内容与模板不一致（建议重新 `install-prompts`）
-- 默认只做信息输出（不修改文件；退出码 `0` 表示命令执行成功，不代表全部为 `ok`）。
-
-接口（仅定义）：
-- `aiws codex status [--template <template_id>] [--dir <path>]`
+- `aiws opencode status-skills [--template <template_id>] [--dir <path>]`
 
-## `aiws codex uninstall-prompts`
+## `aiws opencode uninstall-skills`
 
 语义：
-- 从 Codex 全局 prompts 目录卸载 AIWS 托管的 prompts：
-  - 仅处理“含 AIWS 托管块”的文件（避免误删用户自建 prompts）
-  - 移除前必须备份到：`<promptsDir>/.aiws/backups/codex-prompts/<timestamp>/`
+- 从 OpenCode 全局 skills 目录卸载 AIWS 托管的 skills。
 
 接口（仅定义）：
-- `aiws codex uninstall-prompts [--template <template_id>] [--dir <path>]`
+- `aiws opencode uninstall-skills [--template <template_id>] [--dir <path>]`
 
 ## `aiws hooks install`
 
@@ -350,10 +290,10 @@ Dashboard API（本地只读）：
   - 将生成的证据路径追加回填到：
     - `changes/<change-id>/proposal.md` 的 `Evidence_Path`
     - `Plan_File` 指向的计划文件中的 `Evidence_Path`（若存在）
-  - 若存在 `.agentdocs/tmp/review/codex-review.md` 且 `changes/<id>/review/codex-review.md` 不存在：复制为持久 review 证据。
+  - 若存在 `.agentdocs/tmp/review/review.md` 且 `changes/<id>/review/review.md` 不存在：复制为持久 review 证据。
 - 协同收敛：
   - 若 `analysis/` / `patches/` / `review/` / `evidence/` 目录缺失，会在执行时自动补齐。
-  - 若仅存在 `.agentdocs/tmp/review/codex-review.md` 且 `changes/<id>/review/codex-review.md` 不存在，可先作为有效 review 信号参与阶段推断；执行 evidence 时应复制为持久 review 证据。
+  - 若仅存在 `.agentdocs/tmp/review/review.md` 且 `changes/<id>/review/review.md` 不存在，可先作为有效 review 信号参与阶段推断；执行 evidence 时应复制为持久 review 证据。
   - 若存在 `.agentdocs/tmp/review/spec-review.md`、`.agentdocs/tmp/review/quality-review.md`、`.agentdocs/tmp/review/verify-before-complete.md` 且对应持久路径不存在，执行 evidence 时应同步收敛为持久 gate 证据。
   - 收集 `review/` 下全部 `.md` 文件（支持多 reviewer），并生成 `changes/<id>/evidence/collaboration-summary-<timestamp>.json`。
   - 生成 `changes/<id>/evidence/delivery-summary-<timestamp>.md`，概述协同工件数量、绑定信息、质量门结果与下一步建议。

package/docs/collaboration-artifacts.md

@@ -27,7 +27,7 @@ changes/<change-id>/
 - 外部分析不等于实现完成。主 agent 必须把采用与否的结论写入 `review/` 或最终 handoff。
 - patch 草案不自动应用。主 agent 或人工必须先审查，再决定是否将其转换成真实代码改动。
 - `review/` 允许多人并行，例如：
-  - `codex-review.md`
+  - `review.md`
   - `spec-review.md`
   - `quality-review.md`
   - `reviewer-a.md`
@@ -37,7 +37,7 @@ changes/<change-id>/
   - `changes/<change-id>/review/quality-review.md`
   - `changes/<change-id>/evidence/verify-before-complete.md`
 - `aiws change evidence <change-id>` 应把 review / validate / collaboration summary 收敛到 `evidence/`，并在目标文件缺失时收敛以下 tmp fallback：
-  - `.agentdocs/tmp/review/codex-review.md`
+  - `.agentdocs/tmp/review/review.md`
   - `.agentdocs/tmp/review/spec-review.md`
   - `.agentdocs/tmp/review/quality-review.md`
   - `.agentdocs/tmp/review/verify-before-complete.md`

package/docs/opencode-autonomous-swarm.md

@@ -96,7 +96,6 @@ tmux swarm 只允许做**安全白名单**救援：
 模板提供以下文件：
 
 - `.opencode/oh-my-opencode.json.example`
-- `.claude/settings.json.example`
 - `.opencode/skills/ws-auto/SKILL.md`
 - `.opencode/helpers/tmux-swarm-scan.sh`
 - `.opencode/helpers/tmux-swarm-rescue.sh`
@@ -109,7 +108,6 @@ tmux swarm 只允许做**安全白名单**救援：
 - `.opencode/oh-my-opencode.json.example` 负责声明 agent、`prompt_append`、`backgroundTasks`、`experimental.auto_resume`
 - `.opencode/oh-my-opencode.json.example` 也可声明 `aiws.autonomy.approval_whitelist`
 - `/ws-auto` 与 `aiws opencode auto .` 负责把“需要 update 吗 / watchdog 能否启动”这类 bootstrap 检查前置掉
-- `.claude/settings.json.example` 只作为 hook 兼容层示例，不充当 controller
 - `approval-whitelist-check.sh` 负责把项目级 whitelist policy 转成 `allow` / `deny` / `manual` 判定，并写审计日志
 - `approval-whitelist-run.sh` 负责在 `allow` 场景下执行简单命令，并写执行摘要
 - `approval-whitelist-watchdog.sh` 负责轮询 JSONL 队列，串行调用 runner，并写 watchdog 状态/结果

package/docs/opencode-omo-adapter.md

@@ -115,8 +115,6 @@ CLI 辅助探测：
   - `backgroundTasks`：只用于 analysis / review / doc-search 型并行任务
   - `experimental.auto_resume=true`
   - `aiws.autonomy.approval_whitelist`：只声明只读命令与 evidence 写路径白名单；宿主权限仍是 `manual-only`
-- `.claude/settings.json.example`
-  - 作为 oMo 可读取的 hook 兼容层示例
 - `.opencode/helpers/tmux-swarm-scan.sh`
   - 巡检当前 tmux panes，输出状态摘要
 - `.opencode/helpers/tmux-swarm-rescue.sh`

package/docs/opencode-omo-validation-checklist.md

@@ -87,7 +87,6 @@ aiws opencode status .
 1. 在项目内启用：
 ```bash
 cp .opencode/oh-my-opencode.json.example .opencode/oh-my-opencode.json
-test -f .claude/settings.json.example
 test -f .opencode/helpers/approval-whitelist-check.sh
 test -f .opencode/helpers/approval-whitelist-run.sh
 test -f .opencode/helpers/approval-whitelist-watchdog.sh

package/docs/spec-contract.md

@@ -90,7 +90,7 @@ secrets/test-accounts.json
 - `spec_version`：`@aipper/aiws-spec` 版本
 - `aiws_version`：`@aipper/aiws` 版本
 - `installed_at` / `updated_at`：ISO 8601 UTC 时间
-- `tools`：`["claude","opencode","codex"]` 的子集
+- `tools`：`["opencode"]` 的子集
 - `managed`：托管面清单（文件级或托管块级 hash）
 
 hash 规则（用于跨平台稳定性）：
@@ -109,7 +109,7 @@ hash 规则（用于跨平台稳定性）：
   "aiws_version": "0.0.0",
   "installed_at": "2026-01-25T00:00:00Z",
   "updated_at": "2026-01-25T00:00:00Z",
-  "tools": ["claude", "opencode", "codex"],
+  "tools": ["opencode"],
   "managed": [
     { "path": ".githooks/pre-commit", "mode": "replace_file", "sha256": "<sha256>" },
     { "path": ".gitignore", "mode": "managed_blocks", "blocks": { "gitignore": "<sha256>" } }
@@ -126,45 +126,31 @@ hash 规则（用于跨平台稳定性）：
 
 说明：
 - tool-native 文件是 derived 产物；aiws 按模板 `manifest.json` 的 `update` 策略维护（`managed_blocks` 或 `replace_file`）。
-- 默认覆盖：Claude Code / OpenCode / Codex。
+- 默认覆盖：OpenCode。
 
 约定路径（示例；最终以模板 manifest 为准）：
-- Claude Code native：`.claude/skills/*/SKILL.md`（skills）
-- Claude Code compatibility：`.claude/commands/p-aiws-*.md`（commands；私有原子入口）
 - OpenCode native skills：`.opencode/skills/*/SKILL.md`
 - OpenCode native commands：`.opencode/commands/p-aiws-*.md`
 - OpenCode legacy compatibility：`.opencode/command/p-aiws-*.md`（command；migration window）
-- Codex：`.agents/skills/*/SKILL.md`（skills）
 
 补充（workflow 入口，同样由模板提供；最终以模板 manifest 为准）：
-- Claude Code native：`.claude/skills/ws-*/SKILL.md`
-- Claude Code compatibility：`.claude/commands/ws-*.md`
 - OpenCode native skills：`.opencode/skills/ws-*/SKILL.md`
 - OpenCode native commands：`.opencode/commands/ws-*.md`
 - OpenCode legacy compatibility：`.opencode/command/ws-*.md`
-- Codex：`.agents/skills/ws-*/SKILL.md`
-
-注意（Codex）：
-- Codex 的 repo skills 目录为 `.agents/skills/`（可随仓库共享；prompts 已 deprecated）。
-- 如需在任意仓库也能显式使用 AIWS skills：`aiws codex install-skills` 从模板 `.agents/skills/*/SKILL.md` 安装到 `~/.agents/skills/`。
-- `CODEX_HOME` 或 `--dir` 可作为 compatibility/test override；但不要继续把 `~/.codex/skills/` 当成目录真值。
-- 如仍需使用全局 prompts（遗留机制）：可用 `aiws codex install-prompts` 从模板 `.codex/prompts/*.md` 安装到 `~/.codex/prompts/` 或 `$CODEX_HOME/prompts`。
-
-注意（Claude Code / OpenCode）：
-- 当前 workspace 模板已经同时投影：
-  - Claude Code native skills：`.claude/skills/`
-  - Claude Code command-style compatibility：`.claude/commands/`
+
+注意（目录说明）：
+- 当前 workspace 模板投影了以下路径：
   - OpenCode native skills / commands：`.opencode/skills/` / `.opencode/commands/`
   - OpenCode legacy compatibility：`.opencode/command/`
-- `.claude/commands/` 与 `.opencode/command/` 继续保留为兼容层，但不再作为唯一长期真值。
+- `.opencode/command/` 继续保留为兼容层，但不再作为唯一长期真值。
 
 能力边界（必须在文档中不夸大）：
 - aiws **不保证** 工具会自动加载/自动注册这些文件（是否自动发现、是否需要重启/重新打开会话，由工具实现决定）。
 - aiws 的最低承诺是：这些文件提供一致的“工作流入口”（例如引导执行 `npx @aipper/aiws init|update|validate|rollback`），从而把用户带回同一套真值文件与门禁。
 
 每个文件的托管方式（推荐）：
-- 对于 commands 类文件（如 `.claude/commands/*.md`、`.opencode/commands/*.md`、`.opencode/command/*.md`）：每个文件包含**一个且仅一个**托管块（block id 形如 `claude:aiws-init`）；若文件顶部存在 YAML frontmatter（例如 `description`），`aiws update` 还会同步该 frontmatter，块外正文其余部分保留给用户追加说明。
-- 对于 skills 类文件（`.agents/skills/*/SKILL.md`、`.claude/skills/*/SKILL.md`、`.opencode/skills/*/SKILL.md`）：由于文件顶部 YAML front matter 需要保持一致性，默认采用 `replace_file` 全量托管；如需自定义请新增独立 skill 目录。
+- 对于 commands 类文件（如 `.opencode/commands/*.md`、`.opencode/command/*.md`）：每个文件包含**一个且仅一个**托管块；若文件顶部存在 YAML frontmatter（例如 `description`），`aiws update` 还会同步该 frontmatter，块外正文其余部分保留给用户追加说明。
+- 对于 skills 类文件（`.opencode/skills/*/SKILL.md`）：由于文件顶部 YAML front matter 需要保持一致性，默认采用 `replace_file` 全量托管；如需自定义请新增独立 skill 目录。
 
 最小矩阵（建议写清以下字段，便于未来实现与验收）：
 - `path_pattern`：文件路径模式
@@ -174,21 +160,9 @@ hash 规则（用于跨平台稳定性）：
 - `fallback`：若不生效，用户如何手动触发（直接运行 `npx @aipper/aiws ...`）
 
 建议的默认取值（与 `workspace` 模板一致）：
-- Claude Code
-  - `path_pattern`：`.claude/skills/*/SKILL.md`
-  - `purpose`：提供 native workflow skills；兼容命令入口仍保留在 `.claude/commands/*.md`
-  - `autodiscovery`：不作为契约要求（由工具决定；aiws 不做保证）
-  - `reload_needed`：不作为契约要求
-  - `fallback`：在 shell 直接运行 `npx @aipper/aiws init|update|validate|rollback`
 - OpenCode
   - `path_pattern`：`.opencode/skills/*/SKILL.md` + `.opencode/commands/*.md`
   - `purpose`：提供 native workflow skills 与 native commands；legacy `.opencode/command/*.md` 继续作为迁移兼容层
   - `autodiscovery`：不作为契约要求
   - `reload_needed`：不作为契约要求
-  - `fallback`：同上
-- Codex
-  - `path_pattern`：`.agents/skills/*/SKILL.md`
-  - `purpose`：提供 skills（显式 `$<skill>` 或隐式套用工作流），引导用户运行 `npx @aipper/aiws ...`
-  - `autodiscovery`：不作为契约要求（由工具决定；aiws 不做保证）
-  - `reload_needed`：不作为契约要求
-  - `fallback`：显式使用 `$ws-preflight` / `$ws-plan` / `$ws-dev` / `$ws-review` / `$ws-commit`（或在 shell 直接运行 `npx @aipper/aiws init|update|validate|rollback`）
+  - `fallback`：在 shell 直接运行 `npx @aipper/aiws init|update|validate|rollback`

package/docs/workflow-router-rules.json

@@ -222,7 +222,7 @@
     {
       "id": "case_direct_implementation",
       "scenario": "任务是小步明确修复，归因和验证入口都已清楚。",
-      "request": "修复 codex install-skills 的默认路径，并补一条可复现回归。",
+      "request": "修复 install-skills 的默认路径，并补一条可复现回归。",
       "expectedRuleId": "direct_implementation",
       "expectedRoute": "ws-dev",
       "why": "小步明确实现允许直接进入 dev；若用户明确要轻量直修，可进一步显式使用 ws-dev-lite，但治理归属仍收敛到 ws-dev。"
@@ -278,6 +278,6 @@
   "notes": [
     "default-routed workflow 不等于 daemon / pane / runtime orchestration；这一版只固定真值和入口。",
     "`using-aiws` 可以作为默认入口；若未来需要更短命名，可再引入 `ws-router` 作为等价别名。",
-    "Claude/OpenCode/Codex 的 native 目录不同，但 router 语义必须共用同一份 JSON 真值。"
+    "OpenCode 的 native 目录不同，但 router 语义必须共用同一份 JSON 真值。"
   ]
 }

package/docs/workflow-router-rules.md

@@ -65,7 +65,7 @@ router 在做任何 workflow 判断前，必须先读取：
 | `case_finish_request` | 用户要求合并、push、cleanup 或 finish 当前 change。 | 把 demo-change finish 掉并 push，顺便 cleanup。 | `finish_request` | `ws-finish` | finish 是独立治理阶段，必须先走 finish gate。 |
 | `case_handoff_request` | 用户要求 handoff、交接说明、archive summary 或接力文档。 | 给这个 change 写 handoff，并补 archive summary。 | `handoff_request` | `ws-handoff` | handoff 依赖已有 finish/archive 上下文，不能当成普通实现。 |
 | `case_plan_first` | 任务是跨文件、多步实现，且需要先建立 change 分支或方案。 | 实现 dashboard 的阶段治理视图并补测试，需要新建 change 和计划。 | `plan_first` | `ws-plan` | 中大型实现应先落盘计划，再进入 dev。 |
-| `case_direct_implementation` | 任务是小步明确修复，归因和验证入口都已清楚。 | 修复 codex install-skills 的默认路径，并补一条可复现回归。 | `direct_implementation` | `ws-dev` | 小步明确实现允许直接进入 dev；若用户明确要轻量直修，可进一步显式使用 ws-dev-lite，但治理归属仍收敛到 ws-dev。 |
+| `case_direct_implementation` | 任务是小步明确修复，归因和验证入口都已清楚。 | 修复 install-skills 的默认路径，并补一条可复现回归。 | `direct_implementation` | `ws-dev` | 小步明确实现允许直接进入 dev；若用户明确要轻量直修，可进一步显式使用 ws-dev-lite，但治理归属仍收敛到 ws-dev。 |
 | `case_context_gate` | Router 必须先收集项目上下文再判 direct vs plan。 | 修复一个 auth bug。 | `direct_implementation` | `ws-dev` | Router 必须先 git status/读相关文件确认范围后才能判 direct；`precondition` 字段显式要求先收集上下文；不能仅凭任务描述判"小步"。 |
 | `case_escape_hatch` | 用户说'跳过流程直接改' | "别走流程了，直接改" | `escape_hatch` | `ws-dev-lite` | 显式跳过但遵守最小约束 |
 | `case_design_first` | 任务需要先出设计方案再进入实现。 | 设计 dashboard 架构，出方案后再实现。 | `design_first` | `ws-plan` | 高影响改动应先出设计方案，过审后再投入实现。当前通过 ws-plan 统一承载设计。 |
@@ -92,4 +92,4 @@ router 在做任何 workflow 判断前，必须先读取：
 
 - default-routed workflow 不等于 daemon / pane / runtime orchestration；这一版只固定真值和入口。
 - `using-aiws` 可以作为默认入口；若未来需要更短命名，可再引入 `ws-router` 作为等价别名。
-- Claude/OpenCode/Codex 的 native 目录不同，但 router 语义必须共用同一份 JSON 真值。
+- OpenCode 的 native 目录不同，但 router 语义必须共用同一份 JSON 真值。

package/docs/ws-goal-contract.md

@@ -6,9 +6,9 @@ ws-goal 协议层规范：目标定义、完成审计、预算约束与工具适
 
 ## 1. Background & Motivation
 
-### Codex /goal 的五层架构
+### /goal 类指令的五层架构
 
-Codex 在 0.128.0+ 版本中引入了 `/goal` 指令。它的实现分五层：
+一些工具引入了 `/goal` 类指令。它的实现分五层：
 
 | 层 | 实现 | 职责 |
 |---|---|---|
@@ -32,7 +32,7 @@ aiws 当前没有等价协议。OpenCode + oh-my-opencode 已经提供了 3 层
 
 ### 方案：ws-goal 作为协议层
 
-ws-goal 定义为**协议层**（prompt-template + artifact spec），不是运行时引擎。它负责任务目标的结构化定义、完成审计的证据规范、预算耗尽协议。续跑调度继续借用各平台已有的能力（OpenCode 的 Ralph Loop / Ultrawork，Codex 的 /goal runtime，Claude Code 的自然续跑）。
+ws-goal 定义为**协议层**（prompt-template + artifact spec），不是运行时引擎。它负责任务目标的结构化定义、完成审计的证据规范、预算耗尽协议。续跑调度继续借用各平台已有的能力。
 
 这样做的好处是：不重复造 runtime，不绑定特定工具，只写一份规范就能投影到所有平台。
 
@@ -60,14 +60,14 @@ active → paused (optional) → complete | budget_limited → archived
 ```
 
 - **active**：目标正在执行中。可能有多个 iteration
-- **paused**（可选）：目标被暂停。运行时能力取决于平台（Codex 原生支持 pause/resume，OpenCode 只能 cancel）
+- **paused**（可选）：目标被暂停。运行时能力取决于平台。
 - **complete**：完成审计通过，目标已被证明达成
 - **budget_limited**：预算耗尽，目标未完成但无法继续。产生进度报告和 TODO 列表供继续
 - **archived**：最终状态。goal artifact 归档到 evidence 目录
 
 ### 2.3 Completion Audit Protocol
 
-改编自 Codex continuation.md 的 8 步完成审计方法：
+8 步完成审计方法：
 
 1. **Derive requirements**：从 objective 推导出具体的、可验证的需求列表。不是重复 objective 原文，而是分解为可逐个检查的原子项
 2. **Preserve scope**：保持原始目标范围。不要将"已经做了什么"重新定义为目标——audit 评判的是原始目标是否达成
@@ -171,16 +171,13 @@ token_budget 依赖平台的 token 计数器。aiws 不提供独立的 token 监
 
 | Tool | Continuation Engine | Goal Persistence | Budget Tracking | Audit Method |
 |---|---|---|---|---|
-| **Codex** | `/goal` auto-continuation（Rust runtime，内置 turn 调度） | `thread_goals` DB（Rust 状态表，pursuing/paused/achieved/budget_limited） | 内置 token counter + `budget_limit.md` 软停止 | 模型自检 + continuation.md 8 步审计（prompt 内） |
 | **OpenCode** | Ralph Loop L2（`/ralph-loop` 自引循环） / Ultrawork L3（Ralph Loop + Oracle 审计） | `.opencode/ralph-loop.local.md`（YAML frontmatter，active/iteration 状态） | max_iterations 硬限制（L2），无 token/time budget | L2: `<promise>DONE</promise>` 语义声明；L3: Oracle 独立审计 + `<promise>VERIFIED</promise>` |
-| **Claude Code** | Claude Code 原生 session continuation（无特殊 runtime） | 无内置 goal 持久化。支持通过文件系统手动管理 | 无。用户手动控制 | 人工 review。无自动化审计链路 |
-| **aiws ws-goal protocol** | 不提供。依赖各平台已有 continuation 引擎 | `.aiws/goals/<goal-id>.md`（标准模板工件）+ `changes/<id>/evidence/` 审计证据 | 定义协议但依赖平台 token 计数器。aiws 只做格式规范和软停止信号定义 | 8 步完成审计（协议层规范，平台层执行） |
+| **aiws ws-goal protocol** | 不提供。依赖各平台已有 continuation 引擎 | `.aiws/goals/<goal-id>.md`（标准模板工件）+ `changes/<id>/evidence/` 审计证据 | 定义协议但依赖平台能力 | 8 步完成审计（协议层规范，平台层执行） |
 
 ### 关键说明
 
 - **OpenCode L2 vs L3**：L2 只有自检声明（DONE），可信度较低；L3 引入独立审计者（Oracle），可信度较高但成本也高。ws-goal 协议推荐的审计模式是 L3，但允许 L2 作为轻度使用的降级
-- **Codex 的特殊性**：Codex 的 `/goal` 和 ws-goal 协议不是竞争关系。ws-goal 协议可以投影到 Codex 时直接绑定 `/goal` 的 continuation 能力，只需补充完成审计的规范约束
-- **Claude Code 的局限性**：Claude Code 没有等效的 Ralph Loop 或 /goal 运行时。ws-goal 在 Claude Code 上的能力受限于平台本身的续跑机制
+- ws-goal 协议可以投影到各平台时绑定其 continuation 能力，只需补充完成审计的规范约束
 
 ---
 
@@ -191,18 +188,14 @@ token_budget 依赖平台的 token 计数器。aiws 不提供独立的 token 监
 ws-goal 协议层不实现任何 continuation/scheduling/pause/resume 机制。这些能力完全依赖于各平台：
 
 - OpenCode：依赖 Ralph Loop（文件状态轮询 + prompt 注入）
-- Codex：依赖 /goal 的 Rust runtime（turn 调度 + 数据库）
-- Claude Code：依赖用户手动管理
 
-这意味着跨工具的"暂停/恢复"行为会不一致。Codex 原生支持 Ctrl+C 暂停 + resume 恢复，OpenCode 只能 cancel 重跑，Claude Code 没有等效功能。
+这意味着跨工具的"暂停/恢复"行为会不一致。
 
 ### 5.2 Budget Tracking 依赖平台能力
 
 token_budget 和 time_budget 的监控需要平台提供接口。当前：
 
-- Codex：内置 token counter，支持软停止
 - OpenCode（oh-my-opencode）：无 token 计数，只有 max_iterations
-- Claude Code：无任何 budget tracking
 
 aiws 只定义"预算耗尽时应该做什么"的协议，不提供跨平台的统一计费层。在缺少平台支持的维度上，goal 应标记为 unsupported 而不是假装能工作。
 
@@ -210,23 +203,21 @@ aiws 只定义"预算耗尽时应该做什么"的协议，不提供跨平台的
 
 不同工具使用不同的持久化机制：
 
-- Codex：服务端 `thread_goals` 数据库（跨客户端同步）
 - OpenCode（Ralph Loop）：文件 `.opencode/ralph-loop.local.md`（会话级）
-- Claude Code：无内置持久化
 
-没有共享数据库。如果一个目标在 Codex 中开始，无法在 OpenCode 中恢复。goal objective markdown 文件 `.aiws/goals/<goal-id>.md` 可以作为人类可读的参考，但状态同步不保证。
+没有共享数据库。如果一个目标在一个工具开始，无法在另一个工具中恢复。goal objective markdown 文件 `.aiws/goals/<goal-id>.md` 可以作为人类可读的参考，但状态同步不保证。
 
 ### 5.4 State Machine 的工具依赖
 
 完整状态机 `active → paused → complete | budget_limited → archived` 中各状态的支持情况：
 
-| 状态转换 | Codex | OpenCode (Ralph Loop) | Claude Code |
-|---|---|---|---|
-| active → paused | 原生支持（Ctrl+C） | 不支持（只能 cancel） | 不支持 |
-| paused → active | 原生支持（resume） | 不支持 | 不支持 |
-| active → complete | 支持（模型调用 update_goal） | 支持（DONE 声明 + oracle 验证） | 手动 |
-| active → budget_limited | 支持（budget_limit.md 软停止） | 不支持 | 不支持 |
-| complete → archived | 自动 | 手动 | 手动 |
+| 状态转换 | OpenCode (Ralph Loop) |
+|---|---|---|
+| active → paused | 不支持（只能 cancel） |
+| paused → active | 不支持 |
+| active → complete | 支持（DONE 声明 + oracle 验证） |
+| active → budget_limited | 不支持 |
+| complete → archived | 手动 |
 
 aiws 协议层定义了完整的语义状态，但各平台只能实现其中一部分。goal 创建时应注意平台的能力边界。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aipper/aiws-spec",
-  "version": "0.0.33",
+  "version": "0.0.34",
   "description": "AIWS spec and templates (single source of truth).",
   "type": "module",
   "files": [

package/templates/workspace/.aiws/continuation/CONTINUATION_PROTOCOL.md

@@ -0,0 +1,101 @@
+# ws-* Pipeline Continuation Protocol
+
+## 问题
+
+每个 ws-* skill 完成当前 phase 后输出 `Next:` 文本建议，然后停下。用户需要手动输入下一 phase 的 slash 命令。本协议定义了一套标准化机制，让所有 ws-* skill 在完成后自动推进到下一 phase。
+
+## 核心机制
+
+### 1. Pipeline 状态文件
+
+`.aiws/continuation/pipeline.json` — 共享状态文件，记录当前流水线所有 phase 的状态。
+
+```json
+{
+  "pipeline_id": "<pipeline-id>",
+  "goal_id": "<goal-id>",
+  "change_id": "<change-id>",
+  "created_at": "<UTC timestamp>",
+  "updated_at": "<UTC timestamp>",
+  "phases": [
+    {"name": "preflight",    "status": "completed",   "evidence": ""},
+    {"name": "ws-goal",      "status": "completed",   "evidence": ".aiws/goals/<goal-id>.md"},
+    {"name": "ws-plan",      "status": "in_progress", "evidence": ""},
+    {"name": "ws-plan-verify","status": "pending",    "evidence": ""},
+    {"name": "ws-dev",       "status": "pending",     "evidence": ""},
+    {"name": "ws-review",    "status": "pending",     "evidence": ""},
+    {"name": "ws-commit",    "status": "pending",     "evidence": ""},
+    {"name": "ws-finish",    "status": "pending",     "evidence": ""}
+  ],
+  "current_phase_index": 2,
+  "blockers": []
+}
+```
+
+状态值: `pending` | `in_progress` | `completed` | `blocked`
+
+### 2. Phase Completion Protocol（所有 ws-* skill 共享）
+
+每个 ws-* skill 完成后执行（替代原有 `Next:` 输出 + 结束）：
+
+```
+1. 更新 pipeline.json：
+   - 当前 phase → status: "completed", evidence: <路径>
+   - 下一 phase → status: "in_progress"
+   - current_phase_index → 下一 phase 索引号
+   - updated_at → 当前时间
+
+2. 更新 todo：
+   - 当前 phase 的 todo → completed
+   - 下一 phase 的 todo → in_progress（若还不存在则创建）
+
+3. 若还有下一 phase：
+   - 输出 "→ Auto-continuing to <next_phase>"
+   - 立即开始执行下一 phase 的逻辑（不输出"是否继续"等待文本）
+
+4. 若已是最后一个 phase：
+   - 输出 pipeline 完成摘要
+   - 标记 goal 为 complete
+```
+
+### 3. Continuation Detection（所有 ws-* skill 共享）
+
+当 skill 被调用时（包括 slash command 直接调用 和 Boulder/Ralph Loop continuation）：
+
+```
+检查 .aiws/continuation/pipeline.json：
+- 若存在且有 in_progress phase：
+  a) 如果 in_progress phase 名称 == 当前 skill 名称 → 正常执行当前 skill
+  b) 如果 in_progress phase 名称 ≠ 当前 skill 名称 → 跳到该 phase 的执行逻辑
+  c) 如果所有 phase completed → 输出 pipeline 完成摘要，不再执行新工作
+- 若不存在 → 正常执行当前 skill（独立模式）
+```
+
+### 4. Skill Entry 改造
+
+每个 ws-* SKILL.md 顶部增加 Pipeline Continuation Detection 段。
+
+### 5. Skill Ending 改造
+
+每个 ws-* SKILL.md 的 `输出要求` / `Next:` 段替换为 Phase Completion Protocol。
+
+### 6. ws-goal 作为 Pipeline 启动器
+
+ws-goal 在复杂度评估后：
+- 创建 pipeline.json（预填所有 phase）
+- 创建所有 phase 对应的 todo
+- 直接执行第一个 phase 的逻辑（不停下）
+
+## 默认 Pipeline 链路
+
+preflight → ws-goal → ws-plan → ws-plan-verify → ws-dev → ws-review → ws-commit → ws-finish
+
+根据复杂度评估选择包含哪些 phase：
+- 简单路径: ws-goal → dev → commit → finish
+- 标准路径: ws-goal → plan → plan-verify → dev → review → commit → finish
+- 复杂路径: 标准路径 + intake + deliver + handoff
+
+## 文件位置
+
+- 状态文件: `.aiws/continuation/pipeline.json`
+- 协议文档: `.aiws/continuation/CONTINUATION_PROTOCOL.md`