@devflow-core/dsh-devflow 0.4.0 → 0.6.0

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

@@ -1,6 +1,6 @@
 ---
 name: devflow-brainstorm
-description: "You MUST use this before any creative work — creating features, building components, adding functionality, modifying behavior, or defining a problem-directed change. Explores user intent, requirements, problem boundaries, and design intent before implementation. Acts as a brainstorming partner: clarifies what the user wants through a semantic echo-back, examines the problem from multiple angles, surfaces gaps and risks, and recommends directions within the problem space; stops after a fixed Confirmed request summary and explicit A/B/C depth gate. Do NOT use it for pure Q&A, lookup, verification, or an already approved change; do NOT select a route or depth, produce implementation designs, or hand off except through the user-selected predefined direct branch."
+description: "Use when devflow-core sends ambiguous or materially risky creative work for clarification — creating features, building components, adding functionality, modifying behavior, or defining a problem-directed change. Clarifies intent through a semantic echo-back, runs risk-relevant problem-space exploration, and stops after a fixed Confirmed request summary and explicit A/B/C depth gate. Do NOT use it for clear low-risk existing behavior, pure Q&A, lookup, verification, or an already approved change; do NOT select a route or depth, produce implementation designs, or hand off except through the user-selected predefined direct branch."
 ---
 
 # DevFlow Brainstorm
@@ -13,7 +13,7 @@ This skill owns only:
 
 - minimal fact reading needed to understand the request;
 - Semantic Echo-Back and understanding correction;
-- mandatory multi-angle problem exploration: surfacing gaps, risks, blind spots, and unstated assumptions in the user's request;
+- Core-selected, risk-relevant problem exploration: surfacing gaps, risks, blind spots, and unstated assumptions in the user's request;
 - ideas, suggestions, and direction recommendations inside the problem space;
 - one-at-a-time clarification of goal, scope, exclusions, constraints, acceptance, and real open questions;
 - the fixed `Confirmed request` summary.
@@ -25,20 +25,21 @@ Use `references/interview-discipline.md` for the Semantic Echo-Back, multi-angle
 
 ## Entry And Stop Condition
 
-Enter only when `devflow-core` has identified a requirement, behavior, architecture, or ambiguity that needs clarification.
+Enter only when `devflow-core` has identified ambiguity or material risk that needs clarification. Core may bypass this skill for a clear, reversible, local existing-feature change with one plausible path, no security/data-loss/permission/contract risk, and quick proof.
 
 After producing the fixed summary, present the A/B/C gate and wait for user selection. Start A at `devflow-spec` and B/C at `devflow-cut` only after the user chooses. Do not select Fast, Design-lite, a depth, an approach, or a method on the user's behalf. Do not create design sections, a design contract, documentation, or a visual artifact.
 
 ## Clarification Depth
 
-Depth governs **analysis breadth only**. It never skips the echo-back, the confirm gates, the question discipline, or the recommendation duty.
+Core supplies a depth hint after selecting this skill. Depth governs **analysis breadth only**. It never skips the echo-back, the confirm gates, the question discipline, or the recommendation duty. Compact mode is analysis compression, not permission to skip confirmation.
 
 | Tier | Use when | Behavior |
 |---|---|---|
-| `deep` (default) | Every request, unless the user explicitly asks for a lighter pass. | Full multi-angle checklist with a per-angle report, gap/risk surfacing, direction options with trade-offs, and a recommendation. |
-| `standard` | Only on explicit user request for a lighter pass. | Run the fitting angles instead of the full checklist; every other duty unchanged. |
+| `compact` | Core has established clear goal, scope, constraints, acceptance, and a bounded material-risk reason. | Echo-back, risk/edge/acceptance check, only decision-impact questions, and fixed summary; record non-blocking angles as `none`. |
+| `standard` | Core identifies several relevant uncertainties or interacting impacts without full architecture ambiguity. | Run fitting angles with trade-offs and recommendation; every other duty unchanged. |
+| `deep` | Ambiguous, high-risk, cross-module, externally visible, irreversible, security-sensitive, data-loss-sensitive, or contract-changing work. | Full multi-angle checklist with per-angle findings, gap/risk surfacing, direction options with trade-offs, and recommendation. |
 
