ecc-tools-cost-audit

ECC Tools 成本审计

当用户怀疑ECC Tools GitHub App正在消耗成本、过度创建PR、绕过使用限制或将免费用户路由到高级分析路径时，使用此技能。

这是一个针对同级ECC-Tools仓库的专注操作员工作流。它不是通用的计费技能，也不是仓库范围的代码审查。

技能栈

在相关时，将以下ECC原生技能引入工作流：

• autonomous-loops 用于跨webhook、队列、计费和重试的有界多步骤审计
• agentic-engineering 用于将请求路径追踪为离散、可证明的单元
• customer-billing-ops 当需要清晰分离仓库行为和客户影响计算时
• search-first 在发明辅助工具或重新实现仓库本地工具之前
• security-review 当涉及认证、使用门控、权限或密钥时
• verification-loop 用于证明重试安全性和精确的修复后状态
• tdd-workflow 当修复需要在worker、路由器或计费路径中添加回归覆盖时

何时使用

• 用户提到ECC Tools消耗率、PR递归、过度创建的PR、使用限制绕过或高级模型泄露
• 任务在同级ECC-Tools仓库中，且依赖于webhook处理器、队列worker、使用预留、PR创建逻辑或付费门控执行
• 客户报告称应用创建了太多PR、计费错误或分析了代码但未产生可用结果

范围护栏

• 在同级ECC-Tools仓库中工作，而不是在everything-claude-code中
• 除非用户明确要求修复，否则以只读方式开始
• 在追踪分析消耗时，不要修改无关的计费、结账或UI流程
• 将应用生成的分支和应用生成的PR视为红旗递归路径，直到被证明无害
• 明确分离三件事：
  • 仓库侧消耗根本原因
  • 面向客户的计费影响
  • 需要待办事项跟进的产品或权限缺口

工作流

1. 冻结仓库范围

• 切换到同级ECC-Tools仓库
• 首先检查分支和本地差异
• 确定审计的具体表面：
  • webhook路由器
  • 队列生产者
  • 队列消费者
  • PR创建路径
  • 使用预留/计费路径
  • 模型路由路径

2. 在理论化之前追踪入口

• 首先检查src/index.*或主入口点
• 在建议修复之前，映射每个入队路径
• 确认哪些GitHub事件共享一个队列类型
• 确认push、pull_request、synchronize、comment或手动重新运行事件是否可能汇聚到同一个昂贵路径

3. 追踪worker和副作用

• 检查处理分析的队列消费者或定时worker
• 确认排队的分析是否总是以以下方式结束：
  • PR创建
  • 分支创建
  • 文件更新
  • 高级模型调用
  • 使用量增加
• 如果分析可能消耗令牌但在输出持久化之前失败，则将其归类为“消耗但输出中断”

4. 审计高信号消耗路径

PR倍增

• 检查PR辅助函数和分支命名
• 检查去重、synchronize事件处理和现有PR重用
• 如果应用生成的分支可能重新进入分析，则将其视为优先级0的递归风险

配额绕过

• 检查配额检查的位置与使用预留或增加的位置
• 如果在入队前检查配额但仅在worker内部计费使用，则将并发前端通过视为真正的竞态条件

高级模型泄露

• 检查模型选择、层级分支和提供商路由
• 验证免费或受限用户是否仍能在存在高级密钥时命中高级分析器

重试消耗

• 检查重试循环、重复队列任务和确定性失败重新运行
• 如果相同的非临时错误可能反复消耗分析，则在质量改进之前修复此问题

5. 按消耗顺序修复

如果用户要求代码更改，按此顺序优先修复：

1. 停止自动PR倍增
2. 停止配额绕过
3. 停止高级泄露
4. 停止重复任务扇出和无意义重试
5. 关闭重新运行/更新安全缺口

除非同一根本原因明确跨越多个文件，否则将修复范围限制在一到三个直接修复。

6. 以最小的证明步骤验证

• 仅重新运行覆盖更改路径的目标测试或集成片段
• 验证消耗路径现在是否：
  • 被阻止
  • 被去重
  • 降级为更便宜的分析
  • 或提前被拒绝
• 精确陈述最终状态：
  • 本地更改
  • 本地验证
  • 已推送
  • 已部署
  • 仍被阻止

高信号故障模式

1. 所有触发器使用同一队列类型

如果推送、PR同步和手动审计都入队相同的任务，且worker总是创建PR，则分析等于PR垃圾邮件。

2. 入队后使用预留

如果在入口检查使用量但仅在worker中增加，则并发请求可能全部通过门控并超出配额。

3. 免费层级走高级路径

如果免费排队的任务在存在密钥时仍可路由到Anthropic或其他高级提供商，则即使从未看到高级结果，也存在实际支出泄露。

4. 应用生成的分支重新进入webhook

如果pull_request.synchronize、分支推送或评论触发的运行在应用拥有的分支上触发，则应用可以递归分析自己的输出。

5. 持久化安全之前的昂贵工作

如果系统可能消耗令牌然后在PR创建、文件更新或分支冲突时失败，则是在消耗成本而不产生价值。

陷阱

• 不要以广泛的仓库漫游开始；先确定webhook -> 队列 -> worker
• 不要将客户计费推断与代码支持的产品事实混合
• 在最高消耗路径被控制之前，不要修复低价值的质量问题
• 在重新运行狭窄的证明步骤之前，不要声称消耗已修复
• 除非用户要求，否则不要推送或部署
• 如果无关的仓库本地更改正在进行中，不要触碰它们

验证

• 根本原因引用确切的文件路径和代码区域
• 修复按消耗影响排序，而非代码整洁度
• 证明命令已命名
• 最终状态区分本地更改、验证、推送和部署