@devflow-core/dsh-devflow 0.1.0

package/NOTICE

@@ -0,0 +1,13 @@
+@devflow-core/dsh-devflow
+
+本插件借鉴了以下开源项目的实现（Apache-2.0 / MIT），特此声明：
+
+- lib/dsh-home.js、lib/mount-once.js、lib/sync.js、lib/index.js 的同步/挂载/
+  单实例守卫逻辑改编自 @linxin666/dsh-liangshen
+  （https://github.com/zhu1090093659/dsh-web-ui ，Apache-2.0）。
+- assets/presets/devflow-2/tool-bootstrap.mjs 来自
+  https://github.com/xiaobright/dsh-anchored-standard（MIT），
+  经 dsh-liangshen 扩展后适配 devflow-2（phase1Persona 人设切换）。
+- assets/presets/devflow-2/custom-bash.mjs 与 NOTICE 同源于上述仓库。
+
+原始版权与 MIT/Apache-2.0 许可声明见各开源仓库。

package/README.md

@@ -0,0 +1,82 @@
+# @devflow-core/dsh-devflow — DevFlow 插件（DSH）
+
+把 DevFlow 完整工作流打包成 DeepSeek Harness 插件：devflow-2 agent preset、
+全套 `devflow-*` skills、斜杠命令与验证脚本，一条命令安装，随插件启动自动同步。
+
+## 安装
+
+```sh
+npx @deepseek-ai/dsh plugin --profile web add @devflow-core/dsh-devflow
+```
+
+装完**必须重启 web**（Ctrl+C → 重新 `npx @deepseek-ai/dsh web`）才生效。
+
+重启后：
+
+1. 新建会话，预设选择器可选 **DevFlow 2.0 (Anchored)**（两阶段锚定 + Code Mode）。
+2. 会话内 `devflow-*` skills 出现在技能目录，按任务措辞自动触发。
+3. `~/.dsh/commands/` 出现 `devflow*.toml` 斜杠命令，`~/.dsh/scripts/` 出现
+   `devflow-*.js` 验证脚本（`node scripts/devflow-plan.js <plan>` 等）。
+
+## 同步内容
+
+插件启动时把包内 `assets/` 四类资产同步到用户 `~/.dsh/`：
+
+| 资产 | 源（包内） | 目标（用户） |
+|---|---|---|
+| agent preset | `assets/presets/devflow-2/`（5 文件） | `~/.dsh/.agent-presets/devflow-2/` |
+| skills | `assets/skills/devflow-*/`（14 个，含 references/） | `~/.dsh/skills/` |
+| 斜杠命令 | `assets/commands/devflow*.toml`（11 个） | `~/.dsh/commands/` |
+| 验证脚本 | `assets/scripts/devflow-*.js`（6 个 checker） | `~/.dsh/scripts/` |
+
+## 冲突策略
+
+- **devflow-\* 权威覆盖**：目标文件与包内源文件字节相同 → 跳过；不同 → 覆盖。
+- 源不再包含的 devflow-\* 残留（升级后旧文件）→ 删除（prune）。
+- **非 devflow 资产永不触碰**：用户自装的 skill（如 `atlassian`、`rtk`）、
+  自定义命令/脚本一律保留，不删除不覆盖。
+- **preset 目录完全由插件管理**：`~/.dsh/.agent-presets/devflow-2/` 整目录归
+  插件所有，目录内非包内文件（含手动备份如 `agent.cordis.yml.bak-*`）会在
+  下次同步时被清理。请勿在该目录存放自定义文件；如需自定义 preset，把
+  目录复制成新预设 id 或改源码重新打包。
+
+## 升级更新
+
+DevFlow-Core 仓库发布新版本后，维护者流程：
+
+```sh
+node dsh/plugins/dsh-devflow/scripts/sync-assets.js   # 刷新子包资产（防漂移）
+# bump dsh/plugins/dsh-devflow/package.json 版本号
+npm publish                                            # 在 dsh/plugins/dsh-devflow 目录
+```
+
+已安装用户升级：
+
+```sh
+npx @deepseek-ai/dsh plugin --profile web update @devflow-core/dsh-devflow
+# 或 remove + add，然后重启 web
+```
+
+重启后插件自动把新资产同步到 `~/.dsh/`（字节相同跳过，升级残留 prune）。
+
+## 与 install:user 的关系
+
+`npm run install:user -- --home ~/.dsh`（根仓库）仍是手动路径：把同一批
+preset/skills/commands/scripts 复制到 `~/.dsh/`。本插件把同一件事变成一条
+命令并随插件版本自动维护，二者并存不冲突——本插件同步时按上述冲突策略
+处理已有文件。
+
+## Windows 提示
+
+devflow-2 预设的 `custom-bash.mjs` 需要 Git Bash 可解析：默认自动推断 Git
+安装位置；若 `git` 不在 PATH，在 `~/.dsh/.agent-presets/devflow-2/agent.cordis.yml`
+的 custom-bash 行显式配置 `bashPath` 指向本机 Git（参照
+`docs/dsh-plugins-guide.md` 7.1 节）。
+
+## 发布
+
+```sh
+cd dsh/plugins/dsh-devflow
+node scripts/sync-assets.js   # 发布前必须重跑，保证资产与仓库根一致
+npm publish
+```

