docs(.agents): tech-decisions §12 续——阶段一② mini-desktop 真门窗口两轮结论落档(cutover 三接缝闭合+两正交风险)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.agents/knowledge/tech-decisions.md

@@ -202,3 +202,5 @@ Nacos / RocketMQ / Sentinel 从「已选型未部署」推进到自托管 mini-i
 **红线③ 在 cheap 侧复现（整分支终审才抓到）**：①只在 tier2 `run.py:866` 封了「陈旧 verdict 假绿」，②把 cheap 的两条读盘路径（`cheap_gates` 起 play 前 / driver 收口读 verdict）原样带了进来、都没清残留——同 gameId 重跑局加某次门跑 harness 打嗝，或零门跑路径（setup 静默失败 / SSE 超时未跑一次 check），就会把上一局的绿 verdict 当本次结果放行加落库。这条 per-task review 结构上看不到（跨 `cheap_gates→cheap_run→serve-and-play→driver` 四层加跨任务生命周期），fable 整分支终审才揪出，按①原样两处 unlink 封死（`cheap_gates` 起 play 前 + driver scaffold 后回合前）。**教训：一条红线在一条路径上封了，不等于封完——每条共享同一脆弱模式的路径（这里是「读盘 verdict 不预清」）都要扫一遍；①的 follow-up 甚至已写到「并发 run_gates 撞端口与陈旧 verdict 复合」，却仍漏了 cheap 侧那次真正的封口，直到看整条分支的终审才补上。** 同批还修了 driver 对 Service 的 setup POST 无状态检查（合法 JSON 的错误响应会让 id=None 往下走、空等 SSE 超时约 600s 才降级——触外部交互红线，改 None 即 fail-fast）与 `acquire_ports` 在事件循环里同步阻塞（池耗尽冻死整 Service，改 `await to_thread`）。
 
 **follow-up**：真门 e2e 排 mini-desktop 窗口（单 POST 收敛 + 续修真拦 + C2 首轮不越界 + C1 成功局 costRmb≠0 + 并发不撞端口 + 七值回调 + 代理旁路 + **盲修空转率**——最后这条是决策留的头号观测项：cheap 无九门自检工具、agent 每次纯文本终止后 check 才第一次真跑门、不过就据 feedback 盲修，空转会显著抬时延，cutover 后量真实空转率再定是否加自检工具）；cheap-worker 全套有 14 个 `test_toolkit.py` 失败，是 pre-② 的测试隔离污染（某测试污染 test_toolkit 依赖的共享盘态，单文件跑与排除②新测试都复现），与配置控制面无关、待单独修；有界 worker 池真并发 cap（承①，端口池是为它设计的机制、真放开并发才用得上）。
+
+**mini-desktop 真门窗口验证（2026-07-03，两轮）**：② 归并 cutover 三接缝真门全闭合——单 POST 收敛 / 续修真拦放行 / C2 目录一致 / 代理旁路无 502 / result_out 承重，外加窗口暴露并已修实证的两个部署接缝。其一，requirements 补 `agentscope[service,storage]==2.0.2` extras——裸钉 `agentscope==2.0.2` 缺 fastapi/uvicorn/apscheduler/redis，全新 venv 起不动 Service，而 SDD 单测只 import 到 create_app 之下、真起服务才暴露（`cheap-worker` 与 `tier2/gen-worker` 同款）。其二，成本子系统改用 per-POST 凭据的 key（`current_model.credential.api_key`，SecretStr 公开字段）取价，不再依赖 Service 进程 env NEWAPI_KEY——成功局 costRmb 从 `0.0/degraded` 变 `1.0785/active`（commit `24e558a4`，B深 per-POST 取价 + B浅 `build_cheap_app` 调 `ensure_api_key_env` 双保险）。红线③ 用植入带 marker 的绿 verdict 做受控 e2e 坐实：marker 在 M3 完成前即被 driver 侧 unlink 清掉，终局是本局自产的真 verdict（pass=False）而非假绿。**但便宜档真生成当前系统性产「菜单空壳」（E_live/G_input/H_progress 未过、输入不驱动状态），并撞 MiniMax-M3 `400 tool result's tool id not found(2013)`（崩 ChatService.run → driver idle 600s 慢失败）——这属生成质量（WU-B/C/F）与 M3 可靠性，与 ② 归并正交，但决定便宜档实际可用率、cutover 真上线前需另线解。** 归并交付面 cutover-ready，「便宜档真能上线可用」是另一条线。