3 Commits

Author	SHA1	Message	Date
JianFeeeee	8d5e31f7c0	feat(agent/core): 中断向量表 —— 三个 L4 源统一登记，行为零变化 ... 用户原话：「需要添加中断向量系统，独立成中断子模块就是为了方便添加这个 中断向量系统」。本次落地该目的。 ## 为什么需要向量表 拆分前"有哪些内核中断、各自什么语义"散落在三个裸调用点上： raiseKernelInterrupt("kernel", "kernel", "任务 #N panic…") raiseKernelInterrupt("kernel/overflow", "kernel", "上下文超页…") raiseKernelInterrupt("child/"+rc.id, "kernel", "驻留子已满…") 三者差异**只在 source 字符串**上，语义契约全靠注释与调用方自律。 最能说明问题的是 panic 的递归保护： if t.Class == TaskInterrupt && t.Level >= LevelCritical { return } // 否则同一个 panic 会自我放大成中断风暴 这条规则只属于"panic 中断"，却硬编码在 reportTaskPanic 里。 **新增一种内核中断时，没人会记得要不要也加递归保护**。 ## 设计 interruptVector 声明一条中断源的完整契约： ID / Level / Source / Guard / Build - Level 由条目自己声明（不再写死 L4） - Guard 收容前置判定 —— panic 的递归保护落在这里 - Build 构造正文（模型唯一可见内容） - 未登记 ID **panic**，不静默降级（打错 ID 会变成"中断发了但没人认领"） ## 改动 新增 interrupt_vectors.go + interrupt_vectors_test.go（7 条判据） 三个调用点全部改为 raiseVector(id, args) 新增 raiseKernelInterruptAt / newKernelInterruptTaskAt 以表达条目声明的级别 ## 行为零变化（刻意） - 三个源的 source/正文/级别与改动前逐字一致 - ExpectsReply 字段**未实现**：按计划 §7.5/§7.6，它属于行为变更 （内核提示不再引起模型整轮回复），必须单独提交、单独验证 ## 变异验证 - 去掉 panic 递归保护 ⇒ TestVectors_PanicGuardBlocksRecursiveL4 红 - 调用点绕过向量表 ⇒ TestVectors_PanicSourceComesFromTable 红 （source="kernel-direct"，期望 "kernel"） ## 验证 go build ./... / go test ./internal/agent/core/ / go test -race 全通过	2026-10-25 14:45:36 +08:00
JianFeeeee	c5f236a569	refactor(agent/core): 中断队列归还调度器，中断管理器只留现场保护 ... 用户裁定：「中断队列就该调度器管理啊，中断管理器只负责进入中断的任务」。 上一版我把 interruptQueues/immediate 也搬进了中断管理器，这是错的： 排队是**调度职责**——判断该不该打断、打断不了先排队、按什么次序再取出来， 全是调度策略，不是"进入中断"本身。 ## 本次改动 中断管理器（interrupt.go）现在只有： - 中断栈 suspendStack（**唯一操作者**：压栈/弹栈都在其内） - 中断屏蔽 critical（对应 CPU 关中断） - 让位信号原语 preemptArmed/preemptLevel - 栈状态钩子 stackNotify 迁回调度器（scheduler.go）： - interruptQueues[5] / immediate 两个字段 - highestInterruptLocked / popInterruptLocked / interruptCountLocked - enqueueInterruptLocked / installImmediateLocked ## 新增边界判据 TestInvariant_InterruptManagerHoldsOnlyStackState 用**反射白名单**钉住边界： interruptState 只允许 6 个字段（栈/屏蔽/让位×2/上界/钩子）。 反向确认 interruptQueues 与 immediate 确实在 scheduler 上——避免"两边都没有"的假绿。 变异验证：把 interruptQueues 塞回 interruptState ⇒ 判据立刻变红 （"中断管理器不应持有这些字段：[interruptQueues]"）。 ## 验证 - go build ./... 通过 - go test ./internal/agent/core/ 通过 - go test -race ./internal/agent/core/ 通过 - 12 条不变量判据全绿 ## 顺带排查：/tmp 是 tmpfs 且已 91% `df` 显示 /tmp 是 8.8G tmpfs，Go 链接期临时文件把它填满， 导致并发构建出现 write ... no space left on device（表现为 某包 `FAIL 0.008s`——不是代码问题）。已改用 TMPDIR=/var/tmp/gobuild（根分区 112G）。	2026-10-25 13:37:29 +08:00
JianFeeeee	b829968ac6	refactor(agent/core): 中断子系统独立成 interrupt.go + 修两处真实数据竞争 ... ## 中断子系统拆分（用户按 OS 中断语义三次裁定的最终边界） 中断类比 OS：只提供中断优先级、中断队列、现场保护、中断屏蔽。 调度器建立在其之上——它问"中断侧该出谁"，然后执行那个任务。 新增 internal/agent/core/interrupt.go（303 行），承载： - 中断队列（interruptQueues[5] + immediate 单槽） - 中断栈（suspendStack）—— **唯一操作者** - 中断屏蔽（critical，对应关中断） - 让位信号原语（preemptArmed/preemptLevel） 留在 scheduler.go 的是**策略**： - 任务优先级语义（Level / effectiveLevel / canPreempt / clampPluginLevel） - 恢复决策（nextInterruptSelection：栈顶 vs 中断队列比较） - 就绪队列 / 停止配额 / 背压 ### 关键设计：中断栈只有中断管理器能操作 调度器通过 stackTopLocked() **只读查询**栈顶做比较， 真正的弹栈由 restoreTopLocked() 在中断管理器内完成。 这条不变量在类型层面无法绕过。 ### 解耦机制：stackNotify 钩子 中断栈变化时通告调度器，调度器据此唤醒调度循环重新求值。 中断管理器不知道调度器会怎么选，调度器也不碰栈内部 ⇒ 将来给中断子系统加向量表或换多栈策略，不必改调度器。 ### 测试 新增 interrupt_invariant_test.go：I1–I7 共 11 条**不变量**判据 （区别于既有的行为测试）。两条经变异验证确认会变红： - canPreempt 改成恒 true → L4 不抢 L4 判据红 - maxInterruptFrames 改成 99 → 上界判据红 - 去掉 notifyStackLocked → 钩子判据红（且判据本身带超时，缺判据是"红"不是"挂"） ## 修两处真实数据竞争（阻塞 CI，非本次引入） -race 实测：internal/agent/core 原有 30 个测试失败，整包被判红。 根因（ab27d1a 上已存在，与拆分无关）： - core/stages.go:withExecuteCtx 往调用方共享的 tc.Arguments 原地写 ctx - io/channel.go:bindExecCtx 同样原地写设备 args 原注释称"args 每次调用独立、天然一 goroutine 一份"，但代码改的是调用方那份。 工具在自己的 goroutine 里跑，超时/取消路径下主 goroutine 仍在读同一份 args。 修法：复制 map 而非原地写。变异验证：退回原地写后 TestPreempt_DeferredDuringToolExec 立刻报 DATA RACE。 ## 验证 - go build ./... 通过 - go test -p 1 ./... 全仓无失败 - -race 三关键包（core/io/proc）全绿，core 从 30 红归零 - CI 门禁自检 / 启动图判据 / 版本一致性 本地通过 ## 遗留（不在本次） - 中断向量表（计划 §7 已设计，按 §7.6 应在拆分后单独做） - maxQueue 仍约束中断队列：OS 语义上说不通，但改它是行为变更，单独立项	2026-10-25 13:19:31 +08:00