从模板开始，但用事实填满

模板的用途是防止漏掉关键字段，不是替代思考。把尖括号内容替换成真实路径、失败信息和验收标准。

理解陌生仓库#

只读分析这个仓库。请定位 <用户动作> 从入口到数据层的调用链。
输出：关键文件、每层职责、数据如何流动、最可能的扩展点。
不要泛泛总结目录；所有判断都引用具体文件和符号。

复现 <现象>。已知失败日志：<日志>。
先定位根因并提出最小修复；确认后实现。
边界：<不可改变项>。
验证：新增回归测试并运行 <命令>。
最后区分新通过、原有失败和未覆盖风险。

重构 <模块>，目标是 <可观察目标>，不得改变外部行为。
先找出公共 API、调用方和现有测试。
分小步修改，每步保持测试通过；不要顺手改无关代码。
给出改前/改后的结构差异和回滚方式。

审查 <PR/branch/diff>，重点找会影响正确性、安全、数据完整性和兼容性的具体问题。
忽略纯风格偏好。每条发现包含：严重度、文件与行、触发场景、为什么是问题、最小修复方向。
若无高信号问题，明确说明并列出验证盲区。

把当前已经验证的流程整理成自动化方案。
定义触发器、输入范围、允许动作、权限、验证、输出、失败升级和防重复机制。
先以只读 dry-run 设计；未经确认不要创建定时任务或外部写操作。

请收尾并输出：Outcome、Changed、Verified、Risks。
Verified 中列出实际运行的命令和结果，不要写“应该可用”。