-There is no fast lane. A request that turns out clear after analysis simply ends with fewer questions — the analysis still ran and its findings still reach the summary.
+If no decision-impact gap remains after the supplied facts and echo-back, ask no clarification question. Still produce the fixed summary and wait for confirmation and A/B/C.
 
 ## Clarification Process
 
@@ -65,7 +66,7 @@ There is no fast lane. A request that turns out clear after analysis simply ends
    ```
 
 5. **Revalidate every answer.** Before asking the next question, compare the answer with confirmed facts and the current request. If it introduces a load-bearing assumption, exposes a contradiction, or changes goal, scope, exclusion, constraint, acceptance, terminology, or actor, apply the Understanding Revision Rule. Otherwise record the answer and continue only when another decision-impact gap remains.
-6. **Explore the problem.** Walk the multi-angle checklist from the reference and report what each angle found, including "nothing found here". Name gaps, risks, and blind spots in the user's request; offer directions with trade-offs and recommend one inside the problem space. If exploration exposes a new decision-impact gap, return to step 4 and resolve it one question at a time before finishing.
+6. **Explore the problem.** In `compact`, run only risk, edge, impact, and acceptance checks; in `standard`, run fitting angles; in `deep`, walk the full checklist from the reference. Report negative findings, name gaps and risks, offer directions with trade-offs, and recommend one inside the problem space. If exploration exposes a new decision-impact gap, return to step 4 and resolve it one question at a time before finishing.
 7. **Finish.** When no decision-impact gap remains and every non-blocking unknown is recorded, output the fixed summary, present the A/B/C gate, and wait. On user selection, follow only the corresponding predefined direct branch.
 
 ## Problem-Space Recommendation
@@ -121,6 +122,8 @@ Confirmed request:
 
 The summary records the agreed request and the exploration findings only. It must not contain an implementation plan, solution-space design, lifecycle route, or handoff instruction. It is the factual basis that downstream skills — starting with `devflow-spec` — build on, so record findings faithfully rather than trimming them away.
 
+On `Status: clarified`, create or update the requirement row in `docs/requirements.md` with status `open`; depth is recorded when the lifecycle path is chosen. Pure Q&A, lookup, and read-only verification create no row.
+
 ## A/B/C Gate
 
 After the fixed summary, present these choices and wait for one explicit user selection:

package/assets/skills/devflow-brainstorm/references/interview-discipline.md

@@ -21,14 +21,15 @@ User request
 
 ## Clarification Depth
 
-Depth governs **analysis breadth only**. It never skips the echo-back, the confirm gates, the question discipline, or the recommendation duty.
+Core selects a depth hint when it sends the request. Depth governs **analysis breadth only**. It never skips the echo-back, the confirm gates, the question discipline, or the recommendation duty. Compact mode compresses analysis; it does not remove confirmation.
 
 | Tier | Entry condition | Moves |
 |---|---|---|
-| `deep` (default) | Every request, unless the user explicitly asks for a lighter pass. | Full multi-angle checklist with a per-angle report; directions with trade-offs; recommendation. |
-| `standard` | Only on explicit user request for a lighter pass. | Fitting angles instead of the full checklist; every other duty unchanged. |
+| `compact` | Core has supplied clear goal, scope, constraints, acceptance, and a bounded material-risk reason. | Echo-back, risk/edge/acceptance check, decision-impact questions only, then fixed summary. |
+| `standard` | Several relevant uncertainties or interacting impacts exist without full ambiguity. | Fitting angles with trade-offs and recommendation; every other duty unchanged. |
+| `deep` | Ambiguity, high impact, cross-module/external effects, irreversible/security/data-loss/permission/contract risk, or missing facts. | Full multi-angle checklist with per-angle report; directions with trade-offs; recommendation. |
 
-There is no fast lane. When the user asks for speed, compress wording, never gates.
+When no decision-impact gap remains, ask no clarification question. Always retain the echo-back, confirmation, fixed summary, and A/B/C gate.
 
 ## Semantic Echo-Back
 

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

@@ -19,7 +19,7 @@ When no plan file exists, the approved design and Cut Decision form the Build Co
 
 Load `skills/devflow-build/references/build-methods.md` after this section and before implementation slices. It owns the detailed minimal-change and slice discipline.
 
-There is no pre-edit plan review. The executor reads only the current task's execution spec — `Files`, `Change mechanics`, `Steps`, `Verify` — from the approved plan, edits those files directly, runs `Verify`, and appends actual evidence. An actual edit or verification failure must stop and return `BUILD_BLOCKED` with the facts to `devflow-core`: the observed mismatch, affected anchor, and smallest replan decision. Do not pre-check anchors, do not guess, do not silently repair the plan.
+There is no broad pre-edit plan review. The executor reads the current task's `Files`, `Change`, `Acceptance`, `Verify`, and `Not doing`, and may read the task's named anchors plus one directly changed neighbor to choose the smallest implementation. Build owns how inside the task boundary; it must not broadly rediscover the repository, redesign outside the task boundary, silently repair the plan, or expand scope. An anchor mismatch or verification failure must stop and return `BUILD_BLOCKED` with facts to `devflow-core`: observed mismatch, affected anchor, and smallest replan decision.
 
 Every skill declared in `External Skills` (Cut Decision or plan header) must actually be loaded through the platform's skill mechanism, or the reason it does not apply recorded; loading alone is not completion — Build requires the specialist's returned result, not-applicable, or failure facts. A specialist result implying structure outside the approved scope returns scope-drift facts to `devflow-core`, not silent adoption. Skill loading is not a pre-edit view and remains mandatory.
 
@@ -44,9 +44,11 @@ If work touches more than one file or one logical step, create Implementation Sl
 
 When saving a plan file, use `docs/plans/YYYY-MM-DD-<short-kebab-name>.md`, resolved from the current target project's root, unless that project already documents another plan/spec path. Do not save implementation plans under `docs/features/`; that directory is for feature ledgers.
 
-For multi-step work, tasks must cite the approved source, be small and verifiable, and follow the required task contract (Task: / Task type: / Files: / Interfaces: / Current behavior: / Target behavior: / Change mechanics: / Call impact: / Steps: / Acceptance: / Verify: / Comments: / Not doing:) defined in `skills/devflow-plan/SKILL.md`.
+For multi-step work, tasks must cite the approved source, be small and verifiable, and follow the six-field contract (`Task` / `Files` / `Change` / `Acceptance` / `Verify` / `Not doing`) in `skills/devflow-plan/SKILL.md`. Legacy plans with `Change mechanics` and `Prewalk` stay executable under their own contract.
 
-No unresolved markers. For `Code change`, the dispatched execution spec follows the recorded file symbol/anchor and `Change mechanics`; do not re-decide the implementation mechanism in Build. `Current behavior`, `Target behavior`, and `Call impact` are the plan author's records, not executor re-read requirements. The verification step must retain its trigger/input, expected result, and command or manual scenario. `Documentation-only` applies only to tasks with no runtime code files and explicit `documentation-only` interfaces. No "add tests" without naming the behavior. No "handle edge cases" without naming the edge case. No "similar to Task N" shortcuts; repeat enough detail for each task to stand alone.
+No unresolved markers. `Change` states the executable intent and boundary; add exact mechanics only when the change crosses a module contract, is irreversible, or touches security or data boundaries. Otherwise Build chooses the smallest implementation and records it as Progress evidence. The verification step keeps its trigger/input, expected result, and command or manual scenario. A task whose files are all documentation paths is documentation-only. No "add tests" without naming the behavior, no "handle edge cases" without naming the edge case, no "similar to Task N" shortcuts.
+
+Close each task by writing back its `## Progress` row: `doing` when starting, `done` with the command and key result when its `Verify` passes. A `done` row without evidence fails the checker. On a legacy plan without a Progress table, report the same evidence in the completion message. When every task is `done`, advance the requirement row in `docs/requirements.md` to `built`.
 
 Before Build, run `node scripts/devflow-plan.js <plan-file>` when a plan is saved to a file. If not found at `scripts/devflow-plan.js` (project-level), try `~/.codex/scripts/devflow-plan.js` or `~/.claude/scripts/devflow-plan.js` (user-level). Do NOT look under `skills/scripts/`. See `core-methods.md` Script Path Resolution.
 
