@godv61/dsh-task-engine 0.28.0 → 0.29.1

package/.adaptive-test.mjs

@@ -0,0 +1,189 @@
+import test from 'node:test'
+import assert from 'node:assert/strict'
+import { join, resolve } from 'node:path'
+import { mkdtempSync, rmSync } from 'node:fs'
+import { tmpdir } from 'node:os'
+import { adaptiveWorkflow, COMPLEXITY_OPTIONS } from './lib/adaptive.js'
+import { validateWorkflow } from './lib/engine.js'
+import { registerDevTask } from './lib/dev-task.js'
+import { inspectSonar } from './lib/sonar.js'
+import Controller from './lib/controller.js'
+
+const home = mkdtempSync(join(tmpdir(), 'dsh-adaptive-'))
+process.env.DSH_HOME = home
+process.on('exit', () => rmSync(home, { recursive: true, force: true }))
+
+function fixture(extra = {}) {
+  const cwd = resolve('adaptive-project')
+  const files = new Map([[join(cwd, 'package.json'), '{"name":"adaptive-project","dependencies":{"vue":"^2.7.0"}}'],
+    [join(cwd, '.git/HEAD'), 'ref: refs/heads/feature'] , ...Object.entries(extra).map(([p, content]) => [join(cwd, p), content])])
+  const events = []
+  const session = { id: 'adaptive', header: { cwd }, snapshotEvents: () => events }
+  const key = (path, options) => join(options?.cwd ?? cwd, path)
+  let execute
+  const fs = {
+    resolve: async (path, options) => ({ path: key(path, options) }),
+    readText: async target => files.get(target.path),
+    lstat: async (path, options) => files.has(key(path, options)) ? { version: 'v1' } : undefined,
+    writeText: async (target, content, intent) => {
+      if (intent?.kind === 'createIfAbsent' && files.has(target.path)) throw new Error('already exists')
+      files.set(target.path, content)
+    },
+    listDir: async target => [...new Set([...files.keys()].filter(path => path.startsWith(target.path + '\\'))
+      .map(path => path.slice(target.path.length + 1).split('\\')[0]))].map(name => ({ name })),
+  }
+  const ctx = { fs, tools: { register(tool) { execute = tool.execute; return () => {} } }, get(name) {
+    if (name === 'sandboxPolicy') return { resolve: () => ({ mode: 'workspace-write', workspaceRoot: cwd, sessionId: session.id }) }
+    return undefined
+  } }
+  registerDevTask(ctx)
+  const exec = { agent: { session }, signal: new AbortController().signal }
+  return { cwd, files, fs, events, call: args => execute(args, exec), state: id => JSON.parse(files.get(join(cwd, `.dsh/task-${id}.json`))) }
+}
+
+test('each task grade has a valid and increasing meta-skill sequence', () => {
+  assert.deepEqual(COMPLEXITY_OPTIONS.map(option => option.id), ['low', 'medium', 'high', 'ultra'])
+  const configs = COMPLEXITY_OPTIONS.map(option => adaptiveWorkflow(option.id))
+  for (const config of configs) assert.deepEqual(validateWorkflow(config), [])
+  assert.deepEqual(configs.map(config => config.stages.length), [4, 5, 6, 7])
+  assert.ok(configs[2].stages.includes('任务编排'))
+  assert.ok(configs[3].stages.includes('架构设计'))
+  assert.ok(configs.every(config => config.transitions.some(edge => edge.requires?.includes('verified'))))
+  assert.ok(configs.every(config => config.commit.checkpoints.includes('测试')))
+})
+
+test('adaptive task freezes a project override and its own Rules, not the bundled same-name Skill', async () => {
+  const f = fixture({
+    '.dsh/skills/requirements-analysis/SKILL.md': '# Project requirement method',
+    '.dsh/skills/requirements-analysis/profile.json': JSON.stringify({ rules: [{ source: 'project', name: 'team-scope' }], evidence: 'artifact' }),
+    '.dsh/rules/team-scope.md': '# Team scope rule',
+    '.dsh/meta.json': JSON.stringify({ meta_bindings: { 'code-development': ['adaptive-project-project-map'] } }),
+    '.dsh/skills/adaptive-project-project-map/SKILL.md': '# Project map',
+    '.dsh/skills/adaptive-project-project-map/profile.json': JSON.stringify({ rules: [], evidence: 'none' }),
+  })
+  const preview = JSON.parse(await f.call({ operation: 'assess', complexity: 'high' }))
+  assert.equal(preview.meta_skills['需求分析'][0].effective_source, 'project')
+  assert.ok(preview.meta_skills['代码开发'].some(skill => skill.logical_name === 'adaptive-project-project-map'))
+  await f.call({ operation: 'create', task_id: 'A-1', title: 'cross-module change', branch: 'feature',
+    complexity: 'high', complexity_reason: 'Several implementation steps depend on earlier interfaces', files: ['app.js'] })
+  const state = f.state('A-1')
+  assert.equal(state.flow.flow, 'adaptive-high')
+  assert.equal(state.flow.config.stage_bindings['需求分析'].skills[0].skill.source, 'project')
+  assert.ok(state.flow.resources.some(entry => entry.ref.name === 'team-scope' && entry.ref.source === 'project'))
+  assert.match(await f.call({ operation: 'load_skill', task_id: 'A-1', skill_name: 'project:requirements-analysis' }), /Project requirement method/)
+  await assert.rejects(f.call({ operation: 'load_skill', task_id: 'A-1', skill_name: 'bundled:requirements-analysis' }), /exact source:name/)
+})
+
+test('init_project proposes project-specific Skills and binds reviewed resources', async () => {
+  const f = fixture()
+  const inventory = JSON.parse(await f.call({ operation: 'init_project', phase: 'inspect' }))
+  assert.ok(inventory.suggestions.some(entry => entry.name === 'adaptive-project-project-map'))
+  assert.ok(inventory.manifests.some(entry => entry.facts.includes('vue=^2.7.0')))
+  const resources = [
+    { kind: 'rule', name: 'component-boundary', content: 'Keep component boundary calls behind the existing service interface.' },
+    { kind: 'skill', name: 'adaptive-project-project-map', description: 'Project structure and entry points',
+      content: 'The root package.json declares Vue 2.7; inspect src for the actual component layout.',
+      meta_skills: ['requirements-analysis', 'code-development'], rules: ['component-boundary'] },
+  ]
+  const proposed = JSON.parse(await f.call({ operation: 'init_project', phase: 'propose', resources }))
+  assert.equal(f.files.has(join(f.cwd, '.dsh/meta.json')), false)
+  await f.call({ operation: 'init_project', phase: 'apply', resources, expected_hash: proposed.expected_hash,
+    existing_hash: proposed.existing_hash })
+  const meta = JSON.parse(f.files.get(join(f.cwd, '.dsh/meta.json')))
+  assert.deepEqual(meta.meta_bindings['code-development'], ['adaptive-project-project-map'])
+  assert.ok(f.files.has(join(f.cwd, '.dsh/skills/adaptive-project-project-map/profile.json')))
+})
+
+test('workbench adaptive settings persist meta bindings with a version check', async () => {
+  const f = fixture()
+  const receiver = { authorizedPath: async path => path, fs: () => f.fs,
+    listSkills: async () => ({ skills: [{ name: 'adaptive-project-project-map', source: 'project' }] }),
+    readAdaptive: Controller.prototype.readAdaptive }
+  const before = await Controller.prototype.readAdaptive.call(receiver, f.cwd)
+  assert.equal(before.source, 'default')
+  const config = { meta_bindings: { 'code-development': ['adaptive-project-project-map'] }, sonar: { enabled: false } }
+  const after = await Controller.prototype.writeAdaptive.call(receiver,
+    { path: f.cwd, config, expected_hash: before.hash })
+  assert.equal(after.ok, true)
+  assert.deepEqual(after.config.meta_bindings['code-development'], ['adaptive-project-project-map'])
+  await assert.rejects(Controller.prototype.writeAdaptive.call(receiver,
+    { path: f.cwd, config, expected_hash: before.hash }), /已被其他会话修改/)
+})
+
+test('Sonar audit reads the exact CI analysis gate and filters new-code medium/high findings', async () => {
+  const calls = []
+  const fetcher = async (url, options) => {
+    calls.push({ url: String(url), authorization: options.headers.Authorization })
+    const body = String(url).includes('/ce/task')
+      ? { task: { status: 'SUCCESS', analysisId: 'AN-1', componentKey: 'project' } }
+      : String(url).includes('/qualitygates/project_status')
+        ? { projectStatus: { status: 'ERROR' } }
+        : { paging: { total: 2 }, issues: [
+          { key: 'ISSUE-1', rule: 'java:S111', message: 'problem', severity: 'MAJOR', component: 'project:src/A.java', line: 3 },
+          { key: 'ISSUE-2', rule: 'java:S222', message: 'minor', severity: 'MINOR', component: 'project:src/B.java' },
+        ] }
+    return { ok: true, json: async () => body }
+  }
+  const policy = { enabled: true, host_url: 'https://sonar.example', project_key: 'project', mode: 'branch', token_env: 'SONAR_TOKEN' }
+  const audit = await inspectSonar(policy, 'secret-token', 'CE-TASK-123', 'feature', 'scope-hash', fetcher)
+  assert.equal(audit.analysis_id, 'AN-1')
+  assert.equal(audit.gate, 'ERROR')
+  assert.deepEqual(audit.blocking.map(issue => issue.key), ['ISSUE-1'])
+  assert.ok(calls[2].url.includes('inNewCodePeriod=true'))
+  assert.ok(calls.every(call => call.authorization === 'Bearer secret-token'))
+  assert.equal(JSON.stringify(audit).includes('secret-token'), false)
+})
+
+test('review-only Sonar gate blocks pass until the task records a passing CI analysis', async () => {
+  const f = fixture({ '.dsh/meta.json': JSON.stringify({ sonar: { enabled: true, host_url: 'https://sonar.example',
+    project_key: 'project', mode: 'branch', token_env: 'SONAR_TOKEN' } }) })
+  await f.call({ operation: 'create', task_id: 'S-1', title: 'change', branch: 'feature', complexity: 'low',
+    complexity_reason: 'One local change', files: ['app.js'], items: [{ id: 'one', title: 'change', status: 'done' }] })
+  const state = f.state('S-1')
+  state.stage = '代码审核'
+  state.verification = { passed: true, evidence: ['verified'] }
+  state.commits = [{ label: 'TASK', hash: 'abcdef1234567890' }]
+  f.files.set(join(f.cwd, '.dsh/task-S-1.json'), JSON.stringify(state))
+  await assert.rejects(f.call({ operation: 'review', task_id: 'S-1', outcome: 'pass' }), /SonarQube audit is enabled/)
+  const oldFetch = globalThis.fetch
+  const oldToken = process.env.SONAR_TOKEN
+  process.env.SONAR_TOKEN = 'secret-token'
+  globalThis.fetch = async url => ({ ok: true, json: async () => String(url).includes('/ce/task')
+    ? { task: { status: 'SUCCESS', analysisId: 'AN-2', componentKey: 'project' } }
+    : String(url).includes('/qualitygates/project_status') ? { projectStatus: { status: 'OK' } }
+      : { paging: { total: 0 }, issues: [] } })
+  try {
+    await f.call({ operation: 'sonar_check', task_id: 'S-1', ce_task_id: 'CE-123456' })
+    await f.call({ operation: 'review', task_id: 'S-1', outcome: 'pass' })
+    assert.equal(f.state('S-1').review.outcome, 'pass')
+  } finally {
+    globalThis.fetch = oldFetch
+    if (oldToken === undefined) delete process.env.SONAR_TOKEN
+    else process.env.SONAR_TOKEN = oldToken
+  }
+})
+
+test('a failed Sonar finding becomes a reviewed project Rule attached to the coding Skill', async () => {
+  const f = fixture()
+  await f.call({ operation: 'create', task_id: 'L-1', title: 'change', branch: 'feature', complexity: 'low',
+    complexity_reason: 'One local change', files: ['app.js'] })
+  const state = f.state('L-1')
+  const finding = { key: 'ISSUE-9', rule: 'java:S999', message: 'Handle null', severity: 'MAJOR', file: 'A.java' }
+  state.stage = '代码审核'
+  state.sonar_audit = { ce_task_id: 'CE-123456', analysis_id: 'AN-9', gate: 'ERROR', checked_at: 'now',
+    scope_hash: 'old', findings: [finding], blocking: [finding], target: 'feature' }
+  f.files.set(join(f.cwd, '.dsh/task-L-1.json'), JSON.stringify(state))
+  await f.call({ operation: 'revise', task_id: 'L-1', target_stage: '代码开发',
+    revision_kind: 'defect', revision_reason: 'Fix the SonarQube issue' })
+  assert.equal(f.state('L-1').sonar_history[0].blocking[0].key, 'ISSUE-9')
+  const args = { operation: 'learn_rule', task_id: 'L-1', issue_key: 'ISSUE-9', skill_name: 'bundled:code-development',
+    rule_name: 'handle-null-boundary', learning_reason: 'This boundary appears in several service methods',
+    content: 'At a service boundary, check for null before dereferencing. Show the failing call and a guarded call in the review example.' }
+  const proposal = JSON.parse(await f.call({ ...args, phase: 'propose' }))
+  assert.equal(f.files.has(join(f.cwd, '.dsh/rules/handle-null-boundary.md')), false)
+  await f.call({ ...args, phase: 'apply', expected_hash: proposal.expected_hash })
+  assert.match(f.files.get(join(f.cwd, '.dsh/rules/handle-null-boundary.md')), /java:S999/)
+  assert.ok(f.files.has(join(f.cwd, '.dsh/skills/code-development/SKILL.md')))
+  assert.deepEqual(JSON.parse(f.files.get(join(f.cwd, '.dsh/skills/code-development/profile.json'))).rules,
+    [{ source: 'project', name: 'handle-null-boundary' }])
+})

