JianFeeeee 158395bfdf test(scheduler): 优先级压力测试（100 排队 + 100 中断各级混合、嵌套到 4 帧上限） ...

按需造一个固定内容的 fakeprovider，做两件事：

E4：混合载荷（用户指定的形状）
  100 条排队输入 + 100 条中断（L1/L2/L3/L4 各 25）混合打入。每条中断都等到
  “该被它打断的受害者正在跑”时才注入——调度器是单线程的，闭着眼睛猛灌只会
  让绝大多数中断退化成排队，压力就压不到抢占/挂起路径上。
  判据：200 个任务全部到达终态、Rejected=0、各级登记数=25、**各级抢占数都>0**、
  排空后 Suspended==Resumed、每次“取消流式段”都换来一次挂起。

E5：嵌套到结构上限
  排队任务运行中依次注入 L1→L2→L3→L4（每级都等上一级在跑）。判据：栈深峰值
  恰好 4（= 结构上限，此时 canSuspend()=false），恢复顺序严格 LIFO
  [L3,L2,L1,排队]，Suspended==Resumed==4。

顺带修掉两处：
- **Resumed 双计**：nextRef 弹栈与 resumeTask 各计一次，使“排空后
  Suspended==Resumed”这条不变量失真。现在只在 resumeTask 计（nextRef 只负责选出）。
- 新增分级可观测：SchedulerStats.InterruptsByLevel[1..4] / PreemptsByLevel[1..4]。
  只看总数会掩盖“总数一样但级别分布完全不同”，按级别验收才是这套调度器的判据。
  注意 PreemptsByLevel 是“判定可抢占并进入 immediate”的次数，与 Suspended 不等价：
  受害者可能在让位生效前就自行结束，此时抢占者只是“下一个运行”，没有挂起发生。

教训：provider 必须感知 ctx 取消。第一版没做，结果 LLM完成==任务数、挂起≈0——
抢占全落在“步骤之间”，流式段（真正需要保存/恢复现场的地方）一次都没压到。

验收：go test ./... 37 包 ok 0 FAIL；-race 全绿；压力连跑 3 次稳定；
新内核 go build 通过并真实启动冒烟 OK。

2026-09-13 07:31:32 +08:00

..

zh

test(scheduler): 优先级压力测试（100 排队 + 100 中断各级混合、嵌套到 4 帧上限）

2026-09-13 07:31:32 +08:00

embedding-comparison.md

feat(vector): pluggable multimodal vector space

2026-09-09 17:38:34 +08:00

git-branching.md

docs(branching): 明确开发者文档的发布归属——以 rel 分支的形态为准，再合入 main

2026-09-12 13:05:24 +08:00