@devflow-core/dsh-devflow 0.5.0 → 0.6.1

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

@@ -19,6 +19,10 @@ Verification:
 
 Split multi-step work into one to five testable slices. Each slice names files, user-visible or contract behavior, verification, and comment requirements. Verify a slice before moving on whenever a focused check exists.
 
+Build owns how. A v2 plan task gives `Files`, `Change`, `Acceptance`, `Verify`, and `Not doing`; the executor reads the named anchors plus one directly changed neighbor, chooses the smallest implementation inside that boundary, and records the choice in the task's `## Progress` evidence. It does not wait for Plan to pre-decide the edit, and it does not widen the boundary. Legacy plans that prescribe `Change mechanics` are followed as written.
+
+After a slice passes its verification, write back the plan's `## Progress` row: `doing` while in flight, `done` with the command and key result when verified. On a legacy plan without a Progress table, report the same evidence in the completion message.
+
 ## Readability Outcome Check
 
 Before handoff, review changed code from the perspective of a maintainer familiar with the project but not this change. Use names, structure, extraction, comments, and tests as appropriate; do not apply any technique mechanically.

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

@@ -15,6 +15,7 @@ Trigger: <user words or task shape>
 Route: Problem / Fast / Design-lite / Design / Build / Recovery
 Brainstorm required: yes/no
 Depth hint: skip / compact / standard / deep / none
+Preferences applied: <count of global preference cards matched this turn>
 Next skill: <skill name or none>
 Status: [DevFlow: <node> -> <next> | awaiting approval / in progress]
 ```
@@ -25,7 +26,7 @@ While a DevFlow lifecycle node is active, end each user-facing message with one
 
 Read `skills/devflow-core/references/core-methods.md` before route selection. It supplies Method 0, shared route rules, and the owner map. Do not load all lifecycle references by default.
 
-Read the narrowest relevant project facts, then progressively recall learning and project knowledge. Scan available skills and record a matching external specialist skill; a specialist may perform bounded specialist work inside the current node while DevFlow retains route and node ownership.
+Read the narrowest relevant project facts, then match the task keywords against `docs/features/INDEX.md` and `docs/plans/INDEX.md` when present and open only the matched row's entry file or ledger section; an index over 40 rows is filtered with `node scripts/devflow-plan.js --index --query 关键词`. Do not bulk-read capability documents. Then progressively recall learning and project knowledge. Scan available skills and record a matching external specialist skill; a specialist may perform bounded specialist work inside the current node while DevFlow retains route and node ownership.
 
 Before a route-specific decision, load only the selected owner reference:
 
@@ -61,6 +62,8 @@ Brainstorm is required when any material risk or decision-impact uncertainty exi
 | Build | User asks to implement, fix, build, or land an approved change. | Select Cut, then Plan when construction needs several steps, then Build and Prove. |
 | Recovery | Same target remains wrong after correction or proof failure. | Select PUA, consume recovery facts, then choose a different path. |
 
+Every creative or problem-directed change creates or updates one row in `docs/requirements.md`: Brainstorm writes `open` after `Confirmed request`, and Design-lite writes `open` with depth `C` when Brainstorm is skipped. Pure Q&A, lookup, read-only verification, and explicit independent reviews create no row.
+
 ## Core Flow Map
 
 ```text

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

@@ -35,10 +35,11 @@ Apply these principles to every route:
 Read the narrowest useful facts:
 
 1. Project rules and relevant source, tests, commands, and current docs.
-2. `.copilot/LEARNING_INDEX.md`, then only cards whose Trigger and Scope match.
-3. `docs/project-knowledge/AI-START-HERE.md` or `index.md`, then only navigation-selected documents.
-4. `graphify-out/GRAPH_REPORT.md` when architecture impact is in scope.
-5. Available environment skills; record a matching specialist skill without widening DevFlow scope. For a matched specialist, record the bounded-work contract:
+2. `docs/features/INDEX.md` and `docs/plans/INDEX.md` when present: match the task keywords against the index rows and read only the matched row's entry file or ledger section; an index over 40 rows is filtered with `node scripts/devflow-plan.js --index --query 关键词`. Do not bulk-read capability documents. Missing indexes are non-blocking.
+3. `.copilot/LEARNING_INDEX.md`: match `Scope: global` preference cards first (few, cross-project), then `project` cards whose Trigger and Scope match. Apply known preferences and report the count in Activation Evidence.
+4. `docs/project-knowledge/AI-START-HERE.md` or `index.md`, then only navigation-selected documents.
+5. `graphify-out/GRAPH_REPORT.md` when architecture impact is in scope.
+6. Available environment skills; record a matching specialist skill without widening DevFlow scope. For a matched specialist, record the bounded-work contract:
 
 ```text
 Owner: current DevFlow node

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

@@ -167,6 +167,14 @@ CUT_REUSE: existing capability can be reused; do not write new implementation
 CUT_BLOCKED: missing facts or risk too high; return the blocking facts to `devflow-core`
 ```
 
