dsh-vibe-math 2.6.0 → 2.7.1

package/README.en.md

@@ -20,6 +20,20 @@ After installing this plugin package (or manually copying the presets), **four**
 
 ---
 
+## 🧭 Navigation: I want to … → start here
+
+- **Get started (first run)** → [Start in five minutes](#-start-in-five-minutes)
+- **Which of the four presets to pick** → [How to choose among the four presets](#-how-to-choose-among-the-four-presets)
+- **Positioning, flow and division of labour of the four** → [Architecture Diagrams](#-architecture-diagrams-v2--v3--v4--v5) · [Architecture and division of labour](#-architecture-and-division-of-labour-all-four-in-parallel)
+- **New: the final paper (produced at closure)** → [Features](#-features) · [full contract](docs/final-paper.md)
+- **Lean formal verification** → [Lean formal verification](#-lean-formal-verification-shared-by-the-four-architectures-adjustable-switch) · [full contract](docs/formal-verification.md)
+- **What is in the directories** → [Directory structure](#-directory-structure)
+- **Tuning parameters** → [Parameter quick reference](#-parameter-quick-reference)
+- **Checkpoint resume / mid-run intervention** → [Checkpoint resume & manual intervention](#-checkpoint-resume--manual-intervention-two-hard-requirements)
+- **Known limitations** → [Known limitations](#-known-limitations-deliberate-simplifications)
+
+---
+
 ## 🧩 Architecture Diagrams (v2 + v3 + v4 + v5)
 
 > Static architecture diagrams; for the complete process description see [the v1-era architecture notes](docs/架构图.md) (historical: the layout changed from v2 on) and
@@ -93,126 +107,15 @@ flowchart TB
     M --> RULE
 ```
 
-#### Positions and Authority
-
-| Position | Codename | Voting right | Authority |
-|---|---|---|---|
-| **Academician** (leader) | `acad` | ✅ one vote, **of equal weight with others** | **Center of organization and coordination**: build an institute-wide overview (`overview`), decompose the original problem into tasks and **assign** them (`assign`), set priorities (`prioritize`), convene and chair meetings (`convene`), supervise progress (`nudge`), move temp workers around, report outward. **Cannot unilaterally conclude**, and cannot expand the roster on its own. |
-| **Resident researcher** | `r-<n>` | ✅ one vote | Digs deep in its own direction; **may autonomously hire/fire its own temp workers**; reports progress to the academician and accepts its organization and assignments (**has the right of reasoned objection**). |
-| **Temp worker** | `t-<n>` | ❌ | Hired temporarily for a specific task: can read/think/speak/write its own output library/claim or be assigned tasks; fired by its **employer or the academician**. Codenames are never reused. |
-| **Institute office** (main assistant) | —— | ❌ | **Does not take part in research and does not vote.** Only reports, translates the human's words into tool calls, and holds on the human's behalf the creation rights the platform requires (creating an institute / adding resident researchers). |
-
-**Division of labor in one sentence**: **organization is the academician's responsibility, but judgment belongs to each person individually** —— what the academician assigns is **work**, not **conclusions**.
-
-#### Truth Rules (the core of V5)
-
-For an object to enter `Verified/` it must **simultaneously** satisfy:
-
-1. At least **m = min(`quorumCap`, number of registered voting members)** voting members cast a **Boolean probability value**;
-2. These votes are **all** `1` (absolutely true) or **all** `0` (absolutely false).
-
-A vote is a numeric value in `[0,1]`: **strictly between 0 and 1 = abstention/doubt** (not counted toward m, but counted in the group's average probability).
-**Any single opposing Boolean vote blocks a conclusion** —— the minority cannot push a conclusion through by having others abstain.
-An object that falls short of the threshold **stays in its original library**, with the group's average probability and the complete debate record attached, and is **not forcibly ruled on**.
-
-Voting has two stages: first [independent initial assessment] (mutually invisible), and if undecided, then [open debate] followed by a re-vote, with a round cap of `verdictMaxRounds`.
-`quorumMode: "all-unanimous"` switches back to v4's "all-unanimous" standard.
-
-#### Operating Mechanisms
-
-- **Communication**: group chat (fanned out to every other member), direct message, votes cast only to members with voting rights; messages are **persisted per recipient**,
-  written to disk before delivery, and group chat is batched into digests by `chatDigestMs` / `chatDigestMax` (direct messages/meetings/votes are not batched).
-  All in-institute communication goes through the framework relay (DSH's adjacency restriction does not allow members to message each other directly), but **the signature is always the real sender**.
-- **Meetings and verification are mutually exclusive** (in both directions): meeting requests while verification is under way are **held**; verification requested while a meeting is under way is **queued** ——
-  the two consensus processes never run at the same time, avoiding mutual starvation of the watchdog clocks. Meetings collect opinions one by one in a **random speaking order**,
-  and at closing they aggregate the votes and check whether everyone considers the problem solved.
-- **Task board**: compare-and-set (the latest `expected_revision` must be read before a change) + dependency DAG (all dependencies must be complete before claiming;
-  cycle detection rejects bad dependencies) + write-scope overlap warnings; when an owner is fired, its tasks are automatically reclaimed.
-- **Hiring / firing**: both academicians and resident researchers can hire **their own** temp workers, with a dual quota per member (`maxTempPerMember`) and institute-wide
-  (`maxTempTotal`); firing is **real** —— it cancels in-flight turns, releases the resident sub-session, reclaims tasks, and discards undelivered mail.
-- **Liveness**: the main drive is a **one-shot activity wait** (`vibe_v5_wait`, no polling); the scheduler advances by priority
-  (in-progress meetings/verification → queued verification → held meetings → active tasks → urgent mail → group chat digest → auto-meeting on stall → fallback heartbeat),
-  and concurrency is gated by `maxParallel`; the task board's "nudge" is **throttled** by `activityTimeoutMs`.
-- **Watchdog**: if a meeting/verification goes beyond 2×`activityTimeoutMs` with no new speech/new votes → abandon it and return to self-organization;
-  the heartbeat is **re-armed after every wake**, so the scheduler never freezes permanently.
-- **Context**: upon reaching `compactThreshold` (%) or accumulating `compactAfterRounds` rounds, members are asked to condense their working state into
-  `Progress/`; **the charter lives in the persona**, remains in effect after compaction, and does not need to be restated every round.
-- **Stopping**: the problem is concluded (**writing `Problems/conclusion.md`**) **only when all voting members consider the original problem solved**.
-
-#### State and Persistence
-
-Institute state is written **only** to the **hardened JSON file** `State/<institute>.v5state.json` under the institute directory: the framework's only side effect is to hand 11 kinds of events to
-`applyV5Event`, which purely folds them into a state, and then to write that whole snapshot **serially to disk** (one serialization chain per file). Therefore
-
-- **Zero token cost**: these events **do not enter the model context** and do not consume members' conversation budget;
-- **Recovery takes the same code path**: both cross-process restarts and resume after an in-process abort are covered by the "mandatory load before read", which is the same code either way;
-- the whole class of problems caused by v4's direct writes to `State/*.json` — "corrupted silent overwrite / concurrent lost writes / stale cross-process snapshots" — is eliminated by construction.
-
-**v5 no longer writes institute events into the host session log**: DSH's session persistence **refuses to load an entire session** whose log carries an event type it does not know
-(unless the writer marked it `ignorable: true`, and `Session.append` cannot set that field) — which would make **your own session unopenable on the next resume**.
-Everything except the state file (member output libraries, group chat, meeting minutes, debate records, roster mirror, task board mirror) is a **human-readable artifact**,
-and breaking it by hand does not damage the institute.
+**One-sentence pipeline**: the institute office (session root / human) `configure → start`s the institute → the **academician** (center of organization and coordination) decomposes the original problem, **assigns** tasks, sets priorities, chairs meetings and supervises progress; **resident researchers** research on their own and hold the vote, and **temp workers** can be hired as needed (no vote, genuinely dismissible). **The framework is only a medium and never assigns tasks**; every conclusion needs **≥ m = min(`quorumCap`, number of registered voting members) Boolean votes, all on the same side**, before it is written to `Verified/` (an opposing vote blocks; abstentions do not count as votes but count toward the average; below the threshold the object stays in its library with its average probability); meetings and verification are **mutually exclusive in both directions**; state lives in the hardened JSON `State/<institute>.v5state.json` under the institute directory (zero token cost, serial writes, a mandatory load before read); the problem is concluded **only when all voting members consider it solved**.
 
-#### How the Prompt Is Composed
-
-A member's "persona" carries the **ten-section public charter** (roster and colleagues, general rules, knowledge base and progress format,
-organization and coordination, voting rules, per-round rhythm, hiring and firing, task board, context discipline, stopping conditions), which is **frozen at onboarding** and persists with the session;
-each round's prompt carries only a short **state block** (who I am / the round / m / the registered roster / my tasks / newly arrived messages), **this round's question**,
-and the **receipt contract**. Every field in the receipt contract that the framework actually handles appears, trimmed by position
-(temp workers have no `verdict`/`hire`/`fire`; non-academicians have no `assign`/`prioritize`/`nudge`/`convene_meeting`).
-
-The framework treats "the text a member reads" as a product to be guaranteed: identity is **passed explicitly and never guessed**; a member is **written to the roster first, and only then** are its onboarding
-prompts constructed; the charter snapshot is frozen at onboarding, and a session rebuild is framed as the literal marker `【会话重建 —— <role> <id>】` ("session rebuild") rather than "just onboarded"; no academician narrative appears when there is no academician;
-message headers are labeled by **true origin** (institute office assignment ≠ academician assignment; supervision ≠ assignment); framework feedback has its own sender,
-and **only one message is delivered per prompt**.
-
-#### Directory Structure (Institute)
-
-```
-<session workspace>/VibeMath/Projects/<project>/Institutes/<institute>/
-├─ Institutes.md                 # roster mirror (human-readable snapshot, do not edit by hand)
-├─ Problems/<id>.md              # original problem
-├─ Problems/conclusion.md        # conclusion record
-├─ Members/<codename>/
-│   ├─ Progress/progress.md      # research log (the main basis for restoring state after compaction)
-│   ├─ Propos/<id>.md            # proposition
-│   ├─ Methods/<id>.md           # method / theory / tool
-│   └─ Subproblems/<id>.md       # subproblem
-├─ Shared/
-│   ├─ Chat/<date>.md            # group chat log
-│   ├─ Meetings/<mt-id>.md       # meeting minutes (including the voting section)
-│   ├─ Debates/<object>.md       # debate record (each round's votes and reasons + average probability)
-│   ├─ TaskBoard.md              # task board mirror
-│   └─ State-of-institute.md     # snapshot of members' judgment on "whether it is solved"
-├─ Verified/<type>/<id>.md       # conclusion (read-only; only this can be treated as established)
-└─ State/README.md               # explains that "the files here are mirrors — do not hand-edit them"
-```
-
-#### Tool Surface
-
-| Who | Tools |
-|---|---|
-| **Institute office / human** | `vibe_v5_configure` (configure first) → `vibe_v5_start` (start work); `vibe_v5_resume` / `pause` / `stop`; `vibe_v5_set` (adjust parameters, effective immediately); `vibe_v5_status` / `report` / `members`; `vibe_v5_message` / `meeting`; `vibe_v5_hire` / `fire` / `add_researcher` / `remove_researcher`; slash command `/v5` |
-| **All members** | `vibe_v5_say` (group chat/direct message/to all voters), `vibe_v5_wait` (poll-free wait), `vibe_v5_record_progress`, `vibe_v5_record_proposition` / `_method` / `_subproblem`, `vibe_v5_read_library` (cross-read others' libraries, read-only), `vibe_v5_propose_verify`, `vibe_v5_verdict`, `vibe_v5_task_create` / `_list` / `_get` / `_update`, `vibe_v5_meeting` (propose) |
-| **Academician** (also has the `academicianLeads` switch) | `vibe_v5_overview` (institute-wide overview), `vibe_v5_assign` (assignment, must state the reason and acceptance criteria), `vibe_v5_prioritize`, `vibe_v5_nudge` |
-
-#### Key Differences from v4
-
-- **There is a leader**: v4 has no central scheduling and everything emerges from discussion; v5 has an academician responsible for organization and assignment **inside the institute**
-  (**the framework still never assigns** —— the assigner is the academician, who is likewise bound by the m votes).
-- **The truth gate changes from "all-unanimous" to "≥ m unanimous"** (switchable back to the v4 standard).
-- **State is stored in the hardened JSON file** `State/<institute>.v5state.json` under the institute directory (serial writes, a mandatory load before read): recovery is simply that load-before-read (see above).
-- **Three classes of positions + hireable temp workers**: the roster is mutable, and hiring/firing are real reversible operations.
-- **No npm experimental package is introduced**: v5 is a single `.js` file within the preset, with zero dependencies.
-- **Meetings and verification are strictly mutually exclusive** (queued in both directions).
-
-See [the v5 specification](vibe-math-v5/实现方案.md) (written specification) and
-[the v5 detail diagrams](vibe-math-v5/架构图.md) (all detail diagrams).
+> Positions and authority, the detailed truth rules, operating mechanisms, state and persistence, prompt composition, the institute directory, the tool surface, and the differences from v4: see [the v5 detail diagrams](vibe-math-v5/架构图.md) §13 "v5 notes moved from the README" (text preserved); parameters are in the [parameter quick reference](#-parameter-quick-reference), and the final paper in [`docs/final-paper.md`](docs/final-paper.md).
 
 ---
 
 ## ✨ Features
 
+- **Final paper (on by default in all four presets)**: at closure the run writes a complete paper that **only organises evidence it already has**, and the paper phase runs **before** the run is marked complete; the artifacts are `Paper/<id>/{paper.md,paper.tex,paper.pdf,paper.meta.json,paper.log.md}`. Parameters: `finalPaper` (default `true`) / `paperFormat` (default `both`) / `paperLanguage` (default `zh`) / `paperCompilePdf` (default `true`) (plus `paperEditor` on v4/v5); the manual trigger is `/vN paper [lang=] [format=] [editor=] [force]`. A PDF needs a LaTeX engine on the host (`xelatex` preferred for Chinese); without one the tex+md are still delivered. Full contract and usage: [`docs/final-paper.md`](docs/final-paper.md).
 - **Multi-agent automatic solving**: the main agent hands the problem to the scheduler, which dispatches explorer / solver / verifier (v2/v3) plus subagents such as **planner (planning agent, v3)** and **method-keeper (method organizing agent, v3)** to solve collaboratively; **you do not need to operate node by node by hand**.
 - **Multi-agent cross-validation**: every conclusion goes to ≥3 "strict reviewers" for **independent review → debate (exchange group) → adjudication** (v3 defaults to **near-consensus adjudication**: if on the same side and the mean is ≥0.85/≤0.15, take the mean, so that "0.9 vs 1" is not misjudged as 0.5).
 - **Paper-style Markdown knowledge base (v3)**: the problem list (including dependencies between problems, and the causes and plans of descendant problems), research log, propositions, and method library are all written and continued in md paper/research-report style (when a direction is re-derived, the logs of the old direction are automatically archived and kept); **only `Verified/` and the objects that a verifier judged true/false are absolutely trustworthy**, and all other md (including unverified assertions in the method library) serve only as empirical reference.
@@ -242,96 +145,19 @@ See [the v5 specification](vibe-math-v5/实现方案.md) (written specification)
 
 **What it changes is not "being a bit stricter" but the object of review itself.** m agents agreeing that "this is right" is still **consensus** —
 it cannot rule out shared misunderstanding; passing Lean is **machine checking**. The only remaining uncertainty is thus reduced to a question a single person can review effectively:
+**are the definitions / objects / conditions / assumptions / conclusions in the Lean code fully consistent with the original text of the proposition (fidelity)?**
 
-> **Are the definitions / objects / conditions / assumptions / conclusions in the Lean code fully consistent with the original text of the proposition?**
+- **Switch `formalVerify` (same name in all four architectures, default `'off'`)**: `'off'` is a **true no-op** (no Lean content appears in the prompts, no formalization state is written, and the verification flow and gates are completely unchanged; the five tools stay registered and usable and the persona always lists them, otherwise the switch would be undiscoverable and could not be turned on); `'encourage'` is **encouraged but not mandatory** (decide by implementation difficulty whether to formalize; once Lean passes, the focus of review shifts to fidelity; **no gate**); `'require'` is **mandatory** — a true/false conclusion must satisfy "**Lean has passed**" or "**the blocking reason was explicitly recorded**", otherwise the adjudication does not take effect (recorded as undecided, reason `formal-required`, written into the "formalization TODO"). Related parameters: `leanCommand` (default `lean`), `leanArgs` (used with `lake env lean`), `leanTimeoutMs` (default 120s).
 
-| | Original verification work | Verification work after formalization passes |
-|---|---|---|
-| Object of review | The proposition itself (whether the derivation is correct) | **Fidelity**: whether the Lean code ↔ the original text of the proposition are consistent |
-| Strength of the conclusion | Consensus (may be jointly wrong) | Strict (already checked by the kernel), provided that fidelity holds |
-| By-product | None | A reusable Lean definition / lemma library |
+- **⚠️ A fidelity defect ≠ the proposition is false (important)**: passing Lean only guarantees that "this piece of code passed the kernel"; it **does not guarantee that it says what the proposition means to say**. When a voter finds the Lean code and the original proposition inconsistent (too narrow / too broad / a different object / a missing condition): **do not vote 0** (0 means "the proposition is false" — that would record "the formalization does not qualify" as "the proposition was disproved", and under v5's all-0 consistency rule it would even write the proposition into `Verified/` marked **false**, so a mechanism meant for truth-seeking would fabricate a wrong negative conclusion); instead vote a value strictly between 0 and 1 (an abstention) and record the deviation with the receipt `formal:{decision:'defect', note:'<specific deviation>'}`. The framework then **revokes the "passed" state of this proof** (downgraded to `attempted`, `Verified/Lean/<id>.lean` deleted or rewritten as a "withdrawn" note if the host cannot delete it, and written into the "formalization TODO"), and under `require` this adjudication is not concluded (the `encourage` setting has no gate, so you must not claim the framework will force a shelving). Vote 0 only when the voter, **independently of this Lean code**, can also determine that the proposition is false (and can give independent reasons).
+- **The receipt channel and three further hard requirements** (members who do not call the Lean tools can also leave a judgment; mandatory under `require`): the receipt field is `"formal": {"target":"<object id>", "decision":"used|blocked|defect", "file":"Formal/<object id>.lean", "note":"difficulty judgment/blocking reason/specific deviation"}`; when `decision='blocked'`/`'defect'`, **`note` is required** (if missing the whole entry is rejected), `used` only records the object as `attempted`, and under `off` this channel **is disabled** (otherwise `off` would not be a true no-op). Three more: tool names in the injected text are always given in **full** (`<prefix>_lean_archive`, not `lean_archive` — an abbreviation is not a registered name); before archiving a reusable definition/lemma **run it through first**, and if it does not run through it must not enter the library; when the **toolchain is missing** (`LEAN_NOT_FOUND` cannot resolve the executable / the host has no `subprocess` service), write the code down, archive it, and state "the host has no Lean toolchain" in `note` — this counts as an explicit blocking reason and the gate lets it through.
 
-### Switch: `formalVerify` (same name in all four architectures, default `'off'`)
+- **Where the artifacts go**: `<VibeMath root>/Formal/Lib|Proved/` are the **cross-project** reusable definitions and already-proved lemmas (each with an `Index.md`, to be checked before writing a new definition); inside a project, `Formal/<object id>.lean` is the object's working file (next to an `Index.md` and, under `require`, a `TODO.md`), and `Verified/Lean/<object id>.lean` is the **archived proof** (in v5 these live under `Projects/<project>/Institutes/<institute>/`).
 
-| Value | Meaning |
-|---|---|
-| **`'off'` (default)** | **No additional requirement whatsoever.** No Lean content appears in member prompts, no formalization state is written, and the verification flow and gates are completely unchanged (it is a **true no-op**, guarded by assertions and probes). The three tools are still registered and usable (calling them proactively works as usual); the main agent's persona **always** lists these three tools and four parameters — otherwise the switch would not be discoverable, and "off" could not be turned on |
-| `'encourage'` | **Encouraged but not mandatory**: at verification time, first judge the **implementation difficulty** of the object, and if it can be formalized within an acceptable amount of work, do that first; once Lean passes, the focus of review shifts to **fidelity**. In ordinary work, it is also encouraged to formalize and archive commonly used / potentially reusable objects, assumptions, and new definitions along the way. **No gate** |
-| `'require'` | **Mandatory**: a true/false conclusion must satisfy "**Lean has passed**" or "**the blocking reason has been explicitly recorded**", otherwise this adjudication **does not take effect** — it is recorded as undecided (reason `formal-required`), written into the "formalization TODO", announced in the group chat, and the object is kept in the library to be re-proposed after formalization |
-
-> "Explicitly record the blocking reason" in `require` is exactly where **"decide not to do it based on implementation difficulty"** lands: **the decision is the agent's,
-> but the decision must be spoken and auditable**, and silently skipping is not allowed. Related parameters also include `leanCommand` (default `lean`),
-> `leanArgs` (used with `lake env lean`), and `leanTimeoutMs` (default 120s).
-
-### ⚠️ A fidelity defect ≠ the proposition is false (important)
-
-Passing Lean only guarantees that "this piece of code passed the kernel"; it **does not guarantee that it says what the proposition means to say**. So when a voter, checking item by item,
-finds that the Lean code and the original text of the proposition are inconsistent (written too narrowly / too broadly / a different object / a missing condition):
-
-- **Do not vote 0.** Voting 0 means "**the proposition is false**"; an incorrectly written formalization would make the framework record "the formalization does not qualify"
-  as "the proposition was disproved", and under v5's all-0 consistency rule it would even write the proposition into `Verified/` marked **false** —
-  a mechanism meant for truth-seeking would instead **fabricate a wrong negative conclusion**.
-- The correct approach: give a value strictly between 0 and 1 (recorded as an abstention) + use the receipt
-  `formal:{decision:'defect', note:'<specific deviation>'}` to record the deviation. The framework then **revokes the "passed" state of this proof**
-  (downgraded to `attempted`; `Verified/Lean/<id>.lean` is **deleted**, and if the host cannot delete it, it is rewritten as a "withdrawn" note,
-  never leaving a withdrawn proof in the place where everyone looks for proofs; and it is written into the "formalization TODO"), and under the `require` setting
-  **this adjudication is not concluded** (the `encourage` setting has no gate, so you must not claim that the framework will force a shelving — there it relies on voters abstaining to prevent a conclusion);
-  vote again only after fixing the formalization and getting it to run through.
-- Vote 0 only when the voter, **independently of this Lean code**, can also determine that the proposition is false (and can give independent reasons).
-
-> **Receipt channel** (members who do not call the Lean tools can also leave a judgment; it is mandatory under the `require` setting):
-> `"formal": {"target":"<object id>", "decision":"used|blocked|defect", "file":"Formal/<object id>.lean", "note":"difficulty judgment/blocking reason/specific deviation"}`.
-> When `decision='blocked'`/`'defect'`, **`note` is required** (if missing, the whole entry is rejected); `used` only records the object as `attempted`;
-> under the `off` setting this channel **is disabled** (otherwise `off` would not be a true no-op).
-
-> Three further hard requirements injected into the prompt (contract §6): tool names are always given in **full** (`<prefix>lean_archive`, not
-> `lean_archive` — an abbreviation is not a registered name, and an agent copying it would call a nonexistent tool); before archiving a reusable definition/lemma, **run it through first** —
-> if it does not run through, it must not enter the library; when the **toolchain is missing** (`LEAN_NOT_FOUND` cannot resolve the executable / `NO_SUBPROCESS` the host has no
-> subprocess service), write the code down, archive it, and state "the host has no Lean toolchain" in `note` — this counts as an explicit blocking reason,
-> and the gate lets it through on that basis, so it will not stall just because Lean cannot be installed.
-
-### Archive: where formalized code goes
+- **The five tools (one set per architecture, prefix following each one's naming)**: `<prefix>_lean_run` executes Lean on the host `subprocess` service (with `leanAsync=true` it enqueues and returns `{async:{jobId,state}}`; otherwise it returns `{ok, exitCode, ms, stdout, stderr}` synchronously) and **never throws** (missing toolchain → `LEAN_NOT_FOUND`, timeout → `LEAN_TIMEOUT`, path escape → rejected); `<prefix>_lean_archive`: `kind='def'/'lemma'` archives into the **cross-project** `Formal/Lib|Proved` (identical content is deduplicated), `kind='proof'` writes `Formal/<target>.lean` and **only a `settled(ok)` job** writes `Verified/Lean/<target>.lean` and marks the object Lean-passed, `kind='blocked'` records an explicit difficulty judgment/blocking reason (**reason required**); `<prefix>_lean_lib` rebuilds and returns the three indexes, the per-object status and the background jobs — **check for duplicates and reuse before writing a new definition**; `<prefix>_lean_read` reads one archived file back verbatim (only `Formal/Lib|Proved`, 64KB cap); `<prefix>_lean_job` inspects or waits for a background compile (read-only). For example, v5 is `vibe_v5_lean_*`, v2/v3 are `vibe_math_lean_*`, and v4 is `vibe_v4_lean_*` (each with run / archive / lib / read / job).
+- **Boundaries (intentional)**: the framework **does not bundle Lean** (no toolchain installation, no dependency downloads; when the toolchain is missing it degrades gracefully and records this faithfully); it **does not judge fidelity** (that is what agents/humans review and vote on; the framework is only responsible for **switching** the focus of review to fidelity); **Lean passing ≠ the proposition is true** — it only means "this piece of formalized code passed the kernel check".
 
-```
-<VibeMath root>/
-├─ Formal/                              # ★ cross-project reusable library (shared by the four architectures)
-│   ├─ Lib/<name>.lean                  # reusable definitions / objects / assumptions (def / structure / notation)
-│   ├─ Lib/Index.md                     # name → file → category → summary (check here before writing a new definition)
-│   ├─ Proved/<name>.lean               # established Lean propositions / lemmas (already machine-checked)
-│   └─ Proved/Index.md
-└─ Projects/<project>/                  # (in v5, Projects/<project>/Institutes/<institute>/)
-    ├─ Formal/
-    │   ├─ <object id>.lean              # formalization working file for this object
-    │   ├─ Index.md                      # object → status → file → archived proof → run result → difficulty judgment
-    │   └─ TODO.md                       # the "formalization TODO" under require mode
-    └─ Verified/
-        ├─ <original conclusion card>
-        └─ Lean/<object id>.lean            # ★ archived proof: the formalized code corresponding to this conclusion object
-```
-
-### Tools (three per architecture, prefix following each one's naming)
-
-| Tool | Purpose |
-|---|---|
-| `<prefix>_lean_run` | Execute Lean on the host `subprocess` service, returning `{ok, exitCode, ms, stdout, stderr}`. **Never throws**: missing toolchain → `LEAN_NOT_FOUND`, timeout → `LEAN_TIMEOUT`, path escape → rejected |
-| `<prefix>_lean_archive` | `kind='def'/'lemma'` → archive to the **cross-project** `Formal/Lib` or `Formal/Proved`; `kind='proof'` → write `Formal/<target>.lean`, and if it runs through, also write **`Verified/Lean/<target>.lean`** and mark the object as Lean-passed; `kind='blocked'` → record an explicit difficulty judgment/blocking reason (**reason required**) |
-| `<prefix>_lean_lib` | Rebuild and return the three indexes and the per-object formalization status — **check for duplicates and reuse directly before writing a new definition** |
-
-For example, v5 is `vibe_v5_lean_run` / `vibe_v5_lean_archive` / `vibe_v5_lean_lib`, v2/v3 are `vibe_math_lean_*`, and v4 is `vibe_v4_lean_*`.
-
-**Boundaries (intentional)**: the framework **does not bundle Lean** (it does not install a toolchain or download dependencies; when the toolchain is missing it degrades gracefully and records this faithfully);
-the framework **does not judge fidelity** (that is what agents/humans review and vote on; the framework is only responsible for **switching** the focus of review to fidelity);
-**Lean passing ≠ the proposition is true** — it only means "this piece of formalized code passed the kernel check".
-
-For the complete contract (parameters, paths, state transitions, prompt semantics, gate locations, index format, test requirements), see
-[`docs/formal-verification.md`](docs/formal-verification.md).
-
-> **The personas of all four presets (the prompt the main agent receives) fully list the three tools and four parameters above**,
-> and the two blocks `prefix` and `text` are identical line by line (only line 0 may differ). This layer is guarded by
-> [`audit-persona-surface.test.mjs`](tests/audit-persona-surface.test.mjs) and
-> [`audit-persona-sensitivity.mjs`](tests/audit-persona-sensitivity.mjs) — when this feature was added, it was precisely
-> in the four presets that the defect "the tools were registered but the persona never listed them" was found (the same batch also found that the persona listed two
-> tools for adding/removing resident researchers too few, and that the `/v4`/`/v5` subcommand lists were inconsistent with the implementation; see the release notes shipped with the package).
+For the complete contract (parameters, paths, state transitions, prompt semantics, gate locations, index format, test requirements), see [`docs/formal-verification.md`](docs/formal-verification.md). The personas (the prompt the main agent receives) of all four presets fully list these five tools and eight parameters, and the `prefix` and `text` blocks are identical line by line (only line 0 may differ); this layer is guarded by [`audit-persona-surface.test.mjs`](tests/audit-persona-surface.test.mjs) and [`audit-persona-sensitivity.mjs`](tests/audit-persona-sensitivity.mjs) — when this feature was added, it was precisely in the four presets that the defect "the tools were registered but the persona never listed them" was found (see the release notes shipped with the package).
 
 ---
 
@@ -425,124 +251,80 @@ choose v3 if you prefer paper-style md, the planner agent and the theory inventi
 
 ---
 
-## 🧠 Architecture and Division of Labor (v3 · third generation) · classic
+## 🧠 Architecture and division of labour (all four in parallel)
 
-The framework = **one main agent (assistant) + one code scheduler + one planner agent + six kinds of subagents**.
+### V2 (probability-driven · classic)
 
-| Role | Type | Responsibility |
-|---|---|---|
-| **Main agent** | LLM (the assistant in the session) | **Natural-language interface + reporter + assistant**. It **does not solve or schedule on its own**; it is only responsible for: translating your words into `vibe_math_*` tool calls, reporting progress, configuring parameters in Q&A form, and executing control commands. |
-| **Scheduler** | Plugin code (not a model) | The sole master control: maintains the md knowledge base index, builds the state brief, **validates and executes the planner agent's plan**, writes files, and advances the state machine. **Hard constraints (concurrency / idempotency / already-verified is never scheduled again / write ownership) are enforced by code**. |
-| **Planner (planner agent)** 🆕 | Subagent | Each time a dispatch is being prepared, it reads the state brief (problem + dependencies + survival rate, verifiable objects, active agents, concurrency budget, available methods, result of the last plan) and **autonomously chooses the optimal scheduling scheme, arranging the next N steps in one go** (spawn/continue/interrupt/promote/verify/method-keep/wait). It outputs a JSON plan, which the scheduler validates before executing; on failure it automatically falls back to heuristics. |
-| **Explorer subagent** | Subagent | Metacognitive brainstorming: constraint decomposition, boundary testing, similar-problem mapping, splitting the problem into multiple "widely divergent" solution directions (if all are dead ends, re-derive). Before starting work it first checks the `Methods/` method library. |
-| **Solver subagent** | Subagent | One dedicated solver per direction, **multiple iteration rounds within the same session**, producing lemmas (with proofs), sub-routes, survival probability, and a complete solution, and **reporting `methods_used` and `new_inventions`** (methods/tools/ideas newly invented in this round). |
-| **Verifier subagent** | Subagent | Each verification object gets ≥3 independent "harsh reviewers": independent review → debate (chat group) → **near-consensus verdict** (if on the same side with mean ≥0.85/≤0.15, take the mean; otherwise flat/forced). |
-| **Method Keeper (method-organizing agent)** 🆕 | Subagent | Periodically digests recent work and new-invention reports, **distills new method cards, merges fragments, improves the system structure (parent system/sub-methods), maintains trusted assertions**, and deposits the theories/frameworks/tools/methods/ideas invented during solving into the `Methods/` general theory invention library. |
+The framework = **main agent + code scheduler + explorer / solver / verifier subagents**. The scheduler is the sole master control and the sole file writer (subagents only return structured JSON and never write files); it decides the next step by **code heuristics** over "correctness probability + value/criticality + priority"; each verification object goes to ≥3 independent "harsh reviewers" for review → debate → adjudication (a solution/proof reaching probability `1` closes it; `never` is never scheduled). **Pick it** if you prefer structured JSON (`qs.json` / `Propos/`) and predictable, deterministic scheduling that does not depend on a planner agent.
 
-> Division of labor in one sentence: **the main agent handles "talking to people", the planner agent handles "setting the plan", the scheduler handles "execution and boundary-keeping", subagents handle "thinking", and the Method Keeper handles "depositing inventions into theory".**
+> Division of labour in one sentence: **the main agent handles "talking to people", the scheduler handles "execution and boundary-keeping", and the subagents handle "thinking".**
 
-### Architecture and Division of Labor (v4 / v5)
+### V3 (paper-style md + planner agent + method library) · classic
 
-| | **v4 (resident self-organization)** | **v5 (institute system)** |
-|---|---|---|
-| Principal | N resident subagents (continuable) | academicians + resident researchers + temp workers (all continuable subagents) |
-| Who assigns tasks | **No one**: emerges on its own through mutual messages and meetings | **academicians** (institute members, equally bound by the voting rules); the framework still does not assign |
-| Who judges | Each on its own; a conclusion is reached only when all agree | Each on its own; a conclusion is reached only on **≥ m voting members in boolean agreement** |
-| Coordination mechanism | messages + meetings | messages + meetings (strictly mutually exclusive with verification) + **compare-and-set task board** |
-| Roster | resident, can be spawned/closed | **can grow and shrink**: resident researchers are hired with the institute office's approval; temp workers are hired and fired autonomously by academicians/researchers |
-| State | `State/*.json` written directly | **`State/<institute>.v5state.json` hardened JSON** (zero token cost, serial writes, a mandatory load before read) |
+The framework = **main agent + code scheduler + planner agent + explorer / solver / verifier / method-keeper subagents**. Each time a dispatch is prepared, the **planner agent** reads the state brief (problem dependencies, survival rate, verifiable objects, concurrency budget, result of the last plan) and **autonomously draws up an N-step plan**, which the scheduler validates before executing (falling back to heuristics on failure); theories/frameworks/tools/methods/ideas invented during solving are reported via `methods_used`/`new_inventions` and distilled by the **Method Keeper** into new method cards in the `Methods/` general theory invention library. **Pick it** if you prefer a paper-style md knowledge base, want more flexible scheduling, and want a systematizable, cross-project method library.
+
+> Division of labour in one sentence: **the main agent handles "talking to people", the planner agent handles "setting the plan", the scheduler handles "execution and boundary-keeping", the subagents handle "thinking", and the Method Keeper handles "depositing inventions into theory".**
+
+### V4 (resident self-organization · experimental)
 
-For the complete v5 architecture (including member lifecycle, one-round timeline, consensus state machine, meeting flow, scheduling priority, state folding, prompt composition, task board, authority matrix), see [the v5 detail diagrams](vibe-math-v5/架构图.md); for the textual specification see
-[the v5 specification](vibe-math-v5/实现方案.md).
+The principal is **N persistent resident subagents** (continuable): **there is no central scheduling and no leader** — task arrangements emerge from residents **messaging each other + holding meetings** (the framework only provides the message bus/meetings/task board and never assigns); each accumulates its own `Progress/Propos/Methods/Subproblems` library **owned by resident id** and may read the others'; verification is written to `Verified/` **only when all residents agree (true or false)**, otherwise it stays in the library with a probability; when the context reaches a threshold it automatically `/compact`s; it stops **only when all agree that the original problem is solved** (`vibe_v4_resume` resumes from a checkpoint). **Pick it** if you want fully self-organizing research and can accept the strict "unanimity before a conclusion" threshold.
+
+### V5 (institute system · experimental · latest)
+
+It upgrades v4's residents into an **institute**: **academician** (leader / organizing and coordinating centre: decomposition, **assignment**, prioritization, chairing meetings, supervising progress) + **resident researchers** (voting rights, may autonomously hire/fire their own temp workers) + **temp workers** (no voting rights); **the framework still only relays, keeps the task board, holds meetings and counts — it never assigns tasks**. The conclusion threshold is **≥ m = min(`quorumCap`, number of enrolled voting members) boolean-consistent votes** (opposing votes block; abstentions do not count as votes but count toward the average; below the threshold the object stays in the library with its average probability); state lives in `State/<institute>.v5state.json` (zero token cost); meetings and verification are strictly mutually exclusive. **Pick it** if you want "organized self-organization", a roster that can grow or shrink, and an adjustable threshold.
+
+For the complete v5 architecture (member lifecycle, one-round timeline, consensus state machine, meeting flow, scheduling priority, state folding, prompt composition, task board, authority matrix), see [the v5 detail diagrams](vibe-math-v5/架构图.md); for the textual specification see [the v5 specification](vibe-math-v5/实现方案.md).
 
 ---
 
 
 ## 📁 Directory Structure
 
+> Only the **top-level and high-value paths** are listed; for the full meaning of every file see each preset's `实现方案.md` ([v2](vibe-math-v2/实现方案.md) · [v3](vibe-math-v3/实现方案.md) · [v4](vibe-math-v4/实现方案.md) · [v5](vibe-math-v5/实现方案.md)) and [the v5 detail diagrams](vibe-math-v5/架构图.md).
+
 ### v2 (probability-driven · classic)
 
 ```
-<session workspace>/VibeMath/
-├─ current.json                        # current project
-├─ vibe_math_setting.json             # (optional, global fallback) default parameters JSONC, with comments
-└─ Projects/<project>/
-   ├─ vibe_math_setting.json          # default parameters for this project
-   ├─ qs/qs.json                       # problem list: overview/solved/solution list (complete solution · correctness probability)/priority/progress
-   ├─ Propos/<category>_Propos.json        # proposition library: overview/boolean estimate/fine type/proof·disproof list/priority/value·criticality/progress
-   ├─ Reliable/                        # trusted references (read-only, placed by the user)
-   ├─ Verified/                        # concluded-fact index (propositions with boolean estimate = 0/1)
-   ├─ Verification_logs/               # debate record of each verification round (for auditing)
-   ├─ Progress_Logs/                   # periodic progress reports report.json
-   └─ VibeMath_State/                  # scheduler-private persistent state (for checkpoint resume)
+<VibeMath>/Projects/<project>/
+├─ qs/qs.json                   # problem list (overview/solved/solutions + correctness probability/priority)
+├─ Propos/<category>_Propos.json # proposition library (boolean estimate/proof·disproof/value·criticality)
+├─ Verified/                    # concluded-fact index
+├─ Reliable/                    # trusted references (read-only, placed by the user)
+└─ VibeMath_State/              # scheduler-private persistent state (for checkpoint resume)
 ```
 
 ### v3 (paper-style md + planner agent + method library) · classic
 
 ```
-<session workspace>/VibeMath/
-├─ Methods/                            # [global] cross-project general theory invention library (v3, promoted from project level)
-├─ Formal/                             # object formalization workspace: Lib/ (reusable definitions) and Proved/ (proved lemmas)
-├─ current.<session id>.json               # current project per session (parallel sessions do not overwrite each other)
-├─ vibe_math_setting.json             # (optional, global fallback) default parameters JSONC, with comments
+<VibeMath>/
+├─ Methods/                     # [global] cross-project general theory invention library (promoted from project level)
+├─ Formal/{Lib,Proved}/         # cross-project reusable definitions / proved lemmas (Lean)
 └─ Projects/<project>/
-   ├─ vibe_math_setting.json          # default parameters for this project
-   ├─ Problems/<id>.md                 # problem list: one md per problem (soft-spec anchor: ID/type/status/priority/dependencies/dependents/source/plan
-   │                                   #   + ## statement / ## source and motivation (later-born problems: generation flow/motivation/backfill plan) / ## solution candidates)
-   ├─ Progress/<id>.md                 # aggregated research log index (per-direction summaries + lemma index + per-round records)
-   ├─ Progress/<id>/<direction id>.md         # one independent file per direction (written directly by self-organizing agents, no cross-direction concurrency conflict)
-   ├─ Propos/<category>/<id>.md            # proposition library: one md per proposition (statement/proof attempts/disproof attempts, soft-spec anchor + free narrative)
-   ├─ Methods/<id>.md                  # [general theory invention library] method card: theoretical system/framework/tool/method/idea (with application records/improvement history/system hierarchy)
-   ├─ Verified/命题/<id>.md            # absolutely trusted: scheduler-generated verified proposition cards (read-only)
-   ├─ Verified/问题/<id>.md            # absolutely trusted: complete trusted solution cards for solved problems (read-only)
-   ├─ Reliable/                        # trusted references (read-only, placed by the user)
-   ├─ Notes/                           # free notes (not involved in scheduling)
-   ├─ Logs/Verification/               # debate record of each verification round (for auditing)
-   ├─ Logs/Plans/                      # each scheduling plan + execution result (planner learning loop)
-   ├─ Logs/报告.md                     # paper-style human-readable progress report
-   └─ State/                           # scheduler-private persistent state (agents/tasks/plans/verifier_accuracy/index/project lock/process epoch)
+   ├─ Problems/ Progress/ Propos/ Methods/     # paper-style md knowledge base (soft-spec anchors + free narration)
+   ├─ Verified/{命题,问题}/                      # absolutely trusted (read-only)
+   ├─ Logs/{Verification,Plans}/  Logs/报告.md   # debate records / scheduling plans / paper-style progress report
+   └─ State/                                     # index, project lock, process epoch
 ```
 
-**Iron rule (v2 general)**: the scheduler is the **sole file writer** (subagents only return structured JSON and never write files).
-**v3 iron rule**: only `Verified/` and objects judged true/false by the verifier are **absolutely trusted**; all other md (unconcluded propositions, research logs, unverified assertions in the method library) serve only as experiential reference; the scheduler parses only soft-spec anchor lines and entry title lines, and never parses body prose. **v3 allows agents to write md directly** (self-organizing agents locate their own files, e.g. a solver writes `Progress/<id>/<direction id>.md`, a new lemma is written to `Propos/<category>/<id>.md`, and the method-organizing agent writes `Methods/<id>.md`); concurrency safety relies on **write locks** — before writing any file call `vibe_math_claim_write`, after writing call `vibe_math_release_write` (only one agent may write a given file at a time); the content stays in the md, and lightweight metadata is reported to the scheduler via `vibe_math_sync_meta`.
-
-### v5 (institute system · experimental)
+### v4 / v5 (resident self-organization / institute system · experimental)
 
 ```
-<session workspace>/VibeMath/Projects/<project>/Institutes/<institute>/
-├─ Institutes.md                 # roster mirror (human-readable snapshot: codename/position/status/employer/direction/round/context%)
-├─ Problems/<id>.md              # original problem
-├─ Problems/conclusion.md        # conclusion record (generated when all those with voting rights agree it is solved)
-├─ Members/<codename>/
-│   ├─ Progress/progress.md      # research log (narrative, appendable; the main basis for restoring state after compaction)
-│   ├─ Propos/<id>.md            # proposition (with proof attempts/disproof attempts)
-│   ├─ Methods/<id>.md           # method / theory / tool (with definition notation/application records/improvement history)
-│   └─ Subproblems/<id>.md       # subproblem
-├─ Shared/
-│   ├─ Chat/<date>.md            # group chat record (including institute founding/hiring/firing/meetings/votes/conclusion announcements)
-│   ├─ Meetings/<mt-id>.md       # meeting minutes (each member's speech + vote subsection)
-│   ├─ Debates/<object>.md         # debate record (each round's votes and reasons + whole-group mean probability)
-│   ├─ TaskBoard.md              # task board mirror
-│   └─ State-of-institute.md     # snapshot of members' judgment on "whether it is solved"
-├─ Verified/<type>/<id>.md       # conclusions (read-only; only these may be treated as established)
-└─ State/
-    ├─ README.md                 # explains that "the files here are mirrors — do not hand-edit them"
-    └─ <institute>.v5state.json      # the authoritative state (hardened JSON, serial writes, a mandatory load before read)
+<VibeMath>/Projects/<project>/
+├─ Progress|Propos|Methods|Subproblems/<resident id>/   # v4: owned by resident id
+└─ Institutes/<institute>/                               # v5
+   ├─ Members/<codename>/{Progress,Propos,Methods,Subproblems}/
+   ├─ Shared/{Chat,Meetings,Debates}/  Shared/TaskBoard.md  Institutes.md
+   ├─ Verified/<type>/<id>.md                      # conclusions (read-only)
+   └─ State/<institute>.v5state.json               # ★ authoritative state (hardened JSON, serial writes, mandatory load before read)
 ```
 
-> Enabling Lean formal verification adds two more directories: this institute's `Formal/` (working files + index + formalization todos) and `Verified/Lean/`
-> (**archived proofs**), plus the **cross-project** `<VibeMath root>/Formal/{Lib,Proved}/` (reusable definitions and already-proved lemmas) — see
-> the "Lean formal verification" section above.
-
-**v5 iron rules**: ① the authoritative state is written only to `State/<institute>.v5state.json` (hardened JSON, serial writes, a mandatory load before read);
-in the table above, every other file is merely a **mirror/workspace**, and breaking it by hand-editing will not destroy the institute;
-② members **write only their own library** (`Members/<own codename>/`), but may read anyone's library;
-③ only `Verified/` and cards marked "verified·true/false" are **absolutely trusted**; everything else (including unverified assertions in `Methods/`) is merely experiential reference,
-and citations must be marked "unverified"; ④ entry into the library must state all three of **degree of value / motivation-purpose plan / own probability estimate**, none may be omitted.
+**Iron rules (all four)**: the v2/v3 scheduler is the **sole file writer** (v3 also lets agents write md directly, with `vibe_math_claim_write`/`vibe_math_release_write` guaranteeing that only one writer touches a file at a time); only `Verified/` and cards marked "verified·true/false" are **absolutely trusted**, and all other md (including unverified assertions in `Methods/`) is merely experiential reference; in v5 the authoritative state is written only to `State/<institute>.v5state.json`, every other file above is only a **mirror/workspace** (hand-editing it will not break the institute), members **write only their own library**, and an entry must state **degree of value / motivation-purpose plan / own probability estimate**. With Lean enabled there are additionally the institute's `Formal/` (working files + index + formalization TODO) and `Verified/Lean/` (archived proofs), plus the **cross-project** `<VibeMath root>/Formal/{Lib,Proved}/` — see the "Lean formal verification" section above.
 
 ---
 
-## ⚡ Quick Start
+## ⚡ Start in five minutes
+
+> One main line: **start in plain language → ask about progress at any time → (optionally) tune parameters / intervene → wrap up**. At closure all four presets **produce a final paper by default** (`Paper/<id>/`, see "Features" above and [`docs/final-paper.md`](docs/final-paper.md)). Pick whichever of the three usages below you like; you do not need to read them all.
 
 ### Method A: Direct conversation (recommended, the least effort)
 
@@ -588,11 +370,9 @@ Call the tools directly in the conversation (arguments are JSON):
 
 Slash commands (equivalent to the tools): `/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` (v3 additionally has `methods|index|plan|lock`)
 
----
-
-## 🎓 Tutorial: Let the Main Agent Do the Work for You
+### 🎓 Let the main agent do the work for you (no need to memorize commands)
 
-### 1. Natural-language driven (no need to memorize commands)
+#### 1. Natural-language driven (no need to memorize commands)
 
 The main agent's role is to be your "translator". You only need to describe the **goal**, and it will choose and call the tools itself:
 
@@ -605,7 +385,7 @@ The main agent's role is to be your "translator". You only need to describe the
 | “Give one of q1's directions a new angle (e.g. turn it into a constructive proof)” | `list_agents` to find the childId → `message_agent` to inject new instructions |
 | “Interrupt a stuck subagent” | `interrupt_agent` |
 
-### 2. Q&A-style parameter configuration (/vibe setup)
+#### 2. Q&A-style parameter configuration (/vibe setup)
 
 You do not even need to remember parameter names. Say:
 
@@ -619,7 +399,7 @@ and finally ask whether to save them as defaults with `vibe_math_save_settings`.
 
 You can also just run the command: `/vibe setup` (view the schema) → tell the main agent which ones you want to change → `/vibe save` (save as defaults).
 
-### 3. Configuration file (vibe_math_setting.json)
+#### 3. Configuration file (vibe_math_setting.json)
 
 - **Generate a template**: `/vibe template` (generated into the workspace) or `/vibe template project` (generated into the current project) —
   it produces a JSON template **with `//` comments and an item-by-item Chinese description**; after you edit it by hand, restart/resume to take effect.
@@ -627,9 +407,7 @@ You can also just run the command: `/vibe setup` (view the schema) → tell the
 - **The only persistent source**: that file is the **only persistence layer** for parameters (project level takes precedence → when missing, fall back to the global `<workspace>/VibeMath/vibe_math_setting.json` → built-in defaults).
   `vibe_math_set_params` / `set_mode` **write back immediately** to the project-level file and persist, so no manual save is needed.
 
----
-
-## 🌱 Beginner example walkthrough (using “prove √2 is irrational” as the example)
+### 🌱 Complete example: prove √2 is irrational
 
 **Step 1 — Start with one sentence**
 
@@ -677,9 +455,11 @@ The main agent `vibe_math_status`: in `qs/qs.json`, `q1` has been written back w
 
 > v2 writes no CSV at all: solved problems live in `qs/qs.json`, and `Verified/<category>_Verified.json` is the resolved-fact index (a solution with `正确概率 = 1` closes its problem; a proof or disproof with `正确概率 = 1` sets the proposition estimate to `1`/`0`).
 
----
+**Step 6 — the final paper is produced automatically at closure (on by default)**
+
+All four presets default to `finalPaper=true`: once the respective closure signal fires, the paper phase starts **before the run is marked complete** (in v2/v3 a dedicated "paper writer" subagent organises the existing evidence; in v4/v5 the team co-authors, cross-reviews, and the editor finalises on unanimous agreement). The artifacts are `Paper/<id>/{paper.md,paper.tex,paper.pdf,paper.meta.json,paper.log.md}`: `paper.tex` / `paper.pdf` are produced only when `paperFormat` includes tex and the host detects a LaTeX engine (`xelatex` preferred for Chinese; with no engine only md/tex are delivered, and the wrap-up is never blocked). Trigger it manually with `/vibe paper` (v2/v3), `/v4 paper` or `/v5 paper`, optionally with `lang=` / `format=` / `editor=` / `force`; the full contract is in [`docs/final-paper.md`](docs/final-paper.md).
 
-## 🖼️ Real usage example (long screenshot)
+### 🖼️ Real usage example (long screenshot)
 
 > The screenshot is very long, so it is **collapsed** by default here: the full long image is loaded only after you click “Expand” below, so that it does not fill the page and block the surrounding text.
 
@@ -694,54 +474,89 @@ The main agent `vibe_math_status`: in `qs/qs.json`, `q1` has been written back w
 
 ## ⚙️ Parameter quick reference
 
-### v2 (probability-driven · classic) defaults
+### Shared parameters (accepted by ≥2 presets)
 
-| Parameter | Default | Description |
-|---|---|---|
-| `mode` | `auto` | `auto` / `manual` |
-| `maxParallelThreshold` | 4 | Global maximum number of concurrent subagent rounds (before a new dispatch, active must be < threshold) |
-| `solverMaxRounds` | 3 | Maximum number of iteration rounds per solving direction (agent_self_iteration cap) |
-| `directionsPerSolver` | 1 | Total number of directions visible to each solver prompt (1 = only its own direction, no mutual interference; N>1 = its own plus summaries of up to N-1 other active directions) |
-| `verifierCount` | 3 | Number of independent verifiers per verification target |
-| `debateMaxRounds` | 5 | Maximum number of rounds of verification debate (chat group) |
-| `verdictMode` | `flat` | `flat` = the **equal-weight mean** of the probabilities the verifiers report (an inconsistency is no longer judged 0.5) / `forced` = forced verdict (weighted by historical accuracy + rigor; accuracy is tracked per model and scored only when the object later receives a boolean verdict) |
-| `reportMode` | `file` | `file` = write a report file / `push` = push a report to the main agent / `both` |
-| `promoteValueThreshold` | 0.7 | A proposition in Propos with "value/criticality" ≥ this value and undecided (0,1) is automatically added to qs.json |
-| `priorityAdjust` | `none` | `none` / `deadend-deprioritize` (deprioritize all dead ends) / `survival-map` (recompute by survival rate) |
-| `proposPriorityAdjust` | `none` | Dynamic adjustment of proposition priority: `none` / `progress-graded` (recompute by proximity to a conclusion + amount of proof/disproof material; the closer to a conclusion, the higher the priority for verification) |
-| `provider` / `model` | empty | Subagent model (empty = inherit the root agent) |
-| `solverPersona` / `verifierPersona` / `explorerPersona` | empty | Persona/requirements injected at the start of the solver/verifier/explorer prompt |
-| `knowledgeContext` | empty | Shared knowledge/data model description (empty = built-in full version: object/attribute definitions, probability semantics, folder purposes, output completeness requirements; non-empty = overrides and is injected into all subagent prompts) |
-| `solverToolAllow` / `solverToolDeny` | `[]` | Tools allowed/denied for the solver |
-| `verifierToolAllow` / `verifierToolDeny` | `[]` | Tools allowed/denied for the verifier |
-| `solverAllowNetwork` / `verifierAllowNetwork` | empty | Network tool switch (web_search/web/fetch): empty = inherit everything; `true` = add to the existing allow list when one is present; `false` = deny |
-| `solverAllowScripts` / `verifierAllowScripts` | empty | Script tool switch (bash/pwsh): same as above |
-| `solverMaxToolCalls` / `verifierMaxToolCalls` | 0 | Maximum external tool calls per round (0 = unlimited) |
-| `reportIntervalMs` | 0 | 0 = event-driven only (write/push only when there is a state update); >0 = timed automatic reporting (milliseconds) |
-| `tickIntervalMs` | 2000 | Scheduler heartbeat interval (milliseconds) |
-| `activityLogCap` | 100 | Number of activity log entries retained (the report displays at most 30) |
-| `maxExplorerRetries` | 3 | Upper limit on re-dispatching after an explorer fails to split directions |
-| `formalVerify` | `'off'` | **Lean formal verification switch**: `'off'` no additional requirement (default)｜`'encourage'` encouraged (during verification, decide for yourself whether to formalize based on implementation difficulty)｜`'require'` mandatory (a true/false conclusion must first have a "Lean passed" or an explicit blocking record, otherwise it is recorded as undecided and enters the formalization todo list). Any illegal value falls back to `'off'` |
-| `leanCommand` | `'lean'` | The Lean executable to run (e.g. `'lake'`) |
-| `leanArgs` | `[]` | Additional arguments inserted before the file name (e.g. `['env','lean']` together with `leanCommand='lake'`) |
-| `leanTimeoutMs` | `120000` | Upper limit for a single Lean run (milliseconds) |
-| `finalPaper` | `true` | **Final paper**: written automatically at closure (`false` disables only the automatic trigger; the manual command still works). Full contract: `docs/final-paper.md` |
-| `paperFormat` | `both` | Which text versions to produce: `both` (md+tex) / `md` (skips compilation and must not warn about a missing tex) / `tex` |
-| `paperLanguage` | `zh` | Paper language: `zh` (ctexart, engine prefers xelatex) / `en` (article, pdflatex first) |
-| `paperCompilePdf` | `true` | Compile `paper.pdf` when a LaTeX engine is detected; with no engine or a failed compile, tex+md are still delivered and a warning is logged |
-| `paperLatexCommand` | `''` | Force one LaTeX engine executable (empty = auto-detect per language: xelatex→latexmk→pdflatex→lualatex→tectonic) |
+> Each preset's **complete parameter set = every row of this table whose "Applies to" column names that preset ∪ that preset's own preset-specific table** (v2 has no preset-specific parameters).
+> For parameter details and gate locations see [`docs/formal-verification.md`](docs/formal-verification.md) and [`docs/final-paper.md`](docs/final-paper.md).
+
+| Parameter | Default | Applies to | Description (including per-preset differences) |
+|---|---|---|---|
+| `mode` | `auto` | v2·v3 | `auto` / `manual` (manual suspends decisions at key nodes and waits for your approve/reject/override) |
+| `maxParallelThreshold` | 4 | v2·v3 | Global maximum number of concurrent subagent rounds (before a new dispatch, active must be < threshold) |
+| `solverMaxRounds` | 3 | v2·v3 | Maximum number of iteration rounds per solving direction (agent_self_iteration cap) |
+| `directionsPerSolver` | 1 | v2·v3 | Total number of directions visible to each solver prompt (1 = only its own direction, no mutual interference; N>1 = its own plus summaries of up to N-1 other active directions) |
+| `verifierCount` | 3 | v2·v3 | Number of independent verifiers per verification target |
+| `debateMaxRounds` | 5 | v2·v3 | Maximum number of rounds of verification debate (chat group) |
+| `verdictMode` | v2 `flat`; v3 `forced` | v2·v3 | **The default differs per preset.** v2 `flat` = the **equal-weight mean** of the probabilities the verifiers report (an inconsistency is no longer judged 0.5); v2 `forced` = forced verdict (weighted by historical accuracy + rigor; accuracy is tracked per model and scored only when the object later receives a boolean verdict). v3 `forced` = first a **near-consensus determination** (all results on the same side with a mean ≥0.85/≤0.15 takes the mean — this runs BEFORE the mode, so 0.9 vs 1 yields ≈0.95 in either mode), otherwise the **equal-weight mean** of the reported probabilities (no accuracy weighting; strict 1/0 still act as absolute votes), while `flat` rules `0.5` (a disagreement is undecided) |
+| `reportMode` | `file` | v2·v3 | `file` = write a report file / `push` = push a report to the main agent / `both` |
+| `promoteValueThreshold` | 0.7 | v2·v3 | A proposition in Propos with "value/criticality" ≥ this value and undecided (0,1) is automatically added to qs.json |
+| `priorityAdjust` | `none` | v2·v3 | `none` / `deadend-deprioritize` (deprioritize all dead ends) / `survival-map` (recompute by survival rate) |
+| `proposPriorityAdjust` | `none` | v2·v3 | Dynamic adjustment of proposition priority: `none` / `progress-graded` (recompute by proximity to a conclusion + amount of proof/disproof material; the closer to a conclusion, the higher the priority for verification) |
+| `provider` / `model` | empty | all four | Model route (empty = inherit the root agent). **Per preset**: v2/v3 = subagent model (v3's planner agent has its own `plannerProvider`/`plannerModel` in the preset-specific table); v4 = **resident LLM route** (previously declared but unused, actually wired up in v1.4.1); v5 = member LLM route (empty = inherit the institute office/main agent route) |
+| `solverPersona` / `verifierPersona` / `explorerPersona` | empty | v2·v3 | Persona/requirements injected at the start of the solver/verifier/explorer prompt |
+| `knowledgeContext` | empty | v2·v3 | Shared knowledge/data model description (empty = built-in full version: object/attribute definitions, probability semantics, folder purposes, output completeness requirements; non-empty = overrides and is injected into all subagent prompts) |
+| `solverToolAllow` / `solverToolDeny` | `[]` | v2·v3 | Tools allowed/denied for the solver |
+| `verifierToolAllow` / `verifierToolDeny` | `[]` | v2·v3 | Tools allowed/denied for the verifier |
+| `solverAllowNetwork` / `verifierAllowNetwork` | empty | v2·v3 | Network tool switch (web_search/web/fetch): empty = inherit everything; `true` = add to the existing allow list when one is present; `false` = deny |
+| `solverAllowScripts` / `verifierAllowScripts` | empty | v2·v3 | Script tool switch (bash/pwsh): same as above |
+| `solverMaxToolCalls` / `verifierMaxToolCalls` | 0 | v2·v3 | Maximum external tool calls per round (0 = unlimited) |
+| `reportIntervalMs` | 0 | v2·v3 | 0 = event-driven only (write/push only when there is a state update); >0 = timed automatic reporting (milliseconds) |
+| `mathComputation` | `auto` | all four | Math-computation tier: `off` (a true no-op: no probing, no execution, nothing injected into prompts) / `auto` (works once an engine is detected) / `on`. See [`docs/math-computation.md`](docs/math-computation.md) |
+| `mathMode` | `typed+shell` | all four | **Prompt policy only** (the plugin cannot enforce it): `typed+shell` lets the prompt fall back to the host shell when the tool cannot run, but such conclusions must be marked "not tool-archived" and only tool-routed runs count as reproducible supporting material; `typed` never mentions the shell and also disables `engine:'cli'` |
+| `mathEngines` | `[python, r, octave, julia, matlab, maple, wolfram, cli]` | all four | Allowed engines and detection order. The three commercial ones (matlab/maple/wolfram) are detected and licence-checked only and are **never installed**; removing `cli` closes the generic escape hatch |
+| `mathTimeoutMs` | `60000` | all four | Per-run budget in milliseconds (minimum 1000); on timeout the process is terminated |
+| `mathPackages` | `[]` | all four | Packages/toolboxes required by default; a missing one is reported with an install plan - it is **never installed automatically** |
+| `mathInstallScope` | `user` | all four | Install scope; `system` must be given **explicitly on every call and is never remembered** (most managers have no system template, in which case the request is refused) |
+
+> **Archive = evidence**: every run writes `Computation/<id>/` and the receipt carries `scriptPath` + `scriptHash`; the script original may be opened/edited, but after editing you MUST re-run it with `mode:'file'` to get a NEW receipt - **an old receipt does not represent edited code** (`scriptChanged` / `scriptChangedDuringRun` warn explicitly). Archives are append-only and over-cap behaviour is warn-only, never delete. See [`docs/math-computation.md`](docs/math-computation.md) §4.1.
+
+> **Declare substitutions**: when an alternative changes **exactness or conclusion strength** (exact solution -> numerical approximation, closed form -> sampling/quadrature, changed precision/tolerances/assumptions, a different algorithm class), the conclusion MUST say so and must not read as if the original result had been obtained; if the exact result is unavailable, say so plainly (rule line `MATH_SUBSTITUTION_RULE_LINE`, injected into all four personas and prompts).
+
+> **Install and versions**: `op:'install'` dispatches on the **detected python environment** - conda/mamba (`-c conda-forge`), uv (`uv pip …`) or the documented pip fallback (ambiguous cases carry `managerAssumed`); R/Octave/Julia are **user-scope only** (`system` => `MATH_REFUSED` with a per-engine reason). **Version solving belongs to the package manager**: the tool only checks presence by base name and passes `pkg==1.2` (conda `pkg=1.2`) through verbatim; unsafe or unknown syntax => `unsupported-version-syntax`. See [`docs/math-computation.md`](docs/math-computation.md) §5.1-5.3.
+> **Engine discovery**: PATH first, and **only as a last resort** the runtimes DSH ships itself (`<DSH_HOME or user home>/.dsh/dsh-runtimes/*/dependencies/<engine>/`, tree name **globbed**); a found engine reports its **real version** and **no** install guidance is emitted - guidance appears only when nothing usable exists, and it targets **the engine you asked for**. `op:'probe'` reports the requested engine; `mathEngineOverride` **only overrides argv templates and cannot name an executable**, so it is not a discovery escape hatch (use PATH, the DSH runtime, or `engine:'cli'` + `cli.command`). With `engine:'cli'`: the package precheck runs for `cli.command`'s family (unknown family => skipped with a `PACKAGE_PRECHECK_SKIPPED` warning), `mode:'code'` **appends the archived script to argv** (so the code really runs instead of a REPL), and the version is the real one. See §5.4.
+| `tickIntervalMs` | 2000 | v2·v3 | Scheduler heartbeat interval (milliseconds) |
+| `activityLogCap` | 100 | v2·v3 | Number of activity log entries retained (the report displays at most 30) |
+| `maxExplorerRetries` | 3 | v2·v3 | Upper limit on re-dispatching after an explorer fails to split directions |
+| `maxParallel` | 3 | v4·v5 | Upper limit on simultaneously awakened residents (v4) / members (v5) (framework-side concurrency gate, not an assignment) |
+| `activityTimeoutMs` | 120000 | v4·v5 | v4: idle heartbeat interval (only on timeout is a **self-driven** CHECKPOINT wakeup triggered, pushing residents to keep making progress; a failed wakeup automatically re-arms the heartbeat, ensuring the group never permanently stalls); v5: idle fallback heartbeat interval (the main driver is a one-shot activity wait, not polling; the task board's "nudge" is also throttled by it) |
+| `stallAutoMeetingMs` | 360000 | v4·v5 | **Stall auto sync meeting threshold** (tiered keep-alive B): when the team is idle with no new artifacts for longer than this duration, the framework automatically convenes a sync meeting so the members decide the next route/division of labor themselves (the framework only facilitates, it does not assign) |
+| `verdictMaxRounds` | 3 | v4·v5 | Maximum number of rounds of debate (v4) / public debate (v5) after independent initial assessment in verification |
+| `compactThreshold` | 66 | v4·v5 | Context share (0–100) that triggers soft compaction: v4 = resident context share reaching this value triggers soft compaction (self-report instruction); v5 = a member reaching this value triggers compaction (condensing the working state into `Progress/`) |
+| `compactAfterRounds` | 8 | v4·v5 | Trigger one soft compaction every N accumulated rounds (uncompacted) |
+| `meetingKeepEvery` | 5 | v4·v5 | Automatically trigger one sync meeting every N accumulated new artifacts |
+| `toolAllow` / `toolDeny` | `[]` | v4·v5 | **Resident / resident-staff tool permissions** (scoped `tools.restrict()` via `startContinuable`'s `toolFilter`; empty = inherit all tools; ⚠️ an empty `allow:[]` rejects all tools); v5's temp workers have their own `tempToolAllow`/`tempToolDeny` |
+| `formalVerify` | `'off'` | all four | **Lean formal verification switch**: `'off'` no additional requirement (default)｜`'encourage'` encouraged (during verification, decide for yourself whether to formalize based on implementation difficulty)｜`'require'` mandatory (a true/false conclusion must first have a "Lean passed" or an explicit blocking record, otherwise it is recorded as undecided and enters the formalization todo list). Any illegal value falls back to `'off'` |
+| `leanCommand` | `'lean'` | all four | The Lean executable to run (e.g. `'lake'`) |
+| `leanArgs` | `[]` | all four | Additional arguments inserted before the file name (e.g. `['env','lean']` together with `leanCommand='lake'`) |
+| `leanTimeoutMs` | `120000` | all four | Upper limit for a single Lean run (milliseconds); the async queue reuses it as the per-compile budget |
+| `leanAsync` | `true` | all four | Lean compile mode: `true` (default) = background queue — `lean_run` / `lean_archive{run:true}` enqueue and return `async.jobId` immediately without blocking the member; `false` = synchronous await (the previous semantics, verbatim) |
+| `leanJobsMaxParallel` | `1` | all four | Background-compile concurrency cap (default 1 = serial; raise it to compile in parallel) |
+| `leanInitiative` | `'normal'` | all four | **Daily formalization eagerness**: `off` / `normal` (default, formalize along the way) / `eager` (more proactive). A **separate knob** from `formalVerify` (which only says how strong verification must be) |
+| `leanSearchPaths` | `[]` | all four | Extra Lean search roots (injected first; the automatic `<VibeMath root>` is added after them; nothing is injected when `leanArgs` already sets `--search-path`/`-R`/`--root`) |
+| `finalPaper` | `true` | all four | **Final paper**: written automatically at closure (`false` disables only the automatic trigger; the manual command still works). Full contract: `docs/final-paper.md` |
+| `paperFormat` | `both` | all four | Which text versions to produce: `both` (md+tex) / `md` (skips compilation and must not warn about a missing tex) / `tex` |
+| `paperLanguage` | `zh` | all four | Paper language: `zh` (ctexart, engine prefers xelatex) / `en` (article, pdflatex first) |
+| `paperCompilePdf` | `true` | all four | Compile `paper.pdf` when a LaTeX engine is detected; with no engine or a failed compile, tex+md are still delivered and a warning is logged |
+| `paperLatexCommand` | `''` | all four | Force one LaTeX engine executable (empty = auto-detect per language: xelatex→latexmk→pdflatex→lualatex→tectonic) |
+| `paperEditor` | v4 `office`; v5 `academician` | v4·v5 | Who finalises. v4: `office` (the session root / human side, default) or `resident:<id>` (if that resident has left, it degrades to office and the meta/log say so); v5: `academician` (default, the only editor an unattended run can reach) or `office` (manual `/v5 paper editor=office` only, and only after consulting the whole institute) |
+
+- **Async is the default**: with `leanAsync=true` compilation runs on a background queue and `lean_run` / `lean_archive{run:true}` return immediately; `leanAsync=false` is the synchronous wait.
+- **Only a settled compile counts as passed**: a job must be `settled` with exit 0 **and** have an unchanged content hash and build context during the compile before it may set `passed` / write `Verified/Lean/<id>.lean`; everything else (queued / failed / timeout / interrupted / changed content or context) stays `attempted`.
+
+### v2 (probability-driven · classic) preset-specific parameters
+
+v2 has **no preset-specific parameters**: its complete parameter set is every row of the table above whose "Applies to" column names v2. Adjust them at runtime with `vibe_math_set_params` (or `/vibe set`); they persist in the project-level `vibe_math_setting.json` (falling back to the global `<workspace>/VibeMath/vibe_math_setting.json` → built-in defaults when absent).
 
 #### Final paper
 
 All four presets have it **on by default**: after the closure signal fires and **before the run is marked complete**, the run enters the paper phase. In v2 a dedicated "paper writer" subagent assembles the concluded evidence into `Paper/<project>/{paper.md,paper.tex,paper.meta.json,paper.log.md}` (plus `paper.pdf` only when an engine is detected). Manual: `/vibe paper [lang=zh|en] [format=both|md|tex] [force]`. A PDF needs a LaTeX engine on the host (`xelatex` preferred for Chinese); with no engine or a failed compile the tex+md are still delivered with only a logged warning — the finalisation is never blocked and an existing pdf is never overwritten. Full contract: `docs/final-paper.md`.
 
-### v3 (paper-style md + planner agent + method library) defaults
+### v3 (paper-style md + planner agent + method library) preset-specific parameters
 
-Added/adjusted on top of all v2 parameters:
+v3 accepts **all** of v2's parameters (the rows above whose "Applies to" column names v3) and adds:
 
 | Parameter | Default | Description |
 |---|---|---|
-| `verdictMode` | `forced` | v3 first makes a **near-consensus determination** (all results on the same side with a mean ≥0.85/≤0.15 takes the mean) — this runs BEFORE the mode, so 0.9 vs 1 yields ≈0.95 in either mode; otherwise `forced` takes the **equal-weight mean** of the reported probabilities (no accuracy weighting; strict 1/0 still act as absolute votes), while `flat` rules `0.5` (a disagreement is undecided) |
 | `planningHorizon` | 3 | Maximum number of actions in one plan by the planner agent ("the next n times") |
 | `plannerEnabled` | true | false = fully use the built-in heuristic scheduling (planner agent disabled) |
 | `plannerProvider` / `plannerModel` | empty | Planner agent model route (empty = inherit the root agent) |
@@ -754,55 +569,31 @@ Added/adjusted on top of all v2 parameters:
 | `indexAutoRebuild` | true | Automatically rebuild `State/index.json` after each disk write (false = manual `vibe_math_index`) |
 | `projectLockTimeoutMs` | 60000 | Project lock wait timeout (only one session may schedule a given project at any one time) |
 | `methodKeeperPersona` | empty | Persona/requirements injected at the start of the method consolidation agent prompt |
-| `formalVerify` | `'off'` | **Lean formal verification switch**: `'off'` no additional requirement (default)｜`'encourage'` encouraged (during verification, decide for yourself whether to formalize based on implementation difficulty)｜`'require'` mandatory (a true/false conclusion must first have a "Lean passed" or an explicit blocking record, otherwise it is recorded as undecided and enters the formalization todo list). Any illegal value falls back to `'off'` |
-| `leanCommand` | `'lean'` | The Lean executable to run (e.g. `'lake'`) |
-| `leanArgs` | `[]` | Additional arguments inserted before the file name (e.g. `['env','lean']` together with `leanCommand='lake'`) |
-| `leanTimeoutMs` | `120000` | Upper limit for a single Lean run (milliseconds) |
-| `finalPaper` | `true` | **Final paper**: written automatically at closure (`false` disables only the automatic trigger; the manual command still works). Full contract: `docs/final-paper.md` |
-| `paperFormat` | `both` | Which text versions to produce: `both` (md+tex) / `md` (skips compilation and must not warn about a missing tex) / `tex` |
-| `paperLanguage` | `zh` | Paper language: `zh` (ctexart, engine prefers xelatex) / `en` (article, pdflatex first) |
-| `paperCompilePdf` | `true` | Compile `paper.pdf` when a LaTeX engine is detected; with no engine or a failed compile, tex+md are still delivered and a warning is logged |
-| `paperLatexCommand` | `''` | Force one LaTeX engine executable (empty = auto-detect per language: xelatex→latexmk→pdflatex→lualatex→tectonic) |
 
 #### Final paper
 
 v3 uses the same switch and the same ordering as v2 (strict termination; the writer is spawned **before** the scheduler stops): a dedicated "paper writer" subagent produces `Paper/<project>/{paper.md,paper.tex,paper.meta.json,paper.log.md}` (plus `paper.pdf` when an engine is detected). Manual: `/vibe paper [lang=zh|en] [format=both|md|tex] [force]`. No engine or a failed compile still delivers tex+md, logs a warning and never blocks the finalisation. Full contract: `docs/final-paper.md`.
 
-### v4 (resident self-organization · experimental) defaults
+### v4 (resident self-organization · experimental) preset-specific parameters
 
-Adjustable via `vibe_v4_set` (persisted to `State/settings.json`):
+Adjustable via `vibe_v4_set` (persisted to `State/settings.json`); shared parameters are in the table above, and v4 additionally has:
 
 | Parameter | Default | Description |
 |---|---|---|
 | `residentCount` | 4 | Resident count (can be increased/decreased via `vibe_v4_add_member`) |
-| `compactThreshold` | 66 | Reaching this resident context share triggers soft compaction (self-report instruction) |
-| `compactAfterRounds` | 8 | Trigger one soft compaction every N accumulated rounds per resident (uncompacted) |
-| `meetingKeepEvery` | 5 | Automatically trigger one sync meeting every N accumulated new artifacts |
-| `maxParallel` | 3 | Upper limit on simultaneously awakened residents (framework-side concurrency gate, not an assignment) |
-| `activityTimeoutMs` | 120000 | Idle heartbeat interval (only on timeout is a **self-driven** CHECKPOINT wakeup triggered, pushing residents to keep making progress; a failed wakeup automatically re-arms the heartbeat, ensuring the group never permanently stalls) |
-| `stallAutoMeetingMs` | 360000 | **Stall auto sync meeting threshold** (tiered keep-alive B): when the team is idle with no new artifacts for longer than this duration, the framework automatically convenes a sync meeting so the residents decide the next route/division of labor themselves (the framework only facilitates, it does not assign) |
-| `verdictMaxRounds` | 3 | Maximum number of rounds of debate after independent initial assessment in verification |
-| `provider` / `model` | empty | **Resident LLM route** (empty = residents inherit the main agent's provider/model; previously declared but unused, actually wired up in v1.4.1) |
 | `residentPersona` | empty | Persona/requirements injected at the start of each resident prompt |
-| `toolAllow` / `toolDeny` | `[]` | **Resident tool permissions** (scoped `tools.restrict()` via `startContinuable`'s `toolFilter`; empty = inherit all tools; ⚠️ an empty `allow:[]` rejects all tools) |
-| `formalVerify` | `'off'` | **Lean formal verification switch**: `'off'` no additional requirement (default)｜`'encourage'` encouraged (during verification, decide for yourself whether to formalize based on implementation difficulty)｜`'require'` mandatory (a true/false conclusion must first have a "Lean passed" or an explicit blocking record, otherwise it is recorded as undecided and enters the formalization todo list). Any illegal value falls back to `'off'` |
-| `leanCommand` | `'lean'` | The Lean executable to run (e.g. `'lake'`) |
-| `leanArgs` | `[]` | Additional arguments inserted before the file name (e.g. `['env','lean']` together with `leanCommand='lake'`) |
-| `leanTimeoutMs` | `120000` | Upper limit for a single Lean run (milliseconds) |
-| `finalPaper` | `true` | **Final paper**: written automatically at closure (`false` disables only the automatic trigger; the manual command still works). Full contract: `docs/final-paper.md` |
-| `paperFormat` | `both` | Which text versions to produce: `both` (md+tex) / `md` (skips compilation and must not warn about a missing tex) / `tex` |
-| `paperLanguage` | `zh` | Paper language: `zh` (ctexart, engine prefers xelatex) / `en` (article, pdflatex first) |
-| `paperCompilePdf` | `true` | Compile `paper.pdf` when a LaTeX engine is detected; with no engine or a failed compile, tex+md are still delivered and a warning is logged |
-| `paperLatexCommand` | `''` | Force one LaTeX engine executable (empty = auto-detect per language: xelatex→latexmk→pdflatex→lualatex→tectonic) |
-| `paperEditor` | `office` | Who finalises: `office` (the session root / human side, default) or `resident:<id>` (if that resident has left, it degrades to office and the meta/log say so) |
 
 #### Final paper
 
-On by default; v4 enters the paper phase after the closing meeting casts its unanimous stop vote and **before** the run is marked complete. Team flow: each resident writes its own part → merge (deduplicate, unify terms and notation) → at least one **cross-review** round → the editor named by `paperEditor` (default `office`, or `resident:<id>`) turns it into the final draft → the paper is finalised only on **unanimous "deliverable"** (objections keep iterating; past the round cap a warning is recorded and the disagreement goes into the appendix). Manual: `/v4 paper [lang=] [format=] [editor=office|resident:<id>] [force]`. Output: `Paper/<run id>/{paper.md,paper.tex,paper.meta.json,paper.log.md}` (plus `paper.pdf` when an engine is available). Full contract: `docs/final-paper.md`.
+On by default; v4 enters the paper phase after the closing meeting casts its unanimous stop vote and **before** the run is marked complete. Team flow: each resident writes its own part → merge (deduplicate, unify terms and notation) → at least one **cross-review** round → the editor named by `paperEditor` (default `office`, or `resident:<id>`) turns it into the final draft → the paper is finalised only on **unanimous "deliverable"** (objections keep iterating; past the round cap a warning is recorded and the disagreement goes into the appendix). Manual: `/v4 paper [lang=] [format=] [editor=office|resident:<id>] [force]`. Output: `Paper/<run id>/{paper.md,paper.tex,paper.meta.json,paper.log.md,paper.lock.json}` (plus `paper.pdf` when an engine is available; `paper.lock.json` is the directory's write lock, serialising concurrent rewrites/recompiles). Full contract: `docs/final-paper.md`.
+
+**v4-only tool `vibe_v4_formal_report` (documented in round 3)**: it reports "which propositions/methods have formal support and how strong it is" back to the resident team. That is part of v4's **team-autonomy** flow - residents must align on which settled conclusion may be cited - so it exists **only in v4** (v2/v3 use the dedicated solver/verifier architecture, where formal status travels through `vibe_math_lean_*` plus the verification logs; v5 carries it through the academician review path `vibe_v5_propose_verify`/`vibe_v5_verdict` and `vibe_v5_status`). Both v4 persona blocks require members to use it, and v4's `status`/`report` aggregate its output.
+
+> **Status-surface asymmetry (documented in round 3)**: v2/v3's `vibe_math_status` returns a **parameter block** (current `math*`/`lean*` values), while v4's `vibe_v4_status` and v5's `vibe_v5_status` return their own status/member/institute views **without** a parameter block (use the closed `vibe_v4_set`/`vibe_v5_set` schema, or the fields those statuses already expose). This is by design; this round chose to **document it** rather than add a params block to v4/v5.
 
-### v5 (institute system · experimental) defaults
+### v5 (institute system · experimental) preset-specific parameters
 
-Adjustable via `vibe_v5_set` (persisted in the institute state file `State/<institute>.v5state.json`):
+Adjustable via `vibe_v5_set` (persisted in the institute state file `State/<institute>.v5state.json`); shared parameters are in the table above, and v5 additionally has:
 
 | Parameter | Default | Description |
 |---|---|---|
@@ -812,30 +603,11 @@ Adjustable via `vibe_v5_set` (persisted in the institute state file `State/<inst
 | `researcherCount` | 3 | Number of resident researchers (at institute founding) |
 | `quorumCap` | 3 | Upper limit of m; actually **m = min(quorumCap, number of enrolled voting members)** |
 | `quorumMode` | `'m-unanimous'` | v5 calibration; switching to `'all-unanimous'` returns to v4's "all unanimous" |
-| `verdictMaxRounds` | 3 | Maximum number of rounds of public debate after independent initial assessment |
 | `maxTempPerMember` | 3 | Upper limit on temp workers **simultaneously** enrolled per academician/researcher (counted by enrollment, not cumulative — so swapping people is not restricted) |
 | `maxTempTotal` | 12 | Upper limit on temp workers simultaneously enrolled across the whole institute |
-| `compactThreshold` | 66 | Reaching this member context share (0–100) triggers compaction |
-| `compactAfterRounds` | 8 | Or trigger one soft compaction every N accumulated rounds |
-| `maxParallel` | 3 | Upper limit on simultaneously awakened members (framework-side concurrency gate) |
-| `activityTimeoutMs` | 120000 | Idle fallback heartbeat interval (the main driver is a one-shot activity wait, not polling) |
-| `stallAutoMeetingMs` | 360000 | Threshold for automatically convening a sync meeting on stall |
 | `chatDigestMs` / `chatDigestMax` | 45000 / 12 | Time window and entry cap for batching group chat digests (direct messages/meetings/votes are not batched) |
-| `meetingKeepEvery` | 5 | Automatically initiate one sync meeting every N accumulated new artifacts |
-| `provider` / `model` | empty | Member LLM route (empty = inherit the institute office/main agent route) |
-| `toolAllow` / `toolDeny` | `[]` | Resident staff tool permissions (⚠️ an empty `allow:[]` rejects all tools) |
 | `tempToolAllow` / `tempToolDeny` | `[]` | Temp worker tool permissions (narrower than residents) |
 | `staffPersona` | empty | Persona/requirements appended before each member charter |
-| `formalVerify` | `'off'` | **Lean formal verification switch**: `'off'` no additional requirement (default)｜`'encourage'` encouraged (during verification, decide for yourself whether to formalize based on implementation difficulty)｜`'require'` mandatory (a true/false conclusion must first have a "Lean passed" or an explicit blocking record, otherwise it is recorded as undecided and enters the formalization todo list). Any illegal value falls back to `'off'` |
-| `leanCommand` | `'lean'` | The Lean executable to run (e.g. `'lake'`) |
-| `leanArgs` | `[]` | Additional arguments inserted before the file name (e.g. `['env','lean']` together with `leanCommand='lake'`) |
-| `leanTimeoutMs` | `120000` | Upper limit for a single Lean run (milliseconds) |
-| `finalPaper` | `true` | **Final paper**: written automatically at closure (`false` disables only the automatic trigger; the manual command still works). Full contract: `docs/final-paper.md` |
-| `paperFormat` | `both` | Which text versions to produce: `both` (md+tex) / `md` (skips compilation and must not warn about a missing tex) / `tex` |
-| `paperLanguage` | `zh` | Paper language: `zh` (ctexart, engine prefers xelatex) / `en` (article, pdflatex first) |
-| `paperCompilePdf` | `true` | Compile `paper.pdf` when a LaTeX engine is detected; with no engine or a failed compile, tex+md are still delivered and a warning is logged |
-| `paperLatexCommand` | `''` | Force one LaTeX engine executable (empty = auto-detect per language: xelatex→latexmk→pdflatex→lualatex→tectonic) |
-| `paperEditor` | `academician` | Who finalises: `academician` (default, the only editor an unattended run can reach) or `office` (manual `/v5 paper editor=office` only, and only after consulting the whole institute) |
 
 #### Final paper
 
@@ -865,7 +637,7 @@ Common controls: `vibe_v5_configure` (configure first) → `vibe_v5_start` (star
 - **Lean formal verification (a contract shared by the four architectures)**: [`docs/formal-verification.md`](docs/formal-verification.md)
 - **Final paper (a contract shared by the four architectures)**: [`docs/final-paper.md`](docs/final-paper.md) (the five parameters plus `paperEditor` on v4/v5, the "paper phase before the run is marked complete" ordering, the `Paper/<id>/` artifacts and the nine-section skeleton, LaTeX detection with repair-then-degrade, the v4/v5 team co-authoring flow and the v5 office-consultation rule)
 - **Test timing baseline and parallel run recipes**: [`docs/test-timing.md`](docs/test-timing.md) (`node tests/run-tests.mjs` runs **every suite AND every probe** in parallel: `TOTAL 57` (39 suites + 18 probes/variants) in ≈3.5 min; which 18 of them ship in the package and which are repository-only is in §1.1 of that document; every runner prints its elapsed time/speedup so the next strategy can be chosen from data)
-- **Static prompt-surface consistency (persona ↔ tool registry ↔ slash command hint/usage)**: [`audit-persona-surface.test.mjs`](tests/audit-persona-surface.test.mjs) (208 assertions, and generates [`prompt-corpus-persona/persona-corpus.md`](prompt-corpus-persona/persona-corpus.md) for manual review) + [`audit-persona-sensitivity.mjs`](tests/audit-persona-sensitivity.mjs) (16 sensitivity probes) — guarding "every registered tool must appear in the persona / every name in the persona must really be registered / the `prefix` and `text` blocks must match line by line / hint, usage, and the actual branch must agree in all three places"
+- **Static prompt-surface consistency (persona ↔ tool registry ↔ slash command hint/usage)**: [`audit-persona-surface.test.mjs`](tests/audit-persona-surface.test.mjs) (260 assertions, and generates [`prompt-corpus-persona/persona-corpus.md`](prompt-corpus-persona/persona-corpus.md) for manual review) + [`audit-persona-sensitivity.mjs`](tests/audit-persona-sensitivity.mjs) (16 sensitivity probes) — guarding "every registered tool must appear in the persona / every name in the persona must really be registered / the `prefix` and `text` blocks must match line by line / hint, usage, and the actual branch must agree in all three places"
 - **Mandatory checklist for a full review**: [`AUDIT-CHECKLIST.md`](docs/AUDIT-CHECKLIST.md) (this repository's mandatory audit process; §1.9 specifically checks "whether the tool parameter schema can accommodate them")
 - **Prompt/interaction invariants (all four sets together, re-checkable in one command)**: [`audit-prompt-invariants.mjs`](tests/audit-prompt-invariants.mjs) (157 assertions) — encoding, one by one, "the classes of prompt/tool-surface defects that have really occurred historically" as static invariants (abbreviated tool names, projecting a fidelity defect as 0, `defect` written only in the prompt but not implemented, a receipt contract missing `defect`, passing without a note, wrong field names, the `off` tier still being able to write state in its receipt, uncertain corpora, missing probes, **a tool's closed schema that cannot accommodate the parameters in its own documentation**, **keys that the schema declares at the parameter level but silently drops**). Adding `--self-probe` injects these defect shapes in memory and requires the corresponding invariants to **turn red** while the unmutated control run **stays green** (5/5); the script itself additionally carries six self-checks X5–X8b (the comment scanner must recognize regex literals — including regexes **after a keyword** such as `return /…/` — `//` inside strings must be preserved, stripping comments must not change line structure, and the parse-level criterion that "the four sets of source, with comments stripped, must still parse under `node --check`")
 - **Specification ↔ code traceability (all four sets together)**: [`audit-spec-traceability.mjs`](tests/audit-spec-traceability.mjs) (94 assertions) — tools promised in `实现方案.md`/README must really be registered; the four Lean parameters must be accepted by both the documentation and the code