|
|
d17e261b76
|
feat(update): update 注册为内核标准模块（第 0 层）+ 启动失败自动回滚
## 为什么必须是第 0 层（用户口径）
update 肩负「启动失败回滚上一次升级」的职责，该职责必须**早于所有模块**。
若排在后面：升级后新内核在 memory/llm 阶段崩了，而回滚还没跑 ⇒ 机器进
崩溃循环，只能靠 guard 的 failback（受限启动）兜底。failback 是最后手段，
不该承担"换错二进制"这种**已知可回滚**的故障。
⇒ Requires() 为空 ⇒ 依赖图天然把它放 Layers[0]。
## 两段式升级确认（rollback.go）
升级成功 ──→ 写 pending 标记（"这个版本尚未被确认能启动"）
↓
重启 → 内核启动 → update 模块（第 0 层）读标记
↓
┌────────────┴────────────┐
标记还在 标记已不在
（上次升级没能活到清除） （上次升级已确认成功）
↓ ↓
回滚到备份版本 正常继续 + 清标记
清除时机：模块跑完自检后立刻清。只依赖"进程活着且执行到第 0 层"，
不依赖其他模块 ⇒ 不会误判。
**为什么不用 TTL / 重启次数**：那是 guard 已有的 failback，但判据是
"崩了几次"，不是"这次升级该不该撤销"。用重启次数会在"新版本偶发崩溃"时
误回滚 —— 而那种情况该修的是崩溃，不是回退版本。
## 分层（与仓库其他模块同一惯例）
internal/update/ 业务实现（三端共用：CLI/WebAPI/agent 工具）
internal/kernelmod/update/ 适配层（读 ks → 调业务包 → 写回 ks）
参照 supervisor 模块：实现在 internal/supervisor，模块里只做装配。
分开的理由：internal/update 被三端调用，它们都没有 KernelState。
## 标记写入时机（一个真实的顺序坑）
MarkPendingUpgrade 在**替换二进制之前**调用。反过来（替换后才写）会在
"替换成功但没来得及写标记就崩了"时丢标记 ⇒ 下次启动不知道该回滚。
且写标记失败 ⇒ **放弃本次升级**（未替换任何文件）：没有标记就没有回滚
能力，而不带回滚的升级等于赌运气。
## 回滚失败必须响亮
备份不存在时返回 error，调用方（模块 Init）必须中止启动 —— 继续装配等于
用一个已知起不来的版本。错误文案带备份路径与标记路径（删标记即可放弃回滚），
人能照着修。
## 判据
internal/update/rollback_test.go 10 条，2 条经变异验证：
· TestRollback_RestoresBackup —— 二进制+depgraph 同批回滚、标记清除、
坏版本留档 homed-broken-*、版本轨迹记录
变异：回滚后不清标记 ⇒ 红
· TestRollback_MissingBackupIsLoud —— 备份缺失时报错且可执行
变异：静默返回 nil ⇒ 红
· TestPendingMarker_AbsentIsNotError —— 无标记返回 (nil,nil) 而非 error
（否则每次启动都走"回滚失败"分支 ⇒ 内核永远起不来）
· TestPendingMarker_CorruptIsActionable —— 标记损坏时提示可删
· TestStateSummary_* —— 回滚信息进 healthcheck；nil 安全
## 顺带修正的既有判据
· runtime_dep_test.go：L0 设施集合从 2 个变 3 个（新增 kernel.version），
改为断言**集合**而非顺序（注册表本就是乱序的）
· facilities.go：新增 FacVersion，并登记为 internalOnlyFacilities
（它是启动时序事实，不是插件契约 —— facilities_sync_test 的守卫正确拦住了
"把内部标记泄漏成对外契约"）
三个 DoUpgrade 调用点补 dataDir 参数（标记落点必须与内核 --data 一致）。
|
2026-10-26 02:08:29 +08:00 |
|
|
|
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 |
|
