cowork-flow 0.0.20 → 0.0.21

package/template/.cowork-flow/workflow.md

@@ -5,41 +5,41 @@
 默认执行模型固定为：
 
 ```text
-Plan -> Implement -> Check -> Finish
+changes -> brainstorming -> read spec -> plan -> tasks -> implement -> check -> complete
 ```
 
 核心路径：
 
-1. Plan: 建立任务、明确 PRD、整理 `implement.jsonl` / `check.jsonl`。
-2. Implement: 主会话用 `spawn_agent` 派发 `cowork-implement`，`fork_turns="none"`，先发 `COWORK_DISPATCH_V1` 信封并等待 `COWORK_ACK`。
-3. Check: 主会话用 `spawn_agent` 派发 `cowork-check`，`fork_turns="none"`，先发 `COWORK_DISPATCH_V1` 信封并等待 `COWORK_ACK`。
-4. Finish: 主会话做最终验证、同步规格、提交、归档、记录 session。
+1. changes: 通过用户需求,构建原始需求文件
+2. brainstorming：对changes需求做头脑风暴,确定目标、范围、验收标准、范围边界、被拒方案、实现方案、检查方案。
+3. read spec: 读取项目规范
+4. plan：构建开发计划。
+5. tasks：根据plan拆分具体执行任务、明确 PRD、整理 `implement.jsonl` / `check.jsonl`。
+6. implement：主会话通过当前宿主适配器派发 `cowork-implement`，按 `.cowork-flow/spec/subagent-dispatch.md` 执行固定代理派发协议。
+7. check：主会话通过当前宿主适配器派发 `cowork-check`，按 `.cowork-flow/spec/subagent-dispatch.md` 执行固定代理派发协议。
+8. complete：主会话做最终验证、同步规格、归档、记录会话、提交。
 
-`cowork-flow` 只保存项目状态、任务上下文和恢复线索；实际执行由主会话和固定 `cowork-*` agent 完成。
+`cowork-flow` 只保存项目状态、任务上下文、宿主适配器契约和恢复线索；实际执行由主会话和固定 `cowork-*` 代理完成。宿主工具名只写在 `.cowork-flow/adapters/<host>/adapter.yaml`，不进入流程分支。
 
-## 1.1 Hook 注入状态
+`task next` 是主会话的阶段导航器。进入任务阶段、恢复会话、派发实现、进入检查、完成收口前，先运行 `./.cowork-flow/run task next` 或 `.\.cowork-flow\run.cmd task next`，用当前任务和 `task.json.status` 决定下一步。该命令只读，不推进状态。
 
-`.codex/hooks/inject-workflow-state.py` 每轮读取当前 session task，并把下面的 `[workflow-state:*]` 片段注入 Codex 上下文。`workflow.md` 是状态提示的唯一来源；修改流程时必须同步这些片段。
+## 1.1 状态注入与入口分类
 
-[workflow-state:no_task]
-No active task for this session. For read-only Q&A, answer directly. For implementation, refactor, behavior change, or multi-step work, create or start a task first, then continue through Plan -> Implement -> Check -> Finish.
-[/workflow-state:no_task]
+1. 宿主钩子或插件每轮注入当前会话的入口分类和任务状态。状态提示的文本片段定义在 `.cowork-flow/spec/workflow-state-templates.md`，hook 从该文件读取；不再内联到本文件。
+2. runtime context 绑定先于入口分类。hook/plugin 先解析 `cowork_runtime_context_id`，绑定成功或 fail-closed 时注入 `delegated_subtask`。
+3. 入口分类只服务主会话导航，不能用 prompt 形状推断正式子代理身份。`UNKNOWN` 不能冒充委托子任务；保持当前任务/no-task 状态可见，并在突变工作流前澄清。
 
-[workflow-state:delegated_subtask]
-The current prompt looks like a bounded delegated subtask. Follow the delegated prompt first. Do not run start/resume, create or activate a task, or switch into main-session coordination unless the delegated prompt explicitly asks for that. Keep project rules visible as constraints, not as the task.
-[/workflow-state:delegated_subtask]
+## 1.2 需求澄清与头脑风暴门禁
 
