@devflow-core/dsh-devflow 0.1.0 → 0.3.0

package/README.md

@@ -13,7 +13,7 @@ npx @deepseek-ai/dsh plugin --profile web add @devflow-core/dsh-devflow
 
 重启后：
 
-1. 新建会话，预设选择器可选 **DevFlow 2.0 (Anchored)**（两阶段锚定 + Code Mode）。
+1. 新建会话，预设选择器可选 **DevFlow 2.0**（两阶段锚定 + Code Mode）。
 2. 会话内 `devflow-*` skills 出现在技能目录，按任务措辞自动触发。
 3. `~/.dsh/commands/` 出现 `devflow*.toml` 斜杠命令，`~/.dsh/scripts/` 出现
    `devflow-*.js` 验证脚本（`node scripts/devflow-plan.js <plan>` 等）。
@@ -73,10 +73,14 @@ devflow-2 预设的 `custom-bash.mjs` 需要 Git Bash 可解析：默认自动
 的 custom-bash 行显式配置 `bashPath` 指向本机 Git（参照
 `docs/dsh-plugins-guide.md` 7.1 节）。
 
-## 发布
+## 发布与更新
+
+完整维护者流程（前置条件、版本 bump、发布命令、错误对照表、git 备选）见
+[RELEASE.md](RELEASE.md)。简版：
 
 ```sh
 cd dsh/plugins/dsh-devflow
 node scripts/sync-assets.js   # 发布前必须重跑，保证资产与仓库根一致
-npm publish
+# bump package.json 版本号
+npm publish --access public --//registry.npmjs.org/:_authToken=<TOKEN>
 ```

package/RELEASE.md

@@ -0,0 +1,128 @@
+# @devflow-core/dsh-devflow — 发布与更新流程
+
+维护者指南：如何发布新版本、用户如何升级、常见错误与修复。用户安装/使用说明见
+[README.md](README.md)。
+
+## 前置条件
+
+| 项 | 要求 |
+|---|---|
+| npm 账号 | 拥有 `@devflow-core` 组织（org）的写权限（创建于 npmjs.com/org/create，免费 public 方案） |
+| npm token | Granular Access Token，**Read and write** + **勾选 "Bypass 2FA for publish"**（或 Automation token）。生成地址：https://www.npmjs.com/settings/<账号>/tokens |
+| Node / pnpm | Node ≥22；pnpm ≥10（发布由 npm CLI 完成，但 `dsh plugin` 安装链路依赖 pnpm） |
+| 仓库 | DevFlow-Core 仓库可写，`dsh/plugins/dsh-devflow/` 子包为发布源 |
+
+> token 不要写进仓库或 .npmrc。发布时用命令行参数临时注入（见下），用完即弃；
+> token 一旦在聊天/日志中暴露，发布后立即到 npm 设置页 revoke 并重新生成。
+
+## 一次完整发布（改代码 → 发布 → 用户升级）
+
+### 1. 修改源码或资产
+
+需要更新的内容都在仓库根：
+
+- 预设：`dsh/agent-presets/devflow-2/`（agent.cordis.yml / preset.yml / tool-bootstrap.mjs / custom-bash.mjs / NOTICE）
+- 技能：`skills/devflow-*/`（SKILL.md 与 references/）
+- 命令：`commands/devflow*.toml`
+- 验证脚本：`scripts/devflow-*.js`（spec/plan/review/debt/audit/doctor）
+- 插件代码：`dsh/plugins/dsh-devflow/lib/`（同步引擎 / 挂载 / announce）
+
+### 2. 根仓库验证不回归
+
+```sh
+npm run verify:all        # 必须全绿（exit 0）
+```
+
+### 3. 刷新子包资产（防漂移）
+
+子包 assets/ 是自包含副本，发布前必须从仓库根重新复制：
+
+```sh
+node dsh/plugins/dsh-devflow/scripts/sync-assets.js
+```
+
+预期输出四行 `synced N entries`；重复运行应幂等（第二次仍成功且无新文件）。
+
+### 4. 子包自测
+
+```sh
+node dsh/plugins/dsh-devflow/test/sync.test.js
+# 预期: DevFlow DSH plugin sync test passed（五场景: 创建/幂等/覆盖/隔离/prune）
+```
+
+### 5. 版本 bump
+
+```sh
+# 编辑 dsh/plugins/dsh-devflow/package.json 的 "version"
+# 语义: patch=缺陷修复, minor=资产/功能更新, major=不兼容变更
+```
+
+发布时使用 CLI 参数临时注入 token（不落盘）：
+
+```sh
+cd dsh/plugins/dsh-devflow
+node scripts/sync-assets.js   # 发布前再跑一次，保证资产最新
+npm publish --access public --//registry.npmjs.org/:_authToken=<TOKEN>
+```
+
+- `--access public` 必须显式给出：scoped 包默认按私有发布，会报 `E402 Payment Required`。
+- `--//registry.npmjs.org/:_authToken=` 是 npm 的 per-registry 参数注入，token 不写入 .npmrc。
+
+### 6. 发布后验证
+
+```sh
+npm view @devflow-core/dsh-devflow version dist-tags.latest
+# 预期输出: 0.1.x 与 latest: 0.1.x
+```
+
+> 新包首次发布后 registry 有约 5 分钟传播延迟，期间 `npm view` 可能 404 属正常；
+> 用 `--prefer-online` 绕过本地缓存。若发布命令报 "cannot publish over the
+> previously published versions"，说明该版本已存在，bump 版本号再发。
+
+### 7. 提交并推送仓库
+
+```sh
+git add -A
+git commit -m "chore(dsh-devflow): release v<新版本>"
+git push origin master
+```
+
+## 用户升级
+
+已安装用户升级到新版本：
+
+```sh
+npx @deepseek-ai/dsh plugin --profile web update @devflow-core/dsh-devflow
+# 或 remove + add 后重启
+```
+
+重启 web 后插件启动时自动把新资产同步到 `~/.dsh/`：
+
+- 字节相同的文件跳过（不覆盖用户 mtime）
+- 不同的文件覆盖（devflow-* 权威）
+- 源不再包含的 devflow-* 残留 prune
+- 非 devflow 资产（atlassian、rtk 等）永不触碰
+- `~/.dsh/.agent-presets/devflow-2/` 整目录归插件管理，目录内非包内文件会被清理
+
+## 常见错误对照表
+
+| 报错 | 原因 | 修复 |
+|---|---|---|
+| `E403 Two-factor authentication or granular access token with bypass 2fa` | token 未勾选 Bypass 2FA | 重新生成 token，勾选 "Bypass 2FA for publish" 或改用 Automation token |
+| `E402 Payment Required - You must sign up for private packages` | scoped 包按私有发布 | 加 `--access public` |
+| `E404 Scope not found` | `@devflow-core` 组织不存在或无权 | 先在 npmjs.com 创建 `devflow-core` org，或改用账号 scope |
+| `E403 You cannot publish over the previously published versions: x.y.z` | 该版本已发布 | bump 版本号再发 |
+| `npm view` 404 但 publish 成功 | registry 传播延迟 / 本地缓存 | 等 5 分钟；`npm view --prefer-online` |
+| `E404 Not found`（view 时） | 包不存在或 scope 无权 | 确认发布成功（`npm view --prefer-online`），或检查 org 归属 |
+
+## 备选：git 分发（不用 npm）
+
+仓库已推送到 GitHub 时，用户也可以不经 npm registry 直接安装：
+
+```sh
+npx @deepseek-ai/dsh plugin --profile web add github:huangwen-changdu/DevFlow-Core#path:dsh/plugins/dsh-devflow
+```
+
+- `dsh plugin` 是 pnpm 转发器，git URL 直接透传；`#path:` 指定仓库内子目录。
+- 无需 npm token/org；更新 = 推送仓库后用户重装。
+- 与 npm 发布二选一即可；npm 发布提供版本化与 `dsh plugin update` 升级路径。

