@devflow-core/dsh-devflow 0.4.0 → 0.6.0

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

@@ -16,13 +16,14 @@ Turn an A/B `CUT_PASS`-bounded approved design or confirmed Spec into one review
 ## Authoring Process
 
 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, 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.
+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.
+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.
 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`.
+9. On approval, advance the requirement row in `docs/requirements.md` to `planned` and fill the plan path in its artifact column.
 
 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/`.
 
@@ -33,88 +34,64 @@ Structural headers remain English so the checker can parse them; content uses th
 ```text
 # <Plan title>
 
+Status: draft | approved | in-progress | done | abandoned
 Goal: <outcome>
-Architecture: <smallest design and boundaries>
-Tech Stack: <relevant existing stack>
-Source: <approved design or docs/specs/YYYY-MM-DD-<short-kebab-name>.md>
-Spec coverage: <requirements mapped to tasks, or design-only>
-Cut Decision: <CUT_PASS allowed scope, reuse conclusion, exclusions, verification constraints>
-External Skills: <skill-name>; role: <bounded specialist work>; expected evidence: <result needed by that node>; return facts: <result / not-applicable / failure> / none
+Not doing: <scope excluded>
+Cut: 做 <included> | 不做 <excluded> | 复用 <reused capability> | 验证 <verification> | Rejected: <at least one cut candidate, or none plus evidence why nothing could be cut>
+Source: <approved design or docs/specs/YYYY-MM-DD-<short-kebab-name>.md> (optional)
 Execution mode: sequential | single-subagent | fan-out (optional; ask and record at approval)
+Landed: <date and fresh evidence> (completion only)
 
-## Global Constraints
-- <applicable boundary>
+## Tasks
 
-## File Structure
+Task: <short, independently understandable title>
+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>
+Acceptance: <specific observable condition>
+Verify: <exact command or manual scenario, trigger/input, and expected result>
+Not doing: <scope excluded by this task>
+
+## Progress
 
-| File / symbol | Operation | Responsibility | Why here | Not responsible for |
-|---|---|---|---|---|
-| <path and stable anchor> | Create / Modify / Test | <one responsibility> | <placement rationale> | <explicit boundary> |
+| # | Task | Status | Evidence |
+|---|---|---|---|
+| 1 | <task title> | todo | - |
 ```
 
+The v2 header is deliberately slim: the Plan owns ordering and acceptance, while Cut owns the subtraction and Build owns how the change is implemented. `Cut` is one line and must carry a non-empty `Rejected` (or `none` plus evidence), so a plan without a real subtraction is visible instead of silently passing. `## Progress` is the resume and landing record: Build flips one row to `doing` or `done` and fills its evidence, and Prove writes `Landed` on `PASS`. A plan without `## Progress` and with a `Prewalk` block is a legacy plan; `scripts/devflow-plan.js` keeps validating it with the old rules, so existing plans never need migration.
+
 Inherit `External Skills` from the Cut Decision unchanged; the Plan Pack carries the specialist role, expected evidence, and return facts into Build and Prove. When a specialist skill is declared, merge its core quality checks into the affected tasks' `Acceptance` and `Verify` fields — the Plan Pack is the only channel that carries external-skill quality requirements into Build and Prove. A declared skill never widens the Cut scope; if its recommendation exceeds the Cut Decision, return the scope-drift facts to `devflow-core`.
 
 `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.
+Each task's `Files`, `Change`, `Acceptance`, `Verify`, and `Not doing` form the execution basis（执行规范）handed to the executor. Build may read the current task's named anchors and a directly changed neighbor to choose the smallest implementation; it must not broadly rediscover the repository, redesign outside the task boundary, silently repair the plan, or expand the touch set. A real anchor mismatch or verification failure returns `BUILD_BLOCKED` facts to `devflow-core` instead of a guessed edit.
 
 ## Required Task Contract
 
 ```text
 Task: <short, independently understandable title>
