qyqy
f1b8cb859a
docs: 新增《接手文档 · NL_develop 这条线（给架构师）》
面向"接手维护"而非"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 四份文档的分工表（防止读串）
2026-09-11 19:32:19 +08:00
..
2026-09-11 16:28:19 +08:00
2026-09-11 18:42:46 +08:00
2026-09-11 15:25:45 +08:00
2026-09-11 14:46:40 +08:00
2026-09-09 21:55:37 +08:00
2026-09-10 15:55:54 +08:00
2026-09-11 17:26:18 +08:00
2026-09-09 21:55:37 +08:00
2026-09-11 18:42:46 +08:00
2026-09-11 15:38:11 +08:00
2026-09-11 18:42:46 +08:00
2026-09-11 18:56:26 +08:00
2026-09-10 15:55:54 +08:00
2026-09-11 18:56:26 +08:00
2026-09-11 18:42:46 +08:00
2026-09-11 14:46:40 +08:00
2026-09-11 18:56:26 +08:00
2026-09-11 18:42:46 +08:00
2026-09-11 14:46:40 +08:00
2026-09-11 14:46:40 +08:00
2026-09-11 14:46:40 +08:00
2026-09-10 15:55:54 +08:00
2026-09-11 14:46:40 +08:00
2026-09-11 15:40:32 +08:00
2026-09-10 15:55:54 +08:00
2026-09-11 09:49:21 +08:00
2026-09-10 18:35:52 +08:00
2026-09-10 21:36:23 +08:00
2026-09-11 14:47:08 +08:00
2026-09-11 14:47:08 +08:00
2026-09-11 15:40:32 +08:00
2026-09-11 19:15:23 +08:00
2026-09-11 18:42:46 +08:00
2026-09-09 21:55:37 +08:00
2026-09-11 19:15:23 +08:00
2026-09-11 16:57:47 +08:00
2026-09-11 16:57:47 +08:00
2026-09-11 19:32:19 +08:00
2026-09-11 19:15:50 +08:00