@godv61/dsh-task-engine 0.29.3 → 0.30.0

package/docs/CHANGELOG.md

@@ -1,407 +0,0 @@
-# 更新日志
-
-[← 文档导航](README.md)
-
-按版本查阅功能变化。当前使用方式以[项目首页](../README.md)和使用指南为准；历史条目中的实现方式、限制与测试数量可能已被后续版本替代。
-
-## 0.29.3（2026-10-01）
-
-- “项目初始化”页明确区分项目 Skill/Rule 初始化与 `AGENTS.md` 生成，提供可复制的工程会话请求；“自适应流程”页增加直达入口。
-- 说明 Web 服务更新后旧页面可能失去交互，需要刷新页面；规则配置按钮在新页面可打开编辑窗口。
-
-## 0.29.2（2026-10-01）
-
-- “配置核心 Skill 的 Rule”现在可打开内置或用户级核心 Skill 的规则编辑器；保存时创建同名项目 Skill 并挂载 Rule，创建前不会修改项目文件。
-- 工作台移除“旧版流程”标签；既有任务快照和 `.dsh/eng.json` 继续可读。
-
-## 0.29.1（2026-09-30）
-
-- 修复 0.29.0 浏览器 Remote 清单漏掉四个自适应配置接口，导致“工程任务”工作台打开时报 `remote.readAdaptive is not a function` 的问题。
-- DSH 兼容检查现在比对 Host 暴露的方法与浏览器描述符，防止同类遗漏再次发布。
-
-## 0.29.0（2026-09-30）
-
-- 新任务可按低、中、高、超高复杂度选择任务级流程；内置六个元技能及交接契约，旧 `.dsh/eng.json` 与旧任务快照兼容。
-- 项目、Codex 项目、用户、内置同名 Skill 按该顺序解析；生效 Skill 自带 Rule 档案，`.dsh/meta.json` 挂载附加 Skill。
-- `init_project` 扫描项目结构与依赖清单，分预览与应用两步生成多个项目 Skill/Rule。
-- 可选 SonarQube 审核在代码审核阶段读取已提交代码的 CI 分析结果；失败案例经预览可成为项目 Rule，修复后需重新测试与扫描。当前不支持未提交代码的本地 Sonar 审核。
-- 工作台新增“自适应流程”，旧版流程保留为兼容入口；提交钩子按任务快照判断，代码审核阶段由任务工具检查已启用的 SonarQube 审核。
-
-## 0.28.0
-
-- 兼容 DSH `0.2.0-rc.2` 的依赖版本检查，插件可通过正常安装流程进入 Web profile，无需精确版本豁免。
-- 适配 DSH 0.2 的声明式 Agent 预设：以该版本的 `standard` 清单声明工程模式，替换工程人设并追加 `task-engine-agent`，不再依赖已经移除的 `@deepseek-ai/dsh-agent-presets` 目录。
-- 保留 DSH 0.1 的 `.agent-presets` 文件生成路径；同一发布包按宿主能力选择预设接入方式。
-
-## 0.27.1
-
-- 移除六个内置业务 Skill 和三个内置 Rule，仅保留会话编排 Skill `eng-delivery`；阶段技能和规则完全由使用者创建或安装。
-- 三个流程及其推荐配置均不再绑定业务资源。推荐配置只提供可修改的提交文本、产物字段和评审深度，采用时保留现有技能与规则绑定。
-- 移除依赖已删内置规则的全局指纹与技能名称特例；空绑定流程仍按阶段与门禁运行，用户资源继续按原引用实时读取。
-- 兼容 DSH 新旧版本的图标导出名称，修复新版客户端中“工程流程”侧栏入口渲染失败、工作台无法打开的问题。
-
-## 0.27.0
-
-- 采用推荐配置时将所引用的内置技能和规则各复制一份到项目目录，并改写为项目引用；共享规则仍只有一份，重复采用保留用户已编辑的项目文件。旧项目可单独迁移内置引用，打开或普通保存时不自动改写。
-- 用户级技能的规则配置移到用户目录，跨项目和会话共用；不允许用户级技能依赖项目级规则。任务保留创建时流程和资源引用，Skill/Rule 正文从下一次交互读取最新版本；创建时正文仅作为审计基线。缺失的源资源阻止继续流转。
-- 流程切换时清理不属于新流程的阶段绑定，修复残留阶段造成的校验报错。技能规则配置改为挤压主内容的侧栏，不再覆盖蒙版。修复浏览器与宿主间的配置编解码，保存时保留资源引用、规则档案、提交和产物设置。
-- 正文实时读取是有意的行为变更：任务创建前已经记录的验证或人工确认不会因之后修改 Skill/Rule 自动作废。`status` 会报告资源变更；变更约束后请重新核查相关证据。
-
-## 0.26.1
-
-- 将会话预设强制加载的 `eng-delivery` 收敛为纯流程编排：只按任务状态和冻结配置加载技能、遵守规则及检查证据，不再暗示固定阶段技能映射或所有技能都需要命令回执；同步修正预设人设和工具参数说明。
-- 内置业务技能与规则明确作为只读样本；工作台可从样本预填新资源，改名后保存到项目或个人目录，再单独配置完成凭证、规则和阶段绑定。复制与保存不会自动启用样本。
-- 修正内置实现技能对未绑定 `coding-conventions` 的强制引用，以及旧规则迁移提示中的配置位置。
-
-## 0.26.0
-
-- 修复旧内联阶段绑定与新 `skill_profiles` 同时存在时，技能档案规则未展开、同一技能跨节点误报冲突的问题；明确的技能档案现在覆盖旧内联副本，并在任务创建时冻结实际生效的规则。
-- 技能规则改为项目级 `skill_profiles`，节点在 `.dsh/eng.json` 中只保存 `skill_refs`。旧内联绑定继续读取；没有明确技能档案时，同一技能在不同节点的规则或证据冲突会明确报错，保存时转换为单一配置。
-- “技能”页可集中编辑技能规则和完成凭证。流程页只选择技能，并可查看当前节点的有效规则；修改同一技能的配置会同步其所有节点引用。
-- 任务快照以资源类型、来源、名称定位技能和规则，避免同名资源正文串用；任务创建时拒绝缺失的绑定资源，并在运行时披露冻结的技能与规则正文。
-- `complete` 检查终态技能、证据与缺失规则，完成后禁止继续修改任务（可通过 `revise` 返工）。`status` 增加完成状态和完成阻塞原因。
-- `manual` 技能证据通过宿主人工审批记录，不再强制执行 shell；`artifact` 证据要求该阶段有产物定义且必填字段完整。
-- `commit_required: false` 同时取消离开提交检查点的强制提交要求。返工会使受影响阶段的技能结果失效。
-- 增加配置保存读回、同名资源、人工审批、终态阻塞及返工证据回归测试。
-- 工作台改用更宽的自适应布局；流程页用双栏穿梭框绑定技能，技能卡片和已绑定技能都可打开右侧规则配置抽屉，窄屏自动改为纵向布局。
-
-## 0.25.0
-
-针对 2026-09-24 复评的改造。**这是一个破坏性版本**：预设不再自带任何技能、产物或提交格式，`SkillBinding` 新增 `evidence` 字段，敏捷流程的门禁语义与版本号都变了。核心是落实产品原则：**流程只控制状态，业务方法由用户配置，Rule 真正归属 Skill。**
-
-已有项目不会因此失效，但**行为会变**：预设不再提供内置技能，所以一个从未采用推荐配置的项目，其节点将没有绑定。升级后打开工作台点一次「采用推荐配置」即可获得与升级前等价的起点，此后完全由你控制——删除的不再补回，升级也不覆盖。已有任务按各自的冻结快照执行，不受影响。
-
-### 流程骨架与可选推荐配置（破坏性）
-
-预设此前把技能、提交规则和产物字段烘焙进解析结果，`mergeBindings` 又只做**追加**——于是内置技能无法移除，而用户给内置技能配自己的规则时，条目会因引用已存在被整个跳过，静默保留预设规则。工作台里选择流程也会一并写入这些内容，等于选择流程即接受内置工作方法。
-
-现在分成两层：
-
-- **骨架**只含阶段图、每条边的守卫，以及提交规则中属于**流程控制**的那一半：何时需要提交、哪个节点是检查点、是否强制文件范围。最后一项留在骨架上是有意的——高风险检查读它作为安全底线，不能因为用户没采用推荐配置就消失。
-- **推荐配置**（`FlowRecommendation`）单独存放技能绑定、提交**文本**约定、产物字段与审查深度。
-- `adoptRecommendation()` 只在用户显式请求时写入。这是一次性动作：此后这些值就是用户的普通配置，用户删除的值不会回来，升级也不覆盖。
-- `resolveFlow` 逐字采用项目配置。用户没配的节点就是没有绑定，这是合法状态，不是待补齐的空缺。
-- 工作台新增「采用推荐配置」按钮；**选择流程不再写入任何绑定**。
-
-### 冻结真正接入执行链
-
-此前 `flow.resources` 只**存档**正文，`status` 与阶段披露仍走 `readRuleAt` 读实时文件——改一条规则会无声改变进行中任务所遵循的内容，正是快照本该阻止的不稳定。现在解析优先使用冻结正文，并把漂移**报告**出来：源被改动记为 `stale_source_rules`（source edited），源被删除也记为漂移而非缺失——任务手里已有内容，说它缺失是错的。没有快照的旧任务继续读实时文件并把删除报为缺失，两条路径可区分，不会互相悄悄退化。
-
-### 缺失资源、节点结果与完成条件改为真正阻塞
-
-- **规则无法解析则不可推进**。`missing_rules` 以前只披露不阻塞，删掉绑定规则仍能推进——阶段在缺少既定约束的情况下走完，而记录看起来正常。判定实现为引擎里的纯函数，工具与 hook 从同样输入得到同样结论。
-- **完成检查流程声明的节点结果**。此前只查「是否站在终态、实施项是否完成、有无提交」，于是一个在进入终态的路上声明了 `review_passed` 的流程，只要**到达**就满足——审核被 blocked 仍能完成。要求由 `terminalRequirements` 从流程推导，没声明验证门禁的流程不会被强加。
-- 敏捷流程的审查要求需要另一种机制：`审查` 是终态且**就是**审查本身，没有出边可承载守卫。把 `review_passed` 挂到 `交付 → 审查` 会要求「在产生结论的阶段之前就有结论」，还会挡住 `交付` 的提交（提交要求其出边守卫全部满足）。改用 `completion_guards` 显式声明，这正是 `complete` 作为独立操作存在的原因。敏捷版本号升至 4。
-
-### 技能声明自己需要哪类证据
-
-每种非内置技能都必须记录「真实验收命令」，于是需求或设计类技能——产出是一份文档——被迫运行一条无关命令来满足门禁。证据本来就有，只是形态不同。技能绑定现在可声明 `evidence`：`command` / `artifact` / `review` / `manual` / `none`，引擎按各自形态检查对应记录。未声明时保持历史行为（命令回执），因此既有配置与冻结快照不受影响。
-
-### 保存完整配置 + 列表可用性
-
-- **保存不再只写 `flow` 与 `stage_bindings`**。提交规则、产物声明、审查深度与 `commit_required` 以前只用于预览，保存时被静默丢弃——面板显示一套配置、文件里是另一套。写入载荷与面板状态现在都覆盖全部字段。
-- **技能与规则列表在规模增长后可用**：加搜索（匹配名称、说明与来源层）、「仅看已选」筛选，展开的规则列表改为**有界滚动区**。一条规则贯穿全部筛选：**已绑定或预设自带的条目任何查询下都保持可见**——面板展示的是配置本身，筛选藏起正在生效的资源会让面板与它显示的配置不一致，那比列表长更糟。
-
-## 0.24.0
-
-针对 2026-09-23 外部深度评测的改造。**这是一个破坏性版本**：配置里的 `stage_bindings[*].rules` 不再作为节点级规则读取，`skills` 的格式也从字符串数组改为带来源的对象。已有配置会继续工作——旧的节点级规则以 `legacy_rules` 保留并**仍然生效**——但它们的归属需要你确认一次，见下面「规则改为只挂在技能下」。
-
-每个问题都先以独立复现确认存在，再修，并做正反两面验证。四个批次按实施顺序列在下面。
-
-### 返工、资源冻结与预设重新定位（第三批·续）
-
-- **新增 `revise` 操作：受控返工**。流程图只有正向边，但工作不是——需求会在实现开始后变化，缺陷会在审核时发现。此前唯一的回头方式是手改记录，而那会让每一条下游结论**名义上依然成立**：确认、验证回执、审核结论都描述着一棵已被取代的代码树，却仍读作"通过"。
-  - **失效范围按声明的类型推导，不是一刀切**：`requirement` 清掉需求确认及其全部下游；`solution` 保留需求确认，清掉方案确认与实现相关证据；`defect` 保留需求与方案确认，只清掉"旧实现是正确的"这一批证据。**每次返工都清空一切会更简单，也会丢掉仍然成立的结论**，让工作无谓重做。
-  - 被清掉审核的实施项**退回未完成状态**——留着 `done` 会让 `todos_done` 在审核刚被作废的工作上通过。
-  - 返工历史记入 `revisions`，含类型、原因、从哪个阶段回到哪个阶段、以及本次失效了哪些结论。
-- **任务创建时冻结技能与规则正文**。名字无法让进行中的任务保持稳定：改一条正在使用的规则会**无声改变该任务正在做的事**，删掉它则让一条已配置的约束凭空消失。现在每个解析到的正文都连同一个内容 hash 存入 `flow.resources`，**同一正文按 hash 只存一份**（`security-redlines` 被两个技能引用，正文不重复）。读不到正文的资源会被报为 `unreadable`，而不是假装冻结成功。
-- **预设重新定位为三种任务复杂度**，而不是三种安全底线。名称与描述改为面向任务的表述：**完整研发**（新功能、架构或跨模块改动、高风险）、**日常迭代**（目标明确的常规功能与缺陷修复）、**快速修改**（局部、低风险、方案明确的改动）。三者都以同一个 `completed` 生命周期收尾。
-- **修复 UI 的两个编辑丢失问题**：点击**当前已选中**的流程卡片会重新用预设默认值覆盖绑定——一次误点就会丢掉全部自定义；现在点击当前项无操作。有未保存修改时切换流程会**先确认**，因为绑定是整体替换、编辑无法恢复。保存按钮在有未保存修改时才可点，并显示状态。
-
-### 规则改为只挂在技能下（第三批，破坏性）
-
-**规则改为只挂在技能下。** 此前 `StageBinding` 是 `{ skills: string[], rules: string[] }` 两个平级数组，于是「这个技能在什么规则下运行」这个问题，必须先把预设默认、项目追加、优先级解析全部算一遍才能回答——而且答案会随阶段变化。现在：
-
-```text
-流程 → 节点 → 技能 → 规则
-```
-
-- `StageBinding` 只保留 `skills`，每项是 `SkillBinding { skill: ResourceRef, rules: ResourceRef[] }`。**节点不再有规则列表，也不提供追加、禁用或覆盖**；打开一个技能看到的就是它完整的规则列表，挂到任何节点都是同一套。
-- 同一技能需要不同规则时**复制成另一个独立技能**，不建立隐式继承。测试里有一条断言专门锁住这一点：同一个技能引用在任何流程的任何节点都必须携带完全相同的规则集合。
-- **资源引用带来源**（`bundled:` / `project:` / `user:`）。裸名字无法区分「项目里的 coding-conventions」和「用户目录里的 coding-conventions」——过去二者只能靠优先级隐式决定，现在引用本身说明去哪一层找，解析不再走优先级遍历。
-- **规则可被多个技能引用**，正文不复制。`security-redlines` 同时被 `code-implement` 与 `code-review` 引用，就是这种共享（有断言覆盖）。同一阶段的重复引用会去重披露。
-- **内置规则的归属按正文内容逐条审查，不按文件名机械搬迁**：`coding-conventions` 给 `code-implement`（写时遵循）与 `code-review`（审的就是这些）；`commit-conventions` 只给 `code-commit`；`security-redlines` 给 `code-implement`、`code-review` 与 `requirement-analysis`——它的「服务端校验才是边界，前端校验不是」在需求阶段就要定。
-- **旧配置的节点级规则不丢弃、不猜归属**。`legacy_rules` 保留原名，**仍然生效**，同时 `status.unassigned_legacy_rules` 列出它们等待归属；阶段披露文本也会说明这是待分配规则。`validateWorkflow` 会报出未分配的旧规则，让这个迁移状态保持可见而不是沉淀成两套并存的模型。
-- `status` 新增 `unassigned_legacy_rules`，`rules[]` 现在带 `source`；`skill_obligations` 与 `skill_result` 按技能名比较（DSH 的 skill 工具按名寻址），来源只决定解析到哪一层。
-
-**界面**：节点页只列技能；勾选技能后展开「规则设置」，在**技能**上增删规则。旧的平级「技能 / 规则」双选择器（`BindingPicker`）已删除——它表达的正是被取消的双层模型。技能卡片区分预设绑定（锁定）与项目追加，并显示该技能当前携带几条规则。
-
-**关于测试**：`.p0-test.mjs` 与 `.workflow-test.mjs` 里各有一条断言依赖旧的节点级规则语义（「清空节点规则仍保留核心规则」「技能以字符串数组绑定」），已改为按新模型断言——不变量没有变（核心能力不可被覆盖取消），变的只是它落在技能上。新增 4 条第三批断言。
-
-### 显式完成与可配置的审查深度（第二批）
-
-- **完成成为显式动作，不再由「站在最后一个阶段」推定**。`minimal` 的终态恰好又是它的提交检查点，而「离开检查点前必须提交」这条规则只在**离开**阶段时触发——终态没有出口，于是该流程能在 `commits` 为空时抵达终点，**没有任何交付记录**。新增 `complete` 操作与 `TaskCompletion` 记录：三个预设统一以同一生命周期收尾，`completionBlockers()` 在完成时检查「是否处于终态」「`todos_done` 条件是否满足」「交付方式是否要求提交」。
-- **是否必须提交改为流程的交付方式**。`commit_required`（缺省 `true`，保持既有行为）允许非代码任务或非 Git 项目完成而不需要提交——Git 提交是一种交付方式，不是通用终点。
-- **每项审查深度改为流程属性**。`review_depth`（`two-stage` / `single`，缺省 `two-stage` 保持既有行为）。此前 `todosBlockers` 被三个预设共用且硬编码要求 `spec` 与 `quality` **两个**结论，因此 `minimal` 虽只有两个阶段，逐项审查负担与完整流程完全相同——实测三者对同一状态返回**逐字节相同**的阻塞列表。现有 `minimal` 声明 `single`：**轻量是减少重复判定，不是跳过检查**——未审核的项、未通过的结论仍然阻塞。
-- **`review` 结构改为防御性读取**。`todosBlockers` 原先假设 `quality` 必然存在；加载轻量深度或较早快照写下的记录时会崩溃，而不是报告问题。
-- **未知的 `review_depth` 是配置错误**，不会静默退回最严档位把拼写错误藏在更严行为背后。`validateWorkflow` 会报出它。
-- `minimal` 版本升到 2；`standard` / `agile` 的 v1 快照继续按原语义读取。
-
-**关于测试**：第一批里那条针对 `minimal` 的断言是**空过的**——它检查 `status.skill_blockers`/`commit_blockers`，而 `todosBlockers` 的输出从不进入这两个字段，所以断言的失败分支不可达，对着完全未修复的引擎也能通过。现已改为**直接调用被测函数**，并加了一条「三个预设的审查负担不得完全相同」的断言。反向验证：临时移除 `review_depth` 声明，两条测试立即失败。
-
-### 门禁一致性修复（第一批）
-
-针对 2026-09-23 外部深度评测的第一批修复。全部问题先用独立复现确认存在（`.assessment-batch1.mjs`，8 项），再修，且每条都有正反两面验证。
-
-- **验证失败不再能取得提交许可**。标准流程的 `交付 → 代码审核` 要求 `verified`，而 `代码审核 → 完成` 只要求 `review_passed`；`evidenceBlockers` 又把陈旧检查挂在 `verification.passed` 为真之下，于是**重新验证失败反而让检查彻底消失**——失败比从不验证更宽松。现在 `verified` 作为流程级约束计算：`verificationHeldStages()` 从所有 `verified` 边**向前闭包**推导出「该要求仍在生效的阶段集合」，使要求只在跨过验证门之后适用（任务在需求阶段尚无物可验，不应被阻塞），跨过之后则一直适用。提交与完成共用该判断。
-- **敏捷流程的提交标签契约统一**。检查点阶段返回标签 `TASK`，而该预设的消息正则只接受 `T\d+`，导致引擎交给模型的状态行与校验器对同一份契约互相矛盾。正则改为同时接受 `TASK` 与 `T\d+`，覆盖 `item` 策略实际产生的两种标签形状（实施项提交与收尾提交）。
-- **敏捷流程补齐 `review` 产物**。该预设的 `审查` 阶段绑定 `code-review`，而该技能指示模型 `record artifact=review`；预设却只声明了 `requirement`，于是被绑定技能的指令被引擎拒绝——预设自己制造了一个不可能满足的契约。现声明 `审查` 阶段的 `review` 产物。
-- **缺失规则不再静默跳过**。`resolveRules` 在 bundled/project/user 三处都找不到时只是不加入结果，调用方无从察觉——被删除的规则文件与从未绑定的规则无法区分。现在解析结果区分 `resolved`/`missing`，并记录每条规则的**来源层**（内置规则按设计优先于同名项目/用户文件，不记录来源就无法判断哪一份在生效）。`status` 新增 `missing_rules` 与 `rules[]`（含来源），阶段披露文本也会明确列出找不到的绑定。
-- **敏捷版本号提升到 2**。上一项改变了预设的产物契约与消息契约，因此按版本区分：新任务采用 v2，既有任务继续读取各自冻结的 v1 快照。
-
-**关于既有测试**：`.workflow-test.mjs` 中一项用例从 `代码审核` 阶段起步却未给出验证状态，此前正是靠上述缺陷（`passed` 为假时陈旧检查不触发）才得以看到它真正要测的技能门禁。已为该项补上验证状态——被测意图不变（未执行的附加技能不得冒充完成），只是不再依赖缺陷的副作用。
-
-## 0.23.9
-
-- **工作台的阶段绑定改为可搜索的选择器**。此前技能和规则各是一串可点击的胶囊标签：没有搜索、没有筛选、没有计数，列表也没有滚动容器，资源一多就把页面撑得很长。现在每类资源各有一个选择器：
-  - 技能与规则**各自独立搜索**，另有「仅看已选」筛选。
-  - 显示**已选/总数**、每项的资源来源，空态区分「尚未安装」和「没有匹配项」。
-  - 列表在 280px 内**就地滚动**，不再随目录增长而拉伸页面。
-  - **预设默认绑定保持勾选且不可取消**，与引擎的追加式覆盖语义一致——界面不会表达一个引擎会忽略的移除。
-  - 目录中找不到的绑定**仍然可见**并标注为未找到；目录加载失败不能静默隐藏已有选择。
-  - 切换阶段时**重置筛选但不改动绑定**。
-- 顺带删除重复的只读流程节点列表和每个预设的说明文字——选择器已经展示了这些信息。
-- **修复客户端 source map 内联源码**。`lib/client.js.map` 此前带有 `sourcesContent`，把整棵 `src/client` 源码原样以 `lib/` 名义打进包里（447 KB）；基于路径的「tarball excludes src sources」检查因此形同虚设。改为只保留行映射后为 148 KB，并补上**按内容而非按文件名**断言的检查，防止退回。
-- **修复 10 处 UTF-8 字节损坏**。四处文件里出现了「被截断的 UTF-8 首字节 + `?`」的序列——工具链某处把无法编码的字符替换掉了而没有报错，因此评审从未看到。最严重的一处在**预设名内部**：`工程化开发引擎` 的「擎」是 `E6 93 3F` 而非 `E6 93 8D`，而这正是预设选择器渲染的文字。其余为破折号和一个箭头。全部修复后，仓库现以严格的 UTF-8 解码器验证通过——此前用容错解码读取，正是它掩盖了这个问题。
-
-## 0.23.8
-
-- **更正文档中与代码不符的陈述**，不改动任何运行时行为：
-  - 可视化自定义流程在五个位置（`roadmap.md`、`faq.md`、`configuration.md`、项目首页、HTML 手册）被描述为“规划中/尚未发布”，但它**不在计划内**——它把流程设计的负担转嫁给使用者，而三个内置流程已覆盖个人项目的常见需要；`main` 上不存在该能力的实现。现改为明确说明不实现的理由。
-  - `development.md` 曾称“已存在的 eng 预设不会被自动覆盖”。该行为自 0.23.6 起已改变：预设**每次启动都从运行中 harness 的 `standard` 重新派生**，判断依据是文件里有没有本插件的 agent 行——插件生成的会被更新，手工编辑过的原样保留。`enable` 脚本仍直接拒绝覆盖，这是旧表述显得合理的原因。
-  - `getting-started.md` 的安装命令写死 `@0.23.0`（落后七个版本），改为安装 `latest` 并说明如何主动固定版本。
-  - 描述**当前**行为的 FAQ 条目以引入版本号开头（如“0.23.1 …”），读起来像历史而非当前行为，已去掉版本前缀。
-  - `roadmap.md` 的“当前 npm 版本为 0.23.0”与 `manual.html` 页脚的“0.23.2-rc.1”改为指向更新日志。
-- 文档目录重组：发布说明移入 `docs/releases/`，文档索引拆为“开始使用 / 参与开发 / 历史记录”三段。**没有删除任何文件**——旧的发布说明与测试报告是被更新日志引用的逐版本快照，且带有各自的范围声明（例如 0.23.1 报告写明“不等同业务项目端到端验收”），保留它们才能追溯当时的验证边界。
-- 更正 0.23.7 条目的一处描述错误：文中说旧格式产出 `text: |-`，实际**沿用源预设的 `>-`（折叠标量）**。所有随包发布的 `standard` 都使用 `>-`，而 0.23.7 的实现是照写源的标量风格——`>-` 会把正文内的单个换行折叠为空格，与 `|-` 语义不同，因此这条描述当时会误导读者。
-
-> 本版仅文档变更，`src/`、`package.json` 与测试均未改动；功能行为与 0.23.7 完全一致。
-
-## 0.23.7
-
-- **修复 persona 字段在旧版 DSH 上不兼容**。`@deepseek-ai/dsh-persona` 在提交 `40792330c0`（2026-09-06，首次随 `dsh-v0.1.3-alpha.2` 发布）把配置字段从 `text` 改名为 `prefix`/`suffix`，两个 schema 互斥：写 `prefix` 的预设会被旧版 persona 插件以 `$.text missing required value` 整份拒绝，反之亦然。0.23.6 的派生逻辑**硬编码了 `prefix`**，因此在 `dsh-v0.1.3-alpha.1` 及更早的 harness 上，`eng` 预设挂载失败、新会话无法创建。现在改为**读取源预设自己使用的字段**再照写——`standard` 就是运行中 harness 的格式权威。已用两个版本的真实 `standard` 验证：`v0.1.3-alpha.1` 产出 `text: |-`，`v0.1.6-alpha.2` 产出 `suffix` + `prefix: |-`，两者 YAML 均解析通过。
-- 顺带修复派生时的缩进：`suffix:` 此前被写到错误的层级，使新格式的 persona 段落 YAML 结构改变。新格式下同时保留源预设的 `suffix`（它声明工作目录），旧格式则不引入该字段。
-- peer 范围补上 `|| ^0.1.7-alpha.1`。DSH `0.1.7-alpha.1` 修复了 0.1.6 中导致所有工具调用失败的问题（`ctx.tools[TOOL_RUNTIME_SCHEDULER]` 为 `undefined`，社区在讨论 #7035 / #7194 报告，官方确认修复）；peer 范围需要跟着覆盖该版本。
-- `.preset-test.mjs` 增至 9 项：新增两组 persona fixture，分别断言 `text` 与 `prefix` 两种 schema 下的字段选择、`suffix` 保留与缩进正确性。已反向验证：把字段选择改回硬编码 `prefix`，两项断言立即失败。
-
-## 0.23.6
-
-- **修复「工程化开发引擎」预设加载失败**。`seed-preset.ts` 用 `@deepseek-ai/dsh-agent-presets` 导出的 `SHIPPED_PRESET_ROOT` 常量定位源预设，而该常量是 `fileURLToPath(new URL('../presets/', import.meta.url))`——它锁在**插件自己依赖树**里的那份包上，可能和**正在运行的** DSH 不同版本。于是派生出的预设携带运行中 harness 早已替换掉的行：DSH 2026-09-13 把 `workflow-worker-thread` 换成了 `workflow-ptc`，而该包同时退出了 `apps/cli` 的依赖，预设因此报 `row "workflow-worker-thread" names a plugin that cannot be resolved`，整个预设显示「加载失败」，任何新会话都无法启用任务流程。现在改为在**调用时**用 `createRequire` 从插件自身位置解析，跟随宿主的安装图。
-- **预设改为每次启动重新派生**，而非"存在即跳过"。此前一次性复制把预设冻结成首次运行时的快照，DSH 每次修改 `standard` 都会让它失配；persona 格式也经历过 `text:` → `prefix`/`suffix` 的迁移，旧副本因此被 persona 插件的 schema 拒绝。现在检测到是本插件生成的预设才更新，**手工编辑过的预设绝不被覆盖**。
-- persona 行改为**整块重写 `config:`**，不再匹配某一种历史措辞，因此对 schema 的后续演进免疫。同时**不再设置 `complete: true`**——那会让这段 prefix 成为整个系统提示词并抑制其余所有 section。
-- 新增 `.preset-test.mjs`（7 项），断言 persona 已替换、使用当前 `prefix` 形式、不含 `complete`、agent 行只出现一次、`standard` 的所有顶层行都被继承、以及重复派生结果稳定。已反向验证：把 `complete: true` 加回去该测试即失败。`npm test` 从 43 项增至 50 项。
-
-## 0.23.5
-
-- **修复 `scripts/` 未随包发布，导致两条已声明的 npm script 在安装后无法执行**。`package.json` 声明了 `verify:package` 与 `verify:dsh`，但 `files` 白名单不含 `scripts/**`，用户装包后运行它们会直接 `MODULE_NOT_FOUND`。该问题早于 0.23.3 存在（`verify:package` 一直如此），0.23.4 新增的 `verify:dsh` 只是沿用了同一模式。现在把 `scripts/**` 纳入白名单，并在 `verify:package` 中加断言：包内必须能找到每一条 `package.json` 里声明的 `node <file>` script 目标。
-
-## 0.23.4
-
-- **关闭两处 Remote 路径边界漏洞**。`checkedPath` 此前用**原始字符串**比对禁止前缀，`D:/proj/../../Windows` 不匹配任何前缀，却被后续 `join()` 解析到 `C:/Windows`；实测 8 个越界样本中旧实现放过 7 个。现在先 `resolve()` 归一化再判断，禁止列表不再绑定盘符（`D:/Windows`、`E:/Program Files` 同样拒绝），并拒绝裸盘符根（`D:/`、`C:/`）。
-- `writeInit` 不再写到工作区之外。`locateInitRoot` 的祖先回溯可能定位到工作区上一级：**读取**该文件是有意的（那才是真正拥有 `AGENTS.md` 的项目），但**写入**不是本工作区的事。现在越界写入直接拒绝并提示改选工作区，与 `dev_task init apply` 的 `assertInsideRoot` 一致；祖先回溯同时加上 8 层上限。新增 `isInside` 按**路径段**而非字符串前缀比较，`D:/a/bc` 不会被误判为在 `D:/a/b` 内。
-- **新增 DSH 契约兼容性检查**（`scripts/verify-dsh-compat.mjs`，`npm run verify:dsh`）。它读取真实 DSH 检出里 typert 协议的类型声明，判断当前契约是 `schema` 还是 `create()`，再断言产物满足它、且 peer 范围确实覆盖该版本。这正是 0.23.3 修复的那类问题——单元测试看不到，因为测试从不通过真实注册表加载 descriptor。CI 新增 `dsh-contract` 作业：对固定基线 `dsh-v0.1.6-alpha.2` 失败即红，对 `master` 仅告警（`continue-on-error`），因此破坏性变更会在发布前暴露。已反向验证：把 peer 范围改回旧值，该检查会失败。
-- **新增提交钩子端到端测试**（`.hook-test.mjs`，6 项）。此前的 P0 断言只检查钩子**源码**的字符串（关闭路径转义、NUL 分隔、捆绑冻结快照），能防手抄回潮，但**无法证明门禁真的拦住了提交**——一个全部拒绝或全部放行的钩子都能通过。新测试在临时 git 仓库里真实执行 `git commit`，双向断言：合法提交放行，消息格式错误、范围外文件、未到检查点、快照被篡改、敏感路径无高风险回执五类均被拒绝且给出对应理由。
-- P0 断言从 126 增至 146；`npm test` 现包含钩子端到端用例（37 → 43 项）。
-
-## 0.23.3
-
-- **适配 DSH 0.1.6-alpha.2 的 typert strict codec 契约变更**。该版本把 codec 从直接携带 `schema` 改为惰性工厂 `create: () => TypertSchema`，并在注册时硬校验 `typeof codec.create === 'function'`；旧写法会在插件加载阶段抛 `strict codec has no create() factory`，整份 Remote 贡献被拒绝。`src/client/remote.ts` 的 36 个 strict codec 现在**同时携带 `create` 与 `schema`**，因此同一份产物在 0.1.2-rc.1（桌面版）与 0.1.6-alpha.2（源码版）上都能加载。两处内联的 `z.object({...})` 提为具名常量，与文件既有风格一致。
-- peer 范围补上 `|| ^0.1.6-alpha.2`。此前声明未覆盖该版本，pnpm 只在安装时警告、运行时不拦，导致问题在启动时才暴露。
-- 注意：npm 的 semver 不匹配未被范围显式点名的预发布版本，因此后续每个新的 DSH alpha 都需要在此处追加，否则会重新出现同类加载失败。
-
-## 0.23.2
-
-- 修复 verify / skill_result 先执行命令后审批、批准权限未传入 shell 的问题；拒绝、取消或审批不可用时不执行命令。
-- 审批显示实际验证命令；批准模式只用于本次命令和回执写入，不改变会话策略，也不重复申请保存回执的审批。
-- 修正提交规则与手册中的模块名示例，第一段使用当前任务 id，第二段使用 status 的 commit.label；自定义格式以任务冻结流程为准。
-- dshtest 首轮在 0.23.1 复现权限问题；修复后连续两轮完整开发、验证、审核、本地提交及归档回退通过。专项覆盖审批拒绝、原命令批准执行、证据过期和单次权限恢复，详见[发布说明](releases/0.23.2.md)与[测试报告](testing/0.23.2/测试报告.md)。
-
-## 0.23.1
-
-- 汇总本轮候选版的资源来源、Windows 技能加载、实施审核保留、派工状态、真实技能/验证/提交回执及状态一致性修复。
-- 新增 status.artifact_requirements，提前披露当前阶段的记录字段和缺项；未知字段拒绝时给出恢复指引，整次写入保持不变。
-- 需求技能按预设实际字段记录，修正敏捷流程误用标准字段的问题；小修正、权限恢复、契约核对和测试证据说明同步更新。
-- 旧任务保留冻结流程，新任务使用标准 v2 和执行证据门禁。实际能力及未覆盖边界见[发布说明](releases/0.23.1.md)与[测试说明](testing/0.23.1/测试报告.md)。
-
-以下 rc 条目为本轮迭代历史，已汇总至 0.23.1；“尚未发布”描述的是当时状态。
-
-## 0.23.1-rc.5（本地回归候选，尚未发布）
-
-- 修复状态查询显示允许提交、实际却因技能未执行或回执过期而拒绝的不一致。status 新增 evidence_blockers，commit.allowed 纳入同一技能与文件摘要检查；不改写历史验证回执。
-- 回归覆盖缺失技能、两种回执同时过期、只刷新验证、全部刷新后恢复，以及只读状态查询不修改台账。
-- 测试说明区分已执行但失败、依赖阻塞未执行和模拟验证，要求测试对象与证据对应；不以报告行数证明质量。
-
-## 0.23.1-rc.4（本地回归候选，尚未发布）
-
-- 小修正允许主代理实施，保留两阶段审核与必要验证，不强制重新派子代理和无关编译。
-- 子任务指引要求沙箱拒绝后走正式审批或报告阻塞，禁止反复换等价命令、改 ACL 规避。
-- 这些是执行指引改进，不替代 Harness 沙箱或子代理控制能力；实际回归仍在进行。
-
-## 0.23.1-rc.3（本地回归候选，尚未发布）
-
-- 状态明确列出需要命令回执的附加技能；内置技能不重复要求 skill_result，可选的内置回执过期不会额外阻塞流程。
-- 派工前登记 dispatch，自动标记实施项进行中；重派清除旧审核，禁止同时派发另一进行中项。登记表示派工意图，实际执行以工具日志为准。
-- 已有实施项更新可省略标题，保留原文和审核；已审核项改标题且仍标完成时立即拒绝，避免追加修复项造成审核静默丢失。
-- 方案要求核对真实接口字段及组件行为；审批驳回后先获取反馈、修订方案，再重新申请。
-- 验证和审核指引补充异步时序、组件交互及上游异常响应检查；编译和源码匹配不能代替行为测试。
-- 已安装并在原 EAMDEV-R2 任务实机验证：省略标题保留审核、派工先设进行中、重派撤销旧审核。完整终态闭环仍在验证。
-
-## 0.23.1-rc.2（本地回归候选，尚未发布）
-
-- 修复同名项目/个人资源覆盖导致来源误标。
-- 第二轮实机发现并修复 Windows CRLF / BOM 导致内置技能注册、技能列表与正文读取失败；安装包检查覆盖七个内置技能注册。
-- status 支持不带 task_id 发现工作区任务；更新实施项状态保留已有审核记录。
-- 验证命令继承调用会话的沙箱策略及取消信号，返回真实失败与沙箱信息。
-- 标准流程 v2 将提交放在审核之后；新任务完成前检查真实提交回执。
-- 新任务检查技能加载记录，附加技能要求执行证据；终态技能提前执行。
-- 验证回执关联声明文件内容，文件或范围变化后须重验。旧任务不强制迁移。
-
-真实 EAM 项目重跑尚未完成，不能据自动化测试宣告实机闭环通过。
-
-## 0.23.0
-
-- 技能选择系统文件夹，规则选择 Markdown 文件，预览后确认安装。
-- 统一资源卡片、搜索筛选、加载反馈、删除确认和窄屏布局。
-- 增加任务台账搜索、风险/阶段筛选与验证审核摘要。
-- 加强导入校验与失败清理，修复任务并发写入的版本读取次序。
-- 优先使用 Harness 已注册的工作区，补充发布包行为测试和 Node 22/24 CI。
-
-[完整发布说明](releases/0.23.0.md) · [测试报告](testing/0.23.0/测试报告.md)
-
-## 早期版本
-
-以下保留原项目的版本记录，供追溯变化；历史验证描述不代表对当前版本的额外测试承诺。
-
-### 0.22.7
-
-**skill 目录选择器 + 包形态（0.22.7）**：① 安装表单新增「浏览…」——host 端 `listDirs` 逐级列举目录（Windows 盘符快捷 + 路径输入回车跳转 + ↑ 上级 + **可点击面包屑**标明当前位置），含 `SKILL.md` 的子目录标「含 SKILL.md ✓」，当前目录能否直接安装实时提示，点「选此目录」回填路径，彻底不用手输；② 安装上限放宽到 1000 文件 / 100 MB（单文件 20 MB 上限），skill 作为<b>完整包</b>安装（references / scripts / 模板 / 资源等全部保留，仍自动排除 node_modules / `.git` / `__pycache__` 缓存）；③ 实机验证<b>项目级</b>（工作区 `.dsh/skills`）与<b>用户级</b>（`$DSH_HOME/skills`）两条安装路径均完整落盘，逐级进入与面包屑经浏览器实测确认。
-
-### 0.22.6
-
-**文案与安装体验（0.22.6）**：「安装 skill」输入框 placeholder 去掉示例绝对路径，改为通用提示「本机 skill 目录，需含 SKILL.md」；`installSkill` 支持<b>容器目录自动定位</b>——填的目录自身没有 SKILL.md 但直接子目录里恰好有一个含 SKILL.md 的 skill 根时自动装入该子目录（多个候选则提示直接填 skill 根）。
-
-### 0.22.5
-
-**目录型 skill 安装（0.22.5）**：工作台「技能」页新增「安装 skill」——把本机已有的目录型 skill（`SKILL.md` + references / scripts / agents 等文件）一键装到<b>项目级</b>（工作区 `.dsh/skills`，团队共享）或<b>用户级</b>（`$DSH_HOME/skills`，个人所有项目可用）；安装校验 SKILL.md frontmatter、拒绝覆盖内置同名、拒绝覆盖已装同名、自动排除 node_modules / .git / `__pycache__` 等缓存目录并限制 200 文件 / 20 MB；实机验证 `software-testing` 目录型 skill 从 UI 安装完整落盘（含 references + scripts）。
-
-### 0.22.3
-
-**可信边界加固（0.22.3，采纳 GPT 评审）**：① 验证命令统一在任务记录的项目根运行（monorepo 子目录不再跑错目录），receipt.root 与任务根强校验；② 旧任务（无 frozen 快照）禁止升 `high_risk`——迁移或重建后才可；③ `init apply` 强制 `expected_hash`，新增 `existing_hash` 防审批期间文件被换（TOCTOU）；④ 任务记录新增 `revision`，每次写入 compare-and-swap，并发覆盖直接报错（`changed concurrently`）；⑤ 工作台 Remote 增加 host workspace registry（`registerWorkspace` 供 harness 集成，注册后未授权路径一律拒绝）；⑥ sandbox 升级审批展示 workspace；⑦ 文档明确 hook（本地反馈）/ host（工具流约束）/ CI（最终可信门禁）三层职责边界。
-
-### 0.22.2
-
-**质量修补（0.22.2，采纳 codex 评审五项）**：① client typecheck 修复——`project.ts` 不再依赖 `node:path`，浏览器面可完整类型检查；② sandbox 升级补审批——`sandbox_permissions` 必须与 `justification` 成对出现，`danger-full-access` 需人工一次批准，无审批服务即拒绝；③ Remote 任意路径设防——工作台 Remote 拒绝非绝对路径与系统级根目录；④ `set_risk` 升到 `high_risk` 时受流程能力门约束（`minimal`/`agile` 拒绝，不再绕过 `create` 的检查）；⑤ `loadTask` 补齐旧记录缺失字段（items / verification / review / commits），损坏记录 fail-closed 而非引擎裸崩。
-
-### 0.22.1
-
-**沙箱写入修复（0.22.1）**：`dev_task` 的文件写入此前没有携带按调用传递的沙箱策略（`writeText` 的 `sandboxPolicy` 参数），在 DSH 文件沙箱下会把 workspace 内的任务记录写入误判为越界而拒绝（`file access denied under workspace-write mode`，且会话策略变化无法影响它）；现在每次写入显式携带 `{ mode, workspaceRoot: 会话目录 }`，并新增 `sandbox_permissions` 参数（`workspace-write` / `danger-full-access`）作为被拒后的一次性升级路径。
-
-### 0.22.0
-
-**审计和发布质量（0.22.0）**：① 流程快照 hash——任务创建时固化 `config` 的 SHA-256，工具与提交钩子读任务记录时校验，被手改的快照一律拒绝继续；② 提交钩子完整性检测——新增 `dev_task verify_hook`，比对 `.git/hooks/commit-msg` 与内置门禁的 hash，被替换/篡改立即报错；③ 风险降级审批——新增 `set_risk`，`high_risk → standard` 必须人工批准并落 `risk_downgrades` 审计记录；④ 验证回执绑定项目根——receipt 记录 `root`，与任务 workspace 绑定；⑤ 内置规则指纹锁定——创建时固化内置规则内容指纹，包升级后 `status` 报 `bindings_drift` 而非静默换规则；⑥ 多项目 / 多语言 / 多任务测试矩阵补强。
-
-### 0.21.0
-
-**通用项目适配（0.21.0）**：① 新增项目适配层 `src/project.ts`——按特征文件识别 Node / Java / Python / Go / Rust 类型，从 workspace 向上发现项目根（`.git` / `.dsh` / 语言特征文件）；② 各语言默认验证命令（`npm test` / `mvn -q test` / `python -m pytest` / `go test ./...` / `cargo test`），`verify` 不带 `command` 时按 `.dsh/eng.json` 的 `verify_command` → 语言默认链自动跑真实命令；③ 治理文件识别扩展至 `AGENTS.md`、`CLAUDE.md`、`.cursorrules`，`init inspect` 一并报告治理文件、项目根、语言栈与项目级 skill/rule 目录（约定 `.dsh/rules/*.md`、`.dsh/skills/<name>/SKILL.md`）；④ 提交钩子加风险策略——触及敏感路径（`.git` / `.env` / credentials / secrets；`.dsh` 的任务记录与流程配置由快照 hash 与豁免保护）要求任务为 `high_risk` 且验证有真实命令回执，否则拒绝；⑤ 初始化写入越界保护——`init` / `create` 的写入目标必须落在项目根内；任务记录新增 `root` / `project_type` 字段。
-
-### 0.20.0
-
-**安全闭环（0.20.0）**：① 验证改真实命令回执——`dev_task verify` 新增 `command` 入参，引擎通过宿主 shell 服务真实运行该命令并落 `VerificationReceipt`（命令 / 退出码 / 超时 / 中止 / 起止时间 / stdout / stderr）；`high_risk` 任务的 `verified` 门改为要求回执 `exit_code === 0` 且非超时 / 中止，纯文本 `passed` 声明不再放行（常规风险仍可用 `passed` + `evidence` 文本）；② 文件范围检查补 `T` + 改用 `--name-status`——`--diff-filter=ACMRDT` 纳入类型变换，提交状态随范围拒绝一并报出，删除 / 类型变换 / 重命名的旧·新路径都受范围检查；③ 提交钩子改为从 `engine.ts` / `workflows.ts` 单一源打包生成（`build-hook.mjs`），彻底消除手写镜像漂移，未知流程在钩子侧同样 fail-closed（不再静默回退 `standard`）。
-
-### 0.19.2
-
-**审计修复（0.19.2）**：补齐七项——① 提交钩子 `stagedFiles` 用 `core.quotePath=false` + `-z` 按 NUL 拆分（中文文件名不再被八进制转义误拒）并补 `D`（删除范围外文件也被拦）；② 提交消息第一段改为 task id、钩子按 id 精确定位任务（不再按分支/mtime 猜，同分支多任务不再锁错）；③ artifact id 全流程唯一 + `record` 校验产物属于当前阶段（堵越阶段复用）；④ 高风险验证证据 `trim()` 后须非空（`evidence:[""]` 不再通过）；⑤ README/手册加「诚实边界」，明说验证/评审/实施项是模型自报、需人工或 CI 兜底；⑥ 文档修正优先级（内置 &gt; 用户 &gt; 项目、内置不可覆盖）与 enable 措辞，`.dsh/task-*.json`/`eng.json` 豁免文件范围门；⑦ 提交钩子改用任务快照的 frozen 配置校验（对抗任务执行中改流程导致的配置漂移）；⑧ 工作台 `writeInit` 对齐 `init` 保护（已有 `AGENTS.md` 时需显式 overwrite + 前端确认才覆盖）；⑨ `.p0-test.mjs` 纳入发布包，装包后 `npm test` 可用。新增回归测试。
-
-### 0.19.1
-
-**使用手册跟进（0.19.1）**：随包发布的 `docs/manual.html` 补上工作台「项目初始化」（默认置顶标签页、项目根自动发现、AI 生成 150 秒超时 + 覆盖需人工确认），第 7 节标签页从「三个」改为「五个」；安装章节补全 dsh CLI（非源码）安装方式与 pnpm 前置、`dsh plugin add` 的挂载机制；删除顶层已废弃的 `USER_GUIDE.html`（v0.9.1、无引用、不随包发布），README 目录结构描述同步为五标签页。
-
-### 0.19.0
-
-**工作台项目初始化（0.19.0）**：工作台新增置顶的「项目初始化」标签页——加载展示项目根 `AGENTS.md`、一键让 AI 扫描项目生成草稿（预览后再确认写回）、支持手动编辑与覆盖；Host 控制器新增 `readInit`/`writeInit`/`generateInit` 三个 Remote，`generateInit` 通过 `ctx.llm` + 默认模型在 Host 端直接生成，复用 `dev_task init` 的 200 行硬约束。
-
-### 0.18.1
-
-**会话工作目录修复（0.18.1）**：`dev_task` 的所有文件操作此前用 `fs.resolve(相对路径)` 不带 cwd，落到了 fs 后端默认目录（DSH 进程目录）而非会话工作区——在 web 会话里会把台账、配置、`AGENTS.md`、git 钩子写到/读到错误位置。改为从 `exec.agent.session.header.cwd` 取会话工作区并传给每个解析，补 4 项回归测试。
-
-### 0.18.0
-
-**工程可靠性加固（0.18.0）**：① 高风险任务与流程能力绑定——`high_risk` 任务只能在具备「验证门 + 文件范围 + 评审门」能力的流程创建，选 `agile`/`minimal` 直接拒绝；② 任务创建时固化流程快照（预设 id + version + 完整配置），后续 `status`/`advance`/`verify`/`review`/`commit` 一律用快照，中途改 `.dsh/eng.json` 不再漂移在途任务的门禁；③ 未知流程失败关闭——`.dsh/eng.json` 缺 `flow` 或 `flow` 不在预设里一律报错（`UNKNOWN_FLOW` / 缺字段），不再静默回退 `standard`；④ 核心 skill/rule 不可取消、不可被同名覆盖——项目阶段绑定只能追加不能移除预设自带绑定，同名规则/技能读内置版、新建同名被拒；⑤ `init` 升级 `inspect → propose → apply` 三阶段，覆盖已有 `AGENTS.md` 需人工批准。
-
-### 0.17.0
-
-**项目初始化 + 语言无关内置规则（0.17.0）**：`dev_task` 新增 `init` 操作，生成项目根 `AGENTS.md`（DSH 每会话自动注入），落盘前做 200 行硬校验、已存在需 `overwrite` 才覆盖；内置 `solution-design` / `coding-conventions` / `security-redlines` 去掉 Java 专属概念（Impl / DTO / VO、Controller / Mapper），改成语言中立骨架，语言特定规范交给项目自建 rule。
-
-### 0.16.0
-
-**流程预设收敛（0.16.0）**：把「自由编辑阶段图/守卫/产物/提交规则/验证开关」收敛为「选一套内置流程预设 + 给节点挂 skill/rule」。新增 `src/workflows.ts` 内置 `standard` / `agile` / `minimal` 三套流程（阶段图、守卫、产物字段、提交规则、验证证据开关全部固化）；`.dsh/eng.json` 从完整配置精简为 `{ flow, stage_bindings }`；工作台删掉流转/产物/提交规则/验证开关编辑 UI，只剩「流程预设 + 流程节点（只读）+ 阶段技能/规则」；git 提交钩子同步按 `flow` 选预设。
-
-### 0.15.0
-
-**弹窗 + markdown 查看（0.15.0）**：skill/rule 的查看与编辑从内联卡片改为居中宽弹窗；查看时正文用 DSH 自带的 `MarkdownText` 渲染成 markdown 富文本（不引入任何新依赖），编辑时正文保持纯文本。
-
-### 0.14.0
-
-**skill / rule 查看 + 删除（0.14.0）**：内置 skill/rule 从「只读不可见」改为「可查看正文」；自建（项目/用户）skill/rule 新增删除（两步确认）。删改在类型层即把 `bundled` 排除，内置资源永不误删。
-
-### 0.13.0
-
-**两阶段评审硬门（0.13.0）**：`todos_done` 进一步收紧——每个 done 的 item 必须带 spec + quality 都 pass 的评审记录，缺评审或任一阶段 fail 都会挡住「开发 → 交付」，并以具体 item 报出阻塞原因（`todosBlockers`）。派工审计保持软约束。
-
-### 0.12.0
-
-**台账硬门 + 软约束修复（0.12.0）**：`todos_done` 守卫改为「实施项非空且全部 done」；`code-implement` 技能里写清「两阶段都 pass 才标 done」。
-
-### 0.11.0
-
-**派工 / 审核审计（0.11.0）**：`TaskItem` 新增 `dispatch`（子代理派工留痕）与 `review`（spec / quality 两阶段评审）字段；`dev_task` 新增 `dispatch`、`review_item` 操作；工作台新增「任务台账」视图展示逐项审计。派工留痕是软约束——模型可自己实现小项而不强制派子代理。
-
-### 0.10.0
-
-**需求/方案人工确认门（0.10.0）**：`requirement_confirmation` / `solution_confirmation` 两个守卫从「模型自己标记」升级为「人来批准」。走 `advance` 撞上确认门时，`dev_task` 用 `@deepseek-ai/dsh-user-approval` 发起审批；人在页面点「允许」才放行，模型不能自己确认、也不能绕过。headless e2e 验证真模型全流程时两个确认都会触发。
-
-### 0.9.1
-
-**工作台可用性（0.9.1）**：修复「新建 skill / 新建 rule」按钮点击不弹出表单（`formOpen` 只认编辑态，新建态缺少显式标志）；给六个守卫补 hover 说明、把「产物齐全」改名「产物字段已填全」并讲清「产物 = 阶段要写清楚的记录、字段 = 这份记录里必填的空」，「节点挂载」改名「阶段技能 / 规则」。
-
-### 0.9.0
-
-**点选即用（0.9.0）**：host 入口新增 `src/seed-preset.ts`——首次启动自动把当前 `standard` 复制成 `eng` 预设（换工程人设 + 追加 agent 行，幂等、不覆盖手改）。装 bundle 重启后预设列表直接出现「工程化开发引擎」，点选即激活、切走即不激活，零复制/零编辑/零脚本。实机 boot 验证：boot 后 `.agent-presets/eng` 自动生成（agent 行 + 工程人设齐全）、roster 列出 `eng`（user）、`eng` 会话有 `dev_task` 且 persona 含「铁律」、`standard` 会话无 `dev_task`。
-
-### 0.8.1
-
-**一键激活（0.8.1）**：新增 `preset/enable.mjs`（bin: `dsh-task-engine-enable`），一条命令自动复制 `standard` → `eng`、把 persona 换成工程人设、追加 agent 行、写 `preset.yml`。persona 从「必须换」降级为「可选」——`eng-delivery` 技能自带 `whenToUse`，即使不加人设，模型遇到开发请求也自己加载技能走 `dev_task`；最简激活只剩「复制预设 + 追加一行 agent 行」。实机验证：脚本生成的 `eng` 预设挂载后 `dev_task` 可见、persona 以工程人设（含「铁律」）渲染、`standard` 仍无 `dev_task`。
-
-### 0.8.0
-
-**按预设激活（0.8.0）**：`dev_task` 工具与内置技能从 host 全局层拆到 agent 层。host 入口只挂 `task-engine` Remote 控制器 + 工作台 UI（`src/index.ts`）；新增 `src/agent.ts`（`./agent` 出品）、`src/dev-task.ts`、`src/shipped-skills.ts`，由预设的 `agent.cordis.yml` 命名后，在**该预设的 scope** 里注册工具与技能。实机 boot 验证：`standard` 会话工具目录不含 `dev_task`（26 个工具），加了 `@godv61/dsh-task-engine/agent` 行的 `eng` 会话含 `dev_task`（27 个工具）且描述正确，换回 `standard` 再次不含——切换预设即切换流程激活状态。
-
-### 0.7.0
-
-**全屏工作台 + 在线编辑（0.7.0）**：配置页从设置弹窗迁出，改为侧边栏 `sidebar.footer.action`「工程流程」按钮，点开 `shell.overlay` 全屏工作台（触发按钮与覆盖层共享一个 store 控制开关）。工作台分「流程配置 / 技能 skill / 规则 rule」三个标签页；技能和规则列表支持在线编辑——`readSkill`/`readRule` 读回正文、改 description/whenToUse/正文、`writeSkill`/`writeRule` 写回；内置项只读，项目/用户项可原地编辑，新建同时支持项目级/用户级。旧的 `settings.section` 入口移除，统一走侧边栏按钮。浏览器 e2e 全绿。
-
-### 0.6.1
-
-**配置页精简 + 自建 skill 可观测（0.6.1）**：设置页的流转/产物/提交规则/新建默认折叠，「节点挂载」从六阶段全平铺改成「选一个阶段再看它挂了什么」；新建成功提示带回显路径（`.dsh/skills/<name>/SKILL.md` 或 `$DSH_HOME/…`），挂载清单给非内置的 skill/rule 标「（项目）/（用户）」来源。修复 `listSkills` 依赖 host skill registry 导致项目 `.dsh/skills` 自建技能不显示的问题——改为与 `listRules` 一致，直接扫「内置 + 项目 + 用户」三层目录。浏览器 e2e 全绿。
-
-### 0.6.0
-
-**skill/rule 挂载与渐进披露（0.6.0）**：`WorkflowConfig` 新增 `stage_bindings`（每阶段挂 skills/rules，可选字段），`dev_task` 的 `status`/`advance` 按当前阶段披露挂载的 skill 名 + rule 正文；内置 6 技能 + 3 规则库；Host 控制器新增 `listSkills`/`listRules`/`writeSkill`/`writeRule`；设置页新增「节点挂载」和「新建 skill / rule」两块，同时补上 `dev_task` 缺失的 `items` 操作（更新实施项状态）。引擎层 `stage_bindings` 校验（未知阶段/空名）与合并已单测通过。
-
-### 0.5.0
-
-**网页图形化配置界面（0.5.0）**：新增 `src/client/` 设置页「工程流程配置」+ Host 端 `task-engine` Remote 控制器；`@godv61/dsh-task-engine` 升级为双端包（`dsh.client` manifest + `./client` 出品，`exports` 暴露）。已实机验证：`dsh web` 起服务后 boot 数据里 `@godv61/dsh-task-engine` 以 `inject:["@deepseek-ai/dsh-api-gateway"]` 进入 application batch、`/plugins/…/client.js` 正常服务；headless 冒烟确认 boot + `dev_task` 未被新控制器破坏。浏览器点击级 e2e 留到发布后用真浏览器收尾。
-
-### 0.4.1
-
-**真实模型端到端（0.4.1）**：headless + NewAPI DeepSeek 下让真模型走 `dev_task` 全流程，抓到并修掉一个真实 bug——`readText`/`writeText` 调 `fs.resolve()` 漏了 `await`，把 `Promise<FsTarget>` 当 `target` 传给了读写方法，导致 create/record/advance/commit 全部写不了任务文件、读永远返回 undefined。0.4.1 修复（`await fs.resolve(relPath)`），并把 `task_id` 在 create 也必填的说明补进工具 schema 与技能。修复后走真实 `ctx.fs` 路径冒烟全绿。