-[workflow-state:planning]
-The active task is in planning. Finish prd.md, curate implement.jsonl and check.jsonl with spec/research files, then run task start before dispatching cowork-implement.
-[/workflow-state:planning]
+1. 新需求先判断清晰度。只读问题、单步且目标/范围/验收标准都清楚的小改可以绕过；否则必须先进入 `brainstorming`，在写 PRD、计划或固定代理派发前收束方向。
+2. 以下情况触发头脑风暴：
+    - 目标、用户价值或期望行为不清楚。
+    - 范围边界、非目标或影响面不清楚。
+    - 存在多种有效方案或关键取舍尚未决定。
+    - 涉及 L1/L2 行为变化，或影响架构、接口、数据、权限、发布迁移。
+    - 验收标准缺失、风险未知，或关键假设需要暴露。
 
-[workflow-state:in_progress]
-The active task is in progress. Main session dispatches cowork-implement work according to the plan, then cowork-check after integration. Every spawn_agent call uses fork_turns="none" and a COWORK_DISPATCH_V1 envelope. Main session waits for COWORK_ACK, sends EXECUTE with followup_task, then uses per-dispatch post-ACK execution grace while each child loads context. Main session verifies child output, lists agents, and closes children only after completion or clear failure evidence.
-[/workflow-state:in_progress]
-
-[workflow-state:completed]
-The active task is completed. Main session should verify the final diff, commit intended files, archive the task, and record the session. Do not dispatch new implementation work against this completed task.
-[/workflow-state:completed]
+3. `brainstorming` 输出至少包括：目标、非目标、关键假设、范围边界、推荐方向、被拒方案、验收标准、开放问题/阻塞。只有方向和验收标准清楚后，才进入 PRD、计划或固定代理派发。
 
 ## 2. 状态文件
 
@@ -54,219 +54,174 @@ The active task is completed. Main session should verify the final diff, commit
 | 行为变更 | `.cowork-flow/changes/<slug>/` |
 | 实施计划 | `.cowork-flow/plans/*.md` |
 | 项目规格 | `.cowork-flow/spec/` |
+| 项目上下文摘要 | `.cowork-flow/project-context.md` |
 | 会话记录 | `.cowork-flow/workspace/<developer>/journal-*.md` |
 