package/assets/commands/devflow-adversarial.toml

@@ -7,5 +7,6 @@ Identify the review target from the request and available task materials. Ask on
 This command is manual and independent: it does not require, read, modify, or hand off to devflow-prove, PUA, Build, Learn, or any completion state.
 Cover requirement coverage, reachability, boundaries and regressions, evidence strength, and user-visible outcome.
 Report only the skill's required findings, five-angle coverage, context limitations, and suggested manual next action.
+On DeepSeek Harness (DSH), dispatch a fresh subagent and run the review in bounded rounds, one round per review angle; the subagent returns each round's findings and the main agent aggregates them into the final report.
 Do not edit files, invoke another skill, create a task, or declare global task status.
 '''

package/assets/commands/devflow-find-fault.toml

@@ -7,5 +7,6 @@ This command is manual and independent: it does not require, read, modify, or ha
 Answer the biggest omission, unrecognized blind spot, and least certain point, plus every explicit user question.
 When reviewing implemented work, also run a post-implementation unease check: find business decisions encoded by the implementation but not explicitly confirmed, classify their risk, and state the confirmation needed.
 Separate facts, inference, and unknowns; give every answer confidence and a next step, then report finding levels, unease decisions, limitations, and suggested manual action.
+On DeepSeek Harness (DSH), dispatch a fresh subagent and run the review in bounded rounds, one round per question and one round for the post-implementation unease check; the subagent returns each round's findings and the main agent aggregates them into the final report.
 Do not edit files, invoke another skill, create a task, or declare global task status.
 '''

package/assets/presets/devflow-2/README.md

@@ -1,4 +1,4 @@
-# DevFlow 2.0 (Anchored) — DeepSeek Harness Agent Preset
+# DevFlow 2.0 — DeepSeek Harness Agent Preset
 
 A DSH agent preset that anchors the FIRST model request on the Minimal
 surface, then promotes into a full DevFlow session: Code Mode (PTC) on the
@@ -19,7 +19,7 @@ wire, the complete DevFlow persona, and the DevFlow lifecycle guaranteed.
   `xiaobright/dsh-anchored-standard`, MIT, extended by `dsh-liangshen`),
   with a `phase1Persona` swap so the DevFlow persona only appears after
   promotion.
-- `preset.yml` — picker metadata (name: DevFlow 2.0 (Anchored)).
+- `preset.yml` — picker metadata (name: DevFlow 2.0).
 
 Skills are NOT bundled: the preset's `skill-filesystem` row uses the default
 user root (`$DSH_HOME/skills`), which is exactly where `npm run install:user`
@@ -46,7 +46,7 @@ cp dsh/agent-presets/devflow-2/NOTICE                ~/.dsh/.agent-presets/devfl
 
 ## Use
 
-Start a new session in the web UI and pick **DevFlow 2.0 (Anchored)** in the
+Start a new session in the web UI and pick **DevFlow 2.0** in the
 preset picker. The roster may need a refresh or restart to show a newly added
 preset. Existing sessions keep their old phase; the two-phase behavior applies
 to new sessions.

package/assets/presets/devflow-2/agent.cordis.yml

@@ -20,7 +20,7 @@
   config:
     shellTools: [bash]
     commonTools: [str_replace_editor]
-    messageSources: [user]
+    messageSources: [user, goal]
     anchorGate: true
     maxBootstrapSteps: 4
     promoteAfterFirstResponse: true
@@ -30,6 +30,9 @@
     deferredSources: [agent-instructions, skill-catalog]
     deferredGraceSteps: 1
     promotedPresentation: code
+    # Aligned with liangshen 0.2.8 (issue #388): after promotion, replace the
+    # full-text AGENTS.md injection with one non-imperative reference hint.
+    instructionHint: true
     phase1Persona: You are a helpful software engineer assistant.
 
 # The `devflow` agent preset: the full coding agent plus DevFlow workflow

package/assets/presets/devflow-2/preset.yml

@@ -1,3 +1,3 @@
-name: DevFlow 2.0 (Anchored)
+name: DevFlow 2.0
 description: DevFlow 开发工作流 + 梁神式两阶段锚定：首个请求只暴露一行 persona（You are a helpful software engineer assistant.）+ 最小工具对（持久 bash + str_replace_editor），无运行时上下文与任何注入；anchorGate 门控（首个 minimal-like 推理块或 4 步兜底）+ 1024 输出预算稳定锚定后，晋升为 Code Mode（单一 run_code），恢复完整 DevFlow 人设并自动激活 devflow-core 生命周期（Brainstorm → Spec/Cut → Plan → Build → Prove）与验证完成闭环；workspace 指令与技能目录延迟一步注入。
 order: 6

package/assets/presets/devflow-2/tool-bootstrap.mjs

@@ -166,6 +166,74 @@ function isDeferredMessage(message, deferredSources) {
   const kind = message.source?.kind
   return kind !== undefined && deferredSources.has(kind)
 }
