@devflow-core/dsh-devflow 0.3.0 → 0.5.0

package/assets/commands/devflow-prove.toml

@@ -4,6 +4,8 @@ Run DevFlow Prove.
 
 Identify the narrowest sufficient command, test, build, lint, validation script, or manual scenario.
 Run it now if tools are available.
+Load `skills/devflow-prove/references/proof-recovery-methods.md` always. Load `skills/devflow-prove/references/flow-self-test.md` only for DevFlow runtime, skill, command, host, hook, validator, scenario, installer, or harness changes. For code, load `skills/devflow-prove/references/code-review-checklist.md`, always apply General Engineering Review, and apply only language sections matching changed extensions.
+Read the actual diff and the current task's named anchors; reread at most one already-listed neighbor needed to detect drift; do not restart broad repository discovery.
 For development work, run adversarial review before completion: state the strongest plausible reason the result is still wrong, incomplete, unreachable, over-broad, or under-verified, then check it against the acceptance criteria, touched files, likely regressions, activation path, and proof coverage.
 If adversarial review finds a real gap, report FAIL or continue the appropriate DevFlow route before any completion claim.
 Read the real output and exit status.

package/assets/commands/devflow.toml

@@ -2,17 +2,18 @@ description = "Route a task through DevFlow Core."
 prompt = '''
 Use DevFlow Core for this request.
 
-Route the work as Fast, Design-lite, Design, Build, or Recovery.
-Before creative work — creating features, building components, adding functionality, modifying behavior, or defining an unapproved problem-directed change — run Brainstorm to confirm the request: read facts, follow `skills/devflow-brainstorm/references/interview-discipline.md`, send a Semantic Echo-Back, apply the Understanding Revision Rule when a correction changes the request, ask one question at a time only for goal/scope/exclusions/constraints/acceptance/open-question gaps, then output `Confirmed request` with `Status: clarified`. Brainstorm then presents A/B/C and waits for the user's explicit choice: A directly starts Spec, B directly starts Cut then Plan, and C directly starts Cut then Build. Brainstorm never infers the depth; a missing or changed selection returns facts to Core.
+Route the work as Fast, Design-lite, Design, Build, or Recovery. Apply this precedence: explicit independent review -> investigation/pure inquiry -> approved scope -> risk gate -> lifecycle owner; keywords alone never choose a route.
+For creative work, run Brainstorm only when the request is ambiguous or materially risky. A clear existing-feature change may go directly to Cut only when all conditions hold: clear goal, existing local behavior, one plausible path, local impact, reversible change, no security/data-loss/permission/contract risk, and quick proof. This bypass compresses clarification only; Cut and Prove remain mandatory. When Brainstorm is selected, read `skills/devflow-brainstorm/references/interview-discipline.md`, send a Semantic Echo-Back, apply the Understanding Revision Rule when a correction changes the request, ask one question at a time only for decision-impact gaps, then output `Confirmed request` with `Status: clarified`. Brainstorm then presents A/B/C and waits for the user's explicit choice: A directly starts Spec, B directly starts Cut then Plan, and C directly starts Cut then Build. Brainstorm never infers the depth; a missing or changed selection returns facts to Core.
+An unapproved problem-directed change uses the same risk gate: ambiguity or material risk selects Brainstorm; otherwise the low-risk direct Cut criteria must all pass.
 An investigation-only problem report without a requested change uses Problem: Sense -> Prove facts. Pure Q&A, fact lookup, verification, and already approved changes are exceptions to the Brainstorm entry gate.
 If the user explicitly asks for upgraded adversarial review, deep adversarial review, red-team review, 对抗审查, or 升级版对抗审查, load `skills/devflow-adversarial/SKILL.md` directly. If the user explicitly asks to find faults, identify the biggest omission, surface a blind spot, name the least certain point, 找茬, 最大遗漏, 没有意识到什么, or 最没有把握, load `skills/devflow-find-fault/SKILL.md` directly. These are independent manual reviews: they may run at any stage and must not read, require, modify, or hand off to devflow-prove, PUA, Build, Learn, or any completion state.
 If the user challenges the result, says changed wrong, says your code is wrong/you wrote it wrong/has a problem/not right/missing/incomplete/still missing/有问题/不对/写错了/少了/少个/缺少/缺漏/遗漏/漏了, reports a quality complaint, or repeated edits miss, use Recovery through devflow-pua before more edits. For repeated challenge, explicit wrong-code signals, or repeated missing-piece complaints, return recovery facts to devflow-core; Core may restart devflow-brainstorm only for request re-confirmation, then selects the lifecycle work. Quarantine the old wrong context, diagnose the user-view miss, ask what is wrong and what result is wanted, then switch to a different/opposite method when the prior method failed.
-Use Fast for pure Q&A, fact lookup, verification, or an already approved trivial code change (one line, no logic change, no risk).
-Use Design-lite only after Brainstorm confirms a small unapproved change to an existing feature with clear behavior, one plausible path, low risk, local impact, and quick proof. Not for new requirements.
+Use Fast for pure Q&A, fact lookup, verification, or an already approved trivial code change (one line, no logic change, no risk). Unapproved edits are not Fast and must not skip Cut.
+Use Design-lite when the risk gate skips Brainstorm for a small unapproved change to an existing feature with all low-risk conditions holding. Design-lite states goal, acceptance, and exclusions, records Depth C, and selects Cut then Build. It does not wait for Brainstorm. Not for new requirements.
 If the boundary is unclear after Brainstorm, have Core select the smallest compatible route instead of guessing.
 Run Sense first by reading or citing relevant project facts.
 At Sense, probe `.copilot/LEARNING_INDEX.md` and `docs/project-knowledge/` when present. Read only matched learning cards or navigation-selected knowledge documents; missing locations are non-blocking and do not create storage.
-The direct success map is A: Brainstorm -> Spec -> Cut -> Plan -> Build -> Prove, B: Brainstorm -> Cut -> Plan -> Build -> Prove, C: Brainstorm -> Cut -> Build -> Prove. An approved A Spec directly starts Cut; A/B `CUT_PASS` directly starts Plan; C `CUT_PASS` directly starts Build; an approved A/B Plan directly starts Build; a completed Build directly starts Prove.
+The direct success map is Skip-Brainstorm Design-lite: Cut -> Build -> Prove, A: Brainstorm -> Spec -> Cut -> Plan -> Build -> Prove, B: Brainstorm -> Cut -> Plan -> Build -> Prove, C: Brainstorm -> Cut -> Build -> Prove. An approved A Spec directly starts Cut; A/B `CUT_PASS` directly starts Plan; C `CUT_PASS` and a skip-path `CUT_PASS` directly start Build; an approved A/B Plan directly starts Build; a completed Build directly starts Prove.
 Before implementation, run Cut with Required Gates: Reuse, Native, Overbuild, Diff, and Scope checks. Core keeps non-unique selection: `CUT_REDUCE`/`CUT_REUSE` STOP for user confirmation, then return facts to Core; `CUT_BLOCKED`, Plan scope drift, `BUILD_BLOCKED`, Proof `FAIL`/`BLOCKED`, changed intent, and PUA recovery return facts so Core chooses the next owner.
 For bug fixes, include Root-Cause Check: searched callers/references; shared vs narrow fix; reason.
 For deliberate simplifications, add or report `devflow: <ceiling>, revisit when <trigger>`.

package/assets/presets/devflow-2/tool-bootstrap.mjs

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

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

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 only the current task's execution spec — `Files`, `Change mechanics`, `Steps`, `Verify` — and must reread the current task's named anchors. A current task anchor plus a directly changed neighbor may be reread only when that neighbor is already listed in the task `Files` and its contract could invalidate the edit. An actual edit, anchor mismatch, or verification failure must stop and return `BUILD_BLOCKED` with facts to `devflow-core`: observed mismatch, affected anchor, and smallest replan decision. Do not broadly rediscover, guess, silently repair the plan, or expand scope.
 
 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.
 
@@ -46,7 +46,7 @@ When saving a plan file, use `docs/plans/YYYY-MM-DD-<short-kebab-name>.md`, reso
 
 For multi-step work, tasks must cite the approved source, be small and verifiable, and follow the required task contract (Task: / Task type: / Files: / Interfaces: / Current behavior: / Target behavior: / Change mechanics: / Call impact: / Steps: / Acceptance: / Verify: / Comments: / Not doing:) defined in `skills/devflow-plan/SKILL.md`.
 
-No unresolved markers. For `Code change`, 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. 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; bounded current-anchor/neighbor reread is allowed only for drift detection. The verification step must retain its trigger/input, expected result, and command or manual scenario. `Documentation-only` applies only to tasks with no runtime code files and explicit `documentation-only` interfaces. No "add tests" without naming the behavior. No "handle edge cases" without naming the edge case. No "similar to Task N" shortcuts; repeat enough detail for each task to stand alone.
 
 Before Build, run `node scripts/devflow-plan.js <plan-file>` when a plan is saved to a file. If not found at `scripts/devflow-plan.js` (project-level), try `~/.codex/scripts/devflow-plan.js` or `~/.claude/scripts/devflow-plan.js` (user-level). Do NOT look under `skills/scripts/`. See `core-methods.md` Script Path Resolution.
 

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,8 @@ 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
 Next skill: <skill name or none>
 Status: [DevFlow: <node> -> <next> | awaiting approval / in progress]
 ```
@@ -45,11 +47,16 @@ 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. |
@@ -57,6 +64,7 @@ Unknowns: <none or specific unknown>
 ## 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 +87,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

@@ -65,9 +65,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 +96,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.
 

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

@@ -18,7 +18,7 @@ Turn an A/B `CUT_PASS`-bounded approved design or confirmed Spec into one review
 1. Read only source material, code, tests, and conventions relevant to the approved scope. Load `skills/devflow-spec/references/spec-plan-methods.md` and `skills/devflow-plan/references/plan-methods.md` before applying Plan Pack mechanics.
 2. Map exact affected file responsibilities once in `## File Structure` before writing tasks. Reuse existing modules and name the intended file operation.
 3. Perform bounded real investigation and record it as task-level `Prewalk`: actual `Execution Trace`, Current Handoff Facts, and only the unfinished `Remaining Structured Worklist`.
-4. Split independent deliverables into small, reviewable tasks. Each task should be understandable without referring to another task, and it carries its own complete execution spec（执行规范）— `Files`, `Change mechanics`, `Steps`, and `Verify` — so the executor edits directly from the task without re-reading the plan or the code for a pre-edit view（零 view）.
+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.
 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.
@@ -56,7 +56,7 @@ Inherit `External Skills` from the Cut Decision unchanged; the Plan Pack carries
 
 `Execution mode` is not part of Cut scope and does not change the checker. It is asked at approval and recorded so Build knows how to run tasks: sequentially as the Build agent itself, through one delegated subagent while the main agent only schedules, or fan out independent tasks to parallel subagents.
 
-Each task's `Files`, `Change mechanics`, `Steps`, and `Verify` form the only execution basis（执行规范）handed to the executor: dispatch sends just these fields, and the executor edits directly from them without a pre-edit view of the plan document, the code, or the anchors. `Read-basis` / `Live anchors` remain the plan author's evidence record, not executor re-read instructions.
+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.
 
 ## Required Task Contract
 
@@ -106,7 +106,7 @@ Remaining Structured Worklist:
   Done when: <fact proving this action is complete>.
 ```
 
-`File Structure` is one responsibility map, not a fixed architecture rule. For every non-trivial Code change, every task must carry a `Prewalk`. Each trace row records an action actually performed and its observed result; it cannot describe planned work. `Remaining Structured Worklist` contains only unfinished actions. Each item needs `Anchors`, `Verify`, and `Done when`; cap one task at 12 items. The executor reads the current task's execution spec (`Files`, `Change mechanics`, `Steps`, `Verify`), edits directly, runs `Verify`, appends actual evidence, and returns the observed difference as facts to `devflow-core` only when an edit or verification actually fails — there is no pre-edit plan or code view. Documentation-only tasks retain their existing exception.
+`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. 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.
 
@@ -138,7 +138,7 @@ Before leaving this skill, confirm:
 - [ ] `Spec coverage` maps the source to plan tasks.
 - [ ] Header, constraints, File Structure, interfaces, concrete steps, acceptance, verification, context-specific comments, exclusions, and task-level Prewalk records are present.
 - [ ] Each trace entry is an observed past action/result; each remaining worklist item is bounded, verified, and fact-complete.
-- [ ] Every task is independently understandable, requires no pre-edit read, and has no unresolved or vague placeholder.
+- [ ] Every task is independently understandable, requires named-anchor rereads and at most one already-listed neighbor, and has no unresolved or vague placeholder.
 - [ ] The checker passed when available.
 - [ ] The user reviewed the written plan.
 - [ ] An approved A/B Plan entered `devflow-build`; any scope-drift facts returned to `devflow-core`.

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

@@ -61,14 +61,14 @@ Remaining Structured Worklist:
 
 ## Delegated Execution
 
-A delegated executor — the main agent itself, one delegated subagent, or one fan-out subagent — never re-reads the plan document, the latest trace, the anchors, the goal, or the code for a pre-edit view. It receives only the current task's execution spec (`Files`, exact replacement rules, `Steps`, `Verify`), edits those files directly, runs the task's `Verify` command, and returns actual evidence or failure facts to the orchestrating Build agent. `Read-basis` and `Live anchors` stay in the plan as the plan author's evidence record (the checker requires them); they are not executor re-read instructions.
+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.
 
-When an edit cannot be applied or a `Verify` fails, the executor returns the observed difference — affected file/anchor, actual behavior, blocked verification, and smallest replan decision — as facts to `devflow-core`; it does not pre-check anchors and does not guess past a failed edit. A stale line reference may be corrected without returning only when the symbol, contract, responsibility, and intended outcome are unchanged.
+When an edit cannot be applied 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.
 
 ### Fan-out
 
-When the plan's `Execution mode` is `fan-out`, one Build orchestrator partitions tasks into parallel groups and dispatches each task to a subagent. Every subagent receives only its own task's execution spec, edits its task's `Files` directly, runs its task's `Verify`, and returns evidence or failure facts; it does not re-read the plan, the trace, the anchors, or the code. Two tasks may run in parallel only when their `Files` touch disjoint file/symbol sets and neither `Interfaces` consumes a symbol the other `Produces`; tasks sharing a file/symbol or with a consume/produce dependency run in sequence. The orchestrator merges returned results, reconciles cross-task overlap, and enters Prove once with merged evidence.
+When the plan's `Execution mode` is `fan-out`, one Build orchestrator partitions tasks into parallel groups and dispatches each task to a subagent. Every subagent receives only its own task's 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.
 
 ### Single-subagent
 
-When the plan's `Execution mode` is `single-subagent`, the main agent only schedules: it dispatches one task's execution spec at a time to one executor subagent, waits for the return, then merges the returned evidence and enters Prove once. The main agent dispatches one task at a time — only that task's execution spec, not the whole plan. The subagent edits that task's `Files` directly, runs its `Verify`, appends actual evidence, and returns the task results and evidence or `BUILD_BLOCKED` facts; the next task continues the same subagent conversation through `send_message`. On DeepSeek Harness (DSH), subagent turns are time-bounded, so one task per round is the norm; a timeout or truncated return retries that one task once with a narrower instruction. The subagent never re-reads the plan, the trace, the anchors, or the code for a pre-edit view. Nothing runs in parallel; prefer this mode for small to medium plans or plans whose tasks are strongly dependent, and keep `fan-out` for large parallel plans.
+When the plan's `Execution mode` is `single-subagent`, the main agent only schedules: it dispatches one task's 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.

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

@@ -11,17 +11,20 @@ No proof, no completion.
 
 ## Methodology Assets
 
-When this skill activates, read these local references before choosing or running proof scenarios:
+Context loading is conditional and selected by changed surface.
 
-- `skills/devflow-prove/references/flow-self-test.md` — end-to-end scenario tests and pressure scenarios for the framework itself.
-- `skills/devflow-prove/references/code-review-checklist.md` — language-specific code quality criteria for adversarial code review.
+When this skill activates, read only the references required by the changed surface:
+
+- Always read `skills/devflow-prove/references/proof-recovery-methods.md` — shared proof and recovery method.
+- Read `skills/devflow-prove/references/flow-self-test.md` only when the change touches DevFlow runtime rules, skills, commands, host adapters, hooks, validators, scenarios, installers, or harness behavior.
+- For code, read `skills/devflow-prove/references/code-review-checklist.md` and apply only the matching language section: `.js/.jsx/.ts/.tsx` -> TypeScript / JavaScript plus React/Vue when present; `.py` -> Python; `.go` -> Go; `.java` -> Java; `.cs` -> C# / .NET; `.sql` -> SQL. Always apply General Engineering Review. Unlisted extensions use General Engineering Review and record the missing language checklist.
 
 ## Process
 
 Load `skills/devflow-prove/references/proof-recovery-methods.md` before selecting proof. It owns the shared proof and recovery method details used by Prove and PUA.
 
 1. Identify the command, test, build, lint, diff check, validation script, or manual scenario that proves the claim.
-2. Confirm the exact changed files, approved File Structure/Plan boundary, latest Prewalk Execution Trace and Current Handoff Facts. Read the task's remaining-work completion evidence plus the nearest comparable code.
+2. Confirm the exact changed files, approved File Structure/Plan boundary, latest Prewalk Execution Trace and Current Handoff Facts. Read task-local completion evidence plus only the nearest directly relevant code or contract.
 3. Run the narrowest sufficient check now, then independently inspect the actual implementation diff before interpreting test results.
 4. Run adversarial review (对抗式审查) against the approved responsibility boundary, Prewalk facts, direct contracts, nearby convention, and likely regressions.
 5. For code changes: run the **Code Quality Review** (General Engineering Review + Language-Specific Checklist from `code-review-checklist.md`), then generate a **Code Review Report** (see format below). Classify each evidence-backed finding as Blocker, Warning, or Recommendation. An unresolved Blocker or Warning returns `FAIL` facts to Core; recommendations do not block an otherwise proven result.

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

@@ -2,7 +2,7 @@
 
 Use these scenarios to verify the framework from request to landing. A scenario passes only when the expected skill behavior, output contract, and proof are visible.
 
-## Scenario 1: Vague Feature Request
+## Scenario 1: Vague Or Material-Risk Feature Request
 
 Input:
 
@@ -14,6 +14,7 @@ Expected behavior:
 
 - Route: Design.
 - Skill path: `devflow-core -> devflow-brainstorm -> Confirmed request -> user-selected A/B/C direct branch`.
+- Core must classify the request as ambiguous/material-risk before entering Brainstorm and pass a suitable depth hint.
 - Brainstorm must read current project context before clarifying.
 - Brainstorm must send a Semantic Echo-Back, apply the Understanding Revision Rule when a correction changes the request, then ask or infer only goal, scope, exclusions, constraints, acceptance, and open questions.
 - Brainstorm must output the fixed `Confirmed request` summary with `Status: clarified`, present A/B/C, and wait for explicit user selection.
@@ -190,7 +191,7 @@ Expected behavior:
 - Route: Fast verification
 - Skill path: `devflow-core -> devflow-prove`
 - Must check `AGENTS.md`, `CLAUDE.md`, Copilot instructions, VS Code instruction/prompt, CodeBuddy rule, plugin metadata, and Gemini metadata.
-- Must confirm platform adapters preserve `Sense -> Brainstorm clarification -> user-selected A/B/C -> direct success edges -> devflow-prove`, with Core routing non-unique exceptions.
+- Must confirm platform adapters preserve the risk gate: skip-Brainstorm Design-lite is Cut -> Build -> Prove; ambiguous or material-risk work is Sense -> Brainstorm clarification -> user-selected A/B/C -> direct success edges -> devflow-prove, with Core routing non-unique exceptions. Unapproved edits never use Fast.
 - Must confirm plugin metadata includes all shipped skills and commands.
 - Must not rewrite adapter rules unless drift is proven.
 
@@ -281,8 +282,10 @@ In README, rename "Proof Gate" to "Proof Before Done".
 
 Expected behavior:
 
-- Route: Build because implementation is requested and scope is clear.
-- Still run a lightweight Sense and Cut.
+- Route: Design-lite because implementation is requested and the low-risk gate passes.
+- This is a clear low-risk existing behavior change; Core records `Brainstorm required: no` and `Depth hint: skip`, then select `devflow-cut` directly with a Design-lite contract and Depth C.
+- Core may bypass Brainstorm only after the low-risk gate passes.
+- `CUT_PASS` enters Build, then Prove. Cut and Prove remain mandatory. Unapproved edits never use Fast.
 - Touch only the requested file.
 - Verify with text search.
 

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

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

package/package.json

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