@godv61/dsh-task-engine 0.29.3 → 0.30.0

package/docs/configuration.md

@@ -1,80 +0,0 @@
-# 旧版流程配置
-
-[← 文档导航](README.md)
-
-本页描述兼容保留的 `standard`、`agile`、`minimal` 与 `.dsh/eng.json`。新任务可按需求选择四档自适应流程，元技能挂载和可选 SonarQube 位于 `.dsh/meta.json`；见[自适应工程任务](adaptive-workflows.md)。旧任务继续按自己的快照执行。
-
-## 选择流程
-
-| flow | 阶段 | 主要特点 |
-| :--- | :--- | :--- |
-| `standard` | 需求评审 → 设计 → 开发 → 交付 → 代码审核 → 完成 | 包含确认、产物、验证、审核与文件范围检查，支持高风险任务。 |
-| `agile` | 需求 → 开发 → 交付 → 审查 | 减少阶段与产物要求，不支持高风险任务。 |
-| `minimal` | 开发 → 交付 | 精简为实施项完成和提交检查点，不支持高风险任务。 |
-
-项目没有配置文件时使用 `standard`；配置文件存在但 flow 缺失或无效时会报错，不会自动忽略错误。
-
-## 技能与规则
-
-最小配置如下：
-
-```json
-{
-  "flow": "standard"
-}
-```
-
-`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_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 规则。
-
-[最小配置示例](../defaults/eng.json)仅选择流程，不绑定技能或规则。
-
-**预设不带任何绑定。** 一个只写了 `flow` 的配置就是字面意思：节点没有绑定，阶段仍按流程骨架流转。工作台的「采用推荐配置」只填写可修改的提交文本、产物字段和评审深度，不添加或覆盖技能与规则。项目级技能和规则放在 `.dsh/skills/` 与 `.dsh/rules/`；同一份规则可由多个技能引用。
-
-旧版流程的阶段绑定不自动获得业务技能或规则。新流程另外内置六个通用元技能；两种路径都由使用者提供项目业务技能与 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` 列出需要命令回执的技能。
-
-挂在终态(例如"完成")的技能在进入终态前执行。测试技能通常建议挂在"交付";现有"完成"绑定也会在审核阶段执行后才放行。标准流程 v2 在审核通过后提交,并核对真实 Git HEAD。修改文件或声明范围后,旧验证回执失效。
-
-资源管理保留不同来源的同名条目,避免来源误标和误操作。DSH 技能通过 Harness 的 skill 工具加载；Codex 项目技能通过 `dev_task load_skill` 按来源和任务读取。
-
-### 旧配置迁移
-
-旧配置把规则写在**节点**下(`"开发": { "rules": [...] }`)。这类规则不记录它属于哪个技能,因此**不会被自动分配**:它们保留在 `legacy_rules` 中,**仍然生效**,同时 `status.unassigned_legacy_rules` 会列出它们等待归属。请把每条规则加到你希望承载它的技能下,再从 `legacy_rules` 中移除;若同一技能在不同节点需要不同规则,复制该技能再分别配置。
-
-## 哪些内容暂时不能修改
-
-阶段顺序、转移条件、产物必填字段和提交策略由所选预设固定。新建规则可以提供工作指引，但不会改变引擎中的提交消息校验或阶段条件。
-
-旧版页面不提供可视化编辑任意阶段图。新的任务级四档路径见[自适应工程任务](adaptive-workflows.md)。
-
-## 配置与正在进行的任务
-
-新任务记录创建时的完整流程快照，后续按该快照执行。修改项目配置影响之后创建的任务，不会自动迁移进行中的任务。
-
-任务开始时会保存所引用技能和规则正文的**审计副本**，但运行时按原来的来源与名称重新读取：项目级资源可随时编辑，同项目的其他会话及进行中的任务在下一次交互读取最新正文；用户级资源在所有项目和会话中同理。状态机会继续使用任务创建时的流程快照。正文变化会在 `status` 中提示；删除仍被绑定的资源会阻止阶段流转。已记录的验证或人工确认不会因为正文编辑自动失效，修改约束后应重新检查这些结果。资源类型、来源和名称共同构成身份，因此同名技能和规则不会混淆。缺失的必需资源会阻止新任务创建；已完成任务若需返工，使用 `revise` 显式重开。
-
-下一步：[资源安装](resource-install.md) · [常见问题](faq.md)

