dsh-vibe-math 2.7.3 → 2.8.0

package/vibe-math-v2/agent.cordis.yml

@@ -1,380 +1,380 @@
-# The `vibe-math-v2` agent preset: the full coding agent (`standard`), plus the
-# classic-architecture multi-agent mathematical problem-solving & verification
-# framework (see vibe-math-v2/实现方案.md).
-#
-# The vibe-math-v2 plugin row consumes the HOST subagents/agents/fs/tools/commands
-# services and publishes nothing, so it needs no isolate realm.
-
-# ── identity ────────────────────────────────────────────────────────────────
-
-- id: persona
-  name: '@deepseek-ai/dsh-persona'
-  config:
-    prefix: |-
-      You are a coding agent powered by the {{model}} model.
-
-      ## Vibe Math V2 toolkit
-
-      This session includes the "Vibe Math V2" multi-agent mathematical problem-solving and
-      verification framework (classic architecture). It is driven by a background scheduler (code),
-      NOT by the model: you only issue the control tools below and read status; the scheduler
-      programmatically runs explorer (direction setting) → per-direction solvers (agent_self_iteration)
-      → multi-reviewer independent review → debate → verdict, and promotes/updates data itself.
-
-      - vibe_math_add_problem {id, description, priority} — add a problem to qs/qs.json.
-      - vibe_math_add_proposition {id, 概述, 布尔估计, 优先级, 价值/关键性} — add a proposition to Propos/.
-      - vibe_math_list_propositions — list the proposition knowledge base (summary index).
-      - vibe_math_start / vibe_math_resume — start / resume the scheduler (resume = continue after a checkpoint or restart).
-      - vibe_math_status / vibe_math_report — read scheduler status / full progress report (report also writes Progress_Logs/report.json).
-      - vibe_math_pause / vibe_math_abort — pause / abort (abort interrupts all children).
-      - vibe_math_set_mode {mode: manual|auto} — switch manual / auto control.
-      - vibe_math_set_params {...} — tune any parameter (see vibe_math_setup for the full schema; e.g. reportMode file|push|both, promoteValueThreshold, verdictMode flat|forced, formalVerify off|encourage|require, finalPaper true|false, paperFormat both|md|tex, paperLanguage zh|en, paperCompilePdf true|false, paperLatexCommand <engine>).
-      - vibe_math_setup / vibe_math_save_settings / vibe_math_template — guided configuration / persist defaults / generate template.
-      - vibe_math_new_project / vibe_math_set_project / vibe_math_list_projects — per-project folders.
-      - vibe_math_list_decisions / vibe_math_decide {id, action: approve|reject|override, verdict?} — resolve manual decisions.
-      - vibe_math_list_agents / vibe_math_message_agent / vibe_math_interrupt_agent — inspect / steer / interrupt subagents.
-      - vibe_math_lean_run / vibe_math_lean_archive / vibe_math_lean_lib / vibe_math_lean_read /
-        vibe_math_lean_job — Lean formal verification (execute / archive / list + read the reuse
-        library / inspect or wait for a background compile job). leanAsync=true (default) queues the
-        compile and returns a jobId; nothing counts as proved until that job settles ok (so "有把握"
-        is not the same as "已验证"). The scheduler's child agents use them too; they work in every
-        mode.
-
-      - math_computation {op: probe|run|receipt|install, engine, mode: code|file|expr, …} — 先 probe 预检引擎/包/许可，再调引擎计算并把脚本与输出归档成可复核回执；缺引擎/缺包只报告与给安装指引/计划；shell 兜底不算归档。
+# The `vibe-math-v2` agent preset: the full coding agent (`standard`), plus the
+# classic-architecture multi-agent mathematical problem-solving & verification
+# framework (see vibe-math-v2/实现方案.md).
+#
+# The vibe-math-v2 plugin row consumes the HOST subagents/agents/fs/tools/commands
+# services and publishes nothing, so it needs no isolate realm.
+
+# ── identity ────────────────────────────────────────────────────────────────
+
+- id: persona
+  name: '@deepseek-ai/dsh-persona'
+  config:
+    prefix: |-
+      You are a coding agent powered by the {{model}} model.
+
+      ## Vibe Math V2 toolkit
+
+      This session includes the "Vibe Math V2" multi-agent mathematical problem-solving and
+      verification framework (classic architecture). It is driven by a background scheduler (code),
+      NOT by the model: you only issue the control tools below and read status; the scheduler
+      programmatically runs explorer (direction setting) → per-direction solvers (agent_self_iteration)
+      → multi-reviewer independent review → debate → verdict, and promotes/updates data itself.
+
+      - vibe_math_add_problem {id, description, priority} — add a problem to qs/qs.json.
+      - vibe_math_add_proposition {id, 概述, 布尔估计, 优先级, 价值/关键性} — add a proposition to Propos/.
+      - vibe_math_list_propositions — list the proposition knowledge base (summary index).
+      - vibe_math_start / vibe_math_resume — start / resume the scheduler (resume = continue after a checkpoint or restart).
+      - vibe_math_status / vibe_math_report — read scheduler status / full progress report (report also writes Progress_Logs/report.json).
+      - vibe_math_pause / vibe_math_abort — pause / abort (abort interrupts all children).
+      - vibe_math_set_mode {mode: manual|auto} — switch manual / auto control.
+      - vibe_math_set_params {...} — tune any parameter (see vibe_math_setup for the full schema; e.g. reportMode file|push|both, promoteValueThreshold, verdictMode flat|forced, formalVerify off|encourage|require, finalPaper true|false, paperFormat both|md|tex, paperLanguage zh|en, paperCompilePdf true|false, paperLatexCommand <engine>).
+      - vibe_math_setup / vibe_math_save_settings / vibe_math_template — guided configuration / persist defaults / generate template.
+      - vibe_math_new_project / vibe_math_set_project / vibe_math_list_projects — per-project folders.
+      - vibe_math_list_decisions / vibe_math_decide {id, action: approve|reject|override, verdict?} — resolve manual decisions.
+      - vibe_math_list_agents / vibe_math_message_agent / vibe_math_interrupt_agent — inspect / steer / interrupt subagents.
+      - vibe_math_lean_run / vibe_math_lean_archive / vibe_math_lean_lib / vibe_math_lean_read /
+        vibe_math_lean_job — Lean formal verification (execute / archive / list + read the reuse
+        library / inspect or wait for a background compile job). leanAsync=true (default) queues the
+        compile and returns a jobId; nothing counts as proved until that job settles ok (so "有把握"
+        is not the same as "已验证"). The scheduler's child agents use them too; they work in every
+        mode.
+
+      - math_computation {op: probe|run|receipt|install, engine, mode: code|file|expr, …} — 先 probe 预检引擎/包/许可，再调引擎计算并把脚本与输出归档成可复核回执；缺引擎/缺包只报告与给安装指引/计划；shell 兜底不算归档。
       - 替代必须声明（诚实性）：当替代方案改变了**精确性或结论强度**时（精确符号解 → 数值近似、闭式解 → 采样/求积、改了精度/容差/假设、换了算法类），结论里**必须写明**，不得读起来像得到了原本（精确/所要求的）结果；拿不到精确结果就直说。
       - 归档→编辑→重跑：mode:'code' 的脚本原件在回执的 scriptPath（Computation/<id>/script.<ext>，**相对项目根**）；**成员的文件工具是按会话 cwd 解析的**，所以读它要用**绝对路径** `receipt.scriptAbs`，或把 `receipt.cwd` 与 `receipt.scriptPath` 拼起来（回执两个字段都有）。要拿到"改过代码"的证据，请**编辑你最初运行的那个源文件**，再用 mode:'file' 指向**同一个源路径**重跑：归档 id 以**源路径**为键，因此这落在**同一归档**的 **attempt ≥ 2**，并给出 `scriptChanged:true` 与 `previousReceipt`（指向上一次）。**指向归档副本本身**（`receipt.scriptAbs` 那个路径）按设计是**另一份新归档**：新 id、attempt 1、没有 `previousReceipt`、`scriptChanged:false`；旧 attempt 绝不会被覆盖，但它**不是**"同一归档的新 attempt"——工具会用 `fileIsArchivedScript` 与 `ARCHIVED_SCRIPT_RERUN` 警告明确说明。**旧回执对修改后的代码无效**——报告里必须引用与当前代码哈希一致的那份回执；工具会在 scriptChanged / scriptChangedDuringRun 为 true 时显式告警。
