docs: 全量校订文档到当前代码状态 + 建立 future-plan 作为唯一未做登记处

## 为什么

文档里混着三种时态：当时实测、历史推演、描述现状但已失真。三者外观相同，
读者无从分辨。本次逐条用实测核对，把失真的改成事实，把「已做」从「未做」
里摘出来，把「真没做」集中登记到一处。

## 新文件：docs/zh/future-plan.md

此前「未做」散落在各设计文档的「待办/剩余/遗留」小节，时间一长就与代码
脱节（已完成却仍写未做，未做却被当成已完成）。新建本文作为**唯一登记处**，
收录规则明确：只收「代码里确实没有」与「有机制但零生产调用方」两类。

它同时把本仓一个反复出现的缺陷形态显式化 —— **机制 ≠ 接线**。已攒够 5 例：

| 能力 | 曾经/现在的状态 |
|---|---|
| `Policy.CheckTool` | 曾 `Agent.security` 恒 nil → 2026-10-30 修 |
| `CheckToolFor` | 曾 0 生产调用方 → 2026-10-30 修 |
| `ActivateProfile` | **现在仍 0 调用方** |
| `ScanContent` | **现在仍 0 调用方** |
| `CheckPath` / `CheckNetwork` | **现在仍 0 调用方** |

## 已失真的表述（逐条实测后更正）

**kernel-modularization-design.md**

- §2.7.4 原标题是「未做（Step 4b 的剩余）」，写着「main.go 仍走原来的串行代码，
  下一步是把 Run(plan) 真接进 main」。**实际 `main.go:229` 早已调用
  `RunKernelModules` → `kernelboot.Run`**，插件调度也已归位 plugin-host。
  改为「已完成」并给出两处代码位置 + 生产日志证据。
- §2.7 分层数字「6 层 / 17 模块，最宽层 9」→ 实测 **20 模块 / 6 层 / 最宽 10**。
  同时给出取数命令，并要求「数字一律现场取，不凭文档记忆」。
- §2.3.5 那段标着「当前已产出的分层结果（实测）」的 4 层 14 模块表，是
  2026-10-16 的推演。改为明确标注「已过时，仅作设计推演保留」。
- §2.7.3 判据表 7 条**全部不存在**（随 3864f36 删死包迁包时丢失）。改为
  左右栏对照：左边当时名字、右边现仓库真实判据，找不到对应物的 4 条明确标 ❌。
- 文件头补状态声明、与 future-plan 的分工、数字取数方式。

**kernel-secret-firewall-design.md**

- 状态从「已实现」改为「部分实现」。原来那句会让读者以为整套安全能力都在跑。
- 新增接线状态表：逐个写**实测的生产调用点**（不写 ✅/❌ 定性）。
  事实是：凭据三件套与工具闸生效；**敏感词/注入、路径沙箱、网络闸三条
  机制完整但零生产调用方**；档位声明侧通、激活侧零调用方。
- §5 T1–T10：T2/T3/T4 早已落地却仍挂在「待办」表里。改为现状列，
  并把真未做的 T5–T10 迁入 future-plan §1.5。

**对外文档的工具名**（外部读者正在看错的名字）

- `ARCHITECTURE.md` 6 处、`OVERVIEW.md` 1 处、`README.md` / `README_EN.md` 各 3 处、
  `resident-subagent-design.md` 2 处：`memory_*` / `doc_query` → `stablemem_*` / `coldcontext_*`
- README 的 v1.1.1 发布说明保留原名（那是历史事实），加一句现名注记

**input-scheduler-design.md / resident-subagent-design.md**

- 补状态头。input-scheduler 记入 rtchild 不走四级阶梯（单槽覆盖）这一下游差异；
  resident-subagent 记入「继承安全运行时实例但**不继承权限**」这一下沉事实。

## 未动的（有意为之）

历史归档文档（`legacy-*`、`*-plan.md`、`live-run-evidence-*`、
`production-recall-validation.md`、`context-overflow-l4-design.md`、
`entities-retirement-plan.md`、`memory-*-plan.md`）**一律不改** ——
它们是历史记录，改了就篡改证据。其中的待办以索引形式登记在
future-plan §六，原文档保留。

## 核对结论

