@godv61/dsh-task-engine 0.23.1 → 0.23.3

package/rules/security-redlines.md

@@ -1,6 +1,6 @@
-# 安全红线
-
-- 禁止读取、展示或修改密码、Token、私钥和生产凭据。
-- 禁止把敏感请求体、文件正文或凭据写入日志。
-- 禁止用户输入直接拼接 SQL、表名、列名、排序、路径或命令。
+# 安全红线
+
+- 禁止读取、展示或修改密码、Token、私钥和生产凭据。
+- 禁止把敏感请求体、文件正文或凭据写入日志。
+- 禁止用户输入直接拼接 SQL、表名、列名、排序、路径或命令。
 - 权限与关键业务校验必须在服务端执行，前端校验不是安全边界。

package/skills/code-commit/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: code-commit
-description: 提交节点：校验阶段、文件范围与消息格式，执行范围受控的本地提交。以 dev_task status 返回的提交检查点为准，标准流程在代码审核通过后提交。
+description: 提交节点：校验阶段、文件范围与消息格式，执行范围受控的本地提交。以 dev_task status 返回的提交检查点为准，标准流程在代码审核通过后提交。
 ---
 
 # 提交
 
 1. `dev_task`（operation=commit, files=[...], message=...) 校验阶段、范围与消息格式。
 2. 拿到 approved 后逐文件 `git add <files>`（禁止 `git add .` / `git add -A`），再 `git commit -m "<message>"`。
-3. 用 `dev_task`（operation=commit, files=同一列表, message=同一消息, hash=<真实HEAD>）回写。引擎核对真实提交后才允许离开检查点。不要在回写前宣告完成。
+3. 用 `dev_task`（operation=commit, files=同一列表, message=同一消息, hash=<真实HEAD>）回写。引擎核对真实提交后才允许离开检查点。不要在回写前宣告完成。
 4. 只提交任务 files 范围内文件；发现范围外文件、密钥或环境配置时停止并报告。
 
-不 push、不合并、不建 PR、不执行数据库、部署或发布。
+不 push、不合并、不建 PR、不执行数据库、部署或发布。

package/skills/code-implement/SKILL.md

@@ -1,24 +1,24 @@
 ---
 name: code-implement
-description: 开发节点：按方案拆解实施项，独立交付可派子 agent，小修正可由主 agent 实施；经「规格符合 → 代码质量」两阶段审查通过才记完成。仅在任务处于「开发」阶段时使用（以 dev_task status 的 stage 为准）。
+description: 开发节点：按方案拆解实施项，独立交付可派子 agent，小修正可由主 agent 实施；经「规格符合 → 代码质量」两阶段审查通过才记完成。仅在任务处于「开发」阶段时使用（以 dev_task status 的 stage 为准）。
 ---
 
 # 代码实现
 
 进入本节点时需求与方案均已确认。按顺序，一项一项做：
 
-1. `dev_task`（operation=status）读当前阶段、风险、实施项明细与验证基线。实施项按能独立审查的交付内容拆分，不为达到任意时间粒度重复拆同一调用链；用 `dev_task`（operation=items, items=[...]) 记录清单，后续可通过 status 读取明细和审核记录。
-2. 按改动选择执行方式：独立功能或需要隔离上下文的重做，可先 `dev_task`（operation=dispatch, item_id=<本项 id>, description=<目标与范围>）登记派发计划，工具会把该项设为唯一 doing，再派一个 fresh 子 agent。主 agent 可直接完成范围清楚的小修正（如测试文件移位），先用 items 标 doing，完成后仍须真实验证和两阶段审核，不补造 dispatch。
+1. `dev_task`（operation=status）读当前阶段、风险、实施项明细与验证基线。实施项按能独立审查的交付内容拆分，不为达到任意时间粒度重复拆同一调用链；用 `dev_task`（operation=items, items=[...]) 记录清单，后续可通过 status 读取明细和审核记录。
+2. 按改动选择执行方式：独立功能或需要隔离上下文的重做，可先 `dev_task`（operation=dispatch, item_id=<本项 id>, description=<目标与范围>）登记派发计划，工具会把该项设为唯一 doing，再派一个 fresh 子 agent。主 agent 可直接完成范围清楚的小修正（如测试文件移位），先用 items 标 doing，完成后仍须真实验证和两阶段审核，不补造 dispatch。
    - 用 `subagent` 工具，前台调用（默认等结果，不设 run_in_background）。
    - prompt 必须自包含（子 agent 看不到本对话），写清：任务目标（引用需求/方案要点）、本项要做什么、只改本项和必要调用方（不顺带重构）、可改的文件范围、完成标准，并要求返回「改动文件清单 + 验证结果/命令」。