package/assets/commands/devflow-adversarial.toml

@@ -0,0 +1,11 @@
+description = "Run an independent manual adversarial review of current work."
+prompt = '''
+Run DevFlow Adversarial Review.
+
+Load `skills/devflow-adversarial/SKILL.md` and begin the review when the user explicitly requests it.
+Identify the review target from the request and available task materials. Ask one smallest question only when the target is unclear.
+This command is manual and independent: it does not require, read, modify, or hand off to devflow-prove, PUA, Build, Learn, or any completion state.
+Cover requirement coverage, reachability, boundaries and regressions, evidence strength, and user-visible outcome.
+Report only the skill's required findings, five-angle coverage, context limitations, and suggested manual next action.
+Do not edit files, invoke another skill, create a task, or declare global task status.
+'''

package/assets/commands/devflow-audit.toml

@@ -0,0 +1,32 @@
+description = "Audit a repository or scope for overengineering and code that can be deleted."
+prompt = '''
+Audit the repository or named scope for overengineering only.
+
+When `scripts/devflow-audit.js` exists, run:
+
+```bash
+node scripts/devflow-audit.js <target-directory>
+```
+
+If only user-level DevFlow is installed, run the user script instead:
+
+```bash
+node ~/.codex/scripts/devflow-audit.js <target-directory>
+# or, for Claude Code user-level install:
+node ~/.claude/scripts/devflow-audit.js <target-directory>
+```
+
+Use the script output as a first-pass candidate scan, then read referenced code before reporting important findings.
+
+Scope: overengineering and complexity only. Do not report correctness, security, performance, or style issues as audit findings.
+
+Findings use:
+<file>:L<line>: <delete|reuse|stdlib|native|yagni|shrink>: <what to cut>. <replacement>.
+
+Rank biggest useful cut first.
+End with:
+net: -<N> lines, -<M> deps possible.
+
+If nothing should be cut:
+Lean already. Ship.
+'''

package/assets/commands/devflow-debt.toml

