@godv61/dsh-task-engine 0.29.3 → 0.29.8

package/docs/adaptive-workflows.md

@@ -1,76 +1,88 @@
-# 自适应工程任务
-
-本页描述 `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",
+# 自适应工程任务
+
+本页描述任务级流程。可选 SonarQube 审核支持 CI 结果、上传式本机扫描，以及在未提交工作区运行的本地规则审核。
+
+旧 `.dsh/eng.json` 与已创建任务的快照继续可读，工作台不再提供旧版流程配置页。新需求在工程化会话中先评估复杂度，调用 `dev_task assess` 预览，再用 `create` 的 `complexity` 与 `complexity_reason` 创建任务。复杂度由需求范围和实现依赖决定，`risk_level` 单独判断。
+
+| 复杂度 | 适用情形 | 元技能顺序 |
+| :--- | :--- | :--- |
+| 低 `low` | 边界明确的局部修改 | 代码开发 → 测试 → 代码审核 → 完成 |
+| 中 `medium` | 常规功能或缺陷修复 | 需求分析 → 代码开发 → 测试 → 代码审核 → 完成 |
+| 高 `high` | 跨模块或存在实现依赖 | 需求分析 → 任务编排 → 代码开发 → 测试 → 代码审核 → 完成 |
+| 超高 `ultra` | 完整新模块或大范围重构 | 需求分析 → 架构设计 → 任务编排 → 代码开发 → 测试 → 代码审核 → 完成 |
+
+高档的任务编排按实现先后拆解，记录每步依赖、完成判据和交接产物；它不按人员或分支分发。`task-plan.steps` 中每项应单独起行并以稳定 ID 开头（例如 `- I1 数据模型`），`dev_task items` 必须登记相同的全部 ID；缺项不能进入代码开发。超高档的架构设计记录模块边界、接口和取舍，不默认要求迁移或回退演练。每档的测试要有实际命令回执，审核要有通过结论；低档每项一次审核，其余档对需求符合性和质量分别记录。CI 与上传式本机扫描在测试后提交；本地规则审核先检查未提交代码，再于代码审核通过后提交。
+
+任务台账中的“已开始”是实施项进入执行的记录，可由当前会话直接完成，不表示一定派给子代理。“待审查”指该实施项缺少规格/质量审查，和最后的整项代码审核阶段不同。实施项列表重排时，已完成或有开始/审查记录的项仍保留在台账。
+
+## 元技能交接契约
+
+| 元技能 | 输入 | 交接产物 |
+| :--- | :--- | :--- |
+| 需求分析 | 用户诉求、代码库现状 | 目标、范围、可验证的验收条件 |
+| 架构设计 | 已明确的需求与现有结构 | 模块边界、接口变化、主要取舍 |
+| 任务编排 | 需求、必要的架构决定 | 按先后顺序的实施项、依赖、每步完成判据与交接 |
+| 代码开发 | 上述产物、项目 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 覆盖。扫描结果只提供证据，旧代码中的偶发写法不能自动成为团队规则。`*-project-map` 要总结整个仓库的模块职责、依赖和通用导航，供不同需求复用；当前需求的专属调用链放在任务产物或单独命名的领域 Skill。插件会拒绝遗漏扫描发现的主要模块或构建清单的地图草稿，并在仓库结构变化后要求重新预览；这不能代替人检查正文事实。应用结果中的团队配置文件应纳入 Git，供其他分支和成员使用。
+
+## 可选 SonarQube 审核
+
+不需要 SonarQube 的项目保持工作台「自适应流程」里的开关关闭，或不在 `.dsh/meta.json` 写 `sonar`。不需要配置 Token，代码审核仍按审核元技能和项目 Rule 执行。
+
+需要使用的项目，在工作台打开 SonarQube 开关，填写服务地址、项目 Key、扫描来源及分析对象，并保存。Token 可直接在同页输入并单独保存；插件调用 DSH 本机凭据存储，按项目工作区隔离，页面只显示是否已配置，不回显 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 的最新扫描重新审核，避免把旧结果当成当前代码。
-
+    "source": "ide-local",
+    "reference_branch": "main",
+    "include_paths": ["backend", "pom.xml"],
+    "token_env": "SONAR_TOKEN"
+  }
+}
+```
+
+Token 首选从本机 DSH 凭据存储按项目读取；没有保存时兼容 `token_env` 指定的服务进程环境变量。它不写入项目配置或任务台账，切换项目不会串用。DSH 的本地凭据提供方使用仅当前操作系统用户可读的本机文件持久化，重启后仍可用；它不向同一用户运行的其他程序提供隔离。功能测试通过后，到“代码审核”调用 `dev_task sonar_check`。`source=ide-local` 同步项目 Quality Profile，用独立的 SonarLint 后台检查当前任务登记文件中、相对本机 Git 参考分支新增或修改的 Java、JS/TS、Vue、CSS、HTML 和 XML 代码行；`include_paths` 可限定项目相对目录或文件，留空则使用任务登记的全部代码。它不需要提交、推送、CE task ID，也不上传分析。本地中高级问题会阻止审核通过；对本地分析器不支持的语言，只有该项目服务端 Quality Profile 存在生效规则时才标为未覆盖并阻止通过。此结果不代表服务端 Quality Gate。审核通过后，在“代码审核”检查点提交。`source=ci` 先在“测试”检查点提交并推送，传入 CI 的 `ceTaskId`；`source=local` 也先提交，但由本机 SonarScanner 上传并等待 Compute Engine。后两种方式只依据新代码问题和 `new_*` Gate 条件阻断，旧代码导致的整体 Gate 状态单独展示。代码变化后须重新测试和审核。
+
+Quality Profile 决定规则，CI 构建与扫描参数决定分析哪些目录，两者不是同一项配置。QMS 当前服务端分析索引只有 Java 与 XML 的后端文件，即使服务端还存在 JavaScript Quality Profile，本地审核也应通过 `include_paths` 对齐后端模块。使用者可在当前项目工作台的「任务台账」展开任务的“最近一次 SonarQube 审核”，查看通过状态、阻断数量、每条规则及文件行号。每次 `sonar_check` 在项目 `.dsh/reviews/<任务 ID>/` 生成一份 Markdown 文件，任务台账显示文件路径；完整结构化结果仍在 `.dsh/task-<任务 ID>.json` 的 `sonar_audit` 字段。两处均不写 Token。报告目录可加入项目 `.gitignore`。代码或 Skill/Rule 改动后，需要重新测试并再次运行 `dev_task sonar_check`。
+
+本地规则审核需预先提供 SonarLint 后台组件及其所需 Java 运行时路径。设置 DSH 服务进程环境变量 `DSH_SONARLINT_JAVA`（Java 可执行文件）、`DSH_SONARLINT_LIB`（包含后台 JAR 的目录）和 `DSH_SONARLINT_PLUGINS`（内置分析器 JAR 路径；Windows 多个路径以分号分隔），然后重启 DSH。此路径可以指向独立安装的组件；无需启动 IDEA，也不要求把项目的 JDK 8 升级为分析器使用的 Java 版本。JavaScript、TypeScript、Vue 与 CSS 分析还需本机 Node.js。当前实现未覆盖 SQL 等其他代码扩展名；它会查询该项目的服务端 Quality Profile，只有相应语言存在生效规则时才把此类文件列为未覆盖。QMS 项目目前没有 SQL 语言的 Quality Profile，因此 SQL 迁移文件不构成 Sonar 阻断，但仍需单独完成数据库验证。部分服务端规则本来就不能在 SonarLint 本地执行；本地检查也没有服务端 Quality Gate、跨文件语义和完整构建依赖的同等保证。需要与服务端完全一致的结论时，使用 CI 扫描。
+
+本机扫描只支持分支模式，要求 SonarQube Server Developer Edition 或更高版本；Community Build 只能保存主分支分析，插件会在上传前拒绝。`reference_branch` 必须已在该 Sonar 项目中分析过，且不能等于当前任务分支。参考分支决定 Sonar 对“新代码”的定义；它不是“本次任务涉及的文件”过滤器。任务分支的 HEAD 必须与记录的提交一致，工作区除 `.dsh` 任务记录外不能有未提交文件。本机需要安装 Maven 或 SonarScanner 并能访问 Sonar 服务。默认有根 `pom.xml` 时运行固定版本 Maven Sonar 插件，否则运行 `sonar-scanner`。复杂项目可在页面配置 `scan_command`（例如 Maven 命令及项目所需的 `-DskipTests` 等参数）；只允许单条 Maven 或 SonarScanner 命令，不接受 Shell 运算符和 Token 参数。插件追加项目 Key、分支、参考分支和结果文件参数，通过子进程环境传入 Token，不会执行 `git push`。本机扫描会更新 Sonar 服务端同名分支的分析结果；团队共用分支应优先使用个人本地分支进行试验。
+
+CI 模式建议保存扫描产生的 `report-task.txt` 为制品，方便取得 `ceTaskId`。如果 CI 已配置 `sonar.qualitygate.wait=true`，它可以继续作为 CI 门禁；插件读取分析结果，不重复运行扫描。Sonar 只需针对所选任务实际扫描的分支或合并请求配置 `mode`，具体 CI 触发条件由项目自行决定。分支/MR 最新问题列表与指定 `analysisId` 的门禁分别来自 SonarQube API；如果同一分支同时运行多次扫描，应按最新扫描重新审核，避免把旧结果当成当前代码。
+
 失败案例可以用 `dev_task learn_rule phase=propose` 生成项目 Rule 预览，注明 Sonar issue key、可复用原因和正确写法；审阅后用 `phase=apply` 写入项目 Rule 并挂到对应项目代码 Skill。它只影响未来任务，不能把一次误报或整个 Quality Profile 自动复制成规则。