-Task type: Code change | Documentation-only
 Files:
 - Create: <path> | new file | <responsibility>
 - Modify: <path> | <symbol or stable anchor> | <responsibility>
-- Test: <path> | <test symbol or stable anchor> | <behavior proved>  # only when applicable
-Interfaces:
-- Consumes: <exact symbol/API input and type/shape, or documentation-only exception>
-- Produces: <exact symbol/API output and type/shape, or documentation-only exception>
-Current behavior: <observable current state>  # Code change only
-Target behavior: <observable outcome>  # Code change only
-Change mechanics: <minimal code snippet, pseudocode, or exact replacement rule>  # Code change only
-Call impact: <known callers/downstream effect, or no runtime impact>  # Code change only
-Steps:
-- [ ] <one file + symbol/anchor + executable action; include the relevant snippet, pseudocode, or exact replacement for code logic>
-- [ ] <one verification action with trigger/input, expected result, and command or manual scenario>
+- 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>
 Acceptance: <specific observable condition>
 Verify: <exact command or manual scenario, trigger/input, and expected result>
-Comments: <locations and reasons required by Code Documentation, project convention, or non-obvious boundaries; or "none — trivial change">
-Not doing: <scope excluded>
-
-Prewalk:
-
-Execution Trace:
-- Read: <actual file/symbol/range> → <observed fact relevant to this task>.
-- Traced: <actual caller, entry point, collaborator, contract, or test> → <observed path or constraint>.
-- Ran: <actual command or scenario> → <relevant result, including a failure when applicable>.
-- Edited: <actual file/symbol and change> → <reason; or "none yet">.
-- Verified: <actual check> → <observed result; or "none yet">.
-
-Current Handoff Facts:
-- 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">.
-- Planned touch set: <remaining expected files/symbols and reason>.
-- Risks / stop conditions: <facts requiring Core replan; or "none beyond ordinary Plan drift">.
-
-Remaining Structured Worklist:
-- [ ] <one independently completable remaining action with file/symbol and expected outcome>.
-  Anchors: <minimum current anchors>.
-  Verify: <command, test, call-path check, or observable result>.
-  Done when: <fact proving this action is complete>.
+Not doing: <scope excluded by this task>
 ```
 
-`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. `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. 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.
+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.
 
-`Documentation-only` is allowed only when no runtime code changes. Its `Consumes` and `Produces` entries explicitly say `documentation-only`; it cannot label a task that changes a code file. A task does not need a test file unless a test is needed for its stated behavior. Avoid vague work such as generic test additions, unnamed edge cases, cleanup, or cross-task shorthand.
+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.
 
 ## 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 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.
+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 slim construction checklist plus a Progress record. The checker validates static structure; it does not judge architecture or lifecycle state. The v2 contract applies to new plans only; legacy plans keep the old validation rules and are never migrated or rewritten.
 
 ## Anti-Rationalization
 
@@ -131,14 +108,13 @@ Plan generation does not repeat Cut, perform Build or Prove, prescribe independe
 
 Before leaving this skill, confirm:
 
-- [ ] `CUT_PASS` is cited with allowed scope, reuse conclusion, exclusions, and verification constraints.
+- [ ] `Cut` is one line with 做 / 不做 / 复用 / 验证 and a non-empty `Rejected`.
 - [ ] `External Skills` is inherited from the Cut Decision; declared skills' quality checks are merged into task `Acceptance`/`Verify`.
 - [ ] Execution mode was asked at approval and recorded as the optional `Execution mode` header.
-- [ ] Approved design or saved spec is cited as `Source`.
-- [ ] `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 no pre-edit read, and has no unresolved or vague placeholder.
+- [ ] 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.
+- [ ] Progress row count equals task count; every `done` row carries evidence.
 - [ ] 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

@@ -2,73 +2,51 @@
 
 Use this reference after `skills/devflow-spec/references/spec-plan-methods.md` and before writing a Plan Pack. It defines the smallest handoff that lets another executor continue approved work without repeating broad repository discovery.
 