package/docs/README.md

@@ -1,42 +0,0 @@
-# 使用文档
-
-[← 返回项目首页](../README.md)
-
-DSH Task Engine 是 DeepSeek Harness 的工程任务工作台。先完成安装，再按需要配置技能和规则。`0.29.0` 新增任务级流程、项目初始化与可选 SonarQube CI 审核。
-
-## 开始使用
-
-| 文档 | 内容 |
-| :--- | :--- |
-| [安装与启用](getting-started.md) | 安装到 Web profile、启用工程会话、确认安装结果。 |
-| [自适应工程任务](adaptive-workflows.md) | 四档任务流程、元技能、项目 init 与可选 SonarQube；说明当前尚不支持未提交代码的 Sonar 审核。 |
-| [旧版流程配置](configuration.md) | 旧三流程、阶段绑定、配置文件与任务快照。 |
-| [技能与规则安装](resource-install.md) | 系统文件选择、安装预览、项目/个人范围和格式要求。 |
-| [常见问题](faq.md) | 预设区别、资源使用、项目目录与能力限制。 |
-| [完整 HTML 手册](manual.html) | 当前功能与旧版兼容说明；下载后在浏览器中打开。 |
-
-## 参与开发
-
-| 文档 | 内容 |
-| :--- | :--- |
-| [开发指南](development.md) | 构建、测试、包结构与可选 host 接入。 |
-| [功能规划](roadmap.md) | 已发布能力与规划中的范围。 |
-| [更新日志](CHANGELOG.md) | 按版本查阅变化；**这是版本信息的唯一权威来源**。 |
-| [插件收录材料](listing/submission.md) | Awesome DSH Plugin 的提交条件、条目内容与收录结果。 |
-
-## 历史记录
-
-以下文档是**各自版本当时的快照**，用于追溯当时的验证范围与已知边界。其中的测试数量、
-实现细节和界面描述可能已被后续版本替代——当前行为以「开始使用」和[更新日志](CHANGELOG.md)为准。
-
-| 文档 | 内容 |
-| :--- | :--- |
-| [0.23.2 验证记录](testing/0.23.2/测试报告.md) | 两轮完整开发、归档回退与门禁专项的实际结果。 |
-| [0.23.2 发布说明](releases/0.23.2.md) | 验证命令单次审批修复、提交指引与管控边界。 |
-| [0.23.1 验证记录](testing/0.23.1/测试报告.md) | 自动化、安装包与实机证据的适用范围。 |
-| [0.23.1 发布说明](releases/0.23.1.md) | 真实项目发现的问题、修复及能力边界。 |
-| [0.23.1 回归迭代说明](workflow-regression.md) | 真实项目逐轮问题的处理记录。 |
-| [0.23.0 验证记录](testing/0.23.0/测试报告.md) | 资源导入、工作台交互与包入口的验证。 |
-| [0.23.0 发布说明](releases/0.23.0.md) | 早期安装交互及界面调整。 |
-
-> 0.23.3 起的版本变化全部记录在[更新日志](CHANGELOG.md)中，不再单独出具发布说明。

