codebee 0.1.59 → 0.1.61

package/CHANGELOG.md

@@ -24,6 +24,17 @@ README 元数据带回，供老版本在「发现新版本」时展示新版更
 
 - **首选 KEY 超限自动切备用了**：同厂商多密钥此前只认欠费类文案——首选 KEY 撞上 429 限流（智谱「并发数超过限制」「每分钟Token数已超过上限」、claude 的 rate_limit_error、codex 的 "429 Too Many Requests" 等）只记一笔错误、不进冷却，每个新步骤仍从超限的首选 KEY 重新烧起。现在限流文案与欠费同口径：进冷却 30 分钟、密钥镜像自动切下一把、链展开跳过冷却中的 KEY（到期或「恢复」按钮一键回首选）。顺带补一处漏账：无显式链时「换模型回退」的链条目不带 KEY 标记，这类重试失败此前完全不记 KEY 账。
 
+## v0.1.61（2026-09-24）
+
+- 修复 mimo 评审器永远 Invalid API Key 的根因：mimo 不读任何环境变量 Key，唯一通道是配置内的 provider 块——现已自动注入（绑定即生效，Key/端点/模型一起落盘）。禅道双单 20+ 轮评审全灭实案
+- 「完成·未达标」琥珀色胶囊：跑完但评审未通过的任务不再显示成「完成」，一眼可辨
+- 同工作目录并行硬限制（后来者排队等待，60 秒自动重试）
+
+## v0.1.60（2026-09-23）
+
+- 同工作目录并行硬限制：两个任务共用同一工作目录时，后来者自动排队等待（每 60 秒重试，先来者完成自动放行）——不再只是告警，彻底杜绝任务计划/项目记忆/分支检出互相覆盖（禅道双单实案）
+- 工作目录被占用时任务卡片显示「将于 HH:MM 自动续跑」，排队原因可见
+
 ## v0.1.59（2026-09-23）
 
 - 评审器故障不再伪装「评审未通过」：评审器鉴权失效/崩溃时（实案：Invalid API Key 整晚空转修复轮），任务以「评审器故障（评审未执行）」明确收口，不再烧无意义的修复轮

package/README.md

@@ -21,10 +21,11 @@ Kimi Code、MiMo Code、Grok Build、Pi、DeepSeek Harness……），提供
 不会把你的任务内容交给任何第三方。
 
 <!-- relnotes:start -->
-### 最新版更新内容（v0.1.59）
+### 最新版更新内容（v0.1.61）
 
-- 评审器故障（如 Key 失效）明确报错，不再伪装成「评审未通过」空转修复轮
-- 同工作目录并行任务自动告警；后台标签页让出连接，多标签不再互相挤超时
+- 修复 mimo 评审器永远「Invalid API Key」：Key 通道缺失（非 Key 失效），现自动注入配置
+- 「完成·未达标」琥珀胶囊：跑完但评审未过不再伪装「完成」
+- 同工作目录任务自动排队，互不覆盖
 <!-- relnotes:end -->
 
 ---

package/app/core/branching.py

@@ -39,9 +39,16 @@ def plan_branches(run_id, task, i, goal, outline_txt, prev, n, *, log_path=None)
     不是闸门）。全部分支连同 pick 追加 .codebee/branch-plans.md 审计。"""
     if n < 2:
         return None
+    # Token 压力守卫：压力 > 0.7 时跳过推演——每次推演是额外 4000
+    # max_tokens 编排者调用；长篇后期预算紧张时推演是第一个该省的增强
+    # （压缩守卫先跑、推演不跑，省下的预算留给正文章稿）。
+    try:
+        from . import token_meter
+        if token_meter.pressure_ratio(run_id) > 0.7:
+            return None
+    except Exception:
+        pass
     from . import modelhub, runner
-    if n < 2:
-        return None
     orch = modelhub.resolve_orchestrator()
     if not orch:
         return None