Commit Graph

4 Commits

Author SHA1 Message Date
cc0eb51286 refactor(kernel): 统一挂载点 kstate + 插件声明式系统提示词段
## 起因(生产故障)

A2A 分诊助手(驻留子)把 terminal_create 当一次性命令执行器:

    terminal_create(command='cd /usr/lib/node_modules/@deepseek-ai && ls -d */ | head -60 && …')
    → read /dev/ptmx: input/output error
    → 再开 term_7、term_8、term_9 …

链路拆开四层:
  ① cmd 插件 auto_start=false ⇒ 工具表里没有 cmd_run
  ② 需要 cmd-tools skill 说明"先 plugin_start cmd"
  ③ 但 skill 索引没进那个 agent 的提示词
  ④ 因为 skillIndex 只是根 agent 的字段、由 bootstrap 手工接线

④ 才是总根。而它之所以必须手工接线:agent/core 读不到内核的共享数据。

## 环的精确形状(实测,非推测)

kernelboot 因为持有 KernelState 而依赖 19 个业务包:

    kernelboot ──▶ agent/core ──▶ …
               ──▶ plugin
               ──▶ security
               ──▶ memory / knowledge / text / coldcontext / …

而 kernelboot.go / scheduler.go / funcmodule.go / syncbus.go / lifecycle.go
**一行业务代码都不需要** —— 依赖全在 kernelstate.go 这一个数据文件里。

后果是四个底层包各自造通道:

    core      → Agent 字段(每种 agent 构造点都要记得传)
    plugin    → 12 个 SetXxx
    sdk       → SDKConfig 传参
    security  → 包级单例 Global() / RuntimeGlobal() / ConfigCodec()

四条通道是同一个根因的四个表现。

## 本次做的事

### 1. 抽出 internal/kstate(断环)

kernelstate.go / syncbus.go / lifecycle.go 搬出 kernelboot:

    internal/kstate     纯数据 + 唯一挂载点(叶子,谁都能 import)
    internal/kernelboot 装配引擎,零业务包

挂载点 API:Mount / Get(nil 安全)/ MountForTest(返回 restore,并行测试隔离)。

验证:core 现在能 import kstate(此前 import cycle not allowed)。

### 2. StageHost / Agent 字段存 any

它们是 core 自己的类型(core 是环的一极,这是真环)。按用户裁定的方向:

    > 是其他包在kstate挂共享内容啊

存 any,消费方断言回具体类型 —— 与本仓既有的 PluginCatalog /
PluginScheduler / UpdateCapabilities 同型。

★ 其余字段保持**具体类型**,没有一律改 any。判据是"它会不会反向依赖
agent/core":实测 plugin / security / sdk 都不依赖 core,所以它们作为
具体类型不构成环,而类型化字段让"拼错/取错类型"是编译错误(本结构体的
设计原则)。

### 3. 插件声明式系统提示词段

SDK 新增 SystemPromptAPI(见 submodule 提交)。内核侧:

    kstate.State.PromptSections *promptsec.Registry   ← 唯一事实来源
    Agent.renderSystemPrompt() 每轮重建时读它

skillmgr 从"实现 SkillIndexProvider 让内核来问"改为"声明自己的段":

    DeclarePromptSection{Section:"skillmgr.skills", Order:100, Volatile:true}

并挂到全部变更点(启动全扫后、移交事件后、load/unload/create/install/
enable/disable 后、Stop 时撤销)。

### 4. 内核自身的提示词段也走同一管理器

按用户裁定「把现在内核所有 systemprompt 的相关注入都接入到这个统一的
systemprompt 管理器上」,把 buildSystemPrompt 里硬拼的十几块
(人格卡/任务提示词/记忆说明/输出规则/工具目录…)改为声明式:
kernelSections() 当轮计算 → 与插件段按 Order 合并渲染。

顺序由 Order 常量决定,改结构变成调常量而不是挪代码块。

