@devflow-core/dsh-devflow 0.2.0 → 0.4.0

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/tool-bootstrap.mjs

@@ -5,6 +5,10 @@
  * preset's full DevFlow prompt from agent.cordis.yml) is restored untouched,
  * and the workspace line is only appended when the persona does not already
  * mention a working directory (the DevFlow template resolves {{cwd}} itself).
+ *
+ * Synced with dsh-liangshen 0.3.14: goal whitelist (#578), presentation
+ * broadcasts (#1128), and the snapshotEvents() session-events fallback for
+ * newer DSH releases.
  */
 
 /**
@@ -16,7 +20,8 @@
  * - prompt sections: only the persona section (all other sections,
  *   including plan-mode's `plan:policy`, return after promotion)
  * - runtime contexts: emptied (no sandbox/approval snapshot)
- * - pre-step messages: only explicit user messages pass
+ * - pre-step messages: only whitelisted source kinds pass (direct user
+ *   messages and goal auto-rounds by default)
  *
  * Promotion opens the full tool catalog and restores runtime contexts and all
  * prompt sections. With `anchorGate` the promotion after the first tool call
@@ -82,11 +87,13 @@ const PERSONA_SECTION_NAMES = new Set(['deployment:persona', 'persona'])
  */
 const WORKSPACE_LINE_PREFIX = '\n\nYour working directory is '
 
-/** Message-source kinds the model may see during phase 1. */
-const DEFAULT_MESSAGE_SOURCES = ['user']
-
-/** Message-source kinds delayed after promotion. */
-const DEFAULT_DEFERRED_SOURCES = []
+/**
+ * Message-source kinds the model may see during phase 1. Goal auto-rounds
+ * (source kind `goal`, issue #578) must be here: a filtered-out goal round
+ * never produces a response or tool call, so no promotion branch ever fires
+ * and the goal resume/pause loop deadlocks.
+ */
+const DEFAULT_MESSAGE_SOURCES = ['user', 'goal']
 
 function stringList(value, field, fallback) {
   if (value === undefined) return [...fallback]
@@ -153,12 +160,15 @@ export function hasAnchoredReasoning(content) {
 }
 
 /**
- * Whether one pre-step message is an explicit user message. Only `kind:
- * 'user'` passes; injected kinds and source-less seed messages never pass.
+ * Whether one pre-step message belongs to a whitelisted source kind. The
+ * configured whitelist alone decides; injected kinds and source-less seed
+ * messages never pass unless explicitly named. (Before issue #578 this also
+ * hardcoded `kind === 'user'`, so no whitelist entry could ever admit a
+ * goal auto-round and `/goal` sessions deadlocked in phase 1.)
  */
 function isAllowedMessage(message, allowedSources) {
   const kind = message.source?.kind
-  return kind === 'user' && allowedSources.has(kind)
+  return kind !== undefined && allowedSources.has(kind)
 }
 
 /** Whether one pre-step message belongs to a deferred injection kind. */
@@ -166,6 +176,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 +266,7 @@ function stateFor(session) {
       turnEnded: false,
       steps: 0,
       deferredSteps: 0,
+      instructionHinted: false,
       presentationApplied: false,
       hasCompacted: false,
       presentationDisposer: undefined,
@@ -207,7 +286,7 @@ function stateFor(session) {
  * Code Mode presentation is disposed so the next assembly sees the native
  * catalog and the phase-1 filter can narrow it again.
  */
-function resetToControlled(state) {
+function resetToControlled(state, session) {
   if (typeof state.presentationDisposer === 'function') {
     try {
       state.presentationDisposer()
@@ -216,6 +295,10 @@ function resetToControlled(state) {
       // next promotion re-declares Code Mode anyway.
     }
     state.presentationDisposer = undefined
+    const agent = session !== undefined ? agentBySession.get(session) : undefined
+    if (agent?.ctx && typeof agent.ctx.emit === 'function') {
+      agent.ctx.emit('tools/presentation-changed', { mode: 'native', session: session?.id })
+    }
   }
   state.promoted = false
   state.toolCalled = false
@@ -224,6 +307,7 @@ function resetToControlled(state) {
   state.turnEnded = false
   state.steps = 0
   state.deferredSteps = 0
+  state.instructionHinted = false
   state.presentationApplied = false
   state.hasCompacted = true
 }
@@ -235,13 +319,20 @@ function resetToControlled(state) {
  */
 function applyPresentation(agent, state, policy) {
   if (state.presentationApplied || policy.promotedPresentation !== 'code') return
-  state.presentationApplied = true
-  const tools = agent.ctx.tools
+  const tools = agent?.ctx?.tools
+  // Latch only after the switch really happened: without a tools view there
+  // is nothing to present, and latching early would skip Code Mode forever.
   if (tools === undefined) return
   // The disposer restores the deployment-default (native) presentation; it is
   // kept on the state so a post-compaction reset can release Code Mode and
   // let the phase-1 catalog filter see the native tool list again.
   state.presentationDisposer = tools.presentAs('code')
+  state.presentationApplied = true
+  // #1128: Broadcast presentation switch so external discipline / analysis
+  // plugins decouple presentation mode from tool failure detection.
+  if (typeof agent?.ctx?.emit === 'function') {
+    agent.ctx.emit('tools/presentation-changed', { mode: 'code', session: agent.session?.id })
+  }
 }
 
 /**
@@ -263,7 +354,11 @@ function decidePromotion(state, config) {
 
 /** Scan newly appended session events and update promotion state. */
 function scanEvents(state, session) {
-  const events = session.events
+  const events = Array.isArray(session?.events)
+    ? session.events
+    : typeof session?.snapshotEvents === 'function'
+      ? session.snapshotEvents()
+      : []
   for (; state.next < events.length; state.next += 1) {
     const event = events[state.next]
     if (event === undefined) continue
@@ -273,7 +368,7 @@ function scanEvents(state, session) {
       // past this boundary (the `next` pointer stays, so events before the
       // boundary never re-promote). Handled inside the scan so cold starts
       // reconstruct the same phase from the durable log.
-      resetToControlled(state)
+      resetToControlled(state, session)
     } else if (event.type === 'tool/call') {
       state.toolCalled = true
     } else if (event.type === 'step/start') {
@@ -369,6 +464,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
@@ -381,7 +477,7 @@ export function apply(ctx, config) {
   // start reconstructs the same controlled phase from the durable log.
   ctx.on('session/event', (session, event) => {
     if (event.type === 'compaction/end') {
-      resetToControlled(stateFor(session))
+      resetToControlled(stateFor(session), session)
       return
     }
     if (event.type !== 'step/end' && event.type !== 'turn/end') return
@@ -464,14 +560,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 +593,4 @@ export function apply(ctx, config) {
     }
     return { ...resolved, maxTokens: policy.bootstrapMaxTokens }
   }, { prepend: true })
-}
+}

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-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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@devflow-core/dsh-devflow",
-  "version": "0.2.0",
+  "version": "0.4.0",
   "description": "DevFlow for DeepSeek Harness: devflow-2 agent preset + skills + commands + verification scripts, synced into ~/.dsh on host startup.",
   "type": "module",
   "engines": {
@@ -30,4 +30,4 @@
     "sync-assets": "node scripts/sync-assets.js",
     "test": "node test/sync.test.js"
   }
-}
+}