@@ -0,0 +1,42 @@
+description = "Harvest devflow: simplification markers into a debt ledger report."
+prompt = '''
+Harvest every `devflow:` intentional-simplification marker in this repository.
+
+When `scripts/devflow-debt.js` exists, run:
+
+```bash
+node scripts/devflow-debt.js .
+```
+
+If only user-level DevFlow is installed, run the user script instead:
+
+```bash
+node ~/.codex/scripts/devflow-debt.js .
+# or, for Claude Code user-level install:
+node ~/.claude/scripts/devflow-debt.js .
+```
+
+Use the script output as the debt ledger report.
+
+Search the tree for comment or prose markers such as:
+- `// devflow:`
+- `# devflow:`
+- `<!-- devflow:`
+- `devflow:`
+
+Skip generated output, build folders, dependency folders, and VCS metadata.
+
+For each marker, report:
+<file>:<line> - <what was simplified>. ceiling: <ceiling>. revisit: <trigger>.
+
+Rules:
+- A valid marker names both the ceiling and the revisit trigger.
+- Tag missing trigger/ceiling as `no-trigger`.
+- Do not change files unless the user explicitly asks to persist the ledger.
+
+End with:
+<N> markers, <M> no-trigger.
+
+If none exist, say:
+No devflow debt markers found.
+'''

package/assets/commands/devflow-find-fault.toml

@@ -0,0 +1,11 @@
+description = "Run an independent manual find-fault review of current work."
+prompt = '''
+Run DevFlow Find Fault.
+
+Load `skills/devflow-find-fault/SKILL.md` and review the user-specified current task materials.
+This command is manual and independent: it does not require, read, modify, or hand off to devflow-prove, PUA, Build, Learn, or any completion state.
+Answer the biggest omission, unrecognized blind spot, and least certain point, plus every explicit user question.
+When reviewing implemented work, also run a post-implementation unease check: find business decisions encoded by the implementation but not explicitly confirmed, classify their risk, and state the confirmation needed.
+Separate facts, inference, and unknowns; give every answer confidence and a next step, then report finding levels, unease decisions, limitations, and suggested manual action.
+Do not edit files, invoke another skill, create a task, or declare global task status.
+'''

package/assets/commands/devflow-learn.toml

@@ -0,0 +1,21 @@
+description = "Capture or verify a reusable correction, pitfall, or project convention with DevFlow Learn."
+prompt = '''
+Run DevFlow Learn.
+
+Use this when the user says wrong, not like that, changed wrong, remember, learn, next time don't, wrong place, misplaced content, repeated correction, repeated user challenge, skipped validation, repeated failure, or project convention.
+
+Process:
+1. Detect the learning signal and decide whether it is reusable.
+2. Probe `.copilot/LEARNING_INDEX.md`; when present, match the task against Trigger and Scope, then read only matched cards. Do not load all cards.
+3. If a reusable execution lesson qualifies, lazily create or update one focused card and `.copilot/LEARNING_INDEX.md`; do not create empty learning storage after a no-record review.
+4. If code-backed business semantics changed, report a project-knowledge candidate and wait for user confirmation before loading `devflow-project-knowledge` to lazily maintain `docs/project-knowledge/`.
+5. Update `.copilot/LEARNING_INDEX.md` when a card is created, renamed, or its trigger changes.
+6. Report the learning closure before claiming completion.
+
+Learning closure:
+- Learning signal: none / present
+- Recalled record: none / index / card
+- Knowledge recall: none / learning index + matched card / project-knowledge candidate
+- Added memory: none / learning card / rule / skill
+- Next intercept: Next time encountering <X>, first do <Y>, not <Z>.
+'''

package/assets/commands/devflow-plan.toml