## 判据(均经变异验证)

  TestCoreCanImportKstate            真编译探针;环重现则红(实测)
  TestKstateDoesNotDependOnCore      静态版,指向具体字段
  TestKstateIsLeaf                   kstate 不得反依赖上层
  TestRTChildSeesPromptSections      子 agent 能看到插件段
  TestResidentSeesPromptSections     生产实际中招的那一类;变异后红(实测)
  TestRootAgentSeesPromptSections    确认没改坏根路径
  TestNoPromptSectionsMount          未装配时不 panic、不凭空出现段
  TestDeclareTwiceRendersOnce        ★ 回应"会不会多份":声明 5 次渲染 1 份
  TestSectionRemovalTakesEffect      Stop 后段消失
  TestRuntimeUpdateVisibleToExistingAgent  同一实例下一轮看到新内容
  TestSectionOrderIsRespected        Order 生效且稳定

## 验证

  go build ./...                   PASS
  go vet ./...                     PASS
  gofmt -l internal/ cmd/ pkg/     干净
  go test ./... -count=1           63 包全过,0 FAIL
  干净检出(git worktree)           build + 4 包测试全绿

## 未做(见 kernelplan.md)

  T3 security 三单例收敛(含 Store 复用 Codec 的惰性迁移)
  T5 plugin Setter 收敛
  T6 防腐判据(部分已随本次落地)
2026-11-04 11:23:05 +08:00
599252f9b0 fix(ci): ID:19 空表假绿堵口 —— 空表须显式声明 # none,删空与有意清空可区分
check-ci-gates.py: TABLE 捕获体 `(.*?)` 允许空串,表被删空时静默走「无排除项」分支。
现在 ci.yml 里加显式空表标记校验(while 跳过 # 注释行),门脚本补正反自测:
合法 `# none` 必过、完全空体/只空行/非显式注释必红。

ID:18: bootgraph_test.go 失败面引用改为按区分词定位,不再依赖包名/行号。
2026-10-25 07:56:45 +08:00
1905d32053 docs(kernelboot): ID:14 已完成,同步 registry_test.go 失败面第 4 条
## 为什么改
bootgraph_test.go(原 internal/kernelboot/modules/registry_test.go)文件头
「失败面」一节第 4 条是**历史实测记录**,原文结句写着:

    要"红得干净"得让 kernelboot.Run 对 nil 依赖显式报错 —— 那是业务改动,
    不在本线权限内,已记入待办。

ID:14(e70c2b5)做完之后这句成了**假信息**:留着比删掉更有害 ——
下次有人照着它判断「Run 不拦 nil 依赖」,会得出与事实相反的结论。
同时 kernelstate.go 的注释已改成「Run 会显式拦」,两边口径不一致更要命。

## 改了什么(纯注释,**零行为改动**)
- 原记录的「崩在业务代码里」形态**保留**,但明确标注为「ID:14 之前的形态,
  作为为什么需要执行期校验的原始证据」
- 新增「已完成(ID:14,提交 e70c2b5)」小节,写清现在的行为与**实测**结果
- 指向专用回归判据(runtime_dep_test.go / runtimedep_test.go)

## 注释里那句「换成可读报错」是实测过的(非声称)
用真实登记表 kernelmod.Registered() 算 plan 后注入两种变异,均得
*DependencyNotReadyError,**无 panic / SIGSEGV**:
  · 整层逆序    ⇒ 第 0 层拒(produced 为空)
    模块 agent 缺设施 [docmem knowledge llm memory stagehost textmem tracker];
    模块 plugin-host 缺设施 [config docmem kernel-io knowledge lua memory
    stagehost supervisor textmem tracker]
  · 跳过第 2 层 ⇒ 第 2 层拒
    模块 stage-host 缺设施 [knowledge llm textmem]

(初稿写成「第 1 层 … 模块 llm 缺设施 [lua]」,与实测不符,已按实际输出改正。)

## 校验
git diff 中非注释行改动 = 0(grep 计数)
go build ./... = 0 error,go vet ./... = 0 warning
go test ./internal/kernelboot/ ./internal/kernelmod/all/ = ok
2026-10-24 12:58:40 +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