auditing-rails-tech-debt

Rails 技术债审计

仅报告；除非用户要求，否则不要编辑代码。简短地报告已确认的问题，胜过冗长地罗列可能存在的问题。

每项发现

1. 引用代码。 对于你读过的代码，标注 file:line。切勿报告未读过的代码异味。
2. 引用具名来源。 至少链接一个来自引用资源的来源，或一个 PoEAA 模式页面，并优先选择最具体的来源。如果无法指出被违反的原则及其来源，那就只是个人观点：删除。
3. 展示修改前和修改后，并使用本代码库中的名称和风格。
4. 采用最简单的修改后方案：模型方法、模块函数或查询作用域。只有当新类需要持有状态或协调多个模型时，才引入新类。调用 Skill 工具 simplifying-ruby-code 并引用其模式编号；如果该工具不可用，则按此规则执行。 如果没有 Skill 工具，请遵循技能调用规则。
5. 独立验证。 由发现问题的 Agent 之外的另一个 Agent，根据代码确认每个候选问题（是否实际调用、concern 或其他结构是否已缓解问题、schema 或测试是否能证明该设计合理）。删除任何未经确认的问题。

参考文件

阅读你所调查的问题类别或引用的模式对应的参考资料： PoEAA 领域逻辑、 数据源、 对象关系映射、 Web 呈现、 分发、并发与会话， 以及基础模式； Rails 反模式（滥用回调、 N+1、default_scope、作用域中的 SQL 插值）；以及 SOLID 与惯用 Ruby。

调查线索

• 运行 node <skill-dir>/scripts/find-leads.mjs <app>。如果退出码为 1 或 2， 请修复 stderr 指出的内容并重新运行。如果退出码为 3，请阅读 db/structure.sql 并应用 schema 规则。
• 从 Gemfile、config/routes.rb、db/schema.rb 和 sizes 中最大的文件入手；缺少某个层，与该层臃肿一样具有诊断价值。
• 调查线索只是阅读代码的起点，并非发现：请根据对应的发现规则逐项确认，并通过阅读模型或迁移来处理每个 schema.unresolved 条目。

严重程度

• CRITICAL： 导致数据损坏、引入安全漏洞或阻碍正确性（作用域中的 SQL 注入、资金路径缺少锁、具有跨记录副作用的回调）。
• HIGH： 增加该领域每项变更的成本（上帝模型、控制器中的业务逻辑、高频路径中的 N+1）。
• MEDIUM： 局部技术债（缺少值对象、重复的作用域、视图中的逻辑）。
• LOW： 风格或惯用写法偏差。

报告

• 每项发现默认采用以下结构，并可根据需要调整：### [SEVERITY] <title> 标题，然后依次列出 Where（file:line 范围）、Smell、Violates（带链接的具名原则）、Evidence（引用代码）、Before 和 After、Why a class（仅当 After 新增类时），以及 Effort（S、M 或 L，可渐进实施或一次完成）。
• 按严重程度排列发现，并以汇总表收尾。
• 按优先处理成本最低、严重程度最高的问题的顺序安排修复；能为其他重构铺路的重构应优先进行（例如，在查询对象之前先提取服务层）。