-   - 明令子 agent：只实现这一项、跑本地验证，不要调 dev_task 流转、不要 items、不要 commit、不要 push。
-   - 权限或沙箱拒绝时保留失败，核对路径和调用配置后使用 Harness 正式审批机制；没有可用审批时报告阻塞并返回主 agent。不得反复换删除命令、切 shell、改 ACL 或削弱验证来规避同一拒绝。子任务 prompt 必须包含此约束。
-   - 不要等子代理返回才登记派发，否则任务台账会在实际开发时一直显示 todo。dispatch 只是计划记录，实际执行由子代理工具调用和结果证明；重派会使该项旧审核失效。
-3. 本项实现完成后（主 agent 实施或子 agent 返回），主 agent 做两阶段审查（顺序不可反）：
+   - 明令子 agent：只实现这一项、跑本地验证，不要调 dev_task 流转、不要 items、不要 commit、不要 push。
+   - 权限或沙箱拒绝时保留失败，核对路径和调用配置后使用 Harness 正式审批机制；没有可用审批时报告阻塞并返回主 agent。不得反复换删除命令、切 shell、改 ACL 或削弱验证来规避同一拒绝。子任务 prompt 必须包含此约束。
+   - 不要等子代理返回才登记派发，否则任务台账会在实际开发时一直显示 todo。dispatch 只是计划记录，实际执行由子代理工具调用和结果证明；重派会使该项旧审核失效。
+3. 本项实现完成后（主 agent 实施或子 agent 返回），主 agent 做两阶段审查（顺序不可反）：
    - 规格符合：对照需求/方案，查「做对了没、有没有超范围、漏没漏边界」。
    - 代码质量：按内置规则 coding-conventions 查「做得好不好」——契约兼容、边界与错误处理、命名与结构。
 4. 审查完用 `dev_task`（operation=review_item, item_id=<本项 id>, spec_outcome=pass|fail, quality_outcome=pass|fail, notes=[结论或问题清单]) 落两阶段结论留痕。
-5. 任一阶段不过：按第 2 步选择主 agent 小修正或 fresh 子 agent 重做，明确上次的问题；重做后再审查，并再次 `review_item` 覆盖前次结论。只改测试路径或文案时，运行受影响的定向检查，不重复无关的全量编译。
-6. **两阶段都 pass 后**才用 `dev_task`（operation=items, items=[...]) 全量回写，把本项标 done（其余项原样保留）；已有项可只传 id/status，省略 title 以保留原文与审核。追加修复项时不要重写已完成项标题；确需改标题应显式重开并重新审核。spec 或 quality 任一 fail 都不许标 done，回到第 5 步重做。
+5. 任一阶段不过：按第 2 步选择主 agent 小修正或 fresh 子 agent 重做，明确上次的问题；重做后再审查，并再次 `review_item` 覆盖前次结论。只改测试路径或文案时，运行受影响的定向检查，不重复无关的全量编译。
+6. **两阶段都 pass 后**才用 `dev_task`（operation=items, items=[...]) 全量回写，把本项标 done（其余项原样保留）；已有项可只传 id/status，省略 title 以保留原文与审核。追加修复项时不要重写已完成项标题；确需改标题应显式重开并重新审核。spec 或 quality 任一 fail 都不许标 done，回到第 5 步重做。
 7. 重复 2-6 直到全部 done。随后跑一次聚焦验证（目标测试、受影响模块编译、契约检查；high_risk 覆盖核心失败路径）确认整体可交付。
-8. 全部 done 才 `dev_task`（operation=advance）；`todos_done` 门会硬校验：每个 done 的项都必须带两阶段审查留痕且都 pass，缺 `review_item` 留痕会被拒绝。失败保持 doing、只记最新结果与阻塞；需求或方案变化时回退确认并停止编码。
+8. 全部 done 才 `dev_task`（operation=advance）；`todos_done` 门会硬校验：每个 done 的项都必须带两阶段审查留痕且都 pass，缺 `review_item` 留痕会被拒绝。失败保持 doing、只记最新结果与阻塞；需求或方案变化时回退确认并停止编码。

package/skills/code-review/SKILL.md

