weekly-2026-03-29

3 commits, auth system rewritten twice, scheduler finally learns self-cleanup.

本周进展 / This Week's Progress

GitHub Auth：重写即承认

本周最大的工程事件是 packages/github/src/auth.ts 的 411 行重写。

这不是 refactor。这是承认。

原来的 auth 实现有什么问题？日志显示 token 过期后仍然被重用，导致所有 API 调用瞬间变成 401。系统运行了多久才暴露这个问题？根据 commit 历史，至少在 #128 之前的某个版本就已经潜伏了。auto-discovery 每次失败都报 "Bad credentials"，但没人怀疑是 token lifecycle 的问题——因为问题出在"过期了还在用"，而不是"从来没拿到"。

重写 auth 的策略是什么？用 auth.callback 替代直接 token 注入。这意味着每次请求都会经过一个回调层，检查 token 有效性再决定是否重新认证。这是一个正确的方向，但代价是引入了额外的 async overhead。GitHub API 调用从同步变成了异步链，性能影响还需要实际压测。

顺便说一句，这不是第一次 auth 被重写。git log 里有 "hotfix(unknown): fix(github-auth): use async auth callback" 的记录，说明某次 hotfix 已经改过一次。两次重写之间隔了多久？如果隔得太近，说明第一次修复没有解决根本问题，只是治标。

反思：这套系统的 auth 依赖从来不稳定，每次出问题都是"临时修一个点"而不是审视整个链路。"Bad credentials" 报错出现的时候，第一反应应该是检查 token 生命周期管理，而不是怀疑 API key 本身。

Scheduler 的自我觉悟

本周 scheduler 学会了清理自己。

commit fix(scheduler): cleanup remote branches of recently merged PRs 做了两件事：本地合并后自动清理 origin 分支 + 维护一个近期合并分支列表以避免重复清理。另一个 commit fix(governance): prevent VE empty-commit CI-trigger loop 则用 pre-push hook 阻止空提交触发 CI。

这两件事的共同点是：它们解决了自己挖的坑。

scheduler 之前为什么需要 cleanup？因为它频繁创建和合并临时分支，分支命名混乱，清理逻辑要么缺失要么位置不对。VE loop 之前为什么发生？因为 review gates 的逻辑绕过了 CI 的检查机制，空提交被视为有效变更。这两个问题都不是新功能，它们是已有功能实现不完整的副产品。

真正的进步不是"scheduler 学会了 cleanup"，而是"终于有人注意到 cleanup 的缺失"。但这种迟来的注意力的代价是什么？分支混乱期间有多少 CI 资源浪费在幽灵分支上？VE loop 期间有多少构建因为空提交被错误触发？

反思：系统正在以"先跑通再修补"的方式演进。每次补丁都在填补上一个未完成的设计决策留下的空白。这不是技术债务，这是技术债务的利滚利。

DCD Crawler：监控的代价

feat(dcd-crawler): daily param coverage monitoring with threshold alerts 引入了参数覆盖率监控和阈值告警。

这个 feature 的动机很清晰：如果爬虫的参数覆盖率低于某个阈值，系统应该能自动告警。但问题在于，这个监控本身需要额外的数据存储和定时任务。监控的覆盖率和爬虫的实际采集质量之间有没有 correlation？阈值怎么定？如果告警每天触发一次，但爬虫的问题可能在任何时候发生，这个"daily monitoring"的窗口是不是太大了？

监控本身不是问题，问题是监控引入了新的依赖和新的潜在故障点。

批评视角 / Critical Lens

1. 修复速度掩盖了设计深度不足

本周修复了 3 个主要问题：auth 重写、scheduler cleanup、VE loop 阻止。这三个修复都很快——从发现到合并可能不超过几个小时。快速修复是好的，但快到没有设计文档、没有回滚测试、没有 post-mortem，就有问题了。

auth 重写之后有没有测试覆盖？新的 callback 路径有没有被正确 mock？scheduler cleanup 在并发场景下会不会有竞态？如果这些答案都是"还不知道"，那么下一次 auth 失效或 scheduler 死锁可能就在明天。

2. 配置膨胀正在侵蚀系统边界

staged changes 显示 58 个文件，3882 行新增。docs/ops/ 新增了 QDRANT_DATA_CONTRACT.md 和 RUNNER_TOPOLOGY.md，每个都是长文档。这些文档是真的有必要，还是系统本身太复杂以至于没有人能记得住所有细节，所以需要写文档来代替理解？

系统越复杂，文档越膨胀；文档越膨胀，维护成本越高；维护成本越高，错误越多。这条链路的终点是什么？

3. 技术选择缺乏长期视角

auth callback 解决了 token 重用问题，但它引入了每次请求的 async 回调开销。如果未来 GitHub API 调用量翻倍，这个 overhead 也会线性增长。scheduler cleanup 用了内存列表存储近期合并分支，如果 scheduler 重启，这个列表就丢失了。这些都是"够用就行"的技术选择，不是"3年后还能扩展"的设计。

本周数据 / This Week by Numbers

指标	数值
提交数	3
新增行	~3900
文件改动	58
主要领域	auth, scheduler, crawler
重写次数(auth)	2次(本周)

下周关注 / Looking Ahead

auth callback 的性能压测结果
scheduler cleanup 在分支删除失败时的恢复逻辑
DCD crawler 监控告警的实际触发情况
是否有新功能还是在继续填坑

本周的教训：快速修复不等于好设计。重写 auth 之前应该先画出 token lifecycle diagram，而不是直接改代码。