package/docs/adaptive-workflows.md

@@ -1,76 +0,0 @@
-# 自适应工程任务
-
-本页描述 `0.29.3` 的任务级流程。可选 SonarQube 接入复用 CI 扫描，要求先提交并推送才能审核；它还不能对未提交代码执行 Sonar 检查。
-
-旧 `.dsh/eng.json` 与已创建任务的快照继续可读，工作台不再提供旧版流程配置页。新需求在工程化会话中先评估复杂度，调用 `dev_task assess` 预览，再用 `create` 的 `complexity` 与 `complexity_reason` 创建任务。复杂度由需求范围和实现依赖决定，`risk_level` 单独判断。
-
-| 复杂度 | 适用情形 | 元技能顺序 |
-| :--- | :--- | :--- |
-| 低 `low` | 边界明确的局部修改 | 代码开发 → 测试 → 代码审核 → 完成 |
-| 中 `medium` | 常规功能或缺陷修复 | 需求分析 → 代码开发 → 测试 → 代码审核 → 完成 |
-| 高 `high` | 跨模块或存在实现依赖 | 需求分析 → 任务编排 → 代码开发 → 测试 → 代码审核 → 完成 |
-| 超高 `ultra` | 完整新模块或大范围重构 | 需求分析 → 架构设计 → 任务编排 → 代码开发 → 测试 → 代码审核 → 完成 |
-
-高档的任务编排按实现先后拆解，记录每步依赖、完成判据和交接产物；它不按人员或分支分发。超高档的架构设计记录模块边界、接口和取舍，不默认要求迁移或回退演练。每档的测试要有实际命令回执，审核要有通过结论；低档每项一次审核，其余档对需求符合性和质量分别记录。提交检查点在“测试”：验证通过后提交并推送分支，CI 才能产生供“代码审核”读取的 Sonar 分析。
-
-## 元技能交接契约
-
-| 元技能 | 输入 | 交接产物 |
-| :--- | :--- | :--- |
-| 需求分析 | 用户诉求、代码库现状 | 目标、范围、可验证的验收条件 |
-| 架构设计 | 已明确的需求与现有结构 | 模块边界、接口变化、主要取舍 |
-| 任务编排 | 需求、必要的架构决定 | 按先后顺序的实施项、依赖、每步完成判据与交接 |
-| 代码开发 | 上述产物、项目 Skill/Rule | 变更文件、实现结果、已知限制 |
-| 测试 | 验收条件和变更 | 真实命令回执、覆盖场景、失败及修复结果 |
-| 代码审核 | 变更和测试结果 | 审核结论；启用 SonarQube 时包含该次 CI 扫描的结果 |
-
-每个节点始终加载同名核心 Skill。`.dsh/meta.json` 的 `meta_bindings` 只增加项目需要的 Skill 名称，不决定整个项目所有会话的流程。相同名称按 `.dsh/skills` → `.agents/skills` → `$DSH_HOME/skills` → 插件内置解析。生效 Skill 的 `profile.json` 持有 Rule 引用；项目同名覆盖用户级时采用项目 Skill 自身的 Rule，不暗中合并。
-
-工作台中点击“配置核心 Skill 的 Rule”即可编辑。若核心 Skill 当前来自内置、用户级或 `.agents/skills`，保存时会先复制为同名 `.dsh/skills` 项目 Skill，再写入该项目 Skill 的 Rule 档案；打开编辑器不会写入文件。
-
-```json
-{
-  "meta_bindings": {
-    "requirements-analysis": ["qms-project-map"],
-    "code-development": ["qms-project-map", "qms-code-backend"]
-  }
-}
-```
-
-任务创建时冻结实际的流程、Skill 来源和 Rule 引用。运行时仍读取相同来源的最新正文并报告漂移，因此团队修改规范后，进行中的任务应重新核查已有结论。
-
-## 初始化项目知识
-
-工作台“项目初始化”页将项目 Skill/Rule 与 `AGENTS.md` 分为两个区域。“自适应流程”页顶部也有“初始化项目 Skill / Rule”入口。点击“复制初始化请求”后，在项目根工作区的新“工程化开发引擎”会话中粘贴发送；页面本身不会启动模型或写入 Skill/Rule。
-
-在项目根目录运行 `dev_task init_project phase=inspect`。扫描读取一级目录与常见构建清单，返回结构、可证实的技术栈版本及建议的多个项目 Skill 名称，例如 `eam-project-map`、`eam-tech-stack`、`eam-code-backend`。模型结合实际源码、测试和现有治理文件拟定 Skill/Rule 内容；`phase=propose` 预览文件与挂载关系；用相同内容及哈希调用 `phase=apply` 才写入 `.dsh/skills`、`.dsh/rules` 和 `.dsh/meta.json`。已有同名资源不会被 init 覆盖。扫描结果只提供证据，旧代码中的偶发写法不能自动成为团队规则。
-
-## 可选 SonarQube 审核
-
-不需要 SonarQube 的项目保持工作台「自适应流程」里的开关关闭，或不在 `.dsh/meta.json` 写 `sonar`。不需要配置 Token，代码审核仍按审核元技能和项目 Rule 执行。
-
-需要使用当前 CI 接入的项目，在工作台打开 SonarQube 开关，填写服务地址、项目 Key、分析对象（分支或合并请求）及 Token 环境变量名，并保存。也可以手工写入 `.dsh/meta.json`。只有显式启用时，之后创建的新任务才冻结 SonarQube 审核策略；已创建任务不会因开关变化而自动切换：
-
-```json
-{
-  "sonar": {
-    "enabled": true,
-    "host_url": "https://sonarqube.example.com",
-    "project_key": "my-project",
-    "mode": "branch",
-    "token_env": "SONAR_TOKEN"
-  }
-}
-```
-
-Token 只放在运行插件的服务进程环境变量，不能写入配置或任务台账。功能测试通过后，**当前实现**在“测试”检查点提交并推送分支，等待现有 CI 完成扫描。到达“代码审核”后，从 CI 的 `report-task.txt` 取 `ceTaskId`，调用 `dev_task sonar_check`；合并请求模式还要提供请求编号。该操作查询这次 Compute Engine 任务的 `analysisId` 和 Quality Gate，并在配置的分支或合并请求上读取新代码问题。Quality Gate 不是 `OK`、有中高等级问题或代码在审核后变化，都会阻止审核通过与任务完成。修复后重新测试、重新扫描、重新检查。
-
-建议在 CI 的 Sonar job 中保存 `target/sonar/report-task.txt` 为制品，方便取得 `ceTaskId`。如果 CI 已配置 `sonar.qualitygate.wait=true`，它可以继续作为 CI 门禁；插件读取分析结果，不重复运行扫描。Sonar 只需针对所选任务实际扫描的分支或合并请求配置 `mode`，具体 CI 触发条件由项目自行决定。分支/MR 最新问题列表与指定 `analysisId` 的门禁分别来自 SonarQube API；如果同一分支同时运行多次扫描，应按 CI 的最新扫描重新审核，避免把旧结果当成当前代码。
-
-失败案例可以用 `dev_task learn_rule phase=propose` 生成项目 Rule 预览，注明 Sonar issue key、可复用原因和正确写法；审阅后用 `phase=apply` 写入项目 Rule 并挂到对应项目代码 Skill。它只影响未来任务，不能把一次误报或整个 Quality Profile 自动复制成规则。
-
-### 分支、提交与当前限制
-
-SonarQube 服务端把分析结果放在项目的某个分支或合并请求下，插件以它定位要查询的问题。分支是结果的命名空间，**不是审核前必须提交的技术要求**。本版要求先提交，是因为它选择复用 CI：CI 扫描已推送的代码，插件随后读取结果。这与“功能通过后先审核未提交代码，修复通过再提交”的目标不一致。
-
-SonarQube for IDE 的 Connected Mode 可以对本地未提交代码应用服务端 Quality Profile 中受支持的规则；本地分析不能代表完整的服务端 Quality Gate，部分复杂规则只在服务端分析时运行。本插件当前没有接入 IDE 的本地分析，也没有提供未提交代码的 Sonar 审核。因此需要提交前 Sonar 审核的团队，暂时不能把本版 `sonar_check` 当作该门禁。未来应把提交前本地检查和提交后 CI Quality Gate 分开设计，并明确两者覆盖范围。