-当前任务是 session-scoped。没有 `COWORK_FLOW_CONTEXT_ID`、`CODEX_SESSION_ID` 或 `CODEX_THREAD_ID` 时，不得猜测当前任务。
-
-## 3. Agent
-
-### cowork-research
-
-- 只做调研。
-- 只写入 `<task>/research/`。
-- 不改代码、不改规格、不改任务状态、不操作 git。
-
-### cowork-implement
-
-- 读取 `<task>/prd.md`、`<task>/info.md`、`<task>/implement.jsonl` 和 JSONL 指向的文件。
-- 按任务范围实现。
-- 不启动其他 agent，不提交，不归档，不运行 task start/finish/archive。
-- 汇报改动文件和验证命令。
-
-### cowork-check
-
-- 读取 `<task>/prd.md`、`<task>/check.jsonl` 和 `git diff`。
-- 检查行为、测试、规格同步和遗漏。
-- 范围内问题直接修复。
-- 不提交、不归档、不启动其他 agent。
-
-兼容旧派发时，提示仍可用这一行开头：
-
-```text
-Active task: .cowork-flow/tasks/<task>
-```
-
-## 3.1 Agent 派发入口
-
-固定 `cowork-*` agent 使用 Codex 原生 subagent 工具，由主会话负责派发、等待、验收和关闭。派发必须用 `fork_turns="none"`，避免子线程继承主会话历史。
-
-主会话派发约定：
-
-```python
-spawn_agent(
-    agent_type="cowork-implement",
-    fork_turns="none",
-    message=(
-        "COWORK_DISPATCH_V1\n"
-        "dispatch_id: <unique-id>\n"
-        "task_dir: .cowork-flow/tasks/<task>\n"
-        "agent_type: cowork-implement\n"
-        "role: implement\n"
-        "context_file: <context-file>\n"
-        "ack_token: <ack-token>\n"
-        "COWORK_DISPATCH_END\n\n"
-        "Return only: COWORK_ACK <dispatch_id> <ack_token>"
-    ),
-)
-```
-
-等待与验收约定：
-
-- Use `wait_agent` for `COWORK_ACK <dispatch_id> <ack_token>` before execution.
-- Missing or mismatched `COWORK_ACK` means the task is not dispatched.
-- Only after a matching ACK, send `EXECUTE <dispatch_id>` with `followup_task`.
-- Record `execute_sent_at[dispatch_id]` when `EXECUTE <dispatch_id>` is sent.
-- Compute `deadline[dispatch_id] = execute_sent_at[dispatch_id] + codex.post_ack_execution_grace_ms`; do not use a shared/global deadline across children.
-- After `EXECUTE <dispatch_id>`, no reply or no compass/status file while the child loads context is inconclusive.
-- Use post-ACK execution grace for execution startup before judging execution health. The default is `300000` ms and can be configured with `codex.post_ack_execution_grace_ms` in `.cowork-flow/config.yaml`.
-- Do not call `close_agent` only because the executing child has not produced a compass/status file.
-- If `list_agents` still shows the child running, continue waiting through post-ACK execution grace instead of closing it.
-- Post-ACK execution grace expiration for one `dispatch_id` is a review checkpoint for that child only, not a close trigger and not evidence about other children.
-- If progress, compass, or status files exist, continue waiting and do not close solely because grace expired.
-- If a child reports another `dispatch_id`, close that child and respawn the intended task.
-- An executing child may be closed only after wrong-dispatch evidence, child completion, or user cancellation.
-- 用 `wait_agent` 等待子 agent 返回。
-- 用 `list_agents` 确认没有遗留 running child。
-- 验收子 agent 汇报的文件、命令和结果；不只信“已完成”文本。
-- 完成或失败后用 `close_agent` 关闭子 agent。
-- 子 agent 自身是 leaf executor；不得再调用 `spawn_agent`、`wait_agent`、`list_agents`、`close_agent`。
-
-Generic worker boundary:
-
-- Formal execution uses `cowork-research`, `cowork-implement`, or `cowork-check`.
-- Generic `worker` dispatch is best-effort only.
-- If a generic worker does not ACK after one retry, close it and do not execute the task.
-- For advisory/default subagents without a hard envelope, the first sentence must explicitly say this is a bounded delegated task, not a main-session start request. This is a natural-language first-screen boundary, not a new runtime state machine.
-
-## 3.2 parallel sessions
-
-并行执行采用 clean-room 的 parallel sessions 模型：
-
-- 用户无需在需求输入时声明是否并行；Plan 阶段由主会话评估并行可行性。
-- 开发计划必须明确执行策略：串行执行，或列出可并行的 low-conflict slices。
-- 多个独立任务优先拆成多个 Codex sessions；只要存在写入冲突风险，就用独立 `git worktree` 隔离。
-- 单个 task 内只允许低冲突的 low-conflict slices 并行；每个 slice 必须写清 file ownership、dependencies、expected outputs 和验证命令。
-- 同一文件、同一行为链、依赖未合并或验收标准不清的工作不得并行，改为串行。
-- 主会话是唯一协调者：派发所有子 agent 后逐个 `wait_agent`，核对子 agent 汇报的文件、命令和产物，再 `list_agents` / `close_agent` 收口。
-- 多个实现 slice 合并后必须再执行 final integrated verification；不能把各子 agent 的局部通过当成整体通过。
-- 固定 `cowork-*` agent 仍是 leaf executor；并行不允许子 agent 再派发 agent，也不引入旧集中式状态机。
-
-## 4. 任务分级
-
-### L0: 无外部行为变化
-
-适用：文档、格式、小范围重构、注释、脚本整理、测试补充，且不改变用户可观察行为。
-
-流程：读取规则 -> 创建或选择任务 -> 写 PRD -> 初始化上下文 -> 实现 -> 验证 -> 记录 session。
-
-### L1: 局部行为变化
-
-适用：单模块功能、局部接口行为、局部数据处理逻辑，边界清晰。
+> 当前任务是会话级状态。没有 `COWORK_FLOW_CONTEXT_ID`、`CODEX_SESSION_ID`、`CODEX_THREAD_ID`、`OPENCODE_SESSION_ID` 或 `CLAUDE_SESSION_ID` 时，不得猜测当前任务。
 