@@ -0,0 +1,58 @@
+description = "Create a reviewed, executable implementation plan from an approved DevFlow spec or design."
+prompt = '''
+Load `skills/devflow-plan/SKILL.md` after an A/B direct `CUT_PASS`, or when `devflow-core` selects planning for a non-unique artifact. Create the single DevFlow Plan Pack from A/B `CUT_PASS` plus its approved design or confirmed spec.
+
+`CUT_PASS` must state the allowed scope, reuse conclusion, exclusions, and verification constraints. Do not create a construction plan before Cut returns `CUT_PASS`.
+
+Save plans by default at:
+
+```text
+docs/plans/YYYY-MM-DD-<short-kebab-name>.md
+```
+
+Keep the plan header in English:
+
+```text
+Goal: <outcome>
+Architecture: <smallest design and boundaries>
+Tech Stack: <relevant existing stack>
+Source: <docs/specs/YYYY-MM-DD-<short-kebab-name>.md or approved design>
+Spec coverage: <requirements mapped to tasks, or design-only>
+Cut Decision: <CUT_PASS allowed scope, reuse conclusion, exclusions, verification constraints>
+External Skills: <skill-name>; role: <bounded specialist work>; expected evidence: <result needed by that node>; return facts: <result / not-applicable / failure> / none
+Execution mode: sequential | single-subagent | fan-out (optional; ask and record at approval)
+```
+
+Inherit `External Skills` from the Cut Decision unchanged; the Plan Pack carries the specialist role, expected evidence, and return facts into Build and Prove. When a specialist skill is declared, merge its core quality checks into the affected tasks' `Acceptance`/`Verify` fields; the Plan Pack is the only channel that carries external-skill quality requirements into Build and Prove.
+
+Each independently understandable task must contain:
+
+```text
+Task: <short title>
+Task type: Code change | Documentation-only
+Files:
+- Create: <path> | new file | <responsibility>
+- Modify: <path> | <symbol or stable anchor> | <responsibility>
+- Test: <path> | <test symbol or stable anchor> | <behavior proved>  # only when applicable
+Interfaces:
+- Consumes: <exact symbol/API input and type/shape, or documentation-only exception>
+- Produces: <exact symbol/API output and type/shape, or documentation-only exception>
+Current behavior: <observable current state>  # Code change only
+Target behavior: <observable outcome>  # Code change only
+Change mechanics: <minimal code snippet, pseudocode, or exact replacement rule>  # Code change only
+Call impact: <known callers/downstream effect, or no runtime impact>  # Code change only
+Steps:
+- [ ] <one file + symbol/anchor + executable action; include code snippet, pseudocode, or exact replacement for code logic>
+- [ ] <one verification action with trigger/input, expected result, and command or manual scenario>
+Acceptance: <specific condition>
+Verify: <exact command or manual scenario, trigger/input, and expected result>
+Comments: <required code comments or "none — trivial change">
+Not doing: <scope removed>
+```
+
+For `Code change`, every existing-file row must name a symbol or stable anchor; every `Create` row uses `new file`. Require `Current behavior`, `Target behavior`, `Change mechanics`, and `Call impact`. `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 trigger/input, expected result, and runnable command or manual scenario. `Documentation-only` is allowed only when no runtime code changes; both interface entries must explicitly say `documentation-only` and it cannot be used for a code-file task.
+
+Run `node scripts/devflow-plan.js <plan-file>` when it exists; otherwise use the user-level fallback specified in `core-methods.md`. Self-review source coverage, interfaces, precise locations, behavior changes, mechanics, call impact, verification expectations, placeholders, and file-operation labels before presenting the plan.
+
+STOP after writing and validating the plan: request user review. On approval, ask execution mode (`sequential` — the Build agent runs tasks in dependency order / `single-subagent` — the main agent only schedules while one subagent runs all tasks / `fan-out` — independent tasks run as parallel subagents) and record it as the plan's optional `Execution mode` header, then perform a lightweight Cut-consistency review. An approved A/B Plan directly starts `devflow-build`; any scope-drift or non-success facts return to `devflow-core`. Do not perform Cut, Build, Prove, test-first workflow, version-control task steps, independent review, or automatic execution here.
+'''

package/assets/commands/devflow-prove.toml