-## File Structure
+## Touch Set
 
-Write one `## File Structure` table before tasks:
+State the intended touch set once, before tasks: the files and the responsibility each one carries. Reuse the nearest owner when it already has the responsibility. If no target can hold the responsibility without a materially different concern, return the fact to Core instead of inventing a generic abstraction.
 
-```text
-| File / symbol | Operation | Responsibility | Why here | Not responsible for |
-|---|---|---|---|---|
-| [path and stable anchor] | Create / Modify / Test | [one responsibility] | [placement rationale] | [explicit boundary] |
-```
+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.
 
-The table states where approved responsibility belongs. It does not mandate a class count, layer, pattern, or automatic file split. Reuse the nearest owner when it already has the responsibility. If no target can hold the responsibility without a materially different concern, return the fact to Core rather than inventing a generic abstraction.
+## Task Rows
 
-## Prewalk
-
-Every non-trivial Code change task ends with `Prewalk`. It is an append-only handoff with three parts:
+Each task carries exactly six fields:
 
 ```text
-Prewalk:
-
-Execution Trace:
-- Read: [actual file/symbol/range] → [observed fact].
-- Traced: [actual caller, entry point, collaborator, contract, or test] → [observed path or constraint].
-- Ran: [actual command or scenario] → [relevant result].
-- Edited: [actual file/symbol and change] → [reason; or "none yet"].
-- Verified: [actual check] → [observed result; or "none yet"].
-
-Current Handoff Facts:
-- 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: [计划作者已确认的锚点——执行者不重读，仅作失败回报时的定位].
-
-Remaining Structured Worklist:
-- [ ] [one independently completable remaining action with file/symbol and expected outcome].
-  Anchors: [minimum current anchors].
-  Verify: [command, test, call-path check, or observable result].
-  Done when: [fact proving completion].
+Task: <short, independently understandable title>
+Files: <Create / Modify / Test rows with path and symbol or stable anchor>
+Change: <what changes and its boundary>
+Acceptance: <specific observable condition>
+Verify: <command or manual scenario with trigger, input, and expected result>
+Not doing: <scope excluded by this task>
 ```
 
