@godv61/dsh-task-engine 0.26.1 → 0.27.1

package/skills/code-implement/SKILL.md

@@ -1,24 +0,0 @@
----
-name: code-implement
-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。
-   - 用 `subagent` 工具，前台调用（默认等结果，不设 run_in_background）。
-   - prompt 必须自包含（子 agent 看不到本对话），写清：任务目标（引用需求/方案要点）、本项要做什么、只改本项和必要调用方（不顺带重构）、可改的文件范围、完成标准，并要求返回「改动文件清单 + 验证结果/命令」。
-   - 明令子 agent：只实现这一项、跑本地验证，不要调 dev_task 流转、不要 items、不要 commit、不要 push。
-   - 权限或沙箱拒绝时保留失败，核对路径和调用配置后使用 Harness 正式审批机制；没有可用审批时报告阻塞并返回主 agent。不得反复换删除命令、切 shell、改 ACL 或削弱验证来规避同一拒绝。子任务 prompt 必须包含此约束。
-   - 不要等子代理返回才登记派发，否则任务台账会在实际开发时一直显示 todo。dispatch 只是计划记录，实际执行由子代理工具调用和结果证明；重派会使该项旧审核失效。
-3. 本项实现完成后（主 agent 实施或子 agent 返回），主 agent 做两阶段审查（顺序不可反）：
-   - 规格符合：对照需求/方案，查「做对了没、有没有超范围、漏没漏边界」。
-   - 代码质量：按当前任务为本技能配置的规则（若有）及实际代码契约查「做得好不好」——契约兼容、边界与错误处理、命名与结构；不自行补用未绑定的内置规则。
-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 步重做。
-7. 重复 2-6 直到全部 done。随后跑一次聚焦验证（目标测试、受影响模块编译、契约检查；high_risk 覆盖核心失败路径）确认整体可交付。
-8. 全部 done 才 `dev_task`（operation=advance）；`todos_done` 门会硬校验：每个 done 的项都必须带两阶段审查留痕且都 pass，缺 `review_item` 留痕会被拒绝。失败保持 doing、只记最新结果与阻塞；需求或方案变化时回退确认并停止编码。

package/skills/code-review/SKILL.md

@@ -1,13 +0,0 @@
----
-name: code-review
-description: 代码审核节点：评审变更，产出结论与问题清单并落评审记录。仅在任务处于「代码审核」阶段时使用（以 dev_task status 的 stage 为准）。
----
-
-# 代码审核
-
-1. `dev_task`（operation=status）读当前变更与验证结果。
-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。

package/skills/code-verify/SKILL.md

@@ -1,20 +0,0 @@
----
-name: code-verify
-description: 交付验证节点：执行目标测试、编译与契约检查，记录验证结果与证据。仅在任务处于「交付」阶段时使用（以 dev_task status 的 stage 为准）。
----
-
-# 验证
-
-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 正式审批；审批不可用时报告失败路径和所需授权，等待处理，不把工具访问限制推断为服务不可达。
-
-`verify` / `skill_result` 的验证命令因沙箱受阻时，保持原命令，增加 `sandbox_permissions: "danger-full-access"` 和具体 `justification` 申请单次重试。批准发生在命令执行之前，只对本次调用生效；回执中的实际模式与退出码才是本次结果，不能引用之前 shell 调用通过的结果替代。保存完整测试输出后从已有日志提取用例，不为截取不同摘要重复跑已通过测试。
-
-验证失败不得 advance。
-
-测试报告应区分已执行但失败、依赖阻塞未执行、模拟接口与真实联调；每个验收点引用对应组件或接口的测试，按已有日志记录逐项结果和耗时，缺证据就注明。不得以报告行数或关键词出现替代内容审查。预计交付的测试文件和文档应尽早纳入 scope，完成修订后再登记最终回执，减少范围变化引起的重复验证。

package/skills/requirement-analysis/SKILL.md

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

package/skills/solution-design/SKILL.md

@@ -1,19 +0,0 @@
----
-name: solution-design
-description: 设计节点：产出最小方案、改动点与技术选择，落设计文档并等确认。仅在任务处于「设计」阶段时使用（以 dev_task status 的 stage 为准）。
----
-
-# 方案设计
-
-进入本节点时需求已确认、方案尚未确认。按顺序：
-
-1. `dev_task`（operation=status）读当前节点与待办。
-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）流转；系统发起「方案确认」审批，批准才放行。被驳回时先获取修改意见，修订并重提；不要把驳回默认解释为误操作，也不要自动重试。
-
-方案未获人批准不得进入实现。