自研方案做到一半，越来越不对劲
当时我在做一个 ROS2 Integration Goal。
技术路线已经讨论过，Requirement 也冻结了，Route B Sidecar 甚至已经有了一套能工作的实现。
但越往后做，要补的东西越来越多：生命周期、重连、自定义消息、二进制传输、Clock、TF、Diagnostics......
每个都不是不能做，就是做着做着开始觉得：
我到底是在做 ROS2 Adapter，还是莫名其妙自己造 ROS2 Integration 了？
旧方案能跑，代码也写了一半，所以又不是那种可以毫无心理负担直接扔掉的东西，这种"明明继续做也能做完，但越做越觉得哪里不太聪明"的状态实在难受。
Prior Art Review，别人好像已经做完了
我问 AI 能不能调研下现有的成熟方案是怎么做的，他说这叫 Prior Art Review。
翻成人话就是：先别写了，看看别人是不是早就把这些坑踩完了。
然后就查到了 TempoROS。
现有方案到底能不能接入呢？还是要先验证一下的。于是Route B 继续保持不动，新的方案放到隔离项目里旁路验证：Lifecycle、Custom Message、大 Payload......
就在大 Payload 的时候还真遇到了问题， 6 MiB FString 大概要用20多ms，大量挤占 Game Thread 的线程时间，或者说已经超过 16.67ms 了，险些否决这个方案。后来又做了实验，才发现是转换时间过长，换 Binary Image 才变成 2-3ms 左右的 mapper 用时，通过验收。
到这里才算：
不是"这个方案看起来不错"，而是真的有证据证明它可以替代旧方案。
旧方案如何清理，才是真正的麻烦
让 Coding Agent 接受新方案很容易，你说以后走 TempoROS，它基本马上就会开始干，但是他真的会完全忘记之前的方案吗？但是他上下文压缩后真的会忘记之前的方案吗？
哦，他会，于是他会去读文档，这个时候，他还能分清谁是真方案吗？我替他问了：为什么这个项目的代码这么乱？怎么有两种方案叠在一起，我该按哪个执行？干脆都保留吧。
也就是说，旧方案已经形成了 Plan、Requirement、代码、测试和一堆调查证据。
如果只是再写一个新方案，最后将是：
旧方案：有文档、有代码、有证据
新方案：也有文档、有代码、有证据然后下一任 Agent 非常认真地：
两边都有道理，那我综合一下。
喜提一个没人设计过的缝合怪。
所以这次没有搞什么 Plan-v2、Final-Plan。
还是同一个 Active Plan，还是同一套 Requirement Ledger。
新证据改变了 Current Decision，但以前的证据也没有删，而是明确降成 Historical Evidence / Superseded。
我认为这是一个很明确的区分：
旧方案没有消失，它只是失去了投票权。
它甚至还能解释"当时为什么这么做"，但再也不会允许回答"现在应该怎么做"。
整个流程大概是：
css
旁路证明新方案
→ 修改当前决策
→ 主项目实现新路线
→ 完整验收
→ 确认新路线站稳
→ 删除旧 Route B
→ 删完再验一遍也就是先把新桥修通，确认真能走，再改路牌，最后才拆旧桥。
旧 Sidecar、Bridge、Framing、Reconnect 等实现最终真的被删掉，而且删除以后重新 Build、Automation，确认项目仍然成立。
挑战已经成功，现在是总结时间
Goal 完成后，Plan 归档进 Archive；当前事实进 Architecture 形成契约；为什么长期选择 TempoROS，则由 ADR 长期记录。
后来我把这种做法也整理进了 DocOS：
这次最大的感受其实不是"换方案成功了"。
而是：
让 Coding Agent 改主意很简单，难的是让整个项目一起改主意。