@godv61/dsh-task-engine 0.27.1 → 0.29.0

package/docs/CHANGELOG.md

@@ -4,37 +4,51 @@
 
 按版本查阅功能变化。当前使用方式以[项目首页](../README.md)和使用指南为准；历史条目中的实现方式、限制与测试数量可能已被后续版本替代。
 
-## 0.27.1
+## 0.29.0（2026-09-30）
 
-- 移除六个内置业务 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` 同时取消离开提交检查点的强制提交要求。返工会使受影响阶段的技能结果失效。
-- 增加配置保存读回、同名资源、人工审批、终态阻塞及返工证据回归测试。
-- 工作台改用更宽的自适应布局；流程页用双栏穿梭框绑定技能，技能卡片和已绑定技能都可打开右侧规则配置抽屉，窄屏自动改为纵向布局。
+- 新任务可按低、中、高、超高复杂度选择任务级流程；内置六个元技能及交接契约，旧 `.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
 

package/docs/README.md

@@ -2,17 +2,18 @@
 
 [← 返回项目首页](../README.md)
 
-DSH Task Engine 是 DeepSeek Harness 的个人工程流程工作台。先完成安装，再按需要配置流程、技能和规则。
+DSH Task Engine 是 DeepSeek Harness 的工程任务工作台。先完成安装，再按需要配置技能和规则。`0.29.0` 新增任务级流程、项目初始化与可选 SonarQube CI 审核。
 
 ## 开始使用
 
 | 文档 | 内容 |
 | :--- | :--- |
-| [安装与启用](getting-started.md) | 安装到 Web profile、启用工程会话、确认安装结果。 |
-| [流程配置](configuration.md) | 三个内置流程、阶段绑定、配置文件与任务快照。 |
+| [安装与启用](getting-started.md) | 安装到 Web profile、启用工程会话、确认安装结果。 |
+| [自适应工程任务](adaptive-workflows.md) | 四档任务流程、元技能、项目 init 与可选 SonarQube；说明当前尚不支持未提交代码的 Sonar 审核。 |
+| [旧版流程配置](configuration.md) | 旧三流程、阶段绑定、配置文件与任务快照。 |
 | [技能与规则安装](resource-install.md) | 系统文件选择、安装预览、项目/个人范围和格式要求。 |
 | [常见问题](faq.md) | 预设区别、资源使用、项目目录与能力限制。 |
-| [完整 HTML 手册](manual.html) | 详细操作、工具说明与任务走查；下载后在浏览器中打开。 |
+| [完整 HTML 手册](manual.html) | 当前功能与旧版兼容说明；下载后在浏览器中打开。 |
 
 ## 参与开发
 
@@ -38,4 +39,4 @@ DSH Task Engine 是 DeepSeek Harness 的个人工程流程工作台。先完成
 | [0.23.0 验证记录](testing/0.23.0/测试报告.md) | 资源导入、工作台交互与包入口的验证。 |
 | [0.23.0 发布说明](releases/0.23.0.md) | 早期安装交互及界面调整。 |
 
-> 0.23.3 起的版本变化全部记录在[更新日志](CHANGELOG.md)中，不再单独出具发布说明。
+> 0.23.3 起的版本变化全部记录在[更新日志](CHANGELOG.md)中，不再单独出具发布说明。

package/docs/adaptive-workflows.md

@@ -0,0 +1,72 @@
+# 自适应工程任务
+
+本页描述 `0.29.0` 的任务级流程。可选 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，不暗中合并。
+
+```json
+{
+  "meta_bindings": {
+    "requirements-analysis": ["qms-project-map"],
+    "code-development": ["qms-project-map", "qms-code-backend"]
+  }
+}
+```
+
+任务创建时冻结实际的流程、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/configuration.md

@@ -1,8 +1,8 @@
-# 流程配置
+# 旧版流程配置
 
 [← 文档导航](README.md)
 
-当前版本通过内置流程和阶段资源绑定配置项目。推荐使用工作台“流程配置”页面；高级用户也可以编辑项目根目录的 `.dsh/eng.json`。
+本页描述兼容保留的 `standard`、`agile`、`minimal` 与 `.dsh/eng.json`。新任务可按需求选择四档自适应流程，元技能挂载和可选 SonarQube 位于 `.dsh/meta.json`；见[自适应工程任务](adaptive-workflows.md)。旧任务继续按自己的快照执行。
 
 ## 选择流程
 