@@ -191,7 +193,7 @@ If any file has no goal link, remove that change.
 | "We'll verify everything at the end." | Verify slices when focused checks exist. |
 | "Docs changes do not need proof." | Docs/rules/skills need validation just like code. |
 | "The issue only mentions one caller." | Check sibling callers before choosing the fix location. |
-| "The plan is approved, so I just execute." | Right: the approved execution spec is edited directly; an actual edit or verification failure returns `BUILD_BLOCKED` to Core. |
+| "The plan is approved, so I just execute." | The plan fixes the boundary and proof; Build still chooses the smallest implementation inside that boundary. A real edit or verification failure returns `BUILD_BLOCKED` to Core. |
 | "I'll infer the missing step." | Guessing past a gap is forbidden; unclear instructions return `BUILD_BLOCKED` facts. |
 | "The code is self-explanatory." | That does not waive a comment required by the approved contract, project convention, or a non-obvious boundary. |
 | "Comments will get stale." | Keep a required comment accurate or remove a stale one; a stale explanation is not a reason to skip a needed decision record. |

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

@@ -1,6 +1,6 @@
 ---
 name: devflow-core
-description: "Use when starting development work, routing Problem, Fast, Design-lite, Design, Build, or Recovery work, investigating issues, handling requirements or bugs, or deciding which DevFlow skill owns the next lifecycle step. Before any creative work — creating features, building components, adding functionality, modifying behavior, or defining an unapproved problem-directed change — select devflow-brainstorm for a Confirmed request; pure Q&A, lookup, verification, and investigation-only reports remain exceptions."
+description: "Use when starting development work, routing Problem, Fast, Design-lite, Design, Build, or Recovery work, investigating issues, handling requirements or bugs, or deciding which DevFlow skill owns the next lifecycle step. Apply Core's risk gate before selecting Brainstorm or Cut; clear low-risk existing behavior may skip Brainstorm but never Cut or Prove."
 ---
 
 # DevFlow Core