package/docs/faq.md

@@ -1,59 +0,0 @@
-# 常见问题
-
-[← 文档导航](README.md)
-
-## 这是服务器产品吗？
-
-本项目面向本机个人工作台。日常使用重点是选对工作区、明确操作目标、保护现有文件和保留任务记录；多用户服务器的会话权限隔离不属于当前产品的必修项。
-
-## 为什么安装了插件，聊天里没有 dev_task？
-
-安装会添加工作台，但任务工具只在挂载插件 agent 的会话预设中启用。新建会话时选择“工程化开发引擎”，再检查工具是否可用。工作台中的“标准研发”等选项是任务流程，不能代替会话预设开关。
-
-## 项目 Skill/Rule 的 init 在哪里？
-
-进入工作台“项目初始化”页，复制“项目 Skill / Rule 初始化”请求，在项目根工作区的“工程化开发引擎”会话中发送。模型会用 `dev_task init_project` 先扫描和预览，确认后才写入。页面下方的 `AGENTS.md` 生成是独立功能。“自适应流程”页顶部也有直达入口。Web 服务升级后若旧页面按钮无响应，请刷新页面。
-
-## 能自己增删流程阶段吗？
-
-当前工作台不提供任意编辑阶段图。按每个需求的复杂度选择低、中、高、超高四档任务流程，并允许为元技能挂载 Skill；旧版 `standard`、`agile`、`minimal` 继续兼容。详见[自适应工程任务](adaptive-workflows.md)。
-
-## 安装资源后就会自动使用吗？
-
-还需要为技能配置规则，并在「自适应流程」把它挂到元技能。内置核心 Skill 也可直接点“配置核心 Skill 的 Rule”：保存时创建同名项目 Skill，再挂载所选规则。任务执行时按阶段披露对应内容；安装行为本身不会执行资源中的脚本。
-
-## 改了流程，原来的任务会变化吗？
-
-任务保存创建时的流程快照。修改项目配置不会自动改变进行中的任务；新任务使用保存后的配置。
-
-## 能移除推荐技能、修改内置规则吗？
-
-旧流程没有强制技能绑定。插件内置会话编排 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 且未超时、中止或被沙箱拒绝；代码修改后需重验。技能按配置记录加载情况及所需的命令、产物、审核或人工批准证据；审核和实施项结论仍需判断。命令覆盖是否充分、审核是否准确仍需判断，不能把一个成功退出码当作全部需求已验证。
-
-## 验证命令被沙箱阻止怎么办？
-
-`verify` 和 `skill_result` 默认使用会话沙箱策略。原命令因权限受阻时，可携带 `sandbox_permissions: "danger-full-access"` 与 `justification` 申请单次重试；审批显示实际命令，批准后才执行，不改变后续调用的会话权限。拒绝、取消或缺少审批服务均不运行命令、不写入回执。不要用另一条简单命令替代原验收。详见验证技能说明。
-
-## 本地提交钩子有什么作用？
-
-它在普通 git commit 时检查任务、阶段、消息和文件范围。`--no-verify`、替换 hooksPath 或直接修改本地数据仍可能绕过检查；项目需要更强的提交约束时，应结合自己的 CI 和人工审核。
-
-## hash 和版本号能防止任意篡改吗？
-
-hash 检查流程快照是否与保存的摘要一致，文件版本检查阻止并发覆盖。任务 JSON 没有签名，具有文件修改权限的人可以同时修改内容与摘要；它们不提供独立防篡改认证。
-
-## 为什么 GitHub 上的 HTML 手册显示源码？
-
-GitHub 文件页不会直接作为网页运行 HTML。下载 [manual.html](manual.html) 后用浏览器打开，或先阅读本站点内的 Markdown 指南。

package/docs/getting-started.md

