dsh-vibe-math 2.2.1 → 2.3.0

package/AUDIT-CHECKLIST.md

@@ -76,6 +76,30 @@
 - [ ] 成员被解雇/失败后，还会不会收到后续消息？
 - [ ] 会话重建（resume）后的提示词，措辞是否与"新入职"区分开？
 
+### 1.6 静态提示词面：人设 ↔ 注册表
+
+1.1–1.5 检查的是**运行时逐条发出的**提示词；还有一层**静态**提示词面必须一起核对——
+`agent.cordis.yml` 的 persona 行。它是主代理收到的**唯一**一份"有哪些工具、能调哪些参数"的清单，
+而所有 e2e 套件都直接 `apply(ctx)`，**从不加载 YAML**，因此对这一层完全盲。
+
+- [ ] 注册的**每一个工具**是否在 persona（`prefix` 与 `text` **两个**块）里出现？
+      没出现 = 代理**无法发现**该能力（连准确名字都猜不到）。
+- [ ] persona 里出现的**每一个** `vibe_*` 名字是否都真的注册了？
+      出现但未注册 = 代理会去调用一个必然失败的工具。
+- [ ] 新参数是否同时进了 persona 与工具 description 的参数表？
+      （例：`formalVerify` / `leanCommand` / `leanArgs` / `leanTimeoutMs`）
+      参数没写进 prompt = 用户无法开启这个能力。
+- [ ] `prefix` 与 `text` 两个块是否**逐行一致**（只允许第 0 行不同）？
+      旧宿主读 `text`、新宿主读 `prefix`，两者漂移 = 不同宿主看到不同的工具面。
+- [ ] 工具**改名/删除**时 persona 是否同步？（"persona 提到的名字 ⊆ 注册表"这条反向检查负责抓）
+- [ ] 人设里写的路径/模式名（`Formal/Lib`、`off|encourage|require`）是否与实现中的字符串**逐字**一致？
+
+`audit-persona-surface.test.mjs` 把上述各条变成断言（"未文档化工具"用**显式快照**表示：
+新增工具必须主动改快照、或在 persona 里写清）；`audit-persona-sensitivity.mjs` 用 11 条探针
+证明这套断言真的会变红。**v2.3.0 修的就是这一类缺陷**：三个 `*_lean_*` 工具无条件注册，
+而 v2/v3/v4 的 persona 从未列出它们（只有 v5 列了），v4 的 `vibe_v4_set` 参数表也漏了
+`formalVerify`/`leanCommand`/`leanArgs`/`leanTimeoutMs`——当时**所有既有套件全绿**。
+
 ---
 
 ## 2. 第二优先：把上面每一条变成**会变红**的测试
@@ -120,12 +144,34 @@
       这类变异不能做探针——它会让审计误报"盲点"。
 - [ ] 探针**不得引入语法错误**：语法错误导致的非零退出同样是"假红"。
       每条变异都应能被 `node --check` 通过。
+- [ ] 守 **persona 静态面**的套件也要有探针，且该套件必须支持"指向副本"的环境变量
+      （`audit-persona-surface.test.mjs` 的 `PERSONA_ROOT`）：探针变异的是**副本**，
+      套件不读这个变量就永远在跑原始文件、恒为绿（同 §2.5 第二条）。
+      探针脚本还应在开跑前先确认"**未变异**的副本是绿的"，否则它探测到的可能是覆盖机制本身。
 - [ ] 对**不可达**的守卫（设计上互斥、永远不会进入的分支），**不要**留一个永远为绿的探针；
       要么写行为可观测的等价探针，要么显式删除并在脚本里注明原因。
 
 ---
 
-## 3. 第三优先：其余（沿用既有做法）
+## 3. 一个高效的补充手段：**把不变式写成文档/图，再拿它去对代码**
+
+本次修复中最后找到的一个真实缺陷（会议与验证的"互斥"只做了单向）就是这么被发现的：
+为 v5 画架构图时，被迫把"会议与验证互斥"写成一句**明确的不变式**，然后拿这句话去逐条对照代码 ——
+发现 `startMeeting` 有守卫、`armNextVerify` 没有。单看任何一处代码都不觉得有问题，
+是"写下不变式 → 双向核对"这个动作把它逼了出来。
+
+所以：
+
+- [ ] 画架构图/写规格时，**每一条箭头与每一个"互斥/永不/必须"的措辞都要落到代码里核对**，
+      特别是**成对出现的关系**（互斥、双向、唯一、幂等）——只做一半是最常见的形态；
+- [ ] 文档里凡是出现"二者互斥""永不同时""必然"这类断言，都要问一句**它在代码里由谁保证**；
+      若答案只在一个方向上成立，那就是缺陷；
+- [ ] 相对顺序**不可观测**的地方（因为互斥）不要写成精确的优先级列表假装精确，
+      而要写明"二者互斥，故顺序无关"。
+
+---
+
+## 4. 第三优先：其余（沿用既有做法）
 
 - [ ] 静态自检：调用了但未定义的函数、未声明的参数键、不存在的会话 API 方法、
       已文档化但从未抛出的错误码、遗留的开发标记。
@@ -138,7 +184,7 @@
 
 ---
 
-## 4. 汇报要求
+## 5. 汇报要求
 
 - 缺陷要分**类**："这一整类此前没有审计维度"比"修了 N 个 bug"更重要。
 - 假绿/假红必须单独说明：**审计本身失效**是最严重的发现。