@@ -0,0 +1,20 @@
+description = "Verify a DevFlow change before claiming completion."
+prompt = '''
+Run DevFlow Prove.
+
+Identify the narrowest sufficient command, test, build, lint, validation script, or manual scenario.
+Run it now if tools are available.
+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.
+Report only:
+
+Command: <actual command run>
+Result: <key output summary>
+Adversarial review: <strongest challenge and disposition, or not applicable for non-development verification>
+Judgment: PASS / FAIL / BLOCKED
+
+If the check is partial, include coverage and explicit gaps.
+If it fails, route back to Recovery: re-read facts, list 3 hypotheses, try a materially different approach.
+If the failure includes user challenge, changed-wrong result, repeated miss, or quality complaint, load `devflow-pua` before more edits.
+'''

package/assets/commands/devflow-pua.toml

@@ -0,0 +1,40 @@
+description = "Run DevFlow PUA pressure recovery when a result is wrong, challenged, or repeatedly misses the user's target."
+prompt = '''
+Run DevFlow PUA.
+
+Use this when the user repeatedly points out that the same function, result, or requested capability has a problem in one task lifecycle, repeatedly identifies missing coverage for that same target, or explicitly invokes `/devflow-pua`.
+
+Stop the current approach before more edits. Re-read the request, correction, relevant files, and proof output.
+
+Read `skills/devflow-pua/references/methodology-router.md`, `skills/devflow-pua/references/methodology-library.md`, and `skills/devflow-pua/references/flavor-display.md` before selecting the recovery method. Do not link out to the original PUA project at runtime; use these local methodology files.
+
+For repeated reports that the same function, result, or requested capability remains wrong, incomplete, or missing, record `Restart Brainstorm: re-confirmation required; Core selects whether to invoke it`, quarantine the previous wrong assumption/path/proof claim, keep only verified facts, diagnose why the user thinks that target is still wrong, and return recovery facts to `devflow-core` before more edits.
+
+This command is not permission to continue the old patch. First classify the user-view miss, display the active flavor/method as `METHOD: {flavor} / {method}`, then switch to a different/opposite method if the prior method failed.
+
+Output:
+Pressure check:
+Restart Brainstorm:
+Discarded context:
+Keep only verified facts:
+METHOD: {flavor} / {method}
+SWITCH:
+User-view miss:
+Satisfaction gap:
+User goal restated:
+Desired result:
+Blocking questions:
+Hypotheses: 1 / 2 / 3
+Blue-team attack:
+New success contract:
+Changed approach:
+Verification:
+Learning closure:
+
+Ask 2-4 pointed questions only when the desired result cannot be inferred from facts. If the result is inferable, state the evidence and return the recovery facts to `devflow-core`. `devflow-core` may select `devflow-brainstorm` only to re-confirm the request; Brainstorm then returns the clarified request to `devflow-core`. Core alone selects the needed lifecycle skill.
+
+Completion still requires:
+Command:
+Result:
+Judgment: PASS / FAIL / BLOCKED
+'''

package/assets/commands/devflow-review.toml

@@ -0,0 +1,36 @@
+description = "Review a plan or diff for overengineering, reuse misses, and scope drift."
+prompt = '''
+Review the provided plan or diff through DevFlow Cut.
+
+When `scripts/devflow-review.js` exists and the plan or diff is in a file, run:
+
+```bash
+node scripts/devflow-review.js <plan-or-diff-file>
+```
+
+If only user-level DevFlow is installed, run the user script instead:
+
+```bash
+node ~/.codex/scripts/devflow-review.js <plan-or-diff-file>
+# or, for Claude Code user-level install:
+node ~/.claude/scripts/devflow-review.js <plan-or-diff-file>
+```
+
+Use the script output as the gate presence report before writing detailed findings.
+
+Check:
+- Reuse Check: existing helpers, patterns, standard library, native platform, installed dependencies
+- Ponytail Rung: smallest rung that should solve the goal
+- Root-Cause Check: for bug fixes, search callers/references and prefer a shared fix when it is the smaller correct fix
+- Native Check: platform or standard-library alternative
+- Overbuild Check: unnecessary dependency, abstraction, config, directory, framework layer, generic engine
+- Diff Check: each changed file maps to the user goal
+- Scope Check: unrequested features or opportunistic refactors
+- Debt Marker Check: intentional `devflow:` shortcuts include both a ceiling and a revisit trigger
+
+For findings, use:
+<file>:L<line>: <delete|reuse|stdlib|native|yagni|shrink>: <what to cut>. <replacement>.
+
+If nothing should be cut, say:
+Lean already. Ship.
+'''