- 文档现在只描述两种内容：**已落地的实现**（附实测证据/取数命令）与
  **尚未实现的事项**（统一在 future-plan）
- 数字类断言全部给出取数命令
- 跨文档的「未做」引用统一指向 future-plan，避免再次分叉

docs/zh/kernel-secret-firewall-design.md

@@ -1,6 +1,35 @@
 # 内核安全模块（Secret Firewall）设计 · 计划追加
 
-> **状态：已实现（持续审计中）。** 本文的安全模块、配置加密、变量库统一与 C1–C8 判据已落地；E-1/E-2/E-3/E-4 已完成；剩余项见文末实现边界。本文保留原始设计与逐条审计记录。
+> **状态：部分实现。** 凭据防火墙、配置加密、变量库统一与 C1–C8 判据已落地并**在生产线生效**；
+> 但**三条能力机制完整却零生产调用方**（敏感词/注入预警、路径沙箱、网络闸）。
+> 本文保留原始设计与逐条审计记录；未实现项统一登记在
+> [`future-plan.md`](./future-plan.md) §一。
+>
+> ## 接线状态表（2026-10-31 实测，逐个查生产调用方）
+>
+> 本仓反复吃亏在「机制写了、判据绿了、生产里从不执行」。所以这里不写✅/❌定性，
+> 只写**实测的生产调用点**：
+>
+> | 能力 | 机制 | 生产调用点 | 状态 |
+> |---|---|---|---|
+> | 出向凭据拦截 `PrepareOutbound` | 完整 | `eventguard.go` / 各界代理 | ✅ 生效 |
+> | 入向凭据清洗 `ScrubInbound` | 完整 | `eventguard.go`、`events/bus.go`、`device/mod.go` | ✅ 生效 |
+> | 执行前回填 `FillForExecution` | 完整 | stage 管道 | ✅ 生效 |
+> | 工具黑白名单 `CheckTool` | 完整 | `agent/core/security_profile.go`（主 agent） | ✅ **2026-10-30 接通** |
+> | 按主体授权 `CheckToolFor` | 完整 | `agent/core/security_profile.go`（子 agent） | ✅ **2026-10-30 接通** |
+> | 插件命名档位 `DeclareProfile` | 完整 | `sdk/security_impl.go`、`proc/corehandler_security.go` | ✅ 声明侧通 |
+> | 插件命名档位 `ActivateProfile` | 完整 | `agent/core/security_profile.go` 内的 `activateSecurityProfile` | 🔴 **该函数零调用方** ⇒ 档位永不激活，见 future-plan §1.1 |
+> | 敏感词/注入 `ScanContent` | 完整（254 行） | **无** | 🔴 配置里的敏感词一条不生效，见 future-plan §1.2 |
+> | 路径沙箱 `CheckPath` | 完整 | **无**（只被 Runtime 自己调 Policy） | 🔴 见 future-plan §1.3 |
+> | 网络闸 `CheckNetwork` | 完整 | **无**（同上） | 🔴 见 future-plan §1.3 |
+> | 事件总线授权 + 载荷过闸 | 完整 | `security/mod.go`（唯一装配点） | ✅ 生效 |
+>
+> ★ **历史的教训（两轮都错）**：
+> 第一轮把「`Agent.security` 从未被赋值」诊断成「少一个注入点」而补了 `SetSecurity()`，
+> 但生产装配链从不调它；第二轮才看清根因是 **`kernelmod/agent` 的 `Requires()` 没声明
+> `FacSecurity`** —— 依赖图没理由把 security 的产物交给 agent。
+> 所以「接线」必须在**依赖图层面**表达，不能靠事后注入。
+>
 > 记录一条由用户纠正后确立的**架构决定**，以及它带来的简化与下沉。
 >
 > 撰写时间：2026-10-14。触发：用户在讨论 commondev 加密 shell 时提出两点纠正。
@@ -387,19 +416,24 @@ internal/security/ 里的一个**进程级单例**（或挂在 ProviderManager
 
 ## 5. 待办与未决
 
