iomgaa
4534444ad8
The ordering is the load-bearing part. All three changes interlock and every wrong interleaving fails silently: flipping the usage fallback to (0, 0) before the settlement points read the derived value refunds the whole pre-deduction on success, and flipping the embedding transport before _merge goes three-state mislabels unavailable batches as measured. So the plan adds the capability first, moves all five call sites onto it while it is still equivalent, only then lets the third state take effect, and unbinds the constraint last. Registers both wiki entries and links the plan to its design.
2.0 KiB
2.0 KiB
type, node_id, title, date
| type | node_id | title | date |
|---|---|---|---|
| plan | plan:est-tokens-decoupling | est_tokens 解耦实施计划 | 2026-07-30 |
est_tokens 解耦实施计划
全文见 2026-07-30-est-tokens-decoupling-plan.md。实现设计 est-tokens-decoupling。
- 5 个任务: T1 加派生能力与三态值域常量(零行为变更)→ T2 五个入场/结算点切到派生值(零行为变更,因显式值优先)→ T3 值域三态生效(行为变更主体)→ T4 解绑
tpm > 0 ⇒ est_tokens > 0(派生值真正启用)→ T5 权威文档、CHANGELOG、wiki 与 issue 回帖。 - 排序是硬约束,不可调换: 三处改动互相牵制且中间态静默偏差、不报错。先改 usage 兜底为
(0,0)而结算点未切派生值 → 成功调用押金整笔退回(TPM 闸退化成进门即放行);先解绑约束而结算点未切 → 同样泄漏;先改openai_compat.py:176而_merge仍是二值any(=="estimated")→unavailable批被误标measured且 cost 照算。 - T2 的等价性是安全阀: 约束未解绑时
effective_est_tokens()恒返回显式值,故 T1/T2 后行为逐字不变,现有测试全绿即为证明;T3 才是唯一的行为变更点。 - 保真校验(不新增移植,但触及关键资产): 不得改 Redis Lua 与内存后端的窗口/租约算法(只改传入
try_acquire的数值来源)、不得改settle多退少补与幂等语义、不得改错误四分类归属、ocr.py一字不动、遥测 18 字段冻结且无 DDL。 - 最易漏的测试: T4 的"成功侧结算不退多"——未填
est_tokens且 usage 帧缺失的成功调用后,TPM 窗口残留须等于派生预扣量而非 0。这正是独立审查在设计阶段抓出的缺陷,实施阶段必须有回归钉死。 - 发布口径: 缺口度量必须写成
WHERE usage_source='unavailable' AND cache_hit = false——缓存命中行按裁决 cost 为0.0且标unavailable,本无账目缺口,不加限定则度量偏高。