package/assets/commands/devflow-spec.toml

@@ -0,0 +1,49 @@
+description = "Create and validate a DevFlow spec document before implementation planning."
+prompt = '''
+Create a DevFlow spec from the `Confirmed request` that `devflow-core` selected for Spec work.
+
+Compare real no-change/reuse, direct implementation, and relevant existing-pattern options before writing the chosen design contract. Record their trade-offs in `Approach`; do not re-confirm request fields and do not select any later lifecycle skill.
+
+Default landing for saved specs is:
+
+```text
+docs/specs/YYYY-MM-DD-<short-kebab-name>.md
+```
+
+Resolve the default path from the current target project's root. Use an existing project specs directory only when the target project already documents that convention. Do not put implementation specs in `docs/features/`; that directory is for feature ledgers. Do not put specs in `docs/plans/`; that directory is for implementation plans.
+
+When `scripts/devflow-spec.js` exists and the spec is in a file, run:
+
+```bash
+node scripts/devflow-spec.js <spec-file>
+```
+
+If only user-level DevFlow is installed, run the user script instead:
+
+```bash
+node ~/.codex/scripts/devflow-spec.js <spec-file>
+# or, for Claude Code user-level install:
+node ~/.claude/scripts/devflow-spec.js <spec-file>
+```
+
+Use the script output as the required-section, unresolved-marker, and spec-landing check.
+
+Required sections (headers must remain in English for checker validation; content can be in the user's language):
+Goal:
+Context:
+Requirements:
+Non-goals:
+Approach:
+Impact:
+Acceptance:
+Verification:
+Code Documentation:
+Open Questions:
+
+When Cut returns `CUT_PASS`, any resulting plan cites:
+Source: <confirmed spec path or approved design>
+Spec coverage: <which requirements map to which tasks>
+Cut Decision: <allowed scope, reuse conclusion, exclusions, verification constraints>
+
+After the user reviews and approves an A-branch design contract/spec, directly start `devflow-cut` with the confirmed Spec and preserved Depth. Any rejection, missing depth, scope change, or other non-success result returns facts to `devflow-core`; do not select another lifecycle skill yourself.
+'''

package/assets/commands/devflow.toml