-### Trace Rules
+`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.
+
+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.
 
-- Record only work actually performed and what it observed. Do not write future-tense discovery instructions as trace evidence.
-- `Read`, `Traced`, `Ran`, `Edited`, and `Verified` may say `none yet` only where that action truly has not happened. At least one actual read or trace result is required for a Code change handoff.
-- A failed command is valid evidence when its relevant failure is recorded. Do not rewrite it as success.
-- The executor appends real evidence after completing each remaining work item; it does not erase prior trace facts.
+## Progress Table
 
-### Worklist Rules
+Close the plan with one row per task:
+
+```text
+| # | Task | Status | Evidence |
+|---|---|---|---|
+| 1 | <task title> | todo | - |
+```
 
-- Include only unfinished work. Completed work belongs in `Execution Trace`.
-- Order work by dependency. Keep every item independently verifiable.
-- Require `Anchors`, `Verify`, and `Done when` for each item. Generic phrases such as “check the code” do not prove completion.
-- Limit one task to 12 remaining items. Group mechanical substeps under one verified result or return a scope-splitting fact to Core.
+Status values are `todo`, `doing`, and `done`. Build flips the row it is working on and fills the evidence with the command and key result. Prove writes `Status: done` and `Landed:` on `PASS`. A `done` row without evidence fails the checker, and a plan whose header `Status` is `done` requires every row to be `done`. The table is why an interrupted session can resume: the next reader sees exactly what landed and what did not.
 
-## Delegated Execution
+## Execution Handoff
 
-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.
+An executor — the main agent itself, one delegated subagent, or one fan-out subagent — receives the current task's six fields. It may read the task's named anchors and one directly changed neighbor to choose the smallest implementation; it must not broadly rediscover the repository, redesign outside the task boundary, silently repair the plan, or expand the touch set.
 
-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.
+When an edit cannot be applied, a `Verify` fails, or a bounded read finds changed contract behavior, the executor returns the observed difference — affected file/anchor, actual behavior, blocked verification, and the smallest replan decision — as facts to `devflow-core`. It never guesses past a mismatch.
 
 ### 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 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.
+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 six fields, reads its anchors, edits its task's `Files`, runs its task's `Verify`, flips its Progress row, and returns evidence or failure facts. Two tasks may run in parallel only when their `Files` touch disjoint file/symbol sets and neither task's `Change` consumes what the other produces; tasks sharing a file/symbol or with a 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 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.
+When the plan's `Execution mode` is `single-subagent`, the main agent only schedules: it dispatches one task's six fields at a time to one executor subagent, waits for the return, then merges the returned evidence and enters Prove once. The subagent reads its anchors, edits, verifies, flips its Progress row, and returns the task result 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. 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/SKILL.md

@@ -11,17 +11,20 @@ No proof, no completion.
 
 ## Methodology Assets
 
-When this skill activates, read these local references before choosing or running proof scenarios:
+Context loading is conditional and selected by changed surface.
 
-- `skills/devflow-prove/references/flow-self-test.md` — end-to-end scenario tests and pressure scenarios for the framework itself.
-- `skills/devflow-prove/references/code-review-checklist.md` — language-specific code quality criteria for adversarial code review.
+When this skill activates, read only the references required by the changed surface:
+
+- Always read `skills/devflow-prove/references/proof-recovery-methods.md` — shared proof and recovery method.
+- Read `skills/devflow-prove/references/flow-self-test.md` only when the change touches DevFlow runtime rules, skills, commands, host adapters, hooks, validators, scenarios, installers, or harness behavior.
+- For code, read `skills/devflow-prove/references/code-review-checklist.md` and apply only the matching language section: `.js/.jsx/.ts/.tsx` -> TypeScript / JavaScript plus React/Vue when present; `.py` -> Python; `.go` -> Go; `.java` -> Java; `.cs` -> C# / .NET; `.sql` -> SQL. Always apply General Engineering Review. Unlisted extensions use General Engineering Review and record the missing language checklist.
 
 ## Process
 
 Load `skills/devflow-prove/references/proof-recovery-methods.md` before selecting proof. It owns the shared proof and recovery method details used by Prove and PUA.
 
 1. Identify the command, test, build, lint, diff check, validation script, or manual scenario that proves the claim.
-2. Confirm the exact changed files, approved File Structure/Plan boundary, latest Prewalk Execution Trace and Current Handoff Facts. Read the task's remaining-work completion evidence plus the nearest comparable code.
+2. Confirm the exact changed files, approved File Structure/Plan boundary, latest Prewalk Execution Trace and Current Handoff Facts. Read task-local completion evidence plus only the nearest directly relevant code or contract.
 3. Run the narrowest sufficient check now, then independently inspect the actual implementation diff before interpreting test results.
 4. Run adversarial review (对抗式审查) against the approved responsibility boundary, Prewalk facts, direct contracts, nearby convention, and likely regressions.
 5. For code changes: run the **Code Quality Review** (General Engineering Review + Language-Specific Checklist from `code-review-checklist.md`), then generate a **Code Review Report** (see format below). Classify each evidence-backed finding as Blocker, Warning, or Recommendation. An unresolved Blocker or Warning returns `FAIL` facts to Core; recommendations do not block an otherwise proven result.
@@ -89,6 +92,8 @@ Coverage: <what was verified>
 Not covered: <none or explicit gap>
 ```
 
+On `PASS` with a plan file, write back before reporting: header `Status: done` plus `Landed: <date> · <evidence>`; every `## Progress` row must already be `done` with evidence. `PASS` also requires the `docs/requirements.md` row to be terminal — write `landed` with the evidence, or return the missing-row facts to Core. On `FAIL` or `BLOCKED`, leave `Status` unchanged and report facts to Core.
+
 ## Code Review Report
 
 For code changes, after running the Code Quality Review (General Engineering Review + Language-Specific Checklist), generate this report before claiming PASS or FAIL. Review the actual diff before relying on test results. A Blocker or unresolved Warning returns `FAIL` facts to Core; Recommendations remain visible but do not independently prevent PASS.
