|
|
3864f36992
|
refactor(kernelboot,kernelmod): ID:13 删死包 kernelboot/modules，整机启动图判据迁到 kernelmod/all
## 决策
删除 internal/kernelboot/modules（registry.go + registry_test.go），
把整机启动图判据迁到 internal/kernelmod/all（真实聚合入口）。
文件头那条 TODO(死包清理) 随包一起消失。
## 为什么这个包该删
实测零生产调用：
· 生产代码里 import 它的包数 = 0
· Register() / BuildModules() / Names() 的外部调用点 = 0
· 它的 Register/BuildModules 是 internal/kernelmod 那套注册表的**第二份实现**
（留着只会让人下次接错口子）
· kernelmod/all/facilities_sync_test.go 的注释里早已写明
「kernelmod 才是真实注册表（模块编译期工厂加载）」
## 判据迁移（能力未削弱，逐条实测）
- 判据 1–4（整机装配/层拓扑/严格逆序关闭/无残留）: 只换宿主，
用 kernelmod.Registered() 作为装配输入不变，实测 5 层 / 17 模块 /
关闭顺序 [4 3 2 1 0] / 3 轮 goroutine 差值 0 / 订阅者 2→2
- 判据 5（TestEveryRegisteredModuleIsCompiledIn）: 真相源是扫 `..` 源码树的
「目录+类型名 复合键 + 四方法齐全」，与宿主包无关。scanModuleTypes 的
modRoot 从 "../../kernelmod" 改为 ".."（本文件现在在 kernelmod/all/ 下）
- 删掉 `_ ".../kernelmod/all"` 自引用（判据现在与聚合入口同包，
本包被编译即聚合 import 生效 —— 反而更贴近生产同一条 import 链）
## 「新模块登记了但漏 import」仍咬得住（3 个变异亲测）
A 从 all.go 删 multimodal 聚合 import（叶子模块，无人依赖）
→ TestEveryRegisteredModuleIsCompiledIn 红（指名 multimodal）
→ TestEveryModuleDirIsImported 红
B 删 multimodal 的 init()（Register 调用点消失，真相源不能是被测入口）
→ TestEveryRegisteredModuleIsCompiledIn 仍红（源码侧多数一个类型）
C supervisor 的 Name() 改成非字面量
→ 判据显式失败（不静默跳过 ⇒ 不会变空转）
## 悬空引用清零
全仓 grep kernelboot/modules：代码/文档/CI 只剩 ci.yml 里一条
「那个包零生产调用，已删除」的历史说明。同步修正：
· ci.yml「整机启动图判据」步骤 → go test ./internal/kernelmod/all/
· ci.yml -race 排除表 pkg 行目标包 → internal/kernelmod/all
（该包现在装整机 ⇒ 同样会撞 KERNEL-REGISTRY-SETLOCK；
实测不带 -race 6/6 绿，排除仍必要，单号不变）
· ci.yml 三条说明文本（含证据步骤的提示语）
· kernelboot/kernelstate.go 指向旧判据路径的注释
· docs/zh/kernel-modularization-design.md §2.7 的 declarations.go 路径
· check-ci-gates.py §4 断言目标包 → ./internal/kernelmod/all/
（否则它盯的是一个已不存在的包）
## 验证
go build ./... = 0 error，go vet ./... = 0 error
go test ./internal/kernelboot/... ./internal/kernelmod/... = ok
go test -race ./internal/kernelmod/all/ = ok（连跑 6 次无 DATA RACE）
check-ci-gates.py EXIT=0；ID:15 的 verify_v4 矩阵复跑仍 5 变异全抓 + 误报项 EXIT=0 + 基线 EXIT=0
|
2026-10-24 12:56:37 +08:00 |
|
|
|
e70c2b55b4
|
feat(kernelboot): ID:14 Run 增加执行期依赖校验，顺序被改坏时报可读错而非 SIGSEGV
Build() 里已有构建期校验 diagnoseUnresolvable（查声明：缺依赖/环/重名），
本单**不重复**它。缺的是执行期那一层：声明全对、图也自洽时，plan 的层顺序
仍可能被改坏（手改 Layers / 图与代码漂移 / 有人把某层提前），此时 Build 绿，
模块 Init 拿到 nil 依赖，崩在业务代码里。
实测复现（本单判据的复现形状）：把 kernelmod 真实登记表算出的第 1 层
（lua/memory/onnx-parser/…）与第 2 层（llm/text-memory/knowledge-store）交换，
llm.buildProviderManager 收到 0x0 的 LuaVM：
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV ... addr=0x10]
internal/lua.(*VM).ConfigureConcurrency(0x0, ...) vm.go:213
internal/kernelmod/llm.buildProviderManager(..., 0x0, ...) mod.go:70
改动：Run 逐层维护 produced（**只有真跑完的层**才贡献设施，刻意不从 plan 预填），
每层 Init **之前**核对本层各模块 Requires ⊆ produced；缺则返回
*DependencyNotReadyError 并**本层一个 Init 都不调**（宁可什么都不装，也不装一半再崩）。
错误文本指名「第 N 层 / 模块 X 缺设施 [...]」并列已实际产出的设施。
判据：
internal/kernelmod/all/runtime_dep_test.go —— 用真实登记表算 plan 后做变异
A 正序前缀不误报
B 交换两层 ⇒ 判据红（指名 llm 缺 lua / text-memory 缺 memory,onnx /
knowledge-store 缺 knowledge-migrated），且 ks.LuaVM 仍为 nil（没跑到 llm）
C 删掉提供者整层 ⇒ 第 0 层就拒绝，IO/EventBus 仍 nil（一个模块都没跑）
internal/kernelboot/runtimedep_test.go —— 纯逻辑四形状 + 防 M2 自检
变异证明（4 个，逐个人工注入后跑判据，全部咬住）：
M0 撤掉守卫 → 复现原 SIGSEGV（ConfigureConcurrency(0x0)）
M1 守卫恒放行 → 5 条判据红
M2 produced 从 plan 预填 → 退化成 Build 重复实现，顺序类判据红
M3 报错丢模块名 → 指名类判据红
修前红/修后绿：
修前（M0）：panic SIGSEGV @ lua.(*VM).ConfigureConcurrency(0x0)
修后：DependencyNotReadyError，文本含「第 1 层」「llm」「lua」「缺设施」
go build ./... = 0 error，go vet ./... = 0 error
go test ./internal/kernelboot/... ./internal/kernelmod/... = ok（含 -count=1）
|
2026-10-24 12:50:57 +08:00 |
|
