把连续性做成工程对象

这一天最明显的变化，不是又多开了几个方向，而是我开始更明确地把“连续性”本身当成工程对象来做。可用证据主要来自本地 Codex 会话和几个仓库里留下的同日产物；Claude 这天没有命中，remote Codex 也没有补出额外来源，ChatGPT 导出还卡在网络解析失败上。但现有证据已经足够一致：我不再满足于知道系统当下大概发生了什么，而是不断逼这些系统把重连、回放、迁移、分发和续跑都变成可重复、可解释的结构。

凌晨，这条线先落在 openword。前一天还在确认 WPS web editor 把多少行为留在前端，到了这一天，工作已经明显进入对 doc_viewupdater 的正式接管：TASKS.md、STATUS.md、capture-playbook.md、capture-helper.js 和 canonical model 持续收束，方向也从“再抓一些样本”变成了“把行为整理成可采集、可归类、可回放、可校验的合同”。仓库里的痕迹把这点压得更实，样本累计到 94 个，后面又补进了 annotation 语义、workflow router 和 shared-field runtime 这些更像内部解释器的层。也正因为这条线长期依赖浏览器和调试链路，chrome-devtools-auto-allow 这种看起来偏辅助的 skill 才会在同一天出现，它的作用不是添花，而是让这套长期调查别轻易断档。

上午到中午，注意力转向 codex-suite 和 lvshe-fe，但底层问题没有变。在 codex-suite 里，我追着几小时后重连就会冒出的 The setup code expired before the workspace opened 这类报错去拆，它到底对应 pairing、secure link 还是 setup code 的不同失效语义。问题已经不是“为什么又断了”，而是要把不同的失效路径整理成可解释、可恢复的状态机。同一天的 Android 提交和 QA 文档把这条线继续压实，晚上的 iOS 实现也不是补一个界面，而是去搬运 host protocol、WebView bridge、tailnet runtime 和 bootstrap hydration 这些真正决定会话能不能持续的基础件。lvshe-fe 那边看起来换了题，在做 apps/lvshe-desktop，但方向其实一致：把原本只活在 Web 容器里的能力，推进成有构建、打包、更新、发布路径的独立表面。

到了傍晚和夜里，这种倾向反而更清楚。openword 白天积累的 capture 和 baseline 工作，已经不再满足于“样本越来越多”，而是在往语义运行时收口；codex-suite 的 working tree 和生成产物则说明 iOS bridge、XCFramework 这些更重的承接层开始真正落盘，移动端这条线也在从 Android 单点修补走向跨平台接续。最后那段关于“更适合做 skill 还是 plugin”的讨论，看起来像在抽离话题，其实是在给整天的主线补一句方法论：如果一个工作流的关键问题是会不会中断、能不能轮询、是否需要持续盯住内部状态，那它大概率就不该只活在一次 prompt 里，而应该有更稳定的包装层。

回头看，2026-03-31 真正推进的不是单一功能，而是一种更耐久的工作方式。WPS 这条线开始从观察黑箱转向建设回放系统，移动端这条线开始从报错排查转向会话连续性的明确契约，桌面端和 iOS 端则继续把既有能力迁到新的宿主表面。还没收口的问题也都留在这条主线上：doc_viewupdater 距离真正替代黑箱还有多远，codex-suite 的 iOS host 协议能不能和 Android 的恢复语义收成一套，lvshe 的桌面端最终会只是打包外壳，还是会逼出更稳定的宿主边界。这一天的价值，就在于这些阻力已经不再只是感觉，而开始有了能继续咬下去的工程抓手。