-流程：change -> brainstorming -> spec -> plan -> task context -> Implement -> Check -> Finish。
+任务阶段状态由生命周期命令维护：
 
-### L2: 跨层或重要行为变化
+| 阶段 | 命令 | `task.json.status` |
+| --- | --- | --- |
+| 计划 | `task create` | `planning` |
+| 执行 | `task start <task-dir>` | `in_progress` |
+| 检查 | `task review [task-dir]` | `review` |
+| 完成 | `task complete [task-dir]` | `completed` |
+| 归档 | `task archive <task-name>` | 归档副本保持 `completed` |
 
-适用：API / DB / 消息 / 权限 / 文件格式 / 架构边界 / 发布迁移 / 安全策略等变化。
+`task finish` 只清理当前会话任务指针，不改变 `task.json.status`。
 
-流程：change -> brainstorming -> design.md -> spec -> plan -> task context -> Implement -> Check -> Finish -> cross-layer review。
+## 3. 固定代理
 
-## 5. Plan 阶段
+固定代理只执行主会话派发的叶子任务。子代理是执行者，子任务是工作单元。
 
-1. 读取 `AGENTS.md`、本文件、相关 `.cowork-flow/spec/` 索引。
-2. 创建或确认任务：
+| 代理 | 读取 | 允许 | 禁止 | 输出 |
+| --- | --- | --- | --- | --- |
+| `cowork-research` | 任务上下文和调研输入 | 只做调研，只写入 `<task>/research/` | 改代码、改规格、改任务状态、操作 Git | 调研结论和证据 |
+| `cowork-implement` | `<task>/prd.md`、`<task>/info.md`、`<task>/implement.jsonl` 和 JSONL 指向的文件 | 按任务范围实现 | 启动其他代理、提交、归档、运行 `task start`、`task finish` 或 `task archive` | 改动文件和验证命令 |
+| `cowork-check` | `<task>/prd.md`、`<task>/check.jsonl` 和 `git diff` | 检查行为、测试、规格同步和遗漏；范围内问题直接修复 | 提交、归档、启动其他代理 | 检查结论、修复内容和验证结果 |
 
-```bash
-./.cowork-flow/run task create "<title>" --slug <task-name>
-```
+## 3.1 固定代理派发入口
 
-3. 写 `prd.md`，至少包含目标、范围、验收标准、相关文件、验证方式。
-4. 初始化上下文：
+固定 `cowork-*` 代理使用宿主适配器契约，由主会话负责派发、等待、验收和取消。宿主专属原语只在 `.cowork-flow/adapters/<host>/adapter.yaml` 中声明；工作流只关心阶段职责、协调边界和验收责任。
 
-```bash
-./.cowork-flow/run task init-context <task-dir> <type>
-./.cowork-flow/run task add-context <task-dir> implement <path> "<reason>"
-./.cowork-flow/run task add-context <task-dir> check <path> "<reason>"
-```
+正式派发协议见 `.cowork-flow/spec/subagent-dispatch.md`。该协议定义 runtime context 创建、传输、绑定、等待、返回验收、关闭清理和通用 worker 边界。
 
-5. 对 L1/L2 创建 change；L2 必须有 `design.md`。
-6. 写 `.cowork-flow/plans/YYYY-MM-DD-<slug>.md`，每步带验证命令。
-7. 启动当前会话任务：
+- 主会话必须使用新鲜子上下文派发固定代理。
+- 主会话通过适配器等待原语、适配器列表原语和适配器取消/关闭原语完成收口。
+- 固定 `cowork-*` 代理是叶子执行者；不得再派发、等待、列出或取消其他代理。
+- 通用 `worker`、`default` 或 `explorer` 只能作为 advisory work，不能满足正式实现或检查完成条件。
 
-```bash
-./.cowork-flow/run task start <task-dir>
-```
+## 3.2 并行会话
 
