ECC Tools Cost Audit 是一套面向 ECC Tools GitHub App 的成本燃烧与账单审计工作流，适用于怀疑该应用正在消耗成本、过度创建 PR、绕过用量限制，或将免费用户路由到高级分析路径的场景。它聚焦于同源的 ECC-Tools 仓库，属于运维操作流程，不是通用账单技能，也不是全仓库代码审查。
用途
当用户提到 ECC Tools 燃烧率、PR 递归、过度创建 PR、用量限制绕过或高级模型泄漏时使用。当任务位于同源 ECC-Tools 仓库，并依赖 webhook 处理器、队列 worker、用量预留、PR 创建逻辑或付费门禁执行时使用。当客户报告应用创建了过多 PR、计费不正确，或分析了代码却没有产出可用结果时使用。
技能栈
在相关时可将以下 ECC 原生技能纳入工作流：autonomous-loops 用于跨 webhook、队列、计费和重试的有界多步审计；agentic-engineering 用于将请求路径追踪为离散、可证明的单元；customer-billing-ops 用于清晰分离仓库行为与客户影响计算；search-first 用于在发明辅助工具或重新实现仓库本地工具之前先搜索；security-review 用于涉及认证、用量门禁、权益或密钥时；verification-loop 用于证明重跑安全性与修复后的确切状态；tdd-workflow 用于修复需要在 worker、router 或计费路径中增加回归覆盖时。
范围护栏
在同源 ECC-Tools 仓库中工作，而非 ECC。除非用户明确要求修复，否则以只读方式开始。在追踪分析燃烧时，不要改动无关的计费、结账或 UI 流程。将应用生成的分支和应用生成的 PR 视为红旗递归路径，直到被证明并非如此。明确区分三件事：仓库侧燃烧根因、面向客户的计费影响、需要进入待办跟进的产品或权益缺口。
工作流
-
冻结仓库范围：切换到同源 ECC-Tools 仓库，先检查分支和本地差异，确定审计的确切表面：webhook 路由器、队列生产者、队列消费者、PR 创建路径、用量预留/计费路径、模型路由路径。
-
在理论化之前追踪入口：先检查 src/index.* 或主入口点，在建议修复之前映射每一条入队路径，确认哪些 GitHub 事件共享同一队列类型，确认 push、pull_request、synchronize、comment 或手动重跑事件是否会汇聚到同一条昂贵路径。
-
追踪 worker 与副作用：检查处理分析的队列消费者或定时 worker，确认排队的分析是否总是以 PR 创建、分支创建、文件更新、高级模型调用、用量递增结束。如果分析可以消耗 token 但在输出持久化之前失败，则归类为 burn-with-broken-output。
-
审计高信号燃烧路径：PR 倍增方面，检查 PR 辅助函数与分支命名，检查去重、synchronize 事件处理和现有 PR 复用；如果应用生成的分支可以重新进入分析，将其视为优先级 0 的递归风险。配额绕过方面，检查配额检查位置与用量预留或递增位置；如果配额在入队前检查，但用量只在 worker 内计费，则将并发前门通过视为真实竞态。高级模型泄漏方面，检查模型选择、层级分支和提供商路由，验证免费或受限用户在存在高级密钥时是否仍能命中高级分析器。重试燃烧方面，检查重试循环、重复队列任务和确定性失败重跑；如果同一个非瞬态错误可以反复消耗分析，先修复它再改进质量。
-
按燃烧顺序修复：如果用户要求代码更改，按以下顺序优先修复：停止自动 PR 倍增、停止配额绕过、停止高级模型泄漏、停止重复任务扇出和无意义重试、关闭重跑/更新安全缺口。除非同一根因明显跨多个文件，否则将本次处理限制在一到三个直接修复。
-
用最小证明步骤验证：只重跑覆盖已更改路径的目标测试或集成切片，验证燃烧路径现在是否被阻止、去重、降级为更便宜的分析或提前拒绝。准确说明最终状态：本地已更改、本地已验证、已推送、已部署、仍被阻止。
高信号失败模式
-
所有触发器共用一个队列类型：如果 push、PR 同步和手动审计都入队同一任务，且 worker 总是创建 PR，那么分析就等于 PR 垃圾。
-
入队后用量预留：如果用量在前门检查，但只在 worker 中递增，并发请求可能全部通过门禁并超出配额。
-
免费层级走高级路径：如果免费排队任务在密钥存在时仍可路由到 Anthropic 或其他高级提供商，即使免费用户从未看到高级结果，这也是真实的支出泄漏。
-
应用生成的分支重新进入 webhook：如果 pull_request.synchronize、分支推送或评论触发的运行在应用自有分支上触发，应用可能递归分析自己的输出。
-
持久化安全之前进行昂贵工作：如果系统可以消耗 token，然后在 PR 创建、文件更新或分支冲突时失败，那就是在燃烧成本却没有交付价值。
陷阱
不要一开始就大范围游走仓库；先确定 webhook -> 队列 -> worker。不要将客户计费推断与代码支持的产品事实混为一谈。不要在最高燃烧路径被控制之前修复低价值质量问题。在重跑窄范围证明步骤之前，不要声称燃烧已修复。除非用户要求，否则不要推送或部署。如果无关的仓库本地更改已在进行中，不要触碰它们。
验证
根因需引用确切文件路径和代码区域。修复按燃烧影响排序，而非代码整洁度。证明命令需被命名。最终状态需区分本地更改、验证、推送和部署。