@devflow-core/dsh-devflow 0.6.2 → 0.9.0

package/README.md

@@ -33,7 +33,7 @@ npx @deepseek-ai/dsh plugin --profile web add @devflow-core/dsh-devflow
 
 - **devflow-\* 权威覆盖**：目标文件与包内源文件字节相同 → 跳过；不同 → 覆盖。
 - 源不再包含的 devflow-\* 残留（升级后旧文件）→ 删除（prune）。
-- **非 devflow 资产永不触碰**：用户自装的 skill（如 `atlassian`、`rtk`）、
+- **非 devflow 资产永不触碰**：用户自装的 skill（如 `atlassian`）、
   自定义命令/脚本一律保留，不删除不覆盖。
 - **preset 目录完全由插件管理**：`~/.dsh/.agent-presets/devflow-2/` 整目录归
   插件所有，目录内非包内文件（含手动备份如 `agent.cordis.yml.bak-*`）会在

package/RELEASE.md

@@ -101,7 +101,7 @@ npx @deepseek-ai/dsh plugin --profile web update @devflow-core/dsh-devflow
 - 字节相同的文件跳过（不覆盖用户 mtime）
 - 不同的文件覆盖（devflow-* 权威）
 - 源不再包含的 devflow-* 残留 prune
-- 非 devflow 资产（atlassian、rtk 等）永不触碰
+- 非 devflow 资产（atlassian 等）永不触碰
 - `~/.dsh/.agent-presets/devflow-2/` 整目录归插件管理，目录内非包内文件会被清理
 
 ## 常见错误对照表

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

@@ -88,7 +88,12 @@
 # restores THIS text after promotion. The DevFlow paragraph guarantees
 # activation even when the model would otherwise skip reading AGENTS.md; the
 # route table and hard boundaries stay in the devflow-core skill and AGENTS.md
-# (single source, no duplication).
+# (single source, no duplication). The two trailing paragraphs carry the
+# AGENTS.md rules no lifecycle skill owns — Independent Judgment and the
+# fallback output contracts — because `instructionHint: true` (tool-bootstrap
+# above) replaces the workspace AGENTS.md digest with a reference hint once the
+# session is promoted.
+# devflow: ceiling: clause-level restatement checked by scripts/validate-devflow.js, not full semantic alignment; revisit when either AGENTS.md section is reworded.
 - id: persona
   name: '@deepseek-ai/dsh-persona'
   config:
@@ -97,6 +102,10 @@
 
       You run DevFlow. Before any development work — creating features, building components, adding functionality, modifying behavior, or defining an unapproved problem-directed change — load the `devflow-core` skill with the skill tool and read its `core-methods.md` reference, then load only the selected lifecycle owner skill. The route table and hard boundaries live in that skill and in AGENTS.md; do not invent lifecycle details. Pure Q&A, lookup, verification, and investigation-only reports need no lifecycle.
 
+      Independent judgment: before answering or acting, check for false premises, logical leaps, and material missing information; never agree merely to accommodate the user — when disagreeing, state the evidence, risks, and plausible alternative explanations; separate verified facts, inferences, and opinions, and state the evidence boundary when verification is unavailable; name overlooked variables, costs, constraints, and likely biases.
+
+      Fallback output contracts: design as Goal / Smallest useful plan / Not doing / Impact / Verification; completion as Command / Result / Adversarial review / Judgment (PASS, FAIL, or BLOCKED).
+
 - id: agent-instructions
   name: '@deepseek-ai/dsh-agent-instructions'
   config:

package/assets/scripts/devflow-plan.js

@@ -369,20 +369,24 @@ function splitTasksV2(body) {
 }
 
 /** Validate one v2 task: files, change intent, acceptance, proof, and exclusion. */