-Windows PowerShell 使用：
+并行执行采用干净隔离的并行会话模型。并行只是执行策略，不改变固定代理叶子边界。
 
-```powershell
-.\.cowork-flow\run.cmd task start <task-dir>
-```
-
-## 6. Implement 阶段
-
-默认派发 `cowork-implement`。派发调用必须设置 `fork_turns="none"`，优先使用 `COWORK_DISPATCH_V1` 信封；兼容旧消息时第一行：
-
-```text
-Active task: .cowork-flow/tasks/<task>
-```
+### 3.2.1 并行决策
 
-派发内容应包含当前计划步骤、范围边界和期望验证命令。
+- 用户无需在需求输入时声明是否并行；计划阶段由主会话评估并行可行性。
+- 开发计划必须明确执行策略：串行执行，或列出可并行的低冲突切片。
+- 同一文件、同一行为链、依赖未合并或验收标准不清的工作不得并行，改为串行。
 
-如果用户明确要求主会话 inline 执行，或当前任务正在修改 subagent/runtime 行为，可以不派发 `cowork-implement`，但必须说明原因，并仍按计划与测试循环推进。
+### 3.2.2 隔离方式
 
-涉及行为变化时，先写失败测试，再实现，再验证变绿。
+- 多个独立任务优先拆成多个 cowork-flow 会话。
+- 只要存在写入冲突风险，就用独立 `git worktree` 隔离。
 
-## 7. Check 阶段
+### 3.2.3 单任务内切片
 
-默认派发 `cowork-check`。派发调用必须设置 `fork_turns="none"`，优先使用 `COWORK_DISPATCH_V1` 信封；兼容旧消息时第一行：
+- 单个任务内只允许低冲突切片并行。
+- 每个切片必须写清文件归属、依赖关系、预期产物和验证命令。
 
-```text
-Active task: .cowork-flow/tasks/<task>
-```
+### 3.2.4 协调与验收
 
-检查内容：
+- 主会话是唯一协调者：派发所有子代理后逐个等待，核对子代理汇报的文件、命令和产物，再用适配器列表/取消原语收口。
+- 多个实现切片合并后必须再执行最终集成验证；不能把各子代理的局部通过当成整体通过。
+- 固定 `cowork-*` 代理仍是叶子执行者；并行不允许子代理再派发代理，也不引入旧集中式状态机。
 
-- PRD 验收标准是否满足。
-- `git diff` 是否只包含预期范围。
-- 测试是否覆盖关键行为。
-- `.cowork-flow/spec/` 是否需要更新。
-- plan checkbox 和执行状态是否真实。
+## 4. 任务分级
 
-如果用户明确要求主会话 inline 检查，可以不派发 `cowork-check`，但必须执行等价的 diff、测试、规格同步检查。
+### L0: 无外部行为变化
 
-## 8. Finish 阶段
+适用：文档、格式、小范围重构、注释、脚本整理、测试补充，且不改变用户可观察行为。
+流程：`brainstorming` -> `read spec` -> `implement` -> `check` -> `complete`
 
-完成前必须确认：
+### L1: 局部行为变化
 
-- 当前 session 存在任务，或明确说明本次是无任务只读工作。
-- `cowork-check` 或等价最终检查已执行。
-- 所有声明通过的验证都有命令输出依据。
-- 规格已更新，或明确判断无需更新。
-- 计划状态、任务状态、change metadata 不冲突。
-- 提交在归档和 session 记录之前完成。
-- 不纳入无关脏改。
+适用：单模块功能、局部接口行为、局部数据处理逻辑，边界清晰。
+流程： `changes` -> `brainstorming` -> `read spec` -> `plan` -> `tasks` -> `implement` -> `check` -> `complete` -> `archive` -> `add session`
 
-推荐顺序：
+### L2: 跨层或重要行为变化
 
