本文件只放未完成、要尽快处理的待办（
[ ]开头）——「还有哪些没做」一眼全览。 已完成 / 已更新的条目移入TODO-archive.md归档保留（勿删）。 优先级分类：条目按 🔴 红色紧急度 / 🟠 橙色紧急度 / 🟡 黄色紧急度 / 🟢 绿色紧急度四级分节排列（红色最紧急在前），每条待办写入时必须判断所属级别并放进对应分节；颜色只标在分节标题、条目本身不标颜色 emoji；判断拿不准往高靠。 每条待办带记录时间戳（精确到分钟）与唯一编号（T+序号，全局递增、永不复用，新条目编号 = TODO.md 与 TODO-archive.md 出现过的最大编号 + 1，两文件都扫）。
- T2 客户端设置保存改为「读盘合并」写入，防止用进程内存旧配置快照整体重写
~/.zcode/cli/config.json、冲掉外部对配置的修改（含 hooks 挂载）。为什么：2026-09-04 实测事故（T1 转登材料）——一次客户端设置保存把进程内存中的旧配置快照整体写回用户级 config.json，把外部对 hooks 段的修改（DayTradingAgent 上移到用户级的两条安全 hook）静默冲掉；不修的话，任何经客户端保存设置的时点都可能无声丢配置。T1 落地后项目级 hooks 走 trust store 单源、DayTradingAgent 也将撤回用户级挂载，敞口收窄，但用户级 hooks 段及其它外部工具对 config.json 的修改仍会被冲。做什么：定位设置保存路径（TUI 侧/config类命令或 runtime 侧 config 写入点），把「内存快照整体写回」改为「写前读盘 → 只合并本次编辑目标字段 → 写回」，或至少保留非编辑目标的段（hooks 等）。验证口径：外部修改 config.json 的 hooks 段 → 经 TUI 保存任一设置 → hooks 段原样保留。（记录：2026-09-04 13:10，由 T1 同源风险提示裁定立项） - T5 修复
captureCommand（src/command.ts）启动失败路径抛ERR_STREAM_PREMATURE_CLOSE，实现设计意图的{ code: 1, stderr: 启动错误 }降级返回。为什么：2026-09-06 Hopper 补回归用例时发现（test/command.test.ts 已用test.failing锁定契约）——spawn 的 error 事件触发后子进程 stdout/stderr 流提前关闭，readText()的异步迭代先于Promise.allreject，整个调用抛异常而非返回结果；launchError分支（stderr || launchError）实际永远不可达。受影响调用方：update.ts 调gh（用户未装 gh 时本应优雅报 code 1 + 提示，实际未捕获异常）、zai-oauth.ts / darwin-oauth-callback.ts 打开浏览器。做什么（实现归开发侧）：error 路径下不迭代已关闭的流（如 readText 捕获 premature close 返回已收内容、或 error 事件后直接短路读取）。验证口径：captureCommand("/nonexistent-binary", [])返回{ code: 1, stderr: 非空 }不抛异常；修复后去掉 test/command.test.ts 里该用例的.failing标记（bun 会先反向报错提醒）。（记录：2026-09-06 13:26，Hopper 回归防护网补缺时发现立项） - T6 加固 smoke-tui 冒烟测试的时序稳定性（flaky）。为什么：2026-09-06 PR #1 合并后 main 哨兵 CI 红、重跑即绿——scripts/smoke-tui.ts 的
waitFor（第 82 行附近）等待「Set up model access」界面在 ubuntu runner 上偶发超时，同一份代码 PR 绿 / main 红随机翻转；flaky 会侵蚀「红灯=真有问题」的信号纯度。CI 门禁已精简（3.8.1-32：门禁只跑 bun test + typecheck，冒烟移出），但 publish.yml 发版链仍会跑到冒烟——flaky 不修会在发版时随机阻塞。做什么（实现归开发侧）：waitFor 超时阈值放宽（runner 冷启动慢于本地）、或失败自动重试一次后再判红、或对时序敏感断言加显式轮询上限与诊断输出。验证口径：连续 10 次 dispatch 跑 CI（或 publish validate job）零随机红。（记录：2026-09-06 19:45，Hopper 处理 main 红灯事故时定位立项）
- T3 评估 vendor runtime 升级 3.8.1 → 3.11.2（上游已领先三个 minor 版本）。为什么：2026-09-05 上游调研确认官方稳定版已到 3.11.2（manifest 实测），本项目锁的 runtime 仍是 3.8.1（cliVersion 0.16.3）；中间版本含登录稳定性修复（3.11.2「修复登录态过期、授权回调失败」、3.10.1「优化登录授权流程」）、PDF / 媒体预览、插件按工作区安装等新能力。做什么：跑
sync-runtime拉取 3.11.2 → 核对补丁链（workspace-hook trust、steer 等既有 patch 是否仍命中）→ 全量测试 + 冒烟。边界：BigModel 登录拿不到用户名的问题 3.11.2 未解决（凭证结构与登录流程同构，见 CHANGELOG 3.8.1-27 调研记录），升级不以此为目标。（记录：2026-09-05 22:22，上游调研后立项） - T4 调研 bigmodel「key → 账号信息」查询接口，粘 key 场景自动获取显示名。为什么：2026-09-05 上游逆向发现 runtime 换 key 时调
GET https://bigmodel.cn/api/biz/customer/getCustomerInfo（Authorization = OAuth accessToken），响应含账号 / 机构信息但只取 organizationId / projectId 后丢弃——上游结构性不存用户名（vault 无 bigmodel user_info 槽位）；且 accessToken 不落盘，zcode-cli 无法在 runtime 流程外补调该接口。做什么：调研 bigmodel 开放平台是否有「API key 自查归属 / key → 账号名」的接口（key 自身鉴权），若有则粘 key 登录后自动写入bigmodel-users.json映射，替代手工维护；查官方文档优先，本地实测为辅（n=1 标注）。验证口径：粘 key 登录 → 横幅显示自动获取的账号名而非脱敏 key。（记录：2026-09-05 22:22，上游调研后立项）