@@ -0,0 +1,35 @@
+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.
+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.
+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.
+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>`.
+If implementation is requested for an already approved scope, continue through Build and Prove.
+For problem solving, bug fixing, and architecture design, use First Principles Cut when the cause, constraint, invariant, abstraction, or smallest correct mechanism is unclear; reduce to facts, constraints, and invariants before selecting a solution.
+Before completion of development work, run adversarial review against acceptance criteria, touched files, likely regressions, activation paths, and proof coverage. A real gap means FAIL or continued work before completion.
+
+Design output:
+Goal:
+Smallest useful plan:
+Not doing:
+Impact:
+Verification:
+
+Completion proof:
+Command:
+Result:
+Adversarial review:
+Judgment: PASS / FAIL / BLOCKED
+'''

package/assets/presets/devflow-2/NOTICE

@@ -0,0 +1,4 @@
+agent.cordis.yml 改编自 DeepSeek Harness 内置 Minimal/Standard preset 与 dsh-liangshen（MIT）。
+tool-bootstrap.mjs 来自 https://github.com/xiaobright/dsh-anchored-standard（MIT），
+经 dsh-liangshen 扩展后适配 devflow-2（phase1Persona 人设切换）。
+原始 DeepSeek 版权和 MIT 许可声明见开源仓库。

package/assets/presets/devflow-2/README.md

@@ -0,0 +1,71 @@
+# DevFlow 2.0 (Anchored) — DeepSeek Harness Agent Preset
+
+A DSH agent preset that anchors the FIRST model request on the Minimal
+surface, then promotes into a full DevFlow session: Code Mode (PTC) on the
+wire, the complete DevFlow persona, and the DevFlow lifecycle guaranteed.
+
+## What it is
+
+- `agent.cordis.yml` — two-phase composition (adapted from the `liangshen`
+  preset). Phase 1 shows only the one-line Minimal persona
+  ("You are a helpful software engineer assistant."), persistent
+  `bash` + `str_replace_editor`, no runtime contexts, no injected pre-step
+  messages, and a 1024 output budget. The anchor gate (first minimal-like
+  reasoning block, 4-step fallback, or first-response release) then promotes
+  the session: the wire switches to Code Mode (a single `run_code` tool), the
+  full DevFlow persona is restored, and workspace instructions (AGENTS.md
+  digest) plus the skill catalog are deferred one step.
+- `tool-bootstrap.mjs` — the two-phase bootstrap plugin (from
+  `xiaobright/dsh-anchored-standard`, MIT, extended by `dsh-liangshen`),
+  with a `phase1Persona` swap so the DevFlow persona only appears after
+  promotion.
+- `preset.yml` — picker metadata (name: DevFlow 2.0 (Anchored)).
+
+Skills are NOT bundled: the preset's `skill-filesystem` row uses the default
+user root (`$DSH_HOME/skills`), which is exactly where `npm run install:user`
+ships the DevFlow skills. One install path, no second copy to drift.
+
+## Install
+
+```sh
+npm run install:user -- --home ~/.dsh --write --force
+npm run install:user -- --home ~/.dsh --check
+```
+
+This installs the preset to `~/.dsh/.agent-presets/devflow-2/` (alongside the
+skills). Manual copy works too (remember the bundled plugin):
+
+```sh
+mkdir -p ~/.dsh/.agent-presets/devflow-2
+cp dsh/agent-presets/devflow-2/agent.cordis.yml      ~/.dsh/.agent-presets/devflow-2/
+cp dsh/agent-presets/devflow-2/preset.yml            ~/.dsh/.agent-presets/devflow-2/
+cp dsh/agent-presets/devflow-2/tool-bootstrap.mjs    ~/.dsh/.agent-presets/devflow-2/
+cp dsh/agent-presets/devflow-2/custom-bash.mjs       ~/.dsh/.agent-presets/devflow-2/
+cp dsh/agent-presets/devflow-2/NOTICE                ~/.dsh/.agent-presets/devflow-2/
+```
+
+## Use
+
+Start a new session in the web UI and pick **DevFlow 2.0 (Anchored)** in the
+preset picker. The roster may need a refresh or restart to show a newly added
+preset. Existing sessions keep their old phase; the two-phase behavior applies
+to new sessions.
+
+## Caveats
+
+- `~/.dsh/.agent-presets/` is plugin-maintained: a DSH plugin upgrade may
+  regenerate it. Re-run `npm run install:user -- --home ~/.dsh --write --force`
+  (or re-copy) after upgrades.
+- Phase 1 uses the persistent (PTY-backed) Minimal `bash` shell. On Windows
+  builds where DSH's PTY backend is unavailable, phase-1 `bash` calls fail but
+  `str_replace_editor` still works, and the first-response release /
+  composition-drift guard keep the session usable (Code Mode `run_code` does
+  not need the PTY).
+
+## Customize
+
+Never edit the shipped `agent-presets` beside the deployment config (an
+upgrade overwrites it). This user-root copy is yours: edit `agent.cordis.yml`
+row by row, keeping the plane rule (a row publishing a service needs an
+`isolate` realm group) and the realm rule. Mount-validate with
+`standingKeyFor(id)` from a `cordis` (创造模式) session before shipping.