@@ -6,8 +6,8 @@ description: 代码审核节点：评审变更，产出结论与问题清单并
 # 代码审核
 
 1. `dev_task`（operation=status）读当前变更与验证结果。
-2. 评审：契约是否兼容、边界条件、错误处理、变更范围是否越界。按实际改动检查异步查询乱序、关闭/重开后的旧请求、加载/失败时旧数据可否提交，以及上游业务错误码、空响应和反序列化空对象；相邻旧实现的写法不能作为这些边界正确的证明。涉及交互时检查真实组件的事件、只读、清空和校验行为，不能只凭属性名判断。
+2. 评审：契约是否兼容、边界条件、错误处理、变更范围是否越界。按实际改动检查异步查询乱序、关闭/重开后的旧请求、加载/失败时旧数据可否提交，以及上游业务错误码、空响应和反序列化空对象；相邻旧实现的写法不能作为这些边界正确的证明。涉及交互时检查真实组件的事件、只读、清空和校验行为，不能只凭属性名判断。
 3. 结论与问题用 `dev_task`（operation=record, artifact=review, fields={conclusion, issues}）落库。
 4. 结论用 `dev_task`（operation=review, outcome=pass|blocked）记录；blocked 写清阻塞原因。
 
-是否进入本节点由冻结流程的 legal_next 决定，标准流程必须审核。发现缺陷时在当前阶段修复并重跑 verify，更新结论；不要新建“收尾任务”绕过当前门禁。完成即将进入的终态技能义务后，按 status.commit 执行本地提交并回写真实 hash，再 advance。
+是否进入本节点由冻结流程的 legal_next 决定，标准流程必须审核。发现缺陷时在当前阶段修复并重跑 verify，更新结论；不要新建“收尾任务”绕过当前门禁。完成即将进入的终态技能义务后，按 status.commit 执行本地提交并回写真实 hash，再 advance。

package/skills/code-verify/SKILL.md

@@ -6,13 +6,15 @@ description: 交付验证节点：执行目标测试、编译与契约检查，
 # 验证
 
 1. `dev_task`（operation=status）读风险等级与验收条件。
-2. 执行聚焦验证：目标测试、受影响模块编译、契约检查与必要人工步骤，不默认叠加 clean/package 全家桶。编译和源码字符串断言不证明交互或异常行为正确；按改动风险调用真实方法/组件，覆盖失败响应、请求乱序、取消重开等适用场景。外部接口不可用时可隔离依赖测试本地行为，但明确标为模拟测试，不冒充真实联调。
-3. 结果用 `dev_task`（operation=verify, command=真实验收命令, evidence=[场景与结果]）记录。新任务不接受纯文本 passed 声明；不传 command 时尝试项目 verify_command 和语言默认，但默认命令可能不覆盖验收点。退出码、取消、超时和沙箱结果由引擎采集。PowerShell 多条命令必须显式传播失败退出码，不能让最后成功的命令掩盖前面的失败。
-4. 文件或范围变更会使旧验证回执失效，审核修复后可在当前阶段重跑 verify。沙箱拒绝属于环境阻塞，不能改跑不相关的简单命令来冒充原验收通过。
-5. 环境受阻时如实记"未编译/未联调"；high_risk 核心行为无法验证时不得通过。
-
-权限或沙箱拒绝后，不得切换等价命令、修改 ACL 或安全策略来规避限制。确认错误来自宿主权限后使用 Harness 正式审批；审批不可用时报告失败路径和所需授权，等待处理，不把工具访问限制推断为服务不可达。
+2. 执行聚焦验证：目标测试、受影响模块编译、契约检查与必要人工步骤，不默认叠加 clean/package 全家桶。编译和源码字符串断言不证明交互或异常行为正确；按改动风险调用真实方法/组件，覆盖失败响应、请求乱序、取消重开等适用场景。外部接口不可用时可隔离依赖测试本地行为，但明确标为模拟测试，不冒充真实联调。
+3. 结果用 `dev_task`（operation=verify, command=真实验收命令, evidence=[场景与结果]）记录。新任务不接受纯文本 passed 声明；不传 command 时尝试项目 verify_command 和语言默认，但默认命令可能不覆盖验收点。退出码、取消、超时和沙箱结果由引擎采集。PowerShell 多条命令必须显式传播失败退出码，不能让最后成功的命令掩盖前面的失败。
+4. 文件或范围变更会使旧验证回执失效，审核修复后可在当前阶段重跑 verify。沙箱拒绝属于环境阻塞，不能改跑不相关的简单命令来冒充原验收通过。
+5. 环境受阻时如实记"未编译/未联调"；high_risk 核心行为无法验证时不得通过。
 
