@godv61/dsh-task-engine 0.25.0 → 0.26.0

package/.workflow-test.mjs

@@ -75,6 +75,92 @@ function fixture(stage = '开发', extra = {}, services = {}) {
     state: () => JSON.parse(records.get(join(cwd, '.dsh/task-LIVE-1.json'))) }
 }
 
+test('manual skill evidence is approved by the host without a shell command', async () => {
+  const config = resolveFlow('minimal', { flow: 'minimal', stage_bindings: {
+    '开发': { skills: [{ skill: { source: 'project', name: 'human-check' }, rules: [], evidence: 'manual' }] },
+  } }).config
+  const approvals = []
+  const f = fixture('开发', { flow: { flow: 'minimal', version: 3, config } }, {
+    approval: { request: async request => { approvals.push(request); return 'allowed-once' } },
+  })
+  f.load('human-check')
+  await f.call({ operation: 'skill_result', skill_name: 'human-check', evidence: ['checked by owner'] })
+  assert.equal(f.runs.length, 0)
+  assert.equal(approvals.length, 1)
+  assert.equal(f.state().skill_results['开发']['human-check'].approved, true)
+  assert.deepEqual(JSON.parse(await f.call({ operation: 'status' })).skill_blockers, [])
+  const denied = fixture('开发', { flow: { flow: 'minimal', version: 3, config } }, {
+    approval: { request: async () => 'rejected' },
+  })
+  denied.load('human-check')
+  await assert.rejects(denied.call({ operation: 'skill_result', skill_name: 'human-check', evidence: ['claimed approval'] }), /not approved/)
+  assert.equal(denied.state().skill_results?.['开发']?.['human-check'], undefined)
+})
+
+test('completion rejects unresolved terminal skills and rules', async () => {
+  const config = resolveFlow('minimal', { flow: 'minimal', stage_bindings: {
+    '交付': { skills: [{ skill: { source: 'project', name: 'must-run' }, rules: [{ source: 'project', name: 'missing' }], evidence: 'command' }] },
+  } }).config
+  const f = fixture('交付', {
+    flow: { flow: 'minimal', version: 3, config },
+    items: [{ id: 'A', title: 'small', status: 'done', review: { spec: { outcome: 'pass' }, quality: { outcome: 'pass' } } }],
+    commits: [{ label: 'TASK', hash: 'abcdef1' }],
+  })
+  const status = JSON.parse(await f.call({ operation: 'status' }))
+  assert.ok(status.skill_blockers.length > 0)
+  assert.ok(status.missing_rules.length > 0)
+  await assert.rejects(f.call({ operation: 'complete' }), /cannot complete.*must-run|cannot complete.*missing/)
+  assert.equal(f.state().completed, undefined)
+})
+
+test('same-named skill and rule freeze separately and disclose the rule body', async () => {
+  const f = fixture()
+  f.records.delete(join(f.cwd, '.dsh/task-LIVE-1.json'))
+  f.records.set(join(f.cwd, '.dsh/eng.json'), JSON.stringify({ flow: 'minimal', stage_bindings: {
+    '开发': { skills: [{ skill: { source: 'project', name: 'custom' }, rules: [{ source: 'project', name: 'custom' }], evidence: 'none' }] },
+  } }))
+  f.records.set(join(f.cwd, '.dsh/skills/custom/SKILL.md'), 'SKILL BODY')
+  f.records.set(join(f.cwd, '.dsh/rules/custom.md'), 'RULE BODY')
+  await f.call({ operation: 'create', title: 'collision', branch: 'main', files: ['app.js'] })
+  const resources = f.state().flow.resources.filter(resource => resource.ref.name === 'custom')
+  assert.deepEqual(resources.map(resource => resource.kind).sort(), ['rule', 'skill'])
+  assert.equal(JSON.parse(await f.call({ operation: 'status' })).bindings.rules[0].content, 'RULE BODY')
+  f.records.set(join(f.cwd, '.dsh/skills/custom/SKILL.md'), 'CHANGED SKILL')
+  assert.equal(JSON.parse(await f.call({ operation: 'status' })).bindings.skill_contents[0].content, 'SKILL BODY')
+})
+
+test('task creation applies skill_profiles rules even when legacy inline bindings are empty', async () => {
+  const f = fixture()
+  const skill = { source: 'project', name: 'custom' }
+  const rule = { source: 'project', name: 'my-rule' }
+  f.records.delete(join(f.cwd, '.dsh/task-LIVE-1.json'))
+  f.records.set(join(f.cwd, '.dsh/eng.json'), JSON.stringify({ flow: 'minimal',
+    stage_bindings: {
+      '开发': { skills: [{ skill, rules: [], evidence: 'none' }] },
+      '交付': { skills: [{ skill, rules: [], evidence: 'none' }] },
+    },
+    skill_profiles: { 'project:custom': { rules: [rule], evidence: 'none' } },
+  }))
+  f.records.set(join(f.cwd, '.dsh/skills/custom/SKILL.md'), 'SKILL BODY')
+  await assert.rejects(f.call({ operation: 'create', title: 'profile regression', branch: 'main', files: ['app.js'] }), /rule:project:my-rule/)
+  f.records.set(join(f.cwd, '.dsh/rules/my-rule.md'), 'RULE BODY')
+  await f.call({ operation: 'create', title: 'profile regression', branch: 'main', files: ['app.js'] })
+  assert.deepEqual(f.state().flow.config.stage_bindings['开发'].skills[0].rules, [rule])
+  assert.deepEqual(f.state().flow.config.stage_bindings['交付'].skills[0].rules, [rule])
+  assert.equal(f.state().flow.resources.find(resource => resource.kind === 'rule')?.content, 'RULE BODY')
+  assert.equal(JSON.parse(await f.call({ operation: 'status' })).bindings.rules[0].content, 'RULE BODY')
+})
+
+test('task creation rejects an unavailable skill or rule before writing a record', async () => {
+  const f = fixture()
+  f.records.delete(join(f.cwd, '.dsh/task-LIVE-1.json'))
+  f.records.set(join(f.cwd, '.dsh/eng.json'), JSON.stringify({ flow: 'minimal', stage_bindings: {
+    '开发': { skills: [{ skill: { source: 'project', name: 'missing-skill' }, rules: [] }] },
+  } }))
+  await assert.rejects(f.call({ operation: 'create', title: 'missing', branch: 'main' }), /unreadable bound resources/)
+  assert.equal(f.records.has(join(f.cwd, '.dsh/task-LIVE-1.json')), false)
+})
+
 test('审查通过后更新状态并激活下一项，保留已完成项的审计', async () => {
   const f = fixture()
   await f.call({ operation: 'items', items: [{ id: 'A', title: 'first', status: 'doing' }, { id: 'B', title: 'second' }] })

package/README.md

@@ -27,7 +27,7 @@
 让 AI 修改代码时，你可以先明确需求，再检查方案、推进实施、验证结果，最后审核提交。DSH Task Engine 把这些步骤组织成可检查、可追踪的任务流程，适合在本机使用 DeepSeek Harness 开发个人项目。
 
 - **知道下一步做什么**：按所选流程推进，当前阶段需要的条件和产物清楚可查。
-- **复用自己的工作方法**：把技能和规则安装到项目或个人目录，再挂到节点上；规则跟着技能走，所以同一技能在任何节点都是同一套约束。
+- **复用自己的工作方法**：把技能和规则安装到项目或个人目录，将规则配置在技能下，再把技能挂到节点上；同一技能在任何节点都使用同一套约束。
 - **找得到过程记录**：任务台账集中查看阶段、实施项、验证与审核状态。
 
 ## 快速开始
@@ -53,7 +53,7 @@ dsh plugin --profile web add @godv61/dsh-task-engine
 | **项目初始化** | 查看或编辑 `AGENTS.md`，让 AI 生成项目说明，预览后保存。 |
 | **流程配置** | 选择流程骨架，给节点挂技能，并在技能上配置它遵循的规则。需要现成起点时可「采用推荐配置」。 |
 | **任务台账** | 查看实施、验证和审核记录，按关键词、阶段或风险筛选。 |
-| **技能** | 选择技能文件夹，预览内容与目标目录后安装；支持查看、编辑和删除。 |
+| **技能** | 安装、编辑技能，并集中维护每个技能唯一的规则列表。 |
 | **规则** | 选择 Markdown 文件安装规则，维护项目或个人开发约定。 |
 
 内置技能和规则只读；项目与个人资源可编辑。安装、删除都会明确展示目标位置。
@@ -64,11 +64,11 @@ dsh plugin --profile web add @godv61/dsh-task-engine
 
 | 预设 | 阶段顺序 | 适用场景 |
 | :--- | :--- | :--- |
-| **标准研发** `standard` | 需求评审 → 设计 → 开发 → 交付 → 代码审核 → 完成 | 需要需求、方案和交付检查的完整开发任务。 |
-| **敏捷轻量** `agile` | 需求 → 开发 → 交付 → 审查 | 希望保留任务记录、减少阶段和产物的迭代。 |
-| **纯代码** `minimal` | 开发 → 交付 | 已明确做法的小改动。 |
+| **完整研发** `standard` | 需求评审 → 设计 → 开发 → 交付 → 代码审核 → 完成 | 需要需求、方案和交付检查的完整开发任务。 |
+| **日常迭代** `agile` | 需求 → 开发 → 交付 → 审查 | 目标明确的日常开发任务。 |
+| **快速修改** `minimal` | 开发 → 交付 | 已明确做法的小改动。 |
 
-当前版本的阶段顺序和检查条件由预设固定，默认技能/规则绑定只能追加。**可视化自定义流程不在计划内**——它把流程设计的负担转嫁给使用者，而三个内置流程已覆盖个人项目的常见需要，详见[功能规划](docs/roadmap.md)。
+阶段顺序和检查条件由预设固定；技能与规则由用户配置。选择流程不会强制加入内置技能；需要现成起点时可显式采用推荐配置。**可视化自定义流程不在计划内**，详见[功能规划](docs/roadmap.md)。
 
 ## 把自己的技能和规则带进来
 
@@ -98,7 +98,7 @@ dsh plugin --profile web add @godv61/dsh-task-engine
 
 ## 能力说明
 
-`dev_task` 按配置检查阶段、产物和提交条件。0.23.1 新任务验证要求真实命令回执；附加技能的回执要求可在任务状态中查看，内置技能使用已有的记录、验证、审核和提交操作。任务保存创建时的流程快照，之后修改项目配置不会直接改变进行中的任务。
+`dev_task` 按配置检查阶段、产物和提交条件。新任务的验证要求真实命令回执；技能可按自身配置要求命令、产物、审核、人工批准或无需额外证据，执行义务可在任务状态中查看。任务保存创建时的流程与资源快照，之后修改项目配置不会直接改变进行中的任务。
 
 审核结论、实施项完成情况和测试覆盖面仍需要你判断。本地提交钩子提供即时检查，不能替代人工审核或项目自己的 CI。详细说明见[常见问题](docs/faq.md)。
 

package/cordis.patch.yml

@@ -1,11 +1,11 @@
-# dsh-task-engine bundle: one host-plane row that mounts the `task-engine`
-# Remote namespace (what the browser workbench reads/writes) plus, via
-# `dsh.client`, the workbench UI. This host row registers NO model-facing tool
-# and NO skill — `dev_task` and the shipped skills live on the AGENT plane,
-# behind the `@godv61/dsh-task-engine/agent` entry. A preset's
-# `agent.cordis.yml` names that agent row to activate the flow for its
-# sessions; presets that never name it get neither the tool nor the skills
-# (the workbench stays available so a human can still configure the flow).
-- insert:
-    - id: task-engine
+# dsh-task-engine bundle: one host-plane row that mounts the `task-engine`
+# Remote namespace (what the browser workbench reads/writes) plus, via
+# `dsh.client`, the workbench UI. This host row registers NO model-facing tool
+# and NO skill — `dev_task` and the shipped skills live on the AGENT plane,
+# behind the `@godv61/dsh-task-engine/agent` entry. A preset's
+# `agent.cordis.yml` names that agent row to activate the flow for its
+# sessions; presets that never name it get neither the tool nor the skills
+# (the workbench stays available so a human can still configure the flow).
+- insert:
+    - id: task-engine
       name: '@godv61/dsh-task-engine'

package/defaults/eng.json

@@ -2,48 +2,96 @@
   "flow": "standard",
   "stage_bindings": {
     "需求评审": {
-      "skills": [
+      "skill_refs": [
         {
-          "skill": { "source": "bundled", "name": "requirement-analysis" },
-          "rules": [{ "source": "bundled", "name": "security-redlines" }]
+          "source": "bundled",
+          "name": "requirement-analysis"
         }
       ]
     },
     "设计": {
-      "skills": [
-        { "skill": { "source": "bundled", "name": "solution-design" }, "rules": [] }
+      "skill_refs": [
+        {
+          "source": "bundled",
+          "name": "solution-design"
+        }
       ]
     },
     "开发": {
-      "skills": [
+      "skill_refs": [
         {
-          "skill": { "source": "bundled", "name": "code-implement" },
-          "rules": [
-            { "source": "bundled", "name": "coding-conventions" },
-            { "source": "bundled", "name": "security-redlines" }
-          ]
+          "source": "bundled",
+          "name": "code-implement"
         }
       ]
     },
     "交付": {
-      "skills": [
-        { "skill": { "source": "bundled", "name": "code-verify" }, "rules": [] }
+      "skill_refs": [
+        {
+          "source": "bundled",
+          "name": "code-verify"
+        }
       ]
     },
     "代码审核": {
-      "skills": [
+      "skill_refs": [
+        {
+          "source": "bundled",
+          "name": "code-review"
+        },
+        {
+          "source": "bundled",
+          "name": "code-commit"
+        }
+      ]
+    }
+  },
+  "skill_profiles": {
+    "bundled:requirement-analysis": {
+      "rules": [
+        {
+          "source": "bundled",
+          "name": "security-redlines"
+        }
+      ]
+    },
+    "bundled:solution-design": {
+      "rules": []
+    },
+    "bundled:code-implement": {
+      "rules": [
         {
-          "skill": { "source": "bundled", "name": "code-review" },
-          "rules": [
-            { "source": "bundled", "name": "coding-conventions" },
-            { "source": "bundled", "name": "security-redlines" }
-          ]
+          "source": "bundled",
+          "name": "coding-conventions"
         },
         {
-          "skill": { "source": "bundled", "name": "code-commit" },
-          "rules": [{ "source": "bundled", "name": "commit-conventions" }]
+          "source": "bundled",
+          "name": "security-redlines"
+        }
+      ]
+    },
+    "bundled:code-verify": {
+      "rules": []
+    },
+    "bundled:code-review": {
+      "rules": [
+        {
+          "source": "bundled",
+          "name": "coding-conventions"
+        },
+        {
+          "source": "bundled",
+          "name": "security-redlines"
+        }
+      ]
+    },
+    "bundled:code-commit": {
+      "rules": [
+        {
+          "source": "bundled",
+          "name": "commit-conventions"
         }
       ]
     }
   }
-}
+}

package/docs/BRIEF-FOR-REVIEW.md

@@ -1,163 +1,163 @@
-# DSH Task Engine —— 技术简报（供评估与优化讨论）
-
-> 用途：把事实交给 GPT 讨论时使用。以下内容均经代码/实测核对，不是印象。
-
----
-
-## 1. 它是什么
-
-DeepSeek Harness（DSH）的插件：给 AI 编码会话加一套**可检查的工程交付流程**。
-
-- npm: `@godv61/dsh-task-engine`（`latest` = 0.23.9，MIT）
-- GitHub: https://github.com/godv61/dsh-task-engine（**已被 [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) 收录**，PR #5681 一次通过）
-- 规模：host 面 **4079 行** TS，client 面 **2173 行** TSX，测试 146 项 P0 断言 + 52 项 `node:test`
-
-### 核心机制
-
-**一个工具 `dev_task`**，7 个操作：`status` / `config` / `init` / `create` / `commit` / `install_hook` / `verify_hook`。
-
-它持有任务状态机，**阶段流转是硬门禁**（模型无法绕过）：
-
-| 守卫 | 含义 |
-| :--- | :--- |
-| `requirement_confirmation` | 需求须经人确认 |
-| `solution_confirmation` | 方案须经人确认 |
-| `artifacts_present` | 阶段产物须齐备 |
-| `todos_done` | 实施项须全部完成 |
-| `verified` | 须有**真实命令回执**（退出码 0，未超时/中止/被沙箱拒） |
-| `review_passed` | 须有审核结论 |
-
-**三个内置流程**（阶段顺序与守卫由预设固化）：
-
-| 流程 | 阶段 |
-| :--- | :--- |
-| `standard` | 需求评审 → 设计 → 开发 → 交付 → 代码审核 → 完成 |
-| `agile` | 需求 → 开发 → 交付 → 审查 |
-| `minimal` | 开发 → 交付 |
-
-**渐进式披露**：每个阶段挂「技能 + 规则」，进入该阶段才披露，避免一次性灌入上下文。
-
-**工作台 5 个标签页**：项目初始化 / 流程配置 / 任务台账 / 技能 / 规则。
-
----
-
-## 2. 已知的设计缺口（当前讨论起点）
-
-### 2.1 技能与规则是平级的，但存在**隐式依赖**
-
-**数据模型**（`src/engine.ts`）：
-
-```ts
-interface StageBinding {
-  skills?: string[]   // 独立数组
-  rules?: string[]    // 独立数组
-}
-```
-
-引擎分别解析：
-
-```ts
-const rules = await resolveRules(binding?.rules ?? [], fs, cwd)   // 不经技能
-```
-
-**但技能文本里引用了具体规则**，例如 `code-implement/SKILL.md`：
-
-> 代码质量：按内置规则 **coding-conventions** 查「做得好不好」
-
-**问题**：这个依赖**只写在散文里，没有结构化**。因此：
-
-- 用户在 UI 勾了 `code-implement` 但没勾 `coding-conventions` → 技能执行时引用一个不存在的规则
-- **引擎不校验，UI 不提示**
-- 默认配置碰巧配对，用户改绑定就可能拆散
-
-**默认配置印证耦合确实存在**：规则 `coding-conventions` 同时挂在「开发」（`code-implement`）和「交付」（`code-verify`）两个阶段。
-
-### 2.2 待决策的四个方案
-
-| 方案 | 做法 | 代价 |
-| :--- | :--- | :--- |
-| **A. 声明式依赖** | `SKILL.md` frontmatter 加 `requires_rules: [...]` | 是 B/C/D 的前置条件；需改 7 个内置技能 |
-| **B. 软提示** | 规则列表全量显示，标注「此技能建议配合 X」 | 保留自由组合；仅提示 |
-| **C. 强联动** | 勾技能 → 规则列表过滤到相关项 | ⚠️ 破坏自由组合（同一规则复用于多技能） |
-| **D. 仅保存时校验** | 不联动 UI，保存时警告「技能 X 引用了未挂载的规则 Y」 | 最轻量；问题暴露较晚 |
-
-**当前倾向**：A + D（先让关系可表达，再做校验），或 A + B。**C 需要在 A 的数据之上才成立。**
-
----
-
-## 3. 其他可能值得评估的方向
-
-### 3.1 流程定制能力的边界
-
-**现状**：阶段顺序与守卫由预设固化，**可视化自定义流程不在计划内**（曾评估，结论是不做——把流程设计负担转嫁给使用者）。
-
-**可调部分**：项目根 `.dsh/eng.json` 只声明 `flow`（选哪套预设）+ `stage_bindings`（每阶段挂什么）。
-
-**待评估**：这个边界是否过窄？例如是否该允许「加一个自定义阶段但保留守卫语义」？
-
-### 3.2 验证与审核的可信度边界
-
-**现状**（README 与 FAQ 都声明）：
-
-> 命令覆盖是否充分、审核是否准确仍需判断，**不能把一个成功退出码当作全部需求已验证**。
-
-- 验证需真实回执，但**回执不等于需求被完整覆盖**
-- 审核/实施项结论**由模型记录**，非独立验证
-- 任务 JSON **无签名**，有文件写权限者可同时改内容与摘要
-
-**待评估**：对「成熟开源产品」而言，这个边界是否需要更强机制（如独立验收、产物哈希链）？
-
-### 3.3 提交门禁可被绕过
-
-**现状**：`hooks/commit-msg` 检查任务、阶段、消息与文件范围。但：
-
-> `--no-verify`、替换 `hooksPath` 或直接改本地数据**仍可能绕过**。
-
-**待评估**：是否需要与 CI 结合的服务端校验？还是明确声明「个人本机工具，不提供防篡改」即可？
-
-### 3.4 多环境一致性
-
-**现状问题**：同一插件需在**桌面版 DSH**（`0.1.2-rc.1`）与**源码版 DSH**（`0.1.7-alpha.1`）上工作，两者契约不同：
-
-- persona 字段：桌面版要 `text`，源码版要 `prefix`（已在 0.23.7 通过「跟着运行环境走」解决）
-- 插件管理：桌面版用 generation 机制，源码版用 pnpm
-
-**已采取的防护**：CI 加 `dsh-contract` job（跑 `scripts/verify-dsh-compat.mjs`），peer 范围用显式 `||` 分支覆盖各版本。
-
-**待评估**：DSH 处于 alpha、**1–3 天一个 tag**，这个跟踪成本是否可持续？
-
-### 3.5 其他
-
-- **国际化**：目前中文为主，README 有中英双版。是否需要完整 i18n？
-- **可访问性**：工作台介入了 `aria-label`，但未系统测试
-- **性能**：任务台账在任务多时的表现未测
-- **文档**：本次刚做过一次重组（发布说明归入 `docs/releases/`，索引分「当前/历史」）
-
----
-
-## 4. 近期已完成的修复（供判断演进方向）
-
-| 版本 | 内容 |
-| :--- | :--- |
-| 0.23.9 | 可搜索绑定选择器（独立搜索/仅看已选/计数/就地滚动/预设默认锁定）；source map 停止内联源码（447→148 KB）；修 10 处 UTF-8 字节损坏 |
-| 0.23.8 | 文档修正（4 处与代码矛盾的陈述）+ 目录重组 |
-| 0.23.7 | persona 字段兼容（新旧 DSH 都能用）——**读源预设用哪个字段就写哪个**，不再硬编码 |
-| 0.23.6 | eng 预设每次启动从运行中 harness 重新派生（此前只在首次生成，DSH 升级后失效） |
-
----
-
-## 5. 环境依赖（影响可测试性）
-
-- **DSH 0.1.7-alpha.1** 曾有 bug 致**所有工具调用失败**（`ctx.tools[TOOL_RUNTIME_SCHEDULER]` 为 `undefined`），社区在 discussions #7035 / #7194 报告，**0.1.7 已修**
-- 源码版用 `pnpm dsh web` 会触发模块双重加载；绕过方式：`node apps/cli/lib/bin.js <profile>`
-- 桌面版插件由 `dshmarket` + generation 机制管理，**不能用 CLI 的 `dsh plugin` 直接操作**（会与它冲突）
-
----
-
-## 6. 想请对方重点回答的问题
-
-1. **技能↔规则依赖**：A/B/C/D 选哪个？还是有更好的模型（如规则直接属于技能、互不独立）？
-2. **流程定制边界**：「不做自定义流程」对一个成熟产品是否合理？还是该提供受限的扩展点？
-3. **可信度声明**：当前「不防篡改」的边界，是明确声明即可，还是需要机制补强？
-4. **对 DSH alpha 的跟踪成本**：1–3 天一个 tag，插件该怎么定位（追最新？固定版本？）
+# DSH Task Engine —— 技术简报（供评估与优化讨论）
+
+> 用途：把事实交给 GPT 讨论时使用。以下内容均经代码/实测核对，不是印象。
+
+---
+
+## 1. 它是什么
+
+DeepSeek Harness（DSH）的插件：给 AI 编码会话加一套**可检查的工程交付流程**。
+
+- npm: `@godv61/dsh-task-engine`（`latest` = 0.23.9，MIT）
+- GitHub: https://github.com/godv61/dsh-task-engine（**已被 [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) 收录**，PR #5681 一次通过）
+- 规模：host 面 **4079 行** TS，client 面 **2173 行** TSX，测试 146 项 P0 断言 + 52 项 `node:test`
+
+### 核心机制
+
+**一个工具 `dev_task`**，7 个操作：`status` / `config` / `init` / `create` / `commit` / `install_hook` / `verify_hook`。
+
+它持有任务状态机，**阶段流转是硬门禁**（模型无法绕过）：
+
+| 守卫 | 含义 |
+| :--- | :--- |
+| `requirement_confirmation` | 需求须经人确认 |
+| `solution_confirmation` | 方案须经人确认 |
+| `artifacts_present` | 阶段产物须齐备 |
+| `todos_done` | 实施项须全部完成 |
+| `verified` | 须有**真实命令回执**（退出码 0，未超时/中止/被沙箱拒） |
+| `review_passed` | 须有审核结论 |
+
+**三个内置流程**（阶段顺序与守卫由预设固化）：
+
+| 流程 | 阶段 |
+| :--- | :--- |
+| `standard` | 需求评审 → 设计 → 开发 → 交付 → 代码审核 → 完成 |
+| `agile` | 需求 → 开发 → 交付 → 审查 |
+| `minimal` | 开发 → 交付 |
+
+**渐进式披露**：每个阶段挂「技能 + 规则」，进入该阶段才披露，避免一次性灌入上下文。
+
+**工作台 5 个标签页**：项目初始化 / 流程配置 / 任务台账 / 技能 / 规则。
+
+---
+
+## 2. 已知的设计缺口（当前讨论起点）
+
+### 2.1 技能与规则是平级的，但存在**隐式依赖**
+
+**数据模型**（`src/engine.ts`）：
+
+```ts
+interface StageBinding {
+  skills?: string[]   // 独立数组
+  rules?: string[]    // 独立数组
+}
+```
+
+引擎分别解析：
+
+```ts
+const rules = await resolveRules(binding?.rules ?? [], fs, cwd)   // 不经技能
+```
+
+**但技能文本里引用了具体规则**，例如 `code-implement/SKILL.md`：
+
+> 代码质量：按内置规则 **coding-conventions** 查「做得好不好」
+
+**问题**：这个依赖**只写在散文里，没有结构化**。因此：
+
+- 用户在 UI 勾了 `code-implement` 但没勾 `coding-conventions` → 技能执行时引用一个不存在的规则
+- **引擎不校验，UI 不提示**
+- 默认配置碰巧配对，用户改绑定就可能拆散
+
+**默认配置印证耦合确实存在**：规则 `coding-conventions` 同时挂在「开发」（`code-implement`）和「交付」（`code-verify`）两个阶段。
+
+### 2.2 待决策的四个方案
+
+| 方案 | 做法 | 代价 |
+| :--- | :--- | :--- |
+| **A. 声明式依赖** | `SKILL.md` frontmatter 加 `requires_rules: [...]` | 是 B/C/D 的前置条件；需改 7 个内置技能 |
+| **B. 软提示** | 规则列表全量显示，标注「此技能建议配合 X」 | 保留自由组合；仅提示 |
+| **C. 强联动** | 勾技能 → 规则列表过滤到相关项 | ⚠️ 破坏自由组合（同一规则复用于多技能） |
+| **D. 仅保存时校验** | 不联动 UI，保存时警告「技能 X 引用了未挂载的规则 Y」 | 最轻量；问题暴露较晚 |
+
+**当前倾向**：A + D（先让关系可表达，再做校验），或 A + B。**C 需要在 A 的数据之上才成立。**
+
+---
+
+## 3. 其他可能值得评估的方向
+
+### 3.1 流程定制能力的边界
+
+**现状**：阶段顺序与守卫由预设固化，**可视化自定义流程不在计划内**（曾评估，结论是不做——把流程设计负担转嫁给使用者）。
+
+**可调部分**：项目根 `.dsh/eng.json` 只声明 `flow`（选哪套预设）+ `stage_bindings`（每阶段挂什么）。
+
+**待评估**：这个边界是否过窄？例如是否该允许「加一个自定义阶段但保留守卫语义」？
+
+### 3.2 验证与审核的可信度边界
+
+**现状**（README 与 FAQ 都声明）：
+
+> 命令覆盖是否充分、审核是否准确仍需判断，**不能把一个成功退出码当作全部需求已验证**。
+
+- 验证需真实回执，但**回执不等于需求被完整覆盖**
+- 审核/实施项结论**由模型记录**，非独立验证
+- 任务 JSON **无签名**，有文件写权限者可同时改内容与摘要
+
+**待评估**：对「成熟开源产品」而言，这个边界是否需要更强机制（如独立验收、产物哈希链）？
+
+### 3.3 提交门禁可被绕过
+
+**现状**：`hooks/commit-msg` 检查任务、阶段、消息与文件范围。但：
+
+> `--no-verify`、替换 `hooksPath` 或直接改本地数据**仍可能绕过**。
+
+**待评估**：是否需要与 CI 结合的服务端校验？还是明确声明「个人本机工具，不提供防篡改」即可？
+
+### 3.4 多环境一致性
+
+**现状问题**：同一插件需在**桌面版 DSH**（`0.1.2-rc.1`）与**源码版 DSH**（`0.1.7-alpha.1`）上工作，两者契约不同：
+
+- persona 字段：桌面版要 `text`，源码版要 `prefix`（已在 0.23.7 通过「跟着运行环境走」解决）
+- 插件管理：桌面版用 generation 机制，源码版用 pnpm
+
+**已采取的防护**：CI 加 `dsh-contract` job（跑 `scripts/verify-dsh-compat.mjs`），peer 范围用显式 `||` 分支覆盖各版本。
+
+**待评估**：DSH 处于 alpha、**1–3 天一个 tag**，这个跟踪成本是否可持续？
+
+### 3.5 其他
+
+- **国际化**：目前中文为主，README 有中英双版。是否需要完整 i18n？
+- **可访问性**：工作台介入了 `aria-label`，但未系统测试
+- **性能**：任务台账在任务多时的表现未测
+- **文档**：本次刚做过一次重组（发布说明归入 `docs/releases/`，索引分「当前/历史」）
+
+---
+
+## 4. 近期已完成的修复（供判断演进方向）
+
+| 版本 | 内容 |
+| :--- | :--- |
+| 0.23.9 | 可搜索绑定选择器（独立搜索/仅看已选/计数/就地滚动/预设默认锁定）；source map 停止内联源码（447→148 KB）；修 10 处 UTF-8 字节损坏 |
+| 0.23.8 | 文档修正（4 处与代码矛盾的陈述）+ 目录重组 |
+| 0.23.7 | persona 字段兼容（新旧 DSH 都能用）——**读源预设用哪个字段就写哪个**，不再硬编码 |
+| 0.23.6 | eng 预设每次启动从运行中 harness 重新派生（此前只在首次生成，DSH 升级后失效） |
+
+---
+
+## 5. 环境依赖（影响可测试性）
+
+- **DSH 0.1.7-alpha.1** 曾有 bug 致**所有工具调用失败**（`ctx.tools[TOOL_RUNTIME_SCHEDULER]` 为 `undefined`），社区在 discussions #7035 / #7194 报告，**0.1.7 已修**
+- 源码版用 `pnpm dsh web` 会触发模块双重加载；绕过方式：`node apps/cli/lib/bin.js <profile>`
+- 桌面版插件由 `dshmarket` + generation 机制管理，**不能用 CLI 的 `dsh plugin` 直接操作**（会与它冲突）
+
+---
+
+## 6. 想请对方重点回答的问题
+
+1. **技能↔规则依赖**：A/B/C/D 选哪个？还是有更好的模型（如规则直接属于技能、互不独立）？
+2. **流程定制边界**：「不做自定义流程」对一个成熟产品是否合理？还是该提供受限的扩展点？
+3. **可信度声明**：当前「不防篡改」的边界，是明确声明即可，还是需要机制补强？
+4. **对 DSH alpha 的跟踪成本**：1–3 天一个 tag，插件该怎么定位（追最新？固定版本？）
 5. **还缺什么才能称得上「成熟开源产品」**：贡献指南、issue 模板、语义化版本、变更日志规范、安全策略、行为准则？

package/docs/CHANGELOG.md

@@ -4,6 +4,18 @@
 
 按版本查阅功能变化。当前使用方式以[项目首页](../README.md)和使用指南为准；历史条目中的实现方式、限制与测试数量可能已被后续版本替代。
 
+## 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。**