返回 TraceWise 项目总览 · 交互图：AF · X01 · 请求 · 时序 / 权威 · 切换 · 生命周期 / Foundation · 集成
第一个 Pilot 成功时，很多迁移问题并不会暴露。测试数据量小、身份恰好相同、环境路径固定，系统很容易给出“已经完成平台切换”的乐观印象。
TraceWise 的第二个真实项目证明了为什么一个 adopter 不够。第一个 Pilot 的业务 Project ID 与 Graph ID 恰好相同，隐藏了适配器把两种身份当成同一个值使用的问题。直到选择 model-post-training——业务 Project ID 与 graph_id=demo 明确不同——这个混淆才变成可复现故障。
这篇文章不是迁移宣传稿，而是一次身份不变量、项目级 opt-in 和可恢复交付的工程复盘。
两种 Project ID 分别属于谁
TraceWise 的业务 Project ID 用于：
- 产品路由；
- 用户授权上下文；
- 项目历史；
- 报告、Timeline 和工作台导航。
Graph ID 则标识产品 Graph。AF-X01 的 Registration 不变量要求 Foundation Graph authority 的 project_id 与这个 Graph ID 对齐。
第一个 Pilot 因为两个 ID 相同，没有暴露错误。适配器把业务 Project ID 同时传给 Foundation，看起来仍能工作。第二个项目中，model-post-training != demo，Registration 身份不再匹配，隐藏问题才被看见。
修复没有把两种身份重新合并，而是明确保存 foundation_project_id：TraceWise 继续暴露业务 Project ID，Foundation 使用从冻结 Graph ID 派生的不可变项目身份。旧 Cutover record 如果缺少新字段，可以从其冻结 Graph ID 推导；显式不匹配则失败关闭。
项目级切换，而不是全局开关
Authority 切换最危险的捷径，是设置一个全局环境变量，让所有项目同时改走新后端。这样无法逐项目验证，也难以确认未迁移项目是否被影响。
TraceWise 的 Cutover Registry 默认为空。每个项目需要独立完成：
- 读取当前 Authority 状态；
- 形成 zero-write plan；
- 建立独立 Registration；
- 迁移并逐条记录 Evidence receipt；
- 准备 Graph Proposal authority；
- 显式 activate；
- 阻断旧 Authority 写入；
- 重启后重新读取已持久化状态。
未 opt-in 项目继续使用原产品 Authority。新路径不可用时，已切换项目也不能偷偷 fallback 到旧写入路径。
技术解释图：Authority 切换是项目级持久状态机，不是全局布尔开关。
为什么先做完整备份
这次变更会写入 canonical local persistence，因此在激活前先完成 11 个数据文件的预切换备份，并记录源数据库 SHA-256。备份的作用不是让文章声称已经拥有生产 DR，而是提供一个可恢复的本地变更起点。
随后在 clone 环境先执行同一过程，验证：
- 源数据库保持不变；
- 新 Registration 与原 Pilot 不同；
- 107 条 Evidence 分别产生 migration receipt；
- exact replay 不产生重复数据；
- 原 Pilot 身份保持不变；
- protected product rows 保持不变；
- opt-in 后旧 Evidence 写入被阻断；
- 未 opt-in 项目保持 legacy compatibility。
Clone 通过后，才对 canonical local project 执行正式 opt-in。
107 条 Evidence 不是一个汇总数字
被选项目包含 48 个 Entity、77 个 Relation、107 条 Evidence、17 个实体版本、2 条规则和 5 个历史 pending Proposal。Authority 切换只迁移当前授权范围内的 Evidence，并为每一条生成 receipt。
逐条 receipt 的价值在于：
- 可以确认没有少迁或重复迁移；
- 可以把源 Evidence 与目标 Authority 绑定；
- exact replay 可以判断已经处理过的项；
- 失败可以定位到具体资源，而不是只有一个“迁移失败”状态；
- 后续重新打开项目时可以检查 Registration 与 receipt 数量。
这不意味着其他历史、Simulation、报告或所有业务表都迁移到了 Foundation。TraceWise 仍然拥有自己的产品状态。
技术解释图：Plan 与 Prepare 不直接写 Graph；Review 后由独立 Executor 消费冻结 Proposal。
人审没有因为平台切换而消失
项目 opt-in 后，Graph 变更仍然不能由模型直接执行。TraceWise 将 Registration、Graph baseline、Evidence bindings、operations 和 principals 编译成 Foundation Proposal。Reviewer 在现有业务入口形成决定，独立 Executor 消费 approved outbox。
切换改变的是 Authority 执行位置，不是业务控制权：
- TraceWise 继续拥有用户工作流、模型、Prompt 和 Graph/Evidence 产品语义；
- Foundation 拥有注册后的 Proposal、Decision、Executor 与 receipt 契约；
- Reviewer 不直接写 Graph；
- 旧 Evidence revision 或 Authority drift 会失败关闭；
- 已切换项目的旧写接口返回明确 boundary error。
技术解释图：平台采用改变执行 Authority，但不转移 TraceWise 产品所有权。
正式包重新打开为什么重要
如果验收只在源码目录中执行，结果可能依赖 editable install、PYTHONPATH 或未打包文件。第二项目完成切换后，系统从可复现的 tracewise-product==0.2.0a12 wheel 重新打开 canonical 状态，确认：
- 普通 wheel 非 editable 安装；
- import 来源为
site-packages； - Foundation 版本精确固定；
- Registration 数为 2，且彼此独立；
- 107 条 migration receipt 仍可读取；
- 第一个 Pilot 身份没有变化；
- 未 opt-in 项目仍保持 legacy compatibility。
两个独立 clean build 还产生 byte-identical wheel，并确认源码与 wheel 中 62/62 Python 文件一致，没有额外、缺失、篡改或禁止条目。
回滚为什么不是 automatic
切换涉及 TraceWise 产品状态、Foundation Registration、Evidence authority 和 Graph Proposal 状态。没有统一跨存储事务时，不能把“存在预切换备份”宣传成“一键自动回滚”。
当前 acceptance 明确记录 rollbackAutomatic=false。需要回退时必须协调产品与 Foundation 状态，并依据备份、receipts 和当前 Authority 判断，而不能单独恢复某一个数据库后假设系统一致。
这次验收真正证明了什么
它证明：
- 业务 Project ID 与 Foundation Graph authority ID 已被分开；
- 两个真实受控本地项目可以拥有独立 Registration；
- 第二项目完成 107 条 Evidence receipt 迁移；
- exact replay、重启 reopen 和旧写阻断成立；
- 第一个 Pilot 与受保护产品行保持不变；
- 未 opt-in 项目保持旧路径兼容。
它没有证明：
- 所有项目已经迁移；
- 迁移适合生产数据规模；
- 系统具有自动 rollback；
- 已完成生产 IAM、TLS、Secrets、HA 或 DR；
- 长时间生产流量和 canary 已验证。
第二个真实项目的价值不在于把数量从一变成二，而在于它打破了第一个 Pilot 的偶然条件。只有当业务身份、Graph 身份、Registration 和 Evidence receipt 在不相同的真实项目中仍能对齐，项目级 Authority 切换才开始成为可复用能力。