-验证失败不得 advance。
+权限或沙箱拒绝后，不得切换等价命令、修改 ACL 或安全策略来规避限制。确认错误来自宿主权限后使用 Harness 正式审批；审批不可用时报告失败路径和所需授权，等待处理，不把工具访问限制推断为服务不可达。
 
-测试报告应区分已执行但失败、依赖阻塞未执行、模拟接口与真实联调；每个验收点引用对应组件或接口的测试，按已有日志记录逐项结果和耗时，缺证据就注明。不得以报告行数或关键词出现替代内容审查。预计交付的测试文件和文档应尽早纳入 scope，完成修订后再登记最终回执，减少范围变化引起的重复验证。
+`verify` / `skill_result` 的验证命令因沙箱受阻时，保持原命令，增加 `sandbox_permissions: "danger-full-access"` 和具体 `justification` 申请单次重试。批准发生在命令执行之前，只对本次调用生效；回执中的实际模式与退出码才是本次结果，不能引用之前 shell 调用通过的结果替代。保存完整测试输出后从已有日志提取用例，不为截取不同摘要重复跑已通过测试。
+
+验证失败不得 advance。
+
+测试报告应区分已执行但失败、依赖阻塞未执行、模拟接口与真实联调；每个验收点引用对应组件或接口的测试，按已有日志记录逐项结果和耗时，缺证据就注明。不得以报告行数或关键词出现替代内容审查。预计交付的测试文件和文档应尽早纳入 scope，完成修订后再登记最终回执，减少范围变化引起的重复验证。

package/skills/eng-delivery/SKILL.md

@@ -14,18 +14,18 @@ whenToUse: 开始任何开发、改 bug、加功能、代码评审或提交任
 
 ## 入口
 
-1. 先 `dev_task`（operation=status, branch=当前分支）发现任务，再带 task_id 查询所选任务的详细状态；有多个候选时不要猜测：
+1. 先 `dev_task`（operation=status, branch=当前分支）发现任务，再带 task_id 查询所选任务的详细状态；有多个候选时不要猜测：
    - 没有任务 → `dev_task`（operation=create，task_id=短 ID 如 GREET-001，title=任务标题，branch=当前 git 分支，files=本任务涉及的文件列表）建立任务并停在**起始阶段**（由配置 `start_stage` 决定，默认「需求评审」），从起始阶段开始。
    - 已有任务 → **从 `status` 返回的 `stage` 继续，绝不重走已过的阶段**。每个阶段对应一个节点技能：需求评审→`requirement-analysis`、设计→`solution-design`、开发→`code-implement`、交付→`code-verify`、代码审核→`code-review` + `code-commit`、完成→收尾。只做当前 stage 那一个节点的事：完成该阶段产物、满足 guard，才 `advance` 到下一阶段。
    - 文件范围一时不清就先 `operation=create` 建任务，摸清后用 `operation=scope, files=...` 补齐。
