2 Commits

Author	SHA1	Message	Date
JianFeeeee	cf14b840ef	docs: 补齐文档状态分类 + 校正两轮代码改动后的失真 ... ## 背景 上一次文档校订（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 仍通过（纯文档改动）	2026-10-31 07:50:58 +08:00
JianFeeeee	c53d1da2a6	docs: 内核性能实测基线 + payload 透传/保留键设计 ... ## docs/zh/kernel-performance.md（新增） 全部是实测数据，不是估算，每条标出测量方法与复现命令。 冷启动 15.4s（5 层 17 模块 + 22 插件），耗时分布： 第 0→1 层 3.1s 20% 内存/ONNX/文档存储初始化 第 1→4 层 2.4s 16% LLM/知识库/agent 装配 第 4→完成 9.9s 64% 22 个插件子进程建链 ★ 与早期记录（1538–1709ms）的差异要说明：那是**纯内核**装配时间， 不含插件。两者口径不同，混用会得出"启动变慢 10 倍"的错误结论。 其余指标：RSS 26MB / 插件进程 12 个（13 个按需加载）/ 三层工具超时 （30s ctx → max(声明,参数) → 10m 硬上限）/ 上下文预算实测值 / `offload_busy_after` 1m。 含三个实测踩过的性能陷阱：长工具执行期间 stop 无法生效、 同阶段重复注册静默覆盖、before_output 双触发路径。 ## kernel-modularization-design.md 新增 2.7 节 注入 payload 的透传机制与保留键硬约束。 保留键必须覆盖两类：注入路径自己写入的（no_memory/context_policy/…） 与内核读取的语义键（interrupt/stop/command/…）。插件写保留键会被 跳过并记日志 —— 允许覆盖等于允许伪造"这条不记记忆"或"这条立即打断"， 那是权限提升。 同时记录 output_send__* 的 stage 语义：before_output/after_output 有两条触发路径，output.go 那条才是"消息真发出去"的时刻，而它历史上 连 Extra 都没初始化（实测 extra_keys=0）。 ## 设计过程中的一次返工 曾加 InjectOptions.Meta，等于把同一件事做两遍且只服务注入路径。 用户指出后改为复用 InputEvent.Payload 的扩展口，所有注入路径共用。	2026-10-18 18:36:26 +08:00