-```bash
-git status --short
-git diff --check
-npm run test:all
-git add <expected files>
-git commit -m "<message>"
-./.cowork-flow/run task archive <task-name>
-./.cowork-flow/run add-session --title "<title>" --commit "<commit>" --summary "<summary>"
-```
+适用：API / DB / 消息 / 权限 / 文件格式 / 架构边界 / 发布迁移 / 安全策略等变化。
+流程：`changes` -> `brainstorming` -> `read spec` -> `plan` -> `tasks` -> `implement` -> `cross layer check` -> `complete` -> `archive` -> `add session`。
+
+L2 任务在 `task start` 前必须通过 readiness gate；同一 blocker 列表会在
+`task next` 中展示。缺少 proposal/spec/design、计划、任务链接、关键假设、
+范围边界、验收标准或验证命令时，不得启动实现或正式派发固定代理。
+
+## 5. 计划阶段
+
+1. 对 L1/L2 创建 changes；L2 必须有 `design.md`。
+2. 对changes需求做头脑风暴
+3. 写开发计划 `.cowork-flow/plans/YYYY-MM-DD-<slug>.md`，每步带验证命令。
+4. 读取 `AGENTS.md`、本文件、相关 `.cowork-flow/spec/` 索引。
+5. 创建或确认任务：
+    ```bash
+    ./.cowork-flow/run task create "<title>" --slug <task-name>
+    ```
+6. 对创建的每项任务写 `prd.md`，至少包含目标、范围、验收标准、相关文件、验证方式。
+7. 初始化上下文：
+    ```bash
+    ./.cowork-flow/run task init-context <task-dir> <type>
+    ./.cowork-flow/run task add-context <task-dir> implement <path> "<reason>"
+    ./.cowork-flow/run task add-context <task-dir> check <path> "<reason>"
+    ```
+8. 运行导航器确认准备状态：
+    ```bash
+    ./.cowork-flow/run task next <task-dir>
+    ```
+9. 启动当前会话任务；该命令会把 `task.json.status` 推进到 `in_progress`：
+    ```bash
+    ./.cowork-flow/run task start <task-dir>
+    ```
+   Windows PowerShell 使用：
+    ```powershell
+    .\.cowork-flow\run.cmd task start <task-dir>
+    ```
+
+## 6. 实现阶段
+
+1. 先运行 `task next` 确认当前状态和下一步命令。
+2. 默认通过宿主适配器派发 `cowork-implement`。派发必须使用新鲜子上下文，并遵守 `.cowork-flow/spec/subagent-dispatch.md`。
+3. 派发内容应包含当前计划步骤、范围边界和期望验证命令。
+4. 如果用户明确要求主会话内联执行，或当前任务正在修改子代理/运行时行为，可以不派发 `cowork-implement`，但必须说明原因，并仍按计划与测试循环推进。
+5. 涉及行为变化时，先写失败测试，再实现，再验证变绿。
+6. 实现完成并通过本阶段验证后运行 `./.cowork-flow/run task review [task-dir]`，把任务推进到检查阶段。
+
+## 7. 检查阶段
+
+1. 先运行 `task next` 确认任务处于 `review` / `checking` 检查阶段。
+2. 默认通过宿主适配器派发 `cowork-check`。派发必须使用新鲜子上下文，并遵守 `.cowork-flow/spec/subagent-dispatch.md`。
+3. 检查内容：
+    - PRD 验收标准是否满足。
+    - `git diff` 是否只包含预期范围。
+    - 测试是否覆盖关键行为。
+    - `.cowork-flow/spec/` 是否需要更新。
+    - 计划勾选项和执行状态是否真实。
+4. 如果用户明确要求主会话内联检查，可以不派发 `cowork-check`，但必须执行等价的 diff、测试、规格同步检查。
+5. 检查通过后运行 `./.cowork-flow/run task complete [task-dir]`，把任务推进到完成阶段。
+
+## 8. 完成阶段
+
+1. 完成前必须确认：
+    - 当前会话存在任务，或明确说明本次是无任务只读工作。
+    - `cowork-check` 或等价最终检查已执行。
+    - 所有声明通过的验证都有命令输出依据。
+    - 规格已更新，或明确判断无需更新。
+    - 计划状态、任务状态、`change` 元数据不冲突。
+    - 先归档，再记录会话，然后提交。
+    - 不纳入无关脏改。
+
+2. 顺序：
+    ```bash
+    ./.cowork-flow/run task next
+    git status --short
+    git diff --check
+    npm run test:all
+    ./.cowork-flow/run task archive <task-name>
+    ./.cowork-flow/run add-session --title "<title>" --commit "-" --summary "<summary>"
+    git status --short
+    git add <expected files>
+    git commit -m "<message>"
+    ```
 
 ## 9. 恢复规则
 
 恢复时只读取最小上下文：
