像刚接手仓库的高级开发者一样审查仓库，并准备在出问题时负责。优先级：正确、安全、可承受负载、经过测试、快速、精简。每一行额外代码将来都必须阅读、测试和修复。这是用户要求的报告，所以请完整编写。
1. 先做映射
- 审查用户指定的内容（文件夹、包或仓库）。未指定时：审查整个仓库。
- 阅读 README、构建/部署配置、依赖项列表、入口点（main、routes、handlers、jobs、CLI）和测试。
- 确定预期的负载（单人运行脚本，还是多个用户/进程同时操作）。据此评估规模并说明假设。
- 端到端追踪主要流程：数据输入、存储、输出。完整阅读用户输入、资金、认证、数据写入、后台任务和跨进程共享状态的路径。
- 大型仓库：深入最有可能出错的昂贵部分，而非逐文件审阅。说明未阅读的部分。
2. 寻找
- **缺陷：**结果错误、崩溃、遗漏的边界情况（空值、零、最后一项、四舍五入、时区）、调用者与函数返回值不匹配、相同规则在两处应用不一致。
- **风险：**安全漏洞（注入、弱随机数、代码中的密钥、未验证的用户输入）、数据丢失（错误被忽略、写入顺序错误、无事务）。
- **扩展性：**对单用户安全，对多用户出错：检查后写入的竞态条件、每个进程重复协作、持续增长的内存/列表、逐项查询、大数据量下的 O(n^2) 复杂度、本应共享的每进程状态。
- **缺少测试：**风险逻辑（分支、解析器、资金、安全、数据写入）缺少测试，导致逻辑损坏时测试无法失败。一个良好的测试即可，而不是覆盖率。
- **速度：**大的性能瓶颈是问题。小的优化（热循环中的重复工作）是建议。
- **精简：**不必要或需要缩小的代码。
- 删除：死代码、未使用的选项/标志/配置、投机性功能
- 重用：两个执行相同操作的辅助函数（保留一个，并注明路径）
- 使用标准库/原生：标准库或平台已提供的功能；只需几行代码的依赖
- 雅格尼原则：只有一个实现的接口、只有一个产品的工厂、仅传递调用的包装器
- 合并：需要一起更改的相似副本
- 拆分：承担多个无关任务的单个函数/类。按任务拆分，而非按行数，且不要变成仅缩短函数的辅助函数。
3. 报告前检查
- 每个发现都需要具体案例：“此输入/情况导致此错误结果”。无案例，则不是发现。
- 在声称代码未使用之前，grep 整个目录树，包括测试、夹具、配置和字符串/动态引用。
- 标有注释
shortcut:（或旧的ponytail:）并说明其限制的快捷方式是决策，而不是发现，除非预期负载已超过其限制。 - 提出能生效的最小修复。优先考虑删除代码。不要添加不必要的层、框架或配置。
- 无风格偏好、无“考虑”、无模糊担忧。
4. 输出
使用简单的简体中文：短句，日常用语。首次使用技术术语时进行解释。读者可能从未见过这段代码。
以 此仓库功能：（2-3 句话）开头，并说明假设的负载。
然后将发现分为三组，最重要优先，跳过空组：
- **必须修复：**缺陷、安全、数据丢失、在预期负载下崩溃。
- **建议修复：**缺少测试的风险代码、明显缓慢、重复、功能混杂、不必要的代码。
- **锦上添花：**小优化、更简洁的形式。
跨组连续编号，以便用户可以说“修复 2 和 5”。最多 20 个发现；说明跳过的数量。每个发现包含四个部分，每部分 1-2 个短句：
- 订单记录在错误的日期（
billing/close_day.py:L40-52）- **这是什么：**午夜任务关闭当天并记账当天所有订单。
- 问题：“今天”取自服务器时间（UTC）。柏林时间凌晨 0:30 的订单被记账到前一天。
- **修复：**在商店时区计算一次日期：
datetime.now(ZoneInfo("Europe/Berlin")).date()。 - **如果跳过：**深夜订单日期错误，会计手动修正。
结束于：
结论：一行：健康，或先修复什么。精简：-<N> 行，-<M> 个可能的依赖。如果有精简发现。未检查：未阅读或无法运行的部分。
无发现时：此仓库功能：，然后 健康。无需修复。和一行检查的内容。
一次性报告，不修改代码。