jianf
48c52497c2
feat(memory-b): F6 三段口径固化成判据 + A1b 降级记账
裁定：F6 选 (a)，措辞改写，不留互斥读法
原措辞「仍可按文本调出、不参与向量召回」读起来像互斥。实际是三层：
「按文本调出」= store 级无空间浏览，**不是生产召回路径**。
不改 F2 去迁就 F6 字面自洽的理由：F2 是 fusion.go:495 同款安全缺陷修复，
优先级高于 F6 的措辞。所以 F6 改成三段并列，每段一条断言，
**同一个用例内全断言**：
数据层：指纹变更后旧块仍在库中 —— 块数不减、按 fp 分组两行都在
浏览层：store 级不带空间参数的文本查询仍能取到旧块
召回层：带 fingerprint 的生产召回路径必须把旧块过滤掉（F2 承担）
为什么必须一个用例：只断言「过滤掉了」会漏掉数据被误删
（删库在召回层看起来就是「过滤正确」）；只断言「能调出」会把 F2 挡回去。
F6 判据 3 条
F6 三段全断言 + 反向对照（当前空间块两层都能取到，
防止断言因为「什么都找不到」而假成立）
F6†data 变异：putBlock 顺手 purge 其它空间的行走道 ⇒ 数据层断言红
F6†recall 变异：去掉空间过滤器 ⇒ 召回层断言红
两条变异各自只咬自己那一段，与 F6†data/†recall 的分工一致。
★ F6†data 的变异写法踩了三次坑（据实记）
1. 只写 form（没真改代码）—— 那不是变异，是自测
2. 注入 SQL 里的转义引号把测试文件写成 SyntaxError
3. 最终用 String.fromCharCode(39) 拼引号 + 数组 join 构造注入文本，
避开嵌套模板字符串的转义地狱
裁定 2：A1b 降级要记账
A1b 原先逐字节锁死 recallBlocks 源码，F2 合法地要改它，已降级为
「不传 fingerprint 时行为不变」。但降级后的 A1b-behaviour 只跑 golden
**前 5 个** case，变异 A（非精确带分数微调）下它可能是绿的。
已在判据注释写明：**结论不由 A1b 单独给出，由 A2 兜**
（A2 走全部 45 例、比精确分数）；A1b-behaviour 只是烟测，不是权威。
同步进 memo：docs/dev-notes-mutation-criteria.md 增第 5 条
「判据降级时，覆盖面必须一起交代」—— 这不是失效模式，是记账纪律。
自查问句：这条判据降级后，原本由它兜住的结论现在由谁兜？
答案必须是一个具体的、覆盖更广的判据名。
验证
- npm test 131/131、npm run check 10/10
- 干净副本（git archive + link-dsh）实数见后续消息
2026-10-30 15:39:03 +08:00
..
2026-10-30 15:39:03 +08:00
2026-10-30 00:39:44 +08:00
2026-10-30 15:39:03 +08:00
2026-10-30 09:52:06 +08:00
2026-10-30 09:29:37 +08:00