@@ -13,6 +13,9 @@ Route work through the smallest reliable lifecycle. Core owns next-step selectio
 Skill Activation: devflow-core
 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]
 ```
@@ -23,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:
 
@@ -45,18 +48,26 @@ Unknowns: <none or specific unknown>
 
 ## Routes
 
+Apply this precedence before choosing a route: explicit independent review -> investigation or pure inquiry -> approved scope -> risk gate -> lifecycle owner. Do not route from keywords alone.
+Investigation-only reports remain a Problem exception and do not enter Brainstorm.
+
+Brainstorm is required when any material risk or decision-impact uncertainty exists. A request may bypass Brainstorm only when all of these are true: clear goal, existing local behavior, one plausible path, local impact, reversible change, no security/data-loss/permission/contract risk, and quick proof. Any unknown or failed factor keeps Brainstorm. Skipping Brainstorm compresses analysis only; it never skips Cut or Prove. Unapproved edits never use Fast.
+
 | Route | Use when | Core action |
 |---|---|---|
 | Problem | A reported problem has no explicit fix request. | Prove facts first, then select later work only if a change is known. |
-| Fast | Pure answer, lookup, verification, or one local low-risk change. | Sense, then narrow proof. |
-| Design-lite | Existing feature, one clear low-risk path, quick proof. | State goal, acceptance, exclusions; select Cut before Build. |
+| Fast | Pure answer, lookup, verification, or an already approved trivial change. | Sense, then narrow proof. |
+| Design-lite | Existing feature, all seven low-risk conditions hold. | Record `Brainstorm required: no` and `Depth hint: skip`; state goal, acceptance, exclusions; select Cut with Depth C, then Build. |
 | Design | New requirement, behavior or architecture change, ambiguity, or multiple options. | Select Brainstorm; after confirmation its user-selected A/B/C path directly starts Spec or Cut. |
 | 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
+Skip-Brainstorm Design-lite success: Cut -> Build -> Prove
 A direct success: Brainstorm -> Spec -> Cut -> Plan -> Build -> Prove
 B direct success: Brainstorm -> Cut -> Plan -> Build -> Prove
 C direct success: Brainstorm -> Cut -> Build -> Prove
@@ -79,7 +90,9 @@ Core selects only after a returned non-unique artifact. `CUT_REDUCE` and `CUT_RE
 
 ## Capability Dispatch
 