-
 1. 运行 `./.cowork-flow/run resume`。
 2. 按 `RESUME CHECKLIST` 读取当前任务 PRD、计划状态和 JSONL 指向文件。
-3. 不批量读取所有 spec、所有 plans、所有 tasks 或 workspace journal。
-4. 不存在当前 session task 时，先创建或启动任务。
+3. 不批量读取所有规格、计划、任务或工作区日志。
+4. 不存在当前会话任务时，先创建或启动任务。
 
 ## 10. 禁止事项
 
@@ -275,4 +230,4 @@ git commit -m "<message>"
 - 不维护第二套执行状态。
 - 不把口头状态当成可靠状态。
 - 不把验证未运行说成通过。
-- 不把旧运行模型作为 fallback。
+- 不把旧运行模型作为兜底。

package/template/.opencode/agents/cowork-check.md

@@ -0,0 +1,46 @@
+---
+description: Cowork-flow check fixed subagent.
+mode: subagent
+permission:
+  edit: ask
+  bash: ask
+  task: deny
+  todowrite: deny
+  external_directory: deny
+---
+
+You are the `cowork-check` fixed subagent for OpenCode.
+You are a leaf executor and must not invoke other agents.
+
+Formal `cowork-check` work requires a bound runtime context. The prompt, host
+metadata, or environment must provide:
+
+```text
+cowork_runtime_context_id: <runtime_context_id>
+cowork_host_context_key: <host_context_key>
+```
+
+The plugin may bind that id to
+`.cowork-flow/.runtime/subagents/<runtime_context_id>.json` before workflow
+state is injected. The first child step must still run:
+
+```bash
+./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
+```
+
+If the explicit bind fails, or if the bound context is missing, closed, invalid,
+or names another agent type, report `needs_context` and stop. Do not use
+`COWORK_ENTRY_CONTRACT_V1` to infer subagent identity; that contract classifies
+main-session prompts only.
+
+Rules:
+
+- Read the task directory from the bound runtime context.
+- Read `<task>/prd.md`, `<task>/check.jsonl`, each JSONL `file` entry, and
+  current `git diff`.
+- Check behavior, tests, spec sync, and scope.
+- Fix only in-scope issues.
+- Report changed files and exact verification commands.
+- Do not use the `task` tool or invoke subagents.
+- Do not run task start, task finish, task archive, unscoped resume, commit, or
+  push.

package/template/.opencode/agents/cowork-implement.md

@@ -0,0 +1,45 @@
+---
+description: Cowork-flow implementation fixed subagent.
+mode: subagent
+permission:
+  edit: ask
+  bash: ask
+  task: deny
+  todowrite: deny
+  external_directory: deny
+---
+
+You are the `cowork-implement` fixed subagent for OpenCode.
+You are a leaf executor and must not invoke other agents.
+
+Formal `cowork-implement` work requires a bound runtime context. The prompt,
+host metadata, or environment must provide:
+
+```text
+cowork_runtime_context_id: <runtime_context_id>
+cowork_host_context_key: <host_context_key>
+```
+
+The plugin may bind that id to
+`.cowork-flow/.runtime/subagents/<runtime_context_id>.json` before workflow
+state is injected. The first child step must still run:
+
+```bash
+./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
+```
+
+If the explicit bind fails, or if the bound context is missing, closed, invalid,
+or names another agent type, report `needs_context` and stop. Do not use
+`COWORK_ENTRY_CONTRACT_V1` to infer subagent identity; that contract classifies
+main-session prompts only.
+
+Rules:
+
+- Read the task directory from the bound runtime context.
+- Read `<task>/prd.md`, `<task>/info.md` if present, `<task>/implement.jsonl`,
+  and each JSONL `file` entry.
+- Keep edits inside the assigned scope.
+- Report changed files and exact verification commands.
+- Do not use the `task` tool or invoke subagents.
+- Do not run task start, task finish, task archive, unscoped resume, commit, or
+  push.

