dsh-vibe-math 2.3.6 → 2.3.8

package/AUDIT-CHECKLIST.md

@@ -153,6 +153,11 @@ v2/v3/v4/v5 是**同构实现**（同一份契约、四份独立代码，刻意
 
 - [ ] 该映射是否优先使用**权威来源**（框架生成 id 时就知道的归属）？
 - [ ] 权威来源不在内存时（resume 早期），记录里是否**持久化**了 `objectId` 可查？
+- [ ] **从用户可编辑的状态文件里读出来的"权威值"是否先做了自洽校验？** 状态文件（如
+      `VibeMath_State/formal.json`）是可以被人改的：**真实事故（2.3.7）**——某条记录的 `objectId`
+      被写成 r 形（`r-pX`）时，"验证 id → 对象 id"会映射到**它自己**，于是"两套 id 一起写"退化成
+      只写验证侧、对象侧仍是 `passed`。修法：锚点必须自洽（不以 `r-` 开头）才可用，读与写两处都校验；
+      灵敏度探针见 `_oneoff/probe-v2-anchor-guard.mjs`（去掉守卫 → 用例变红）。
 - [ ] 字符串解析是否只作为**兜底**，而不是唯一手段？
 - [ ] **真实事故（2.3.6）**：`formalObjectIdOf` 无条件剥离 `-sN/-pfN/-rfN`，于是命题 `pAmb-s1` 的
       验证 id `r-pAmb-s1` 被解析成对象 `pAmb`；一句 `defect` 于是降级并**撤回了 `pAmb` 的归档证明**，

package/RELEASE-NOTES-2.3.7.md

@@ -0,0 +1,59 @@
+# dsh-vibe-math 2.3.7 — 权威锚点必须自洽：手改过的状态文件不得劫持 id 映射
+
+> 上一版：2.3.6。本版是 round 8：把 2.3.6 新引入的"记录里持久化权威 `objectId`"这条机制**自己**审一遍。
+> 无破坏性变更，默认仍为 `formalVerify: 'off'`。
+
+---
+
+## 1. 2.3.6 引入的新机制里有一个可被污染的锚点
+
+2.3.6 让 `formalObjectIdOf` 在任务表不可用时读记录里的 `objectId`（跨 resume 生效）。但**状态文件是
+可编辑的**（`VibeMath_State/formal.json`，仓库里本来就有"文件被改坏也要能继续"的守卫测试）：
+
+- 如果某条记录的 `objectId` 自己就是 **r 形**（`r-pX`），那么"验证 id → 对象 id"会映射到**它自己**；
+- 于是 `putFormalBothIds('r-pX', …)` 认为"两侧就是同一个 id"，**只写验证侧**，对象侧仍然 `passed`
+  —— 又回到"成对关系只做一半"的静默错位（门禁/卡片/提示词各读一侧）。
+
+**触发路径**（实测）：**工作轮回执**（explorer/solver 的回执同样带 `formal` 字段）在**没有验证任务**
+在内存里时走到"读记录锚点"这条兜底路径。以手改过的状态文件复现：修前该用例的断言变红
+（对象侧不降级），修后全绿。
+
+## 2. 修法：锚点必须**自洽**才可用
+
+- `formalObjectIdOf` 读记录锚点时，要求 `formalObjectIdOfIsOwner(v)` 为真 —— 即该值**不以 `r-` 开头**、
+  不可能再被解析成别的 id；
+- 写入锚点的两处（`syncVerificationTarget`、`putFormalBothIds`）同样只在**确实是对象 id** 时写入，
+  不给未来留下污染源。
+
+> 说明（如实记录）：写入侧的两道守卫**目前无法用用例证明其必要性**——现有写入者手里的值都来自
+> `formalObjectIdOf`，本身就不会是 r 形（我一度写了一个"归档写在 rId 上会污染锚点"的用例，实测发现它
+> **恒真**，已删除并换成下面这个真正敏感的用例）。因此这两道守卫按**纵深防御**保留并如此标注；
+> 真正被证明有效的是**读取侧**的守卫。
+
+## 3. 新增断言（`formal-verify-v2.test.mjs` 第 14d 节，+5 条）
+
+- 状态文件里的 `r-pX` 记录带 `objectId: 'r-pX'`（手改出来的 r 形锚点），对象 `pX` 是 `passed`；
+- 一个**工作轮回执**（没有验证任务，因此走记录锚点这条路径）点名 `r-pX` 报 `defect`；
+- 断言：**对象侧必须被降级**（锚点被拒绝而不是被信任）、验证侧同样降级。
+
+**灵敏度实测**（`_oneoff/probe-v2-anchor-guard.mjs`）：把读取侧的守卫去掉 → 该用例立刻变红
+（`exit=1`，失败断言正是这一条），装回 → 全绿。即这条守卫是**承重**的，不是摆设。
+
+## 4. 验收（实测）
+
+| 项 | 2.3.6 | 2.3.7 |
+|---|---|---|
+| `formal-verify-v2.test.mjs` | 348 | **353** |
+| 读取侧守卫探针 | — | **红/绿各一次，符合预期** |
+| 全量并行回归 | 23/23 | 23/23 |
+| 49 条 formal 探针 | 全红 | 全红 |
+| 四套语料确定性 | 字节稳定 | 字节稳定 |
+| closing verification | 18/18 | 18/18 |
+
+## 5. 升级
+
+```
+npm i dsh-vibe-math@latest
+```
+
+无迁移。本版只改 v2 的锚点校验与断言；`off` 档行为不变，其余三套预设与上一版逐字节相同。

package/RELEASE-NOTES-2.3.8.md

@@ -0,0 +1,45 @@
+# dsh-vibe-math 2.3.8 — 把 round 7/8 的结论写进契约与审计清单（文档版）
+
+> 上一版：2.3.7。本版**只改文档**（无代码、无预设字节变化）：把 2.3.6/2.3.7 发现的边界与规则写进
+> 共享契约与强制审计流程，免得下一轮审计重新把它当"新问题"或按另一种方式改。
+
+---
+
+## 1. 契约 §4：补两条边界
+
+- **记录与归档文件同生共死（框架侧），但外部文件操作不会自动改记录**：框架撤回证明时记录降级与文件
+  撤回是**同一次操作**；反过来，**外部**删掉 `Verified/Lean/<id>.lean` **不会**自动把记录降级——
+  `passed` 是状态文件里的权威状态，门禁查询是只读的，不会在每次取记录时做文件存在性探测（那会把门禁
+  变成 fs I/O，并在网络盘/权限异常时引入新的失败模式）。人工动过文件后请一并修正记录或重新归档。
+- **v2 的 id 映射同理**：记录里持久化的 `objectId` 是权威锚点，但必须**自洽**（不以 `r-` 开头）才被
+  采纳，否则回退到后缀解析——状态文件可编辑，里面的"权威值"要先校验。
+
+## 2. `AUDIT-CHECKLIST` §1.10：补一条检查项
+
+> **从用户可编辑的状态文件里读出来的"权威值"是否先做了自洽校验？**
+> 真实事故（2.3.7）：某条记录的 `objectId` 被写成 r 形时，"验证 id → 对象 id"映射到它自己，
+> "两套 id 一起写"退化成只写验证侧、对象侧仍是 `passed`。
+
+（§1.10 是 2.3.6 新增的章节「id 映射不许猜」，本版把它与 2.3.7 的教训合并成完整检查项。）
+
+## 3. v2 实现方案 §9.3：同步自洽条件
+
+`formalObjectIdOf` 的权威度顺序里，第 ② 级（记录里的 `objectId`）补上"读出时要求自洽"的条件。
+
+## 4. 验收
+
+| 项 | 结果 |
+|---|---|
+| 代码/预设字节变化 | **无**（四套 `.js` 与 2.3.7 逐字节相同） |
+| 全量并行回归 | 23/23 |
+| 静态守卫 | invariants 157/0（self-probe 5/5）、traceability 94/0、v5-integrity clean |
+| 四套语料确定性 | 字节稳定 |
+| closing verification | 18/18 |
+
+## 5. 升级
+
+```
+npm i dsh-vibe-math@latest
+```
+
+无迁移、无行为变更。

package/docs/formal-verification.md

@@ -150,6 +150,14 @@
 | **回执里 `formal:{target, decision:'defect', note}`** | **撤回 `passed`：→ `attempted`，清空 `proof`、删除 `Verified/Lean/<id>.lean`、把 `note` 写入记录与 `Formal/TODO.md`、公告**（`note` 必填） |
 | 回执里 `formal:{target, decision:'used', file}` | → `attempted`（记录文件）；**若该对象已是 `passed`/`blocked` 则保持原状**——一次"这一轮碰了形式化"的 `used` 回执**不得**撤销已成立的证明（`proof` 指针与归档文件都不变）。撤销只有 `defect` 一条路（§4.1）。 |
 
+> **记录与归档文件同生共死（框架侧），但外部文件操作不会自动改记录**：框架自己撤回证明时，记录降级与
+> 文件撤回是**同一次操作**（§4.1 的删除 → 复核 → 覆写）。反过来，**外部**（人、别的工具、另一个项目）
+> 删掉 `Verified/Lean/<id>.lean` **不会**自动改记录——`passed` 是状态文件里的权威状态，门禁查询是只读的，
+> 不会在每次取记录时做文件存在性探测（那会把门禁变成 fs I/O，并在网络盘/权限异常时引入新的失败模式）。
+> 因此人工动过文件后请一并修正记录，或重新 `lean_archive`；否则门禁仍按 `passed` 放行，忠实性提示词会
+> 打印一个已不存在的路径。**v2 的 id 映射同样如此**：记录里持久化的 `objectId` 是权威锚点，但它必须
+> **自洽**（不以 `r-` 开头），否则会被忽略并回退到后缀解析——状态文件是可编辑的，里面的"权威值"要先校验。
+
 ### 4.1 `defect`：忠实性缺陷**不是**"命题为假"
 
 `passed` 只保证"这段 Lean 代码通过了内核检查"，**不保证它说的就是命题想说的**。当表决者逐条核对后

package/formal-verify-v2.test.mjs

@@ -1040,6 +1040,7 @@ section('14 defect withdrawal covers every id alias AND a host that cannot delet
     assert(!!rec, '★ the defect named by the object id is absorbed')
     assert(!existsSync(aliasProof), '★★ the proof archived under the VERIFICATION id is withdrawn too (every id alias, not just the two named ones)')
     assert(!!rec && (!rec['r-pAlias'] || rec['r-pAlias'].proof === ''), 'the rId record no longer points at a proof')
+    assert(!rec['r-pAlias'] || !rec['r-pAlias'].objectId || rec['r-pAlias'].objectId === 'pAlias', '★★ the rId record owner stamp is the OBJECT id (pAlias), never an r-shaped poisoned anchor (got ' + JSON.stringify(rec['r-pAlias'] && rec['r-pAlias'].objectId) + ')')
   }
 
   // (b) a host whose deletion cannot work: the archived path must not keep reading as the proof.
@@ -1125,6 +1126,41 @@ section('14 defect withdrawal covers every id alias AND a host that cannot delet
   }
 }
 
