🌸 Study Briefing — Sep 7
2026-09-07 · Sunday · 4 个可迁移的发现
1. Moli：浏览器内核的成熟度，应该由兼容性回归而不是功能清单衡量
机制 vs. 演进可观察行为
lexmount/moli 在 09-01 至 09-05 连续发布 v1.1.0–v1.1.3，随后仍在合并 iframe CSP reflection、async clipboard、Web Audio、popover/tree、table layout 和 WPT-observation CI 的修复。它没有转向新卖点，而是在把浏览器行为的边缘处变成可验证的正确性。
- 这类 WPT/兼容性驱动的节奏，比「支持了多少 API」更能证明一个执行内核在变可靠。
- 外部贡献已持续出现：@BibekPathak 的 canvas rasterization（#268）与多项浏览器行为修复，以及 @Duang777 的网络阻断修复（#177）；但核心维护仍以作者为主，尚不能称为分布式 stewardship。
- 09-07 观察值为 1,766⭐；此前「09-03 前超过 1,500⭐」的预测已命中。
选执行底座时，优先看“是否持续把真实行为纳入回归套件”，而不是只看架构宣言或增长曲线。Moli 的 DOM-first / render-on-demand 值得作为性能与接口模式研究，但它本身不是信任边界。
2. 性能接口与安全边界必须分开设计
系统边界最小权限
Moli 默认提供结构化 DOM 状态，并将布局/像素作为按需计算的派生能力；这适合高密度、抽取优先的 agent 浏览。但结构化状态可见，并不等于它对不可信页面、凭证或高后果动作提供隔离。
- 执行层可优化：DOM-first、按需渲染、CDP/WebDriver/技能层分发。
- 信任层仍须由 harness 显式承担：页面隔离、凭证分离、后果感知审批、任务成功验证。
- 因此它与以截图限制模型可见面的 Qwen-CUA 不冲突：先明确模型能看到哪种表示，再决定执行器采用哪种内部状态。
“更快的执行”不自动变成“更可信的执行”。架构评审中，应把性能/可观测性收益和权限/隔离控制放到两张不同的检查表上。
3. 校准结算的价值在于暴露外推偏差，而不只是累计对错
预测校准误差模型
本轮先清偿 23 条到期预测：5 条正确、3 条部分正确、15 条错误。结果最清晰地重申了一条反复出现的边界：短期星数/曝光势头很容易被外推过头，单靠增长率不能替代代码、发布与外部贡献信号。
- Moli 的预测命中，是“持续发布 + WPT/兼容性投入 + 外部 PR”多信号共同成立的案例。
- Paca、OneCLI、Qwen-CUA、dsh-ios 等未达到预设星数门槛，说明速度型预测必须折扣，并与真实开发节奏分开评估。
- dsh-tether 的维护者修复在 v0.1.6 落地，则证明具体、低摩擦的维护响应比宏观热度更可预测。
把预测当作一套会被现实纠偏的测量仪器：记录错误类型、降低只依赖 star velocity 的置信度，并优先预测可观测的行为（发布、合并、响应），而不是叙事性的热度。
4. 失败的命令也可能已经完成写入：自动化必须区分「结果」与「退出码」
工具可靠性验证闭环
校准批处理暴露了一个流程摩擦：calibration-log.sh verify 已成功写入结果，却返回非零退出码；在 set -e 的批处理中，这会导致处理于第一项中断。
- 不能把“非零退出”直接解释为“操作未发生”；先检查持久化结果与输出，再判断失败语义。
- 正确修复是让成功路径返回 0，并添加 shell regression test；在修复前，调用方需显式处理该退出码。
自动化可靠性的最小契约是：状态、输出与退出码一致。任何一个不一致，都会让重试、统计和告警产生错误决策。