-2. 每阶段先通过 `skill` 工具加载所有绑定技能，再执行其指引；仅看到技能名称不算执行。完成本阶段产物后：
-   - 内置七项（eng-delivery、requirement-analysis、solution-design、code-implement、code-verify、code-review、code-commit）使用现有 record/verify/review/commit 门禁，**不需要 skill_result**，即使项目配置显式列出了这些名称。仅对 status.skill_obligations.command_receipts_required 列出的附加技能记录 skill_result；不要为内置节点重复写“检查字段非空”的验证命令。
-   - 新任务的附加技能还需 `operation=skill_result, skill_name=技能名, target_stage=所属阶段, evidence=[实际场景与结果], command=真实验收命令`。命令由引擎执行，失败不能流转；非测试技能可用检查其交付文件内容的命令，不能用 echo/恒成功命令代替验收。
-   - `status.skill_obligations` 包含紧邻的终态绑定：例如挂在“完成”的 software-testing，需要在代码审核阶段提前加载、执行、记录，再提交和进入完成。不要等宣告完成后才测试。
-   - 标准流程在代码审核阶段完成评审后提交；其他流程以 `status.commit` 返回的检查点为准。审核修复允许留在当前阶段处理，但改动后须重新验证，更新评审结论。
+2. 每阶段先通过 `skill` 工具加载所有绑定技能，再执行其指引；仅看到技能名称不算执行。完成本阶段产物后：
+   - 内置七项（eng-delivery、requirement-analysis、solution-design、code-implement、code-verify、code-review、code-commit）使用现有 record/verify/review/commit 门禁，**不需要 skill_result**，即使项目配置显式列出了这些名称。仅对 status.skill_obligations.command_receipts_required 列出的附加技能记录 skill_result；不要为内置节点重复写“检查字段非空”的验证命令。
+   - 新任务的附加技能还需 `operation=skill_result, skill_name=技能名, target_stage=所属阶段, evidence=[实际场景与结果], command=真实验收命令`。命令由引擎执行，失败不能流转；非测试技能可用检查其交付文件内容的命令，不能用 echo/恒成功命令代替验收。
+   - `status.skill_obligations` 包含紧邻的终态绑定：例如挂在“完成”的 software-testing，需要在代码审核阶段提前加载、执行、记录，再提交和进入完成。不要等宣告完成后才测试。
+   - 标准流程在代码审核阶段完成评审后提交；其他流程以 `status.commit` 返回的检查点为准。审核修复允许留在当前阶段处理，但改动后须重新验证，更新评审结论。
    - 若本阶段配置了必交产物（`dev_task` operation=status 会列出 still missing 的字段），先用 `dev_task`（operation=record, artifact=..., fields=...）逐字段记录；字段不填全，流转会被 `artifacts_present` guard 拒绝。
    - 再用 `dev_task`（operation=advance）流转到目标阶段；被拒绝说明 guard 未满足（需求/方案未获人批准 / 产物字段没填全 / 实施项没完 / 高风险没验证 / 评审没过），先补齐再重试，不得绕过。
-3. 提交前用 `dev_task`（operation=commit, files=<要提交的文件列表>, message=...）校验阶段、文件范围与消息格式；拿到 approved 后再逐文件 git add 和 git commit，并把 commit hash 通过 `dev_task`（operation=commit, files=同一列表, message=同一消息, hash=真实HEAD）回写。引擎核对 Git HEAD、消息和实际文件。没有回写成功，不得离开提交检查点。落在任务 files 之外的文件先明确与当前需求的关系，必要时更新 scope；无关工作另开任务。
+3. 提交前用 `dev_task`（operation=commit, files=<要提交的文件列表>, message=...）校验阶段、文件范围与消息格式；拿到 approved 后再逐文件 git add 和 git commit，并把 commit hash 通过 `dev_task`（operation=commit, files=同一列表, message=同一消息, hash=真实HEAD）回写。引擎核对 Git HEAD、消息和实际文件。没有回写成功，不得离开提交检查点。落在任务 files 之外的文件先明确与当前需求的关系，必要时更新 scope；无关工作另开任务。
 
 ## 硬规则
 
@@ -35,4 +35,4 @@ whenToUse: 开始任何开发、改 bug、加功能、代码评审或提交任
 - 阶段必交产物（如需求说明、设计文档、评审记录）必须用 `dev_task` operation=record 落库，字段不能留空、不能装样子。
 - 先声明文件范围：任务 `files` 只放本任务真正要改的文件；提交的文件必须全在 `files` 内，范围外的文件（哪怕是"顺手改一下"）也必须另开任务。
 - 只做任务范围内的本地提交；绝不 push、合并、创建 PR、执行数据库、操作 Jenkins、部署或发布。
-- `dev_task` 的拒绝是硬事实：修正前置条件，而不是换一种方式绕过。
+- `dev_task` 的拒绝是硬事实：修正前置条件，而不是换一种方式绕过。

package/skills/requirement-analysis/SKILL.md

@@ -3,14 +3,14 @@ name: requirement-analysis
 description: 需求评审节点：把一条需求拆成目标、验收、非目标和待确认项，落需求说明并等确认。仅在任务处于「需求评审」阶段时使用（以 dev_task status 的 stage 为准）。
 ---
 
-# 需求分析
+# 需求分析
 
 进入本节点时任务需求尚未确认。按顺序：
 
