cf14b840ef
## 背景 上一次文档校订（b9b5ac0）之后又有两次代码提交（5194a96 / 8293282）， 把 future-plan §1.1 整节变成了错的 —— 它还写着「档位没有生效点」 和「在 prepareInputTask 里加一次 activateSecurityProfile 调用」， 而后者正是被后来的收敛**否定掉的方案**。 ## 新增 docs/zh/README.md（文档索引） 32 篇文档此前混着三种时态（当时实测 / 历史推演 / 设计规划），外观相同。 索引给出**状态分类与可信度规则**： | 状态 | 能不能当事实用 | |---|---| | 已实现并部署 | ✅ 直接信 | | 部分实现 | ⚠️ 只信标了"生效"的部分 | | 设计 / 未实现 | ❌ 只能当设计意图 | | 归档说明 | ❌ 不要改、也不要信 | 并写死**判据名可信度规则**：文档里的 `TestXxx` 不保证还存在。 给了核对命令，以及当前基线（27 条缺失的分布 —— 18 条属"设计未实现"类 文档的规划名、7 条是 §2.7.3 有意保留的历史对照表左栏、2 条属视频能力 未纳入契约）。判定标准：**在"已实现"类文档正文里找不到才是缺陷**。 ## 重写 future-plan §1.1（已结案） 原节写的是错的方案。改成记录**真正的缺陷分三层**： ``` 第 3 层（表面）：activateSecurityProfile 零调用方 第 2 层：agent/core 在替 security 做策略决策 （自己抠 security_profile / 自己选判定链 / 自己写 Kind:"resident" 声明主体类别 —— 提权口子） 第 1 层（根因）：security 缺少「输入接入点」 ``` 并补上「每 agent 一个实例」的最终形态（共享注册表 + per-agent 执行视图， sessionProfile / longtimeProfile 两层，优先级 session > longtime 本身是安全语义）。 §〇「机制 ≠ 接线」表格里档位那一条从 🔴 改为 ✅。 ## 各文档状态行 此前 14 篇缺状态行（runbook / 实测报告 / 计划类）。逐篇补上**符合实际内容** 的声明，而不是统一套一句。特别地： - `commondev-design.md` 标题本就写「设计 · 未实现」→ 归到"设计"类 - `live-run-evidence-2026-10-04.md` → 明确标注"历史证据快照，不要用它的 结论覆盖现在的实现判断" - `legacy-issues.md` → 写明它与 future-plan 的分工（前者收已知问题， 后者收能力缺失与零调用方） ## 正文里两处判据名漂移 - `TestBootCtxCloseAllIsReverseOrder` → 实际是 `TestKernelStateCloseAllIsReverseOrder`（`BootCtx` 改名时判据跟着改的） - `TestNilTypedBusSafety` → 标注为"规划名，仓库中不存在" ## 新增 §2.7.5 模块产物的实例化粒度 依赖图保证"设施已就绪"，但没说该有几个实例 —— 这是独立决策。 记下 security 的两个答案：全局基线共享（否则插件声明对部分 agent 不生效）、 轮次状态 per-agent。并给出给未来新模块的两条判断标准。 ## 安全文档 状态头补「架构形态」段（防火墙定位、per-agent 视图、两层档位）； 接线状态表里 `ActivateProfile` 从 🔴 改为 ✅（2026-10-31 接通）。 ## README 文档列表加索引与 future-plan 入口 —— 此前从 README 找不到 docs/zh 的任何指引。 ## 核对 - docs/zh 32 篇全部有状态行 - 索引里列的文档全部存在，无遗漏 - 分类与各文档自述一致（逐篇抽查） - go build 仍通过（纯文档改动）
4.5 KiB
实战证据：新内核在真实跑分中的行为（2026-10-04 07:13~07:29）
状态：归档说明（历史证据快照）。 记录 2026-10-04 那次实跑的现场数据。 不要用它的结论覆盖现在的实现判断 —— 代码已演进，快照只证明"当时是这样"。
内核 657ccd7（含今天全部 19 个 memory 层提交）跑 tasks.zerobasis + memory_recall 时的实例日志。
一、召回来源标签（今天新增的功能）
标签分布：exact 14 次 text 24 次 symbol 0 次
样例：
[exact 1.00] 第15批与第18批之间缺失，待老大确认是否遗漏
[exact 1.00] 第47批 4279ms
[exact 1.00] 连接池从 ...
[exact 1.00] 第115批周二凌晨2点·停机6分·回滚v2.28.1·灰度5%观察63分后…
[text 0.57] order-gw 运维进展
★ exact 那 14 条正是「端口号/批号/耗时」类事实 ——
它们在纯向量下召不回（实测 chineseclip 对「13010」这类
短数字串极不敏感），今天靠符号路的布尔置顶救回来。
symbol 0 次 说明：纯符号命中（无向量分）这条路在 ha-c 数据上
没有被触发 —— 因为块都是整句块，向量侧总能给分。
二、L4 上下文超页处理在真实负载下触发（本分支早前工作）
overflow 32 次
preempt 6 次
suspend 6 次
裁剪 3 次
recover budget exhausted （未出现，说明恢复预算够用）
tool call loop start, max_ctx=50000 target=40000 fixed=2196
⇒ 在 50000 窗口、26 轮叙事填充下确实触发了超页路径，
且没有出现「no reduction」那类失败。
三、能力标定
tasks.zerobasis 6/6（100%） 墙钟 159.17s
token 281971 缓存命中 42.7% 超时 0
四、召回被全局上限截断
graph.go:944: [graph] recall: 截断 3 个实体（全局上限 20）
★ 这条日志说明旧实体路仍在跑（graph.go:944 是 RecallSorted
的截断逻辑），而今天的块路是并行的另一条。
两路都在 ⇒ da2063b 评估里说的「55 处调用点」在现场得到印证：
旧路径没有退出，只是被块路抢先返回了。
五、★ 跑分正在往旧表里写数据（最重要的发现）
07:29:20 memory_commit result: 已写入 8 个实体和 4 条关系
07:31:02 memory_commit result: 已写入 2 个实体和 1 条关系
07:31:29 [indexer] 实体数 202→207，已增量重建实体名向量索引
07:31:30 [indexer] 实体数 194→202 …
entities: 188（跑分前）→ 207（跑分后）
★ memory_commit 仍写 entities / relations，而且是活跃的在线写入路径。
这修正了 da2063b 的评估，也修正了「写入点已清零」的说法：
| 我以为 | 实际 |
|---|---|
sentences 写入点已清零（迁移与蒸馏） |
✅ 成立，但只针对这两条命令 |
| 旧表在等着被清理 | ❌ 它还在长大（188 → 207） |
⇒ 旧表退场的前置不是「删表」，是「先让 memory_commit 改写为写块」。
在那之前删除旧表 = 在线写入直接报错。
六、召回的三种返回形态（实战统计）
① 正常召回（找到 N 条） 30 次 ← 块路
② 拒答（记忆库里没有） 2 次 ← 今天新增的判据
③ 空返回（走旧路兜底） 31 次 ← 块路让位
② 拒答样本（今天能力的实战验证）
记忆库里没有与「第8批 上线准备」相关的记录
记忆库里没有与「第9批 上线准备」相关的记录
★ 查询含精确串（第8批/第9批）而库里没有 ⇒ 判据正确触发。 今天新增的拒答能力在真实负载下工作了。 而且验证了「拒答后不走旧路兜底」（实测 0 次）—— 拒答是干净的终态。
③ 那些截断日志其实不是 memory_recall
graph.go:944: 截断 149 个实体（全局上限 20）
第一反应是「块路被旧路抢走了」，但查上下文发现来源不同：
[agent] tool memory_commit result: 已写入 2 个实体和 1 条关系
tooldefs.go:107: [agent] memory recall (input:cli): injected 1287 chars
↑ input:cli = 自动记忆注入，不是用户的工具调用
⇒ 截断来自自动记忆注入与 memory_commit 的内部召回，
不是用户显式调用 memory_recall 时的兜底。
★ 我差点又归因错了（「块路 30 vs 旧路 31，块路没抢先」）。 差异的来源是调用方不同，不是优先级失效。