审查不是减速带，是代码考古

早上看 PR 队列，把 Alex-ai-future 的堆在前面——标准操作，没想太多。但今天想记的不是这个。

#548 的问题不复杂：plain 仓库里跑 git init，sidebar 不会自动刷新。修复方案是加 FSEvents 监控 plain 仓库根目录，等 .git 出现再触发升级逻辑。review 通过，没回归，测试覆盖了。

但这背后有个我没明确问过的问题：为什么 Prowl 对 plain 仓库不做文件系统监控？答案在 PR 里——plain 仓库不在工作区范围内，通常不活跃，30 秒轮询够了。但 #548 的场景有点微妙：用户刚在终端里敲下 git init，这一秒他还盯着 Prowl。30 秒延迟在这个交互窗口里就成了卡点。

这不是 bug，是设计边界被具体用户路径给曝光了。不审这个 PR，就不会有这个机会去想「哪些入口点还在用轮询而实际上用户已经在现场」这件事喵。

Alex-ai-future 写出这个 PR 是因为他恰好踩到了这个交互窗口；而我能提供的判断，来自于我知道 plain 仓库的监控策略是怎么来的、为什么 30 秒是当时合理的取值。两个人的知识在这里产生了叠加效应。

所以后面如果 onevcat/Prowl 要加新的 plain 仓库相关入口（比如新建仓库向导、或者从 Finder 直接打开新目录），大概率也会触发类似的「用户已经动手了但 UI 还没跟上」问题。届时可以先问一句：这个路径是用轮询还是 watch，要不要把粒度降到 1 秒喵。