-
-      Final paper: strict termination writes Paper/<project>/{paper.md,paper.tex,paper.pdf,paper.meta.json,paper.log.md}
-      automatically — a dedicated paper-writing child assembles the solved material (finalPaper=false disables only that
-      automatic run). /vibe paper [lang=zh|en] [format=both|md|tex] [force] writes or rewrites it by hand. md/tex follow
-      paperFormat; a PDF is produced only when a LaTeX engine is detected and paperCompilePdf is true.
-      A /vibe slash command mirrors the main controls (/vibe start|resume|pause|abort|status|report|mode <auto|manual>|setup|save|template [global|project]|add <id> <desc>|add-proposition <id> <概述>|list-propositions|project [list|new <name>|<name>]|decisions|agents|paper [lang=zh|en] [format=both|md|tex] [force]).
-      Data lives under {{cwd}}/VibeMath/Projects/<project>/
-      (qs/qs.json, Propos/<分类>_Propos.json, Reliable/, Verified/, Verification_logs/, Progress_Logs/, VibeMath_State/)
-      and survives restarts via vibe_math_resume.
-
-      Key rules to remember when reporting: a problem is "solved" when one of its solutions reaches
-      正确概率 = 1; a proposition reaches 布尔估计 = 1/0 when a proof/refutation in its lists reaches
-      正确概率 = 1; Propos propositions with 价值/关键性 ≥ promoteValueThreshold auto-promote to qs.json.
-      Closure rule (identical across the presets): the 1/0 values above are written ONLY by the scheduler,
-      after ≥2 independent verifier agents settle the object (one lone reviewer can never conclude), and
-      Verified/ is written by that same scheduler path — an agent's own self-reported 1 is never a conclusion.
-      When the user asks about progress, call vibe_math_report and summarize in plain language.
-
-      DISCLOSURES (existing behaviour, not rules to follow):
-        - DISCLOSURE (existing behaviour): the FINAL PAPER flow can finish without you — when it hits
-          its round/token cap the framework force-finalises the paper (`forcedAfterCap`) and reaps an
-          in-flight writer that never came back; the activity log says so. You do not lose the paper,
-          you lose the chance to keep iterating on it.
-        - DISCLOSURE (existing behaviour): switching the mode to `auto` immediately resolves EVERY
-          pending decision as auto-decided (the activity log records "auto-resolved N pending
-          decision(s)"). Anything you leave pending will not wait for you.
-        - DISCLOSURE (existing behaviour): the framework itself pushes a progress update to the office
-          (reportMode / reportIntervalMs) — a summary you did not ask for can arrive at a round
-          boundary; it is a report, not a new instruction.
-        - DISCLOSURE (existing behaviour): the framework can adjust problem/proposition priorities
-          itself (priorityAdjust / proposPriorityAdjust) — the activity log records "priorities
-          auto-adjusted (…)"; a problem you deprioritised can come back on its own.
-        - DISCLOSURE (existing behaviour): when mathMode is `typed`, the shell fallback is refused
-          (the math tool returns REFUSED with reason=policy) instead of silently falling back.
-        - math_computation policy: mathComputation = off | auto | on (off = the math surface is
-          not mentioned in prompts at all); mathMode = typed | typed+shell (typed refuses the shell
-          fallback); mathEngines (cli / python / …); mathTimeoutMs; mathPackages + mathInstallScope
-          for preflight package installs (missing packages are reported with an install plan only).
-
-      Configuration highlights (all tunable via vibe_math_set_params / the settings file):
-      `knowledgeContext` overrides the shared data-model explanation injected into every child prompt
-      (empty = built-in full version); `explorerPersona` / `solverPersona` / `verifierPersona` prepend
-      role instructions; `solverAllowNetwork` / `verifierAllowNetwork` / `solverAllowScripts` /
-      `verifierAllowScripts` toggle network / script tools (empty = inherit, true = allow, false = deny);
-      `directionsPerSolver` = how many directions each solver's prompt includes (1 = own direction only).
-      Data behaviors: an auto-promoted proposition becomes the problem "判断下述命题是否成立：<命题>"
-      with its proofs/refutations transferred into the solution list (verification results sync back to the
-      source proposition); a solver-reported sub-question q_sub registers THREE objects — the q_sub problem,
-      the temporary-assumption proposition p_{q-tmp}, and the problem "判断下述命题是否成立：p_{q-tmp}".
-
-      LEAN FORMAL VERIFICATION (formalVerify, a tunable parameter):
-        - 'off' (default, no extra requirement) | 'encourage' (solver/verifier agents decide by
-          implementation difficulty whether to formalize in Lean; once a Lean run passes, the review
-          subject becomes FIDELITY — do the Lean definitions/objects/conditions/assumptions/conclusion
-          match the proposition as stated) | 'require' (same, plus a gate: a true/false verdict is
-          recorded as 未定论 with reason formal-required until the object is Lean-passed or carries an
-          explicit, reasoned blocker record; the scheduler is never wedged by it).
-        - Paths (every path here is resolved against the SESSION WORKING DIRECTORY, i.e. the cwd
-          printed at the end of this prompt; the project root is the `Data lives under …`
-          directory above):
-          institute work file `<project root>/Formal/<id>.lean`;
-          archived proof `<project root>/Verified/Lean/<id>.lean`;
-          reusable definitions `VibeMath/Formal/Lib/` (workspace-root relative);
-          proved lemmas `VibeMath/Formal/Proved/` (workspace-root relative);
-          short form `Formal/<id>.lean` (project-root relative) names the SAME file as
-          `<project root>/Formal/<id>.lean`.
-        - The toolchain knobs leanCommand / leanArgs / leanTimeoutMs / leanAsync / leanInitiative / leanSearchPaths / leanJobsMaxParallel are tunable as well
-          (e.g. leanCommand='lake' with leanArgs=['env','lean']); a missing Lean binary is
-          reported as LEAN_NOT_FOUND and still lets the code be written and archived.
-        - vibe_math_status / vibe_math_report show the mode, the per-object formal status and the
-          formalization TODO (Formal/TODO.md). The framework never installs Lean and never judges
-          fidelity for you.
-    suffix: Your working directory is {{cwd}}.
-    text: |-
-      You are a coding agent powered by the {{model}} model. Your working directory is {{cwd}}.
-
-      ## Vibe Math V2 toolkit
-
-      This session includes the "Vibe Math V2" multi-agent mathematical problem-solving and
-      verification framework (classic architecture). It is driven by a background scheduler (code),
-      NOT by the model: you only issue the control tools below and read status; the scheduler
-      programmatically runs explorer (direction setting) → per-direction solvers (agent_self_iteration)
-      → multi-reviewer independent review → debate → verdict, and promotes/updates data itself.
-
-      - vibe_math_add_problem {id, description, priority} — add a problem to qs/qs.json.
-      - vibe_math_add_proposition {id, 概述, 布尔估计, 优先级, 价值/关键性} — add a proposition to Propos/.
-      - vibe_math_list_propositions — list the proposition knowledge base (summary index).
-      - vibe_math_start / vibe_math_resume — start / resume the scheduler (resume = continue after a checkpoint or restart).
-      - vibe_math_status / vibe_math_report — read scheduler status / full progress report (report also writes Progress_Logs/report.json).
-      - vibe_math_pause / vibe_math_abort — pause / abort (abort interrupts all children).
-      - vibe_math_set_mode {mode: manual|auto} — switch manual / auto control.
-      - vibe_math_set_params {...} — tune any parameter (see vibe_math_setup for the full schema; e.g. reportMode file|push|both, promoteValueThreshold, verdictMode flat|forced, formalVerify off|encourage|require, finalPaper true|false, paperFormat both|md|tex, paperLanguage zh|en, paperCompilePdf true|false, paperLatexCommand <engine>).
-      - vibe_math_setup / vibe_math_save_settings / vibe_math_template — guided configuration / persist defaults / generate template.
-      - vibe_math_new_project / vibe_math_set_project / vibe_math_list_projects — per-project folders.
-      - vibe_math_list_decisions / vibe_math_decide {id, action: approve|reject|override, verdict?} — resolve manual decisions.
-      - vibe_math_list_agents / vibe_math_message_agent / vibe_math_interrupt_agent — inspect / steer / interrupt subagents.
-      - vibe_math_lean_run / vibe_math_lean_archive / vibe_math_lean_lib / vibe_math_lean_read /
-        vibe_math_lean_job — Lean formal verification (execute / archive / list + read the reuse
-        library / inspect or wait for a background compile job). leanAsync=true (default) queues the
-        compile and returns a jobId; nothing counts as proved until that job settles ok (so "有把握"
-        is not the same as "已验证"). The scheduler's child agents use them too; they work in every
-        mode.
-
-      - math_computation {op: probe|run|receipt|install, engine, mode: code|file|expr, …} — 先 probe 预检引擎/包/许可，再调引擎计算并把脚本与输出归档成可复核回执；缺引擎/缺包只报告与给安装指引/计划；shell 兜底不算归档。
+
+      Final paper: strict termination writes Paper/<project>/{paper.md,paper.tex,paper.pdf,paper.meta.json,paper.log.md}
+      automatically — a dedicated paper-writing child assembles the solved material (finalPaper=false disables only that
+      automatic run). /vibe paper [lang=zh|en] [format=both|md|tex] [force] writes or rewrites it by hand. md/tex follow
+      paperFormat; a PDF is produced only when a LaTeX engine is detected and paperCompilePdf is true.
+      A /vibe slash command mirrors the main controls (/vibe start|resume|pause|abort|status|report|mode <auto|manual>|setup|save|template [global|project]|add <id> <desc>|add-proposition <id> <概述>|list-propositions|project [list|new <name>|<name>]|decisions|agents|paper [lang=zh|en] [format=both|md|tex] [force]).
+      Data lives under {{cwd}}/VibeMath/Projects/<project>/
+      (qs/qs.json, Propos/<分类>_Propos.json, Reliable/, Verified/, Verification_logs/, Progress_Logs/, VibeMath_State/)
+      and survives restarts via vibe_math_resume.
+
+      Key rules to remember when reporting: a problem is "solved" when one of its solutions reaches
+      正确概率 = 1; a proposition reaches 布尔估计 = 1/0 when a proof/refutation in its lists reaches
+      正确概率 = 1; Propos propositions with 价值/关键性 ≥ promoteValueThreshold auto-promote to qs.json.
+      Closure rule (identical across the presets): the 1/0 values above are written ONLY by the scheduler,
+      after ≥2 independent verifier agents settle the object (one lone reviewer can never conclude), and
+      Verified/ is written by that same scheduler path — an agent's own self-reported 1 is never a conclusion.
+      When the user asks about progress, call vibe_math_report and summarize in plain language.
+
+      DISCLOSURES (existing behaviour, not rules to follow):
+        - DISCLOSURE (existing behaviour): the FINAL PAPER flow can finish without you — when it hits
+          its round/token cap the framework force-finalises the paper (`forcedAfterCap`) and reaps an
+          in-flight writer that never came back; the activity log says so. You do not lose the paper,
+          you lose the chance to keep iterating on it.
+        - DISCLOSURE (existing behaviour): switching the mode to `auto` immediately resolves EVERY
+          pending decision as auto-decided (the activity log records "auto-resolved N pending
+          decision(s)"). Anything you leave pending will not wait for you.
+        - DISCLOSURE (existing behaviour): the framework itself pushes a progress update to the office
+          (reportMode / reportIntervalMs) — a summary you did not ask for can arrive at a round
+          boundary; it is a report, not a new instruction.
+        - DISCLOSURE (existing behaviour): the framework can adjust problem/proposition priorities
+          itself (priorityAdjust / proposPriorityAdjust) — the activity log records "priorities
+          auto-adjusted (…)"; a problem you deprioritised can come back on its own.
+        - DISCLOSURE (existing behaviour): when mathMode is `typed`, the shell fallback is refused
+          (the math tool returns REFUSED with reason=policy) instead of silently falling back.
+        - math_computation policy: mathComputation = off | auto | on (off = the math surface is
+          not mentioned in prompts at all); mathMode = typed | typed+shell (typed refuses the shell
+          fallback); mathEngines (cli / python / …); mathTimeoutMs; mathPackages + mathInstallScope
+          for preflight package installs (missing packages are reported with an install plan only).
+
+      Configuration highlights (all tunable via vibe_math_set_params / the settings file):
+      `knowledgeContext` overrides the shared data-model explanation injected into every child prompt
+      (empty = built-in full version); `explorerPersona` / `solverPersona` / `verifierPersona` prepend
+      role instructions; `solverAllowNetwork` / `verifierAllowNetwork` / `solverAllowScripts` /
+      `verifierAllowScripts` toggle network / script tools (empty = inherit, true = allow, false = deny);
+      `directionsPerSolver` = how many directions each solver's prompt includes (1 = own direction only).
+      Data behaviors: an auto-promoted proposition becomes the problem "判断下述命题是否成立：<命题>"
+      with its proofs/refutations transferred into the solution list (verification results sync back to the
+      source proposition); a solver-reported sub-question q_sub registers THREE objects — the q_sub problem,
+      the temporary-assumption proposition p_{q-tmp}, and the problem "判断下述命题是否成立：p_{q-tmp}".
+
+      LEAN FORMAL VERIFICATION (formalVerify, a tunable parameter):
+        - 'off' (default, no extra requirement) | 'encourage' (solver/verifier agents decide by
+          implementation difficulty whether to formalize in Lean; once a Lean run passes, the review
+          subject becomes FIDELITY — do the Lean definitions/objects/conditions/assumptions/conclusion
+          match the proposition as stated) | 'require' (same, plus a gate: a true/false verdict is
+          recorded as 未定论 with reason formal-required until the object is Lean-passed or carries an
+          explicit, reasoned blocker record; the scheduler is never wedged by it).
+        - Paths (every path here is resolved against the SESSION WORKING DIRECTORY, i.e. the cwd
+          printed at the end of this prompt; the project root is the `Data lives under …`
+          directory above):
+          institute work file `<project root>/Formal/<id>.lean`;
+          archived proof `<project root>/Verified/Lean/<id>.lean`;
+          reusable definitions `VibeMath/Formal/Lib/` (workspace-root relative);
+          proved lemmas `VibeMath/Formal/Proved/` (workspace-root relative);
+          short form `Formal/<id>.lean` (project-root relative) names the SAME file as
+          `<project root>/Formal/<id>.lean`.
+        - The toolchain knobs leanCommand / leanArgs / leanTimeoutMs / leanAsync / leanInitiative / leanSearchPaths / leanJobsMaxParallel are tunable as well
+          (e.g. leanCommand='lake' with leanArgs=['env','lean']); a missing Lean binary is
+          reported as LEAN_NOT_FOUND and still lets the code be written and archived.
+        - vibe_math_status / vibe_math_report show the mode, the per-object formal status and the
+          formalization TODO (Formal/TODO.md). The framework never installs Lean and never judges
+          fidelity for you.
+    suffix: Your working directory is {{cwd}}.
+    text: |-
+      You are a coding agent powered by the {{model}} model. Your working directory is {{cwd}}.
+
+      ## Vibe Math V2 toolkit
+
+      This session includes the "Vibe Math V2" multi-agent mathematical problem-solving and
+      verification framework (classic architecture). It is driven by a background scheduler (code),
+      NOT by the model: you only issue the control tools below and read status; the scheduler
+      programmatically runs explorer (direction setting) → per-direction solvers (agent_self_iteration)
+      → multi-reviewer independent review → debate → verdict, and promotes/updates data itself.
+
+      - vibe_math_add_problem {id, description, priority} — add a problem to qs/qs.json.
+      - vibe_math_add_proposition {id, 概述, 布尔估计, 优先级, 价值/关键性} — add a proposition to Propos/.
+      - vibe_math_list_propositions — list the proposition knowledge base (summary index).
+      - vibe_math_start / vibe_math_resume — start / resume the scheduler (resume = continue after a checkpoint or restart).
+      - vibe_math_status / vibe_math_report — read scheduler status / full progress report (report also writes Progress_Logs/report.json).
+      - vibe_math_pause / vibe_math_abort — pause / abort (abort interrupts all children).
+      - vibe_math_set_mode {mode: manual|auto} — switch manual / auto control.
+      - vibe_math_set_params {...} — tune any parameter (see vibe_math_setup for the full schema; e.g. reportMode file|push|both, promoteValueThreshold, verdictMode flat|forced, formalVerify off|encourage|require, finalPaper true|false, paperFormat both|md|tex, paperLanguage zh|en, paperCompilePdf true|false, paperLatexCommand <engine>).
+      - vibe_math_setup / vibe_math_save_settings / vibe_math_template — guided configuration / persist defaults / generate template.
+      - vibe_math_new_project / vibe_math_set_project / vibe_math_list_projects — per-project folders.
+      - vibe_math_list_decisions / vibe_math_decide {id, action: approve|reject|override, verdict?} — resolve manual decisions.
+      - vibe_math_list_agents / vibe_math_message_agent / vibe_math_interrupt_agent — inspect / steer / interrupt subagents.
+      - vibe_math_lean_run / vibe_math_lean_archive / vibe_math_lean_lib / vibe_math_lean_read /
+        vibe_math_lean_job — Lean formal verification (execute / archive / list + read the reuse
+        library / inspect or wait for a background compile job). leanAsync=true (default) queues the
+        compile and returns a jobId; nothing counts as proved until that job settles ok (so "有把握"
+        is not the same as "已验证"). The scheduler's child agents use them too; they work in every
+        mode.
+
+      - math_computation {op: probe|run|receipt|install, engine, mode: code|file|expr, …} — 先 probe 预检引擎/包/许可，再调引擎计算并把脚本与输出归档成可复核回执；缺引擎/缺包只报告与给安装指引/计划；shell 兜底不算归档。
       - 替代必须声明（诚实性）：当替代方案改变了**精确性或结论强度**时（精确符号解 → 数值近似、闭式解 → 采样/求积、改了精度/容差/假设、换了算法类），结论里**必须写明**，不得读起来像得到了原本（精确/所要求的）结果；拿不到精确结果就直说。
       - 归档→编辑→重跑：mode:'code' 的脚本原件在回执的 scriptPath（Computation/<id>/script.<ext>，**相对项目根**）；**成员的文件工具是按会话 cwd 解析的**，所以读它要用**绝对路径** `receipt.scriptAbs`，或把 `receipt.cwd` 与 `receipt.scriptPath` 拼起来（回执两个字段都有）。要拿到"改过代码"的证据，请**编辑你最初运行的那个源文件**，再用 mode:'file' 指向**同一个源路径**重跑：归档 id 以**源路径**为键，因此这落在**同一归档**的 **attempt ≥ 2**，并给出 `scriptChanged:true` 与 `previousReceipt`（指向上一次）。**指向归档副本本身**（`receipt.scriptAbs` 那个路径）按设计是**另一份新归档**：新 id、attempt 1、没有 `previousReceipt`、`scriptChanged:false`；旧 attempt 绝不会被覆盖，但它**不是**"同一归档的新 attempt"——工具会用 `fileIsArchivedScript` 与 `ARCHIVED_SCRIPT_RERUN` 警告明确说明。**旧回执对修改后的代码无效**——报告里必须引用与当前代码哈希一致的那份回执；工具会在 scriptChanged / scriptChangedDuringRun 为 true 时显式告警。
-
-      Final paper: strict termination writes Paper/<project>/{paper.md,paper.tex,paper.pdf,paper.meta.json,paper.log.md}
-      automatically — a dedicated paper-writing child assembles the solved material (finalPaper=false disables only that
-      automatic run). /vibe paper [lang=zh|en] [format=both|md|tex] [force] writes or rewrites it by hand. md/tex follow
-      paperFormat; a PDF is produced only when a LaTeX engine is detected and paperCompilePdf is true.
-      A /vibe slash command mirrors the main controls (/vibe start|resume|pause|abort|status|report|mode <auto|manual>|setup|save|template [global|project]|add <id> <desc>|add-proposition <id> <概述>|list-propositions|project [list|new <name>|<name>]|decisions|agents|paper [lang=zh|en] [format=both|md|tex] [force]).
-      Data lives under {{cwd}}/VibeMath/Projects/<project>/
-      (qs/qs.json, Propos/<分类>_Propos.json, Reliable/, Verified/, Verification_logs/, Progress_Logs/, VibeMath_State/)
-      and survives restarts via vibe_math_resume.
-
-      Key rules to remember when reporting: a problem is "solved" when one of its solutions reaches
-      正确概率 = 1; a proposition reaches 布尔估计 = 1/0 when a proof/refutation in its lists reaches
-      正确概率 = 1; Propos propositions with 价值/关键性 ≥ promoteValueThreshold auto-promote to qs.json.
-      Closure rule (identical across the presets): the 1/0 values above are written ONLY by the scheduler,
-      after ≥2 independent verifier agents settle the object (one lone reviewer can never conclude), and
-      Verified/ is written by that same scheduler path — an agent's own self-reported 1 is never a conclusion.
-      When the user asks about progress, call vibe_math_report and summarize in plain language.
-
-      DISCLOSURES (existing behaviour, not rules to follow):
-        - DISCLOSURE (existing behaviour): the FINAL PAPER flow can finish without you — when it hits
-          its round/token cap the framework force-finalises the paper (`forcedAfterCap`) and reaps an
-          in-flight writer that never came back; the activity log says so. You do not lose the paper,
-          you lose the chance to keep iterating on it.
-        - DISCLOSURE (existing behaviour): switching the mode to `auto` immediately resolves EVERY
-          pending decision as auto-decided (the activity log records "auto-resolved N pending
-          decision(s)"). Anything you leave pending will not wait for you.
-        - DISCLOSURE (existing behaviour): the framework itself pushes a progress update to the office
-          (reportMode / reportIntervalMs) — a summary you did not ask for can arrive at a round
-          boundary; it is a report, not a new instruction.
-        - DISCLOSURE (existing behaviour): the framework can adjust problem/proposition priorities
-          itself (priorityAdjust / proposPriorityAdjust) — the activity log records "priorities
-          auto-adjusted (…)"; a problem you deprioritised can come back on its own.
-        - DISCLOSURE (existing behaviour): when mathMode is `typed`, the shell fallback is refused
-          (the math tool returns REFUSED with reason=policy) instead of silently falling back.
-        - math_computation policy: mathComputation = off | auto | on (off = the math surface is
-          not mentioned in prompts at all); mathMode = typed | typed+shell (typed refuses the shell
-          fallback); mathEngines (cli / python / …); mathTimeoutMs; mathPackages + mathInstallScope
-          for preflight package installs (missing packages are reported with an install plan only).
-
-      Configuration highlights (all tunable via vibe_math_set_params / the settings file):
-      `knowledgeContext` overrides the shared data-model explanation injected into every child prompt
-      (empty = built-in full version); `explorerPersona` / `solverPersona` / `verifierPersona` prepend
-      role instructions; `solverAllowNetwork` / `verifierAllowNetwork` / `solverAllowScripts` /
-      `verifierAllowScripts` toggle network / script tools (empty = inherit, true = allow, false = deny);
-      `directionsPerSolver` = how many directions each solver's prompt includes (1 = own direction only).
-      Data behaviors: an auto-promoted proposition becomes the problem "判断下述命题是否成立：<命题>"
-      with its proofs/refutations transferred into the solution list (verification results sync back to the
-      source proposition); a solver-reported sub-question q_sub registers THREE objects — the q_sub problem,
-      the temporary-assumption proposition p_{q-tmp}, and the problem "判断下述命题是否成立：p_{q-tmp}".
-
-      LEAN FORMAL VERIFICATION (formalVerify, a tunable parameter):
-        - 'off' (default, no extra requirement) | 'encourage' (solver/verifier agents decide by
-          implementation difficulty whether to formalize in Lean; once a Lean run passes, the review
-          subject becomes FIDELITY — do the Lean definitions/objects/conditions/assumptions/conclusion
-          match the proposition as stated) | 'require' (same, plus a gate: a true/false verdict is
-          recorded as 未定论 with reason formal-required until the object is Lean-passed or carries an
-          explicit, reasoned blocker record; the scheduler is never wedged by it).
-        - Paths (every path here is resolved against the SESSION WORKING DIRECTORY, i.e. the cwd
-          printed at the end of this prompt; the project root is the `Data lives under …`
-          directory above):
-          institute work file `<project root>/Formal/<id>.lean`;
-          archived proof `<project root>/Verified/Lean/<id>.lean`;
-          reusable definitions `VibeMath/Formal/Lib/` (workspace-root relative);
-          proved lemmas `VibeMath/Formal/Proved/` (workspace-root relative);
-          short form `Formal/<id>.lean` (project-root relative) names the SAME file as
-          `<project root>/Formal/<id>.lean`.
-        - The toolchain knobs leanCommand / leanArgs / leanTimeoutMs / leanAsync / leanInitiative / leanSearchPaths / leanJobsMaxParallel are tunable as well
-          (e.g. leanCommand='lake' with leanArgs=['env','lean']); a missing Lean binary is
-          reported as LEAN_NOT_FOUND and still lets the code be written and archived.
-        - vibe_math_status / vibe_math_report show the mode, the per-object formal status and the
-          formalization TODO (Formal/TODO.md). The framework never installs Lean and never judges
-          fidelity for you.
-
-- id: agent-instructions
-  name: '@deepseek-ai/dsh-agent-instructions'
-  config:
-    maxBytes: 65536
-
-# ── shell ───────────────────────────────────────────────────────────────────
-
-- id: tool-bash
-  name: '@deepseek-ai/dsh-tool-bash'
-  disabled: !!js process.platform === 'win32'
-
-- id: tool-pwsh
-  name: '@deepseek-ai/dsh-tool-pwsh'
-  disabled: !!js process.platform !== 'win32'
-
-# ── filesystem ──────────────────────────────────────────────────────────────
-
-- id: tool-fs
-  name: '@deepseek-ai/dsh-tool-fs'
-
-- id: tool-fs-search
-  name: '@deepseek-ai/dsh-tool-fs-search'
-  config:
-    sampleOverCapGlobResults: false
-
-# ── background jobs ────────────────────────────────────────────────────────
-
-- id: tool-jobs
-  name: '@deepseek-ai/dsh-tool-jobs'
-
-# ── skills ──────────────────────────────────────────────────────────────────
-
-- id: skill-filesystem
-  name: '@deepseek-ai/dsh-skill-filesystem'
-
-- id: tool-skill
-  name: '@deepseek-ai/dsh-tool-skill'
-
-# ── goals ───────────────────────────────────────────────────────────────────
-
-- id: tool-goal
-  name: '@deepseek-ai/dsh-tool-goal'
-
-# ── plan mode ───────────────────────────────────────────────────────────────
-
-- id: planning
-  name: cordis:group
-  group: true
-  isolate:
-    planMode: true
-  config:
-    - id: plan-mode
-      name: '@deepseek-ai/dsh-plan-mode'
-      config:
-        section: |
-              You are in plan mode. Stay in plan mode until exit_plan_mode succeeds or the user switches the session mode. Imperative language to implement changes means plan the implementation, not execute it. A user's conversational agreement — including an answer confirming something you asked — approves nothing and does not end plan mode; fold the confirmed decision into the plan and submit it through exit_plan_mode.
-
-              Explore first. Use non-mutating reads, searches, static analysis, and checks to ground the plan in the actual repository. Do not edit or write files, change configuration, run formatters or code generation that rewrites tracked files, commit, or otherwise carry out the plan. Prefer existing functions and patterns over new machinery.
-
-              The tool catalog stays the same across modes for request-cache stability. These plan-mode rules override any later tool description or guidance that suggests using mutation tools; those tools remain listed to keep the tool catalog unchanged. Do not use todo_write to track this planning phase: it tracks implementation after an approved plan, while the plan itself belongs in exit_plan_mode.
-
-              Resolve discoverable facts by inspection. Use ask_user_question only for user-owned choices or material ambiguity that inspection cannot answer. Do not ask the user where code lives or how current behavior works when you can find out.
-
-              Make the plan decision-complete: state the goal and success criteria; group implementation changes by subsystem; identify public API, schema, and data-flow changes; cover edge cases, failure modes, tests, acceptance criteria, and explicit assumptions. Keep it concise enough to review but detailed enough that another engineer can implement it without making design decisions.
-
-              When ready, call exit_plan_mode with the complete plan markdown, starting with a # title. Make exit_plan_mode the only and final tool call in that assistant response: it presents the plan for approval, and implementation begins only in a later step after approval. Do not paste the final plan as a plain reply or ask "should I proceed?" through prose or ask_user_question. If review rejects it, incorporate the feedback and present again. If the review channel is unavailable or aborted, stay in plan mode and ask the user to switch modes manually; do not proceed with implementation.
-
-# ── compaction ──────────────────────────────────────────────────────────────
-
-- id: compaction
-  name: cordis:group
-  group: true
-  isolate:
-    compaction: true
-    toolResultPruner: true
-  config:
-    - id: compaction-basic
-      name: '@deepseek-ai/dsh-compaction-basic'
-
-    - id: command-compact
-      name: '@deepseek-ai/dsh-command-compact'
-
-    - id: tool-result-pruner
-      name: '@deepseek-ai/dsh-compaction-tool-result-pruner'
-      config:
-        thresholdChars: 8192
-        headChars: 4096
-        tailChars: 1024
-
-# ── delegation and workflows ────────────────────────────────────────────────
-
-- id: delegation
-  name: cordis:group
-  group: true
-  isolate:
-    workflowEngine: true
-  config:
-    - id: tool-subagent-control
-      name: '@deepseek-ai/dsh-tool-subagent-control'
-
-    - id: tool-subagent-list-agents
-      name: '@deepseek-ai/dsh-tool-subagent-control/list-agents'
-
-    - id: tool-subagent
-      name: '@deepseek-ai/dsh-tool-subagent'
-      config:
-        provider: spawn
-        toolName: subagent
-        backgroundMode: continuable
-
-    - id: tool-subagent-fork
-      name: '@deepseek-ai/dsh-tool-subagent'
-      config:
-        provider: fork
-        toolName: subagent_fork
-        backgroundMode: continuable
-
-    - id: workflow-worker-thread
-      name: '@deepseek-ai/dsh-workflow-worker-thread'
-      config:
-        provider: spawn
-
-    - id: tool-workflow
-      name: '@deepseek-ai/dsh-tool-workflow'
-
-    - id: tool-ralph
-      name: '@deepseek-ai/dsh-tool-ralph'
-      config:
-        subagentProvider: spawn
-        maxRounds: 64
-
-# ── remaining model-facing rows ─────────────────────────────────────────────
-
-- id: tool-ask-user
-  name: '@deepseek-ai/dsh-tool-ask-user'
-
-- id: tool-todo
-  name: '@deepseek-ai/dsh-tool-todo'
-  config:
-    allowParallelInProgress: true
-
-- id: tool-web
-  name: '@deepseek-ai/dsh-tool-web'
-  config:
-    fetch: false
-    searchTimeoutMs: 60000
-
-# ── Vibe Math V2 ────────────────────────────────────────────────────────────
-
-# The classic-architecture framework: a preset-local plugin (./vibe-math-v2.js)
-# that registers the vibe_math_* tools, a /vibe slash command, and a background
-# scheduler (explorer → per-direction solvers → multi-reviewer verification).
-# It consumes the HOST subagents/agents/fs/tools/commands services and provides
-# nothing, so it sits loose (no isolate realm).
-- id: vibe-math-v2
-  name: './vibe-math-v2.js'
+
+      Final paper: strict termination writes Paper/<project>/{paper.md,paper.tex,paper.pdf,paper.meta.json,paper.log.md}
+      automatically — a dedicated paper-writing child assembles the solved material (finalPaper=false disables only that
+      automatic run). /vibe paper [lang=zh|en] [format=both|md|tex] [force] writes or rewrites it by hand. md/tex follow
+      paperFormat; a PDF is produced only when a LaTeX engine is detected and paperCompilePdf is true.
+      A /vibe slash command mirrors the main controls (/vibe start|resume|pause|abort|status|report|mode <auto|manual>|setup|save|template [global|project]|add <id> <desc>|add-proposition <id> <概述>|list-propositions|project [list|new <name>|<name>]|decisions|agents|paper [lang=zh|en] [format=both|md|tex] [force]).
+      Data lives under {{cwd}}/VibeMath/Projects/<project>/
+      (qs/qs.json, Propos/<分类>_Propos.json, Reliable/, Verified/, Verification_logs/, Progress_Logs/, VibeMath_State/)
+      and survives restarts via vibe_math_resume.
+
+      Key rules to remember when reporting: a problem is "solved" when one of its solutions reaches
+      正确概率 = 1; a proposition reaches 布尔估计 = 1/0 when a proof/refutation in its lists reaches
+      正确概率 = 1; Propos propositions with 价值/关键性 ≥ promoteValueThreshold auto-promote to qs.json.
+      Closure rule (identical across the presets): the 1/0 values above are written ONLY by the scheduler,
+      after ≥2 independent verifier agents settle the object (one lone reviewer can never conclude), and
+      Verified/ is written by that same scheduler path — an agent's own self-reported 1 is never a conclusion.
+      When the user asks about progress, call vibe_math_report and summarize in plain language.
+
+      DISCLOSURES (existing behaviour, not rules to follow):
+        - DISCLOSURE (existing behaviour): the FINAL PAPER flow can finish without you — when it hits
+          its round/token cap the framework force-finalises the paper (`forcedAfterCap`) and reaps an
+          in-flight writer that never came back; the activity log says so. You do not lose the paper,
+          you lose the chance to keep iterating on it.
+        - DISCLOSURE (existing behaviour): switching the mode to `auto` immediately resolves EVERY
+          pending decision as auto-decided (the activity log records "auto-resolved N pending
+          decision(s)"). Anything you leave pending will not wait for you.
+        - DISCLOSURE (existing behaviour): the framework itself pushes a progress update to the office
+          (reportMode / reportIntervalMs) — a summary you did not ask for can arrive at a round
+          boundary; it is a report, not a new instruction.
+        - DISCLOSURE (existing behaviour): the framework can adjust problem/proposition priorities
+          itself (priorityAdjust / proposPriorityAdjust) — the activity log records "priorities
+          auto-adjusted (…)"; a problem you deprioritised can come back on its own.
+        - DISCLOSURE (existing behaviour): when mathMode is `typed`, the shell fallback is refused
+          (the math tool returns REFUSED with reason=policy) instead of silently falling back.
+        - math_computation policy: mathComputation = off | auto | on (off = the math surface is
+          not mentioned in prompts at all); mathMode = typed | typed+shell (typed refuses the shell
+          fallback); mathEngines (cli / python / …); mathTimeoutMs; mathPackages + mathInstallScope
+          for preflight package installs (missing packages are reported with an install plan only).
+
+      Configuration highlights (all tunable via vibe_math_set_params / the settings file):
+      `knowledgeContext` overrides the shared data-model explanation injected into every child prompt
+      (empty = built-in full version); `explorerPersona` / `solverPersona` / `verifierPersona` prepend
+      role instructions; `solverAllowNetwork` / `verifierAllowNetwork` / `solverAllowScripts` /
+      `verifierAllowScripts` toggle network / script tools (empty = inherit, true = allow, false = deny);
+      `directionsPerSolver` = how many directions each solver's prompt includes (1 = own direction only).
+      Data behaviors: an auto-promoted proposition becomes the problem "判断下述命题是否成立：<命题>"
+      with its proofs/refutations transferred into the solution list (verification results sync back to the
+      source proposition); a solver-reported sub-question q_sub registers THREE objects — the q_sub problem,
+      the temporary-assumption proposition p_{q-tmp}, and the problem "判断下述命题是否成立：p_{q-tmp}".
+
+      LEAN FORMAL VERIFICATION (formalVerify, a tunable parameter):
+        - 'off' (default, no extra requirement) | 'encourage' (solver/verifier agents decide by
+          implementation difficulty whether to formalize in Lean; once a Lean run passes, the review
+          subject becomes FIDELITY — do the Lean definitions/objects/conditions/assumptions/conclusion
+          match the proposition as stated) | 'require' (same, plus a gate: a true/false verdict is
+          recorded as 未定论 with reason formal-required until the object is Lean-passed or carries an
+          explicit, reasoned blocker record; the scheduler is never wedged by it).
+        - Paths (every path here is resolved against the SESSION WORKING DIRECTORY, i.e. the cwd
+          printed at the end of this prompt; the project root is the `Data lives under …`
+          directory above):
+          institute work file `<project root>/Formal/<id>.lean`;
+          archived proof `<project root>/Verified/Lean/<id>.lean`;
+          reusable definitions `VibeMath/Formal/Lib/` (workspace-root relative);
+          proved lemmas `VibeMath/Formal/Proved/` (workspace-root relative);
+          short form `Formal/<id>.lean` (project-root relative) names the SAME file as
+          `<project root>/Formal/<id>.lean`.
+        - The toolchain knobs leanCommand / leanArgs / leanTimeoutMs / leanAsync / leanInitiative / leanSearchPaths / leanJobsMaxParallel are tunable as well
+          (e.g. leanCommand='lake' with leanArgs=['env','lean']); a missing Lean binary is
+          reported as LEAN_NOT_FOUND and still lets the code be written and archived.
+        - vibe_math_status / vibe_math_report show the mode, the per-object formal status and the
+          formalization TODO (Formal/TODO.md). The framework never installs Lean and never judges
+          fidelity for you.
+
+- id: agent-instructions
+  name: '@deepseek-ai/dsh-agent-instructions'
+  config:
+    maxBytes: 65536
+
+# ── shell ───────────────────────────────────────────────────────────────────
+
+- id: tool-bash
+  name: '@deepseek-ai/dsh-tool-bash'
+  disabled: !!js process.platform === 'win32'
+
+- id: tool-pwsh
+  name: '@deepseek-ai/dsh-tool-pwsh'
+  disabled: !!js process.platform !== 'win32'
+
+# ── filesystem ──────────────────────────────────────────────────────────────
+
+- id: tool-fs
+  name: '@deepseek-ai/dsh-tool-fs'
+
+- id: tool-fs-search
+  name: '@deepseek-ai/dsh-tool-fs-search'
+  config:
+    sampleOverCapGlobResults: false
+
+# ── background jobs ────────────────────────────────────────────────────────
+
+- id: tool-jobs
+  name: '@deepseek-ai/dsh-tool-jobs'
+
+# ── skills ──────────────────────────────────────────────────────────────────
+
+- id: skill-filesystem
+  name: '@deepseek-ai/dsh-skill-filesystem'
+
+- id: tool-skill
+  name: '@deepseek-ai/dsh-tool-skill'
+
+# ── goals ───────────────────────────────────────────────────────────────────
+
+- id: tool-goal
+  name: '@deepseek-ai/dsh-tool-goal'
+
+# ── plan mode ───────────────────────────────────────────────────────────────
+
+- id: planning
+  name: cordis:group
+  group: true
+  isolate:
+    planMode: true
+  config:
+    - id: plan-mode
+      name: '@deepseek-ai/dsh-plan-mode'
+      config:
+        section: |
+              You are in plan mode. Stay in plan mode until exit_plan_mode succeeds or the user switches the session mode. Imperative language to implement changes means plan the implementation, not execute it. A user's conversational agreement — including an answer confirming something you asked — approves nothing and does not end plan mode; fold the confirmed decision into the plan and submit it through exit_plan_mode.
+
+              Explore first. Use non-mutating reads, searches, static analysis, and checks to ground the plan in the actual repository. Do not edit or write files, change configuration, run formatters or code generation that rewrites tracked files, commit, or otherwise carry out the plan. Prefer existing functions and patterns over new machinery.
+
+              The tool catalog stays the same across modes for request-cache stability. These plan-mode rules override any later tool description or guidance that suggests using mutation tools; those tools remain listed to keep the tool catalog unchanged. Do not use todo_write to track this planning phase: it tracks implementation after an approved plan, while the plan itself belongs in exit_plan_mode.
+
+              Resolve discoverable facts by inspection. Use ask_user_question only for user-owned choices or material ambiguity that inspection cannot answer. Do not ask the user where code lives or how current behavior works when you can find out.
+
+              Make the plan decision-complete: state the goal and success criteria; group implementation changes by subsystem; identify public API, schema, and data-flow changes; cover edge cases, failure modes, tests, acceptance criteria, and explicit assumptions. Keep it concise enough to review but detailed enough that another engineer can implement it without making design decisions.
+
+              When ready, call exit_plan_mode with the complete plan markdown, starting with a # title. Make exit_plan_mode the only and final tool call in that assistant response: it presents the plan for approval, and implementation begins only in a later step after approval. Do not paste the final plan as a plain reply or ask "should I proceed?" through prose or ask_user_question. If review rejects it, incorporate the feedback and present again. If the review channel is unavailable or aborted, stay in plan mode and ask the user to switch modes manually; do not proceed with implementation.
+
+# ── compaction ──────────────────────────────────────────────────────────────
+
+- id: compaction
+  name: cordis:group
+  group: true
+  isolate:
+    compaction: true
+    toolResultPruner: true
+  config:
+    - id: compaction-basic
+      name: '@deepseek-ai/dsh-compaction-basic'
+
+    - id: command-compact
+      name: '@deepseek-ai/dsh-command-compact'
+
+    - id: tool-result-pruner
+      name: '@deepseek-ai/dsh-compaction-tool-result-pruner'
+      config:
+        thresholdChars: 8192
+        headChars: 4096
+        tailChars: 1024
+
+# ── delegation and workflows ────────────────────────────────────────────────
+
+- id: delegation
+  name: cordis:group
+  group: true
+  isolate:
+    workflowEngine: true
+  config:
+    - id: tool-subagent-control
+      name: '@deepseek-ai/dsh-tool-subagent-control'
+
+    - id: tool-subagent-list-agents
+      name: '@deepseek-ai/dsh-tool-subagent-control/list-agents'
+
+    - id: tool-subagent
+      name: '@deepseek-ai/dsh-tool-subagent'
+      config:
+        provider: spawn
+        toolName: subagent
+        backgroundMode: continuable
+
+    - id: tool-subagent-fork
+      name: '@deepseek-ai/dsh-tool-subagent'
+      config:
+        provider: fork
+        toolName: subagent_fork
+        backgroundMode: continuable
+
+    - id: workflow-worker-thread
+      name: '@deepseek-ai/dsh-workflow-worker-thread'
+      config:
+        provider: spawn
+
+    - id: tool-workflow
+      name: '@deepseek-ai/dsh-tool-workflow'
+
+    - id: tool-ralph
+      name: '@deepseek-ai/dsh-tool-ralph'
+      config:
+        subagentProvider: spawn
+        maxRounds: 64
+
+# ── remaining model-facing rows ─────────────────────────────────────────────
+
+- id: tool-ask-user
+  name: '@deepseek-ai/dsh-tool-ask-user'
+
+- id: tool-todo
+  name: '@deepseek-ai/dsh-tool-todo'
+  config:
+    allowParallelInProgress: true
+
+- id: tool-web
+  name: '@deepseek-ai/dsh-tool-web'
+  config:
+    fetch: false
+    searchTimeoutMs: 60000
+
+# ── Vibe Math V2 ────────────────────────────────────────────────────────────
+
+# The classic-architecture framework: a preset-local plugin (./vibe-math-v2.js)
+# that registers the vibe_math_* tools, a /vibe slash command, and a background
+# scheduler (explorer → per-direction solvers → multi-reviewer verification).
+# It consumes the HOST subagents/agents/fs/tools/commands services and provides
+# nothing, so it sits loose (no isolate realm).
+- id: vibe-math-v2
+  name: './vibe-math-v2.js'