@devflow-core/dsh-devflow 0.6.2 → 0.7.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/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-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/package.json

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