-1. `dev_task`（operation=status）读当前节点、任务事实及 `artifact_requirements` 的允许字段和缺项，以任务冻结流程为准。
+1. `dev_task`（operation=status）读当前节点、任务事实及 `artifact_requirements` 的允许字段和缺项，以任务冻结流程为准。
 2. 把需求拆成三块：目标（要达成什么）、验收（怎么算完成）、非目标（明确不做）。
 3. 列出疑问、矛盾、假设；存在影响范围或验收的问题时不得进入下一步，也不从沉默推断同意。
-4. 按 `artifact_requirements` 用 `dev_task`（operation=record, artifact=requirement）落需求说明。标准流程使用 `fields={scope, acceptance_criteria}`；敏捷流程只有 `scope`，将验收写在其正文中。目标、非目标、疑问、假设和待确认取舍写入允许字段的正文，不新增“待确认取舍”等字段。字段被拒绝时读取允许字段并修正本次输入，不改流程配置或任务 JSON 来绕过校验。
+4. 按 `artifact_requirements` 用 `dev_task`（operation=record, artifact=requirement）落需求说明。标准流程使用 `fields={scope, acceptance_criteria}`；敏捷流程只有 `scope`，将验收写在其正文中。目标、非目标、疑问、假设和待确认取舍写入允许字段的正文，不新增“待确认取舍”等字段。字段被拒绝时读取允许字段并修正本次输入，不改流程配置或任务 JSON 来绕过校验。
 5. 完成后用 `dev_task`（operation=advance）流转；系统会向人发起「需求确认」审批，批准才放行。
 
-需求未获人批准不得 advance 到下一节点。
+需求未获人批准不得 advance 到下一节点。

package/skills/solution-design/SKILL.md

@@ -8,12 +8,12 @@ description: 设计节点：产出最小方案、改动点与技术选择，落
 进入本节点时需求已确认、方案尚未确认。按顺序：
 
 1. `dev_task`（operation=status）读当前节点与待办。
-2. 产出最小方案：技术基线、修改位置与做法、明确保持不变的部分。
-   - 外部接口字段、请求和响应形态需来自实际文档或用户明确口径。通用网页工具拒绝内网地址，不代表接口本身不可达；使用可用且获授权的文档/浏览器能力，或请用户提供对应内容。不能把关键字段的猜测当成可实施契约。
-   - UI 行为须核对当前组件版本和调用关系；属性名称看起来正确，不代表组合后实际生效。
-   - 已确认业务范围不变的技术契约纠正，记录在当前设计并注明来源即可；不要为修改当前方案扫描 Harness/插件实现或手改历史审批状态。实质改变业务范围时再交用户决定。
+2. 产出最小方案：技术基线、修改位置与做法、明确保持不变的部分。
+   - 外部接口字段、请求和响应形态需来自实际文档或用户明确口径。通用网页工具拒绝内网地址，不代表接口本身不可达；使用可用且获授权的文档/浏览器能力，或请用户提供对应内容。不能把关键字段的猜测当成可实施契约。
+   - UI 行为须核对当前组件版本和调用关系；属性名称看起来正确，不代表组合后实际生效。
+   - 已确认业务范围不变的技术契约纠正，记录在当前设计并注明来源即可；不要为修改当前方案扫描 Harness/插件实现或手改历史审批状态。实质改变业务范围时再交用户决定。
 3. 不做投机性抽象：单一调用方不为"以后可能复用"新增抽象层或包装层，优先复用相邻实现；语言特定的分层与命名约定由项目挂载的 rule 约束，不在这里预设。
-4. 读取 `status.artifact_requirements`，用其允许字段记录设计；标准流程为 `dev_task`（operation=record, artifact=design, fields={approach, risks, impact}）。技术取舍写入 approach，未解决风险写入 risks，不自行新增字段。
-5. 在聊天中展示方案要点、关键契约和待确认项，再用 `dev_task`（operation=advance）流转；系统发起「方案确认」审批，批准才放行。被驳回时先获取修改意见，修订并重提；不要把驳回默认解释为误操作，也不要自动重试。
+4. 读取 `status.artifact_requirements`，用其允许字段记录设计；标准流程为 `dev_task`（operation=record, artifact=design, fields={approach, risks, impact}）。技术取舍写入 approach，未解决风险写入 risks，不自行新增字段。
+5. 在聊天中展示方案要点、关键契约和待确认项，再用 `dev_task`（operation=advance）流转；系统发起「方案确认」审批，批准才放行。被驳回时先获取修改意见，修订并重提；不要把驳回默认解释为误操作，也不要自动重试。
 
-方案未获人批准不得进入实现。
+方案未获人批准不得进入实现。