-- Unclear requirement, new feature, behavior change, or multiple options: select `devflow-brainstorm` for Semantic Echo-Back and a fixed Confirmed request.
+- Clear low-risk existing behavior with one plausible local path and quick proof: record skip depth, select `devflow-cut` directly with a Design-lite contract and Depth C; `CUT_PASS` enters Build. Keep the Cut and Prove gates.
+- An unapproved problem-directed change enters the risk gate; material risk or ambiguity selects `devflow-brainstorm`.
+- Unclear requirement, new feature, materially risky behavior change, cross-module impact, or multiple options: select `devflow-brainstorm` for Semantic Echo-Back and a fixed Confirmed request. Record `Brainstorm required: yes` and a depth hint: `compact` when goal, scope, and acceptance are already clear and one named residual risk remains that is not security, data-loss, permission, contract, or irreversible; `deep` for ambiguity or those protected risks; otherwise `standard`.
 - Explicit spec or design document: select `devflow-spec` after confirmed request.
 - New structure, dependency, abstraction, configuration, folder, or generic capability: select `devflow-cut`.
 - Approved construction work: select `devflow-build` when Core receives a non-unique construction artifact; A/B approved Plans and C `CUT_PASS` enter Build directly.

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
@@ -65,9 +66,19 @@ On DeepSeek Harness (DSH), a long autonomous node — a multi-command Problem or
 
 On DeepSeek Harness code mode (PTC, `run_code`), batch the independent Sense reads above into one program with `Promise.all` (read-only calls may overlap) and `print` only the needed fields instead of dumping full text, so the summary lands in the compaction head. Split into multiple calls when a later read depends on an earlier result. Wrap optional reads — missing indexes or matched cards — in `try/catch` around `ToolCallError` so a missing source stays non-blocking.
 
-## Method 2: Brainstorm Clarification
+## Method 2: Route Precedence And Risk Gate
 