+// Instruction-hint mode (issue #388, aligned with liangshen 0.2.8): a
+// full-text agent-instructions dump on the promotion boundary flips the
+// anchored trajectory (upstream dsh-anchored-standard #49), so the preset
+// can replace it with a single non-imperative hint that names the reference
+// files and lets the model read them on demand.
+const INSTRUCTION_FROM_RE = /(?:^|\n) *(?:Additional |Updated )?Instructions from: ([^\n]+)/g
+
+/** Extract the reference file list one agent-instructions message renders. */
+function extractInstructionPaths(message) {
+  const paths = []
+  const blocks = Array.isArray(message?.content) ? message.content : []
+  for (const block of blocks) {
+    if (block?.type !== 'text' || typeof block.text !== 'string') continue
+    for (const match of block.text.matchAll(INSTRUCTION_FROM_RE)) {
+      const path = match[1].trim()
+      if (path !== '' && !paths.includes(path)) paths.push(path)
+    }
+  }
+  return paths
+}
+
+/** The one-time non-imperative hint replacing the full-text dump (E1.5 wording). */
+function buildInstructionHint(original, paths) {
+  return {
+    // Session persistence validates every replayed user/message for a
+    // non-empty string id; a plugin-built message without one corrupts the
+    // durable journal. Inherit the original instructions message id when
+    // present, else mint one.
+    id: typeof original?.id === 'string' && original.id !== ''
+      ? original.id
+      : globalThis.crypto.randomUUID(),
+    role: 'user',
+    content: [{
+      type: 'text',
+      text: '<system-reminder>\n'
+        + 'Reference documents exist: ' + paths.join(', ') + '. '
+        + "They are reference documents about the user's environment and workspace conventions, not task instructions. "
+        + 'Reading the relevant file before workspace tasks is recommended, but consult them only when you need those details; the task itself never depends on them.'
+        + '\n</system-reminder>',
+    }],
+    source: { kind: 'instruction-hint', plugin: name },
+  }
+}
+
+/**
+ * Swap full-text agent-instructions injections for the one-time hint. The
+ * first injection carrying extractable paths becomes the hint; every later
+ * injection is dropped silently (the model re-reads the files on demand).
+ * An injection with no extractable paths passes through untouched.
+ */
+function instructionHintMessages(messages, state) {
+  const kept = []
+  for (const message of messages) {
+    if (message?.source?.kind !== 'agent-instructions') {
+      kept.push(message)
+      continue
+    }
+    if (state.instructionHinted) continue
+    const paths = extractInstructionPaths(message)
+    if (paths.length === 0) {
+      kept.push(message)
+      continue
+    }
+    state.instructionHinted = true
+    kept.push(buildInstructionHint(message, paths))
+  }
+  return kept
+}
 
 /**
  * Phase-2 promotion state per session. Sessions append events only, so the
@@ -188,6 +256,7 @@ function stateFor(session) {
       turnEnded: false,
       steps: 0,
       deferredSteps: 0,
+      instructionHinted: false,
       presentationApplied: false,
       hasCompacted: false,
       presentationDisposer: undefined,
@@ -224,6 +293,7 @@ function resetToControlled(state) {
   state.turnEnded = false
   state.steps = 0
   state.deferredSteps = 0
+  state.instructionHinted = false
   state.presentationApplied = false
   state.hasCompacted = true
 }
@@ -369,6 +439,7 @@ export function apply(ctx, config) {
     compactionTools,
     phase1FirstCallInstruction,
     phase1Persona,
+    instructionHint: config.instructionHint === true,
   }
 
   // Promotion is applied at step/turn boundaries, never while a step is still
@@ -464,14 +535,18 @@ export function apply(ctx, config) {
         messages: decision.messages.filter(message => isAllowedMessage(message, messageSources)),
       }
     }
+    let result = decision
     if (state.deferredSteps < policy.deferredGraceSteps) {
       state.deferredSteps += 1
-      return {
-        ...decision,
-        messages: decision.messages.filter(message => !isDeferredMessage(message, deferredSources)),
+      result = {
+        ...result,
+        messages: result.messages.filter(message => !isDeferredMessage(message, deferredSources)),
       }
     }
-    return decision
+    if (policy.instructionHint) {
+      result = { ...result, messages: instructionHintMessages(result.messages, state) }
+    }
+    return result
   }, { prepend: true })
 
   // Phase 1 caps the next request output budget to bootstrapMaxTokens, the
@@ -493,4 +568,4 @@ export function apply(ctx, config) {
     }
     return { ...resolved, maxTokens: policy.bootstrapMaxTokens }
   }, { prepend: true })
-}
+}

package/assets/skills/devflow-adversarial/SKILL.md

@@ -1,12 +1,14 @@
 ---
 name: devflow-adversarial
-description: "Use when a user explicitly asks for an independent deep adversarial review, upgraded adversarial review, red-team review, 对抗审查, 升级版对抗审查, or a five-angle challenge of current work. It can run at any task stage and does not read, require, modify, or hand off to devflow-prove, PUA, Build, Learn, or any completion state."
+description: "Use when a user explicitly asks for an independent deep adversarial review, upgraded adversarial review, red-team review, 对抗审查, 升级版对抗审查, 红队审查, 五角度挑战, or a five-angle challenge of current work. It can run at any task stage and does not read, require, modify, or hand off to devflow-prove, PUA, Build, Learn, or any completion state."
 ---
 
 # DevFlow Adversarial Review
 
 Run an independent, user-requested challenge of the current task materials. This skill does not declare global task status or perform work beyond review.
 
+Use this skill when the user asks to challenge whether the current result holds. When the user asks what is missing or uncertain instead, use `devflow-find-fault`.
+
 ## Entry Gate
 
 1. Confirm the user explicitly requested this review.
@@ -14,7 +16,9 @@ Run an independent, user-requested challenge of the current task materials. This
 3. If the target is unclear, ask one smallest question to identify it.
 4. As an independent manual review, do not read, require, or alter `devflow-prove`, PUA, Build, Learn, or any lifecycle state.
 
-On DeepSeek Harness (DSH), run this review as a fresh `subagent` with no conversation seed so the challenge is genuinely independent of the main agent's reasoning; the subagent returns findings only and never declares lifecycle status, edits files, or invokes another skill.
+On DeepSeek Harness (DSH), dispatch a fresh `subagent` so the challenge stays independent of the main agent's reasoning. Call the `subagent` tool once with `run_in_background: false` and a complete standalone prompt that names the review target and the material paths, and instructs the subagent to read those materials and return evidence-backed findings (the subagent has no conversation seed and cannot see this conversation). Then run the review in bounded rounds, one review unit per round: after each round the subagent returns that unit's findings, you aggregate them and report progress, then continue the same subagent conversation with the `send_message` tool. After the final unit, assemble the complete `Required Output` below from the aggregated findings. The subagent returns findings only — it never declares lifecycle status, edits files, or invokes another skill. If a round returns nothing usable (timeout, truncation, or failure), record it under `Context limitations`, retry that unit once with a narrower instruction, and continue with the remaining units; never silently drop a unit.
+
+Review units: one of the five angles per round, five rounds in total.
 
 ## Five-Angle Review
 
@@ -37,6 +41,7 @@ Findings:
 - Critical: <finding or none>; evidence: <facts>; confidence: high/medium/low
 - Important: <finding or none>; evidence: <facts>; confidence: high/medium/low
 - Observation: <finding or none>; evidence: <facts>; confidence: high/medium/low
+Repeat one bullet per finding; order findings by severity, then confidence; write none when a level has no finding.
 Five-angle coverage:
 - Requirement coverage: <challenge and result>
 - Reachability: <challenge and result>

package/assets/skills/devflow-build/SKILL.md

@@ -15,20 +15,15 @@ Receives a `CUT_PASS` Cut Decision from `devflow-cut`, either through the direct
 - Depth C input: `CUT_PASS` plus the approved design contract; no Plan Pack is required.
 
 When no plan file exists, the approved design and Cut Decision form the Build Contract basis; skip the plan checker.
-## Plan Review
+## Direct Execution
 
-Load `skills/devflow-build/references/build-methods.md` after this review and before implementation slices. It owns the detailed minimal-change and slice discipline.
+Load `skills/devflow-build/references/build-methods.md` after this section and before implementation slices. It owns the detailed minimal-change and slice discipline.
 
-Before editing, reconcile the plan against the current codebase — executability review, not redesign:
+There is no pre-edit plan review. The executor reads only the current task's execution spec — `Files`, `Change mechanics`, `Steps`, `Verify` — from the approved plan, edits those files directly, runs `Verify`, and appends actual evidence. An actual edit or verification failure must stop and return `BUILD_BLOCKED` with the facts to `devflow-core`: the observed mismatch, affected anchor, and smallest replan decision. Do not pre-check anchors, do not guess, do not silently repair the plan.
 
-1. Anchors: every `Modify` symbol/anchor and interface in the plan still exists and matches.
-2. Behavior: each task's `Current behavior` still describes the code.
-3. Steps: unambiguous, with verification commands that can run in this environment.
-4. Skills: every skill declared in `External Skills` (Cut Decision or plan header) is actually loaded through the platform's skill mechanism, or the reason it does not apply is recorded; loading alone is not completion — Build requires the specialist's returned result, not-applicable, or failure facts. A specialist result implying structure outside the approved scope returns scope-drift facts to `devflow-core`, not silent adoption.
+Every skill declared in `External Skills` (Cut Decision or plan header) must actually be loaded through the platform's skill mechanism, or the reason it does not apply recorded; loading alone is not completion — Build requires the specialist's returned result, not-applicable, or failure facts. A specialist result implying structure outside the approved scope returns scope-drift facts to `devflow-core`, not silent adoption. Skill loading is not a pre-edit view and remains mandatory.
 
-Any failed check, unclear instruction, or critical gap: stop and return `BUILD_BLOCKED` with the facts to `devflow-core`. Do not guess, do not silently repair the plan. Reviewing fidelity is not re-deciding the mechanism.
-
-For Depth C (no Plan Pack), run the same review against the approved design contract: confirm the symbols and behaviors it names still exist. Depth C keeps Build freedom inside the Cut Decision; it does not skip this review or the Stop Protocol.
+For Depth C (no Plan Pack), the approved design contract is the execution spec: edit directly from it without a separate reconciliation pass. Depth C keeps Build freedom inside the Cut Decision; it does not skip the Stop Protocol.
 
 ## Build Contract
 
@@ -51,7 +46,7 @@ When saving a plan file, use `docs/plans/YYYY-MM-DD-<short-kebab-name>.md`, reso
 
 For multi-step work, tasks must cite the approved source, be small and verifiable, and follow the required task contract (Task: / Task type: / Files: / Interfaces: / Current behavior: / Target behavior: / Change mechanics: / Call impact: / Steps: / Acceptance: / Verify: / Comments: / Not doing:) defined in `skills/devflow-plan/SKILL.md`.
 
-No unresolved markers. For `Code change`, follow the recorded file symbol/anchor, `Current behavior`, `Target behavior`, `Change mechanics`, and `Call impact`; do not re-decide the implementation mechanism in Build. The verification step must retain its trigger/input, expected result, and command or manual scenario. `Documentation-only` applies only to tasks with no runtime code files and explicit `documentation-only` interfaces. No "add tests" without naming the behavior. No "handle edge cases" without naming the edge case. No "similar to Task N" shortcuts; repeat enough detail for each task to stand alone.
+No unresolved markers. For `Code change`, the dispatched execution spec follows the recorded file symbol/anchor and `Change mechanics`; do not re-decide the implementation mechanism in Build. `Current behavior`, `Target behavior`, and `Call impact` are the plan author's records, not executor re-read requirements. The verification step must retain its trigger/input, expected result, and command or manual scenario. `Documentation-only` applies only to tasks with no runtime code files and explicit `documentation-only` interfaces. No "add tests" without naming the behavior. No "handle edge cases" without naming the edge case. No "similar to Task N" shortcuts; repeat enough detail for each task to stand alone.
 
 Before Build, run `node scripts/devflow-plan.js <plan-file>` when a plan is saved to a file. If not found at `scripts/devflow-plan.js` (project-level), try `~/.codex/scripts/devflow-plan.js` or `~/.claude/scripts/devflow-plan.js` (user-level). Do NOT look under `skills/scripts/`. See `core-methods.md` Script Path Resolution.
 
@@ -85,21 +80,21 @@ Rules:
 
 ## Execution Mode
 
-The plan's `Execution mode` (`sequential` | `single-subagent` | `fan-out`) is chosen at Plan approval and passed to Build; Build does not re-decide it. `sequential` runs tasks in dependency order as the Build agent itself; `single-subagent` delegates the whole plan to one executor subagent while the main agent only schedules; `fan-out` runs independent tasks as parallel subagents and dependent tasks in sequence after their inputs land.
+The plan's `Execution mode` (`sequential` | `single-subagent` | `fan-out`) is chosen at Plan approval and passed to Build; Build does not re-decide it. `sequential` runs tasks in dependency order as the Build agent itself; `single-subagent` dispatches one task's execution spec at a time to one executor subagent while the main agent only schedules; `fan-out` runs independent tasks as parallel subagents and dependent tasks in sequence after their inputs land.
 
 ### Single-subagent dispatch
 
-- The main agent does not execute tasks. It dispatches the whole approved Plan Pack to one executor subagent, waits for the return, and then merges the returned evidence and enters Prove once.
-- The subagent runs all tasks in dependency order inside one context under the same Plan Review and Prewalk read discipline, appends actual evidence to the plan's Execution Trace, and returns the merged task results and evidence, or `BUILD_BLOCKED` facts.
+- The main agent does not execute tasks. It dispatches one task's execution spec at a time to one executor subagent, waits for the return, and then merges the returned evidence and enters Prove once.
+- The subagent edits that task's `Files` directly, runs its `Verify`, appends actual evidence, and returns the task results and evidence, or `BUILD_BLOCKED` facts. On DSH, one task per subagent round; the next task continues through `send_message`; a timeout or truncated return retries that task once.
 - The main agent may send one bounded follow-up when the return misses evidence; anything still incomplete is returned to `devflow-core` as `BUILD_BLOCKED` facts. The subagent never declares done, never enters Prove, and never re-decides the mode or the Cut scope.
 
 ### Fan-out dispatch
 
 - Two tasks may run in parallel only when their `Files` touch disjoint file/symbol sets and neither `Interfaces` consumes a symbol the other `Produces`; otherwise run the producer first.
-- Each subagent runs one task contract under the same Plan Review and Prewalk read discipline, and returns the task result or `BUILD_BLOCKED` facts.
+- Each subagent receives only its task's execution spec, edits its task's `Files` directly, runs its `Verify`, and returns the task result or `BUILD_BLOCKED` facts.
 - The main agent merges returned results, reconciles cross-task file overlap, runs the unified `Diff Self-Check`, and enters `devflow-prove` once with merged evidence — never per-subagent.
 
-`single-subagent` and `fan-out` are scheduling only; they do not change Plan Review, Stop Protocol, Cut scope, or the single Prove gate.
+`single-subagent` and `fan-out` are scheduling only; they do not change Cut scope, Stop Protocol, or the single Prove gate.
 
 ## Source Check
 
@@ -196,7 +191,7 @@ If any file has no goal link, remove that change.
 | "We'll verify everything at the end." | Verify slices when focused checks exist. |
 | "Docs changes do not need proof." | Docs/rules/skills need validation just like code. |
 | "The issue only mentions one caller." | Check sibling callers before choosing the fix location. |
-| "The plan is approved, so I just execute." | Plan Review comes first: stale anchors or unclear steps return `BUILD_BLOCKED` to Core. |
+| "The plan is approved, so I just execute." | Right: the approved execution spec is edited directly; an actual edit or verification failure returns `BUILD_BLOCKED` to Core. |
 | "I'll infer the missing step." | Guessing past a gap is forbidden; unclear instructions return `BUILD_BLOCKED` facts. |
 | "The code is self-explanatory." | That does not waive a comment required by the approved contract, project convention, or a non-obvious boundary. |
 | "Comments will get stale." | Keep a required comment accurate or remove a stale one; a stale explanation is not a reason to skip a needed decision record. |
@@ -207,7 +202,7 @@ If any file has no goal link, remove that change.
 
 Stop executing immediately and return `BUILD_BLOCKED` with the blocking facts to `devflow-core` when:
 
-- a Plan Review check fails (dead anchor, stale behavior, missing interface, unclear step)
+- an edit cannot be applied or a verification fails (dead anchor, stale behavior, missing interface, unclear step)
 - a dependency, tool, or declared external skill is missing and the task depends on it, or its returned failure facts block the approved work
 - verification fails repeatedly for the same task
 - the plan has a critical gap that prevents starting or continuing
@@ -228,7 +223,7 @@ Known unverified: ...
 
 Before leaving this skill, confirm:
 
-- [ ] Plan Review passed or concerns were returned to `devflow-core` as `BUILD_BLOCKED`.
+- [ ] Direct Execution completed — each task's spec was edited directly and verified, or actual failures were returned to `devflow-core` as `BUILD_BLOCKED`.
 - [ ] Declared external skills were loaded, or the exception reason was recorded in `Skills loaded`.
 - [ ] Build contract exists.
 - [ ] Cut gates passed or were run.

package/assets/skills/devflow-find-fault/SKILL.md

@@ -7,6 +7,8 @@ description: "Use when a user explicitly asks to find faults, identify the bigge
 
 Run an independent, user-requested critique of the current task materials. This skill identifies gaps and uncertainty without declaring global task status.
 
+Use this skill when the user asks what is missing, unrecognized, or uncertain. When the user asks a five-angle challenge of whether the result holds instead, use `devflow-adversarial`.
+
 ## Entry Gate
 
 1. Confirm the user explicitly requested find-fault review.
@@ -14,12 +16,16 @@ Run an independent, user-requested critique of the current task materials. This
 3. Ask one smallest question when the target is unclear.
 4. As an independent manual review, do not read, require, or alter `devflow-prove`, PUA, Build, Learn, or any lifecycle state.
 
-On DeepSeek Harness (DSH), run this review as a fresh `subagent` with no conversation seed so the critique is genuinely independent of the main agent's reasoning; the subagent returns findings only and never declares lifecycle status, edits files, or invokes another skill.
+On DeepSeek Harness (DSH), dispatch a fresh `subagent` so the critique stays independent of the main agent's reasoning. Call the `subagent` tool once with `run_in_background: false` and a complete standalone prompt that names the review target and the material paths, and instructs the subagent to read those materials and return evidence-backed findings (the subagent has no conversation seed and cannot see this conversation). Then run the review in bounded rounds, one review unit per round: after each round the subagent returns that unit's findings, you aggregate them and report progress, then continue the same subagent conversation with the `send_message` tool. After the final unit, assemble the complete `Required Output` below from the aggregated findings. The subagent returns findings only — it never declares lifecycle status, edits files, or invokes another skill. If a round returns nothing usable (timeout, truncation, or failure), record it under `Context limitations`, retry that unit once with a narrower instruction, and continue with the remaining units; never silently drop a unit.
+
+Review units: one question per round — the three default questions and every user-supplied question — plus one final round for the unease check when the target contains implementation material.
 
 ## Post-Implementation Unease Check
 
 When target materials include an implemented feature, diff, or completion-ready result, also inspect whether the implementation has silently decided business behavior the user never confirmed. This check is for requirement-confidence gaps, not code quality or test coverage.
 
+When the target contains no implementation material (no diff, no new code, no completion-ready result), skip the unease check and report `Unease check: not applicable` with the reason; do not invent business decisions from requirements text alone.
+
 1. Compare explicit requirements, conversation evidence, acceptance criteria, and current behavior against the implementation.
 2. List every material decision with no direct confirmation, especially: ordering, filtering, defaults, empty states, pagination, permissions, state transitions, exceptions, retries, boundary inputs, and conflicting actor outcomes.
 3. For each decision, state the encoded behavior or implicit assumption, plausible alternative interpretations, impact if wrong, the confirmation question, and a temporary recommendation.
@@ -78,6 +84,7 @@ Findings:
 - Critical: <finding or none>; evidence: <facts>; confidence: high/medium/low
 - Important: <finding or none>; evidence: <facts>; confidence: high/medium/low
 - Observation: <finding or none>; evidence: <facts>; confidence: high/medium/low
+Repeat one bullet per finding; order findings by severity, then confidence; write none when a level has no finding.
 Context limitations: <unavailable material or none>
 Suggested next action: <manual action for the user, or none>
 ```

package/assets/skills/devflow-plan/SKILL.md

@@ -18,11 +18,11 @@ Turn an A/B `CUT_PASS`-bounded approved design or confirmed Spec into one review
 1. Read only source material, code, tests, and conventions relevant to the approved scope. Load `skills/devflow-spec/references/spec-plan-methods.md` and `skills/devflow-plan/references/plan-methods.md` before applying Plan Pack mechanics.
 2. Map exact affected file responsibilities once in `## File Structure` before writing tasks. Reuse existing modules and name the intended file operation.
 3. Perform bounded real investigation and record it as task-level `Prewalk`: actual `Execution Trace`, Current Handoff Facts, and only the unfinished `Remaining Structured Worklist`.
-4. Split independent deliverables into small, reviewable tasks. Each task should be understandable without referring to another task.
+4. Split independent deliverables into small, reviewable tasks. Each task should be understandable without referring to another task, and it carries its own complete execution spec（执行规范）— `Files`, `Change mechanics`, `Steps`, and `Verify` — so the executor edits directly from the task without re-reading the plan or the code for a pre-edit view（零 view）.
 5. Write the plan using the required header and task contract below.
 6. Self-review Cut Decision fidelity, source coverage, File Structure, Prewalk evidence, file-operation classifications, interface consistency, concrete steps, acceptance proof, and scope exclusions.
 7. Run `node scripts/devflow-plan.js <plan-file>` when the project-level checker exists. Otherwise resolve the user-level checker according to `core-methods.md` Script Path Resolution.
-8. **STOP — request user review.** On DSH, request review with the structured `ask_user_question` tool (single-select: approve / request changes). Revise and revalidate when requested. On approval, ask execution mode (single-select: `sequential` — the Build agent runs tasks in dependency order / `single-subagent` — the main agent only schedules: one subagent runs all tasks in dependency order / `fan-out` — independent tasks run as parallel subagents) and record it as the plan's optional `Execution mode` header. Then perform only a lightweight Cut-consistency review. An approved A/B Plan directly enters `devflow-build`; scope-drift facts return to `devflow-core`.
+8. **STOP — request user review.** On DSH, request review with the structured `ask_user_question` tool (single-select: approve / request changes). Revise and revalidate when requested. On approval, ask execution mode (single-select: `sequential` — the Build agent runs tasks in dependency order / `single-subagent` — the main agent only schedules: one subagent runs tasks one per round in dependency order / `fan-out` — independent tasks run as parallel subagents) and record it as the plan's optional `Execution mode` header. Then perform only a lightweight Cut-consistency review. An approved A/B Plan directly enters `devflow-build`; scope-drift facts return to `devflow-core`.
 
 Default landing is `docs/plans/YYYY-MM-DD-<short-kebab-name>.md`, resolved from the target project root. Do not place implementation plans in `docs/features/` or `docs/specs/`.
 
@@ -56,6 +56,8 @@ Inherit `External Skills` from the Cut Decision unchanged; the Plan Pack carries
 
 `Execution mode` is not part of Cut scope and does not change the checker. It is asked at approval and recorded so Build knows how to run tasks: sequentially as the Build agent itself, through one delegated subagent while the main agent only schedules, or fan out independent tasks to parallel subagents.
 
+Each task's `Files`, `Change mechanics`, `Steps`, and `Verify` form the only execution basis（执行规范）handed to the executor: dispatch sends just these fields, and the executor edits directly from them without a pre-edit view of the plan document, the code, or the anchors. `Read-basis` / `Live anchors` remain the plan author's evidence record, not executor re-read instructions.
+
 ## Required Task Contract
 
 ```text
@@ -90,7 +92,7 @@ Execution Trace:
 - Verified: <actual check> → <observed result; or "none yet">.
 
 Current Handoff Facts:
-- Target anchors: <current file, symbol, or range that Build minimally re-reads>.
+- Target anchors: <current file, symbol, or range the plan author verified (evidence record, not executor re-read instruction)>.
 - Nearby convention: <comparable inspected code and observed convention; or "no comparable code found">.
 - Direct path: <traced callers, collaborators, boundaries, affected tests; or "none">.
 - Current constraints: <observed contract, ordering, errors, compatibility; or "none">.
@@ -104,7 +106,7 @@ Remaining Structured Worklist:
   Done when: <fact proving this action is complete>.
 ```
 
-`File Structure` is one responsibility map, not a fixed architecture rule. For every non-trivial Code change, every task must carry a `Prewalk`. Each trace row records an action actually performed and its observed result; it cannot describe planned work. `Remaining Structured Worklist` contains only unfinished actions. Each item needs `Anchors`, `Verify`, and `Done when`; cap one task at 12 items. Build reads the latest trace first, minimally re-reads the current item's anchors and directly changed neighbor, appends actual evidence after the item, and returns facts to `devflow-core` if anchors, contracts, conventions, direct dependencies, responsibility, or directly necessary touch set contradict the handoff. Documentation-only tasks retain their existing exception.
+`File Structure` is one responsibility map, not a fixed architecture rule. For every non-trivial Code change, every task must carry a `Prewalk`. Each trace row records an action actually performed and its observed result; it cannot describe planned work. `Remaining Structured Worklist` contains only unfinished actions. Each item needs `Anchors`, `Verify`, and `Done when`; cap one task at 12 items. The executor reads the current task's execution spec (`Files`, `Change mechanics`, `Steps`, `Verify`), edits directly, runs `Verify`, appends actual evidence, and returns the observed difference as facts to `devflow-core` only when an edit or verification actually fails — there is no pre-edit plan or code view. Documentation-only tasks retain their existing exception.
 
 Use only `Create`, `Modify`, and `Test` file-operation labels. For a `Code change`, every existing-file row must name a symbol or stable anchor; `Create` rows use `new file`. `Current behavior`, `Target behavior`, `Change mechanics`, and `Call impact` are mandatory. `Change mechanics` must contain the smallest code snippet, pseudocode, or exact replacement rule that removes implementation inference. Interfaces name exact symbols and input/output shape. The verification step and `Verify` field name the trigger/input, expected result, and runnable command or manual scenario.
 
@@ -112,7 +114,7 @@ Use only `Create`, `Modify`, and `Test` file-operation labels. For a `Code chang
 
 ## Boundaries
 
-Plan generation does not repeat Cut, perform Build or Prove, prescribe independent review, test-first workflow, version-control task steps, or execute automatically. It converts `CUT_PASS` into a static construction checklist. The checker validates static structure; it does not judge architecture or lifecycle state.
+Plan generation does not repeat Cut, perform Build or Prove, prescribe independent review, test-first workflow, version-control task steps, or execute automatically. It converts `CUT_PASS` into a static construction checklist. The checker validates static structure; it does not judge architecture or lifecycle state. Plan generation writes the execution spec（执行规范）; the zero-view（零 view）execution discipline belongs to `plan-methods.md` and `devflow-build` — a Plan Pack must not include execution-phase re-read or pre-edit review instructions.
 
 ## Anti-Rationalization
 
@@ -136,7 +138,7 @@ Before leaving this skill, confirm:
 - [ ] `Spec coverage` maps the source to plan tasks.
 - [ ] Header, constraints, File Structure, interfaces, concrete steps, acceptance, verification, context-specific comments, exclusions, and task-level Prewalk records are present.
 - [ ] Each trace entry is an observed past action/result; each remaining worklist item is bounded, verified, and fact-complete.
-- [ ] Every task is independently understandable, requires only minimal anchor reread, and has no unresolved or vague placeholder.
+- [ ] Every task is independently understandable, requires no pre-edit read, and has no unresolved or vague placeholder.
 - [ ] The checker passed when available.
 - [ ] The user reviewed the written plan.
 - [ ] An approved A/B Plan entered `devflow-build`; any scope-drift facts returned to `devflow-core`.

package/assets/skills/devflow-plan/references/plan-methods.md

@@ -29,14 +29,14 @@ Execution Trace:
 - Verified: [actual check] → [observed result; or "none yet"].
 
 Current Handoff Facts:
-- Target anchors: [minimum current anchors for the next executor].
+- Target anchors: [current file/symbol/range the plan author verified; evidence record, not executor re-read instruction].
 - Nearby convention: [inspected comparable code and observed convention; or "no comparable code found"].
 - Direct path: [traced callers, collaborators, boundaries, affected tests; or "none"].
 - Current constraints: [observed contract, ordering, error behavior, compatibility; or "none"].
 - Planned touch set: [remaining expected files/symbols and reason].
 - Risks / stop conditions: [facts that require Core replan; or "none beyond ordinary Plan drift"].
-- Read-basis: [已读文件清单——执行者无需重读].
-- Live anchors: [仅需现场确认的锚点——执行者只读这些].
+- Read-basis: [已读文件清单——计划作者的证据簿记，执行者不重读].
+- Live anchors: [计划作者已确认的锚点——执行者不重读，仅作失败回报时的定位].
 
 Remaining Structured Worklist:
 - [ ] [one independently completable remaining action with file/symbol and expected outcome].
@@ -61,14 +61,14 @@ Remaining Structured Worklist:
 
 ## Delegated Execution
 
-A delegated executor reads the latest trace, then minimally re-reads the current work item's anchors and directly changed neighbor. It does not repeat File Structure decisions or broadly reread the repository by default. The executor determines its read set from `Current Handoff Facts`: it must not re-read the `Read-basis` list and only live-verifies the `Live anchors`; anchor contradiction still returns facts to `devflow-core`.
+A delegated executor — the main agent itself, one delegated subagent, or one fan-out subagent — never re-reads the plan document, the latest trace, the anchors, the goal, or the code for a pre-edit view. It receives only the current task's execution spec (`Files`, exact replacement rules, `Steps`, `Verify`), edits those files directly, runs the task's `Verify` command, and returns actual evidence or failure facts to the orchestrating Build agent. `Read-basis` and `Live anchors` stay in the plan as the plan author's evidence record (the checker requires them); they are not executor re-read instructions.
 
-Stop and return facts to `devflow-core` when the minimal reread shows a contradiction in any target anchor, direct caller, contract, local convention, dependency, side effect, affected test, responsibility, or directly necessary touch set. The return identifies the observed mismatch, affected anchor, invalidated handoff fact, blocked verification, and smallest replan decision. An obvious stale line reference may be corrected without returning only when the symbol, contract, responsibility, and intended outcome are unchanged.
+When an edit cannot be applied or a `Verify` fails, the executor returns the observed difference — affected file/anchor, actual behavior, blocked verification, and smallest replan decision — as facts to `devflow-core`; it does not pre-check anchors and does not guess past a failed edit. A stale line reference may be corrected without returning only when the symbol, contract, responsibility, and intended outcome are unchanged.
 
 ### Fan-out
 
-When the plan's `Execution mode` is `fan-out`, one Build orchestrator partitions tasks into parallel groups and dispatches each task to a subagent. Every subagent follows the same per-task read discipline above: read the latest trace, minimally re-read only its task's anchors (`Read-basis` / `Live anchors`), execute only its task's `Files`, and return evidence or contradiction facts. Two tasks may run in parallel only when their `Files` touch disjoint file/symbol sets and neither `Interfaces` consumes a symbol the other `Produces`; tasks sharing a file/symbol or with a consume/produce dependency run in sequence. The orchestrator merges returned results, reconciles cross-task overlap, and enters Prove once with merged evidence.
+When the plan's `Execution mode` is `fan-out`, one Build orchestrator partitions tasks into parallel groups and dispatches each task to a subagent. Every subagent receives only its own task's execution spec, edits its task's `Files` directly, runs its task's `Verify`, and returns evidence or failure facts; it does not re-read the plan, the trace, the anchors, or the code. Two tasks may run in parallel only when their `Files` touch disjoint file/symbol sets and neither `Interfaces` consumes a symbol the other `Produces`; tasks sharing a file/symbol or with a consume/produce dependency run in sequence. The orchestrator merges returned results, reconciles cross-task overlap, and enters Prove once with merged evidence.
 
 ### Single-subagent
 
-When the plan's `Execution mode` is `single-subagent`, the main agent only schedules: it dispatches the whole approved Plan Pack to one executor subagent, waits for the return, then merges the returned evidence and enters Prove once. The subagent runs all tasks in dependency order inside one context under the same per-task read discipline above: read the latest trace, minimally re-read only the current item's `Anchors` / `Live anchors`, execute only the task's `Files`, append actual evidence to the plan trace, and return merged results and evidence, or `BUILD_BLOCKED` facts. Nothing runs in parallel; prefer this mode for small to medium plans or plans whose tasks are strongly dependent, and keep `fan-out` for large parallel plans.
+When the plan's `Execution mode` is `single-subagent`, the main agent only schedules: it dispatches one task's execution spec at a time to one executor subagent, waits for the return, then merges the returned evidence and enters Prove once. The main agent dispatches one task at a time — only that task's execution spec, not the whole plan. The subagent edits that task's `Files` directly, runs its `Verify`, appends actual evidence, and returns the task results and evidence or `BUILD_BLOCKED` facts; the next task continues the same subagent conversation through `send_message`. On DeepSeek Harness (DSH), subagent turns are time-bounded, so one task per round is the norm; a timeout or truncated return retries that one task once with a narrower instruction. The subagent never re-reads the plan, the trace, the anchors, or the code for a pre-edit view. Nothing runs in parallel; prefer this mode for small to medium plans or plans whose tasks are strongly dependent, and keep `fan-out` for large parallel plans.

package/assets/skills/devflow-prove/references/flow-self-test.md

@@ -219,6 +219,8 @@ Expected behavior:
 - Must begin after the explicit review request without a separate confirmation prompt. Must not add a second confirmation gate after the explicit review request.
 - Must ask one smallest question only when the review target is unclear.
 - Must cover all five fixed dimensions: requirement coverage, reachability, boundaries and regressions, evidence strength, and user-visible outcome.
+- Must run on DSH in bounded rounds, one round per review angle, with the subagent returning each round's findings to the main agent for aggregation.
+- Must dispatch a fresh subagent.
 - Findings must use `Critical`, `Important`, or `Observation` and include evidence, confidence, and context limitations.
 - Must not read, require, modify, or hand off to `devflow-prove`, PUA, Build, Learn, or any completion state.
 - Must not edit code, create a task, invoke another skill, or declare global task status.
@@ -249,6 +251,8 @@ Expected behavior:
 - Must run only because the user explicitly requested it; it may inspect materials from any task stage.
 - Must answer biggest omission, unrecognized blind spot, and least certain point, plus every explicit user follow-up question.
 - When target material contains implemented work, a diff, or a completion-ready result, must also run the post-implementation unease check: find materially unconfirmed business decisions, show the encoded assumption and alternatives, then classify high/medium/low risk with rationale, a user confirmation question, and temporary recommendation.
+- Must run on DSH in bounded rounds, one round per question or unease-check block, with the subagent returning each round's findings to the main agent for aggregation.
+- Must dispatch a fresh subagent.
 - High-risk unease decisions must prevent a claim that the feature fully meets requirements; medium-risk decisions must be marked `pending confirmation`.
 - Each answer must separate facts, inference, and unknowns, then state confidence and a next step; findings must use `Critical`, `Important`, or `Observation` with evidence and context limitations.
 - Must not read, require, modify, or hand off to `devflow-prove`, PUA, Build, Learn, or any completion state.

package/lib/index.js

@@ -29,7 +29,7 @@ export function bundledAssetsRoot() {
 
 /** Model-facing announcement: plugin presence, preset, and conflict policy. */
 export const DEVFLOW_GUIDANCE =