package/docs/assets/workflow-banner.svg

@@ -1,29 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="1280" height="400" viewBox="0 0 1280 400" role="img" aria-labelledby="title description">
-  <title id="title">DSH Task Engine · 个人工程流程工作台</title>
-  <desc id="description">标准流程示意：需求评审、设计、开发、交付、代码审核、完成。流程、技能与规则组成个人开发工作台。</desc>
-  <defs>
-    <linearGradient id="bg" x1="0" y1="0" x2="1" y2="1"><stop stop-color="#111b2c"/><stop offset="1" stop-color="#172c35"/></linearGradient>
-    <linearGradient id="accent"><stop stop-color="#86efac"/><stop offset="1" stop-color="#5eead4"/></linearGradient>
-  </defs>
-  <rect width="1280" height="400" rx="24" fill="url(#bg)"/>
-  <path d="M1000 0L1280 280M1120 0L1280 160M920 0L1280 360" stroke="#345454" stroke-opacity=".2" stroke-width="1"/>
-  <g font-family="Segoe UI, PingFang SC, Microsoft YaHei, sans-serif">
-    <rect x="56" y="43" width="30" height="30" rx="8" fill="url(#accent)"/>
-    <path d="M64 58h14m-6-6 6 6-6 6" fill="none" stroke="#14262c" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
-    <text x="101" y="65" fill="#d2e8e3" font-size="18" font-weight="600" letter-spacing="2">DSH TASK ENGINE</text>
-    <text x="56" y="141" fill="#f4f7f7" font-size="46" font-weight="650">让每次开发，都有清晰的下一步。</text>
-    <text x="58" y="184" fill="#a6b9bd" font-size="22">DeepSeek Harness 的个人工程流程工作台</text>
-    <text x="58" y="228" fill="#80dcb3" font-size="15" letter-spacing="1">流程预设  /  阶段技能  /  项目规则  /  交付记录</text>
-    <g fill="#1c3440" stroke="#35505a">
-      <rect x="56" y="264" width="168" height="76" rx="13"/><rect x="252" y="264" width="168" height="76" rx="13"/>
-      <rect x="448" y="264" width="168" height="76" rx="13"/><rect x="644" y="264" width="168" height="76" rx="13"/>
-      <rect x="840" y="264" width="168" height="76" rx="13"/><rect x="1036" y="264" width="168" height="76" rx="13"/>
-    </g>
-    <g fill="#e4efee" font-size="21" text-anchor="middle">
-      <text x="140" y="310">需求评审</text><text x="336" y="310">设计</text><text x="532" y="310">开发</text>
-      <text x="728" y="310">交付</text><text x="924" y="310">代码审核</text><text x="1120" y="310" fill="#86efac">完成</text>
-    </g>
-    <g fill="#729a9b" font-size="22" text-anchor="middle"><text x="238" y="310">→</text><text x="434" y="310">→</text><text x="630" y="310">→</text><text x="826" y="310">→</text><text x="1022" y="310">→</text></g>
-    <text x="1204" y="372" fill="#839b9f" font-size="13" text-anchor="end">STANDARD WORKFLOW · 标准流程示意</text>
-  </g>
-</svg>