从 S4-7 到 S4-8：索引验证与原位更新
S4-7 阶段已经收口，会话记录给出的结论是“等价、可进入启用前评审，生产继续 M0”。22 条独立回放和 386 个冻结时间点与参考一致，两轮五候选排序的 P95 从全扫描的 14.36 毫秒降到索引路径的 0.522 毫秒；200 个 XCTest 方法和 S4-2 的 241 个动态检查全部通过，原先被撤回的重算、重建和重开成本也已经单列出来。这意味着 M2S 派生索引优化在工程指标上是站得住脚的，但还停留在“可用”，没有进入生产切换。
进入 S4-8 后，工作从“算得对”转向“装得上、跑得稳”。一条会话围绕原位更新推进，记录显示 Build 99 已经原位安装并启用索引 M2S，同版本的 H1 至 H6 限定真实 IMK 验收通过，正常数据根和输入源也已恢复。221 项 XCTest、10 项 Swift Testing 和相关动态检查都通过了。值得一提的是，这里没有 stage、commit 或 push，也就是说这一轮的所有验证都在本地完成，仓库历史没有被打乱。会话还专门提到通知“另一个聊天释放验收窗口”，可以看出团队里并行跑着多条会话，互相需要协调独占资源。
不过也并非一切顺利。同一会话自述提到，完整宿主编译通过后发现另一个聊天已经启动了它自己的 Build 99 测试服务，占着同一个 IMK 入口，因此安装和按键验收这一段决定先不抢占，组件验证继续做。两个本轮回归进程曾同时往同一日志目录写东西，最终保留了一份无效日志，决定在最终回归时使用独立目录重新确认。这种“小事故”没有被掩盖，而是被诚实记录下来，作为后续回归时要绕开的坑。
S4-9：异常时间与时区任务的真红真绿
S4-9 的任务包来自 /Users/chenjin/Downloads/Ajin-S4-9-time-consistency-task-pack.zip，主题是异常时间与时区一致性。Codex 会话记录显示，执行流程是先读取完整提示词、test-matrix.md 和 test-cases.json，再核对仓库当前状态，最后按任务包完成实现与验证。
这一轮的结论被记成“A：源码修复及本轮验证通过，未安装”。具体来看：保留了旧差异，并完成了真实的红→绿转换；普通、reload、reopen 三种路径都符合独立逐笔参考；213 个 XCTest、3 个 Swift Testing、S4-2 的 241 个动态检查全部通过；22 条回放和 386 个正常时刻保持兼容；宿主 Debug 和 Release 编译都通过。看上去干净利落，但“未安装”这三个字很关键——它意味着源码层面已经修复，但还没有在真实宿主里走过一遍 S4-9 的场景。
围绕 S4-9 还有一段关于“下一步”的讨论。Codex 会话给出的判断是：下一步应当是“发布 S4-9 已完成的修复，再做小范围真实宿主验收”，不重新调模型，也不再做总审计。S4-10 被初步定义成两个阶段：一是发布前核对，包括核对当前源码、正式安装产物以及 S4-9 增量，保留全部既有改动，冻结待发布源码，备份当前 App，明确回退路径；二是沿已有安装流程原位更新同一个 Ajin App，确认运行状态。这段文字读起来不像是一份热情洋溢的冲刺宣言，更像是一位工程师在确认“修是修了，但别急着放大范围”。
S4-10 之前：功能是否全部落地
“所有功能都落地了吗”是这一天被反复提起的问题。Codex 会话对此的回答很直接：还没有全部落地。如果是指两份文档规定的“第一批功能”，代码已经实现，测试、隔离构建和预览也都通过了，但尚未安装；真实宿主里的焦点、框外点击、同 App 输入框切换、Shift 手势以及设置窗口的实际显示还没有验收，因此不能称为完整落地。当前工程还存在既有源码未加入 target 的构建缺口，这一点也被诚实记录在案。
如果是指整个输入工具体系，答案就更克制一些：目前只实现了工具按钮加上仅含“设置”的非激活工具框，符号、常用语等更复杂的工具尚未接入。换句话说，首期的覆盖面是刻意收窄过的，而不是“全部功能都做完了”。
围绕这套工具，还有一段关于冗余设计的讨论。Codex 会话分析认为，在当前首期阶段，“工具→设置”入口属于冗余设计：首期工具框只有“设置”，状态菜单里也已经有了“设置”项，再加一层入口只会多一步操作，还要引入无客户端时的焦点、键盘和关闭规则，收益很小。建议是收窄范围，保留候选栏工具按钮和非激活工具框用于验证组合与候选保护，状态菜单继续直接打开设置，首期不增加“工具”入口；等符号、常用语等实际工具接入之后，再评估无组合时的统一入口。这种“先收口，再扩展”的思路，和前面“等价、可进入启用前评审”的语气是一致的——先把已经做对的事情稳住，再决定下一步要不要做更多。
另一段解释则涉及“无有效客户端时，工具框首期仅支持鼠标”这条规则。这里的“有效客户端”，指的是输入法当前能确认归属的输入框会话，比如 TextEdit 中正在输入的位置。工具框用的是非激活浮窗，打开时不抢走原输入框的键盘焦点：有有效输入会话时，按键经过输入法，工具框可以处理方向键、Enter 和 Esc；没有有效输入会话时，例如从状态菜单打开工具但当前没有可确认的输入框，按键未必经过输入法，因此首期只允许鼠标操作，不去碰键盘路径。这是一条相当克制的设计取舍，把“不会发生的事”挡在门外，避免在没有真实输入会话时引入更复杂的焦点和键盘交互。
Build 100 候选包与卡在锁屏前的真实验收
到了这一天靠后的阶段，Codex 会话围绕“完成下一步把”推进，记录显示 Build 100 已经原位安装并恢复正常运行，模型与学习授权未变。临时 SQLite 的普通查询、refresh、reopen 三种操作共 480 项独立逐笔比较通过；仍然没有 stage、commit 或 push。但有一句很诚实的话：真实输入验收被 macOS 锁屏阻挡，尚不能宣布本轮完成，请解锁桌面后再来告知，会补齐定点验收并收尾。验收报告的路径被截断在 /Volumes/Sata/Wo…，这本身也提示了当时的工作尚未收尾。
另一条更早的会话则把这一天的“功能边界”描述得更细：实际存储验证已经补齐，常用语增删改、重启后读取、输入码去重和文件权限都通过；损坏数据会保留原文件并提示失败；隔离预览里还发现并修复了页面约束异常。Build 100 当时正在构建包含全部工具的签名候选包，而正式安装的 Build 99 还没有被替换。也就是说，候选包已经在路上，但生产线上的版本还是更早的 Build 99，这种“新包在路上、老包在岗”的状态被明确写进了记录。
最后一条会话的语气更短，也更像是一段交接：“收到，安装/IMK 独占窗口已释放。后续验证以最终 Build 99、SHA-256 091f4b1e…47f5650 为准，不使用旧候选包覆盖。输入工具的真实宿主验收仍待完成。”这段话同时说清了两件事：独占资源已经让出来，验证基线被钉死在了一个具体的构建版本和哈希上；而真实宿主的验收——也就是在桌面解锁后还要做的那一段——仍然是悬而未决的尾巴。
收尾时的状态
把这一天放在一起看，Ajin S4 的几条线都往前推了一截：S4-7 的索引验证继续维持“等价”结论，S4-8 把 Build 99 原位安装并启用了 M2S，S4-9 的异常时间与时区任务在源码层面做出了红绿对照的修复，S4-10 的发布前核对和原位更新方案被草拟出来，Build 100 的签名候选包也在构建中。但与此同时，几个未完成的事项也被一并保留下来：真实宿主里的焦点与按键验收被 macOS 锁屏挡住，首期功能是否算“完整落地”仍要等验收窗口，工具框的无客户端键盘路径被刻意延后，仓库历史没有任何 commit 或 push。
这些记录读起来不太像庆祝，更像是一位工程师在一天结束时，把做对的事、做了一半的事和还没开始的事逐条摊在桌上。Build 99 的哈希被钉死，Build 100 的候选包在路上，桌面解锁后的那一步定点验收，是这一天留给第二天的入口。