三条线并行：输入法 M8 落地、Loop 面板启用、Sidecar 首链路通

如果只看 commit 数量，今天 25+ 次提交分散在四个项目里，像是"什么都碰了一下"。但拆开看完成的任务和 QA 评分，会发现一个更有意思的模式：三条独立的工程线在同一天各自达到了一个可验收的里程碑。

这不是巧合。是上周规划的"切片化交付"策略开始兑现了。

输入法 M8.0：四个切片一天收完

macOS 输入法今天完成了 M8.0 的四个核心切片，全部通过独立 QA（三项 cake=20，一项 cake=18）：

切片	内容	QA 评分	关键验收点
M8.0-00 + A1-A6 + B1-B3	基础架构全量切片	20	身份、版本、候选规范化、HMAC 隔离、隐私准入、上下文快照
层级权重与确定性回放	排序模型 + 100 次 exact replay	20	晋升安全门、旧版本 decoder 兼容
模型快照发布与回滚	跨重启生命周期	18	快照发布/回滚/跨重启一致性
输入效率与评估语义	效率度量 + 评估闭环	20	B6/F1/F2、双重隐私扫描、installed=false 门禁

值得注意的是"确定性回放"这个验收点——100 次 exact replay 不是跑 100 次看概率，是要求每次输出完全一致。这在排序模型里是个不低的标准，通常的做法是"大概率对就行"。阿龙这次把确定性写进了合同，说明他对模型稳定性的要求在收紧。

LoopHarbor：从"能跑"到"能看"

LoopHarbor 今天启用了一个本地观察面板。这个功能听起来不起眼——不就是加个 UI 吗？但从 commit 语义看，它解决的是一个长期存在的可观测性问题：本地运行的 Loop 进程没有实时反馈界面，调试靠看日志。

观察面板的意义不在于"好看"，在于它把"运行中"和"可理解"之间的鸿沟填上了。之前要判断一个 Loop 是否健康，需要 tail -f 日志然后人工模式匹配。现在面板直接展示状态机、事件流和当前阶段。

同时 M13 只读流程控制台也在推进中（进行中），这个方向的逻辑很清晰：先能看（观察面板），再能控（控制台），最后能审计（只读流程）。

本地智能工作空间：Sidecar 首链路

这是一个新项目，今天完成了 M0 的两个里程碑：

M0-SIDECAR-001：建立 Sidecar 生命周期 fixture 与可执行启动入口（cake=18）
M0-DESKTOP-001：Desktop 管理真实 Sidecar 的最小纵向链路（cake=18）

"Sidecar"在我们的架构语境里指的是伴随主进程运行的辅助服务——比如做后台数据同步、监控上报、或者轻量级 AI 推理。M0 的目标很明确：先把"启动一个 Sidecar 并由 Desktop 管理它的完整生命周期"这条路跑通，不追求功能丰富度。

从 commit 结构看，两个 milestone 之间有明确的依赖：SIDECAR-001 定义了 fixture 和启动入口，DESKTOP-001 在此基础上接入了 Desktop 的管理能力。这种"先定义契约，再对接管理"的模式，在我们其他项目里也见过——本质上是在降低后续迭代的集成风险。

七项任务，一个共同特征

回顾今天完成的七项任务，它们有一个共同点：每项任务的 QA 验收标准都是在开发前就定义好的。

这不是事后补的测试用例。是在切片规划阶段就把"完成的定义"写进了任务卡——包括具体的命令、预期输出、以及边界条件。这解释了为什么七项任务全部一次性通过 QA，平均 cake 分 19.1。

对比上周的情况——有几项任务因为验收标准模糊导致 QA 打回重做——今天的效率提升不是因为任务变简单了，而是因为定义"完成"的成本被前置到了规划阶段。

进行中：三条线的下一步

目前还有三项任务在推进：

LoopHarbor M13 只读流程控制台：观察面板之后的下一步，从"看到"到"控制"
飞书输入框兼容：修复飞书输入框无法激活中文输入的问题——这是一个宿主兼容性问题，比看起来复杂
LoopHarbor M9 交付与运行治理：长期进行中的全阶段治理任务

飞书那个问题值得单独关注。输入法和宿主应用之间的兼容性，本质上是一个"两个状态机如何同步"的问题——输入法有自己的激活/休眠状态，飞书的输入框也有自己的焦点管理逻辑。当两者不同步时，就会出现"输入法认为自己已激活，但飞书认为没有"的竞态。阿龙今天已经有 commit 在处理这个问题，但考虑到飞书输入框的特殊性（它是一个 WebView 包裹的富文本编辑器），这个修复可能需要更多迭代。

今天不是什么突破性的一天，但它是"切片化交付"策略的一个验证点。当多条线并行推进时，能否保持每条线的交付质量，取决于规划阶段的颗粒度。今天的数据显示：可以。