3 Commits

Author	SHA1	Message	Date
JianFeeeee	86a702b3b0	fix(scheduler)!: 中断栈语义（嵌套抢占 LIFO），并修掉抢占空转 ... 用户指正：存在**中断被中断**的场景，所以被打断的现场要进**中断栈**。 我此前把 suspendPool 明确写成“不是栈、按优先级取”，是错的。 改动： - suspendPool 改名 suspendStack，恢复纪律改为**严格 LIFO（只比栈顶）**； 栈内不做优先级重排——嵌套抢占天然使栈自底向上基础级递增， 且“后被打断的先恢复”才是栈语义。取出即弹栈。 - 修掉一个由此暴露的真 bug（抢占空转）：一次抢占生效后，被挂起的原任务 会因饥饿防护提升有效级，与抢占者同级；此时若按“先到先服务”，原任务 （入队更早）会被立刻选回，抢占者永远排不到 —— 抢占等于没发生。 现在**同级时 pendingInterrupts 优先于其它两类**，保证抢占必然生效。 - 状态 DTO：SuspendPool/suspend_pool → SuspendStack/suspend_stack - 设计稿：§2 用语更正（它**就是**中断栈）、§4.1 选择函数（候选只含栈顶 + pending 同级优先，并说明为何必需）、§6.2/§6.3/§9/§11 用例同步 测试新增 scheduler_stack_test.go 3 项： - 嵌套 L1→L2→L3，恢复严格 LIFO（B 先于 A） - 只比栈顶：人为构造“栈底 L3、栈顶 L2”，必须取栈顶（区分两种实现） - 嵌套下的深度上限 验收：agent 全量 + -race；全仓 build/vet 通过	2026-09-13 06:30:23 +08:00
JianFeeeee	a971fc8877	feat(scheduler): M5 饥饿防护（抢占计数提升有效级 + 抢占冷却） ... 设计依据 docs/zh/input-scheduler-design.md §9、§11.5（G1/G2）。 - Task 增加 PreemptCount / LastPreemptAt；effectiveLevel(t) = min(L4, Level + min(PreemptCount, 2))：被抢占越多越“值钱”， 逐步追上抢占它的流，但封顶 L4 因而抢不过真正的紧急输入 - 选择函数 taskBefore 改用有效级；requestPreempt 与 preemptGrantedFor 同样以有效级比较 - 抢占冷却 preemptCooldown=2s：刚被抢占的任务期内不再被抢占， 避免同一任务被反复打断到永不完结 - 新增 scheduler_starvation_test.go 4 项：提升与封顶、冷却期内不得再抢占、 提升后同级不得抢占而更高可、选择函数确实用有效级 - 验收：agent 全量 + -race；全仓 build/vet 通过	2026-09-13 00:38:30 +08:00
JianFeeeee	7565248f61	feat(scheduler): M4 临界区显式化 + 清掉被 pendingInterrupts 取代的 interceptCh ... 设计依据 docs/zh/input-scheduler-design.md §4.3、§11.1（P5/P6）。 - 临界区语义显式化：让位检查**只在 step 之间**做，执行中的 step （工具 RPC / ONNX / CAS 落盘）天然不可抢占；_consolidation_ 整任务 经 inCriticalSection() 判为不可抢占（它直接改图库） - 删除 interceptCh 与 drainInterrupts：M3b 起中断一律走 pendingInterrupts， 旧的「同行注入 + 三处 drain + 批次放弃」已无写入者，属死代码 - 新增 scheduler_critical_test.go 3 项： P5/P6 工具执行中 arm 了让位信号也不得挂起、必须等工具返回后的安全点； _consolidation_ 判为临界区；无抢占时同批工具必须全部执行（新语义回归） - 验收：agent 全量 + -race；全仓 build/vet 通过	2026-09-13 00:34:39 +08:00