qyqy
af6f689b3f
合并 ZSY 分支前必须先做的对齐。核对结论与"线没接"的旧说法**不一致**：
**主干那条链其实已经接好了**——架构师在 09-10 21:52 的 d7f6ef7 就做完了"记忆→画像→图全自动触发"，
走的是 `domain_event_outbox` + `profile.rebuild_requested`，**已注册进 runtime.py 的 handler 白名单**：
agent.run_completed → memory.extraction_requested → MemoryExtractionService（提升 user_facts）
→ profile.rebuild_requested → ProfileAssemblyService 重建画像 + ProfileGraphProjectionService 投影 Neo4j
而 ZSY 走的是**另一条 outbox**（`memory_sync_outbox` + 自建 MemorySyncOutboxWorker）。
⇒ 两条平行链做同一件事，但 outbox、画像生成方式、消费装配都不同。
顺带修正一处旧结论：`graph_projection_worker.py` 确实**零实例化**（架构师说的对），
但由此推论"整条链没接"不对——接的是 handler 字典，不是那个类；那个类是死代码。
文档内容：
- §1 主干链的完整链路与引入者、现场数据（user_facts 0 行 / memory_sync_outbox 2 行是**我的**生产者写的）
- §2 ZSY 的**真正增量**逐文件列表（只有 3 个是主干完全没有的：Milvus 画像投影适配器、
memory_sync_outbox worker、画像候选复核流程）
- §3 四个必须对齐的分歧（两条 outbox 的分工 / 直接快照 vs 候选复核 / 两套客服 Agent / ZSY 落后 144 提交）
- §4 三步收口方案（先只移植投影适配器，再定 outbox 分工，其余等裁决）
- §5 给架构师与张胜宇的四个问题
- §6 明确不做的事（不整体合并、不改已验链路）
文档守卫通过；本文只做核对，未改任何代码。