dsh-vibe-math 2.3.7 → 2.3.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/AUDIT-CHECKLIST.md
CHANGED
|
@@ -153,6 +153,11 @@ v2/v3/v4/v5 是**同构实现**(同一份契约、四份独立代码,刻意
|
|
|
153
153
|
|
|
154
154
|
- [ ] 该映射是否优先使用**权威来源**(框架生成 id 时就知道的归属)?
|
|
155
155
|
- [ ] 权威来源不在内存时(resume 早期),记录里是否**持久化**了 `objectId` 可查?
|
|
156
|
+
- [ ] **从用户可编辑的状态文件里读出来的"权威值"是否先做了自洽校验?** 状态文件(如
|
|
157
|
+
`VibeMath_State/formal.json`)是可以被人改的:**真实事故(2.3.7)**——某条记录的 `objectId`
|
|
158
|
+
被写成 r 形(`r-pX`)时,"验证 id → 对象 id"会映射到**它自己**,于是"两套 id 一起写"退化成
|
|
159
|
+
只写验证侧、对象侧仍是 `passed`。修法:锚点必须自洽(不以 `r-` 开头)才可用,读与写两处都校验;
|
|
160
|
+
灵敏度探针见 `_oneoff/probe-v2-anchor-guard.mjs`(去掉守卫 → 用例变红)。
|
|
156
161
|
- [ ] 字符串解析是否只作为**兜底**,而不是唯一手段?
|
|
157
162
|
- [ ] **真实事故(2.3.6)**:`formalObjectIdOf` 无条件剥离 `-sN/-pfN/-rfN`,于是命题 `pAmb-s1` 的
|
|
158
163
|
验证 id `r-pAmb-s1` 被解析成对象 `pAmb`;一句 `defect` 于是降级并**撤回了 `pAmb` 的归档证明**,
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# dsh-vibe-math 2.3.8 — 把 round 7/8 的结论写进契约与审计清单(文档版)
|
|
2
|
+
|
|
3
|
+
> 上一版:2.3.7。本版**只改文档**(无代码、无预设字节变化):把 2.3.6/2.3.7 发现的边界与规则写进
|
|
4
|
+
> 共享契约与强制审计流程,免得下一轮审计重新把它当"新问题"或按另一种方式改。
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## 1. 契约 §4:补两条边界
|
|
9
|
+
|
|
10
|
+
- **记录与归档文件同生共死(框架侧),但外部文件操作不会自动改记录**:框架撤回证明时记录降级与文件
|
|
11
|
+
撤回是**同一次操作**;反过来,**外部**删掉 `Verified/Lean/<id>.lean` **不会**自动把记录降级——
|
|
12
|
+
`passed` 是状态文件里的权威状态,门禁查询是只读的,不会在每次取记录时做文件存在性探测(那会把门禁
|
|
13
|
+
变成 fs I/O,并在网络盘/权限异常时引入新的失败模式)。人工动过文件后请一并修正记录或重新归档。
|
|
14
|
+
- **v2 的 id 映射同理**:记录里持久化的 `objectId` 是权威锚点,但必须**自洽**(不以 `r-` 开头)才被
|
|
15
|
+
采纳,否则回退到后缀解析——状态文件可编辑,里面的"权威值"要先校验。
|
|
16
|
+
|
|
17
|
+
## 2. `AUDIT-CHECKLIST` §1.10:补一条检查项
|
|
18
|
+
|
|
19
|
+
> **从用户可编辑的状态文件里读出来的"权威值"是否先做了自洽校验?**
|
|
20
|
+
> 真实事故(2.3.7):某条记录的 `objectId` 被写成 r 形时,"验证 id → 对象 id"映射到它自己,
|
|
21
|
+
> "两套 id 一起写"退化成只写验证侧、对象侧仍是 `passed`。
|
|
22
|
+
|
|
23
|
+
(§1.10 是 2.3.6 新增的章节「id 映射不许猜」,本版把它与 2.3.7 的教训合并成完整检查项。)
|
|
24
|
+
|
|
25
|
+
## 3. v2 实现方案 §9.3:同步自洽条件
|
|
26
|
+
|
|
27
|
+
`formalObjectIdOf` 的权威度顺序里,第 ② 级(记录里的 `objectId`)补上"读出时要求自洽"的条件。
|
|
28
|
+
|
|
29
|
+
## 4. 验收
|
|
30
|
+
|
|
31
|
+
| 项 | 结果 |
|
|
32
|
+
|---|---|
|
|
33
|
+
| 代码/预设字节变化 | **无**(四套 `.js` 与 2.3.7 逐字节相同) |
|
|
34
|
+
| 全量并行回归 | 23/23 |
|
|
35
|
+
| 静态守卫 | invariants 157/0(self-probe 5/5)、traceability 94/0、v5-integrity clean |
|
|
36
|
+
| 四套语料确定性 | 字节稳定 |
|
|
37
|
+
| closing verification | 18/18 |
|
|
38
|
+
|
|
39
|
+
## 5. 升级
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
npm i dsh-vibe-math@latest
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
无迁移、无行为变更。
|
|
@@ -150,6 +150,14 @@
|
|
|
150
150
|
| **回执里 `formal:{target, decision:'defect', note}`** | **撤回 `passed`:→ `attempted`,清空 `proof`、删除 `Verified/Lean/<id>.lean`、把 `note` 写入记录与 `Formal/TODO.md`、公告**(`note` 必填) |
|
|
151
151
|
| 回执里 `formal:{target, decision:'used', file}` | → `attempted`(记录文件);**若该对象已是 `passed`/`blocked` 则保持原状**——一次"这一轮碰了形式化"的 `used` 回执**不得**撤销已成立的证明(`proof` 指针与归档文件都不变)。撤销只有 `defect` 一条路(§4.1)。 |
|
|
152
152
|
|
|
153
|
+
> **记录与归档文件同生共死(框架侧),但外部文件操作不会自动改记录**:框架自己撤回证明时,记录降级与
|
|
154
|
+
> 文件撤回是**同一次操作**(§4.1 的删除 → 复核 → 覆写)。反过来,**外部**(人、别的工具、另一个项目)
|
|
155
|
+
> 删掉 `Verified/Lean/<id>.lean` **不会**自动改记录——`passed` 是状态文件里的权威状态,门禁查询是只读的,
|
|
156
|
+
> 不会在每次取记录时做文件存在性探测(那会把门禁变成 fs I/O,并在网络盘/权限异常时引入新的失败模式)。
|
|
157
|
+
> 因此人工动过文件后请一并修正记录,或重新 `lean_archive`;否则门禁仍按 `passed` 放行,忠实性提示词会
|
|
158
|
+
> 打印一个已不存在的路径。**v2 的 id 映射同样如此**:记录里持久化的 `objectId` 是权威锚点,但它必须
|
|
159
|
+
> **自洽**(不以 `r-` 开头),否则会被忽略并回退到后缀解析——状态文件是可编辑的,里面的"权威值"要先校验。
|
|
160
|
+
|
|
153
161
|
### 4.1 `defect`:忠实性缺陷**不是**"命题为假"
|
|
154
162
|
|
|
155
163
|
`passed` 只保证"这段 Lean 代码通过了内核检查",**不保证它说的就是命题想说的**。当表决者逐条核对后
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "dsh-vibe-math",
|
|
3
3
|
"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).",
|
|
4
|
-
"version": "2.3.
|
|
4
|
+
"version": "2.3.8",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"engines": {
|
|
7
7
|
"node": "^22.19.0 || >=24.0.0"
|
|
@@ -43,6 +43,7 @@
|
|
|
43
43
|
"RELEASE-NOTES-2.3.5.md",
|
|
44
44
|
"RELEASE-NOTES-2.3.6.md",
|
|
45
45
|
"RELEASE-NOTES-2.3.7.md",
|
|
46
|
+
"RELEASE-NOTES-2.3.8.md",
|
|
46
47
|
"selfdrive-v5.mjs",
|
|
47
48
|
"示例图/框架图-v5.svg",
|
|
48
49
|
"docs/架构图.md",
|
|
@@ -106,7 +107,7 @@
|
|
|
106
107
|
},
|
|
107
108
|
"minVersion": "0.1.2-rc.1",
|
|
108
109
|
"testedVersion": "0.1.5-rc.2",
|
|
109
|
-
"compatNote": "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 提示词完整性套件 + 可人工复核的提示词语料(随包发布)。",
|
|
110
|
+
"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 提示词完整性套件 + 可人工复核的提示词语料(随包发布)。",
|
|
110
111
|
"compatibility": {
|
|
111
112
|
"dshReleases": {
|
|
112
113
|
"0.1.2-alpha.4": "compatible",
|
|
@@ -410,7 +410,8 @@ v2 **没有会话投影**,所以记录与待办一起持久化在 v2 自己的
|
|
|
410
410
|
|
|
411
411
|
1. 验证任务自己的所有者(`tasks['verify:'+rId].r.pId | qid`)——框架生成 rId 时就知道对象是谁;
|
|
412
412
|
2. 记录里的 `objectId`(`syncVerificationTarget` 与 `putFormalBothIds` 在**手里有对象 id** 时写入,
|
|
413
|
-
因此跨 resume
|
|
413
|
+
因此跨 resume、任务表还没重建时也正确)——但读出来时要求**自洽**(不以 `r-` 开头):状态文件是可以
|
|
414
|
+
被人改的,一个 r 形锚点会让"验证 id → 对象 id"映射到它自己,于是"两套 id 一起写"退化成只写一侧;
|
|
414
415
|
3. 只有在两者都不可用时,才回退到字符串后缀解析。
|
|
415
416
|
|
|
416
417
|
#### 9.4 提示词的三条硬要求
|