-Before any creative work — creating features, building components, adding functionality, modifying behavior, or defining an unapproved problem-directed change — select `devflow-brainstorm`. This applies even when the request appears clear or low risk. Pure Q&A, lookup, verification, investigation-only reports, and already approved changes remain outside this entry gate.
+Evaluate in this order: explicit independent review -> investigation/pure inquiry -> approved scope -> risk gate -> route owner. Keywords are signals, not decisions.
+
+Brainstorm is required for new behavior, ambiguity, cross-module or externally visible impact, irreversible work, security/data-loss/permission/contract risk, or any missing fact that could change the plan. A clear existing-feature change may enter Cut directly only when every low-risk condition holds: clear goal, existing local behavior, one plausible path, local impact, reversible change, no security/data-loss/permission/contract risk, and quick proof. The absence of one condition is enough to keep Brainstorm controlled.
+
+Unapproved edits never use Fast. A skip records `Brainstorm required: no` and `Depth hint: skip`, writes a Design-lite contract (goal, acceptance, exclusions), and enters Cut at Depth C. Compact is only for a Core-sent hint where goal, scope, and acceptance are already clear and one named residual risk remains that is not security, data-loss, permission, contract, or irreversible work. Core never lets Brainstorm choose skip or depth.
+
+Low-risk autonomy compresses clarification; it does not authorize implementation. Cut still checks reuse, native options, overbuild, diff, and scope, and Prove still requires fresh evidence and adversarial review.
+
+## Method 2A: Brainstorm Clarification
+
+When Core selects Brainstorm for creative work — creating features, building components, adding functionality, modifying behavior, or defining an unapproved problem-directed change — load it before implementation. Clear low-risk existing behavior is the only creative-work bypass. Pure Q&A, lookup, verification, investigation-only reports, and already approved changes remain outside this entry gate.
 
 Read minimum facts, send a Semantic Echo-Back, resolve one real uncertainty at a time, and stop after this fixed artifact:
 
@@ -86,7 +97,7 @@ After the fixed summary, Brainstorm presents A/B/C for an explicit user selectio
 
 ## Method 3: Small Request Boundary
 
-Use Fast only when impact, risk, uncertainty, and proof are all small. Design-lite is for an existing feature with one plausible path after facts are read. Choose full Design when behavior, options, contracts, modules, compatibility, or rollback are unclear. Ask the user to choose when facts cannot distinguish the route.
+Use Fast only for inquiry, verification, or already approved trivial changes; unapproved edits are not Fast. Design-lite is the skip-Brainstorm path for an existing feature after the seven-factor gate passes. Choose full Design when behavior, options, contracts, modules, compatibility, or rollback are unclear. Ask the user to choose when facts cannot distinguish the route.
 
 ## Method 4: Method Lens
 

package/assets/skills/devflow-core/references/reference-projects.md

@@ -63,7 +63,7 @@ What it does:
 
 Absorbed into DevFlow-Core:
 
-- `Sense -> Brainstorm -> [STOP: Depth A/B/C] -> (A: devflow-spec -> /devflow-plan | B: /devflow-plan | C: direct) -> devflow-cut -> devflow-build -> devflow-prove` remains the default chain.
+- Ambiguous or material-risk work still uses `Sense -> Brainstorm -> [STOP: Depth A/B/C] -> (A: devflow-spec -> /devflow-plan | B: /devflow-plan | C: direct) -> devflow-cut -> devflow-build -> devflow-prove`. Clear low-risk existing behavior skips Brainstorm as Design-lite Depth C: Cut -> Build -> Prove.
 - `devflow-brainstorm` includes design approval shape, assumption challenges, and approach comparison.
 - `devflow-spec`, `commands/devflow-spec.toml`, and `scripts/devflow-spec.js` add a saved requirements source for larger or explicitly spec-requested work.
 - Generated specs default to `docs/specs/YYYY-MM-DD-<short-kebab-name>.md`; `docs/plans/` remains implementation planning.

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

@@ -11,7 +11,7 @@ Cut unnecessary work before writing it.
 
 ## Context
 
-Receives a Core-selected approved design or an approved A-branch Spec. Cut decides the smallest implementation boundary before any construction plan; do not use a future plan as evidence for these gates.
+Receives a Core-selected approved design, an approved A-branch Spec, or a Core-selected Design-lite contract after the risk gate skipped Brainstorm. A Design-lite skip records Depth C and `CUT_PASS` enters Build. User-selected A/B still enter Plan. Cut decides the smallest implementation boundary before any construction plan; do not use a future plan as evidence for these gates.
 
 Before applying the Minimal Solution Ladder or Required Gates, load `skills/devflow-cut/references/cut-methods.md`. That reference owns the detailed reuse, root-cause, native, overbuild, and debt rules.
 
@@ -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.