-function checkTaskV2(task) {
+function checkTaskV2(task, enforceGranularity = true) {
   const missing = v2TaskFields.filter((field) => !v2FieldPatterns[field].test(task.body));
   const files = v2FieldBlock(task.body, "Files");
   const change = v2FieldBlock(task.body, "Change");
+  const acceptance = v2FieldBlock(task.body, "Acceptance");
   const verify = v2FieldBlock(task.body, "Verify");
   const notDoing = v2FieldBlock(task.body, "Not doing");
   const fileEntries = parseFileEntries(files);
   const invalidFiles = fileEntries.filter(({ match }) => !match).map(({ line }) => line);
   const unlocatedCodeFiles = findUnlocatedCodeFiles(fileEntries);
   const unresolved = findMatches(task.body, unresolvedPatterns);
-  const vague = findMatches([change, v2FieldBlock(task.body, "Acceptance"), verify].join("\n"), vaguePatterns);
+  const vague = findMatches([change, acceptance, verify].join("\n"), vaguePatterns);
   // v2 不强制精确改法；只要求 Change 说出可执行意图，具体实现归 Build。
   const missingChange = !implementationVerbPattern.test(change) || genericMechanicsPattern.test(change);
   const incompleteVerification = !hasVerificationExpectation(verify);
+  // 单结果保守代理：Acceptance 含分号即视为多交付单元；先剔除反引号代码片段，避免命令里的半角分号误报。语义判据（"且"连接独立结果、镜像合并）在技能指南，checker 只强制可静态判定的子集。
+  const acceptanceText = acceptance.replace(/`[^`]*`/g, "");
+  const multiResult = enforceGranularity && /[；;]/.test(acceptanceText);
 
   return {
     number: task.number,
@@ -393,6 +397,7 @@ function checkTaskV2(task) {
     unlocatedCodeFiles,
     missingChange,
     incompleteVerification,
+    multiResult,
     missingNotDoing: !notDoing,
     ok:
       missing.length === 0 &&
@@ -402,6 +407,7 @@ function checkTaskV2(task) {
       unlocatedCodeFiles.length === 0 &&
       !missingChange &&
       !incompleteVerification &&
+      !multiResult &&
       Boolean(notDoing)
   };
 }
@@ -409,13 +415,15 @@ function checkTaskV2(task) {
 /** Validate the v2 plan contract: slim header, task rows, Progress table, and Cut subtraction. */
 function checkPlanV2(body) {
   const tasks = splitTasksV2(body);
-  const taskResults = tasks.map(checkTaskV2);
-  const missingGlobal = v2GlobalFields.filter((field) => !v2FieldPatterns[field].test(body));
-  const cutBlock = v2FieldBlock(body, "Cut");
-  const missingRejected = !/Rejected\s*:\s*\S/im.test(cutBlock);
   const statusMatch = body.match(statusPattern);
   const status = statusMatch ? statusMatch[1].trim() : "legacy";
   const invalidStatus = statusMatch ? !validStatuses.includes(status) : false;
+  // 粒度代理只在活跃计划（draft/approved/in-progress）上强制；done 计划是历史记录，不重判，避免既有 v2 计划校验回归。
+  const enforceGranularity = status !== "done";
+  const taskResults = tasks.map((task) => checkTaskV2(task, enforceGranularity));
+  const missingGlobal = v2GlobalFields.filter((field) => !v2FieldPatterns[field].test(body));
+  const cutBlock = v2FieldBlock(body, "Cut");
+  const missingRejected = !/Rejected\s*:\s*\S/im.test(cutBlock);
   const progress = [...body.matchAll(progressRowPattern)].map((match) => ({
     number: Number(match[1]),
     state: match[3],
@@ -806,6 +814,7 @@ function report(body, filePath, json) {
           ...task.vague.map((match) => `vague ${match}`),
           ...task.invalidFiles.map((line) => `unclassified file ${line}`),
           ...task.unlocatedCodeFiles.map((line) => `missing file symbol/anchor ${line}`),
+          ...(task.multiResult ? ["Acceptance lists multiple results; split the task or state one observable result"] : []),
           ...(task.missingChange ? ["Change needs an executable intent verb"] : []),
           ...(task.missingNotDoing ? ["missing Not doing exclusion"] : []),
           ...(task.incompleteVerification ? ["Verify needs command/scenario and expected result"] : [])
@@ -1046,7 +1055,7 @@ function selfTest() {
     "Files:",
     "- Modify: scripts/devflow-plan.js | symbol: `checkPlanV2` | validate the slim contract",
     "Change: add v2 field validation and dispatch",
-    "Acceptance: v2 plans pass and legacy plans keep passing",
+    "Acceptance: v2 plans pass the slim contract",
     "Verify: run `node scripts/devflow-plan.js --self-test` expect exit 0",
     "Not doing: changing legacy validation",
     "",
@@ -1058,6 +1067,24 @@ function selfTest() {
   ].join("\n");
   if (!detectV2(validV2Plan)) throw new Error("Self-test expected v2 detection to pass");
   if (!checkPlan(validV2Plan).ok) throw new Error("Self-test expected valid v2 plan to pass");
+  const multiResultV2Plan = validV2Plan.replace(
+    "Acceptance: v2 plans pass the slim contract",
+    "Acceptance: v2 plans pass；legacy plans keep passing"
+  );
+  if (checkPlan(multiResultV2Plan).ok) throw new Error("Self-test expected a semicolon-joined Acceptance to fail");
+  const doneMultiResultV2Plan = multiResultV2Plan
+    .replace("Status: approved", "Status: done")
+    .replace("| 1 | Add v2 validation | todo | - |", "| 1 | Add v2 validation | done | run `node scripts/devflow-plan.js --self-test` |");
+  if (!checkPlan(doneMultiResultV2Plan).ok) {
+    throw new Error("Self-test expected a done plan to keep validating without granularity re-judging");
+  }
+  const codeSpanSemicolonV2Plan = validV2Plan.replace(
+    "Acceptance: v2 plans pass the slim contract",
+    "Acceptance: `node -e \"a;b\"` prints one result"
+  );
+  if (!checkPlan(codeSpanSemicolonV2Plan).ok) {
+    throw new Error("Self-test expected a semicolon inside a code span to stay valid");
+  }
   if (checkPlan(validV2Plan.replace(/Rejected:[^\n]*/, "Rejected:")).ok) throw new Error("Self-test expected missing Rejected to fail");
   if (checkPlan(validV2Plan.replace("| 1 | Add v2 validation | todo | - |", "| 1 | Add v2 validation | done | - |")).ok) {
     throw new Error("Self-test expected a done Progress row without evidence to fail");
@@ -1089,7 +1116,7 @@ function selfTest() {
   if (missingArtifact.length === 0) throw new Error("Self-test expected a missing requirement artifact to fail");
 
   console.log("DevFlow plan self-test passed");
-  console.log("Checked v2 and legacy plan contracts, Progress evidence, Cut Rejected, code-level fields, precise file locations, verification expectations, documentation-only exception, external-skill declaration, and plan landing guidance");
+  console.log("Checked v2 and legacy plan contracts, Progress evidence, Cut Rejected, single-result Acceptance granularity, code-level fields, precise file locations, verification expectations, documentation-only exception, external-skill declaration, and plan landing guidance");
 }
 
 const args = process.argv.slice(2);

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

@@ -46,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 six-field contract (`Task` / `Files` / `Change` / `Acceptance` / `Verify` / `Not doing`) in `skills/devflow-plan/SKILL.md`. Legacy plans with `Change mechanics` and `Prewalk` stay executable under their own contract.
 
-No unresolved markers. `Change` states the executable intent and boundary; add exact mechanics only when the change crosses a module contract, is irreversible, or touches security or data boundaries. Otherwise Build chooses the smallest implementation and records it as Progress evidence. The verification step keeps its trigger/input, expected result, and command or manual scenario. A task whose files are all documentation paths is documentation-only. No "add tests" without naming the behavior, no "handle edge cases" without naming the edge case, no "similar to Task N" shortcuts.
+No unresolved markers. `Change` states the executable intent and boundary; add exact mechanics only when the change crosses a module contract, is irreversible, touches security or data boundaries, or the mechanism cannot be inferred from the task's named anchors by a different session or model. Otherwise Build chooses the smallest implementation and records it as Progress evidence. The verification step keeps its trigger/input, expected result, and command or manual scenario. A task whose files are all documentation paths is documentation-only. No "add tests" without naming the behavior, no "handle edge cases" without naming the edge case, no "similar to Task N" shortcuts.
 
 Close each task by writing back its `## Progress` row: `doing` when starting, `done` with the command and key result when its `Verify` passes. A `done` row without evidence fails the checker. On a legacy plan without a Progress table, report the same evidence in the completion message. When every task is `done`, advance the requirement row in `docs/requirements.md` to `built`.
 

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

@@ -42,3 +42,5 @@ A function may contain several steps when they form one coherent business narrat
 ## Build Comments
 
 The approved Spec/Plan and local project convention define required code comments. Add a comment when it records a protected contract, failure condition, business rule, compatibility boundary, or other non-obvious reason; inline comments explain reasons, not syntax. Markdown runtime contracts use headings and fixed output shapes rather than narrative comments.
+
+When a comment describes behavior, write it from the accepted final state. Regenerate it from the final behavior instead of editing rejected wording; comments never narrate rejected alternatives, session corrections, intermediate attempts, or why-not-X reasoning, and keep only the non-obvious reasons a future maintainer needs.

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

@@ -22,6 +22,14 @@ Status: [DevFlow: <node> -> <next> | awaiting approval / in progress]
 
 While a DevFlow lifecycle node is active, end each user-facing message with one status line: `[DevFlow: <node> -> <next> | awaiting approval / in progress]`. It reflects the current node without reloading the owner skill. Keep progress visible in the persistent UI: maintain a `todo_write` list with one item per active work unit (lifecycle node, background job, or subagent), marking it `completed` the moment it settles, and use `create_goal` for the session's long-running objective.
 
+## Delivery Surfaces
+
+Final artifacts and their wrappers — titles, filenames, body text, comments, tags, commits, PR text, documents, and handoffs — describe the accepted final state, assuming the reader did not see this session; rejected session-only alternatives, intermediate attempts, and wording corrections stay control data.
+
+For each surface, decide whether a session-less reader needs the information: keep an exclusion only when omission would make the artifact inaccurate, unsafe, misleading, or incompatible, or when this surface must explain a real change from the committed or user-approved baseline. Regenerate high-salience names, titles, and openings from the positive target instead of editing rejected wording, and never write an absent option as a labeled absence. Keep real baseline changes, executed external actions, required technical names, diagnostics, tests, and pre-existing user changes.
+
+Before completion, reread every user-visible surface and wrapper, including filenames, metadata, and hook rewrites, and recheck after any content change. Keep unrelated changes out of this task's commit, PR, or handoff; keep comparisons, quotations, audits, or migration notes only when the user asked or the surface requires them, and do not add cleanup or no-residue claims.
+
 ## Context Map
 
 Read `skills/devflow-core/references/core-methods.md` before route selection. It supplies Method 0, shared route rules, and the owner map. Do not load all lifecycle references by default.

package/assets/skills/devflow-docs-followup/SKILL.md

@@ -41,6 +41,8 @@ Rules:
 
 Before writing a selected document, read the current diff, implementation, tests, commands, and user-confirmed decisions. Use project documentation conventions and templates when they exist.
 
+Describe the accepted final state: session-only alternatives, intermediate attempts, and corrections stay out of created documents. Regenerate titles and openings from the positive target; keep API names, real removals, executed external actions, diagnostics, tests, and compatibility facts that accuracy requires, and keep unrelated changes out unless the document requires them.
+
 When the target project has no relevant convention, use these fallback locations:
 
 | Document type | Fallback path |

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

@@ -18,7 +18,7 @@ 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 the intended touch set once: list the files and the responsibility each one carries. Reuse existing modules and name the intended file operation.
 3. Do the bounded investigation needed to write correct tasks. Keep that evidence in the conversation or in a learning card; it is not a plan field.
-4. Split independent deliverables into small, reviewable tasks. Each task carries `Files`, `Change`, `Acceptance`, `Verify`, and `Not doing` so an executor can act on it without reading another task.
+4. Split by delivery unit: one task = one independently verifiable deliverable and the smallest unit worth a fresh reviewer's gate — split only where a reviewer could meaningfully reject one task while approving its neighbor, and fold setup, configuration, scaffolding, and documentation into the task whose deliverable needs them. Split whenever `Acceptance` needs `且`/`and` to join two independently verifiable results; keep one task when the same rule mirrors across files — mirrored edits are one delivery unit, not one task per file. Each task carries `Files`, `Change`, `Acceptance`, `Verify`, and `Not doing` so an executor can act on it without reading another task.
 5. Write the plan using the required header, task contract, and `## Progress` table below.
 6. Self-review Cut fidelity, touch-set coverage, acceptance proof, scope exclusions, and Progress row count against the task count.
 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.
@@ -49,7 +49,7 @@ Files:
 - Create: <path> | new file | <responsibility>
 - Modify: <path> | <symbol or stable anchor> | <responsibility>
 - Test: <path> | <symbol or stable anchor> | <behavior proved>  # only when applicable
-Change: <what changes and its boundary; add the smallest mechanics only when the change crosses a module contract, is irreversible, or touches security or data boundaries>
+Change: <what changes and its boundary; add the smallest mechanics (pseudocode, exact replacement, or key fragment) only when the change crosses a module contract, is irreversible, touches security or data boundaries, or the mechanism cannot be inferred from the task's named anchors by a different session or model>
 Acceptance: <specific observable condition>
 Verify: <exact command or manual scenario, trigger/input, and expected result>
 Not doing: <scope excluded by this task>
@@ -77,15 +77,15 @@ Files:
 - Create: <path> | new file | <responsibility>
 - Modify: <path> | <symbol or stable anchor> | <responsibility>
 - Test: <path> | <symbol or stable anchor> | <behavior proved>  # only when applicable
-Change: <what changes and its boundary; exact mechanics only when the change crosses a module contract, is irreversible, or touches security or data boundaries>
+Change: <what changes and its boundary; exact mechanics (pseudocode, exact replacement, or key fragment) only when the change crosses a module contract, is irreversible, touches security or data boundaries, or the mechanism cannot be inferred from the task's named anchors by a different session or model>
 Acceptance: <specific observable condition>
 Verify: <exact command or manual scenario, trigger/input, and expected result>
 Not doing: <scope excluded by this task>
 ```
 
-Use only `Create`, `Modify`, and `Test` file-operation labels. `Create` rows use `new file`; every other row names a symbol or stable anchor. `Change` states the executable intent and its boundary in one or two lines; it does not restate current behavior, target behavior, call impact, or interfaces unless the task changes a cross-module contract. The Plan no longer classifies tasks by `Task type`: a task whose files are all documentation paths is documentation-only, and the checker treats it that way.
+Use only `Create`, `Modify`, and `Test` file-operation labels. `Create` rows use `new file`; every other row names a symbol or stable anchor. `Change` states the executable intent and its boundary in one or two lines; it does not restate current behavior, target behavior, call impact, or interfaces unless the task changes a cross-module contract. When the mechanism cannot be inferred from the task's named anchors — the common case when a different session or model executes the plan — `Change` carries the smallest runnable mechanics (pseudocode, exact replacement, or key fragment) so the executor acts without the author's session context. The Plan no longer classifies tasks by `Task type`: a task whose files are all documentation paths is documentation-only, and the checker treats it that way.
 
-Six fields per task is the whole contract: ordering, the touch set, the intent, the acceptance condition, the proof command, and the exclusion. Investigation traces, handoff facts, per-task worklists, architecture, tech stack, spec coverage, and comment locations are owned by other nodes or stay in the conversation. `Prewalk`, `File Structure`, `Interfaces`, `Current behavior`, `Target behavior`, `Change mechanics`, `Call impact`, and `Comments` are not part of the v2 contract; a plan that still carries them is treated as legacy.
+Six fields per task is the whole contract: ordering, the touch set, the intent, the acceptance condition, the proof command, and the exclusion. `Acceptance` states one observable result; a `；`/`;`-joined multi-result acceptance is a split signal and the checker fails it while the plan is active. Plan length has no fixed total line cap: it grows with the number of delivery units while every task keeps the six-field, one-result shape. Investigation traces, handoff facts, per-task worklists, architecture, tech stack, spec coverage, and comment locations are owned by other nodes or stay in the conversation. `Prewalk`, `File Structure`, `Interfaces`, `Current behavior`, `Target behavior`, `Change mechanics`, `Call impact`, and `Comments` are not part of the v2 contract; a plan that still carries them is treated as legacy.
 
 Keep one task understandable on its own. Do not use cross-task shorthand, generic test additions, unnamed edge cases, or cleanup entries. Name a test file only when the stated behavior needs one.
 
@@ -103,6 +103,8 @@ Plan generation does not repeat Cut, perform Build or Prove, prescribe independe
 | "The checker proves the architecture." | It proves structure only; the author must review scope and design consistency. |
 | "The plan is approved, so Cut can be skipped." | Plan generation requires an existing `CUT_PASS`; it cannot replace the earlier reuse and scope decision. |
 | "The task details can broaden the solution." | If a task exceeds the Cut Decision, return the scope-drift facts to `devflow-core`; do not directly enter Build. |
+| "Two results can share one task when they ship together." | Two independently verifiable results are two delivery units; split the task or reduce `Acceptance` to one observable result. |
+| "A different session or model will figure out the how." | If the mechanism cannot be inferred from the task's named anchors, `Change` must carry the smallest runnable mechanics; otherwise the handoff stalls. |
 
 ## Verification
 
@@ -114,6 +116,8 @@ Before leaving this skill, confirm:
 - [ ] Approved design or saved spec is cited as optional `Source`.
 - [ ] Header, tasks, and `## Progress` match the v2 contract; each task has six fields and no legacy field.
 - [ ] Every task is independently understandable and has no unresolved or vague placeholder.
+- [ ] Each task is exactly one delivery unit: no `；`/`;`-joined `Acceptance`, and a mirrored rule was not split per file.
+- [ ] Every task is executable by a different session or model from its six fields plus named anchors: a non-inferable mechanism carries the smallest runnable mechanics.
 - [ ] Progress row count equals task count; every `done` row carries evidence.
 - [ ] The checker passed when available.
 - [ ] The user reviewed the written plan.

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

@@ -8,6 +8,17 @@ State the intended touch set once, before tasks: the files and the responsibilit
 
 The v2 Plan Pack has no `File Structure` table. The per-task `Files` rows are the touch set; a global table would only restate them.
 
+## Delivery Unit
+
+Split by delivery unit, not by file or by step: one task = one independently verifiable deliverable.
+
+- Splitting test: if `Acceptance` needs `且`/`and` to join two independently verifiable results, they are two delivery units — split them.
+- Mirror test: the same rule edited across several files is one delivery unit; do not split it per file.
+- Right-sizing test: a task is the smallest unit worth a fresh reviewer's gate — split only where a reviewer could meaningfully reject one task while approving its neighbor; fold setup, configuration, scaffolding, and documentation into the task whose deliverable needs them.
+- `Acceptance` states one observable result. The checker fails a v2 task whose `Acceptance` contains a `；`/`;` separator outside backtick code spans as the conservative static proxy for this rule; it applies while the plan is active (draft/approved/in-progress), while done plans stay historical records. The semantic tests above still govern mirrored and independently verifiable cases.
+- Handoff density: when the mechanism cannot be inferred from the task's named anchors — a different session or model executes the plan — `Change` carries the smallest runnable mechanics (pseudocode, exact replacement, or key fragment); otherwise it stays intent plus boundary.
+- No fixed total line cap: plan length grows with the number of delivery units; the six-field shape keeps each task slim.
+
 ## Task Rows
 
 Each task carries exactly six fields:
@@ -21,7 +32,7 @@ Verify: <command or manual scenario with trigger, input, and expected result>
 Not doing: <scope excluded by this task>
 ```
 
-`Change` states the executable intent. Add exact mechanics only when the change crosses a module contract, is irreversible, or touches security or data boundaries. Otherwise the executor chooses the smallest implementation inside the task boundary. This is the deliberate trade: the plan stops pre-deciding every edit, and Build regains bounded implementation authority. That trade is the fix for the bloated-plan problem, not a relaxation of proof.
+`Change` states the executable intent. Add exact mechanics (pseudocode, exact replacement, or key fragment) only when the change crosses a module contract, is irreversible, touches security or data boundaries, or the mechanism cannot be inferred from the task's named anchors by a different session or model. Otherwise the executor chooses the smallest implementation inside the task boundary. This is the deliberate trade: the plan stops pre-deciding every edit, and Build regains bounded implementation authority. That trade is the fix for the bloated-plan problem, not a relaxation of proof.
 
 Investigation evidence does not belong in the plan. Keep it in the conversation, or in a `.copilot/cards/` learning card when it is reusable across tasks.
 

package/assets/skills/devflow-prove/references/proof-recovery-methods.md

@@ -17,6 +17,8 @@ Adversarial review: <acceptance, regressions, activation, proof coverage>
 Judgment: PASS / FAIL / BLOCKED
 ```
 
+Before the completion report, reread every final artifact and its wrapper — filenames, titles, comments, tags, documents, commit or PR text, metadata, hook rewrites, and the report itself — as a reader without access to this session, and describe only the accepted final state. Recheck after any content change; keep deliberate decision records, safety and compatibility facts, real baseline changes, executed external actions, and pre-existing user changes; keep unrelated changes out of this task's commit, PR, or handoff, and do not add cleanup or no-residue claims.
+
 `PASS` is Prove's terminal success after Learn review. Proof `FAIL`, `BLOCKED`, a real adversarial gap, unresolved Code Review Blocker/Warning, or incomplete PUA recovery evidence returns its facts to `devflow-core`; Core selects the repair, recovery, or re-clarification path. Prove never infers that next owner.
 
 ### Quality-Finding Recovery

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

@@ -8,6 +8,8 @@ Owner: `devflow-spec` and `devflow-plan`. Load this reference only after Core se
 
 `devflow-plan` consumes A/B `CUT_PASS` plus an approved design or confirmed Spec. It creates one implementation plan under `docs/plans/`, then waits for user review. An approved A/B Plan directly enters Build; scope-drift facts return to Core.
 
+Spec and Plan names, titles, and framing describe the accepted final state, regenerated from the positive target rather than edited from rejected wording. Keep Non-goals and Rejected as deliberate decision records; keep unrelated changes, comparisons, quotations, audits, or migration notes out unless the user asked or the document requires them.
+
 A Spec contains Goal, Context, Requirements, Non-goals, Approach, Impact, Acceptance, Verification, Code Documentation, and Open Questions. A Plan states Source, Spec coverage, Cut Decision, External Skills, exact files or anchors, interfaces, current and target behavior, mechanics, call impact, verification, comments, and exclusions.
 
 ## Plan Contract

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devflow-core/dsh-devflow",
-  "version": "0.6.2",
+  "version": "0.9.0",
   "description": "DevFlow for DeepSeek Harness: devflow-2 agent preset + skills + commands + verification scripts, synced into ~/.dsh on host startup.",
   "type": "module",
   "engines": {