package/template/.opencode/agents/cowork-research.md

@@ -0,0 +1,46 @@
+---
+description: Cowork-flow research-only fixed subagent.
+mode: subagent
+permission:
+  edit:
+    "*": deny
+    ".cowork-flow/tasks/**/research/**": allow
+  bash: ask
+  task: deny
+  todowrite: deny
+  external_directory: deny
+---
+
+You are the `cowork-research` fixed subagent for OpenCode.
+You are a leaf executor and must not invoke other agents.
+
+Formal `cowork-research` work requires a bound runtime context. The prompt,
+host metadata, or environment must provide:
+
+```text
+cowork_runtime_context_id: <runtime_context_id>
+cowork_host_context_key: <host_context_key>
+```
+
+The plugin may bind that id to
+`.cowork-flow/.runtime/subagents/<runtime_context_id>.json` before workflow
+state is injected. The first child step must still run:
+
+```bash
+./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
+```
+
+If the explicit bind fails, or if the bound context is missing, closed, invalid,
+or names another agent type, report `needs_context` and stop. Do not use
+`COWORK_ENTRY_CONTRACT_V1` to infer subagent identity; that contract classifies
+main-session prompts only.
+
+Rules:
+
+- Read the task directory and assignment from the bound runtime context.
+- Read `<task>/prd.md`, `<task>/info.md` if present, and prompt-named context.
+- Write research only under `<task>/research/`.
+- Do not edit code, specs, task state, or git state.
+- Do not use the `task` tool or invoke subagents.
+- Do not run task start, task finish, task archive, unscoped resume, commit, or
+  push.

package/template/.opencode/commands/cowork-check.md

@@ -0,0 +1,26 @@
+---
+description: Dispatch cowork-flow check as a runtime-context subtask.
+agent: cowork-check
+subtask: true
+---
+
+Before dispatch, create a runtime context:
+
+```bash
+./.cowork-flow/run subagent init --role check --agent-type cowork-check --execution-task-dir <task-dir> --title "Check <task-dir>" --host opencode --adapter opencode.task
+```
+
+Pass the returned prompt transport to the subagent:
+
+```text
+cowork_runtime_context_id: <runtime_context_id>
+cowork_host_context_key: <host_context_key>
+```
+
+The child must first bind the runtime context before role work:
+
+```bash
+./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
+```
+
+Missing, closed, invalid, mismatched, or unbound context is `needs_context`.

package/template/.opencode/commands/cowork-implement.md

@@ -0,0 +1,26 @@
+---
+description: Dispatch cowork-flow implementation as a runtime-context subtask.
+agent: cowork-implement
+subtask: true
+---
+
+Before dispatch, create a runtime context:
+
+```bash
+./.cowork-flow/run subagent init --role implement --agent-type cowork-implement --execution-task-dir <task-dir> --title "Implement <task-dir>" --host opencode --adapter opencode.task
+```
+
+Pass the returned prompt transport to the subagent:
+
+```text
+cowork_runtime_context_id: <runtime_context_id>
+cowork_host_context_key: <host_context_key>
+```
+
+The child must first bind the runtime context before role work:
+
+```bash
+./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
+```
+
+Missing, closed, invalid, mismatched, or unbound context is `needs_context`.

package/template/.opencode/commands/cowork-research.md

@@ -0,0 +1,26 @@
+---
+description: Dispatch cowork-flow research as a runtime-context subtask.
+agent: cowork-research
+subtask: true
+---
+
+Before dispatch, create a runtime context:
+
+```bash
+./.cowork-flow/run subagent init --role research --agent-type cowork-research --execution-task-dir <task-dir> --title "Research <task-dir>" --host opencode --adapter opencode.task
+```
+
+Pass the returned prompt transport to the subagent:
+
+```text
+cowork_runtime_context_id: <runtime_context_id>
+cowork_host_context_key: <host_context_key>
+```
+
+The child must first bind the runtime context before role work:
+
+```bash
+./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
+```
+
+Missing, closed, invalid, mismatched, or unbound context is `needs_context`.