package/.hook-test.mjs

@@ -113,7 +113,7 @@ async function standardConfig() {
   return resolved.config
 }
 
-test('a task at its checkpoint with the right message commits', async () => {
+test('a task at its checkpoint with the right message commits', async () => {
   const config = await standardConfig()
   const root = repo('allow', approvedTask({ flow: { flow: 'standard', version: 2, config } }))
   try {
@@ -193,4 +193,21 @@ test('touching a sensitive path without a high-risk receipt is refused', async (
   } finally {
     rmSync(root, { recursive: true, force: true })
   }
-})
+})
+
+test('adaptive task can make its first CI commit before Sonar review', async () => {
+  const { adaptiveWorkflow } = await import('./lib/adaptive.js')
+  const config = adaptiveWorkflow('medium')
+  const root = repo('adaptive-sonar', approvedTask({
+    stage: '测试',
+    review: { outcome: 'pending' },
+    sonar_policy: { enabled: true, host_url: 'https://sonar.example.test', project_key: 'example', mode: 'branch', token_env: 'SONAR_TOKEN' },
+    flow: { flow: 'adaptive-medium', version: 1, config },
+  }))
+  try {
+    const result = tryCommit(root, 'first CI scan')
+    assert.equal(result.allowed, true, `the commit must precede its Sonar analysis: ${result.stderr}`)
+  } finally {
+    rmSync(root, { recursive: true, force: true })
+  }
+})

package/.workflow-test.mjs

@@ -411,12 +411,14 @@ test('同名技能与规则在项目和个人目录各自保留管理入口', as
   assert.match(read.content, /Run tests/)
 })
 
-test('安装包只注册会话编排技能，阶段目录不展示它', async () => {
+test('安装包注册会话编排和元技能，阶段目录只隐藏会话编排技能', async () => {
   const registered = []
   registerShippedSkills({ get: name => name === 'skills' ? { register: skill => { registered.push(skill); return () => {} } } : undefined })
-  const expected = ['eng-delivery']
+  const expected = ['architecture-design', 'code-development', 'code-review', 'eng-delivery',
+    'requirements-analysis', 'task-orchestration', 'test-validation']
   assert.deepEqual(registered.map(skill => skill.name).sort(), expected)
   assert.ok(registered.every(skill => skill.content.trim().length > 0))
   const catalog = await Controller.prototype.listSkills.call({ authorizedPath: async path => path }, '')
-  assert.deepEqual(catalog.skills.filter(skill => skill.source === 'bundled').map(skill => skill.name).sort(), [])
-})
+  assert.deepEqual(catalog.skills.filter(skill => skill.source === 'bundled').map(skill => skill.name).sort(),
+    expected.filter(name => name !== 'eng-delivery'))
+})

package/README.md

@@ -2,10 +2,12 @@
   <img src="docs/assets/workflow-banner.svg" alt="DSH Task Engine：DeepSeek Harness 的个人工程流程工作台，标准流程从需求评审走向完成" width="100%" />
 </p>
 
-<h1 align="center">DSH Task Engine</h1>
+<h1 align="center">DSH Task Engine</h1>
+
+> `0.29.0` 新增自适应流程、项目技能初始化与可选 SonarQube CI 审核。SonarQube 集成目前读取提交后的 CI 分析结果，不提供未提交代码的本地 Sonar 审核。
 
-<p align="center">把开发步骤、技能规则和交付记录，放进一个个人工作台。</p>
-<p align="center"><sub>A personal engineering workflow workbench for DeepSeek Harness.</sub></p>
+<p align="center">按每个需求选择工程路径，用项目 Skill 与 Rule 复用团队开发规范。</p>
+<p align="center"><sub>Task-scoped engineering workflows for DeepSeek Harness.</sub></p>
 
 <p align="center">
   <a href="https://www.npmjs.com/package/@godv61/dsh-task-engine"><img src="https://img.shields.io/npm/v/%40godv61%2Fdsh-task-engine?style=flat-square&amp;color=238636" alt="npm version" /></a>
@@ -24,9 +26,9 @@
 
 ## 为什么用它
 
-让 AI 修改代码时，你可以先明确需求，再检查方案、推进实施、验证结果，最后审核提交。DSH Task Engine 把这些步骤组织成可检查、可追踪的任务流程，适合在本机使用 DeepSeek Harness 开发个人项目。
+让 AI 在持续开发的项目中处理不同需求时，按这次需求的复杂度选择低、中、高、超高四档任务流程。元技能规定交接产物，项目 Skill/Rule 承载团队编码规范；同一项目下的多个会话可以各自推进不同任务。
 
-- **知道下一步做什么**：按所选流程推进，当前阶段需要的条件和产物清楚可查。
+- **知道下一步做什么**：任务创建时选择复杂度并冻结流程，当前阶段的条件和产物清楚可查。
 - **复用自己的工作方法**：把技能和规则安装到项目或个人目录，将规则配置在技能下，再把技能挂到节点上；同一技能在任何节点都使用同一套约束。
 - **找得到过程记录**：任务台账集中查看阶段、实施项、验证与审核状态。
 
@@ -38,29 +40,32 @@
 dsh plugin --profile web add @godv61/dsh-task-engine
 ```
 
-1. 重启 Harness Web，打开侧边栏的 **工程流程**。
-2. 选择工作区，在 **流程配置** 中选择一套流程。
+1. 重启 Harness Web，打开侧边栏的 **工程任务**。
+2. 选择工作区，在 **自适应流程** 中查看四档路径，按需挂载项目技能。
 3. 新建会话，选择 **工程化开发引擎** 预设，描述要完成的开发任务。
 
-看到“工程流程”入口和“工程化开发引擎”会话预设，就说明工作台与任务工具已接入。使用 Harness 源码启动的安装方式见[安装与启用](docs/getting-started.md)。
+看到“工程任务”入口和“工程化开发引擎”会话预设，就说明工作台与任务工具已接入。使用 Harness 源码启动的安装方式见[安装与启用](docs/getting-started.md)。
 
-> 工作台中的“流程预设”决定任务怎么推进；会话中的“工程化开发引擎”预设负责启用 `dev_task` 工具。两者作用不同。
+> 工程化会话先分析需求复杂度，再以 `dev_task assess` 预览并创建任务；`.dsh/meta.json` 只配置元技能挂载和可选 SonarQube 审核，不强迫项目所有会话走同一条流程。
 
 ## 工作台里有什么
 
 | 页面 | 你可以做什么 |
 | :--- | :--- |
-| **项目初始化** | 查看或编辑 `AGENTS.md`，让 AI 生成项目说明，预览后保存。 |
-| **流程配置** | 选择流程骨架，给节点挂技能，并在技能上配置它遵循的规则。需要现成起点时可「采用推荐配置」。 |
+| **项目初始化** | 维护 `AGENTS.md`；工程会话可用 `dev_task init_project` 扫描仓库、预览并生成项目 Skill/Rule。 |
+| **自适应流程** | 查看四档任务路径、元技能绑定与可选 SonarQube 审核配置。 |
+| **旧版流程** | 维护旧项目的 `.dsh/eng.json`；已有任务继续按冻结快照执行。 |
 | **任务台账** | 查看实施、验证和审核记录，按关键词、阶段或风险筛选。 |
 | **技能** | 安装、编辑技能，并集中维护每个技能唯一的规则列表。 |
 | **规则** | 选择 Markdown 文件安装规则，维护项目或个人开发约定。 |
 
-插件只内置负责会话编排的 `eng-delivery`。阶段技能和规则由使用者创建或安装，可放在项目或个人目录；安装、删除都会明确展示目标位置。
+插件内置会话编排 Skill `eng-delivery` 和六个通用元技能 Skill。项目知识、领域编码方法和 Rule 由使用者创建或通过 init 生成，可放在项目或个人目录；同名项目 Skill 在新任务中覆盖用户级 Skill。
+
+新路径的四档顺序、元技能交接契约、`init_project` 和可选 SonarQube 审核见[自适应工程任务](docs/adaptive-workflows.md)。
 
-**流程与工作方法是两回事。** 流程只决定工作怎么流转（阶段顺序与门禁），预设不自带任何技能或提交格式。要用什么技能、遵守哪些规则，都由你配置。「采用推荐配置」只填写可修改的提交文本、产物字段和评审深度，不改变技能与规则绑定。同一条规则可由多个技能共享。用户级技能及其规则配置由所有项目和会话共用。任务的流程与资源引用在创建时确定；Skill/Rule 正文在每次交互读取最新版本，创建时副本仅用于审计。[配置细节](docs/configuration.md)
+**流程与工作方法各有职责。** 四档流程规定阶段与门禁，并在相应阶段加载内置元技能；项目业务技能和规则由使用者配置。旧版三个流程不自带技能或提交格式，「采用推荐配置」只填写可修改的提交文本、产物字段和评审深度。同一条规则可由多个技能共享。任务的流程与资源引用在创建时确定；Skill/Rule 正文在每次交互读取最新版本，创建时副本仅用于审计。[新流程说明](docs/adaptive-workflows.md) · [旧版配置细节](docs/configuration.md)
 
-## 选择适合这次任务的流程
+## 旧版流程兼容
 
 | 预设 | 阶段顺序 | 适用场景 |
 | :--- | :--- | :--- |
@@ -68,7 +73,7 @@ dsh plugin --profile web add @godv61/dsh-task-engine
 | **日常迭代** `agile` | 需求 → 开发 → 交付 → 审查 | 目标明确的日常开发任务。 |
 | **快速修改** `minimal` | 开发 → 交付 | 已明确做法的小改动。 |
 
-阶段顺序和检查条件由预设固定；技能与规则由用户配置。空绑定也能运行流程。需要提交文本和产物字段的起点时可显式采用推荐配置。**可视化自定义流程不在计划内**，详见[功能规划](docs/roadmap.md)。
+旧版阶段顺序和检查条件继续有效；没有传入 `complexity` 的旧调用仍按 `.dsh/eng.json` 执行。新任务通过 `complexity` 使用四档自适应流程；旧任务不迁移或改写。
 
 ## 把自己的技能和规则带进来
 
@@ -90,7 +95,8 @@ dsh plugin --profile web add @godv61/dsh-task-engine
 | 想了解什么 | 从这里开始 |
 | :--- | :--- |
 | 安装、启用与第一次使用 | [快速上手](docs/getting-started.md) |
-| 项目配置与阶段绑定 | [流程配置](docs/configuration.md) |
+| 任务级流程、元技能与 SonarQube | [自适应工程任务](docs/adaptive-workflows.md) |
+| 旧项目配置与阶段绑定 | [流程配置](docs/configuration.md) |
 | 技能文件夹与 Markdown 规则 | [资源安装](docs/resource-install.md) |
 | 完整操作说明 | [HTML 手册](docs/manual.html)（下载后在浏览器打开） |
 | 当前能力与常见问题 | [常见问题](docs/faq.md) |

package/docs/CHANGELOG.md

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

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)。旧任务继续按自己的快照执行。
 
 ## 选择流程
 
@@ -53,7 +53,7 @@
 
 **预设不带任何绑定。** 一个只写了 `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` 列出需要命令回执的技能。
 
@@ -69,7 +69,7 @@
 
 阶段顺序、转移条件、产物必填字段和提交策略由所选预设固定。新建规则可以提供工作指引，但不会改变引擎中的提交消息校验或阶段条件。
 
-可视化自定义流程**不在计划内**：它把流程设计的负担转嫁给使用者，而三个内置流程已覆盖个人项目的常见需要。详见[功能规划](roadmap.md)。
+旧版页面不提供可视化编辑任意阶段图。新的任务级四档路径见[自适应工程任务](adaptive-workflows.md)。
 
 ## 配置与正在进行的任务
 

package/docs/faq.md

@@ -10,21 +10,29 @@
 
 安装会添加工作台，但任务工具只在挂载插件 agent 的会话预设中启用。新建会话时选择“工程化开发引擎”，再检查工具是否可用。工作台中的“标准研发”等选项是任务流程，不能代替会话预设开关。
 
-## 能自己增删流程阶段吗？
-
-不支持，且**不打算支持**。可以选择三个内置流程（`standard`、`agile`、`minimal`）并为阶段追加资源，但阶段与条件本身固定。让使用者自行设计流程会把流程设计的负担转嫁给使用者，而内置流程已覆盖个人项目的常见需要。详见[功能规划](roadmap.md)。
+## 能自己增删流程阶段吗？
+
+当前工作台不提供任意编辑阶段图。按每个需求的复杂度选择低、中、高、超高四档任务流程，并允许为元技能挂载 Skill；旧版 `standard`、`agile`、`minimal` 继续兼容。详见[自适应工程任务](adaptive-workflows.md)。
 
 ## 安装资源后就会自动使用吗？
 
-还需要为技能配置规则，再到“流程配置”选择阶段并挂载技能。任务执行时按阶段披露对应内容；安装行为本身不会执行资源中的脚本。
+还需要为技能配置规则，并在「自适应流程」把它挂到元技能；旧版流程则在「旧版流程」挂到阶段。任务执行时按阶段披露对应内容；安装行为本身不会执行资源中的脚本。
 
 ## 改了流程，原来的任务会变化吗？
 
 任务保存创建时的流程快照。修改项目配置不会自动改变进行中的任务；新任务使用保存后的配置。
 
-## 能移除推荐技能、修改内置规则吗？
-
-流程预设没有强制技能绑定。当前安装包只保留会话编排技能 `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#分支提交与当前限制)。
 
 ## 工具显示验证或审核通过，能完全相信吗？
 

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 的其他会话预设，该会话不会启用这套任务工具；侧边栏工作台仍可使用。