qyqy
f1b8cb859a
面向"接手维护"而非"review"的第三份文档，与另两份分工明确： - 交付说明 → review 用（我动了你什么、为什么） - 评审意见回复 → 对照你的评审意见 - **本文** → 接手维护用（起点在哪、有哪些坑、哪些待裁决） - 给下一位开发者 → docs/superpowers/handoff/… 内容要点： - §1 三条最要紧的结论：① 两台机器不是同一套环境（附三处实测证据）并由此立下两条硬纪律 （环境相关结论必须带环境限定、禁止硬编码 Milvus 字段名）；② **表数已从 51 变 68** （同事 11 个迁移新建 17 张 offsite_*/promotion_* 表），而 docs/00 基线与 docs/02 未更新 —— 已提示、未擅自改不可变基线；③ 测试 3 failed 均非代码缺陷（附证据） - §2 环境口径（含 Docker Desktop 不常驻、mypy 不可比的实测根因） - §3 分支与提交 + 两个可回退的备份分支 - §4 交付清单（8 项，含状态与位置） - §5 必须知道的 5 个坑（Milvus 读一致性与字节截断、config_release 整版本替换、 两个 outbox 不能混、审计表无 agent_type 列） - §6 待你裁决的 3 件事（白名单补发归属、接线归属、两处文档让号） - §7 建议你拍板的两件事（文档体系口径、docs/00 是否补 17 张新表） - §8 接手后先跑的 5 条自检命令 - §9 四份文档的分工表（防止读串）