-
+`sonar_check` 与 `status` 会按 Sonar 规则列出尚未沉淀的阻断案例；这只是候选清单。先核实是否为真实问题，再把有普遍价值的修复提炼成 Rule，并把生成的 `.dsh/rules/`、`.dsh/skills/` 和 `.dsh/meta.json` 作为团队配置纳入 Git。每次初始化时，项目地图至少要涵盖扫描发现的主要模块与构建清单；插件会拒绝遗漏模块的草稿，仍需人工核对职责、依赖和事实。
+
 ### 分支、提交与当前限制
-
-SonarQube 服务端把分析结果放在项目的某个分支或合并请求下，插件以它定位要查询的问题。分支是结果的命名空间，**不是审核前必须提交的技术要求**。本版要求先提交，是因为它选择复用 CI：CI 扫描已推送的代码，插件随后读取结果。这与“功能通过后先审核未提交代码，修复通过再提交”的目标不一致。
-
-SonarQube for IDE 的 Connected Mode 可以对本地未提交代码应用服务端 Quality Profile 中受支持的规则；本地分析不能代表完整的服务端 Quality Gate，部分复杂规则只在服务端分析时运行。本插件当前没有接入 IDE 的本地分析，也没有提供未提交代码的 Sonar 审核。因此需要提交前 Sonar 审核的团队，暂时不能把本版 `sonar_check` 当作该门禁。未来应把提交前本地检查和提交后 CI Quality Gate 分开设计，并明确两者覆盖范围。
+
+SonarQube 服务端把上传式分析结果放在项目的某个分支或合并请求下，插件以它定位要查询的问题。`ide-local` 的参考分支只用于本机 Git 差异，不在 Sonar 服务端创建新分支分析；因此它可在首次提交之前审核未提交文件，也适用于 Community Build。
+
+`ide-local` 采用与 SonarQube for IDE 相同的本地分析后台，对未提交代码应用服务端 Quality Profile 中受支持的规则。`local` 是另外一条上传式扫描路径，要求 SonarQube 支持分支分析、参考分支已有分析，以及本机扫描器和构建环境可用。任一前提缺失时审核会报错。CI 模式继续承担推送后的完整验证。