@@ -96,8 +101,8 @@ For code changes, after running the Code Quality Review (General Engineering Rev
 ```text
 Code Review Report:
 - Diff reviewed: [actual changed files/ranges].
-- Plan boundary: [approved File Structure row(s) and verdict].
-- Prewalk evidence: [Execution Trace, Handoff Facts, remaining-work completion evidence].
+- Plan boundary: [approved task `Files` rows and verdict; legacy plans may cite `File Structure` rows].
+- Progress evidence: [Progress rows with their Status and recorded command/result; legacy plans may cite Prewalk evidence].
 - Comparable code: [nearest inspected file/symbol and observed convention].
 - Blockers: [count].
   1. [Blocker] [file:line] — [changed-code evidence and concrete risk] → [smallest correction].

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

@@ -2,7 +2,7 @@
 
 Use these scenarios to verify the framework from request to landing. A scenario passes only when the expected skill behavior, output contract, and proof are visible.
 
-## Scenario 1: Vague Feature Request
+## Scenario 1: Vague Or Material-Risk Feature Request
 
 Input:
 
@@ -14,6 +14,7 @@ Expected behavior:
 
 - Route: Design.
 - Skill path: `devflow-core -> devflow-brainstorm -> Confirmed request -> user-selected A/B/C direct branch`.
+- Core must classify the request as ambiguous/material-risk before entering Brainstorm and pass a suitable depth hint.
 - Brainstorm must read current project context before clarifying.
 - Brainstorm must send a Semantic Echo-Back, apply the Understanding Revision Rule when a correction changes the request, then ask or infer only goal, scope, exclusions, constraints, acceptance, and open questions.
 - Brainstorm must output the fixed `Confirmed request` summary with `Status: clarified`, present A/B/C, and wait for explicit user selection.
@@ -190,7 +191,7 @@ Expected behavior:
 - Route: Fast verification
 - Skill path: `devflow-core -> devflow-prove`
 - Must check `AGENTS.md`, `CLAUDE.md`, Copilot instructions, VS Code instruction/prompt, CodeBuddy rule, plugin metadata, and Gemini metadata.
-- Must confirm platform adapters preserve `Sense -> Brainstorm clarification -> user-selected A/B/C -> direct success edges -> devflow-prove`, with Core routing non-unique exceptions.
+- Must confirm platform adapters preserve the risk gate: skip-Brainstorm Design-lite is Cut -> Build -> Prove; ambiguous or material-risk work is Sense -> Brainstorm clarification -> user-selected A/B/C -> direct success edges -> devflow-prove, with Core routing non-unique exceptions. Unapproved edits never use Fast.
 - Must confirm plugin metadata includes all shipped skills and commands.
 - Must not rewrite adapter rules unless drift is proven.
 
@@ -281,8 +282,10 @@ In README, rename "Proof Gate" to "Proof Before Done".
 
 Expected behavior:
 
-- Route: Build because implementation is requested and scope is clear.
-- Still run a lightweight Sense and Cut.
+- Route: Design-lite because implementation is requested and the low-risk gate passes.
+- This is a clear low-risk existing behavior change; Core records `Brainstorm required: no` and `Depth hint: skip`, then select `devflow-cut` directly with a Design-lite contract and Depth C.
+- Core may bypass Brainstorm only after the low-risk gate passes.
+- `CUT_PASS` enters Build, then Prove. Cut and Prove remain mandatory. Unapproved edits never use Fast.
 - Touch only the requested file.
 - Verify with text search.
 
@@ -380,7 +383,7 @@ Expected behavior:
 - Cut compares nearest order-history patterns and records convention, responsibility, performance, and readability checks.
 - It must not require a Service split, interface, cache, or fixed function length without current evidence.
 - Build makes business intent, key rules, failure paths, and side effects locally understandable, then records a Readability Check.
-- Prove reviews the actual diff against File Structure, Prewalk evidence, project-convention alignment, local understandability, responsibility boundaries, and any cache benefit/invalidation/consistency claim.
+- Prove reviews the actual diff against the plan task boundary, Progress evidence, project-convention alignment, local understandability, responsibility boundaries, and any cache benefit/invalidation/consistency claim.
 - A coherent orchestration change passes when its responsibility, side effects, and direct contracts remain evidenced in the diff.
 - A changed responsibility or unrecorded side effect is a Blocker or Warning only when the diff shows concrete risk; a justified local convention deviation remains non-blocking.
 
@@ -410,20 +413,22 @@ Expected behavior:
 - Brainstorm presents A/B/C after the confirmed request. User-selected A starts Spec directly; Core routes only missing-depth, changed-intent, or non-success facts.
 - Spec must compare real no-change/reuse, direct, and relevant existing-pattern options; it writes the design contract/saved spec, waits for user approval, then an approved A Spec directly enters Cut.
 - A/B `CUT_PASS` directly enters Plan; only `CUT_REDUCE`, `CUT_REUSE`, `CUT_BLOCKED`, or other non-success facts return to Core.
-- A Code change Plan Pack requires a concrete `File Structure` row per target and task-level `Prewalk`: actual `Execution Trace`, `Current Handoff Facts`, and bounded `Remaining Structured Worklist`.
-- A delegated Build agent reads the latest trace, then re-reads only the current work item's anchors and directly changed neighbor. It does not restart broad discovery or re-decide responsibility by default.
+- A v2 Plan Pack carries a slim header, one six-field task per deliverable, a mandatory `Cut` line with a non-empty `Rejected`, and a `## Progress` table.
+- Build may read the current task's anchors and one directly changed neighbor to choose the smallest implementation, flips the task's Progress row, and records the command and result as evidence.
+- Prove writes `Status: done` and `Landed:` on `PASS`; a `done` Progress row without evidence is not `PASS`.
+- A legacy plan that still carries `File Structure` and `Prewalk` remains valid under the legacy rules.
 - A user-approved Plan Pack receives a lightweight Cut-consistency review; an approved A/B Plan directly enters Build, while scope-drift facts return to Core.
 - Saved plan files default to `docs/plans/YYYY-MM-DD-<short-kebab-name>.md`.
 - Must not save implementation plans under `docs/features/`; that directory is for feature ledgers.
 - Must run `node scripts/devflow-plan.js <plan-file>` when the 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/`.
-- Must fail or revise a plan missing a responsibility map, actual trace evidence, current handoff facts, bounded work items, or concrete verification. The checker does not approve an architecture pattern.
+- Must fail or revise a v2 plan missing `Rejected`, a six-field task, a Progress row matching the task count, evidence on a `done` row, or a runnable `Verify`. The checker does not approve an architecture pattern.
 
 Pass check:
 
 ```text
-CUT_PASS: allowed scope / reuse conclusion / exclusions / verification constraints
+CUT_PASS: 做 / 不做 / 复用 / 验证 plus Rejected
 Command: node scripts/devflow-plan.js docs/plans/YYYY-MM-DD-<short-kebab-name>.md
-Result: DevFlow plan pack report; File Structure: ok; trace and remaining worklist: ok; Judgment: PASS
+Result: DevFlow plan pack report; Format: v2; Cut Rejected: ok; Progress rows match tasks; Judgment: PASS
 Next: lightweight Cut-consistency review -> confirmed Plan and scope-drift facts -> devflow-core
 Judgment: PASS / FAIL / BLOCKED
 ```
@@ -439,8 +444,8 @@ The approved export plan is implemented. Verify it and mark it ready.
 Expected behavior:
 
 - Route: Prove.
-- Prove reads the actual diff before interpreting test output, and compares it with the approved `File Structure`, current `Execution Trace`, `Current Handoff Facts`, remaining-work completion evidence, and nearest comparable code.
-- The Code Review Report names the reviewed diff, plan boundary, Prewalk evidence, comparable code, Blockers, Warnings, Recommendations, and boundary verdict.
+- Prove reads the actual diff before interpreting test output, and compares it with the approved task boundary, Progress evidence, and nearest comparable code.
+- The Code Review Report names the reviewed diff, plan boundary, Progress evidence, comparable code, Blockers, Warnings, Recommendations, and boundary verdict.
 - An unresolved evidence-backed Blocker or Warning returns `FAIL` facts to Core; Recommendations alone do not prevent PASS.
 - A function size, class name, dependency count, cache preference, or fixed architecture shape without changed-code evidence and concrete risk is not a blocking finding.
 
@@ -448,8 +453,8 @@ Pass check:
 
 ```text
 Diff reviewed: actual changed files/ranges
-Plan boundary: File Structure row(s) and verdict
-Prewalk evidence: Trace / Handoff Facts / completion evidence
+Plan boundary: approved task Files rows and verdict
+Progress evidence: row Status plus recorded command/result
 Blockers: 0
 Warnings: 0
 Recommendations: 0 or documented
@@ -683,7 +688,7 @@ Judgment: FAIL
 Input:
 
 ```text
-A Build subagent receives an approved Plan whose latest Prewalk trace records `OrderHistoryQuery`, its API handler, and current authorization behavior. The first remaining work item anchors the query and handler. A minimal anchor reread discovers a new authorization policy that changes denial behavior and the requested rule's placement.
+A Build subagent receives an approved legacy Plan whose latest Prewalk trace records `OrderHistoryQuery`, its API handler, and current authorization behavior. The first remaining work item anchors the query and handler. A minimal anchor reread discovers a new authorization policy that changes denial behavior and the requested rule's placement.
 ```
 
 Expected behavior:

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

@@ -2,6 +2,10 @@
 
 Owners: `devflow-prove` and `devflow-pua`. Load this reference after completed Build directly enters Prove or when Core selects Proof or Recovery for a non-unique artifact.
 
+## Proof Context Selection
+
+Keep proof context proportional to the change. Always load this reference. Load `flow-self-test.md` only for DevFlow runtime, skill, command, host, hook, validator, scenario, installer, or harness changes; ordinary application changes use the changed file, its direct contract, and the relevant proof command. Load `code-review-checklist.md` for code and apply General Engineering Review plus only language sections matching changed extensions. Narrow context does not weaken diff review, adversarial review, or fresh proof.
+
 ## Method 13: Proof Before Done
 
 Run fresh, narrow evidence before a completion claim. Rules and skills need file, trigger, load, and downstream evidence. Code needs a focused test, build, lint, typecheck, or reproducible scenario. A bug fix needs symptom or regression proof.

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

@@ -52,6 +52,7 @@ Do not force a spec for Design-lite work where a short design contract and quick
    - Design: the comparison names the real alternatives and the selected approach has an explicit trade-off.
 6. Run `node scripts/devflow-spec.js <spec-file>` when the script exists. If not found at `scripts/devflow-spec.js` (project-level), try `~/.codex/scripts/devflow-spec.js` or `~/.claude/scripts/devflow-spec.js` (user-level). Do NOT look under `skills/scripts/`. See `core-methods.md` Script Path Resolution.
 7. **STOP — Wait for user approval of the design contract and spec.** On DSH, request approval with the structured `ask_user_question` tool (single-select: approve / request changes). Tell the user the spec path and review result. If they request changes, revise the comparison/design contract and re-run self-review. An approved A-branch Spec directly enters `devflow-cut`; any non-success state returns facts to `devflow-core`.
+8. On approval, advance the requirement row in `docs/requirements.md` to `designed` and fill the spec path in its artifact column.
 
 ## Output
 

package/package.json

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