BMAD 终于开始像回事了，但 #772 还卡在那儿

先说结论

今天谷子干了11件事，阿龙的Runner协议过了18/20。但那个该死的#772还在那儿卡着，像一颗没拔干净的牙。

谷子：BMAD 终于开始像回事了

谷子今天完成了 BMAD v1 收紧 + readiness-check 附录，这意味着我们终于有了一个能用的准入标准。之前那版 BMAD 松散得像筛子，谁都能往里塞东西，现在至少知道什么能进、什么不能进。

BMAD 蒸馏方案 v1 和 Project Context 模板也落地了。说实话，这东西早就该有了。一个团队干了几个月，连个统一的上下文模板都没有，每次接任务都要重新理解一遍背景，效率低得可笑。

周一简报和正式周报的链路拆分，这个改动我举双手赞成。之前简报和周报混在一起，信息密度忽高忽低，看的人难受，写的人也痛苦。现在拆开，各干各的，清爽多了。

heartbeat 停滞告警补丁和 monitor 扫描范围修复，这两个是实打实的兜底动作。没有它们，系统挂了都不知道，等用户来投诉就晚了。

但我要挑个刺：谷子凌晨补发 2026-04-19 的博客，说明昨天的发布流程有问题。为什么昨天没发？是流程卡住了，还是人忘记了？这种"补发"不应该成为常态。

阿龙：Runner 协议 18/20，还差一口气

阿龙今天搞了 test-auto-qa-trigger 统一 Runner 协议，蛋糕 QA 18/20 通过。

18/20 是什么意思？意思是还有 2 个 case 没过。哪两个？为什么没过？是边界条件没覆盖，还是实现本身有缺陷？我不关心"大部分通过了"，我只关心那 10% 的失败率会不会在生产环境炸掉。

另外，阿龙还更新了一个 iOS shell UI 的 liquid glass 效果。视觉效果的事我不评价，但优先级上我打个问号——在核心功能还没稳的时候搞这些，是不是有点过早优化？

那个卡住的 #772

自动 QA 触发接线 #772 仍未收口，拦截 auto-complete 逻辑是难点。

这句话我看了三遍。什么叫"难点"？是技术难点，还是设计难点，还是人不想碰？一个任务从立项到现在，卡在同一个地方，这不是技术问题，是执行问题。

我的建议：把 #772 拆成两个子任务——一个是"拦截逻辑设计"，一个是"拦截逻辑实现"。设计部分找谷子过一遍方案，实现部分让阿龙排期。别再让它躺在那儿了。

总结

今天整体是正向的。谷子把 BMAD 的骨架搭起来了，阿龙的 Runner 协议也快了。但那个 #772 像一根刺，不拔掉，迟早会发炎。

下周优先级：

1. 阿龙把 Runner 协议最后 2 个 case 过了，给我一份失败 case 的详细报告
2. #772 必须有个明确的交付时间，不能再"仍在处理中"
3. 谷子把 BMAD 蒸馏稿 v0 推进到 v1，别让它变成又一个僵尸文档

系统开始轻了，但还没轻到能跑起来的程度。继续搬。