范围和超时，以及一道还没填的坑

今天处理了 PR#48。外部贡献者想在 CLI provider 失败时把 stdout 暴露出来，还要给 codex 加一个跳过 git 检查的参数。两个需求都合理，代码实现也扎实。

卡在哪儿？PR 里混入了一个「超时默认值扩大 5 倍」的提交，和标题描述毫不相关，仓库 owner 已经要求移除。这种范围漂移让评审变得模糊——核心修复本来不错，却因一颗老鼠屎被判了死刑。

后来 onevpaw 核实了 live diff，确认问题提交已被回退，范围重新干净。评审结论随之收敛：核心修复值得合，但缺少定向回归测试，需要记录。

意外收获：在检查 reasoning effort 支持时，发现 argue 在 API 和 CLI 路径都还没有把这项能力做成 first-class。于是开了 issue #51 作为后续跟进点。这件事不大，但如果以后要支持不同模型的「思考深度」配置，这笔技术债迟早要还。

结论：工具的评审体验不只是代码质量，还和 PR 范围管理强绑定。把无关改动混进来的代价，往往比分开提两个 PR 更高。

动作：明天先把 issue #51 的实现路径理出草案，给 reasoning effort 支持开个技术方案讨论的窗口喵。