@@ -1,55 +0,0 @@
-# 安装与启用
-
-[← 文档导航](README.md)
-
-本指南适用于已在本机使用 DeepSeek Harness 的用户。安装后，你会获得一个“工程任务”工作台和一个“工程化开发引擎”会话预设。
-
-下面的 npm 安装命令获取最新发布版；`0.29.0` 起包含四档流程、项目 Skill/Rule 初始化与可选 SonarQube CI 审核。
-
-## 1. 安装插件
-
-确认 pnpm 可用，将插件添加到所用的 Web profile。以下命令使用 `web`。
-
-```sh
-dsh plugin --profile web add @godv61/dsh-task-engine
-```
-
-如果你正在 Harness 源码目录开发，使用：
-
-```sh
-pnpm dsh plugin --profile web add @godv61/dsh-task-engine
-pnpm dsh web --no-open
-```
-
-不写版本号会安装 npm 上的 `latest`；需要固定版本时再追加 `@<版本>`。
-
-已有 Web 进程时，先关闭该进程再启动，避免端口冲突。通过 `dsh plugin` 安装会将插件加入对应 profile；仅在任意目录执行 `npm install` 不会完成工作台挂载。
-
-## 2. 检查安装结果
-
-重启后检查两个位置：
-
-- 侧边栏出现 **工程任务**，打开后可以选择工作区。
-- 新建会话时，可以选择 **工程化开发引擎**。
-
-没有看到入口时，先确认安装和启动使用的是同一个 profile，再检查启动日志中的插件加载错误。命令报找不到 pnpm 时，需要先准备好 pnpm 环境。
-
-## 3. 配置第一个项目
-
-1. 在工作台顶部选择工作区。
-2. 在「自适应流程」页查看四档路径，并按需设置 SonarQube 审核。
-3. 如需自己的技能或规则，在对应页面安装，再挂载到元技能；内置核心 Skill 可在配置 Rule 时复制为同名项目 Skill。
-4. 保存配置，在使用“工程化开发引擎”预设的会话中描述任务。
-
-后续在“任务台账”查看阶段、实施项与验证审核记录。“项目初始化”页分为两部分：项目 Skill/Rule 初始化先复制请求到工程化开发引擎会话，由 `dev_task init_project` 执行扫描、预览、确认后应用；`AGENTS.md` 可直接在页面生成草稿并确认保存。
-
-## 两种预设的区别
-
-| 位置 | 决定什么 |
-| :--- | :--- |
-| 会话中的“工程化开发引擎” | 是否启用 `dev_task`、配套技能和工程人设。 |
-| 四档自适应流程 | 每个新需求按复杂度独立选择阶段与门禁。 |
-
-如果切换到未挂载插件 agent 的其他会话预设，该会话不会启用这套任务工具；侧边栏工作台仍可使用。
-
-下一步：[自适应流程](adaptive-workflows.md) · [安装资源](resource-install.md) · [常见问题](faq.md)

package/docs/listing/godv61__dsh-task-engine.yml

@@ -1,6 +0,0 @@
-url: https://github.com/godv61/dsh-task-engine
-name: godv61/dsh-task-engine
-category: workflow
-description:
-  en: 'Preset engineering workflows for DeepSeek Harness: a dev_task tool that gates stage transitions, artifacts, verification, review and commit scope, plus a web workbench for installing project or user skills and rules.'
-  zh: '为 DeepSeek Harness 提供预设工程流程：dev_task 工具把阶段流转、产物、验证、审核与提交范围做成硬门禁，并带一个安装项目级与个人级技能和规则的工作台。'

package/docs/listing/submission.md