+// (d) THE RECORD-OWNER FALLBACK must not be hijacked by a hand-edited state file. The state file is
+// user-editable, and a record whose `objectId` is itself r-shaped is not a usable owner: it would make
+// the verification id map to ITSELF, so a defect named by that rId would never reach the object side.
+// This case uses a WORK-ROUND (explorer) reply, which also carries `formal` and runs with NO verification
+// task in memory — i.e. it is the path that actually reads the owner from the record (a verifier reply
+// would take the task-registry path instead, which is authoritative and already covered above).
+{
+  const h = await makeCase('anchor-poison', { noSubprocess: true })
+  await h.call('vibe_math_set_params', { formalVerify: 'require', maxParallelThreshold: 8 })
+  const proj = projRoot(h)
+  mkdirSync(join(proj, 'Verified', 'Lean'), { recursive: true })
+  mkdirSync(join(proj, 'Formal'), { recursive: true })
+  const WORK = 'theorem p_x : 2 + 2 = 4 := by decide\n'
+  writeFileSync(join(proj, 'Formal', 'pX.lean'), WORK, 'utf8')
+  writeFileSync(join(proj, 'Verified', 'Lean', 'pX.lean'), WORK, 'utf8')
+  const base = { status: 'passed', file: 'Formal/pX.lean', proof: 'Verified/Lean/pX.lean', decision: 'used', updatedAt: 1 }
+  writeFileSync(join(proj, 'VibeMath_State', 'formal.json'), JSON.stringify({ records: {
+    pX: Object.assign({}, base),
+    'r-pX': Object.assign({}, base, { objectId: 'r-pX' }),   // ← the r-shaped anchor a hand edit could leave
+  }, todo: [] }), 'utf8')
+  await h.call('vibe_math_add_problem', { id: 'qA', description: '锚点污染用例', priority: 1 })
+  await startScheduler(h)
+  await tick(2000)
+  const ex = await waitFor(() => h.spawns.find((s) => s.label.startsWith('explorer:qA')), 60, 200)
+  assert(!!ex, 'anchor-poison: the explorer was spawned (the scheduler is running)')
+  if (ex) {
+    const reply = { directions: [{ id: 'd1', title: 'D', method: 'm', core_assumption: 'c', feasibility: 0.6 }], formal: { target: 'r-pX', decision: 'defect', note: 'Lean 少了 n≥1' } }
+    h.fireEnd({ id: ex.childId, runId: 'rp', provider: 'spawn', local: true, stopReason: 'completed', lastAssistantMessage: [{ type: 'text', text: '```json\n' + JSON.stringify(reply) + '\n```' }] })
+    const rec = await waitFor(() => { const r = (formalStateOf(h).records || {}); return (r['pX'] && r['pX'].decision === 'defect') ? r : undefined }, 40, 150)
+    assert(!!rec, '★★ a work-round defect named by an rId still reaches the OBJECT side when the record carries an r-shaped anchor (the anchor is rejected, not trusted)')
+    const all = formalStateOf(h).records || {}
+    assert(!!all['r-pX'] && all['r-pX'].status === 'attempted', '★★ and the rId record is downgraded as well (both id spaces stay in step)')
+  }
+}
+
 section('15 the require gate also covers the judge-problem transfer')
 {
   const h = await makeCase('judge-gate')

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "dsh-vibe-math",
   "description": "Multi-agent mathematical problem-solving & verification frameworks for DeepSeek Harness — FOUR agent presets in one install: vibe-math-v2 (probability-driven: qs.json + Propos knowledge base + explorer→solver→review/debate verdict), vibe-math-v3 (THIRD-generation, recommended: paper-style Markdown knowledge base with Problems/Progress/Propos/Methods/Verified + planner-agent scheduling that decides the next N actions + universal theory/method invention library + agents write their own Markdown directly via a per-file write lock), and vibe-math-v4 (FOURTH-generation: persistent self-organizing resident subagents that message & meet to decide all tasks, verify only by unanimous consensus, /compact at a context threshold, and stop only when all agree the problem is solved), and vibe-math-v5 (FIFTH-generation research institute: an academician as the organizational centre who decomposes and ASSIGNS work and chairs meetings; permanent researchers who hold the vote and may hire/fire their own temp workers; temp workers with no vote; a group chat and meetings; a durable per-recipient mailbox; a compare-and-set task DAG; and a boolean m-vote consensus rule where an object enters Verified/ only when at least m voting members agree AND every one of them returns exactly 1 or exactly 0). Installing this bundle auto-installs all four presets (v1 was removed at v2.0.0).",
-  "version": "2.3.6",
+  "version": "2.3.8",
   "type": "module",
   "engines": {
     "node": "^22.19.0 || >=24.0.0"
@@ -42,6 +42,8 @@
     "RELEASE-NOTES-2.3.4.md",
     "RELEASE-NOTES-2.3.5.md",
     "RELEASE-NOTES-2.3.6.md",
+    "RELEASE-NOTES-2.3.7.md",
+    "RELEASE-NOTES-2.3.8.md",
     "selfdrive-v5.mjs",
     "示例图/框架图-v5.svg",
     "docs/架构图.md",
@@ -105,7 +107,7 @@
     },
     "minVersion": "0.1.2-rc.1",
     "testedVersion": "0.1.5-rc.2",
-    "compatNote": "v2.3.6 修复 2.3.2 审计中记录为「存疑、需契约决策」的那条 id 解析歧义 —— round 7 先把它做成可复现用例，确认不是理论问题而是真实可达的数据破坏：v2 有两套 id（对象 id 与验证 rId），二者靠唯一一处 formalObjectIdOf 转换，而它无条件剥离 -sN/-pfN/-rfN 后缀；但对象 id 本身就可能以 -s1 结尾（命题 pAmb-s1 的验证 id 是 r-pAmb-s1），映射于是得到 pAmb —— 另一个对象。实测（修前 6 条断言变红）：忠实性提示词打印的是邻居 pAmb 的证明路径；一句 formal:{target:「r-pAmb-s1」,decision:「defect」} 会把 pAmb 降级为 attempted，并**撤回 Verified/Lean/pAmb.lean**（一句关于 A 的回执删掉 B 的归档证明，不可逆）；而真正有问题的 pAmb-s1 仍然是 passed、TODO 里也没有它。修复：formalObjectIdOf 改为按权威度取来源 —— ① 验证任务自己的所有者（tasks[verify:+rId].r.pId|qid，框架生成 rId 时就知道对象是谁）；② 记录里的 objectId（由 syncVerificationTarget 与 putFormalBothIds 在手里确实有对象 id 时写入，因此跨 resume、任务表尚未重建时也正确）；③ 只有两者都不可用时才回退到字符串后缀解析。v3/v4/v5 不受影响（没有第二套 id 空间，验证直接以对象 id 为键，已核对 formalId/formalOf 只做 idSafe）。新增 14 条行为断言（formal-verify-v2 第 14c 节）：两个同前缀对象各自有自己的证明；对 r-pAmb-s1 的忠实性提示词必须指向它自己的证明；defect 必须降级并撤回它自己的证明、TODO 写它；邻居 pAmb 必须仍是 passed 且其归档证明文件分毫未动；验证记录里必须写着权威所有者 objectId。套件 334 → 348。v2.3.5 是 round 5：把\"注释/字符串扫描器\"这一类缺陷追到所有自带扫描器的脚本上。audit-v5-integrity.mjs（静态自检：调用了但未定义的函数 / 未声明的 params.X 读取 / 会话 API 上不存在的方法 / 遗留开发标记）的 stripNoise() 完全不认正则字面量，而 v5 源码里有一个字符类带双引号的 sanitize 正则，那个引号被当成字符串开头。实测（旧 vs 新逐行比对，v5 共 4365 行）：30 行不一致（都是含\"字符类里有引号\"的正则的行），抹除后的文本无法通过 node --check；本次没有任何调用名 / params.* 读取 / s.*() 方法被漏掉，所以是潜在盲区而非已发生的漏检 —— 但只要某个被检查的标识符恰好只出现在这种行上就会完全隐形。现把 stripNoise() 升级为与 audit-prompt-invariants.mjs 同一套词法处理（正则字面量 + 字符类 + 转义 + flags + 关键字规则），正则与字符串统一替换为值占位符；并给该审计加上解析级自检：抹除后的 v5 源码必须仍能被 node --check 解析，且\"引号在字符类里的正则 + 紧随其后的注释\"夹具必须完好。灵敏度实测：把旧扫描器放回去，审计立刻报 stripNoise() corrupted the source it scans（exit 1），换回新版则 clean；39 条 v5 灵敏度探针仍全红。（过程教训：第一版测量用\"文件里下一个引号\"估算受影响区域，得出\"402 行 / 20 个函数\"的错误结论；该扫描器遇到换行即结束字符串，真实影响是 30 行。发布前逐行复核才发现并改正 —— 先量准再下结论。）v2.3.4 是 round 4：只审上一轮改动过的东西（2.3.3 修好的注释扫描器 —— 它是 I1/I13/I14 三条不变式的地基 —— 与它新增的 X5–X7 自检）。扫描器还剩一个盲区：判据\"这个斜杠是正则还是除法\"只看前一个字符，于是关键字后面的正则被读成除法 —— 而 v3 源码里真有 return /^\\s*import\\s+/.test(l) 与 return /\\n$/.test(out) 两处；这两处字符类里恰好没有引号所以今天还没坏，但只要有人在 return /…/ 的正则里写一个引号（如 return /[\"']/.test(s)），扫描器就会把那个引号当成字符串开头、此后整个文件词法状态都是错的，又回到 2.3.2 修掉的坑。现把判据从\"前一个字符\"升级为\"前一个记号\"：除运算符/开括号外，return/typeof/case/delete/void/instanceof/in/of/yield/await/new/do/else 之后也按正则解析，标识符、右括号、右方括号之后仍按除法。并新增解析级判据 X8/X8b：X8 要求四套源码\"抹掉注释\"之后的产物仍能被 node --check 解析（扫描器读错代码时产物往往直接语法错误）；X8b 是专测关键字规则的夹具（return /[\"']/.test(l) + 紧随其后的注释）。灵敏度已实测：2.3.2 的扫描器让四个预设全部 SyntaxError（X8 红），2.3.3 的扫描器 X8 绿但 X8b 红（紧随其后的注释没被抹掉），当前版本两者皆绿 —— 即 X8 守住大回退、X8b 守住这个窄口子，2.3.3 的扫描器会被 X8b 判红。不变式 151 → 157。本版只改随包发布的审计脚本与文档，四套预设字节未变。依赖宿主提供的 subagents/agents/tools/commands/fs 服务与 @deepseek-ai/dsh-* 插件行；可选 subprocess/sandboxPolicy/compaction。persona 行同时携带 prefix 与 text 两个键，以兼容 0.1.3-alpha.2 的 schema 更名（prefix 必填）与 0.1.2 及更早的 text 键。已在 dsh-v0.1.5-rc.2（@deepseek-ai/dsh-persona 0.1.5-rc.2）上逐行校验全部预设行并通过（v2/v3/v4；v1 已于 v2.0.0 移除）。注意：DSH 0.1.2 起 subagents.startContinuable 的 agentOptions/toolFilter 需要宿主 provider 声明对应 capability（spawn/fork 进程内 provider 均支持），安装器启动时会做能力自检并在旧版宿主上告警。2026 兼容性修复：v2/v3 工具权限名表原先硬编码 web/fetch/bash（未注册名会使 tools.restrict() 抛错、子代理无法建立），现按真实注册名并加带守卫的重试；v4 真实 /compact 原先在 subagent/end 里查 agents.get()（该事件触发时子代理已移出注册表，属死代码），现改为在 subagent/start 捕获 Agent 引用；三套预设的可选服务改为惰性读取，不再在 apply() 快照；v4 的 tools/commands 注册补入 ctx.effect；安装器自检新增 subprocess/sandboxPolicy/compaction。v2.1.0 新增 v5 研究所体系：状态存于宿主 host-only 会话投影单元（键 vibeMathV5），因此自检新增 sessionProjections/sessions（均为可选；缺失时 v5 回退到加固 JSON 状态文件）。v5 不依赖任何 npm 实验包，纯 preset 内单文件实现。v2.3.3 是 2.3.2 之后的确认轮（重新审计改动过的每一处：四套插件、四套套件、共享契约，以及审计脚本自身），修掉一处真实缺陷与两处同类/字面问题：① v2 的 formal.decision=used 回执**无条件**把记录写成 attempted —— 一句「这一轮碰了形式化」会把已经 passed 的对象在两个 id 空间上一起降级，而 proof 指针仍留着（记录自相矛盾），后果是后续审查提示词丢掉忠实性分支、require 档对一份已跑通的归档证明重新关门并把对象丢进形式化待办；现改为先取合并后的记录状态（formalGateRecord，两套 id 都认），passed/blocked 一律保留，只有从未尝试起步才写 attempted（与 v4 的 formalSetRun 缺陷同类，只是长在回执通道上且只长在一套里）。② v3 的 used 分支只保留 passed（prev.status === passed ? passed : attempted），会把 blocked 打回 attempted —— blocked 本身就是「门禁已放行」的记录，一句 used 就把门禁重新关上；现两者都保留，四套同构。③ 共享契约 docs/formal-verification.md §4 迁移表有两行与实现相反（used 行与两行 lean_run 都写成「→ attempted」），而规范文档写反最危险之处是下一次修改会照它写（2.3.2 修好 v2 后若只读契约就会把修复改回去）；现已改正为「已是 passed/blocked 则保持原状」，并补上「lean_archive kind=proof 但运行失败 → attempted + 清空 proof + 撤回旧归档证明」这一行，四套实现方案与 v5 规格同步，audit-spec-traceability 增加 3 条字面校验（91 → 94）。④ 审计脚本自身的守卫加固：audit-prompt-invariants.mjs 的注释扫描器此前不认正则字面量，而四套源码都含一个「字符类里带双引号」的 sanitize 正则字面量，旧扫描器把那个引号当成字符串开头、此后整个文件词法状态都是错的（实测新旧逐行比对：v2 190 行 / v3 159 行 / v4 14 行 / v5 121 行不同，典型后果是真实代码行被当注释抹掉 → 真缺陷可能被 I1/I13/I14 漏看）；现在扫描器支持正则字面量（字符类/转义/flags）并新增 X5–X7 三条自检（正则里的引号不得吞掉注释、字符串里的 // 必须保留、转义斜杠不得提前结束正则，且都保持行结构），修复前 X5 会变红。⑤ 行为断言补齐四套同构（此前只有 v4 断言「普通 run 不降级 passed」）：四套各新增 used 回执不得降级已 passed 对象、不得把 blocked 打回 attempted、普通 lean_run 不得降级 passed，v2 还断言「used 之后 require 门禁仍放行（把该轮驱动到一致为真不会产生 formal-required 待办）」；本轮是先用断言复现（v2 修复前实测三条变红：got attempted），再修复。套件断言 v2 334 / v3 294 / v4 277 / v5 153 / prompt-v5-integrity 506，audit-prompt-invariants 151/0（--self-probe 5/5），audit-spec-traceability 94/0。v2.3.2 是对四个架构各做一轮深度审计 + 横向同构对照后的修复版（无破坏性变更，默认仍为 off），修掉三处会让「严格验证」失效或不可用的高危缺陷：① v3 的四个 Lean 参数从未写进 vibe_math_set_params 的参数 schema（该 schema 是 additionalProperties:false，遵守 schema 的 provider 会拒绝这个调用）→ 用户永远无法开启该功能，而套件全绿（它直接调 handler、绕过 schema）；② v2 的 require 门禁只读验证侧自己的 id，而代理用对象 id 归档、别名同步只更新已存在的键 → 「归档了 passed、验证侧还没有记录」时门禁永远搁置，搁置本身又写下 rId=none，于是每轮重开一次辩论、对象永远无法定论并饿死其它对象；③ v4 的 formalSetRun 硬编码 status=attempted，把已验证对象的 passed 抹掉（与注释、规格、v2/v5 都矛盾）→ 一次随手 lean_run 就让对象丢掉「已形式化」，忠实性分支消失、require 档对已有绿色证明的对象重新关门。另修 v2 的一处门禁旁路（settleVerdict 的「判断命题」转移在 v=0 时直接写 布尔估计=0/已验证/优先级 never 并压入 正确概率:1 条目，完全不看门禁）。撤回语义按 v5 的正确做法统一四套：撤回归档证明时先删、再用 fs 复核文件真的没了、仍在则就地覆盖为撤回说明，并如实公告是哪一种（含两者都失败的告警）；lean_archive kind=proof 跑红时不再保留 prev.proof（proof 只属于 passed）并撤回旧的归档证明。提示词/交互修复：忠实性分支改为按档位承诺（只有 require 有门禁，encourage 明确写「本档没有门禁：请务必给弃权值」）；无 Lean 工具链的出路同时点名 LEAN_NOT_FOUND 与 NO_SUBPROCESS；v3 的失败提示不再让人去看并不存在的编译器输出；v4 活动日志里的缩写工具名改为注册名（并纳入注入文本扫描）；v2 的工作轮不再把可复用引理指向项目内不存在的 Formal/Proved/；v2 的 kind=def/lemma 跑红不再声称可复用；v3 setup 的重复 plannerPersona 去重；v4 规格里的幽灵工具 vibe_v4_propose_verify 修正为回执字段。语料确定性：v5 语料此前的非确定有三层根因（心跳/会议依赖真实时钟与异步顺序、最闲成员抖动、写入端只按 kind 排序），现由套件虚拟时钟 + 单成员研究所内捕捉心跳 + 写入端全序排序（kind→owner→prompt）修复，连跑 6 次字节一致且套件 7–9 s → 1.7 s；v3 的 20 条 planner:* 随机 plan id 与 epoch 时间戳一并 scrub。新增两个随包发布的常驻守卫：audit-prompt-invariants.mjs（四套 × 26 条静态不变式 + 3 条跨套检查，把历次真实发生过的提示词缺陷类别编码住，当前 121/0）与 audit-spec-traceability.mjs（规格/README 承诺的工具必须真的注册，能识别「文档里说它不存在」的否定语境；四个 Lean 参数必须同时被文档与代码接受；契约 §7 的 terminate()；契约 §8 的门禁收口点无旁路，当前 91/0），以及 run-tests.mjs（并行跑全部套件并打印耗时/加速比/最慢项，修掉 --only x 空格形式被静默忽略与 --json 混入人类输出两个 bug）。AUDIT-CHECKLIST.md 新增 §1.8「四套同构：任何语义修正必须四套同步」——本轮三处高危里有两处正是改一套或四套同写法却无人横向对照造成的。本轮最贵的一处缺陷还暴露出一整类既有测试全都盲的漏洞：四个预设的工具 schema 都由 objParams 以 additionalProperties:false 关闭，schema 没列出的键会被遵守 schema 的 provider 直接拒绝，而提示词/规格/状态行可以全都在说这个参数、套件也可以全绿（套件直接调 handler、绕过 schema）——因此新增三重守卫：① 四套各自的 formal-verify-vN 套件现在直接检查**真实注册的** schema 对象（封闭性 + 四个 Lean 参数 + formalVerify 的 enum 恰好三档，已用探针证明：去掉 v3 真实注册那份的 leanArgs 立刻变红）；② audit-prompt-invariants.mjs 新增 I13（每一处 set 工具定义都必须声明这四个参数，且每一份 objParams 都必须关闭 schema）；③ 新增 I14（schema 声明的每个键都必须被参数层真正接收：v2/v3 的闸门是 DEFAULT_PARAMS 键集、v4 是 k in params、v5 是 normalizeParams 的类型列表——声明而不接收 = 调用返回 ok:true 却什么都不发生）。该脚本同时新增 --self-probe：在内存里注入这些缺陷形状，要求对应不变式变红、未变异的对照跑仍为绿（5/5），现为 145 条不变式。套件断言 v2 319 / v3 283 / v4 269 / v5 145 / prompt-v5-integrity 506，e2e-v4-fixes 修掉并行下的抖动（T21 会议看门狗 80 ms 在 CPU 争用下提前放弃会议）；全量并行回归连续 3 次 23/23 全绿（最新实测 wall 111.5 s / sum 221.5 s / x1.99）。v2.3.1 是审计驱动的提示词/交互修复版（无破坏性变更，默认仍为 off）：① 忠实性缺陷不再被记成「命题为假」——新增回执取值 decision='defect'（表决者发现 Lean 代码与命题原文不一致时不得投 0，给中间值并记录具体偏差；框架随即把该对象降级为 attempted、清空 proof、撤回归档证明 Verified/Lean/<id>.lean、写入 Formal/TODO.md，require 档下本次裁定不定论），encourage 档不承诺它无法强制的搁置；② 修复 v2 的 formal 回执通道是死代码（提示词要求写进回执、契约里却没有该字段、框架也从不解析）——补齐 formalJsonField/formalReplyNote/absorbFormalFromReply 并接进初评与辩论两条路径，套件改为行为断言而非措辞断言；③ 修复 v2/v3 忠实性分支的字段名错误（写成 verdict，真实字段是 Result，会导致该票被静默丢弃）；④ 注入文本里的工具名一律改为注册名全称（v2/v3/v5 原先出现 lean_lib/lean_archive 缩写，含工具自身返回的 hint）；⑤ 新增「归档可复用定义/引理前先跑通」与「宿主无 Lean 工具链（LEAN_NOT_FOUND）时把代码归档并在 note 写明，算显式阻塞原因」两条硬要求；⑥ 四套各自新增随包发布的人工复核语料 prompt-corpus-vN/（覆盖 off/encourage/require/忠实性/工作轮/回执契约），并修复 v5 语料路径归一化在 Windows 大小写差异下漏掉 VibeMath 根绝对路径、导致语料不确定且泄露本机路径的问题；⑦ 新增 16 条提示词灵敏度探针（删掉「不要投 0」、工具名换缩写、删掉 require 门禁措辞、回执契约去掉 defect，各四套），全套件断言 v2 261 / v3 247 / v4 226 / v5 120 / prompt-v5-integrity 588。v2.3.0 为四个架构新增可调控的 Lean 形式化验证（参数 formalVerify = off/encourage/require，默认 off）：验证时按实现难度决定是否用 Lean 形式化（写代码+执行），一旦通过则审查对象从「推导是否正确」变成「Lean 的定义/对象/条件/假设/结论是否忠实于命题原文」；形式化代码归档为命题的证明（Verified/Lean/<id>.lean），可复用定义与已证引理归档到跨项目的 VibeMath/Formal/{Lib,Proved}/。require 档带门禁：真/假结论必须先有 Lean 通过或显式阻塞记录，否则记为未定论并进入形式化待办。共用契约 docs/formal-verification.md，四套各带 formal-verify-vN 套件（v2 177 / v3 189 / v4 144 / v5 88 断言）与 audit-formal-sensitivity.mjs 探针。同一次审计还发现并修复了一整类**静态提示词面**缺陷（persona ↔ 工具注册表，既有套件全部盲）：v2/v3/v4 的 persona 从未列出无条件注册的三个 *_lean_* 工具，v4 的 vibe_v4_set 参数表漏了 formalVerify/leanCommand/leanArgs/leanTimeoutMs，v3 漏了 setup/save_settings/template，v4 漏了 vibe_v4_prompts，v5 漏了增删常驻研究员的工具、且 prefix 与 text 两个块存在文字漂移；现由 audit-persona-surface.test.mjs（197 断言：双向一致性 + 未文档化工具显式快照 + prefix/text 逐行一致 + 斜杠命令 hint/usage/实际分支三处一致 + Lean 参数/档位/路径，并生成随包发布的 prompt-corpus-persona/ 人读语料）与 audit-persona-sensitivity.mjs（11 条探针，含「未变异副本必须为绿」的对照）守护，AUDIT-CHECKLIST.md 新增 §1.6。v2.2.2 新增 v5 架构图（示例图/框架图-v5.svg + docs/generate_framework_diagram_v5.mjs 零依赖 Node 生成器 + vibe-math-v5/架构图.md 全套 Mermaid 细节图），并修复在绘制架构图时暴露的真实缺陷：会议进行中提出的验证会并发启动（会议与验证的互斥此前只做了单向），现改为排队。v2.2.1 把「全面检查必查清单」(AUDIT-CHECKLIST.md) 作为随包强制流程发布，提示词/交互正确性列为第一优先审计维度。v2.2.0 修复实测发现的提示词身份错乱：状态块改为显式接收它所描述的成员，创建成员时先落盘进编制再构造入职提示词，章程快照冻结在入职时，重建会话不再自称“刚入职”，所办调用不再被误判成某位研究员，框架反馈改为独立发送者投递，一次提示词不再重复投递同一条消息，并新增 prompt-v5-integrity 提示词完整性套件 + 可人工复核的提示词语料（随包发布）。",
+    "compatNote": "v2.3.8 是纯文档版（无代码、无预设字节变化）：把 round 7/8 的结论写进共享契约与强制审计流程，免得下一轮审计重新把它当新问题或按另一种方式改 —— ① docs/formal-verification.md §4 补两条边界：记录与归档文件在框架侧\"同生共死\"，但**外部**删除 Verified/Lean/<id>.lean 不会自动降级记录（passed 是状态文件里的权威状态，门禁查询只读、不做文件存在性探测），人工动过文件后请一并修正记录或重新归档；v2 的 id 映射同理，记录里持久化的 objectId 必须**自洽**（不以 r- 开头）才被采纳。② AUDIT-CHECKLIST §1.10 补一条检查项「从用户可编辑的状态文件里读出来的『权威值』是否先做了自洽校验」，并写入 2.3.7 的真实事故。③ v2 实现方案 §9.3 同步该自洽条件。v2.3.7 是 round 8：把 2.3.6 新引入的「记录里持久化权威 objectId」这条机制自己审一遍。2.3.6 让 formalObjectIdOf 在任务表不可用时读记录里的 objectId（跨 resume 生效），但状态文件是可编辑的（VibeMath_State/formal.json，仓库里本来就有\"文件被改坏也要能继续\"的守卫测试）：若某条记录的 objectId 自己就是 r 形（r-pX），\"验证 id → 对象 id\"就会映射到它自己，于是 putFormalBothIds 认为两侧是同一个 id、只写验证侧，对象侧仍然 passed —— 又回到\"成对关系只做一半\"的静默错位。触发路径已实测：工作轮回执（explorer/solver 回执同样带 formal）在没有验证任务在内存时走\"读记录锚点\"这条兜底路径。修复：读取锚点与写入锚点都要求\"锚点自洽\"（formalObjectIdOfIsOwner：不以 r- 开头、不可能再被解析成别的 id）。写入侧的两道守卫目前无法用用例证明必要性（现有写入者手里的值都来自 formalObjectIdOf，本身不会是 r 形；我一度写的\"归档写在 rId 上会污染锚点\"的用例实测恒真，已删除），因此按纵深防御保留并如此标注；真正被证明有效的是读取侧守卫。新增 5 条断言（formal-verify-v2 第 14d 节）：手改出的 r 形锚点 + 工作轮回执点名 r-pX 报 defect → 对象侧必须被降级（锚点被拒绝而不是被信任）、验证侧同样降级。灵敏度实测（_oneoff/probe-v2-anchor-guard.mjs）：去掉读取侧守卫 → 该用例立刻变红，装回 → 全绿。套件 348 → 353。v2.3.6 修复 2.3.2 审计中记录为「存疑、需契约决策」的那条 id 解析歧义 —— round 7 先把它做成可复现用例，确认不是理论问题而是真实可达的数据破坏：v2 有两套 id（对象 id 与验证 rId），二者靠唯一一处 formalObjectIdOf 转换，而它无条件剥离 -sN/-pfN/-rfN 后缀；但对象 id 本身就可能以 -s1 结尾（命题 pAmb-s1 的验证 id 是 r-pAmb-s1），映射于是得到 pAmb —— 另一个对象。实测（修前 6 条断言变红）：忠实性提示词打印的是邻居 pAmb 的证明路径；一句 formal:{target:「r-pAmb-s1」,decision:「defect」} 会把 pAmb 降级为 attempted，并**撤回 Verified/Lean/pAmb.lean**（一句关于 A 的回执删掉 B 的归档证明，不可逆）；而真正有问题的 pAmb-s1 仍然是 passed、TODO 里也没有它。修复：formalObjectIdOf 改为按权威度取来源 —— ① 验证任务自己的所有者（tasks[verify:+rId].r.pId|qid，框架生成 rId 时就知道对象是谁）；② 记录里的 objectId（由 syncVerificationTarget 与 putFormalBothIds 在手里确实有对象 id 时写入，因此跨 resume、任务表尚未重建时也正确）；③ 只有两者都不可用时才回退到字符串后缀解析。v3/v4/v5 不受影响（没有第二套 id 空间，验证直接以对象 id 为键，已核对 formalId/formalOf 只做 idSafe）。新增 14 条行为断言（formal-verify-v2 第 14c 节）：两个同前缀对象各自有自己的证明；对 r-pAmb-s1 的忠实性提示词必须指向它自己的证明；defect 必须降级并撤回它自己的证明、TODO 写它；邻居 pAmb 必须仍是 passed 且其归档证明文件分毫未动；验证记录里必须写着权威所有者 objectId。套件 334 → 348。v2.3.5 是 round 5：把\"注释/字符串扫描器\"这一类缺陷追到所有自带扫描器的脚本上。audit-v5-integrity.mjs（静态自检：调用了但未定义的函数 / 未声明的 params.X 读取 / 会话 API 上不存在的方法 / 遗留开发标记）的 stripNoise() 完全不认正则字面量，而 v5 源码里有一个字符类带双引号的 sanitize 正则，那个引号被当成字符串开头。实测（旧 vs 新逐行比对，v5 共 4365 行）：30 行不一致（都是含\"字符类里有引号\"的正则的行），抹除后的文本无法通过 node --check；本次没有任何调用名 / params.* 读取 / s.*() 方法被漏掉，所以是潜在盲区而非已发生的漏检 —— 但只要某个被检查的标识符恰好只出现在这种行上就会完全隐形。现把 stripNoise() 升级为与 audit-prompt-invariants.mjs 同一套词法处理（正则字面量 + 字符类 + 转义 + flags + 关键字规则），正则与字符串统一替换为值占位符；并给该审计加上解析级自检：抹除后的 v5 源码必须仍能被 node --check 解析，且\"引号在字符类里的正则 + 紧随其后的注释\"夹具必须完好。灵敏度实测：把旧扫描器放回去，审计立刻报 stripNoise() corrupted the source it scans（exit 1），换回新版则 clean；39 条 v5 灵敏度探针仍全红。（过程教训：第一版测量用\"文件里下一个引号\"估算受影响区域，得出\"402 行 / 20 个函数\"的错误结论；该扫描器遇到换行即结束字符串，真实影响是 30 行。发布前逐行复核才发现并改正 —— 先量准再下结论。）v2.3.4 是 round 4：只审上一轮改动过的东西（2.3.3 修好的注释扫描器 —— 它是 I1/I13/I14 三条不变式的地基 —— 与它新增的 X5–X7 自检）。扫描器还剩一个盲区：判据\"这个斜杠是正则还是除法\"只看前一个字符，于是关键字后面的正则被读成除法 —— 而 v3 源码里真有 return /^\\s*import\\s+/.test(l) 与 return /\\n$/.test(out) 两处；这两处字符类里恰好没有引号所以今天还没坏，但只要有人在 return /…/ 的正则里写一个引号（如 return /[\"']/.test(s)），扫描器就会把那个引号当成字符串开头、此后整个文件词法状态都是错的，又回到 2.3.2 修掉的坑。现把判据从\"前一个字符\"升级为\"前一个记号\"：除运算符/开括号外，return/typeof/case/delete/void/instanceof/in/of/yield/await/new/do/else 之后也按正则解析，标识符、右括号、右方括号之后仍按除法。并新增解析级判据 X8/X8b：X8 要求四套源码\"抹掉注释\"之后的产物仍能被 node --check 解析（扫描器读错代码时产物往往直接语法错误）；X8b 是专测关键字规则的夹具（return /[\"']/.test(l) + 紧随其后的注释）。灵敏度已实测：2.3.2 的扫描器让四个预设全部 SyntaxError（X8 红），2.3.3 的扫描器 X8 绿但 X8b 红（紧随其后的注释没被抹掉），当前版本两者皆绿 —— 即 X8 守住大回退、X8b 守住这个窄口子，2.3.3 的扫描器会被 X8b 判红。不变式 151 → 157。本版只改随包发布的审计脚本与文档，四套预设字节未变。依赖宿主提供的 subagents/agents/tools/commands/fs 服务与 @deepseek-ai/dsh-* 插件行；可选 subprocess/sandboxPolicy/compaction。persona 行同时携带 prefix 与 text 两个键，以兼容 0.1.3-alpha.2 的 schema 更名（prefix 必填）与 0.1.2 及更早的 text 键。已在 dsh-v0.1.5-rc.2（@deepseek-ai/dsh-persona 0.1.5-rc.2）上逐行校验全部预设行并通过（v2/v3/v4；v1 已于 v2.0.0 移除）。注意：DSH 0.1.2 起 subagents.startContinuable 的 agentOptions/toolFilter 需要宿主 provider 声明对应 capability（spawn/fork 进程内 provider 均支持），安装器启动时会做能力自检并在旧版宿主上告警。2026 兼容性修复：v2/v3 工具权限名表原先硬编码 web/fetch/bash（未注册名会使 tools.restrict() 抛错、子代理无法建立），现按真实注册名并加带守卫的重试；v4 真实 /compact 原先在 subagent/end 里查 agents.get()（该事件触发时子代理已移出注册表，属死代码），现改为在 subagent/start 捕获 Agent 引用；三套预设的可选服务改为惰性读取，不再在 apply() 快照；v4 的 tools/commands 注册补入 ctx.effect；安装器自检新增 subprocess/sandboxPolicy/compaction。v2.1.0 新增 v5 研究所体系：状态存于宿主 host-only 会话投影单元（键 vibeMathV5），因此自检新增 sessionProjections/sessions（均为可选；缺失时 v5 回退到加固 JSON 状态文件）。v5 不依赖任何 npm 实验包，纯 preset 内单文件实现。v2.3.3 是 2.3.2 之后的确认轮（重新审计改动过的每一处：四套插件、四套套件、共享契约，以及审计脚本自身），修掉一处真实缺陷与两处同类/字面问题：① v2 的 formal.decision=used 回执**无条件**把记录写成 attempted —— 一句「这一轮碰了形式化」会把已经 passed 的对象在两个 id 空间上一起降级，而 proof 指针仍留着（记录自相矛盾），后果是后续审查提示词丢掉忠实性分支、require 档对一份已跑通的归档证明重新关门并把对象丢进形式化待办；现改为先取合并后的记录状态（formalGateRecord，两套 id 都认），passed/blocked 一律保留，只有从未尝试起步才写 attempted（与 v4 的 formalSetRun 缺陷同类，只是长在回执通道上且只长在一套里）。② v3 的 used 分支只保留 passed（prev.status === passed ? passed : attempted），会把 blocked 打回 attempted —— blocked 本身就是「门禁已放行」的记录，一句 used 就把门禁重新关上；现两者都保留，四套同构。③ 共享契约 docs/formal-verification.md §4 迁移表有两行与实现相反（used 行与两行 lean_run 都写成「→ attempted」），而规范文档写反最危险之处是下一次修改会照它写（2.3.2 修好 v2 后若只读契约就会把修复改回去）；现已改正为「已是 passed/blocked 则保持原状」，并补上「lean_archive kind=proof 但运行失败 → attempted + 清空 proof + 撤回旧归档证明」这一行，四套实现方案与 v5 规格同步，audit-spec-traceability 增加 3 条字面校验（91 → 94）。④ 审计脚本自身的守卫加固：audit-prompt-invariants.mjs 的注释扫描器此前不认正则字面量，而四套源码都含一个「字符类里带双引号」的 sanitize 正则字面量，旧扫描器把那个引号当成字符串开头、此后整个文件词法状态都是错的（实测新旧逐行比对：v2 190 行 / v3 159 行 / v4 14 行 / v5 121 行不同，典型后果是真实代码行被当注释抹掉 → 真缺陷可能被 I1/I13/I14 漏看）；现在扫描器支持正则字面量（字符类/转义/flags）并新增 X5–X7 三条自检（正则里的引号不得吞掉注释、字符串里的 // 必须保留、转义斜杠不得提前结束正则，且都保持行结构），修复前 X5 会变红。⑤ 行为断言补齐四套同构（此前只有 v4 断言「普通 run 不降级 passed」）：四套各新增 used 回执不得降级已 passed 对象、不得把 blocked 打回 attempted、普通 lean_run 不得降级 passed，v2 还断言「used 之后 require 门禁仍放行（把该轮驱动到一致为真不会产生 formal-required 待办）」；本轮是先用断言复现（v2 修复前实测三条变红：got attempted），再修复。套件断言 v2 334 / v3 294 / v4 277 / v5 153 / prompt-v5-integrity 506，audit-prompt-invariants 151/0（--self-probe 5/5），audit-spec-traceability 94/0。v2.3.2 是对四个架构各做一轮深度审计 + 横向同构对照后的修复版（无破坏性变更，默认仍为 off），修掉三处会让「严格验证」失效或不可用的高危缺陷：① v3 的四个 Lean 参数从未写进 vibe_math_set_params 的参数 schema（该 schema 是 additionalProperties:false，遵守 schema 的 provider 会拒绝这个调用）→ 用户永远无法开启该功能，而套件全绿（它直接调 handler、绕过 schema）；② v2 的 require 门禁只读验证侧自己的 id，而代理用对象 id 归档、别名同步只更新已存在的键 → 「归档了 passed、验证侧还没有记录」时门禁永远搁置，搁置本身又写下 rId=none，于是每轮重开一次辩论、对象永远无法定论并饿死其它对象；③ v4 的 formalSetRun 硬编码 status=attempted，把已验证对象的 passed 抹掉（与注释、规格、v2/v5 都矛盾）→ 一次随手 lean_run 就让对象丢掉「已形式化」，忠实性分支消失、require 档对已有绿色证明的对象重新关门。另修 v2 的一处门禁旁路（settleVerdict 的「判断命题」转移在 v=0 时直接写 布尔估计=0/已验证/优先级 never 并压入 正确概率:1 条目，完全不看门禁）。撤回语义按 v5 的正确做法统一四套：撤回归档证明时先删、再用 fs 复核文件真的没了、仍在则就地覆盖为撤回说明，并如实公告是哪一种（含两者都失败的告警）；lean_archive kind=proof 跑红时不再保留 prev.proof（proof 只属于 passed）并撤回旧的归档证明。提示词/交互修复：忠实性分支改为按档位承诺（只有 require 有门禁，encourage 明确写「本档没有门禁：请务必给弃权值」）；无 Lean 工具链的出路同时点名 LEAN_NOT_FOUND 与 NO_SUBPROCESS；v3 的失败提示不再让人去看并不存在的编译器输出；v4 活动日志里的缩写工具名改为注册名（并纳入注入文本扫描）；v2 的工作轮不再把可复用引理指向项目内不存在的 Formal/Proved/；v2 的 kind=def/lemma 跑红不再声称可复用；v3 setup 的重复 plannerPersona 去重；v4 规格里的幽灵工具 vibe_v4_propose_verify 修正为回执字段。语料确定性：v5 语料此前的非确定有三层根因（心跳/会议依赖真实时钟与异步顺序、最闲成员抖动、写入端只按 kind 排序），现由套件虚拟时钟 + 单成员研究所内捕捉心跳 + 写入端全序排序（kind→owner→prompt）修复，连跑 6 次字节一致且套件 7–9 s → 1.7 s；v3 的 20 条 planner:* 随机 plan id 与 epoch 时间戳一并 scrub。新增两个随包发布的常驻守卫：audit-prompt-invariants.mjs（四套 × 26 条静态不变式 + 3 条跨套检查，把历次真实发生过的提示词缺陷类别编码住，当前 121/0）与 audit-spec-traceability.mjs（规格/README 承诺的工具必须真的注册，能识别「文档里说它不存在」的否定语境；四个 Lean 参数必须同时被文档与代码接受；契约 §7 的 terminate()；契约 §8 的门禁收口点无旁路，当前 91/0），以及 run-tests.mjs（并行跑全部套件并打印耗时/加速比/最慢项，修掉 --only x 空格形式被静默忽略与 --json 混入人类输出两个 bug）。AUDIT-CHECKLIST.md 新增 §1.8「四套同构：任何语义修正必须四套同步」——本轮三处高危里有两处正是改一套或四套同写法却无人横向对照造成的。本轮最贵的一处缺陷还暴露出一整类既有测试全都盲的漏洞：四个预设的工具 schema 都由 objParams 以 additionalProperties:false 关闭，schema 没列出的键会被遵守 schema 的 provider 直接拒绝，而提示词/规格/状态行可以全都在说这个参数、套件也可以全绿（套件直接调 handler、绕过 schema）——因此新增三重守卫：① 四套各自的 formal-verify-vN 套件现在直接检查**真实注册的** schema 对象（封闭性 + 四个 Lean 参数 + formalVerify 的 enum 恰好三档，已用探针证明：去掉 v3 真实注册那份的 leanArgs 立刻变红）；② audit-prompt-invariants.mjs 新增 I13（每一处 set 工具定义都必须声明这四个参数，且每一份 objParams 都必须关闭 schema）；③ 新增 I14（schema 声明的每个键都必须被参数层真正接收：v2/v3 的闸门是 DEFAULT_PARAMS 键集、v4 是 k in params、v5 是 normalizeParams 的类型列表——声明而不接收 = 调用返回 ok:true 却什么都不发生）。该脚本同时新增 --self-probe：在内存里注入这些缺陷形状，要求对应不变式变红、未变异的对照跑仍为绿（5/5），现为 145 条不变式。套件断言 v2 319 / v3 283 / v4 269 / v5 145 / prompt-v5-integrity 506，e2e-v4-fixes 修掉并行下的抖动（T21 会议看门狗 80 ms 在 CPU 争用下提前放弃会议）；全量并行回归连续 3 次 23/23 全绿（最新实测 wall 111.5 s / sum 221.5 s / x1.99）。v2.3.1 是审计驱动的提示词/交互修复版（无破坏性变更，默认仍为 off）：① 忠实性缺陷不再被记成「命题为假」——新增回执取值 decision='defect'（表决者发现 Lean 代码与命题原文不一致时不得投 0，给中间值并记录具体偏差；框架随即把该对象降级为 attempted、清空 proof、撤回归档证明 Verified/Lean/<id>.lean、写入 Formal/TODO.md，require 档下本次裁定不定论），encourage 档不承诺它无法强制的搁置；② 修复 v2 的 formal 回执通道是死代码（提示词要求写进回执、契约里却没有该字段、框架也从不解析）——补齐 formalJsonField/formalReplyNote/absorbFormalFromReply 并接进初评与辩论两条路径，套件改为行为断言而非措辞断言；③ 修复 v2/v3 忠实性分支的字段名错误（写成 verdict，真实字段是 Result，会导致该票被静默丢弃）；④ 注入文本里的工具名一律改为注册名全称（v2/v3/v5 原先出现 lean_lib/lean_archive 缩写，含工具自身返回的 hint）；⑤ 新增「归档可复用定义/引理前先跑通」与「宿主无 Lean 工具链（LEAN_NOT_FOUND）时把代码归档并在 note 写明，算显式阻塞原因」两条硬要求；⑥ 四套各自新增随包发布的人工复核语料 prompt-corpus-vN/（覆盖 off/encourage/require/忠实性/工作轮/回执契约），并修复 v5 语料路径归一化在 Windows 大小写差异下漏掉 VibeMath 根绝对路径、导致语料不确定且泄露本机路径的问题；⑦ 新增 16 条提示词灵敏度探针（删掉「不要投 0」、工具名换缩写、删掉 require 门禁措辞、回执契约去掉 defect，各四套），全套件断言 v2 261 / v3 247 / v4 226 / v5 120 / prompt-v5-integrity 588。v2.3.0 为四个架构新增可调控的 Lean 形式化验证（参数 formalVerify = off/encourage/require，默认 off）：验证时按实现难度决定是否用 Lean 形式化（写代码+执行），一旦通过则审查对象从「推导是否正确」变成「Lean 的定义/对象/条件/假设/结论是否忠实于命题原文」；形式化代码归档为命题的证明（Verified/Lean/<id>.lean），可复用定义与已证引理归档到跨项目的 VibeMath/Formal/{Lib,Proved}/。require 档带门禁：真/假结论必须先有 Lean 通过或显式阻塞记录，否则记为未定论并进入形式化待办。共用契约 docs/formal-verification.md，四套各带 formal-verify-vN 套件（v2 177 / v3 189 / v4 144 / v5 88 断言）与 audit-formal-sensitivity.mjs 探针。同一次审计还发现并修复了一整类**静态提示词面**缺陷（persona ↔ 工具注册表，既有套件全部盲）：v2/v3/v4 的 persona 从未列出无条件注册的三个 *_lean_* 工具，v4 的 vibe_v4_set 参数表漏了 formalVerify/leanCommand/leanArgs/leanTimeoutMs，v3 漏了 setup/save_settings/template，v4 漏了 vibe_v4_prompts，v5 漏了增删常驻研究员的工具、且 prefix 与 text 两个块存在文字漂移；现由 audit-persona-surface.test.mjs（197 断言：双向一致性 + 未文档化工具显式快照 + prefix/text 逐行一致 + 斜杠命令 hint/usage/实际分支三处一致 + Lean 参数/档位/路径，并生成随包发布的 prompt-corpus-persona/ 人读语料）与 audit-persona-sensitivity.mjs（11 条探针，含「未变异副本必须为绿」的对照）守护，AUDIT-CHECKLIST.md 新增 §1.6。v2.2.2 新增 v5 架构图（示例图/框架图-v5.svg + docs/generate_framework_diagram_v5.mjs 零依赖 Node 生成器 + vibe-math-v5/架构图.md 全套 Mermaid 细节图），并修复在绘制架构图时暴露的真实缺陷：会议进行中提出的验证会并发启动（会议与验证的互斥此前只做了单向），现改为排队。v2.2.1 把「全面检查必查清单」(AUDIT-CHECKLIST.md) 作为随包强制流程发布，提示词/交互正确性列为第一优先审计维度。v2.2.0 修复实测发现的提示词身份错乱：状态块改为显式接收它所描述的成员，创建成员时先落盘进编制再构造入职提示词，章程快照冻结在入职时，重建会话不再自称“刚入职”，所办调用不再被误判成某位研究员，框架反馈改为独立发送者投递，一次提示词不再重复投递同一条消息，并新增 prompt-v5-integrity 提示词完整性套件 + 可人工复核的提示词语料（随包发布）。",
     "compatibility": {
       "dshReleases": {
         "0.1.2-alpha.4": "compatible",

package/prompt-corpus-v2/formal-verify-v2.json

@@ -474,6 +474,18 @@
       "label": "verifier:r-pAmb-s1:1",
       "prompt": "You are a STRICT peer reviewer verifying one mathematical object. Check it multiple times.\n\nTARGET (r: proposition):\nPROPOSITION (id: pAmb-s1): 对象 id 本身以 -s1 结尾\n\nKNOWLEDGE BASE & DATA MODEL (definition contract you MUST follow):\n\n1) PROBABILITY SEMANTICS — the single most important rule:\n- 正确概率 / 布尔估计 ∈ [0,1]。\n- 1 = 绝对正确（已被证明且验证通过）：你可以把它当作已知事实/可信结论直接用于推理。\n- 0 = 绝对错误（已被证伪且验证通过）。\n- 0 与 1 之间的任何值 = 未定论/待验证：只能作为参考证据，绝不能当作已成立的事实引用。\n- Verified/ 中的卡片概率恒为 1 或 0，内容可信、可直接引用。\n\n2) OBJECT MODELS (按实现方案)：\n- 问题 PROBLEM（qs/qs.json）：{ id, 概述（完整问题陈述，所提到的每个对象/记号都要给出完整定义）, 已解决(bool), 解法列表:[{ 完整解法（详细步骤）, 正确概率, 已验 }], 优先级（整数，越小越优先调度；\"never\"=永不调度）, progress（历史：已试方向、各方向路线、阻碍及原因、教训、可行性评估）}。\n- 命题 PROPOSITION（Propos/<分类>_Propos.json）：{ id, 概述（完整陈述）, 布尔估计（该命题为真的概率）, 细类型（分类 JSON）, 证明列表:[{ 完整过程（完整证明）, 正确概率, 支持信息/依据 }], 证伪列表:[{ 完整过程（完整证伪）, 正确概率, 支持信息/依据 }], 优先级, 价值/关键性（0-1，重要性）, progress（过往尝试与教训）}。\n- 收口规则：问题的某个解法 正确概率=1 → 问题已解决；命题的证明/证伪条目 正确概率=1 → 命题布尔估计=1/0（已定论）。\n\n3) FOLDERS (per project, VibeMath/Projects/<project>/)：\n- qs/qs.json：问题清单——求解与验证的唯一问题来源。\n- Propos/<分类>_Propos.json：命题知识库（已有认知）。\n- Reliable/：可信参考文献（只读）。\n- Verified/<分类>_Verified.json：定论事实索引——布尔估计=0/1 的命题卡片与已解决问题卡片；内容可信、可直接使用。\n- Verification_logs/：辩论记录。Progress_Logs/：进度与报告。VibeMath_State/：调度器私有状态——不要读也不要改。\n\n4) OUTPUT REQUIREMENTS (你输出的每个对象必须满足)：\n- 完整性、不断章取义：任何你写出的问题/命题/结论都要给出完整陈述，并把它所依赖的对象、环境、背景、定义全部补全（例如提到某个序列/函数/定理时给出其完整定义与假设）。\n- 引用溯源：若你引用了 qs/qs.json、Propos/、Verified/、Reliable/ 中已有的命题/引理/结论/解法，必须给出出处——具体文件路径（相对项目根，如 Propos/数论_Propos.json 或 Verified/未分类_Verified.json）+ 对象 id 或 JSON 路径（如 .证明列表[0] 或 .directions[1]）；没有出处的引用一律不允许。你自己新提出的结论则必须自带完整定义，不得引用未定义的内容。\n- 若结论依赖某个临时假设 p，必须显式写成「若 <p 的完整陈述> 成立，则：...」（同样要定义完整）。\n- 只输出规定的 JSON（放在 ```json 代码围栏内），JSON 之外不写任何内容。\n- 示例（完整问题 概述）：\"设 {a_n} 为非负实数序列（n≥1），满足：对任意正整数 n 都存在 i,j 使 |a_i − a_j| = 1/n^p（p>0 为实参数）。判断：p 在什么范围内保证级数 ∑_{n=1}^∞ a_n 发散？\" —— 每个记号（序列、参数、级数）都在句内定义完整，读它的人无需再查背景。\n- 示例（完整命题 概述）：\"设函数 f:[0,1]→R 连续，则 f 在 [0,1] 上有界（连续性按 ε-δ 定义，有界性按标准实数分析定义）。\" —— 概念与对象定义完整，不引用未定义的记号。\n\n\nYOUR PERMISSIONS / CAPABILITIES:\n- Network tools (web search / fetch): available; Script/shell tools (bash/pwsh): available (your actual tool list is enforced by the framework).\n- You may use external tools (web search / literature lookup, symbolic/numeric computation (running scripts)) to assist; no per-round limit by default.\n- You may READ any file under Verified/ as a known, trusted dependency (resolved facts).\n- You should BASE your reasoning on the existing knowledge under Propos/ (propositions with proofs/refutations and probabilities) and Reliable/ (trusted references).\n- You must NOT write files directly: return structured JSON only — the scheduler is the single writer.\n\nHOW TO READ EXISTING KNOWLEDGE (coarse scan → fine read):\n- These are JSON files. A conclusion object carries summary-index fields (概述 / 布尔估计 / 优先级) and the full detail (证明列表 / 证伪列表 / 完整过程 / progress).\n- COARSE SCAN first: use a read/grep tool to extract ONLY the summary index (概述, 布尔估计, 优先级, titles) to locate which files / objects look relevant — do NOT load full proofs yet.\n- FINE READ after: once you identify a valuable object, read that file again and extract its full JSON (完整过程 / 证明 / 证伪 / progress) via the index you found.\n\n【Lean 形式化验证（强制模式）】\n  · 该对象已有**通过的 Lean 形式化证明**（Verified/Lean/pAmb-s1.lean，最近运行 exit 0）。\n    **你不需要重新检查推导**。你的任务是**忠实性审查**：逐条核对 Lean 代码里的\n    定义 / 对象 / 条件 / 假设 / 结论是否与命题原文**完全一致**。\n  ▸ 一致 → Result = 1。\n  ▸ **发现任何偏差，不要投 0**：偏差只说明**形式化不合格**，不代表命题为假。此时请：\n      ① Result 给一个严格介于 0 与 1 之间的值（记为弃权），并在 Reason 里写清偏差；\n      ② 用回执 formal:{decision:'defect', note:'<具体偏差>'} 记录它。框架会撤回这条证明的\n         「已通过」状态（降级为 attempted、删除归档证明、写入形式化待办），本次裁定**不定论**；\n         修正形式化并重新跑通后再投票。\n  ▸ 只有当你**独立于这份 Lean 代码**也能确定命题为假时，才投 0，并在 Reason 里写清独立理由。\n\nResult ∈ [0,1] = your probability that the TARGET is CORRECT: 1 ONLY when you are fully certain (for a bare proposition: Reason must be a complete proof; for a proof/refutation/solution: you verified every step and Reason confirms the whole chain); 0 ONLY when you are certain it is wrong (Reason must be a rigorous complete refutation / pinpoint the fatal flaw); otherwise a value strictly between 0 and 1.\n\nIndependently output your initial review. Respond with ONLY a single JSON object wrapped in a ```json code fence — no prose:\n{\"Result\":0.5,\"Reason\":\"detailed logic chain, potential counterexample, or supporting evidence\",\"formal\":{\"target\":\"r-pAmb-s1\",\"decision\":\"used|blocked|defect\",\"file\":\"Formal/r-pAmb-s1.lean\",\"note\":\"难度判断/阻塞原因/具体偏差\"}}"
     },
+    {
+      "kind": "spawn",
+      "case": "anchor-poison",
+      "label": "explorer:qA",
+      "prompt": "You are a research mathematician orchestrating strategy for one problem.\n\nPROBLEM (id: qA): 锚点污染用例\n\n\nKNOWLEDGE BASE & DATA MODEL (definition contract you MUST follow):\n\n1) PROBABILITY SEMANTICS — the single most important rule:\n- 正确概率 / 布尔估计 ∈ [0,1]。\n- 1 = 绝对正确（已被证明且验证通过）：你可以把它当作已知事实/可信结论直接用于推理。\n- 0 = 绝对错误（已被证伪且验证通过）。\n- 0 与 1 之间的任何值 = 未定论/待验证：只能作为参考证据，绝不能当作已成立的事实引用。\n- Verified/ 中的卡片概率恒为 1 或 0，内容可信、可直接引用。\n\n2) OBJECT MODELS (按实现方案)：\n- 问题 PROBLEM（qs/qs.json）：{ id, 概述（完整问题陈述，所提到的每个对象/记号都要给出完整定义）, 已解决(bool), 解法列表:[{ 完整解法（详细步骤）, 正确概率, 已验 }], 优先级（整数，越小越优先调度；\"never\"=永不调度）, progress（历史：已试方向、各方向路线、阻碍及原因、教训、可行性评估）}。\n- 命题 PROPOSITION（Propos/<分类>_Propos.json）：{ id, 概述（完整陈述）, 布尔估计（该命题为真的概率）, 细类型（分类 JSON）, 证明列表:[{ 完整过程（完整证明）, 正确概率, 支持信息/依据 }], 证伪列表:[{ 完整过程（完整证伪）, 正确概率, 支持信息/依据 }], 优先级, 价值/关键性（0-1，重要性）, progress（过往尝试与教训）}。\n- 收口规则：问题的某个解法 正确概率=1 → 问题已解决；命题的证明/证伪条目 正确概率=1 → 命题布尔估计=1/0（已定论）。\n\n3) FOLDERS (per project, VibeMath/Projects/<project>/)：\n- qs/qs.json：问题清单——求解与验证的唯一问题来源。\n- Propos/<分类>_Propos.json：命题知识库（已有认知）。\n- Reliable/：可信参考文献（只读）。\n- Verified/<分类>_Verified.json：定论事实索引——布尔估计=0/1 的命题卡片与已解决问题卡片；内容可信、可直接使用。\n- Verification_logs/：辩论记录。Progress_Logs/：进度与报告。VibeMath_State/：调度器私有状态——不要读也不要改。\n\n4) OUTPUT REQUIREMENTS (你输出的每个对象必须满足)：\n- 完整性、不断章取义：任何你写出的问题/命题/结论都要给出完整陈述，并把它所依赖的对象、环境、背景、定义全部补全（例如提到某个序列/函数/定理时给出其完整定义与假设）。\n- 引用溯源：若你引用了 qs/qs.json、Propos/、Verified/、Reliable/ 中已有的命题/引理/结论/解法，必须给出出处——具体文件路径（相对项目根，如 Propos/数论_Propos.json 或 Verified/未分类_Verified.json）+ 对象 id 或 JSON 路径（如 .证明列表[0] 或 .directions[1]）；没有出处的引用一律不允许。你自己新提出的结论则必须自带完整定义，不得引用未定义的内容。\n- 若结论依赖某个临时假设 p，必须显式写成「若 <p 的完整陈述> 成立，则：...」（同样要定义完整）。\n- 只输出规定的 JSON（放在 ```json 代码围栏内），JSON 之外不写任何内容。\n- 示例（完整问题 概述）：\"设 {a_n} 为非负实数序列（n≥1），满足：对任意正整数 n 都存在 i,j 使 |a_i − a_j| = 1/n^p（p>0 为实参数）。判断：p 在什么范围内保证级数 ∑_{n=1}^∞ a_n 发散？\" —— 每个记号（序列、参数、级数）都在句内定义完整，读它的人无需再查背景。\n- 示例（完整命题 概述）：\"设函数 f:[0,1]→R 连续，则 f 在 [0,1] 上有界（连续性按 ε-δ 定义，有界性按标准实数分析定义）。\" —— 概念与对象定义完整，不引用未定义的记号。\n\n\nYOUR PERMISSIONS / CAPABILITIES:\n- Network tools (web search / fetch): available; Script/shell tools (bash/pwsh): available (your actual tool list is enforced by the framework).\n- You may use external tools (web search / literature lookup, symbolic/numeric computation (running scripts)) to assist; no per-round limit by default.\n- You may READ any file under Verified/ as a known, trusted dependency (resolved facts).\n- You should BASE your reasoning on the existing knowledge under Propos/ (propositions with proofs/refutations and probabilities) and Reliable/ (trusted references).\n- You must NOT write files directly: return structured JSON only — the scheduler is the single writer.\n\nHOW TO READ EXISTING KNOWLEDGE (coarse scan → fine read):\n- These are JSON files. A conclusion object carries summary-index fields (概述 / 布尔估计 / 优先级) and the full detail (证明列表 / 证伪列表 / 完整过程 / progress).\n- COARSE SCAN first: use a read/grep tool to extract ONLY the summary index (概述, 布尔估计, 优先级, titles) to locate which files / objects look relevant — do NOT load full proofs yet.\n- FINE READ after: once you identify a valuable object, read that file again and extract its full JSON (完整过程 / 证明 / 证伪 / progress) via the index you found.\n\n【顺手形式化（强制）】把你工作中常用或可能复用的对象、假设、新定义用 Lean 形式化定义并归档到全局可复用库（vibe_math_lean_archive kind='def'），已成立的引理归到 <VIBEMATH>/Formal/Proved/（kind='lemma'）；写之前先 vibe_math_lean_lib 查重，避免重复定义。归档前先跑通（vibe_math_lean_run 或 run=true）；跑不通的定义不要进可复用库。\n形式化回执（本模式）：若你本轮对某个对象做了形式化难度判断，或发现已有 Lean 证明与命题原文不符，请在回执里加上 \"formal\":{\"target\":\"<对象id>\",\"decision\":\"used|blocked|defect\",\"file\":\"Formal/<对象id>.lean\",\"note\":\"难度判断/阻塞原因/具体偏差\"}（decision='blocked'/'defect' 时必须写明 note，否则整条记录被拒绝；decision='defect' 会撤回该证明的「已通过」状态并写入「形式化待办」）。\n\nDo a first-stage METACOGNITIVE BRAINSTORM: decompose constraints, test boundary/extreme cases, map to similar known problems. Then propose 3-6 DIVERSE, mutually distinct solution directions (e.g. analytic method, constructive proof, contradiction, numeric approximation + limit passage, categorical abstraction, ...). Record each direction with its core assumption and an initial feasibility estimate.\n\nfeasibility ∈ [0,1]: your estimate of the probability this direction leads to a full solution. Every direction must be self-contained and unambiguous: title / method / core_assumption written completely, defining every object they mention — no 断章取义, no undefined symbols.\n\nRespond with ONLY a single JSON object wrapped in a ```json code fence — no prose and no braces { } outside the JSON:\n{\"directions\":[{\"id\":\"d1\",\"title\":\"...\",\"method\":\"...\",\"core_assumption\":\"...\",\"feasibility\":0.5}]}"
+    },
+    {
+      "kind": "spawn",
+      "case": "anchor-poison",
+      "label": "solver:qA:d1",
+      "prompt": "You are a dedicated solver agent working ONE solution direction of a math problem (agent_self_iteration).\n\nPROBLEM (id: qA): 锚点污染用例\nDIRECTION: D (method: m; core assumption: c)\nROUND: 1 of 3\n\nKNOWLEDGE BASE & DATA MODEL (definition contract you MUST follow):\n\n1) PROBABILITY SEMANTICS — the single most important rule:\n- 正确概率 / 布尔估计 ∈ [0,1]。\n- 1 = 绝对正确（已被证明且验证通过）：你可以把它当作已知事实/可信结论直接用于推理。\n- 0 = 绝对错误（已被证伪且验证通过）。\n- 0 与 1 之间的任何值 = 未定论/待验证：只能作为参考证据，绝不能当作已成立的事实引用。\n- Verified/ 中的卡片概率恒为 1 或 0，内容可信、可直接引用。\n\n2) OBJECT MODELS (按实现方案)：\n- 问题 PROBLEM（qs/qs.json）：{ id, 概述（完整问题陈述，所提到的每个对象/记号都要给出完整定义）, 已解决(bool), 解法列表:[{ 完整解法（详细步骤）, 正确概率, 已验 }], 优先级（整数，越小越优先调度；\"never\"=永不调度）, progress（历史：已试方向、各方向路线、阻碍及原因、教训、可行性评估）}。\n- 命题 PROPOSITION（Propos/<分类>_Propos.json）：{ id, 概述（完整陈述）, 布尔估计（该命题为真的概率）, 细类型（分类 JSON）, 证明列表:[{ 完整过程（完整证明）, 正确概率, 支持信息/依据 }], 证伪列表:[{ 完整过程（完整证伪）, 正确概率, 支持信息/依据 }], 优先级, 价值/关键性（0-1，重要性）, progress（过往尝试与教训）}。\n- 收口规则：问题的某个解法 正确概率=1 → 问题已解决；命题的证明/证伪条目 正确概率=1 → 命题布尔估计=1/0（已定论）。\n\n3) FOLDERS (per project, VibeMath/Projects/<project>/)：\n- qs/qs.json：问题清单——求解与验证的唯一问题来源。\n- Propos/<分类>_Propos.json：命题知识库（已有认知）。\n- Reliable/：可信参考文献（只读）。\n- Verified/<分类>_Verified.json：定论事实索引——布尔估计=0/1 的命题卡片与已解决问题卡片；内容可信、可直接使用。\n- Verification_logs/：辩论记录。Progress_Logs/：进度与报告。VibeMath_State/：调度器私有状态——不要读也不要改。\n\n4) OUTPUT REQUIREMENTS (你输出的每个对象必须满足)：\n- 完整性、不断章取义：任何你写出的问题/命题/结论都要给出完整陈述，并把它所依赖的对象、环境、背景、定义全部补全（例如提到某个序列/函数/定理时给出其完整定义与假设）。\n- 引用溯源：若你引用了 qs/qs.json、Propos/、Verified/、Reliable/ 中已有的命题/引理/结论/解法，必须给出出处——具体文件路径（相对项目根，如 Propos/数论_Propos.json 或 Verified/未分类_Verified.json）+ 对象 id 或 JSON 路径（如 .证明列表[0] 或 .directions[1]）；没有出处的引用一律不允许。你自己新提出的结论则必须自带完整定义，不得引用未定义的内容。\n- 若结论依赖某个临时假设 p，必须显式写成「若 <p 的完整陈述> 成立，则：...」（同样要定义完整）。\n- 只输出规定的 JSON（放在 ```json 代码围栏内），JSON 之外不写任何内容。\n- 示例（完整问题 概述）：\"设 {a_n} 为非负实数序列（n≥1），满足：对任意正整数 n 都存在 i,j 使 |a_i − a_j| = 1/n^p（p>0 为实参数）。判断：p 在什么范围内保证级数 ∑_{n=1}^∞ a_n 发散？\" —— 每个记号（序列、参数、级数）都在句内定义完整，读它的人无需再查背景。\n- 示例（完整命题 概述）：\"设函数 f:[0,1]→R 连续，则 f 在 [0,1] 上有界（连续性按 ε-δ 定义，有界性按标准实数分析定义）。\" —— 概念与对象定义完整，不引用未定义的记号。\n\n\nYOUR PERMISSIONS / CAPABILITIES:\n- Network tools (web search / fetch): available; Script/shell tools (bash/pwsh): available (your actual tool list is enforced by the framework).\n- You may use external tools (web search / literature lookup, symbolic/numeric computation (running scripts)) to assist; no per-round limit by default.\n- You may READ any file under Verified/ as a known, trusted dependency (resolved facts).\n- You should BASE your reasoning on the existing knowledge under Propos/ (propositions with proofs/refutations and probabilities) and Reliable/ (trusted references).\n- You must NOT write files directly: return structured JSON only — the scheduler is the single writer.\n\nHOW TO READ EXISTING KNOWLEDGE (coarse scan → fine read):\n- These are JSON files. A conclusion object carries summary-index fields (概述 / 布尔估计 / 优先级) and the full detail (证明列表 / 证伪列表 / 完整过程 / progress).\n- COARSE SCAN first: use a read/grep tool to extract ONLY the summary index (概述, 布尔估计, 优先级, titles) to locate which files / objects look relevant — do NOT load full proofs yet.\n- FINE READ after: once you identify a valuable object, read that file again and extract its full JSON (完整过程 / 证明 / 证伪 / progress) via the index you found.\n\n【顺手形式化（强制）】把你工作中常用或可能复用的对象、假设、新定义用 Lean 形式化定义并归档到全局可复用库（vibe_math_lean_archive kind='def'），已成立的引理归到 <VIBEMATH>/Formal/Proved/（kind='lemma'）；写之前先 vibe_math_lean_lib 查重，避免重复定义。归档前先跑通（vibe_math_lean_run 或 run=true）；跑不通的定义不要进可复用库。\n形式化回执（本模式）：若你本轮对某个对象做了形式化难度判断，或发现已有 Lean 证明与命题原文不符，请在回执里加上 \"formal\":{\"target\":\"<对象id>\",\"decision\":\"used|blocked|defect\",\"file\":\"Formal/<对象id>.lean\",\"note\":\"难度判断/阻塞原因/具体偏差\"}（decision='blocked'/'defect' 时必须写明 note，否则整条记录被拒绝；decision='defect' 会撤回该证明的「已通过」状态并写入「形式化待办」）。\n\nStart from the last recorded node of direction d1 (inherit progress, or branch a sub-route under it). Each round you MUST produce, even if incomplete:\n- new lemmas / intermediate conclusions WITH full proofs (these go to the Propos/ knowledge base);\n- each concrete sub-route tried, its progress overview, an EXPLICIT feasibility signal (e.g. \"unremovable singularity\", \"conflicts with known theorem X\"), and any blocker;\n- lessons learned from failed attempts (what to avoid, what did not work and why);\n- an updated survival probability for this direction.\n\nIf you encounter an EXTREMELY complex auxiliary conjecture/sub-problem q_sub: list it in \"sub_questions\" as a PROBLEM-class object with its COMPLETE statement (every object/definition/notation it mentions must be fully defined — never quote partially, 不断章取义), together with p_{q-tmp}: a PROPOSITION-class TEMPORARY ASSUMPTION that is one possible answer to q_sub. TEMPORARILY ASSUME p_{q-tmp} holds and continue the main line — every later proposition/conclusion that depends on this assumption MUST be stated as \"若 <p_{q-tmp} 的完整陈述> 成立，则：...\" (with complete definitions). The scheduler registers q_sub and the problem \"判断下述命题是否成立：p_{q-tmp}\" in the problem list, and p_{q-tmp} in the proposition base.\n\nIMPORTANT — PROBABILITY RULES FOR NEW RESULTS: any 布尔估计 / solution_probability / survival_probability you output for NEW results must be strictly BETWEEN 0 and 1 (they await independent verifier confirmation). NEVER mark your own fresh lemma or solution as 1 or 0 — that is the verifiers' job. Only facts already recorded in Verified/ (or 正确概率=1 entries you READ from files) count as certain.\n- Each lemma you output must carry a COMPLETE statement (\"statement\") and a COMPLETE proof (\"proof\"): define every object/notation it uses — no 断章取义, no undefined symbols. If a lemma/conclusion references or is derived from existing knowledge (Propos/Verified/Reliable/qs files), state the source file path + object id / JSON path inside the statement — no unsourced references.\n\nIf you obtain a COMPLETE solution: adversarially self-check (construct counterexamples, test boundary conditions) BEFORE declaring success; put the full solution text in \"solution\".\n\nRespond with ONLY a single JSON object wrapped in a ```json code fence — no prose and no braces { } outside the JSON:\n{\"status\":\"continue|success|dead-end\",\"solution\":\"complete solution text, or null\",\"solution_probability\":0.85,\"lemmas\":[{\"title\":\"...\",\"statement\":\"...\",\"proof\":\"...\",\"细类型\":{\"分类名\":{}},\"布尔估计\":0.6,\"价值/关键性\":0.5,\"优先级\":1}],\"routes\":[{\"title\":\"...\",\"progress\":\"...\",\"feasibility_signal\":\"...\",\"blocker\":\"...\"}],\"lessons\":[\"...\"],\"survival_probability\":0.5,\"dead_end_reason\":\"... or null\",\"sub_questions\":[{\"q_sub_title\":\"...\",\"q_sub_statement\":\"完整问题陈述(含所有对象/定义)\",\"assumption_title\":\"p_{q-tmp} 标题\",\"assumption_statement\":\"完整假设陈述(含所有定义)\"}]}"
+    },
     {
       "kind": "spawn",
       "case": "judge-gate",

package/prompt-corpus-v2/formal-verify-v2.md

@@ -5177,7 +5177,139 @@ Independently output your initial review. Respond with ONLY a single JSON object
 {"Result":0.5,"Reason":"detailed logic chain, potential counterexample, or supporting evidence","formal":{"target":"r-pAmb-s1","decision":"used|blocked|defect","file":"Formal/r-pAmb-s1.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [79] spawn · verifier:r-qJudge-s0:0 · case=judge-gate
+## [79] spawn · explorer:qA · case=anchor-poison
+
+```text
+You are a research mathematician orchestrating strategy for one problem.
+
+PROBLEM (id: qA): 锚点污染用例
+
+
+KNOWLEDGE BASE & DATA MODEL (definition contract you MUST follow):
+
+1) PROBABILITY SEMANTICS — the single most important rule:
+- 正确概率 / 布尔估计 ∈ [0,1]。
+- 1 = 绝对正确（已被证明且验证通过）：你可以把它当作已知事实/可信结论直接用于推理。
+- 0 = 绝对错误（已被证伪且验证通过）。
+- 0 与 1 之间的任何值 = 未定论/待验证：只能作为参考证据，绝不能当作已成立的事实引用。
+- Verified/ 中的卡片概率恒为 1 或 0，内容可信、可直接引用。
+
+2) OBJECT MODELS (按实现方案)：
+- 问题 PROBLEM（qs/qs.json）：{ id, 概述（完整问题陈述，所提到的每个对象/记号都要给出完整定义）, 已解决(bool), 解法列表:[{ 完整解法（详细步骤）, 正确概率, 已验 }], 优先级（整数，越小越优先调度；"never"=永不调度）, progress（历史：已试方向、各方向路线、阻碍及原因、教训、可行性评估）}。
+- 命题 PROPOSITION（Propos/<分类>_Propos.json）：{ id, 概述（完整陈述）, 布尔估计（该命题为真的概率）, 细类型（分类 JSON）, 证明列表:[{ 完整过程（完整证明）, 正确概率, 支持信息/依据 }], 证伪列表:[{ 完整过程（完整证伪）, 正确概率, 支持信息/依据 }], 优先级, 价值/关键性（0-1，重要性）, progress（过往尝试与教训）}。
+- 收口规则：问题的某个解法 正确概率=1 → 问题已解决；命题的证明/证伪条目 正确概率=1 → 命题布尔估计=1/0（已定论）。
+
+3) FOLDERS (per project, VibeMath/Projects/<project>/)：
+- qs/qs.json：问题清单——求解与验证的唯一问题来源。
+- Propos/<分类>_Propos.json：命题知识库（已有认知）。
+- Reliable/：可信参考文献（只读）。
+- Verified/<分类>_Verified.json：定论事实索引——布尔估计=0/1 的命题卡片与已解决问题卡片；内容可信、可直接使用。
+- Verification_logs/：辩论记录。Progress_Logs/：进度与报告。VibeMath_State/：调度器私有状态——不要读也不要改。
+
+4) OUTPUT REQUIREMENTS (你输出的每个对象必须满足)：
+- 完整性、不断章取义：任何你写出的问题/命题/结论都要给出完整陈述，并把它所依赖的对象、环境、背景、定义全部补全（例如提到某个序列/函数/定理时给出其完整定义与假设）。
+- 引用溯源：若你引用了 qs/qs.json、Propos/、Verified/、Reliable/ 中已有的命题/引理/结论/解法，必须给出出处——具体文件路径（相对项目根，如 Propos/数论_Propos.json 或 Verified/未分类_Verified.json）+ 对象 id 或 JSON 路径（如 .证明列表[0] 或 .directions[1]）；没有出处的引用一律不允许。你自己新提出的结论则必须自带完整定义，不得引用未定义的内容。
+- 若结论依赖某个临时假设 p，必须显式写成「若 <p 的完整陈述> 成立，则：...」（同样要定义完整）。
+- 只输出规定的 JSON（放在 ```json 代码围栏内），JSON 之外不写任何内容。
+- 示例（完整问题 概述）："设 {a_n} 为非负实数序列（n≥1），满足：对任意正整数 n 都存在 i,j 使 |a_i − a_j| = 1/n^p（p>0 为实参数）。判断：p 在什么范围内保证级数 ∑_{n=1}^∞ a_n 发散？" —— 每个记号（序列、参数、级数）都在句内定义完整，读它的人无需再查背景。
+- 示例（完整命题 概述）："设函数 f:[0,1]→R 连续，则 f 在 [0,1] 上有界（连续性按 ε-δ 定义，有界性按标准实数分析定义）。" —— 概念与对象定义完整，不引用未定义的记号。
+
+
+YOUR PERMISSIONS / CAPABILITIES:
+- Network tools (web search / fetch): available; Script/shell tools (bash/pwsh): available (your actual tool list is enforced by the framework).
+- You may use external tools (web search / literature lookup, symbolic/numeric computation (running scripts)) to assist; no per-round limit by default.
+- You may READ any file under Verified/ as a known, trusted dependency (resolved facts).
+- You should BASE your reasoning on the existing knowledge under Propos/ (propositions with proofs/refutations and probabilities) and Reliable/ (trusted references).
+- You must NOT write files directly: return structured JSON only — the scheduler is the single writer.
+
+HOW TO READ EXISTING KNOWLEDGE (coarse scan → fine read):
+- These are JSON files. A conclusion object carries summary-index fields (概述 / 布尔估计 / 优先级) and the full detail (证明列表 / 证伪列表 / 完整过程 / progress).
+- COARSE SCAN first: use a read/grep tool to extract ONLY the summary index (概述, 布尔估计, 优先级, titles) to locate which files / objects look relevant — do NOT load full proofs yet.
+- FINE READ after: once you identify a valuable object, read that file again and extract its full JSON (完整过程 / 证明 / 证伪 / progress) via the index you found.
+
+【顺手形式化（强制）】把你工作中常用或可能复用的对象、假设、新定义用 Lean 形式化定义并归档到全局可复用库（vibe_math_lean_archive kind='def'），已成立的引理归到 <VIBEMATH>/Formal/Proved/（kind='lemma'）；写之前先 vibe_math_lean_lib 查重，避免重复定义。归档前先跑通（vibe_math_lean_run 或 run=true）；跑不通的定义不要进可复用库。
+形式化回执（本模式）：若你本轮对某个对象做了形式化难度判断，或发现已有 Lean 证明与命题原文不符，请在回执里加上 "formal":{"target":"<对象id>","decision":"used|blocked|defect","file":"Formal/<对象id>.lean","note":"难度判断/阻塞原因/具体偏差"}（decision='blocked'/'defect' 时必须写明 note，否则整条记录被拒绝；decision='defect' 会撤回该证明的「已通过」状态并写入「形式化待办」）。
+
+Do a first-stage METACOGNITIVE BRAINSTORM: decompose constraints, test boundary/extreme cases, map to similar known problems. Then propose 3-6 DIVERSE, mutually distinct solution directions (e.g. analytic method, constructive proof, contradiction, numeric approximation + limit passage, categorical abstraction, ...). Record each direction with its core assumption and an initial feasibility estimate.
+
+feasibility ∈ [0,1]: your estimate of the probability this direction leads to a full solution. Every direction must be self-contained and unambiguous: title / method / core_assumption written completely, defining every object they mention — no 断章取义, no undefined symbols.
+
+Respond with ONLY a single JSON object wrapped in a ```json code fence — no prose and no braces { } outside the JSON:
+{"directions":[{"id":"d1","title":"...","method":"...","core_assumption":"...","feasibility":0.5}]}
+```
+
+## [80] spawn · solver:qA:d1 · case=anchor-poison
+
+```text
+You are a dedicated solver agent working ONE solution direction of a math problem (agent_self_iteration).
+
+PROBLEM (id: qA): 锚点污染用例
+DIRECTION: D (method: m; core assumption: c)
+ROUND: 1 of 3
+
+KNOWLEDGE BASE & DATA MODEL (definition contract you MUST follow):
+
+1) PROBABILITY SEMANTICS — the single most important rule:
+- 正确概率 / 布尔估计 ∈ [0,1]。
+- 1 = 绝对正确（已被证明且验证通过）：你可以把它当作已知事实/可信结论直接用于推理。
+- 0 = 绝对错误（已被证伪且验证通过）。
+- 0 与 1 之间的任何值 = 未定论/待验证：只能作为参考证据，绝不能当作已成立的事实引用。
+- Verified/ 中的卡片概率恒为 1 或 0，内容可信、可直接引用。
+
+2) OBJECT MODELS (按实现方案)：
+- 问题 PROBLEM（qs/qs.json）：{ id, 概述（完整问题陈述，所提到的每个对象/记号都要给出完整定义）, 已解决(bool), 解法列表:[{ 完整解法（详细步骤）, 正确概率, 已验 }], 优先级（整数，越小越优先调度；"never"=永不调度）, progress（历史：已试方向、各方向路线、阻碍及原因、教训、可行性评估）}。
+- 命题 PROPOSITION（Propos/<分类>_Propos.json）：{ id, 概述（完整陈述）, 布尔估计（该命题为真的概率）, 细类型（分类 JSON）, 证明列表:[{ 完整过程（完整证明）, 正确概率, 支持信息/依据 }], 证伪列表:[{ 完整过程（完整证伪）, 正确概率, 支持信息/依据 }], 优先级, 价值/关键性（0-1，重要性）, progress（过往尝试与教训）}。
+- 收口规则：问题的某个解法 正确概率=1 → 问题已解决；命题的证明/证伪条目 正确概率=1 → 命题布尔估计=1/0（已定论）。
+
+3) FOLDERS (per project, VibeMath/Projects/<project>/)：
+- qs/qs.json：问题清单——求解与验证的唯一问题来源。
+- Propos/<分类>_Propos.json：命题知识库（已有认知）。
+- Reliable/：可信参考文献（只读）。
+- Verified/<分类>_Verified.json：定论事实索引——布尔估计=0/1 的命题卡片与已解决问题卡片；内容可信、可直接使用。
+- Verification_logs/：辩论记录。Progress_Logs/：进度与报告。VibeMath_State/：调度器私有状态——不要读也不要改。
+
+4) OUTPUT REQUIREMENTS (你输出的每个对象必须满足)：
+- 完整性、不断章取义：任何你写出的问题/命题/结论都要给出完整陈述，并把它所依赖的对象、环境、背景、定义全部补全（例如提到某个序列/函数/定理时给出其完整定义与假设）。
+- 引用溯源：若你引用了 qs/qs.json、Propos/、Verified/、Reliable/ 中已有的命题/引理/结论/解法，必须给出出处——具体文件路径（相对项目根，如 Propos/数论_Propos.json 或 Verified/未分类_Verified.json）+ 对象 id 或 JSON 路径（如 .证明列表[0] 或 .directions[1]）；没有出处的引用一律不允许。你自己新提出的结论则必须自带完整定义，不得引用未定义的内容。
+- 若结论依赖某个临时假设 p，必须显式写成「若 <p 的完整陈述> 成立，则：...」（同样要定义完整）。
+- 只输出规定的 JSON（放在 ```json 代码围栏内），JSON 之外不写任何内容。
+- 示例（完整问题 概述）："设 {a_n} 为非负实数序列（n≥1），满足：对任意正整数 n 都存在 i,j 使 |a_i − a_j| = 1/n^p（p>0 为实参数）。判断：p 在什么范围内保证级数 ∑_{n=1}^∞ a_n 发散？" —— 每个记号（序列、参数、级数）都在句内定义完整，读它的人无需再查背景。
+- 示例（完整命题 概述）："设函数 f:[0,1]→R 连续，则 f 在 [0,1] 上有界（连续性按 ε-δ 定义，有界性按标准实数分析定义）。" —— 概念与对象定义完整，不引用未定义的记号。
+
+
+YOUR PERMISSIONS / CAPABILITIES:
+- Network tools (web search / fetch): available; Script/shell tools (bash/pwsh): available (your actual tool list is enforced by the framework).
+- You may use external tools (web search / literature lookup, symbolic/numeric computation (running scripts)) to assist; no per-round limit by default.
+- You may READ any file under Verified/ as a known, trusted dependency (resolved facts).
+- You should BASE your reasoning on the existing knowledge under Propos/ (propositions with proofs/refutations and probabilities) and Reliable/ (trusted references).
+- You must NOT write files directly: return structured JSON only — the scheduler is the single writer.
+
+HOW TO READ EXISTING KNOWLEDGE (coarse scan → fine read):
+- These are JSON files. A conclusion object carries summary-index fields (概述 / 布尔估计 / 优先级) and the full detail (证明列表 / 证伪列表 / 完整过程 / progress).
+- COARSE SCAN first: use a read/grep tool to extract ONLY the summary index (概述, 布尔估计, 优先级, titles) to locate which files / objects look relevant — do NOT load full proofs yet.
+- FINE READ after: once you identify a valuable object, read that file again and extract its full JSON (完整过程 / 证明 / 证伪 / progress) via the index you found.
+
+【顺手形式化（强制）】把你工作中常用或可能复用的对象、假设、新定义用 Lean 形式化定义并归档到全局可复用库（vibe_math_lean_archive kind='def'），已成立的引理归到 <VIBEMATH>/Formal/Proved/（kind='lemma'）；写之前先 vibe_math_lean_lib 查重，避免重复定义。归档前先跑通（vibe_math_lean_run 或 run=true）；跑不通的定义不要进可复用库。
+形式化回执（本模式）：若你本轮对某个对象做了形式化难度判断，或发现已有 Lean 证明与命题原文不符，请在回执里加上 "formal":{"target":"<对象id>","decision":"used|blocked|defect","file":"Formal/<对象id>.lean","note":"难度判断/阻塞原因/具体偏差"}（decision='blocked'/'defect' 时必须写明 note，否则整条记录被拒绝；decision='defect' 会撤回该证明的「已通过」状态并写入「形式化待办」）。
+
+Start from the last recorded node of direction d1 (inherit progress, or branch a sub-route under it). Each round you MUST produce, even if incomplete:
+- new lemmas / intermediate conclusions WITH full proofs (these go to the Propos/ knowledge base);
+- each concrete sub-route tried, its progress overview, an EXPLICIT feasibility signal (e.g. "unremovable singularity", "conflicts with known theorem X"), and any blocker;
+- lessons learned from failed attempts (what to avoid, what did not work and why);
+- an updated survival probability for this direction.
+
+If you encounter an EXTREMELY complex auxiliary conjecture/sub-problem q_sub: list it in "sub_questions" as a PROBLEM-class object with its COMPLETE statement (every object/definition/notation it mentions must be fully defined — never quote partially, 不断章取义), together with p_{q-tmp}: a PROPOSITION-class TEMPORARY ASSUMPTION that is one possible answer to q_sub. TEMPORARILY ASSUME p_{q-tmp} holds and continue the main line — every later proposition/conclusion that depends on this assumption MUST be stated as "若 <p_{q-tmp} 的完整陈述> 成立，则：..." (with complete definitions). The scheduler registers q_sub and the problem "判断下述命题是否成立：p_{q-tmp}" in the problem list, and p_{q-tmp} in the proposition base.
+
+IMPORTANT — PROBABILITY RULES FOR NEW RESULTS: any 布尔估计 / solution_probability / survival_probability you output for NEW results must be strictly BETWEEN 0 and 1 (they await independent verifier confirmation). NEVER mark your own fresh lemma or solution as 1 or 0 — that is the verifiers' job. Only facts already recorded in Verified/ (or 正确概率=1 entries you READ from files) count as certain.
+- Each lemma you output must carry a COMPLETE statement ("statement") and a COMPLETE proof ("proof"): define every object/notation it uses — no 断章取义, no undefined symbols. If a lemma/conclusion references or is derived from existing knowledge (Propos/Verified/Reliable/qs files), state the source file path + object id / JSON path inside the statement — no unsourced references.
+
+If you obtain a COMPLETE solution: adversarially self-check (construct counterexamples, test boundary conditions) BEFORE declaring success; put the full solution text in "solution".
+
+Respond with ONLY a single JSON object wrapped in a ```json code fence — no prose and no braces { } outside the JSON:
+{"status":"continue|success|dead-end","solution":"complete solution text, or null","solution_probability":0.85,"lemmas":[{"title":"...","statement":"...","proof":"...","细类型":{"分类名":{}},"布尔估计":0.6,"价值/关键性":0.5,"优先级":1}],"routes":[{"title":"...","progress":"...","feasibility_signal":"...","blocker":"..."}],"lessons":["..."],"survival_probability":0.5,"dead_end_reason":"... or null","sub_questions":[{"q_sub_title":"...","q_sub_statement":"完整问题陈述(含所有对象/定义)","assumption_title":"p_{q-tmp} 标题","assumption_statement":"完整假设陈述(含所有定义)"}]}
+```
+
+## [81] spawn · verifier:r-qJudge-s0:0 · case=judge-gate
 
 ```text
 You are a STRICT peer reviewer verifying one mathematical object. Check it multiple times.
@@ -5246,7 +5378,7 @@ Independently output your initial review. Respond with ONLY a single JSON object
 {"Result":0.5,"Reason":"detailed logic chain, potential counterexample, or supporting evidence","formal":{"target":"r-qJudge-s0","decision":"used|blocked|defect","file":"Formal/r-qJudge-s0.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [80] spawn · verifier:r-qJudge-s0:1 · case=judge-gate
+## [82] spawn · verifier:r-qJudge-s0:1 · case=judge-gate
 
 ```text
 You are a STRICT peer reviewer verifying one mathematical object. Check it multiple times.
@@ -5315,7 +5447,7 @@ Independently output your initial review. Respond with ONLY a single JSON object
 {"Result":0.5,"Reason":"detailed logic chain, potential counterexample, or supporting evidence","formal":{"target":"r-qJudge-s0","decision":"used|blocked|defect","file":"Formal/r-qJudge-s0.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [81] spawn · explorer:qJudge · case=judge-gate
+## [83] spawn · explorer:qJudge · case=judge-gate
 
 ```text
 You are a research mathematician orchestrating strategy for one problem.
@@ -5376,7 +5508,7 @@ Respond with ONLY a single JSON object wrapped in a ```json code fence — no pr
 {"directions":[{"id":"d1","title":"...","method":"...","core_assumption":"...","feasibility":0.5}]}
 ```
 
-## [82] spawn · explorer:qKeep · case=judge-gate
+## [84] spawn · explorer:qKeep · case=judge-gate
 
 ```text
 You are a research mathematician orchestrating strategy for one problem.
@@ -5437,7 +5569,7 @@ Respond with ONLY a single JSON object wrapped in a ```json code fence — no pr
 {"directions":[{"id":"d1","title":"...","method":"...","core_assumption":"...","feasibility":0.5}]}
 ```
 
-## [83] spawn · verifier:r-pJudgeSrc:0 · case=judge-gate
+## [85] spawn · verifier:r-pJudgeSrc:0 · case=judge-gate
 
 ```text
 You are a STRICT peer reviewer verifying one mathematical object. Check it multiple times.
@@ -5504,7 +5636,7 @@ Independently output your initial review. Respond with ONLY a single JSON object
 {"Result":0.5,"Reason":"detailed logic chain, potential counterexample, or supporting evidence","formal":{"target":"r-pJudgeSrc","decision":"used|blocked|defect","file":"Formal/r-pJudgeSrc.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [84] spawn · verifier:r-pJudgeSrc:1 · case=judge-gate
+## [86] spawn · verifier:r-pJudgeSrc:1 · case=judge-gate
 
 ```text
 You are a STRICT peer reviewer verifying one mathematical object. Check it multiple times.
@@ -5571,7 +5703,7 @@ Independently output your initial review. Respond with ONLY a single JSON object
 {"Result":0.5,"Reason":"detailed logic chain, potential counterexample, or supporting evidence","formal":{"target":"r-pJudgeSrc","decision":"used|blocked|defect","file":"Formal/r-pJudgeSrc.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [85] spawn · explorer:qKeep · case=used-keep
+## [87] spawn · explorer:qKeep · case=used-keep
 
 ```text
 You are a research mathematician orchestrating strategy for one problem.
@@ -5632,7 +5764,7 @@ Respond with ONLY a single JSON object wrapped in a ```json code fence — no pr
 {"directions":[{"id":"d1","title":"...","method":"...","core_assumption":"...","feasibility":0.5}]}
 ```
 
-## [86] spawn · verifier:r-pUsedKeep:0 · case=used-keep
+## [88] spawn · verifier:r-pUsedKeep:0 · case=used-keep
 
 ```text
 You are a STRICT peer reviewer verifying one mathematical object. Check it multiple times.
@@ -5700,7 +5832,7 @@ Independently output your initial review. Respond with ONLY a single JSON object
 {"Result":0.5,"Reason":"detailed logic chain, potential counterexample, or supporting evidence","formal":{"target":"r-pUsedKeep","decision":"used|blocked|defect","file":"Formal/r-pUsedKeep.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [87] spawn · verifier:r-pUsedKeep:1 · case=used-keep
+## [89] spawn · verifier:r-pUsedKeep:1 · case=used-keep
 
 ```text
 You are a STRICT peer reviewer verifying one mathematical object. Check it multiple times.
@@ -5768,7 +5900,7 @@ Independently output your initial review. Respond with ONLY a single JSON object
 {"Result":0.5,"Reason":"detailed logic chain, potential counterexample, or supporting evidence","formal":{"target":"r-pUsedKeep","decision":"used|blocked|defect","file":"Formal/r-pUsedKeep.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [88] wake · verifier:r-pUsedKeep:0 · case=used-keep
+## [90] wake · verifier:r-pUsedKeep:0 · case=used-keep
 
 ```text
 You are one reviewer in a DEBATE ("交流群") about this object.
@@ -5840,7 +5972,7 @@ Respond with ONLY a single JSON object wrapped in a ```json code fence — no pr
 {"Result":0.5,"Reason":"updated logic chain / counterexample / proof / refutation","changed":"brief reason if you changed your Result, else null","formal":{"target":"r-pUsedKeep","decision":"used|blocked|defect","file":"Formal/r-pUsedKeep.lean","note":"难度判断/阻塞原因/具体偏差"}}
 ```
 
-## [89] wake · verifier:r-pUsedKeep:1 · case=used-keep
+## [91] wake · verifier:r-pUsedKeep:1 · case=used-keep
 
 ```text
 You are one reviewer in a DEBATE ("交流群") about this object.

package/vibe-math-v2/vibe-math-v2.js

@@ -645,7 +645,8 @@ export function apply(ctx) {
         syncedFrom: objectId,
         // 这条路径**手里就有**权威的对象 id，把它写进记录：`formalObjectIdOf` 在任务表不在内存时
         // （resume 早期）靠它把验证 id 映射回对象，而不是去猜后缀（对象 id 可能自己以 -sN 结尾）。
-        objectId: objectId,
+        // 依旧只在它**确实是对象 id** 时写（调用方也可能把 rId 传进来，例如"归档写在 rId 上"）。
+        ...(formalObjectIdOfIsOwner(objectId) ? { objectId: objectId } : {}),
         updatedAt: now(),
       }))
     }
@@ -658,12 +659,16 @@ export function apply(ctx) {
    *
    * **权威来源优先**（两级，都能跨 resume 生效）：
    *   ① 验证任务自己知道它属于哪个对象（`t.r.pId` / `t.r.qid`）；
-   *   ② 记录里记着的 `objectId`（写记录时由**拿到对象 id 的那条路径**写上，见 `syncVerificationTarget`）。
+   *   ② 记录里记着的 `objectId`（写记录时由**拿到对象 id 的那条路径**写上）。
    * 只靠字符串后缀解析会有歧义：**对象 id 本身以 `-s1`/`-pf1`/`-rf1` 结尾**时（例如命题 `pAmb-s1` 的
    * 验证 id 是 `r-pAmb-s1`），后缀剥离会把对象截成 `pAmb` —— 另一个对象。后果不是"少一条记录"而是
    * **张冠李戴**：忠实性提示词会打印邻居的证明路径、`defect` 回执会降级邻居的记录并**撤回邻居的归档
    * 证明**，而真正的对象仍然 `passed`（实测复现，见 `formal-verify-v2` 的 ambiguity 用例）。
    * 字符串解析只是前两者都不可用时的兜底。
+   *
+   * 记录里的 `objectId` 还要求**自洽**（它自己再映射一次还是它自己）：否则一次"归档写在 rId 上"的
+   * 调用会把 `objectId: 'r-pAlias'` 写进记录，之后（任务表已不在内存时）这个错误的锚点反而会覆盖
+   * 正确的后缀解析结果。
    */
   function formalObjectIdOf(id) {
     const t = safeId(String(id == null ? '' : id))
@@ -673,10 +678,15 @@ export function apply(ctx) {
       if (owner) return safeId(owner)
     }
     const rec = formalRecords()[t]
-    if (rec && rec.objectId) return safeId(rec.objectId)
+    if (rec && rec.objectId && formalObjectIdOfIsOwner(rec.objectId)) return safeId(rec.objectId)
     const m = /^r-(.+?)(?:-(?:s\d+|pf\d+|rf\d+))?$/.exec(t)
     return m ? m[1] : t
   }
+  /** 一个 id 能否作为"对象 id"落进记录：它不能再被解析成别的 id（对象 id 不以 `r-` 开头）。 */
+  function formalObjectIdOfIsOwner(v) {
+    const s = safeId(String(v == null ? '' : v))
+    return !!s && s.indexOf('r-') !== 0
+  }
   /**
    * 门禁/提示词看到的对象状态 = 合并后的记录，**两个方向都要认**，因为 v2 里归档与验证
    * 用的是两套 id，而代理两种写法都会用：
@@ -709,8 +719,10 @@ export function apply(ctx) {
     if (!t) return []
     const objectId = formalObjectIdOf(t)
     // 记录里写上权威对象 id：验证 id 的那条记录从此**自带**它属于谁，`formalObjectIdOf` 不必再猜
-    // （对象 id 本身可能以 -sN/-pfN/-rfN 结尾，后缀剥离会指向另一个对象）。
-    const withOwner = (t === objectId) ? patch : Object.assign({ objectId: objectId }, patch)
+    // （对象 id 本身可能以 -sN/-pfN/-rfN 结尾，后缀剥离会指向另一个对象）。只有当这个 id **确实
+    // 是对象 id**（不以 r- 开头）时才写，免得把 `objectId:'r-pAlias'` 这种错锚点固化进记录。
+    const withOwner = (t !== objectId && formalObjectIdOfIsOwner(objectId))
+      ? Object.assign({ objectId: objectId }, patch) : patch
     const written = []
     const write = async function (k) {
       if (written.indexOf(k) !== -1) return

package/vibe-math-v2//345/256/236/347/216/260/346/226/271/346/241/210.md

@@ -410,7 +410,8 @@ v2 **没有会话投影**，所以记录与待办一起持久化在 v2 自己的
 
 1. 验证任务自己的所有者（`tasks['verify:'+rId].r.pId | qid`）——框架生成 rId 时就知道对象是谁；
 2. 记录里的 `objectId`（`syncVerificationTarget` 与 `putFormalBothIds` 在**手里有对象 id** 时写入，
-   因此跨 resume、任务表还没重建时也正确）；
+   因此跨 resume、任务表还没重建时也正确）——但读出来时要求**自洽**（不以 `r-` 开头）：状态文件是可以
+   被人改的，一个 r 形锚点会让"验证 id → 对象 id"映射到它自己，于是"两套 id 一起写"退化成只写一侧；
 3. 只有在两者都不可用时，才回退到字符串后缀解析。
 
 #### 9.4 提示词的三条硬要求