-| # | 事项 | 说明 |
+> ★ **2026-10-31 迁出说明**：本节里**仍未实现**的事项已全部迁到
+> [`future-plan.md`](./future-plan.md) §一「安全」。下面保留原表作为**设计讨论的历史记录**
+> （它们的推理过程本身有价值），但**不要再把这张表当待办清单用** ——
+> 它历史上滞后过（T3/T4 已落地却仍挂在表里）。
+> 每行的「现状」列是 2026-10-31 实测结果。
+
+| # | 事项 | 现状（2026-10-31） |
 |---|---|---|
-| **T1** | ~~修 `splitKeyValue` 对 `assigned_secret` 的键名丢失~~ | ✅ **已修**（插件侧；迁内核时可一并搬）。根因：键名后常带空格（`api_key = "..."`），旧判据把“含空格”当成“不像键名”就放弃拆分 ⇒ 整段被当 secret。已配变异验证 |
-| **T9** | **不自动淘汰的规模上限** | 落盘文件只增不减（除非人主动删）。需定一个**可观测**的降级策略（如超 N 条时**告警**，而不是静默删某条） |
-| **T10** | **提交工具的泄露面** | “主动提交”要把明文交给内核 —— 与 `enc_store` 同问题（明文会进会话/日志）。
-  应优先支持 `${ENV}` / `@file:` 两条不明文入会话的路径 |
-| **T2** | 把前稿的 `intercept.go` / `encstore.go` 从插件**迁到内核** | 模式库可复用，别名/存储需重写为内核形态。★ **迁后本插件的 `enc_*` 工具族与加密 shell 应大幅删减**（用户：插件对安全机制无感知） |
-| **T3** | **密钥从哪来**（内核侧） | 内核是长驻进程；密钥须由部署方提供（systemd 环境变量）还是内核自持密钥文件？未定 |
-| **T4** | 变量**持久化与生命周期** | ✅ **已定**：落盘加密持久化（重启不丢）、**不自动淘汰**、可主动删（§2.4）。剩余：落盘位置与 masterKey 来源（同 T3） |
-| **T5** | 压缩（compaction）对别名的影响 | 摘要可能把 `@{sec_1}` 当成普通文本；压缩后别名是否仍有效？ |
-| **T6** | **明文在内存中的擦除** | Go 字符串不可变 ⇒ 只能擦可写副本。要定"努力擦除"还是"不承诺" |
-| **T7** | 替代方案评估 | 内核是否可能拿不到 secret（如 SSH 密钥文件）⇒ 也许该支持"引用外部文件、内核只持路径" |
-| **T8** | **入向回填的安全边界** | 回填后 agent 可把 `@{别名}` 写进**任意**命令参数 ⇒ 等于获得“在任意命令里用明文”的能力。这**正是必需的**（否则没法用密钥），但“能做什么”的边界因此回到**命令本身**。要定：要不要限制哪些工具允许触发回填？ |
+| **T1** | ~~修 `splitKeyValue` 对 `assigned_secret` 的键名丢失~~ | ✅ **已修**（插件侧；迁内核时可一并搬） |
+| **T2** | 把前稿的 `intercept.go` / `encstore.go` 从插件**迁到内核** | ✅ **已迁**（`internal/security/gate.go` + `store.go`；插件对安全机制无感知） |
+| **T3** | 密钥从哪来 | ✅ **已定且已落地**：内嵌主密钥（构建期 `-ldflags`）+ 磁盘钥回退 + keyring（`internal/security/key.go`） |
+| **T4** | 变量持久化与生命周期 | ✅ **已落地**：落盘加密持久化（`security/variables.json`），不自动淘汰 |
+| **T9** | 不自动淘汰的规模上限 | ❌ **未做** → future-plan §1.5 |
+| **T10** | 提交工具的泄露面（`${ENV}` / `@file:` 不明文路径） | ❌ **未做** → future-plan §1.5 |
+| **T5** | 压缩对别名的影向 | ❌ **未做** → future-plan §1.5 |
+| **T6** | 明文在内存中的擦除 | ❌ **未做**（Go 字符串不可变，需先定“努力擦除” vs “不承诺”）→ future-plan §1.5 |
+| **T7** | 引用外部文件、内核只持路径 | ❌ **未做** → future-plan §1.5 |
+| **T8** | 入向回填的安全边界（哪些工具允许触发回填） | ❌ **未做** → future-plan §1.5 |
 
 ### 5.1 ★ 配置落盘加密 ［已完成 · 真机验证］