@@ -24,42 +24,42 @@
 }
 ```
 
-`stage_bindings` 的键是当前流程中的阶段名称，`skill_refs` 只保存技能引用。项目级技能（包括从 `.agents/skills` 发现的 Codex 技能）的 `skill_profiles` 在 `.dsh/eng.json` 中保存唯一的规则列表和证据类型；用户级技能的规则配置保存在 `$DSH_HOME/skills/<技能名>/profile.json`，所有项目和会话共用。用户级技能只能关联用户级规则，避免引用某个项目独有的规则。
+`stage_bindings` 的键是当前流程中的阶段名称，`skill_refs` 只保存技能引用。项目级技能（包括从 `.agents/skills` 发现的 Codex 技能）的 `skill_profiles` 在 `.dsh/eng.json` 中保存唯一的规则列表和证据类型；用户级技能的规则配置保存在 `$DSH_HOME/skills/<技能名>/profile.json`，所有项目和会话共用。用户级技能只能关联用户级规则，避免引用某个项目独有的规则。
 
 ```json
 {
   "flow": "standard",
   "stage_bindings": {
     "开发": {
-      "skill_refs": [{ "source": "project", "name": "my-implementation" }]
-    }
-  },
-  "skill_profiles": {
-    "project:my-implementation": {
-      "rules": [{ "source": "project", "name": "api-contract" }],
-      "evidence": "none"
-    }
-  }
-}
+      "skill_refs": [{ "source": "project", "name": "my-implementation" }]
+    }
+  },
+  "skill_profiles": {
+    "project:my-implementation": {
+      "rules": [{ "source": "project", "name": "api-contract" }],
+      "evidence": "none"
+    }
+  }
+}
 ```
 
-**规则挂载在技能下,节点不提供规则追加、禁用或覆盖。** 在工作台“技能”页或流程页的技能规则侧栏配置规则；同一技能挂到任何节点,都是同一套规则。需要不同规则组合时,复制成另一个独立技能。旧版把规则内联在各节点技能绑定的配置仍可读取；保存后会转为上述格式。若旧内联绑定与 `skill_profiles` 同时存在，明确配置的技能档案优先，所有节点使用它的规则和凭证；若没有技能档案而同一旧技能在不同节点的规则不同，系统会要求先复制为独立技能，不会任意选一套覆盖另一套。
+**规则挂载在技能下,节点不提供规则追加、禁用或覆盖。** 在工作台“技能”页或流程页的技能规则侧栏配置规则；同一技能挂到任何节点,都是同一套规则。需要不同规则组合时,复制成另一个独立技能。旧版把规则内联在各节点技能绑定的配置仍可读取；保存后会转为上述格式。若旧内联绑定与 `skill_profiles` 同时存在，明确配置的技能档案优先，所有节点使用它的规则和凭证；若没有技能档案而同一旧技能在不同节点的规则不同，系统会要求先复制为独立技能，不会任意选一套覆盖另一套。
+
+规则引用带来源(`bundled:` / `project:` / `user:`),因此同名资源不会被混淆。同一份规则可被多个技能引用,不需要复制正文;编辑共享规则时界面会显示受影响的技能。
+
+项目技能可来自 `.dsh/skills/<名称>/SKILL.md`（引用来源 `project:`）或 `.agents/skills/<名称>/SKILL.md`（引用来源 `codex-project:`）。工作台会扫描这两个项目目录；新建技能仍默认写入 `.dsh/skills`。Codex 项目技能的正文在工作台中只读，可在原文件编辑；其规则配置仍属于该技能，存于项目 `.dsh/eng.json`，规则正文可引用项目 `.dsh/rules`。例如，节点使用 `codex-project:my-skill`，对应 `skill_profiles["codex-project:my-skill"].rules` 可引用 `project:api-contract`。Codex 自身 `.codex/rules/*.rules` 是命令权限配置，并非这里的 Markdown 规则。
 
-规则引用带来源(`bundled:` / `project:` / `user:`),因此同名资源不会被混淆。同一份规则可被多个技能引用,不需要复制正文;编辑共享规则时界面会显示受影响的技能。
-
-项目技能可来自 `.dsh/skills/<名称>/SKILL.md`（引用来源 `project:`）或 `.agents/skills/<名称>/SKILL.md`（引用来源 `codex-project:`）。工作台会扫描这两个项目目录；新建技能仍默认写入 `.dsh/skills`。Codex 项目技能的正文在工作台中只读，可在原文件编辑；其规则配置仍属于该技能，存于项目 `.dsh/eng.json`，规则正文可引用项目 `.dsh/rules`。例如，节点使用 `codex-project:my-skill`，对应 `skill_profiles["codex-project:my-skill"].rules` 可引用 `project:api-contract`。Codex 自身 `.codex/rules/*.rules` 是命令权限配置，并非这里的 Markdown 规则。
+[最小配置示例](../defaults/eng.json)仅选择流程，不绑定技能或规则。
 
-[最小配置示例](../defaults/eng.json)仅选择流程，不绑定技能或规则。
+**预设不带任何绑定。** 一个只写了 `flow` 的配置就是字面意思：节点没有绑定，阶段仍按流程骨架流转。工作台的「采用推荐配置」只填写可修改的提交文本、产物字段和评审深度，不添加或覆盖技能与规则。项目级技能和规则放在 `.dsh/skills/` 与 `.dsh/rules/`；同一份规则可由多个技能引用。
 
-**预设不带任何绑定。** 一个只写了 `flow` 的配置就是字面意思：节点没有绑定，阶段仍按流程骨架流转。工作台的「采用推荐配置」只填写可修改的提交文本、产物字段和评审深度，不添加或覆盖技能与规则。项目级技能和规则放在 `.dsh/skills/` 与 `.dsh/rules/`；同一份规则可由多个技能引用。
-
-插件只内置会话编排技能 `eng-delivery`，不提供阶段业务技能或业务规则。它由会话预设使用，不显示在阶段技能列表。工作台可以安装或新建项目级、用户级资源。
+旧版流程的阶段绑定不自动获得业务技能或规则。新流程另外内置六个通用元技能；两种路径都由使用者提供项目业务技能与 Rule。工作台可以安装或新建项目级、用户级资源。
 
-进入阶段后,`dev_task` 按稳定的资源引用读取并披露该阶段技能和规则的最新正文。DSH 技能仍检查 Harness 的 skill 工具成功加载记录；Codex 项目技能使用 `dev_task operation=load_skill`（`skill_name` 传 `codex-project:<名称>`）加载技能及所挂规则，并检查这次加载记录。技能可声明证据类型(`command` / `artifact` / `review` / `manual` / `none`)。`manual` 通过宿主人工审批记录，不要求执行命令；`artifact` 需要该阶段有产物定义且必填字段完整。未声明时沿用命令回执。`status.skill_obligations` 中的 `command_receipts_required` 列出需要命令回执的技能。
+进入阶段后,`dev_task` 按稳定的资源引用读取并披露该阶段技能和规则的最新正文。DSH 技能仍检查 Harness 的 skill 工具成功加载记录；Codex 项目技能使用 `dev_task operation=load_skill`（`skill_name` 传 `codex-project:<名称>`）加载技能及所挂规则，并检查这次加载记录。技能可声明证据类型(`command` / `artifact` / `review` / `manual` / `none`)。`manual` 通过宿主人工审批记录，不要求执行命令；`artifact` 需要该阶段有产物定义且必填字段完整。未声明时沿用命令回执。`status.skill_obligations` 中的 `command_receipts_required` 列出需要命令回执的技能。
 
 挂在终态(例如"完成")的技能在进入终态前执行。测试技能通常建议挂在"交付";现有"完成"绑定也会在审核阶段执行后才放行。标准流程 v2 在审核通过后提交,并核对真实 Git HEAD。修改文件或声明范围后,旧验证回执失效。
 
-资源管理保留不同来源的同名条目,避免来源误标和误操作。DSH 技能通过 Harness 的 skill 工具加载；Codex 项目技能通过 `dev_task load_skill` 按来源和任务读取。
+资源管理保留不同来源的同名条目,避免来源误标和误操作。DSH 技能通过 Harness 的 skill 工具加载；Codex 项目技能通过 `dev_task load_skill` 按来源和任务读取。
 
 ### 旧配置迁移
 
@@ -69,12 +69,12 @@
 
 阶段顺序、转移条件、产物必填字段和提交策略由所选预设固定。新建规则可以提供工作指引，但不会改变引擎中的提交消息校验或阶段条件。
 
-可视化自定义流程**不在计划内**：它把流程设计的负担转嫁给使用者，而三个内置流程已覆盖个人项目的常见需要。详见[功能规划](roadmap.md)。
+旧版页面不提供可视化编辑任意阶段图。新的任务级四档路径见[自适应工程任务](adaptive-workflows.md)。
 
 ## 配置与正在进行的任务
 
 新任务记录创建时的完整流程快照，后续按该快照执行。修改项目配置影响之后创建的任务，不会自动迁移进行中的任务。
 
-任务开始时会保存所引用技能和规则正文的**审计副本**，但运行时按原来的来源与名称重新读取：项目级资源可随时编辑，同项目的其他会话及进行中的任务在下一次交互读取最新正文；用户级资源在所有项目和会话中同理。状态机会继续使用任务创建时的流程快照。正文变化会在 `status` 中提示；删除仍被绑定的资源会阻止阶段流转。已记录的验证或人工确认不会因为正文编辑自动失效，修改约束后应重新检查这些结果。资源类型、来源和名称共同构成身份，因此同名技能和规则不会混淆。缺失的必需资源会阻止新任务创建；已完成任务若需返工，使用 `revise` 显式重开。
+任务开始时会保存所引用技能和规则正文的**审计副本**，但运行时按原来的来源与名称重新读取：项目级资源可随时编辑，同项目的其他会话及进行中的任务在下一次交互读取最新正文；用户级资源在所有项目和会话中同理。状态机会继续使用任务创建时的流程快照。正文变化会在 `status` 中提示；删除仍被绑定的资源会阻止阶段流转。已记录的验证或人工确认不会因为正文编辑自动失效，修改约束后应重新检查这些结果。资源类型、来源和名称共同构成身份，因此同名技能和规则不会混淆。缺失的必需资源会阻止新任务创建；已完成任务若需返工，使用 `revise` 显式重开。
 
 下一步：[资源安装](resource-install.md) · [常见问题](faq.md)

package/docs/development.md

@@ -25,7 +25,7 @@ CI 在 Windows 的 Node 22/24 上运行。每次功能修改选择相关验证
 | 位置 | 职责 |
 | :--- | :--- |
 | [src/engine.ts](../src/engine.ts) | 状态机、阶段条件和提交规则检查。 |
-| [src/workflows.ts](../src/workflows.ts) | 三套流程骨架及可选的推荐配置。 |
+| [src/workflows.ts](../src/workflows.ts) | 三套流程骨架及可选的推荐配置。 |
 | [src/dev-task.ts](../src/dev-task.ts) | 模型使用的 dev_task 工具与任务文件操作。 |
 | [src/controller.ts](../src/controller.ts) | 工作台读取配置、任务和资源的 Remote 控制器。 |
 | [src/resource-import.ts](../src/resource-import.ts) | 导入校验、安装预览、独占写入与失败清理。 |

package/docs/faq.md

@@ -10,13 +10,13 @@
 
 安装会添加工作台，但任务工具只在挂载插件 agent 的会话预设中启用。新建会话时选择“工程化开发引擎”，再检查工具是否可用。工作台中的“标准研发”等选项是任务流程，不能代替会话预设开关。
 
-## 能自己增删流程阶段吗？
-
-不支持，且**不打算支持**。可以选择三个内置流程（`standard`、`agile`、`minimal`）并为阶段追加资源，但阶段与条件本身固定。让使用者自行设计流程会把流程设计的负担转嫁给使用者，而内置流程已覆盖个人项目的常见需要。详见[功能规划](roadmap.md)。
+## 能自己增删流程阶段吗？
+
+当前工作台不提供任意编辑阶段图。按每个需求的复杂度选择低、中、高、超高四档任务流程，并允许为元技能挂载 Skill；旧版 `standard`、`agile`、`minimal` 继续兼容。详见[自适应工程任务](adaptive-workflows.md)。
 
 ## 安装资源后就会自动使用吗？
 
-还需要为技能配置规则，再到“流程配置”选择阶段并挂载技能。任务执行时按阶段披露对应内容；安装行为本身不会执行资源中的脚本。
+还需要为技能配置规则，并在「自适应流程」把它挂到元技能；旧版流程则在「旧版流程」挂到阶段。任务执行时按阶段披露对应内容；安装行为本身不会执行资源中的脚本。
 
 ## 改了流程，原来的任务会变化吗？
 
@@ -24,11 +24,19 @@
 
 ## 能移除推荐技能、修改内置规则吗？
 
-流程预设没有强制技能绑定。当前安装包只保留会话编排技能 `eng-delivery`，不再附带业务技能和规则；它只负责按 `dev_task` 的状态与门禁编排，不决定业务方法。用户的业务技能可建在项目 `.dsh/skills`，也可使用同项目 `.agents/skills` 中已有的 Codex 技能；规则仍由用户配置在技能下。不同来源的同名资源分别引用。
+旧流程没有强制技能绑定。插件内置会话编排 Skill `eng-delivery` 与六个通用元技能；它不内置项目业务规则。项目同名 Skill 覆盖用户同名 Skill，并使用项目 Skill 自己挂载的 Rule。用户的业务技能可建在项目 `.dsh/skills`，也可使用同项目 `.agents/skills` 中已有的技能。
+
+## 不使用 SonarQube 要怎么做？
+
+「自适应流程」中保持 SonarQube 开关关闭即可，不需要服务器地址或 Token。代码审核元技能仍会执行；已创建任务保留创建时冻结的设置。
+
+## 为什么 SonarQube 审核与分支有关？必须先提交吗？
+
+分支或合并请求用于定位 SonarQube 服务端存储的分析结果，并不意味着审核前必须提交。当前插件复用 CI 扫描，因而要先提交并推送代码给 CI；它尚不支持对未提交代码执行 Sonar 审核。SonarQube for IDE Connected Mode 能在本地用服务端支持的规则检查未提交代码，但本地分析并不等于完整的服务器 Quality Gate。详见[当前接入说明](adaptive-workflows.md#分支提交与当前限制)。
 
 ## 工具显示验证或审核通过，能完全相信吗？
 
-新建任务的验证需要真实命令回执，要求退出码为 0 且未超时、中止或被沙箱拒绝；代码修改后需重验。技能按配置记录加载情况及所需的命令、产物、审核或人工批准证据；审核和实施项结论仍需判断。命令覆盖是否充分、审核是否准确仍需判断，不能把一个成功退出码当作全部需求已验证。
+新建任务的验证需要真实命令回执，要求退出码为 0 且未超时、中止或被沙箱拒绝；代码修改后需重验。技能按配置记录加载情况及所需的命令、产物、审核或人工批准证据；审核和实施项结论仍需判断。命令覆盖是否充分、审核是否准确仍需判断，不能把一个成功退出码当作全部需求已验证。
 
 ## 验证命令被沙箱阻止怎么办？
 

package/docs/getting-started.md

@@ -2,7 +2,9 @@
 
 [← 文档导航](README.md)
 
-本指南适用于已在本机使用 DeepSeek Harness 的用户。安装后，你会获得一个“工程流程”工作台和一个“工程化开发引擎”会话预设。
+本指南适用于已在本机使用 DeepSeek Harness 的用户。安装后，你会获得一个“工程任务”工作台和一个“工程化开发引擎”会话预设。
+
+下面的 npm 安装命令获取最新发布版；`0.29.0` 起包含四档流程、项目 Skill/Rule 初始化与可选 SonarQube CI 审核。
 
 ## 1. 安装插件
 
@@ -27,7 +29,7 @@ pnpm dsh web --no-open
 
 重启后检查两个位置：
 
-- 侧边栏出现 **工程流程**，打开后可以选择工作区。
+- 侧边栏出现 **工程任务**，打开后可以选择工作区。
 - 新建会话时，可以选择 **工程化开发引擎**。
 
 没有看到入口时，先确认安装和启动使用的是同一个 profile，再检查启动日志中的插件加载错误。命令报找不到 pnpm 时，需要先准备好 pnpm 环境。
@@ -35,8 +37,8 @@ pnpm dsh web --no-open
 ## 3. 配置第一个项目
 
 1. 在工作台顶部选择工作区。
-2. 进入“流程配置”，按任务复杂程度选择标准研发、敏捷轻量或纯代码。
-3. 如需自己的技能或规则，在对应页面安装，再回到流程配置挂载到阶段。
+2. 在「自适应流程」页查看四档路径；旧项目可在「旧版流程」继续维护原预设。
+3. 如需自己的技能或规则，在对应页面安装，再挂载到元技能或旧版阶段。
 4. 保存配置，在使用“工程化开发引擎”预设的会话中描述任务。
 
 后续在“任务台账”查看阶段、实施项与验证审核记录。项目初始化会管理根目录的 `AGENTS.md`：先查看或生成草稿，再确认保存。
@@ -46,7 +48,8 @@ pnpm dsh web --no-open
 | 位置 | 决定什么 |
 | :--- | :--- |
 | 会话中的“工程化开发引擎” | 是否启用 `dev_task`、配套技能和工程人设。 |
-| 工作台中的三个流程预设 | 任务经过哪些阶段、每一步需要满足什么条件。 |
+| 四档自适应流程 | 每个新需求按复杂度独立选择阶段与门禁。 |
+| 三个旧流程预设 | 沿用项目 `.dsh/eng.json` 中的阶段与门禁。 |
 
 如果切换到未挂载插件 agent 的其他会话预设，该会话不会启用这套任务工具；侧边栏工作台仍可使用。