package/docs/configuration.md

@@ -1,8 +1,8 @@
-# 旧版流程配置
+# 旧版流程配置
 
 [← 文档导航](README.md)
 
-本页描述兼容保留的 `standard`、`agile`、`minimal` 与 `.dsh/eng.json`。新任务可按需求选择四档自适应流程，元技能挂载和可选 SonarQube 位于 `.dsh/meta.json`；见[自适应工程任务](adaptive-workflows.md)。旧任务继续按自己的快照执行。
+本页描述兼容保留的 `standard`、`agile`、`minimal` 与 `.dsh/eng.json`。新任务可按需求选择四档自适应流程，元技能挂载和可选 SonarQube 位于 `.dsh/meta.json`；见[自适应工程任务](adaptive-workflows.md)。旧任务继续按自己的快照执行。
 
 ## 选择流程
 
@@ -53,7 +53,7 @@
 
 **预设不带任何绑定。** 一个只写了 `flow` 的配置就是字面意思：节点没有绑定，阶段仍按流程骨架流转。工作台的「采用推荐配置」只填写可修改的提交文本、产物字段和评审深度，不添加或覆盖技能与规则。项目级技能和规则放在 `.dsh/skills/` 与 `.dsh/rules/`；同一份规则可由多个技能引用。
 