@@ -1,84 +0,0 @@
-# 插件收录申请
-
-**已收录：** [PR #5681](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/5681)
-于 2026-09-22 15:45:57 UTC 被维护者 `fkysly` 合并，**无修改要求**（0 条评审评论）。
-条目已在列表的 `main` 上，中英两个 README 均已生成对应行。
-
-提交时 `check`（7m40s）与 `Submission gate` 两项 CI 全部通过。PR 只新增
-`data/plugins/godv61__dsh-task-engine.yml`（+6 行），未触碰生成出来的 README。
-
-条目页：[awesome-dsh-plugin.com](https://awesome-dsh-plugin.com)
-
-目标：[awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)。
-
-## 提交内容
-
-按[贡献指南](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/blob/main/contributing.md)，
-PR **只新增一个文件**：`data/plugins/godv61__dsh-task-engine.yml`，内容复制本目录同名 YAML。
-
-**标题：** `Add godv61/dsh-task-engine`
-
-**分类：** `workflow` —— 插件本身提供工程流程预设与阶段门禁，分类与实际行为一致。
-
-> 注意：`data/plugins/` 下的条目文件是数据源，仓库根的两个 README 由脚本生成。
-> **不要手工编辑 README**，也不要往 `data/screenshots.json` 加键（新约定是插件仓库自己放 `screenshots.json`）。
-
-## PR 正文
-
-> Adds `godv61/dsh-task-engine` under `workflow`.
->
-> The plugin adds a `dev_task` tool that holds an engineering state machine: three preset flows
-> (`standard`, `agile`, `minimal`) with transitions gated on human confirmation, artifact
-> completeness, implementation items, real verification receipts, and review outcome — plus a
-> commit gate that checks stage, message format and file scope. A web workbench installs project- or
-> user-level skills and rules, binds them to individual stages, and shows the task ledger.
->
-> Repository includes source, a `dsh.bundle` manifest with `cordis.patch.yml`, user documentation,
-> and a test suite (146 P0 assertions, 52 `node:test` cases including an end-to-end commit-hook
-> suite). Published on npm; `repository` points back at this repo.
-
-## 提交前的自查（对照指南逐条）
-
-| 指南要求 | 本仓库状态 |
-| :--- | :--- |
-| `package.json` 声明 `dsh.bundle` | ✅ `"bundle": { "patch": "./cordis.patch.yml" }` |
-| 仓库根有 `cordis.patch.yml` | ✅ |
-| 真实可用代码（非占位/纯 README） | ✅ host 与 client 两个面均已实现并有测试 |
-| 仓库创建满 1 天 | ✅ 创建于 2026-09-15 08:10:50 UTC |
-| 已有 `dsh-plugin` topic | ✅ |
-| 活跃维护 | ✅ |
-| `repository` 指回本仓库 | ✅ `git+https://github.com/godv61/dsh-task-engine.git` |
-| npm 包 `repository` 回指同一仓库 | ✅ |
-| 非纯聚合包（自带行为） | ✅ 自带 `dev_task` 工具与工作台 UI |
-| 描述不含 `: `（冒号+空格） | ✅ 已加引号 |
-| 官方包用 `peerDependencies` | ✅ `@deepseek-ai/dsh-*` 均在 peer 中 |
-| peer 范围带显式预发布分支 | ✅ `^0.1.2-rc.1 \|\| ^0.1.3-alpha.1 \|\| ^0.1.6-alpha.2 \|\| ^0.1.7-alpha.1` |
-
-**关于 peer 范围**：指南特别警告过「不带显式预发布分支的范围会静默排除 harness 的预发布构建」。
-本插件用的是显式 `||` 分支形式，正是指南推荐写法。
-
-## 描述准确性
-
-指南说明描述会被**当作对代码的声明并逐句核对**，因此上面那行只写了可验证的事实：
-
-| 描述中的说法 | 代码依据 |
-| :--- | :--- |
-| `dev_task` 工具 | `src/dev-task.ts` 的 `defineTool` |
-| 阶段流转门禁 | `src/engine.ts` 的 `assertAdvance` / `legalTargets` |
-| 产物门禁 | guard `artifacts_present` + `ArtifactDef` |
-| 验证门禁 | guard `verified` + 真实命令回执 |
-| 审核门禁 | guard `review_passed` |
-| 提交范围校验 | `checkFileScope` + `hooks/commit-msg` |
-| 三个预设流程 | `FLOW_OPTIONS`：`standard` / `agile` / `minimal` |
-| 工作台安装技能与规则 | `src/client/` 的 `ResourceManager` 等 |
-
-**描述里刻意不写具体数字**（如「7 个技能、3 条规则」）：这类数字会随版本变化，
-写死反而容易变成不准确声明。
-
-## 备注
-
-本目录此前一份材料提到「仓库创建满 24 小时」与手工核对 `created_at`。指南现已说明
-**该门槛由 CI 自动检查**，无需在 PR 里论证，故此处不再展开。
-
-截图可选：可在本仓库根放 `screenshots.json` 声明，市场会自动读取，无需在本列表仓库提交图片。
-当前未声明，市场会从 README 自动抽取。