-  '本机已安装 @devflow-core/dsh-devflow 插件（DevFlow agent preset 分发）：新建会话的预设选择器中可选「DevFlow 2.0 (Anchored)」（两阶段锚定 + Code Mode）。插件启动时把 devflow-2 预设、devflow-* skills、devflow*.toml 命令与 devflow-*.js 验证脚本同步到 ~/.dsh/（.agent-presets/skills/commands/scripts）；冲突策略为 devflow-* 权威覆盖（字节相同跳过），非 devflow 资产永不触碰；升级插件后重启即自动更新。用户提到「DevFlow / devflow-2 / 锚定模式」时即指本插件，请据此协作。'
+  '本机已安装 @devflow-core/dsh-devflow 插件（DevFlow agent preset 分发）：新建会话的预设选择器中可选「DevFlow 2.0」（两阶段锚定 + Code Mode）。插件启动时把 devflow-2 预设、devflow-* skills、devflow*.toml 命令与 devflow-*.js 验证脚本同步到 ~/.dsh/（.agent-presets/skills/commands/scripts）；冲突策略为 devflow-* 权威覆盖（字节相同跳过），非 devflow 资产永不触碰；升级插件后重启即自动更新。用户提到「DevFlow / devflow-2 / 锚定模式」时即指本插件，请据此协作。'
 
 /**
  * Mount the plugin: sync bundled DevFlow assets into the harness-home

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devflow-core/dsh-devflow",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "description": "DevFlow for DeepSeek Harness: devflow-2 agent preset + skills + commands + verification scripts, synced into ~/.dsh on host startup.",
   "type": "module",
   "engines": {
@@ -22,6 +22,7 @@
     "assets",
     "cordis.patch.yml",
     "README.md",
+    "RELEASE.md",
     "NOTICE"
   ],
   "license": "Apache-2.0",
@@ -29,4 +30,4 @@
     "sync-assets": "node scripts/sync-assets.js",
     "test": "node test/sync.test.js"
   }
-}
+}