+Every result also records a four-line decision plus a mandatory subtraction record:
+
+```text
+Cut: 做 <what is included> | 不做 <what is excluded> | 复用 <reused capability> | 验证 <verification> | Rejected: <at least one candidate scope, dependency, abstraction, or config that was cut, or none plus evidence why nothing could be cut>
+```
+
+`Rejected` is what separates a real Cut from a rubber stamp. A Cut that removes nothing writes `Rejected: none` and names the evidence that ruled each candidate out; a Cut that removes something names it. Without this line, a plan can pass every gate while quietly carrying avoidable work.
+
 When `CUT_REDUCE` or `CUT_REUSE` occurs, **STOP — present the reduction or reuse finding to the user**. Explain what was cut, what existing capability replaces it, and why the smaller option is sufficient. After confirmation, return the confirmed result to `devflow-core`.
 
 When `CUT_BLOCKED` occurs, return the blocking facts to `devflow-core`. Core decides whether it must restart `devflow-brainstorm` to re-explore the goal and constraints.
@@ -195,7 +203,7 @@ When `CUT_BLOCKED` occurs, return the blocking facts to `devflow-core`. Core dec
 
 ## Handoff
 
-After `CUT_PASS`, record a Cut Decision containing the allowed scope, reuse conclusion, exclusions, required verification, `External Skills`, and `Depth`. A recorded specialist role performs bounded work only; Cut retains reuse and scope authority, and `CUT_PASS` is never delegated. A/B directly enter `devflow-plan`; C directly enters `devflow-build`. `CUT_REDUCE`, `CUT_REUSE`, and `CUT_BLOCKED` return facts to `devflow-core`; `CUT_REDUCE` and `CUT_REUSE` remain stopped until user confirmation. A Plan Pack that broadens scope returns affected-gate facts to Core before any later selection.
+After `CUT_PASS`, record a Cut Decision containing the four-line decision, the `Rejected` subtraction record, allowed scope, reuse conclusion, exclusions, required verification, `External Skills`, and `Depth`. When a plan file is produced, the four lines and `Rejected` go into the plan header; at depth C they stay in the Build Contract message. A recorded specialist role performs bounded work only; Cut retains reuse and scope authority, and `CUT_PASS` is never delegated. A/B directly enter `devflow-plan`; C directly enters `devflow-build`. `CUT_REDUCE`, `CUT_REUSE`, and `CUT_BLOCKED` return facts to `devflow-core`; `CUT_REDUCE` and `CUT_REUSE` remain stopped until user confirmation. A Plan Pack that broadens scope returns affected-gate facts to Core before any later selection.
 
 ## Verification
 
@@ -204,5 +212,6 @@ Before leaving this skill, confirm:
 - [ ] Reuse, Root-Cause when relevant, Native, Overbuild, Diff, and Scope checks were answered.
 - [ ] Any new structure has a current need.
 - [ ] Removed scope is explicitly named.
+- [ ] The four-line `Cut` decision is recorded, with a non-empty `Rejected` or `none` plus evidence.
 - [ ] Intentional simplifications have `devflow:` ceiling and revisit trigger markers.
 - [ ] Cut result is one of the four allowed statuses.

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

@@ -40,8 +40,11 @@ Reuse Check: what existing capability was checked first?
 Trace Check: what accepted request does each key change trace to?
 Scope Check: what tempting but unrequested feature was removed?
 Diff Check: which user goal does each changed file serve?