-旧版流程的阶段绑定不自动获得业务技能或规则。新流程另外内置六个通用元技能；两种路径都由使用者提供项目业务技能与 Rule。工作台可以安装或新建项目级、用户级资源。
+旧版流程的阶段绑定不自动获得业务技能或规则。新流程另外内置六个通用元技能；两种路径都由使用者提供项目业务技能与 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` 列出需要命令回执的技能。
 
@@ -69,7 +69,7 @@
 
 阶段顺序、转移条件、产物必填字段和提交策略由所选预设固定。新建规则可以提供工作指引，但不会改变引擎中的提交消息校验或阶段条件。
 
-旧版页面不提供可视化编辑任意阶段图。新的任务级四档路径见[自适应工程任务](adaptive-workflows.md)。
+旧版页面不提供可视化编辑任意阶段图。新的任务级四档路径见[自适应工程任务](adaptive-workflows.md)。
 
 ## 配置与正在进行的任务
 

package/docs/faq.md

@@ -6,37 +6,43 @@
 
 本项目面向本机个人工作台。日常使用重点是选对工作区、明确操作目标、保护现有文件和保留任务记录；多用户服务器的会话权限隔离不属于当前产品的必修项。
 
-## 为什么安装了插件，聊天里没有 dev_task？
-
-安装会添加工作台，但任务工具只在挂载插件 agent 的会话预设中启用。新建会话时选择“工程化开发引擎”，再检查工具是否可用。工作台中的“标准研发”等选项是任务流程，不能代替会话预设开关。
-
-## 项目 Skill/Rule 的 init 在哪里？
-
-进入工作台“项目初始化”页，复制“项目 Skill / Rule 初始化”请求，在项目根工作区的“工程化开发引擎”会话中发送。模型会用 `dev_task init_project` 先扫描和预览，确认后才写入。页面下方的 `AGENTS.md` 生成是独立功能。“自适应流程”页顶部也有直达入口。Web 服务升级后若旧页面按钮无响应，请刷新页面。
+## 为什么安装了插件，聊天里没有 dev_task？
+
+安装会添加工作台，但任务工具只在挂载插件 agent 的会话预设中启用。新建会话时选择“工程化开发引擎”，再检查工具是否可用。工作台中的“标准研发”等选项是任务流程，不能代替会话预设开关。
 
-## 能自己增删流程阶段吗？
+## 项目 Skill/Rule 的 init 在哪里？
+
+进入工作台“项目初始化”页，复制“项目 Skill / Rule 初始化”请求，在项目根工作区的“工程化开发引擎”会话中发送。模型会用 `dev_task init_project` 先扫描和预览，确认后才写入。页面下方的 `AGENTS.md` 生成是独立功能。“自适应流程”页顶部也有直达入口。Web 服务升级后若旧页面按钮无响应，请刷新页面。
 
-当前工作台不提供任意编辑阶段图。按每个需求的复杂度选择低、中、高、超高四档任务流程，并允许为元技能挂载 Skill；旧版 `standard`、`agile`、`minimal` 继续兼容。详见[自适应工程任务](adaptive-workflows.md)。
+`init_project phase=inspect` 只返回仓库证据和建议的资源名称；Skill/Rule 正文由会话模型拟定，在 `phase=propose` 预览，`phase=apply` 才保存。项目地图应描述整个仓库，不能把当前任务的局部分析当成长期项目地图。
+
+## 能自己增删流程阶段吗？
+
+当前工作台不提供任意编辑阶段图。按每个需求的复杂度选择低、中、高、超高四档任务流程，并允许为元技能挂载 Skill；旧版 `standard`、`agile`、`minimal` 继续兼容。详见[自适应工程任务](adaptive-workflows.md)。
 
 ## 安装资源后就会自动使用吗？
 
-还需要为技能配置规则，并在「自适应流程」把它挂到元技能。内置核心 Skill 也可直接点“配置核心 Skill 的 Rule”：保存时创建同名项目 Skill，再挂载所选规则。任务执行时按阶段披露对应内容；安装行为本身不会执行资源中的脚本。
+还需要为技能配置规则，并在「自适应流程」把它挂到元技能。内置核心 Skill 也可直接点“配置核心 Skill 的 Rule”：保存时创建同名项目 Skill，再挂载所选规则。任务执行时按阶段披露对应内容；安装行为本身不会执行资源中的脚本。
 
 ## 改了流程，原来的任务会变化吗？
 
 任务保存创建时的流程快照。修改项目配置不会自动改变进行中的任务；新任务使用保存后的配置。
 
-## 能移除推荐技能、修改内置规则吗？
-
-旧流程没有强制技能绑定。插件内置会话编排 Skill `eng-delivery` 与六个通用元技能；它不内置项目业务规则。项目同名 Skill 覆盖用户同名 Skill，并使用项目 Skill 自己挂载的 Rule。用户的业务技能可建在项目 `.dsh/skills`，也可使用同项目 `.agents/skills` 中已有的技能。
-
-## 不使用 SonarQube 要怎么做？
+## 能移除推荐技能、修改内置规则吗？
+
+旧流程没有强制技能绑定。插件内置会话编排 Skill `eng-delivery` 与六个通用元技能；它不内置项目业务规则。项目同名 Skill 覆盖用户同名 Skill，并使用项目 Skill 自己挂载的 Rule。用户的业务技能可建在项目 `.dsh/skills`，也可使用同项目 `.agents/skills` 中已有的技能。
+
+## 不使用 SonarQube 要怎么做？
+
+「自适应流程」中保持 SonarQube 开关关闭即可，不需要服务器地址或 Token。代码审核元技能仍会执行；已创建任务保留创建时冻结的设置。
+
+## 为什么 SonarQube 审核与分支有关？必须先提交吗？
 
-「自适应流程」中保持 SonarQube 开关关闭即可，不需要服务器地址或 Token。代码审核元技能仍会执行；已创建任务保留创建时冻结的设置。
+选择“本地规则审核（ide-local）”时，插件会用服务器项目的 Quality Profile 审核本机新增或修改的代码，无需提交或推送；Git 参考提交仅用于划分新代码。选择“CI 结果（ci）”时，需要先提交并推送以取得本次分析的 CE task ID；“上传式本机扫描（local）”需要先提交但无需推送。本地规则审核不等于服务器的完整 Quality Gate。详见[自适应工程任务](adaptive-workflows.md)。
 
-## 为什么 SonarQube 审核与分支有关？必须先提交吗？
+## 为什么任务台账显示待开始或待审查？
 
-分支或合并请求用于定位 SonarQube 服务端存储的分析结果，并不意味着审核前必须提交。当前插件复用 CI 扫描，因而要先提交并推送代码给 CI；它尚不支持对未提交代码执行 Sonar 审核。SonarQube for IDE Connected Mode 能在本地用服务端支持的规则检查未提交代码，但本地分析并不等于完整的服务器 Quality Gate。详见[当前接入说明](adaptive-workflows.md#分支提交与当前限制)。
+实施项是按实现依赖排列的工作步骤，不要求分发给其他人。页面的开始记录表示已进入该实施项，可以由当前会话直接开发；实施项审查记录是规格符合性与代码质量的结论，和最后整个任务的“代码审核”阶段不同。旧版页面把缺少两种记录统一写成“未派发 / 未审查”，容易让人以为必须派给子代理。标成完成但缺少审查记录的实施项不能通过阶段门禁；任务列表更新时，已有完成或审查记录的项目会保留。
 
 ## 工具显示验证或审核通过，能完全相信吗？
 

package/docs/getting-started.md

@@ -2,9 +2,9 @@
 
 [← 文档导航](README.md)
 
-本指南适用于已在本机使用 DeepSeek Harness 的用户。安装后，你会获得一个“工程任务”工作台和一个“工程化开发引擎”会话预设。
-
-下面的 npm 安装命令获取最新发布版；`0.29.0` 起包含四档流程、项目 Skill/Rule 初始化与可选 SonarQube CI 审核。
+本指南适用于已在本机使用 DeepSeek Harness 的用户。安装后，你会获得一个“工程任务”工作台和一个“工程化开发引擎”会话预设。
+
+下面的 npm 安装命令获取最新发布版；`0.29.0` 起包含四档流程、项目 Skill/Rule 初始化与可选 SonarQube 审核。`0.29.8` 增加本地规则审核、逐次 Markdown 报告、项目地图覆盖检查和任务编排完整性门禁；Web profile 安装并重启后才会加载对应版本。
 
 ## 1. 安装插件
 
@@ -29,7 +29,7 @@ pnpm dsh web --no-open
 
 重启后检查两个位置：
 
-- 侧边栏出现 **工程任务**，打开后可以选择工作区。
+- 侧边栏出现 **工程任务**，打开后可以选择工作区。
 - 新建会话时，可以选择 **工程化开发引擎**。
 
 没有看到入口时，先确认安装和启动使用的是同一个 profile，再检查启动日志中的插件加载错误。命令报找不到 pnpm 时，需要先准备好 pnpm 环境。
@@ -37,19 +37,19 @@ pnpm dsh web --no-open
 ## 3. 配置第一个项目
 
 1. 在工作台顶部选择工作区。
-2. 在「自适应流程」页查看四档路径，并按需设置 SonarQube 审核。
-3. 如需自己的技能或规则，在对应页面安装，再挂载到元技能；内置核心 Skill 可在配置 Rule 时复制为同名项目 Skill。
+2. 在「自适应流程」页查看四档路径，并按需设置 SonarQube 审核。启用时保存项目的服务地址、Key、扫描来源和本机 Token；选“本地规则审核”需填写本机 Git 参考分支，并配置 SonarLint 后台运行时路径（见[自适应流程说明](adaptive-workflows.md)）。Token 不写入项目仓库，换项目需配置对应的 Token。
+3. 如需自己的技能或规则，在对应页面安装，再挂载到元技能；内置核心 Skill 可在配置 Rule 时复制为同名项目 Skill。
 4. 保存配置，在使用“工程化开发引擎”预设的会话中描述任务。
 
-后续在“任务台账”查看阶段、实施项与验证审核记录。“项目初始化”页分为两部分：项目 Skill/Rule 初始化先复制请求到工程化开发引擎会话，由 `dev_task init_project` 执行扫描、预览、确认后应用；`AGENTS.md` 可直接在页面生成草稿并确认保存。
+后续在“任务台账”查看阶段、实施项与验证审核记录。“项目初始化”页分为两部分：项目 Skill/Rule 初始化先复制请求到工程化开发引擎会话，由 `dev_task init_project` 执行扫描、预览、确认后应用；`AGENTS.md` 可直接在页面生成草稿并确认保存。
 
 ## 两种预设的区别
 
 | 位置 | 决定什么 |
 | :--- | :--- |
 | 会话中的“工程化开发引擎” | 是否启用 `dev_task`、配套技能和工程人设。 |
-| 四档自适应流程 | 每个新需求按复杂度独立选择阶段与门禁。 |
+| 四档自适应流程 | 每个新需求按复杂度独立选择阶段与门禁。 |
 
 如果切换到未挂载插件 agent 的其他会话预设，该会话不会启用这套任务工具；侧边栏工作台仍可使用。
 
-下一步：[自适应流程](adaptive-workflows.md) · [安装资源](resource-install.md) · [常见问题](faq.md)
+下一步：[自适应流程](adaptive-workflows.md) · [安装资源](resource-install.md) · [常见问题](faq.md)

package/docs/manual-legacy.html

@@ -35,7 +35,7 @@
   <header class="hero">
     <p class="eyebrow">DSH · ENGINEERING DELIVERY ENGINE</p>
     <h1>工程化交付引擎 使用手册</h1>
-    <p class="lead">历史手册：本页保留旧版三流程的操作说明。四档任务流程、元技能和可选 SonarQube 说明请阅读 <a href="manual.html" style="color:#fff">现行 HTML 手册</a>。</p>
+    <p class="lead">历史手册：本页保留旧版三流程的操作说明。四档任务流程、元技能和可选 SonarQube 说明请阅读 <a href="manual.html" style="color:#fff">现行 HTML 手册</a>。</p>
     <div class="badges">
       <span class="badge">流程与工作方法分离</span>
       <span class="badge">standard / agile / minimal</span>