{"name":"attempt_completion","arguments":{"result":"以下为《BMAD-Solo 业务流驱动的 Agent 文档与任务治理落地规范》工程草案，覆盖角色嵌入、任务模板、数据交接、双重门禁及宿主映射。本次仅交付规范，不修改生产代码、宿主配置或既有任务资产。\n\n- 业务流组织任务，角色只是工序职责，不建立按角色分割的文档体系。\n- 任务契约与当前状态收敛到 [`specs/tasks/`](specs/tasks/)；入口文件只保存单焦点指针。\n- 同一 Agent 切换到 Supervisor 可以进行反向审查，但不能据此产生独立审查签章。\n- 所有新增校验器、证据收集器和权限拦截均属于待实施能力，不能因本规范存在而登记通过。\n\n# BMAD-Solo 业务流驱动的 Agent 文档与任务治理落地规范\n\n版本：Engineering Specification Draft 0.1 \n日期：2026-10-27 \n状态：PROPOSED \n适用项目：dotfiles-bmad-solo\n\n## 0. 规范边界与证据说明\n\n### 0.1 规范用语\n\n- “必须”：必要约束；不满足时拒绝相关流转。\n- “禁止”：不得由角色提示词、宿主模式切换或普通重试豁免。\n- “应”：默认选择；偏离须记录理由及影响。\n- “待实现”：目标接口或资产尚未获得实现和验证回执。\n- “未知”：没有足够证据；不解释为通过。\n\n本规范定义目标治理架构，不宣称当前仓库已经实现这些控制。\n\n### 0.2 理论来源与工程化边界\n\n本规范将用户指定的业务流原点、What 与职责分离、“刚刚好”的数据交接、KCP 与 SOD 作为设计约束。\n\n本次未取得徐直军指定文章的可核验一手全文；对其逐字表述与本规范工程规则之间的直接对应关系：Insufficient evidence。以下内容是对用户明确原则的工程化，不冒充原文引述。\n\n检索返回了 AutoSwarm: Automating Agent Swarms 的 arXiv 记录。[1](cite:1) 但返回材料不足以核对指定版本的 CS 定义及验收公式原文；对此：Insufficient evidence。\n\n因此，本规范采用用户给定的任务单元、CS 与双重门禁作为约束，不声称下面的目录、状态枚举、签章格式或宿主适配方案来自论文原文。\n\n### 0.3 与既有资产的对照入口\n\n迁移评审应对照以下已读取材料，而不是直接覆盖它们：\n\n- [`docs/blueprint.md`](docs/blueprint.md:1)：现有文档拓扑设计。\n- [`文档与测试治理提案`](docs/adrs/ADR-20261022-document-test-governance-and-host-adaptation.md:21)：资产职责与迁移边界。\n- [`Cline Plan/Act 提案`](docs/adrs/ADR-20261023-cline-native-plan-act-and-backpressure.md:71)：模式绑定与程序门禁边界。\n- [`现有 Cline 路由模板`](bmad-suite-v4/cline/templates/bmad-router.md:1)：行为适配的对照入口。\n- [`现有 Roo 模式配置`](bmad-suite-v4/roo/settings/custom_modes.yaml:1)：静态权限迁移的对照入口。\n- [`现有实施计划模板`](bmad-suite-v4/skills/bmad/references/templates/implementation-plan.template.md:18)：授权、验证、恢复约束的来源入口。\n\n本草案不接受、归档或恢复上述材料关联的历史任务。\n\n### 0.4 物理门禁的最低成立条件\n\n本规范的“可机械校验”不等于“仅靠 Markdown 即可强制执行”。实施必须具备：\n\n1. 严格解析任务契约的校验器。\n2. 真实执行并收集结果的受信验证入口。\n3. 可核验的独立审查身份与批准事件。\n4. 在下游释放之前实际执行的拒绝入口。\n\n上述能力缺失时，相关任务可以保持草稿或完成局部实现，但不得获得物理门禁意义上的 ACCEPTED。\n\n## 1. 模块一：端到端 Plan-Act 业务流与角色嵌入\n\n### 1.1 唯一业务流\n\n业务流定义为：目标摄入 → 业务分析 → 架构契约 → 实施 → 验证与审查 → 下游释放 → 长效规范沉淀。\n\nPlan 与 Act 是人机交互的两个基础动作。Analyst、Architect、Coder、Supervisor 是沿业务流切换的职责视角，不要求独立 Agent 进程，也不拥有各自的文档目录。\n\n### 1.2 工序、职责与出口\n\n| 交互阶段 | 工序 | 当前职责 | 必须完成的工作 | 出口条件 |\n|---|---|---|---|---|\n| Plan 前半段 | 业务分析 | Analyst | 明确客观目标、业务不变量、验收、范围及必要非目标 | 形成 Task Spec Draft；关键歧义显式标注 |\n| Plan 后半段 | 架构设计 | Architect | 确定接口、所有权、依赖、交付清单、KCP、独立审查要求 | 契约冻结；实施前置条件可检查 |\n| Act 前半段 | 实施 | Coder | 仅修改获准范围，保护既有改动，运行适用自测 | 形成固定候选、完整差异及真实自测证据 |\n| Act 后半段 | 验证与审查 | Supervisor | 检查 CS、实测覆盖、失败路径、边界与异常，提出接受或返工意见 | 机器门禁成立，且取得独立批准事件 |\n\n角色出口是工件契约，不是“模型说已完成”。\n\n### 1.3 Prompt Framing 切换契约\n\n每次切换职责必须装载以下框架：\n\n- 当前任务标识、契约版本、业务工序。\n- 当前用户批准范围和宿主实际权限。\n- 本工序消费的输入、允许输出、禁止操作。\n- 未完成义务、已知局限性及退出条件。\n\n角色提示词不得授予工具能力。切换到 Coder 不等于获准实施全部阶段；切换到 Supervisor 不等于获得签章身份。\n\n若宿主模式信号与任务工序冲突，停止依赖该信号的副作用操作。不得从旧摘要、文件名或模型自我描述推断权限。\n\n### 1.4 单 Agent 与独立 SOD 的兼容方式\n\n必须区分两件事：\n\n- “审查视角独立”：同一 Agent 使用 Supervisor 框架重新检查候选。\n- “批准主体独立”：没有参与该候选实施、且具有真实批准身份的主体签章。\n\n前者有助于发现缺陷，但不构成后者。\n\n允许的独立批准方式：\n\n1. 由未参与候选实施的人类审查者批准；单 Agent 的 Supervisor 提供审查材料。\n2. 经另行授权，由独立审查主体完成受限审查；不要求常驻多 Agent 架构。\n\n禁止的方式：\n\n- Coder 改写提示词后自行填写“独立审查通过”。\n- 将另一个角色名当作另一个身份。\n- 使用同一个可伪造的本地字符串证明身份不同。\n- 把模型自审、测试全绿或宿主自动批准当作独立签章。\n\n独立审查主体不存在时，任务保持 IN_REVIEW，并记录审查阻塞；不得降低门禁标准。\n\n### 1.5 上下文加载与清洗契约\n\n#### 常驻内容\n\n常驻内容只包括全局安全约束、业务流路由、权威工件定位和当前授权边界。项目入口候选为 [`AGENTS.md`](AGENTS.md)。\n\n不得常驻全部任务、全部领域规范、全部角色长提示词或历史日志。\n\n#### 工序加载顺序\n\n1. 读取显式指定任务；没有显式任务时读取 [`specs/tasks/_active.md`](specs/tasks/_active.md)。\n2. 读取目标任务的 Frontmatter 和本工序所需正文。\n3. 按输入清单加载相关领域规范、接口和源码切片。\n4. 加载当前候选的必要证据摘要；原始日志按需读取。\n5. Supervisor 先独立阅读目标、CS 与候选差异，再读取 Coder 的解释，避免解释先入为主。\n\n#### 清洗边界\n\n在角色切换、上下文压缩、恢复会话及候选变化时：\n\n- 不再加载已过期的候选结论、重复文件全文、无关分析和历史对话。\n- 不把完整内部推理过程当作交接工件。\n- 保留全部未完成验收、阻塞、授权、候选定位及证据引用。\n- 摘要不能替代原始契约、回执或签章。\n\n“清洗”首先表示控制下一次加载；除非宿主提供并验证了相应能力，否则不得声称历史上下文已从模型窗口物理删除。\n\n#### 有界交接\n\n建议采用以下可配置预算，作为治理默认值而非效果保证：\n\n- 状态交接摘要最多 80 行、12 KiB。\n- 首次源码读取按不超过 200 行的切片进行；必要时继续读取相关块。\n- 日志输出限制由任务指定，不将完整日志塞入会话。\n\n预算不足以保留必要义务时，必须拆分加载或重建上下文，不能静默删减验收和风险。\n\n## 2. 模块二：核心工件、字段及完整模板\n\n### 2.1 目标知识拓扑\n\n| 路径 | 唯一职责 | 权威性 |\n|---|---|---|\n| [`AGENTS.md`](AGENTS.md) | 全局规则与导航 | 全局政策，不保存任务进度 |\n| [`specs/tasks/TU-.md`](specs/tasks/) | 单个任务契约、当前阶段及门禁决定 | 当前任务唯一语义权威源 |\n| [`specs/tasks/_active.md`](specs/tasks/_active.md) | 当前单焦点指针 | 只决定默认入口，不复制任务状态 |\n| [`specs/tasks/TU-/`](specs/tasks/) | 任务级签章及必要审计附件 | 附件证据，不另建任务状态 |\n| [`specs/tasks/archive/`](specs/tasks/archive/) | 已封存任务 | 历史契约，不自动执行 |\n| [`specs/.md`](specs/) | 已交付的领域不变量、接口和验证要求 | 当前领域契约，不保存工单流水 |\n| [`verification/`](verification/) | 实测回执、日志、候选清单及执行现场 | 事实证据载体，不承载任务审批决策 |\n| [`tests/`](tests/) | 持久测试及回归资产 | 可执行源码，不保存运行日志 |\n| [`docs/`](docs/) | 必要分析和重大决策说明 | 参考资产，不另建实施任务 |\n\n禁止创建 Analyst、Architect、Coder、Supervisor 专属任务目录。\n\n目标架构不再向 [`_bmad-output/`]( _bmad-output/) 写入新的任务契约；其退役必须通过独立迁移任务完成，不能以“废弃”名义删除未完成任务或唯一证据。\n\n### 2.2 单一权威源与写入职责\n\n任务 Frontmatter 是机器解释的唯一结构化契约。正文解释字段含义和设计理由，不能定义另一套与 Frontmatter 冲突的验收。\n\n写入职责必须区分：\n\n| 内容 | 允许提出变更的职责 | 允许提交的主体 |\n|---|---|---|\n| 目标、不变量、验收 | Analyst / Architect | 获准契约编辑入口 |\n| 冻结后的 CS 与 KCP | Architect 提出修订 | 新批准事件绑定的新契约版本 |\n| 生产及测试实现 | Coder | 获准实施入口 |\n| 自测说明与返工建议 | Coder / Supervisor | 对应受限证据入口 |\n| 独立签章 | 独立审查者 | 身份可核验的批准入口 |\n| 阶段与门禁状态 | 各角色可申请 | 受信状态提交入口 |\n\n单纯的文件路径正则无法实现字段级隔离。若宿主允许 Coder 任意改写任务文件，必须由提交入口重新验证并拒绝其伪造状态或签章；没有覆盖证据时不能宣称已实现物理 SOD。\n\n平台 TODO 只作为非权威展示，不镜像成第二套可写任务状态。\n\n### 2.3 标识、路径与结构规则\n\n- 任务标识必须满足 `^[A-Z0-9][A-Z0-9_-]{0,63}$`，与任务文件基名一致。\n- 所有路径基于项目根目录解析；禁止绝对路径、目录穿越及越界链接。\n- 输入必须明确到文件、稳定锚点或有界行范围，并记录内容身份。\n- Frontmatter 使用严格 YAML 解析：禁止重复键、自定义标签及无法识别的字段。\n- 类型错误、引用缺失、权限拒绝、磁盘错误和格式损坏分别报告。\n- 草稿中的未知可以使用 null，但执行前必需字段不得为 null。\n\n下面的模板是结构化原文；代码块中的路径和字段保持原始格式，避免把链接语法写入可解析数据。\n\n### 2.4 完整任务模板\n\n以下示例任务用于说明“任务契约校验入口”的交付要求。新增资产均标为待创建，示例不是当前可执行任务。\n\n对应工件：[`specs/tasks/TU-GOV-0001.md`](specs/tasks/TU-GOV-0001.md)。\n\n```yaml\n---\nschema_version: bmad.task/v1\ntask_id: GOV-0001\nparent_objective: 建立业务流驱动的任务契约与失败默认拒绝门禁\ncontract_version: 1\ncontract_state: DRAFT\nscenario: structural\ncurrent_stage: PLAN_ANALYZE\nactive_role: Analyst\ngate_status: READY\n\ninputs:\n - input_id: IN-01\n path: docs/blueprint.md\n selector:\n kind: lines\n start: 1\n end: 29\n purpose: 识别现有拓扑并提出受控迁移差异\n authority: historical_reference\n availability: AVAILABLE\n expected_sha256: null\n\ndependencies: []\n\nexecution_authorization:\n approval_ref: null\n approved_contract_digest: null\n allowed_stages: []\n product_write_paths: []\n evidence_write_paths: []\n external_effects: []\n allow_merge: false\n allow_domain_publication: false\n allow_archive: false\n\ncs_specification:\n deliverables:\n - deliverable_id: OUT-01\n path: scripts/task_gate.py\n operation: create\n purpose: 严格解析任务契约并提供只读校验入口\n asset_status: PLANNED_NOT_YET_CREATED\n - deliverable_id: OUT-02\n path: schemas/task-unit.schema.json\n operation: create\n purpose: 固化任务字段类型与结构约束\n asset_status: PLANNED_NOT_YET_CREATED\n - deliverable_id: OUT-03\n path: tests/tasks/test_task_gate.py\n operation: create\n purpose: 提供正常路径与失败拒绝回归\n asset_status: PLANNED_NOT_YET_CREATED\n allowed_transient_paths:\n - verification/TU-GOV-0001/\n prohibited_changes:\n - 不改变历史任务的授权和完成语义\n - 不修改真实宿主配置或项目事实基线\n - 不删除或降低现有必要测试\n invariants:\n - invariant_id: INV-01\n statement: 显式任务缺失时不得退回默认任务\n assertion_ids: [KCP-02]\n review_required: true\n - invariant_id: INV-02\n statement: 缺失或过期证据不得获得接受决定\n assertion_ids: [KCP-02]\n review_required: true\n - invariant_id: INV-03\n statement: 只读校验不得写入任务或执行其声明的命令\n assertion_ids: [KCP-02]\n review_required: true\n acceptance_criteria:\n - criterion_id: AC-01\n statement: 合法契约通过，格式及引用错误按类型拒绝\n assertion_ids: [KCP-01, KCP-02]\n review_required: true\n - criterion_id: AC-02\n statement: 正常流转可完成，失败及伪造批准不可释放下游\n assertion_ids: [KCP-02]\n review_required: true\n interface_contracts:\n - interface_id: API-01\n entrypoint: task_gate.validate\n behavior: 校验任务但不执行任务内的验证命令\n success_exit_code: 0\n invalid_contract_exit_code: 2\n operational_error_exit_code: 3\n downstream_consumers:\n - consumer_id: ENGINEERING-ENTRY\n required_exports: [OUT-01, OUT-02]\n\nkcp_verification:\n required: true\n trusted_runner_ref: null\n environment_requirements:\n - Python 解释器及本地测试依赖已准备\n - 测试不得隐式联网安装依赖\n - 受信测试预言与被测实现分离\n oracle_policy:\n trusted_suite_ref: null\n candidate_may_change_trusted_oracle: false\n checks:\n - check_id: KCP-01\n purpose: 任务契约静态校验\n argv:\n - python3\n - scripts/task_gate.py\n - validate\n - --task\n - specs/tasks/TU-GOV-0001.md\n cwd: .\n timeout_seconds: 15\n kill_grace_seconds: 2\n stdin: closed\n network: denied\n required: true\n expected_exit_codes: \n result_adapter: contract-validator-v1\n required_assertions: [schema_valid, references_valid]\n asset_status: PLANNED_NOT_YET_CREATED\n - check_id: KCP-02\n purpose: 正常路径及失败拒绝回归\n argv:\n - python3\n - -m\n - unittest\n - discover\n - -s\n - tests/tasks\n - -p\n - test_task_gate.py\n cwd: .\n timeout_seconds: 30\n kill_grace_seconds: 2\n stdin: closed\n network: denied\n required: true\n expected_exit_codes: \n result_adapter: unittest-v1\n minimum_collected: 1\n forbid_required_skips: true\n asset_status: PLANNED_NOT_YET_CREATED\n cleanup_required: true\n\nsod_review:\n required: true\n independence_policy: NON_AUTHOR_AUTHENTICATED_REVIEWER\n self_review_counts_as_approval: false\n code_author_principals: []\n required_topics:\n - 业务不变量与接口边界\n - 异常、取消、超时及资源清理\n - 权限绕过、证据过期和状态竞态\n - 测试预言独立性与负控有效性\n signoff: null\n known_limitations: []\n downstream_guidance: []\n\nruntime:\n state_revision: 0\n focus_generation: null\n attempt: 0\n contract_digest: null\n candidate_ref: null\n latest_verdict_ref: verification/TU-GOV-0001.verdict.json\n halt:\n kind: NONE\n code: null\n detail: null\n---\n```\n\n上述 Frontmatter 后必须附以下完整正文骨架：\n\n```markdown\n# TU-GOV-0001：任务契约校验与门禁基础\n\n## 业务目标\n\n说明解决的客观问题、受益对象及可观察结果。\n本节解释 parent_objective，不定义第二套验收。\n\n## 范围与非目标\n\n明确本任务负责的连贯交付边界。\n列出必要非目标；不机械要求固定数量。\n\n## 输入判读\n\n逐个解释 inputs 中的用途、可信度和适用范围。\n历史参考不自动升级为当前有效规范。\n\n## 设计与接口\n\n解释 CS 中的接口、所有权、依赖和失败语义。\n不存在的资产明确为待实现。\n\n## 交付规范说明\n\n按 OUT、INV、AC 标识解释交付物、不变量与验收。\n所有可执行约束以 Frontmatter 为准。\n\n## KCP 验证说明\n\n解释每个检查覆盖什么、不覆盖什么、使用哪个受信预言。\n说明环境前提、超时、必要输出及清理验收。\n不在本节保存逐轮执行日志。\n\n## 反向审查重点\n\n列出当前设计相关的边界、异常、失败转换及绕过风险。\n虚拟推演与真实实测必须分别标识。\n\n## 已知局限性\n\n每项局限性说明影响范围、是否阻塞验收及证据定位。\n机器使用 sod_review.known_limitations，不解释自由文本为通过。\n\n## 下游使用指引\n\n说明获准下游可消费哪些交付物、必须保持哪些前提。\n明确 ACCEPTED 不等于已合并、已部署或已归档。\n\n## 授权与恢复说明\n\n引用批准事件，不在此自行声明批准。\n说明返工范围、现场保留及历史恢复边界。\n```\n\n### 2.5 字段级定义\n\n| 字段 | 类型与约束 | 解释 |\n|---|---|---|\n| schema_version | 固定版本字符串 | 决定解析规则；未知版本拒绝 |\n| task_id | 唯一字符串 | 任务身份，不复用已封存标识 |\n| parent_objective | 非空字符串 | 端到端业务目标，而非角色工作目标 |\n| contract_version | 正整数 | 实质改变 CS、KCP、依赖或授权时递增 |\n| contract_state | DRAFT / FROZEN | 草稿可分析，冻结后才可能进入实施 |\n| scenario | algo / structural / bugfix / ops | 选择验证类别，不作为免检标签 |\n| current_stage | 规定工序枚举 | 当前业务工序，不等同宿主按钮 |\n| active_role | 四职责之一 | 当前职责，不作为身份凭据 |\n| inputs | 输入对象数组 | 路径、切片、用途、权威类别及内容身份 |\n| dependencies | 依赖对象数组 | 每项绑定上游任务、契约版本和已接受候选 |\n| execution_authorization | 批准与范围对象 | 真实批准引用及允许副作用 |\n| cs_specification | 结构化对象 | 精确交付清单、不变量、验收和接口 |\n| kcp_verification | 结构化对象 | 冻结命令、环境、预言、适配器及判定条件 |\n| sod_review | 结构化对象 | 独立策略、作者身份、签章、局限与使用指引 |\n| gate_status | 五状态枚举 | 当前流转决定，仅由受信入口提交 |\n| runtime | 运行绑定对象 | 候选、回执和并发修订定位；不是日志账本 |\n\n补充约束：\n\n- 输入内容摘要必须由工具生成，不要求模型手工计算。\n- 交付物清单必须逐文件列出创建、修改或删除操作；目录通配不得代替最终交付清单。\n- 每个验收项必须绑定必要断言及审查要求。\n- 测试、Lint 与构建按影响范围选择；不机械要求每种任务运行全库。\n- 接口条目中的退出码、参数和行为是待实施契约，不是当前已有接口事实。\n- 暂存产物和验证输出必须另列允许范围，不能混入生产交付清单。\n\n### 2.6 状态机与门禁\n\n五种门禁状态保持用户指定枚举，不添加含混的“基本通过”。\n\n| 状态 | 含义 | 允许行为 |\n|---|---|---|\n| READY | 等待分析、冻结或实施接管 | 只能进行当前批准范围内的准备；不是无条件可执行 |\n| IN_PROGRESS | 当前候选正在实施或自测 | 不释放给依赖下游 |\n| IN_REVIEW | 候选已固定，等待机器复核和独立审查 | 禁止修改候选；修改须退出审查 |\n| ACCEPTED | 当前候选满足双重门禁 | 仅允许另获批准的下游动作 |\n| REJECTED | 当前候选不满足验收 | 保留现场，允许获准返工，不推进依赖 |\n\n另用 runtime.halt 表示 NONE、BLOCKED 或 SUSPENDED，不用 ACCEPTED 掩盖缺失证据。\n\n合法转换：\n\n1. READY → IN_PROGRESS：契约冻结、授权有效、输入与依赖有效、实施范围明确。\n2. IN_PROGRESS → IN_REVIEW：候选固定、CS 差异完整、自测证据齐全。\n3. IN_REVIEW → ACCEPTED：机器检查、独立签章及绑定一致性全部成立。\n4. IN_REVIEW → REJECTED：存在明确检查失败或审查拒绝。\n5. REJECTED → IN_PROGRESS：返工仍在获准范围内；新建尝试并使旧签章失效。\n\n缺证据时停留在相应非接受状态，并标明 BLOCKED。候选或契约变化后，不允许沿用 ACCEPTED；重开须获得授权并进入新尝试。\n\n### 2.7 单焦点入口\n\n对应工件：[`specs/tasks/_active.md`](specs/tasks/_active.md)。\n\n```yaml\n---\nschema_version: bmad.active/v1\ngeneration: 0\ntask_id: null\ntask_path: null\n---\n```\n\n规则：\n\n- null 表示没有默认焦点，是正常状态。\n- 非空时标识与路径必须同时存在，且指向有效任务。\n- 不保存阶段、角色、门禁状态或任务清单，避免双写。\n- 用户显式指定任务时跳过默认入口；显式任务缺失不得静默替换。\n- 切换焦点必须确认原任务已完成或获准暂停，保留全部未完成事项。\n- 使用锁及 generation 比较交换提交；目标任务的 focus_generation 必须匹配。\n- 指针与任务绑定不一致时停止副作用，不能猜测谁较新。\n\n“单焦点”不表示删除其他任务；它只限制默认交互入口。\n\n### 2.8 Archive 契约\n\n归档目标采用日期加任务标识，例如 [`specs/tasks/archive/2026-10-27/TU-GOV-0001.md`](specs/tasks/archive/2026-10-27/TU-GOV-0001.md)。\n\n归档必须满足：\n\n1. 当前候选已接受，任务声明的交付义务已完成。\n2. 如契约要求合并或领域沉淀，已取得相应完成证据。\n3. 当前用户批准归档；目标不得覆盖。\n4. 保存任务、签章及必要证据的完整封存副本并核对摘要。\n5. 重新核对源身份、版本与焦点；源变化时保留源并停止。\n6. 清除匹配的焦点后，再按批准范围移除活动源。\n\n跨文件操作不假设整体原子性。必须使用可恢复提交步骤；中断、磁盘失败或校验失败时保留源和诊断，不清空入口掩盖失败。\n\n归档保留 ACCEPTED 的历史含义，但不赋予新环境的运行许可。历史恢复必须新建任务实例，引用来源，重新批准并验证。\n\n原始证据的保留策略必须在任务中明确；不能一律放进本地忽略目录后宣称跨机器可追溯。\n\n## 3. 模块三：“刚刚好”的 Data Flow Contracts\n\n### 3.1 上下游交接表\n\n| 交接 | 必须输出 | 严禁输出 | 下游接收门禁 |\n|---|---|---|---|\n| Analyst → Architect | 业务目标、不变量、验收、约束、输入定位、必要非目标、未决问题 | 大段聊天、未经核实的项目事实、提前锁死的实现细节、伪造评分 | 目标可判读；关键歧义明确，阻塞项不冒充已解决 |\n| Architect → Coder | 冻结任务契约、精确交付清单、接口与所有权、依赖、获准范围、KCP、失败与清理要求 | 完整研究流水、无关候选、未标注的假接口、无批准的命令 | 契约、输入、依赖、授权和预言均有效 |\n| Coder → Supervisor | 固定候选、精确差异、实际变更文件、真实自测回执、已知局限、需重点审查的边界 | 仅“测试全绿”、模型自制通过 JSON、凭据、完整无界日志、自行批准 | 候选身份稳定；回执可核验；范围无越界 |\n| Supervisor → 领域规范 | 已过审且已交付的稳定不变量、接口、必要验证要求、任务与决策溯源 | 逐轮流水、未实现设计、未经批准特性、全部失败日志、自审即签章 | 独立接受有效；领域变更已审查且获得发布授权 |\n\n### 3.2 交接最小内容\n\n每次交接只回答：\n\n- 下游要完成什么？\n- 消费哪些具体输入？\n- 必须保持哪些业务约束？\n- 哪些行为已被授权？\n- 如何判定交付合格？\n- 哪些问题仍未知或阻塞？\n\n不能为了压缩而删掉必要约束，也不能为了完整而附上全部历史。\n\n### 3.3 公共领域规范沉淀\n\n目标工件为 [`specs/.md`](specs/)。\n\n沉淀流程必须是：\n\n1. Architect 在任务 CS 中声明拟修改的领域规范文件和内容范围。\n2. Coder 形成候选领域规范变更，与实现一起进入审查。\n3. Supervisor 验证文档中的行为与实际候选、必要运行证据一致。\n4. 独立审查者批准包含该文档变更的候选。\n5. 获得发布授权后提交；未交付特性不得描述成当前事实。\n\n若文档是在 ACCEPTED 后新增或实质改写，该文档构成新候选变化，必须重新审查受影响部分；禁止用“知识沉淀”绕开代码与规范一致性检查。\n\n领域规范只保存：\n\n- 当前业务不变量与接口。\n- 当前适用验证入口。\n- 必要兼容性和已知限制。\n- 接受任务与必要决策的精确引用。\n\n任务完成记录仍留在任务工件，不复制进领域规范形成流水。\n\n## 4. 模块四：双重门禁的物理落地\n\n### 4.1 门禁公式与绑定范围\n\n采用用户给定公式：$a_t(g) = C_t^g(z_t^g) \\land R_t(g)$。\n\n在工程中，两个分量都必须解释为“对应同一任务、同一契约、同一候选、同一必要环境的有效证据”，而不是任意两个通过字符串。\n\n因此，在批准入口计算：\n\n- C：全部必需机器检查通过且回执真实有效。\n- R：独立审查批准成立，审查覆盖必需主题且无阻塞项。\n- 绑定核验：两个分量对应当前候选、契约、依赖和环境。\n\n绑定核验不是替代第三个质量门禁，而是 C 与 R 被解释为有效的前提。\n\n任何缺失、未知、过期或验证异常均不能取真。\n\n### 4.2 契约摘要与候选身份\n\n契约摘要由受信程序对规范化结构计算，包含：\n\n- 任务身份、业务目标及契约版本。\n- 输入、依赖、批准范围。\n- CS、KCP 和独立审查策略。\n\n摘要排除当前阶段、状态修订号、回执引用和签章结果，避免“记录通过 → 摘要变化 → 永久失效”的自引用循环。\n\n正文不能额外定义未纳入结构化契约的执行要求。\n\n候选清单必须覆盖：\n\n- 全部交付物及实际变更文件。\n- 相关测试、配置、依赖与受影响的接口。\n- 删除操作和必要未变文件的内容身份。\n- 当前验证环境和受信预言身份。\n\n内容摘要用于一致性，不自动证明来源可信或防篡改。\n\n### 4.3 验证运行与证据隔离\n\n证据目录按任务和尝试组织，例如 [`verification/TU-GOV-0001/`](verification/TU-GOV-0001/)。\n\n每次验证必须：\n\n1. 固定候选快照，阻止验证过程中被实现者改写。\n2. 固定已经批准的命令、环境及测试预言。\n3. 串行、前台执行，封闭标准输入。\n4. 使用进程级超时，并确认超时后的进程树与资源清理。\n5. 收集真实命令、工作目录、时间、退出状态、收集数量及必要输出。\n6. 保存受限日志；敏感信息按既定策略脱敏，不删除判定所需信息。\n7. 由收集器生成回执，不由模型手工写入“通过”。\n\n验证输出目录不是执行级沙箱。网络、文件系统、凭据、进程与外部服务的隔离必须分别实现并取得证据。\n\n### 4.4 回执格式\n\n当前机器回执工件为 [`verification/TU-GOV-0001.verdict.json`](verification/TU-GOV-0001.verdict.json)。\n\n以下是未运行状态的完整格式示例，不代表成功回执：\n\n```json\n{\n \"schema_version\": \"bmad.verdict/v1\",\n \"task_id\": \"GOV-0001\",\n \"contract_version\": 1,\n \"contract_digest\": null,\n \"attempt\": 0,\n \"run_id\": null,\n \"candidate\": {\n \"manifest_path\": null,\n \"manifest_sha256\": null,\n \"snapshot_id\": null\n },\n \"environment\": {\n \"fingerprint\": null,\n \"host_version\": null,\n \"interpreter_version\": null,\n \"dependency_snapshot\": null,\n \"trusted_oracle_digest\": null,\n \"network_policy\": \"denied\"\n },\n \"producer\": {\n \"runner_id\": null,\n \"principal_ref\": null,\n \"attestation_ref\": null\n },\n \"started_at\": null,\n \"finished_at\": null,\n \"checks\": [\n {\n \"check_id\": \"KCP-02\",\n \"required\": true,\n \"argv\": [\n \"python3\", \"-m\", \"unittest\", \"discover\",\n \"-s\", \"tests/tasks\", \"-p\", \"test_task_gate.py\"\n ],\n \"cwd\": \".\",\n \"timeout_seconds\": 30,\n \"kill_grace_seconds\": 2,\n \"process_exited\": false,\n \"exit_code\": null,\n \"timed_out\": false,\n \"cancelled\": false,\n \"collected\": null,\n \"passed\": null,\n \"failed\": null,\n \"required_skipped\": null,\n \"adapter\": \"unittest-v1\",\n \"adapter_valid\": false,\n \"required_assertions\": {},\n \"stdout_path\": null,\n \"stdout_sha256\": null,\n \"stderr_path\": null,\n \"stderr_sha256\": null,\n \"status\": \"NOT_RUN\"\n }\n ],\n \"cleanup\": {\n \"required\": true,\n \"status\": \"UNKNOWN\",\n \"evidence_ref\": null\n },\n \"aggregate\": {\n \"required_checks_complete\": false,\n \"candidate_unchanged\": false,\n \"contract_unchanged\": false,\n \"machine_gate\": \"UNKNOWN\",\n \"reason_codes\": [\"NOT_EXECUTED\"]\n }\n}\n```\n\n字段语义：\n\n- producer 必须能定位实际收集主体；自填名称不构成认证。\n- checks 必须覆盖契约中的全部必需检查，不允许遗漏。\n- collected 不适用于某类静态检查时可以为 null，但该检查必须提供已声明的结构化断言。\n- 对测试适配器，零收集、数量未知或必需项跳过不能通过。\n- timed_out 和 cancelled 独立于退出码；退出零不能掩盖取消、解析失败或缺失输出。\n- cleanup 为 UNKNOWN 时，必需清理不能通过。\n- machine_gate 仅为 PASS、FAIL、UNKNOWN，不包含任务审批状态。\n\n### 4.5 回执权威性与历史保存\n\n当前回执文件只代表当前最近一次已提交的验证结果，不是审批文件。\n\n在替换当前回执前，必须将旧回执完整封存到任务尝试目录。历史副本只用于审计，不能因为其中存在 PASS 而自动选择它作为当前结果。\n\n回执必须由受信入口写入或认证。若 Coder 可以同时改写候选、回执和批准记录，目录分离与摘要无法提供物理内控保证。\n\n严格场景应使用独立账户、受保护存储或受保护 CI 执行入口；同一操作系统账户下的“约定不可修改”只能报告为行为约束。\n\n### 4.6 C 的判断逻辑\n\n机器门禁 PASS 必须同时满足：\n\n- 回执结构、来源及内容身份可核验。\n- 任务、契约、候选和必要环境匹配当前绑定。\n- 必需检查集合完整，实际参数与冻结命令一致。\n- 每个必需检查进程真实退出，满足允许退出码。\n- 没有超时、取消、结果解析错误或必要输出缺失。\n- 测试达到规定收集要求，没有必需项跳过。\n- 所有声明的必要物理断言成立。\n- 必需清理完成，验证前后候选保持一致。\n\n明确断言失败时记 FAIL；缺依赖、缺记录、身份不可核验或采集异常时记 UNKNOWN。两者都拒绝下游释放。\n\n### 4.7 独立反向审查报告与签章\n\n审查附件按任务组织，例如 [`specs/tasks/TU-GOV-0001/review-R001.json`](specs/tasks/TU-GOV-0001/review-R001.json)。\n\n签章对象完整结构如下，未批准时保留 null：\n\n```json\n{\n \"schema_version\": \"bmad.review/v1\",\n \"review_id\": \"R001\",\n \"task_id\": \"GOV-0001\",\n \"contract_version\": 1,\n \"contract_digest\": null,\n \"candidate_manifest_sha256\": null,\n \"verdict_sha256\": null,\n \"reviewer\": {\n \"principal_ref\": null,\n \"authentication_ref\": null,\n \"independence_verified\": false\n },\n \"topics\": [\n {\n \"topic_id\": \"BOUNDARIES\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n },\n {\n \"topic_id\": \"EXCEPTIONS_AND_CLEANUP\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n },\n {\n \"topic_id\": \"BYPASS_AND_STALE_EVIDENCE\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n },\n {\n \"topic_id\": \"ORACLE_INDEPENDENCE\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n }\n ],\n \"findings\": [],\n \"known_limitations\": [],\n \"downstream_guidance\": [],\n \"decision\": \"PENDING\",\n \"approval\": {\n \"approved_at\": null,\n \"approval_event_ref\": null,\n \"signed_payload_sha256\": null,\n \"signature_ref\": null\n }\n}\n```\n\n审查必须关注实际相关风险：\n\n- 边界输入、空集合、重复请求及状态转换。\n- 未捕获异常、取消、超时、部分失败与资源释放。\n- 依赖错误、候选漂移、过期回执与并发提交。\n- 权限越界、回执伪造、审查身份复用。\n- 测试预言被实现者降低、错误实现仍然“全绿”。\n\n每个发现必须记录严重性、证据、违反的 CS 标识和处理要求。存在未解决阻塞发现时不得 APPROVE；已知局限不能用来豁免必要验收。\n\n签章规则：\n\n1. 批准者身份不属于当前候选作者集合。\n2. 批准事件来自模型不能伪造的身份入口。\n3. 批准载荷绑定契约、候选和机器回执。\n4. 必需主题已审查，结论有依据。\n5. 审查决定和局限性被批准事件覆盖，不能批准后改写。\n\n密码学签名不是唯一可用方式；受认证的平台批准事件也可以作为证据。但事件身份、载荷绑定和查询验证必须实际成立，不能仅记录一个任意链接。\n\n任务中的 sod_review.signoff 只引用当前有效报告和批准事件，不复制第二份可编辑报告正文。\n\n### 4.8 接受提交的并发与释放控制\n\n接受入口必须在固定候选上完成：\n\n1. 获取任务锁，读取当前 state_revision。\n2. 核对契约、候选、C、R 与批准范围。\n3. 重新检查候选未变化。\n4. 通过比较交换提交 ACCEPTED，并记录绑定引用。\n5. 下游释放入口再次核对绑定，而不是仅检查状态字符串。\n\n验证、审查和合并之间的候选变化必须被发现。若无法固定快照或防止竞态，相关释放保持 BLOCKED。\n\nACCEPTED 不是任意生产代码直接合并的许可；合并、提交、推送、部署及归档分别受授权控制。\n\n### 4.9 REJECTED 回退与现场保护\n\n拒绝当前候选后必须：\n\n- 保留差异、候选清单、日志、失败回执和审查发现。\n- 阻断依赖下游，不更新公共领域事实。\n- 保留用户既有改动及未授权文件。\n- 将失败分类为契约问题、实现问题、环境问题、采集问题或审查阻塞。\n- 在当前授权和预算内允许针对性返工；不降低断言，不删除必要测试。\n- 新尝试使用新 run_id，并使旧候选签章失效。\n\n契约本身错误时返回 Plan 修订；实质改变目标、接口、所有权或验收必须重新批准。\n\n不得默认执行整库重置、整目录删除或自动生产回滚。只回退可定位且获准的改动；资源清理不明时先阻塞，而不是假设现场安全。\n\n### 4.10 门禁程序自身的可信启动\n\n任务门禁的实现不能仅依赖自己生成的 PASS 证明自己可信。\n\n首轮实施必须由独立审查者确认：\n\n- 验收预言来自冻结且不由候选随意修改的基准。\n- 正常实现能通过，故意破坏的实现会失败。\n- 校验器、收集器和释放入口分别经过验证。\n- 被测候选不能控制最终批准身份或受保护验证记录。\n\n未建立可信启动证据前，只能报告局部静态或隔离验证，不能宣布完整物理门禁已经接管。\n\n## 5. 模块五：Roo Code / Cline 配置与 Prompt 映射\n\n### 5.1 宿主适配原则\n\n宿主只承载交互、工具和审批；项目任务契约仍只有一份。\n\n以下提示词可作为规则内容使用，但配置发现路径、模式信号和拦截接口必须在目标版本核验。本次没有目标宿主运行回执；对自动发现、自动角色绑定及字段级拒绝行为：Insufficient evidence。\n\n不得通过本草案开启自动批准、安装扩展、重载 IDE 或扩大分发集合。\n\n### 5.2 公共路由 Prompt\n\n规则入口候选为文件型 [` .clinerules`](.clinerules) 或目标宿主实际支持的项目规则位置。不要同时维护两份内容不同的项目规则。\n\n```text\n你服务于单一端到端软件业务流，只有 Plan 与 Act 两个基础交互动作。\nAnalyst、Architect、Coder、Supervisor 是任务工序职责，不是独立文档体系。\n\n项目任务唯一权威源为 specs/tasks/TU-.md。\n显式任务优先；未显式指定时读取 specs/tasks/_active.md。\n默认入口为空是正常状态；显式任务缺失不得静默替换。\n\n只使用宿主实际提供的模式信号和当前用户批准范围。\n角色切换、任务读取和提示词不能增加工具权限。\n\nPlan 按任务工序采用 Analyst 或 Architect 视角。\n默认只读，不运行终端、不修改生产代码、不创建或执行探针。\n获准持久化时只交接明确文档范围，不顺带实施。\n\nAct 前半段采用 Coder 视角，仅实施获准范围。\nAct 后半段采用 Supervisor 视角，固定候选并进行反向审查。\n同一模型的 Supervisor 自审不得产生独立审查批准。\n\n没有真实机器回执及可核验独立签章时，不请求接受或下游释放。\n失败、超时、缺失、过期和未知都不能当作通过。\n不得直接改写门禁状态、伪造回执或填写审查身份。\n\n只加载当前任务所需输入、差异及证据。\n保留全部未完成义务；不要交接完整聊天和内部推理过程。\n压缩或恢复后重新读取权威任务，不继承摘要中的历史绿灯。\n```\n\n### 5.3 四工序 Prompt 片段\n\n#### Analyst\n\n```text\n当前职责：Analyst；当前工序：PLAN_ANALYZE。\n读取用户目标和任务 inputs，区分事实、用户陈述、推断与未知。\n提炼业务不变量、可观察验收、约束与必要非目标。\n不预设不必要的技术方案，不编造成本、权重或评分。\n输出 Task Spec Draft 及确实阻塞设计的问题。\n只读咨询只会话交付；持久化须有明确授权和实际权限。\n```\n\n#### Architect\n\n```text\n当前职责：Architect；当前工序：PLAN_DESIGN。\n消费业务目标与验收，不重新制造第二份需求文档。\n先按权限、兼容性、资源和时间硬门禁筛选，再比较候选。\n固化精确交付文件、接口、所有权、依赖、KCP 和 SOD 要求。\n验证命令声明环境、超时、收集规则、必要输出和清理要求。\n缺失资产标记待实现；未知不写成通过。\n契约冻结后停止，不自动切换并启动实施或实验。\n```\n\n#### Coder\n\n```text\n当前职责：Coder；当前工序：ACT_IMPLEMENT。\n直接消费已批准且冻结的任务契约，不重复完整分析。\n预检输入、依赖、授权范围及既有改动。\n仅实施 CS 声明的交付物及获准暂存范围。\n运行任务声明的相关验证，使用真实工具结果生成证据。\n不修改独立审查策略、受信预言、批准身份或门禁状态。\n提交固定候选、实际差异、自测回执及已知局限后停止。\n```\n\n#### Supervisor\n\n```text\n当前职责：Supervisor；当前工序：ACT_REVIEW。\n先读取目标、CS、必要领域约束和固定候选差异，再读作者解释。\n核对实际交付范围和机器回执，检查边界、异常、清理及绕过风险。\n新增必要物理断言须走获准验证入口，不私自扩大命令范围。\n输出有证据定位的审查发现、局限性及下游使用指引。\n如果你与 Coder 是同一 Agent，你的结论仅为审查建议。\n独立批准必须来自非作者且身份可核验的主体。\n未经有效 C 与 R，不请求 ACCEPTED、合并或发布。\n```\n\n### 5.4 Cline 的交互映射\n\n目标交互保持两个按钮，不要求用户输入四套角色命令：\n\n- Plan + PLAN_ANALYZE：加载 Analyst 框架。\n- Plan + PLAN_DESIGN：加载 Architect 框架。\n- Act + ACT_IMPLEMENT：加载 Coder 框架。\n- Act + ACT_REVIEW：加载 Supervisor 框架；等待独立批准。\n\n文档保存若必须在 Act 中完成，应使用“仅文档保存”授权范围，保存后停止。不能将保存任务升级为生产实施。\n\n若宿主无法自动提供可信工序信号，可以从任务契约读取工序；但该工序值仍须由受信状态入口维护，不由模型自由改写。\n\n若只实现提示词路由，则交付必须写明“行为适配”，不得称为程序权限隔离。\n\n### 5.5 Roo 的两职责配置草案\n\n下面是与现有两职责结构对齐的静态配置草案，不是对已加载配置的修改，也不证明目标 Roo 版本的运行拒绝行为。\n\n对应评审入口：[`custom_modes.yaml`](bmad-suite-v4/roo/settings/custom_modes.yaml:1)。\n\n```yaml\ncustomModes:\n - slug: ana-architect\n name: Plan：业务分析与架构\n roleDefinition: >-\n 在端到端业务流中承担 Analyst 与 Architect 职责。\n 只读分析，不实施生产代码，不运行终端或探针。\n groups:\n - read\n - browser\n customInstructions: >-\n 显式任务优先；否则读取 specs/tasks/_active.md。\n

{"name":"attempt_completion","arguments":{"result":"以下为《BMAD-Solo 业务流驱动的 Agent 文档与任务治理落地规范》工程草案，覆盖角色嵌入、任务模板、数据交接、双重门禁及宿主映射。本次仅交付规范，不修改生产代码、宿主配置或既有任务资产。\n\n- 业务流组织任务，角色只是工序职责，不建立按角色分割的文档体系。\n- 任务契约与当前状态收敛到 [`specs/tasks/`](specs/tasks/)；入口文件只保存单焦点指针。\n- 同一 Agent 切换到 Supervisor 可以进行反向审查，但不能据此产生独立审查签章。\n- 所有新增校验器、证据收集器和权限拦截均属于待实施能力，不能因本规范存在而登记通过。\n\n# BMAD-Solo 业务流驱动的 Agent 文档与任务治理落地规范\n\n版本：Engineering Specification Draft 0.1 \n日期：2026-10-27 \n状态：PROPOSED \n适用项目：dotfiles-bmad-solo\n\n## 0. 规范边界与证据说明\n\n### 0.1 规范用语\n\n- “必须”：必要约束；不满足时拒绝相关流转。\n- “禁止”：不得由角色提示词、宿主模式切换或普通重试豁免。\n- “应”：默认选择；偏离须记录理由及影响。\n- “待实现”：目标接口或资产尚未获得实现和验证回执。\n- “未知”：没有足够证据；不解释为通过。\n\n本规范定义目标治理架构，不宣称当前仓库已经实现这些控制。\n\n### 0.2 理论来源与工程化边界\n\n本规范将用户指定的业务流原点、What 与职责分离、“刚刚好”的数据交接、KCP 与 SOD 作为设计约束。\n\n本次未取得徐直军指定文章的可核验一手全文；对其逐字表述与本规范工程规则之间的直接对应关系：Insufficient evidence。以下内容是对用户明确原则的工程化，不冒充原文引述。\n\n检索返回了 AutoSwarm: Automating Agent Swarms 的 arXiv 记录。[1](cite:1) 但返回材料不足以核对指定版本的 CS 定义及验收公式原文；对此：Insufficient evidence。\n\n因此，本规范采用用户给定的任务单元、CS 与双重门禁作为约束，不声称下面的目录、状态枚举、签章格式或宿主适配方案来自论文原文。\n\n### 0.3 与既有资产的对照入口\n\n迁移评审应对照以下已读取材料，而不是直接覆盖它们：\n\n- [`docs/blueprint.md`](docs/blueprint.md:1)：现有文档拓扑设计。\n- [`文档与测试治理提案`](docs/adrs/ADR-20261022-document-test-governance-and-host-adaptation.md:21)：资产职责与迁移边界。\n- [`Cline Plan/Act 提案`](docs/adrs/ADR-20261023-cline-native-plan-act-and-backpressure.md:71)：模式绑定与程序门禁边界。\n- [`现有 Cline 路由模板`](bmad-suite-v4/cline/templates/bmad-router.md:1)：行为适配的对照入口。\n- [`现有 Roo 模式配置`](bmad-suite-v4/roo/settings/custom_modes.yaml:1)：静态权限迁移的对照入口。\n- [`现有实施计划模板`](bmad-suite-v4/skills/bmad/references/templates/implementation-plan.template.md:18)：授权、验证、恢复约束的来源入口。\n\n本草案不接受、归档或恢复上述材料关联的历史任务。\n\n### 0.4 物理门禁的最低成立条件\n\n本规范的“可机械校验”不等于“仅靠 Markdown 即可强制执行”。实施必须具备：\n\n1. 严格解析任务契约的校验器。\n2. 真实执行并收集结果的受信验证入口。\n3. 可核验的独立审查身份与批准事件。\n4. 在下游释放之前实际执行的拒绝入口。\n\n上述能力缺失时，相关任务可以保持草稿或完成局部实现，但不得获得物理门禁意义上的 ACCEPTED。\n\n## 1. 模块一：端到端 Plan-Act 业务流与角色嵌入\n\n### 1.1 唯一业务流\n\n业务流定义为：目标摄入 → 业务分析 → 架构契约 → 实施 → 验证与审查 → 下游释放 → 长效规范沉淀。\n\nPlan 与 Act 是人机交互的两个基础动作。Analyst、Architect、Coder、Supervisor 是沿业务流切换的职责视角，不要求独立 Agent 进程，也不拥有各自的文档目录。\n\n### 1.2 工序、职责与出口\n\n| 交互阶段 | 工序 | 当前职责 | 必须完成的工作 | 出口条件 |\n|---|---|---|---|---|\n| Plan 前半段 | 业务分析 | Analyst | 明确客观目标、业务不变量、验收、范围及必要非目标 | 形成 Task Spec Draft；关键歧义显式标注 |\n| Plan 后半段 | 架构设计 | Architect | 确定接口、所有权、依赖、交付清单、KCP、独立审查要求 | 契约冻结；实施前置条件可检查 |\n| Act 前半段 | 实施 | Coder | 仅修改获准范围，保护既有改动，运行适用自测 | 形成固定候选、完整差异及真实自测证据 |\n| Act 后半段 | 验证与审查 | Supervisor | 检查 CS、实测覆盖、失败路径、边界与异常，提出接受或返工意见 | 机器门禁成立，且取得独立批准事件 |\n\n角色出口是工件契约，不是“模型说已完成”。\n\n### 1.3 Prompt Framing 切换契约\n\n每次切换职责必须装载以下框架：\n\n- 当前任务标识、契约版本、业务工序。\n- 当前用户批准范围和宿主实际权限。\n- 本工序消费的输入、允许输出、禁止操作。\n- 未完成义务、已知局限性及退出条件。\n\n角色提示词不得授予工具能力。切换到 Coder 不等于获准实施全部阶段；切换到 Supervisor 不等于获得签章身份。\n\n若宿主模式信号与任务工序冲突，停止依赖该信号的副作用操作。不得从旧摘要、文件名或模型自我描述推断权限。\n\n### 1.4 单 Agent 与独立 SOD 的兼容方式\n\n必须区分两件事：\n\n- “审查视角独立”：同一 Agent 使用 Supervisor 框架重新检查候选。\n- “批准主体独立”：没有参与该候选实施、且具有真实批准身份的主体签章。\n\n前者有助于发现缺陷，但不构成后者。\n\n允许的独立批准方式：\n\n1. 由未参与候选实施的人类审查者批准；单 Agent 的 Supervisor 提供审查材料。\n2. 经另行授权，由独立审查主体完成受限审查；不要求常驻多 Agent 架构。\n\n禁止的方式：\n\n- Coder 改写提示词后自行填写“独立审查通过”。\n- 将另一个角色名当作另一个身份。\n- 使用同一个可伪造的本地字符串证明身份不同。\n- 把模型自审、测试全绿或宿主自动批准当作独立签章。\n\n独立审查主体不存在时，任务保持 IN_REVIEW，并记录审查阻塞；不得降低门禁标准。\n\n### 1.5 上下文加载与清洗契约\n\n#### 常驻内容\n\n常驻内容只包括全局安全约束、业务流路由、权威工件定位和当前授权边界。项目入口候选为 [`AGENTS.md`](AGENTS.md)。\n\n不得常驻全部任务、全部领域规范、全部角色长提示词或历史日志。\n\n#### 工序加载顺序\n\n1. 读取显式指定任务；没有显式任务时读取 [`specs/tasks/_active.md`](specs/tasks/_active.md)。\n2. 读取目标任务的 Frontmatter 和本工序所需正文。\n3. 按输入清单加载相关领域规范、接口和源码切片。\n4. 加载当前候选的必要证据摘要；原始日志按需读取。\n5. Supervisor 先独立阅读目标、CS 与候选差异，再读取 Coder 的解释，避免解释先入为主。\n\n#### 清洗边界\n\n在角色切换、上下文压缩、恢复会话及候选变化时：\n\n- 不再加载已过期的候选结论、重复文件全文、无关分析和历史对话。\n- 不把完整内部推理过程当作交接工件。\n- 保留全部未完成验收、阻塞、授权、候选定位及证据引用。\n- 摘要不能替代原始契约、回执或签章。\n\n“清洗”首先表示控制下一次加载；除非宿主提供并验证了相应能力，否则不得声称历史上下文已从模型窗口物理删除。\n\n#### 有界交接\n\n建议采用以下可配置预算，作为治理默认值而非效果保证：\n\n- 状态交接摘要最多 80 行、12 KiB。\n- 首次源码读取按不超过 200 行的切片进行；必要时继续读取相关块。\n- 日志输出限制由任务指定，不将完整日志塞入会话。\n\n预算不足以保留必要义务时，必须拆分加载或重建上下文，不能静默删减验收和风险。\n\n## 2. 模块二：核心工件、字段及完整模板\n\n### 2.1 目标知识拓扑\n\n| 路径 | 唯一职责 | 权威性 |\n|---|---|---|\n| [`AGENTS.md`](AGENTS.md) | 全局规则与导航 | 全局政策，不保存任务进度 |\n| [`specs/tasks/TU-.md`](specs/tasks/) | 单个任务契约、当前阶段及门禁决定 | 当前任务唯一语义权威源 |\n| [`specs/tasks/_active.md`](specs/tasks/_active.md) | 当前单焦点指针 | 只决定默认入口，不复制任务状态 |\n| [`specs/tasks/TU-/`](specs/tasks/) | 任务级签章及必要审计附件 | 附件证据，不另建任务状态 |\n| [`specs/tasks/archive/`](specs/tasks/archive/) | 已封存任务 | 历史契约，不自动执行 |\n| [`specs/.md`](specs/) | 已交付的领域不变量、接口和验证要求 | 当前领域契约，不保存工单流水 |\n| [`verification/`](verification/) | 实测回执、日志、候选清单及执行现场 | 事实证据载体，不承载任务审批决策 |\n| [`tests/`](tests/) | 持久测试及回归资产 | 可执行源码，不保存运行日志 |\n| [`docs/`](docs/) | 必要分析和重大决策说明 | 参考资产，不另建实施任务 |\n\n禁止创建 Analyst、Architect、Coder、Supervisor 专属任务目录。\n\n目标架构不再向 [`_bmad-output/`]( _bmad-output/) 写入新的任务契约；其退役必须通过独立迁移任务完成，不能以“废弃”名义删除未完成任务或唯一证据。\n\n### 2.2 单一权威源与写入职责\n\n任务 Frontmatter 是机器解释的唯一结构化契约。正文解释字段含义和设计理由，不能定义另一套与 Frontmatter 冲突的验收。\n\n写入职责必须区分：\n\n| 内容 | 允许提出变更的职责 | 允许提交的主体 |\n|---|---|---|\n| 目标、不变量、验收 | Analyst / Architect | 获准契约编辑入口 |\n| 冻结后的 CS 与 KCP | Architect 提出修订 | 新批准事件绑定的新契约版本 |\n| 生产及测试实现 | Coder | 获准实施入口 |\n| 自测说明与返工建议 | Coder / Supervisor | 对应受限证据入口 |\n| 独立签章 | 独立审查者 | 身份可核验的批准入口 |\n| 阶段与门禁状态 | 各角色可申请 | 受信状态提交入口 |\n\n单纯的文件路径正则无法实现字段级隔离。若宿主允许 Coder 任意改写任务文件，必须由提交入口重新验证并拒绝其伪造状态或签章；没有覆盖证据时不能宣称已实现物理 SOD。\n\n平台 TODO 只作为非权威展示，不镜像成第二套可写任务状态。\n\n### 2.3 标识、路径与结构规则\n\n- 任务标识必须满足 `^[A-Z0-9][A-Z0-9_-]{0,63}$`，与任务文件基名一致。\n- 所有路径基于项目根目录解析；禁止绝对路径、目录穿越及越界链接。\n- 输入必须明确到文件、稳定锚点或有界行范围，并记录内容身份。\n- Frontmatter 使用严格 YAML 解析：禁止重复键、自定义标签及无法识别的字段。\n- 类型错误、引用缺失、权限拒绝、磁盘错误和格式损坏分别报告。\n- 草稿中的未知可以使用 null，但执行前必需字段不得为 null。\n\n下面的模板是结构化原文；代码块中的路径和字段保持原始格式，避免把链接语法写入可解析数据。\n\n### 2.4 完整任务模板\n\n以下示例任务用于说明“任务契约校验入口”的交付要求。新增资产均标为待创建，示例不是当前可执行任务。\n\n对应工件：[`specs/tasks/TU-GOV-0001.md`](specs/tasks/TU-GOV-0001.md)。\n\n```yaml\n---\nschema_version: bmad.task/v1\ntask_id: GOV-0001\nparent_objective: 建立业务流驱动的任务契约与失败默认拒绝门禁\ncontract_version: 1\ncontract_state: DRAFT\nscenario: structural\ncurrent_stage: PLAN_ANALYZE\nactive_role: Analyst\ngate_status: READY\n\ninputs:\n - input_id: IN-01\n path: docs/blueprint.md\n selector:\n kind: lines\n start: 1\n end: 29\n purpose: 识别现有拓扑并提出受控迁移差异\n authority: historical_reference\n availability: AVAILABLE\n expected_sha256: null\n\ndependencies: []\n\nexecution_authorization:\n approval_ref: null\n approved_contract_digest: null\n allowed_stages: []\n product_write_paths: []\n evidence_write_paths: []\n external_effects: []\n allow_merge: false\n allow_domain_publication: false\n allow_archive: false\n\ncs_specification:\n deliverables:\n - deliverable_id: OUT-01\n path: scripts/task_gate.py\n operation: create\n purpose: 严格解析任务契约并提供只读校验入口\n asset_status: PLANNED_NOT_YET_CREATED\n - deliverable_id: OUT-02\n path: schemas/task-unit.schema.json\n operation: create\n purpose: 固化任务字段类型与结构约束\n asset_status: PLANNED_NOT_YET_CREATED\n - deliverable_id: OUT-03\n path: tests/tasks/test_task_gate.py\n operation: create\n purpose: 提供正常路径与失败拒绝回归\n asset_status: PLANNED_NOT_YET_CREATED\n allowed_transient_paths:\n - verification/TU-GOV-0001/\n prohibited_changes:\n - 不改变历史任务的授权和完成语义\n - 不修改真实宿主配置或项目事实基线\n - 不删除或降低现有必要测试\n invariants:\n - invariant_id: INV-01\n statement: 显式任务缺失时不得退回默认任务\n assertion_ids: [KCP-02]\n review_required: true\n - invariant_id: INV-02\n statement: 缺失或过期证据不得获得接受决定\n assertion_ids: [KCP-02]\n review_required: true\n - invariant_id: INV-03\n statement: 只读校验不得写入任务或执行其声明的命令\n assertion_ids: [KCP-02]\n review_required: true\n acceptance_criteria:\n - criterion_id: AC-01\n statement: 合法契约通过，格式及引用错误按类型拒绝\n assertion_ids: [KCP-01, KCP-02]\n review_required: true\n - criterion_id: AC-02\n statement: 正常流转可完成，失败及伪造批准不可释放下游\n assertion_ids: [KCP-02]\n review_required: true\n interface_contracts:\n - interface_id: API-01\n entrypoint: task_gate.validate\n behavior: 校验任务但不执行任务内的验证命令\n success_exit_code: 0\n invalid_contract_exit_code: 2\n operational_error_exit_code: 3\n downstream_consumers:\n - consumer_id: ENGINEERING-ENTRY\n required_exports: [OUT-01, OUT-02]\n\nkcp_verification:\n required: true\n trusted_runner_ref: null\n environment_requirements:\n - Python 解释器及本地测试依赖已准备\n - 测试不得隐式联网安装依赖\n - 受信测试预言与被测实现分离\n oracle_policy:\n trusted_suite_ref: null\n candidate_may_change_trusted_oracle: false\n checks:\n - check_id: KCP-01\n purpose: 任务契约静态校验\n argv:\n - python3\n - scripts/task_gate.py\n - validate\n - --task\n - specs/tasks/TU-GOV-0001.md\n cwd: .\n timeout_seconds: 15\n kill_grace_seconds: 2\n stdin: closed\n network: denied\n required: true\n expected_exit_codes: \n result_adapter: contract-validator-v1\n required_assertions: [schema_valid, references_valid]\n asset_status: PLANNED_NOT_YET_CREATED\n - check_id: KCP-02\n purpose: 正常路径及失败拒绝回归\n argv:\n - python3\n - -m\n - unittest\n - discover\n - -s\n - tests/tasks\n - -p\n - test_task_gate.py\n cwd: .\n timeout_seconds: 30\n kill_grace_seconds: 2\n stdin: closed\n network: denied\n required: true\n expected_exit_codes: \n result_adapter: unittest-v1\n minimum_collected: 1\n forbid_required_skips: true\n asset_status: PLANNED_NOT_YET_CREATED\n cleanup_required: true\n\nsod_review:\n required: true\n independence_policy: NON_AUTHOR_AUTHENTICATED_REVIEWER\n self_review_counts_as_approval: false\n code_author_principals: []\n required_topics:\n - 业务不变量与接口边界\n - 异常、取消、超时及资源清理\n - 权限绕过、证据过期和状态竞态\n - 测试预言独立性与负控有效性\n signoff: null\n known_limitations: []\n downstream_guidance: []\n\nruntime:\n state_revision: 0\n focus_generation: null\n attempt: 0\n contract_digest: null\n candidate_ref: null\n latest_verdict_ref: verification/TU-GOV-0001.verdict.json\n halt:\n kind: NONE\n code: null\n detail: null\n---\n```\n\n上述 Frontmatter 后必须附以下完整正文骨架：\n\n```markdown\n# TU-GOV-0001：任务契约校验与门禁基础\n\n## 业务目标\n\n说明解决的客观问题、受益对象及可观察结果。\n本节解释 parent_objective，不定义第二套验收。\n\n## 范围与非目标\n\n明确本任务负责的连贯交付边界。\n列出必要非目标；不机械要求固定数量。\n\n## 输入判读\n\n逐个解释 inputs 中的用途、可信度和适用范围。\n历史参考不自动升级为当前有效规范。\n\n## 设计与接口\n\n解释 CS 中的接口、所有权、依赖和失败语义。\n不存在的资产明确为待实现。\n\n## 交付规范说明\n\n按 OUT、INV、AC 标识解释交付物、不变量与验收。\n所有可执行约束以 Frontmatter 为准。\n\n## KCP 验证说明\n\n解释每个检查覆盖什么、不覆盖什么、使用哪个受信预言。\n说明环境前提、超时、必要输出及清理验收。\n不在本节保存逐轮执行日志。\n\n## 反向审查重点\n\n列出当前设计相关的边界、异常、失败转换及绕过风险。\n虚拟推演与真实实测必须分别标识。\n\n## 已知局限性\n\n每项局限性说明影响范围、是否阻塞验收及证据定位。\n机器使用 sod_review.known_limitations，不解释自由文本为通过。\n\n## 下游使用指引\n\n说明获准下游可消费哪些交付物、必须保持哪些前提。\n明确 ACCEPTED 不等于已合并、已部署或已归档。\n\n## 授权与恢复说明\n\n引用批准事件，不在此自行声明批准。\n说明返工范围、现场保留及历史恢复边界。\n```\n\n### 2.5 字段级定义\n\n| 字段 | 类型与约束 | 解释 |\n|---|---|---|\n| schema_version | 固定版本字符串 | 决定解析规则；未知版本拒绝 |\n| task_id | 唯一字符串 | 任务身份，不复用已封存标识 |\n| parent_objective | 非空字符串 | 端到端业务目标，而非角色工作目标 |\n| contract_version | 正整数 | 实质改变 CS、KCP、依赖或授权时递增 |\n| contract_state | DRAFT / FROZEN | 草稿可分析，冻结后才可能进入实施 |\n| scenario | algo / structural / bugfix / ops | 选择验证类别，不作为免检标签 |\n| current_stage | 规定工序枚举 | 当前业务工序，不等同宿主按钮 |\n| active_role | 四职责之一 | 当前职责，不作为身份凭据 |\n| inputs | 输入对象数组 | 路径、切片、用途、权威类别及内容身份 |\n| dependencies | 依赖对象数组 | 每项绑定上游任务、契约版本和已接受候选 |\n| execution_authorization | 批准与范围对象 | 真实批准引用及允许副作用 |\n| cs_specification | 结构化对象 | 精确交付清单、不变量、验收和接口 |\n| kcp_verification | 结构化对象 | 冻结命令、环境、预言、适配器及判定条件 |\n| sod_review | 结构化对象 | 独立策略、作者身份、签章、局限与使用指引 |\n| gate_status | 五状态枚举 | 当前流转决定，仅由受信入口提交 |\n| runtime | 运行绑定对象 | 候选、回执和并发修订定位；不是日志账本 |\n\n补充约束：\n\n- 输入内容摘要必须由工具生成，不要求模型手工计算。\n- 交付物清单必须逐文件列出创建、修改或删除操作；目录通配不得代替最终交付清单。\n- 每个验收项必须绑定必要断言及审查要求。\n- 测试、Lint 与构建按影响范围选择；不机械要求每种任务运行全库。\n- 接口条目中的退出码、参数和行为是待实施契约，不是当前已有接口事实。\n- 暂存产物和验证输出必须另列允许范围，不能混入生产交付清单。\n\n### 2.6 状态机与门禁\n\n五种门禁状态保持用户指定枚举，不添加含混的“基本通过”。\n\n| 状态 | 含义 | 允许行为 |\n|---|---|---|\n| READY | 等待分析、冻结或实施接管 | 只能进行当前批准范围内的准备；不是无条件可执行 |\n| IN_PROGRESS | 当前候选正在实施或自测 | 不释放给依赖下游 |\n| IN_REVIEW | 候选已固定，等待机器复核和独立审查 | 禁止修改候选；修改须退出审查 |\n| ACCEPTED | 当前候选满足双重门禁 | 仅允许另获批准的下游动作 |\n| REJECTED | 当前候选不满足验收 | 保留现场，允许获准返工，不推进依赖 |\n\n另用 runtime.halt 表示 NONE、BLOCKED 或 SUSPENDED，不用 ACCEPTED 掩盖缺失证据。\n\n合法转换：\n\n1. READY → IN_PROGRESS：契约冻结、授权有效、输入与依赖有效、实施范围明确。\n2. IN_PROGRESS → IN_REVIEW：候选固定、CS 差异完整、自测证据齐全。\n3. IN_REVIEW → ACCEPTED：机器检查、独立签章及绑定一致性全部成立。\n4. IN_REVIEW → REJECTED：存在明确检查失败或审查拒绝。\n5. REJECTED → IN_PROGRESS：返工仍在获准范围内；新建尝试并使旧签章失效。\n\n缺证据时停留在相应非接受状态，并标明 BLOCKED。候选或契约变化后，不允许沿用 ACCEPTED；重开须获得授权并进入新尝试。\n\n### 2.7 单焦点入口\n\n对应工件：[`specs/tasks/_active.md`](specs/tasks/_active.md)。\n\n```yaml\n---\nschema_version: bmad.active/v1\ngeneration: 0\ntask_id: null\ntask_path: null\n---\n```\n\n规则：\n\n- null 表示没有默认焦点，是正常状态。\n- 非空时标识与路径必须同时存在，且指向有效任务。\n- 不保存阶段、角色、门禁状态或任务清单，避免双写。\n- 用户显式指定任务时跳过默认入口；显式任务缺失不得静默替换。\n- 切换焦点必须确认原任务已完成或获准暂停，保留全部未完成事项。\n- 使用锁及 generation 比较交换提交；目标任务的 focus_generation 必须匹配。\n- 指针与任务绑定不一致时停止副作用，不能猜测谁较新。\n\n“单焦点”不表示删除其他任务；它只限制默认交互入口。\n\n### 2.8 Archive 契约\n\n归档目标采用日期加任务标识，例如 [`specs/tasks/archive/2026-10-27/TU-GOV-0001.md`](specs/tasks/archive/2026-10-27/TU-GOV-0001.md)。\n\n归档必须满足：\n\n1. 当前候选已接受，任务声明的交付义务已完成。\n2. 如契约要求合并或领域沉淀，已取得相应完成证据。\n3. 当前用户批准归档；目标不得覆盖。\n4. 保存任务、签章及必要证据的完整封存副本并核对摘要。\n5. 重新核对源身份、版本与焦点；源变化时保留源并停止。\n6. 清除匹配的焦点后，再按批准范围移除活动源。\n\n跨文件操作不假设整体原子性。必须使用可恢复提交步骤；中断、磁盘失败或校验失败时保留源和诊断，不清空入口掩盖失败。\n\n归档保留 ACCEPTED 的历史含义，但不赋予新环境的运行许可。历史恢复必须新建任务实例，引用来源，重新批准并验证。\n\n原始证据的保留策略必须在任务中明确；不能一律放进本地忽略目录后宣称跨机器可追溯。\n\n## 3. 模块三：“刚刚好”的 Data Flow Contracts\n\n### 3.1 上下游交接表\n\n| 交接 | 必须输出 | 严禁输出 | 下游接收门禁 |\n|---|---|---|---|\n| Analyst → Architect | 业务目标、不变量、验收、约束、输入定位、必要非目标、未决问题 | 大段聊天、未经核实的项目事实、提前锁死的实现细节、伪造评分 | 目标可判读；关键歧义明确，阻塞项不冒充已解决 |\n| Architect → Coder | 冻结任务契约、精确交付清单、接口与所有权、依赖、获准范围、KCP、失败与清理要求 | 完整研究流水、无关候选、未标注的假接口、无批准的命令 | 契约、输入、依赖、授权和预言均有效 |\n| Coder → Supervisor | 固定候选、精确差异、实际变更文件、真实自测回执、已知局限、需重点审查的边界 | 仅“测试全绿”、模型自制通过 JSON、凭据、完整无界日志、自行批准 | 候选身份稳定；回执可核验；范围无越界 |\n| Supervisor → 领域规范 | 已过审且已交付的稳定不变量、接口、必要验证要求、任务与决策溯源 | 逐轮流水、未实现设计、未经批准特性、全部失败日志、自审即签章 | 独立接受有效；领域变更已审查且获得发布授权 |\n\n### 3.2 交接最小内容\n\n每次交接只回答：\n\n- 下游要完成什么？\n- 消费哪些具体输入？\n- 必须保持哪些业务约束？\n- 哪些行为已被授权？\n- 如何判定交付合格？\n- 哪些问题仍未知或阻塞？\n\n不能为了压缩而删掉必要约束，也不能为了完整而附上全部历史。\n\n### 3.3 公共领域规范沉淀\n\n目标工件为 [`specs/.md`](specs/)。\n\n沉淀流程必须是：\n\n1. Architect 在任务 CS 中声明拟修改的领域规范文件和内容范围。\n2. Coder 形成候选领域规范变更，与实现一起进入审查。\n3. Supervisor 验证文档中的行为与实际候选、必要运行证据一致。\n4. 独立审查者批准包含该文档变更的候选。\n5. 获得发布授权后提交；未交付特性不得描述成当前事实。\n\n若文档是在 ACCEPTED 后新增或实质改写，该文档构成新候选变化，必须重新审查受影响部分；禁止用“知识沉淀”绕开代码与规范一致性检查。\n\n领域规范只保存：\n\n- 当前业务不变量与接口。\n- 当前适用验证入口。\n- 必要兼容性和已知限制。\n- 接受任务与必要决策的精确引用。\n\n任务完成记录仍留在任务工件，不复制进领域规范形成流水。\n\n## 4. 模块四：双重门禁的物理落地\n\n### 4.1 门禁公式与绑定范围\n\n采用用户给定公式：$a_t(g) = C_t^g(z_t^g) \\land R_t(g)$。\n\n在工程中，两个分量都必须解释为“对应同一任务、同一契约、同一候选、同一必要环境的有效证据”，而不是任意两个通过字符串。\n\n因此，在批准入口计算：\n\n- C：全部必需机器检查通过且回执真实有效。\n- R：独立审查批准成立，审查覆盖必需主题且无阻塞项。\n- 绑定核验：两个分量对应当前候选、契约、依赖和环境。\n\n绑定核验不是替代第三个质量门禁，而是 C 与 R 被解释为有效的前提。\n\n任何缺失、未知、过期或验证异常均不能取真。\n\n### 4.2 契约摘要与候选身份\n\n契约摘要由受信程序对规范化结构计算，包含：\n\n- 任务身份、业务目标及契约版本。\n- 输入、依赖、批准范围。\n- CS、KCP 和独立审查策略。\n\n摘要排除当前阶段、状态修订号、回执引用和签章结果，避免“记录通过 → 摘要变化 → 永久失效”的自引用循环。\n\n正文不能额外定义未纳入结构化契约的执行要求。\n\n候选清单必须覆盖：\n\n- 全部交付物及实际变更文件。\n- 相关测试、配置、依赖与受影响的接口。\n- 删除操作和必要未变文件的内容身份。\n- 当前验证环境和受信预言身份。\n\n内容摘要用于一致性，不自动证明来源可信或防篡改。\n\n### 4.3 验证运行与证据隔离\n\n证据目录按任务和尝试组织，例如 [`verification/TU-GOV-0001/`](verification/TU-GOV-0001/)。\n\n每次验证必须：\n\n1. 固定候选快照，阻止验证过程中被实现者改写。\n2. 固定已经批准的命令、环境及测试预言。\n3. 串行、前台执行，封闭标准输入。\n4. 使用进程级超时，并确认超时后的进程树与资源清理。\n5. 收集真实命令、工作目录、时间、退出状态、收集数量及必要输出。\n6. 保存受限日志；敏感信息按既定策略脱敏，不删除判定所需信息。\n7. 由收集器生成回执，不由模型手工写入“通过”。\n\n验证输出目录不是执行级沙箱。网络、文件系统、凭据、进程与外部服务的隔离必须分别实现并取得证据。\n\n### 4.4 回执格式\n\n当前机器回执工件为 [`verification/TU-GOV-0001.verdict.json`](verification/TU-GOV-0001.verdict.json)。\n\n以下是未运行状态的完整格式示例，不代表成功回执：\n\n```json\n{\n \"schema_version\": \"bmad.verdict/v1\",\n \"task_id\": \"GOV-0001\",\n \"contract_version\": 1,\n \"contract_digest\": null,\n \"attempt\": 0,\n \"run_id\": null,\n \"candidate\": {\n \"manifest_path\": null,\n \"manifest_sha256\": null,\n \"snapshot_id\": null\n },\n \"environment\": {\n \"fingerprint\": null,\n \"host_version\": null,\n \"interpreter_version\": null,\n \"dependency_snapshot\": null,\n \"trusted_oracle_digest\": null,\n \"network_policy\": \"denied\"\n },\n \"producer\": {\n \"runner_id\": null,\n \"principal_ref\": null,\n \"attestation_ref\": null\n },\n \"started_at\": null,\n \"finished_at\": null,\n \"checks\": [\n {\n \"check_id\": \"KCP-02\",\n \"required\": true,\n \"argv\": [\n \"python3\", \"-m\", \"unittest\", \"discover\",\n \"-s\", \"tests/tasks\", \"-p\", \"test_task_gate.py\"\n ],\n \"cwd\": \".\",\n \"timeout_seconds\": 30,\n \"kill_grace_seconds\": 2,\n \"process_exited\": false,\n \"exit_code\": null,\n \"timed_out\": false,\n \"cancelled\": false,\n \"collected\": null,\n \"passed\": null,\n \"failed\": null,\n \"required_skipped\": null,\n \"adapter\": \"unittest-v1\",\n \"adapter_valid\": false,\n \"required_assertions\": {},\n \"stdout_path\": null,\n \"stdout_sha256\": null,\n \"stderr_path\": null,\n \"stderr_sha256\": null,\n \"status\": \"NOT_RUN\"\n }\n ],\n \"cleanup\": {\n \"required\": true,\n \"status\": \"UNKNOWN\",\n \"evidence_ref\": null\n },\n \"aggregate\": {\n \"required_checks_complete\": false,\n \"candidate_unchanged\": false,\n \"contract_unchanged\": false,\n \"machine_gate\": \"UNKNOWN\",\n \"reason_codes\": [\"NOT_EXECUTED\"]\n }\n}\n```\n\n字段语义：\n\n- producer 必须能定位实际收集主体；自填名称不构成认证。\n- checks 必须覆盖契约中的全部必需检查，不允许遗漏。\n- collected 不适用于某类静态检查时可以为 null，但该检查必须提供已声明的结构化断言。\n- 对测试适配器，零收集、数量未知或必需项跳过不能通过。\n- timed_out 和 cancelled 独立于退出码；退出零不能掩盖取消、解析失败或缺失输出。\n- cleanup 为 UNKNOWN 时，必需清理不能通过。\n- machine_gate 仅为 PASS、FAIL、UNKNOWN，不包含任务审批状态。\n\n### 4.5 回执权威性与历史保存\n\n当前回执文件只代表当前最近一次已提交的验证结果，不是审批文件。\n\n在替换当前回执前，必须将旧回执完整封存到任务尝试目录。历史副本只用于审计，不能因为其中存在 PASS 而自动选择它作为当前结果。\n\n回执必须由受信入口写入或认证。若 Coder 可以同时改写候选、回执和批准记录，目录分离与摘要无法提供物理内控保证。\n\n严格场景应使用独立账户、受保护存储或受保护 CI 执行入口；同一操作系统账户下的“约定不可修改”只能报告为行为约束。\n\n### 4.6 C 的判断逻辑\n\n机器门禁 PASS 必须同时满足：\n\n- 回执结构、来源及内容身份可核验。\n- 任务、契约、候选和必要环境匹配当前绑定。\n- 必需检查集合完整，实际参数与冻结命令一致。\n- 每个必需检查进程真实退出，满足允许退出码。\n- 没有超时、取消、结果解析错误或必要输出缺失。\n- 测试达到规定收集要求，没有必需项跳过。\n- 所有声明的必要物理断言成立。\n- 必需清理完成，验证前后候选保持一致。\n\n明确断言失败时记 FAIL；缺依赖、缺记录、身份不可核验或采集异常时记 UNKNOWN。两者都拒绝下游释放。\n\n### 4.7 独立反向审查报告与签章\n\n审查附件按任务组织，例如 [`specs/tasks/TU-GOV-0001/review-R001.json`](specs/tasks/TU-GOV-0001/review-R001.json)。\n\n签章对象完整结构如下，未批准时保留 null：\n\n```json\n{\n \"schema_version\": \"bmad.review/v1\",\n \"review_id\": \"R001\",\n \"task_id\": \"GOV-0001\",\n \"contract_version\": 1,\n \"contract_digest\": null,\n \"candidate_manifest_sha256\": null,\n \"verdict_sha256\": null,\n \"reviewer\": {\n \"principal_ref\": null,\n \"authentication_ref\": null,\n \"independence_verified\": false\n },\n \"topics\": [\n {\n \"topic_id\": \"BOUNDARIES\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n },\n {\n \"topic_id\": \"EXCEPTIONS_AND_CLEANUP\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n },\n {\n \"topic_id\": \"BYPASS_AND_STALE_EVIDENCE\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n },\n {\n \"topic_id\": \"ORACLE_INDEPENDENCE\",\n \"status\": \"NOT_REVIEWED\",\n \"evidence_refs\": [],\n \"conclusion\": null\n }\n ],\n \"findings\": [],\n \"known_limitations\": [],\n \"downstream_guidance\": [],\n \"decision\": \"PENDING\",\n \"approval\": {\n \"approved_at\": null,\n \"approval_event_ref\": null,\n \"signed_payload_sha256\": null,\n \"signature_ref\": null\n }\n}\n```\n\n审查必须关注实际相关风险：\n\n- 边界输入、空集合、重复请求及状态转换。\n- 未捕获异常、取消、超时、部分失败与资源释放。\n- 依赖错误、候选漂移、过期回执与并发提交。\n- 权限越界、回执伪造、审查身份复用。\n- 测试预言被实现者降低、错误实现仍然“全绿”。\n\n每个发现必须记录严重性、证据、违反的 CS 标识和处理要求。存在未解决阻塞发现时不得 APPROVE；已知局限不能用来豁免必要验收。\n\n签章规则：\n\n1. 批准者身份不属于当前候选作者集合。\n2. 批准事件来自模型不能伪造的身份入口。\n3. 批准载荷绑定契约、候选和机器回执。\n4. 必需主题已审查，结论有依据。\n5. 审查决定和局限性被批准事件覆盖，不能批准后改写。\n\n密码学签名不是唯一可用方式；受认证的平台批准事件也可以作为证据。但事件身份、载荷绑定和查询验证必须实际成立，不能仅记录一个任意链接。\n\n任务中的 sod_review.signoff 只引用当前有效报告和批准事件，不复制第二份可编辑报告正文。\n\n### 4.8 接受提交的并发与释放控制\n\n接受入口必须在固定候选上完成：\n\n1. 获取任务锁，读取当前 state_revision。\n2. 核对契约、候选、C、R 与批准范围。\n3. 重新检查候选未变化。\n4. 通过比较交换提交 ACCEPTED，并记录绑定引用。\n5. 下游释放入口再次核对绑定，而不是仅检查状态字符串。\n\n验证、审查和合并之间的候选变化必须被发现。若无法固定快照或防止竞态，相关释放保持 BLOCKED。\n\nACCEPTED 不是任意生产代码直接合并的许可；合并、提交、推送、部署及归档分别受授权控制。\n\n### 4.9 REJECTED 回退与现场保护\n\n拒绝当前候选后必须：\n\n- 保留差异、候选清单、日志、失败回执和审查发现。\n- 阻断依赖下游，不更新公共领域事实。\n- 保留用户既有改动及未授权文件。\n- 将失败分类为契约问题、实现问题、环境问题、采集问题或审查阻塞。\n- 在当前授权和预算内允许针对性返工；不降低断言，不删除必要测试。\n- 新尝试使用新 run_id，并使旧候选签章失效。\n\n契约本身错误时返回 Plan 修订；实质改变目标、接口、所有权或验收必须重新批准。\n\n不得默认执行整库重置、整目录删除或自动生产回滚。只回退可定位且获准的改动；资源清理不明时先阻塞，而不是假设现场安全。\n\n### 4.10 门禁程序自身的可信启动\n\n任务门禁的实现不能仅依赖自己生成的 PASS 证明自己可信。\n\n首轮实施必须由独立审查者确认：\n\n- 验收预言来自冻结且不由候选随意修改的基准。\n- 正常实现能通过，故意破坏的实现会失败。\n- 校验器、收集器和释放入口分别经过验证。\n- 被测候选不能控制最终批准身份或受保护验证记录。\n\n未建立可信启动证据前，只能报告局部静态或隔离验证，不能宣布完整物理门禁已经接管。\n\n## 5. 模块五：Roo Code / Cline 配置与 Prompt 映射\n\n### 5.1 宿主适配原则\n\n宿主只承载交互、工具和审批；项目任务契约仍只有一份。\n\n以下提示词可作为规则内容使用，但配置发现路径、模式信号和拦截接口必须在目标版本核验。本次没有目标宿主运行回执；对自动发现、自动角色绑定及字段级拒绝行为：Insufficient evidence。\n\n不得通过本草案开启自动批准、安装扩展、重载 IDE 或扩大分发集合。\n\n### 5.2 公共路由 Prompt\n\n规则入口候选为文件型 [` .clinerules`](.clinerules) 或目标宿主实际支持的项目规则位置。不要同时维护两份内容不同的项目规则。\n\n```text\n你服务于单一端到端软件业务流，只有 Plan 与 Act 两个基础交互动作。\nAnalyst、Architect、Coder、Supervisor 是任务工序职责，不是独立文档体系。\n\n项目任务唯一权威源为 specs/tasks/TU-.md。\n显式任务优先；未显式指定时读取 specs/tasks/_active.md。\n默认入口为空是正常状态；显式任务缺失不得静默替换。\n\n只使用宿主实际提供的模式信号和当前用户批准范围。\n角色切换、任务读取和提示词不能增加工具权限。\n\nPlan 按任务工序采用 Analyst 或 Architect 视角。\n默认只读，不运行终端、不修改生产代码、不创建或执行探针。\n获准持久化时只交接明确文档范围，不顺带实施。\n\nAct 前半段采用 Coder 视角，仅实施获准范围。\nAct 后半段采用 Supervisor 视角，固定候选并进行反向审查。\n同一模型的 Supervisor 自审不得产生独立审查批准。\n\n没有真实机器回执及可核验独立签章时，不请求接受或下游释放。\n失败、超时、缺失、过期和未知都不能当作通过。\n不得直接改写门禁状态、伪造回执或填写审查身份。\n\n只加载当前任务所需输入、差异及证据。\n保留全部未完成义务；不要交接完整聊天和内部推理过程。\n压缩或恢复后重新读取权威任务，不继承摘要中的历史绿灯。\n```\n\n### 5.3 四工序 Prompt 片段\n\n#### Analyst\n\n```text\n当前职责：Analyst；当前工序：PLAN_ANALYZE。\n读取用户目标和任务 inputs，区分事实、用户陈述、推断与未知。\n提炼业务不变量、可观察验收、约束与必要非目标。\n不预设不必要的技术方案，不编造成本、权重或评分。\n输出 Task Spec Draft 及确实阻塞设计的问题。\n只读咨询只会话交付；持久化须有明确授权和实际权限。\n```\n\n#### Architect\n\n```text\n当前职责：Architect；当前工序：PLAN_DESIGN。\n消费业务目标与验收，不重新制造第二份需求文档。\n先按权限、兼容性、资源和时间硬门禁筛选，再比较候选。\n固化精确交付文件、接口、所有权、依赖、KCP 和 SOD 要求。\n验证命令声明环境、超时、收集规则、必要输出和清理要求。\n缺失资产标记待实现；未知不写成通过。\n契约冻结后停止，不自动切换并启动实施或实验。\n```\n\n#### Coder\n\n```text\n当前职责：Coder；当前工序：ACT_IMPLEMENT。\n直接消费已批准且冻结的任务契约，不重复完整分析。\n预检输入、依赖、授权范围及既有改动。\n仅实施 CS 声明的交付物及获准暂存范围。\n运行任务声明的相关验证，使用真实工具结果生成证据。\n不修改独立审查策略、受信预言、批准身份或门禁状态。\n提交固定候选、实际差异、自测回执及已知局限后停止。\n```\n\n#### Supervisor\n\n```text\n当前职责：Supervisor；当前工序：ACT_REVIEW。\n先读取目标、CS、必要领域约束和固定候选差异，再读作者解释。\n核对实际交付范围和机器回执，检查边界、异常、清理及绕过风险。\n新增必要物理断言须走获准验证入口，不私自扩大命令范围。\n输出有证据定位的审查发现、局限性及下游使用指引。\n如果你与 Coder 是同一 Agent，你的结论仅为审查建议。\n独立批准必须来自非作者且身份可核验的主体。\n未经有效 C 与 R，不请求 ACCEPTED、合并或发布。\n```\n\n### 5.4 Cline 的交互映射\n\n目标交互保持两个按钮，不要求用户输入四套角色命令：\n\n- Plan + PLAN_ANALYZE：加载 Analyst 框架。\n- Plan + PLAN_DESIGN：加载 Architect 框架。\n- Act + ACT_IMPLEMENT：加载 Coder 框架。\n- Act + ACT_REVIEW：加载 Supervisor 框架；等待独立批准。\n\n文档保存若必须在 Act 中完成，应使用“仅文档保存”授权范围，保存后停止。不能将保存任务升级为生产实施。\n\n若宿主无法自动提供可信工序信号，可以从任务契约读取工序；但该工序值仍须由受信状态入口维护，不由模型自由改写。\n\n若只实现提示词路由，则交付必须写明“行为适配”，不得称为程序权限隔离。\n\n### 5.5 Roo 的两职责配置草案\n\n下面是与现有两职责结构对齐的静态配置草案，不是对已加载配置的修改，也不证明目标 Roo 版本的运行拒绝行为。\n\n对应评审入口：[`custom_modes.yaml`](bmad-suite-v4/roo/settings/custom_modes.yaml:1)。\n\n```yaml\ncustomModes:\n - slug: ana-architect\n name: Plan：业务分析与架构\n roleDefinition: >-\n 在端到端业务流中承担 Analyst 与 Architect 职责。\n 只读分析，不实施生产代码，不运行终端或探针。\n groups:\n - read\n - browser\n customInstructions: >-\n 显式任务优先；否则读取 specs/tasks/_active.md。\n