+Rejected: what candidate scope, dependency, abstraction, or config was cut — or none plus the evidence that ruled each candidate out?
 ```
 
+`Rejected` is not optional. A gate that answers only "what is included" cannot show whether any subtraction happened, which is how a Cut degrades into a stamp. Name the cut candidate, or name the evidence that closed each candidate out.
+
 ## Method 8A: Contextual Design Quality Check
 
 For changes that introduce or relocate code, alter module responsibilities, or add performance behavior, inspect the nearest comparable project code before selecting a shape. Record the decision without requiring a fixed layer, class count, interface, or cache:

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

@@ -34,7 +34,7 @@ Rules:
 
 - Treat only an explicit selection as approval to create that document type.
 - Treat silence, an ambiguous reply, or an unselected item as not approved.
-- Treat `none` as a completed follow-up with no files written.
+- Treat `none` as a completed follow-up with no files written; record it as `opt-out` in `docs/requirements.md` with the skip reason and the verification evidence. Silence or an ambiguous reply never becomes `opt-out`; the default requirement record still applies.
 - If the user selects more than one type, create only those selected types.
 
 ## Evidence And Landing

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

@@ -19,15 +19,21 @@ Extract only knowledge that can help a future task:
 - a non-obvious repository convention or invariant
 - a costly, counterintuitive, repeated, or project-wide lesson
 - a confirmed project-business fact that may require knowledge-package maintenance
+- a user-visible capability or interface-contract change that must appear in `docs/features/INDEX.md`
+- a developer preference about how to work — language, documentation depth, design-first, verify-command habits, review style — confirmed by a repeated correction
 
 `PASS` requires the review, not a new record. If no useful reusable knowledge remains after classification, report that result and create nothing.
 
 | Review result | Action | Store |
 |---|---|---|
 | Reusable execution experience or proven work pattern | Create or update one focused card | `.copilot/cards/` |
+| User-visible capability or interface contract changed | Add or update one row: what it does, its trigger words, its entry point, its verify command, and its source plan | `docs/features/INDEX.md` |
+| The same how-to preference was corrected twice | Create or update one `Scope: global` preference card | `.copilot/cards/` |
 | Confirmed business fact changed | Report a project-knowledge candidate and wait for user confirmation | `docs/project-knowledge/` after confirmation via `devflow-project-knowledge` |
 | Ordinary detail, one-off fact, already-covered lesson, or pure refactor without insight | Report no useful record | none |
 
+The capability row is a mechanical duty, not a documentation inquiry: a verified change that alters what a user can do, or an interface contract others depend on, must be findable from one index on the next session. Writing a longer document still needs explicit user confirmation through `devflow-docs-followup`.
+
 Project-knowledge candidates include changed domain semantics, rules, boundaries, entity/DTO/enum meaning, API or table boundaries, module responsibility, job behavior, and task entry points. `devflow-learn` must not update the package itself or infer business facts without evidence.
 
 ## Process
@@ -39,6 +45,7 @@ Project-knowledge candidates include changed domain semantics, rules, boundaries
 4. Extract a candidate from the task's implementation, decisions, proof, and business impact.
 5. Decide whether to record:
    - record if the candidate is cross-task reusable and proven useful, costly if missed, counterintuitive, non-obvious, repeated, or project-wide
+   - add or update one capability row in `docs/features/INDEX.md` with trigger words if the verified change altered user-visible behavior or an interface contract; report `no-change` otherwise
    - report a project-knowledge candidate if code-backed business semantics changed; wait for user confirmation before calling `devflow-project-knowledge`
    - skip if it is ordinary narration, a one-off fact, already covered, or too context-specific
 6. Create `.copilot/LEARNING_INDEX.md`, `.copilot/cards/`, and one focused card only when the result belongs in project learning; do not create empty learning storage after a no-record review.
@@ -96,9 +103,10 @@ Learning storage is lazily created only by this skill after a qualifying reusabl
 |---|---|---|
 | `graphify-out/` | Structural code graph, communities, and dependency relationships | Execution lessons or curated business guidance |
 | `.copilot/cards/` | Execution experience, intercept rules, and proven work patterns | Business reference documentation |
+| `docs/features/INDEX.md` | The capability routing index: what a feature does, its trigger words, its entry point, its verify command, and its source plan | Execution lessons, business reference docs, version history, feature bodies |
 | `docs/project-knowledge/` | Curated, code-backed business facts, boundaries, and task entry points | Agent mistakes or raw implementation history |
 
-Handoff: `devflow-prove PASS` -> `devflow-learn` review -> project-knowledge candidate -> user confirmation -> `devflow-project-knowledge` lazy maintenance of `docs/project-knowledge/`. Only after a verified feature implementation with an actual source-behavior or interface-contract change may `devflow-learn` hand off to `devflow-docs-followup` for an optional documentation inquiry. Do not automatically hand off validation-only, documentation-only, rule-only, skill-only, or no-diff `PASS` results.
+Handoff: `devflow-prove PASS` -> `devflow-learn` review -> capability row in `docs/features/INDEX.md` and/or a project-knowledge candidate -> user confirmation -> `devflow-project-knowledge` lazy maintenance of `docs/project-knowledge/`. Only after a verified feature implementation with an actual source-behavior or interface-contract change may `devflow-learn` hand off to `devflow-docs-followup` for an optional documentation inquiry. Do not automatically hand off validation-only, documentation-only, rule-only, skill-only, or no-diff `PASS` results.
 
 ## Card Format
 
@@ -133,6 +141,7 @@ Read this index first. Only read a card when its trigger matches the current tas
 | 1 | Create/update card, confidence 0.3-0.5 |
 | 2 | Raise confidence and force recall before acting |
 | 3 | Propose `AGENTS.md` or platform rule update |
+| Card confidence reaches 0.7 | Propose the rule or skill change and create one `docs/requirements.md` row for the proposal, so learning returns to the requirement loop |
 | 4+ | Propose skill or command automation |
 | User explicitly says remember/learn/沉淀 | Promote immediately if scope is clear |
 
@@ -145,7 +154,8 @@ Learning closure:
 - Learning signal: PASS review/correction/pitfall/none
 - Recall record: none/index/card
 - Knowledge recall: none/learning index + matched card/project knowledge candidate
-- Review result: learning card/project-knowledge candidate/no useful record
+- Review result: learning card/capability row/project-knowledge candidate/no useful record
+- Capability entry: added/updated/no-change
 - New sediment: none/learning card/rule/skill
 - Next intercept: next time <X>, first do <Y>, do not do <Z>
 ```
@@ -172,5 +182,6 @@ Before leaving this skill, confirm:
 - [ ] Only matched cards were read.
 - [ ] Repeated user corrections, repeated user challenges, and misplaced content were recorded or explicitly classified as already covered.
 - [ ] New or updated card has trigger, lesson, next action, scope, related files, evidence, and invalidation condition.
+- [ ] A user-visible capability or interface-contract change added or updated one `docs/features/INDEX.md` row with trigger words, or was reported as `no-change`.
 - [ ] Business-semantic changes were reported as candidates and await user confirmation before knowledge-package maintenance.
 - [ ] Completion output includes learning closure.

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 can edit directly while still re-reading the current task anchor. A directly changed neighbor is reread only when it is already listed and its contract could invalidate the edit.
-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 execution basis（执行规范）handed to the executor. The executor must re-read the current task's named anchors. A current task anchor and directly changed neighbor may be reread only when that neighbor is already listed and its contract could invalidate the edit; this is a bounded drift check, not broad repository rediscovery. `Read-basis` / `Live anchors` remain the plan author's evidence record. Do not silently repair stale instructions, redesign outside scope, or expand the touch set.
+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, must reread named anchors, may reread at most one already-listed neighbor for drift detection, edits, runs `Verify`, appends actual evidence, and returns observed differences as facts to `devflow-core` when an edit or verification fails. 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 named-anchor rereads and at most one already-listed neighbor, 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 — receives only the current task's execution spec (`Files`, exact replacement rules, `Steps`, `Verify`). Before editing, it must re-read the current task's named anchors. A current task anchor and directly changed neighbor may be reread only when that neighbor is already listed and its contract could invalidate the edit; it must not broadly rediscover the repository, re-plan, or expand scope. `Read-basis` and `Live anchors` stay in the plan as the plan author's evidence record. A detected mismatch returns facts to Core instead of silent repair.
+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, or a bounded reread finds changed authorization/contract behavior, 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 guess past a mismatch. A stale line reference may be corrected 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, must reread named anchors and at most one already-listed neighbor, edits its task's `Files`, runs its task's `Verify`, and returns evidence or failure facts. It does not broadly rediscover or redesign. 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 must reread current named anchors and at most one already-listed neighbor for drift, but never broadly rediscover or redesign; it edits, verifies, appends 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. 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

@@ -92,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.
@@ -99,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

@@ -383,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.
 
@@ -413,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
 ```
@@ -442,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.
 
@@ -451,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
@@ -686,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-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.5.0",
+  "version": "0.6.1",
   "description": "DevFlow for DeepSeek Harness: devflow-2 agent preset + skills + commands + verification scripts, synced into ~/.dsh on host startup.",
   "type": "module",
   "engines": {