ecc-tools-cost-audit

ECC Tools Kostenprüfung

Verwenden Sie diesen Skill, wenn der Benutzer vermutet, dass die ECC Tools GitHub App Kosten verursacht, übermäßig PRs erstellt, Nutzungslimits umgeht oder kostenlose Benutzer in Premium-Analysepfade leitet.

Dies ist ein fokussierter Operator-Workflow für das Schwester-Repository ECC-Tools. Es handelt sich nicht um einen allgemeinen Abrechnungs-Skill oder eine Repositorien-weite Code-Review-Runde.

Skill-Stack

Ziehen Sie diese ECC-nativen Skills bei Bedarf in den Workflow ein:

• autonomous-loops für begrenzte mehrschrittige Audits, die Webhooks, Warteschlangen, Abrechnung und Wiederholungen umfassen
• agentic-engineering zur Rückverfolgung des Anforderungspfades in diskrete, beweisbare Einheiten
• customer-billing-ops wenn Repositorienverhalten und Kundenauswirkungsmathematik sauber getrennt werden müssen
• search-first bevor Sie Helfer erfinden oder repositorienlokale Dienstprogramme neu implementieren
• security-review wenn Authentifizierung, Nutzungsgrenzen, Berechtigungen oder Geheimnisse betroffen sind
• verification-loop zum Nachweis der erneuten Ausführungssicherheit und des exakten Zustands nach der Fehlerbehebung
• tdd-workflow wenn die Fehlerbehebung eine Regressionsabdeckung im Worker, Router oder in den Abrechnungspfaden benötigt

Wann verwenden

• Der Benutzer erwähnt ECC Tools Brennrate, PR-Rekursion, übermäßig erstellte PRs, Nutzungslimit-Umgehung oder Premium-Modell-Leckage
• Die Aufgabe befindet sich im Schwester-Repository ECC-Tools und hängt von Webhook-Handlern, Queue-Workern, Nutzungsreservierung, PR-Erstellungslogik oder der Durchsetzung von Bezahlschranken ab
• Ein Kundenbericht besagt, dass die App zu viele PRs erstellt, falsch abgerechnet oder Code ohne nutzbares Ergebnis analysiert hat

Bereichsbegrenzungen

• Arbeiten Sie im Schwester-Repository ECC-Tools, nicht in everything-claude-code
• Beginnen Sie im Nur-Lese-Modus, es sei denn, der Benutzer hat explizit nach einer Fehlerbehebung gefragt
• Mutieren Sie keine nicht verwandten Abrechnungs-, Checkout- oder UI-Abläufe, während Sie die Analyse-Burn-Rate verfolgen
• Behandeln Sie app-generierte Branches und app-generierte PRs als rote-Flagge-Rekursionspfade, bis das Gegenteil bewiesen ist
• Trennen Sie drei Dinge explizit:
  • Repositorien-seitige Burn-Ursache
  • Kundenorientierte Abrechnungsauswirkung
  • Produkt- oder Berechtigungslücken, die ein Backlog-Follow-up erfordern

Workflow

1. Repositorienbereich einfrieren

• Wechseln Sie in das Schwester-Repository ECC-Tools
• Überprüfen Sie zuerst Branch und lokalen Diff
• Identifizieren Sie die genaue Oberfläche unter Prüfung:
  • Webhook-Router
  • Queue-Producer
  • Queue-Consumer
  • PR-Erstellungspfad
  • Nutzungsreservierungs-/Abrechnungspfad
  • Modell-Routing-Pfad

2. Ingress zurückverfolgen, bevor Sie theorisieren

• Überprüfen Sie zuerst src/index.* oder den Haupteinstiegspunkt
• Kartieren Sie jeden Enqueue-Pfad, bevor Sie eine Fehlerbehebung vorschlagen
• Bestätigen Sie, welche GitHub-Ereignisse einen Warteschlangentyp teilen
• Bestätigen Sie, ob Push-, pull_request-, synchronize-, comment- oder manuelle erneute Ausführungsereignisse auf demselben teuren Pfad zusammenlaufen können

3. Worker und Seiteneffekte zurückverfolgen

• Überprüfen Sie den Queue-Consumer oder geplanten Worker, der die Analyse durchführt
• Bestätigen Sie, ob eine in die Warteschlange gestellte Analyse immer endet in:
  • PR-Erstellung
  • Branch-Erstellung
  • Dateiaktualisierungen
  • Premium-Modell-Aufrufen
  • Nutzungsinkrementen
• Wenn die Analyse Token verbrauchen und dann fehlschlagen kann, bevor die Ausgabe persistiert wird, klassifizieren Sie sie als Burn-mit-unterbrochener-Ausgabe

4. Die High-Signal-Burn-Pfade prüfen

PR-Multiplikation

• Überprüfen Sie PR-Helfer und Branch-Benennung
• Überprüfen Sie Deduplizierung, synchronize-Ereignisbehandlung und Wiederverwendung vorhandener PRs
• Wenn app-generierte Branches erneut in die Analyse eintreten können, behandeln Sie dies als Rechenschaftsrisiko der Priorität 0

Quota-Umgehung

• Überprüfen Sie, wo die Quote geprüft wird im Vergleich zu wo die Nutzung reserviert oder erhöht wird
• Wenn die Quote vor dem Enqueue geprüft wird, die Nutzung aber nur innerhalb des Workers berechnet wird, behandeln Sie gleichzeitige Frontdoor-Pässe als echten Wettlauf

Premium-Modell-Leckage

• Überprüfen Sie die Modellauswahl, das Tier-Branching und das Provider-Routing
• Verifizieren Sie, ob kostenlose oder gedeckelte Benutzer weiterhin Premium-Analysegeräte erreichen können, wenn Premium-Schlüssel vorhanden sind

Retry-Burn

• Überprüfen Sie Wiederholungsschleifen, doppelte Warteschlangenjobs und deterministische Fehlerwiederholungen
• Wenn derselbe nicht-vorübergehende Fehler die Analyse wiederholt durchführen kann, beheben Sie dies vor Qualitätsverbesserungen

5. Fehlerbehebung in Burn-Reihenfolge

Wenn der Benutzer Codeänderungen angefordert hat, priorisieren Sie Behebungen in dieser Reihenfolge:

1. Automatische PR-Multiplikation stoppen
2. Quota-Umgehung stoppen
3. Premium-Leckage stoppen
4. Duplicate-Job-Fanout und sinnlose Wiederholungen stoppen
5. Sicherheitslücken bei erneuter Ausführung/Aktualisierung schließen

Halten Sie den Durchlauf auf ein bis drei direkte Behebungen begrenzt, es sei denn, dieselbe Ursache erstreckt sich eindeutig über mehrere Dateien.

6. Mit den kleinsten Nachweisschritten verifizieren

• Führen Sie nur die gezielten Tests oder Integrationsschnitte aus, die den geänderten Pfad abdecken
• Verifizieren Sie, ob der Burn-Pfad jetzt:
  • blockiert
  • dedupliziert
  • auf günstigere Analyse herabgestuft
  • oder frühzeitig abgewiesen wird
• Geben Sie den endgültigen Status genau an:
  • lokal geändert
  • lokal verifiziert
  • gepusht
  • deployed
  • noch blockiert

Hochsignifikante Fehlermuster

1. Ein Warteschlangentyp für alle Auslöser

Wenn Pushes, PR-Synchronisationen und manuelle Überprüfungen alle denselben Job einreihen und der Worker immer einen PR erstellt, entspricht Analyse gleich PR-Spam.

2. Nutzungsreservierung nach dem Enqueue

Wenn die Nutzung an der Haustür geprüft, aber nur im Worker erhöht wird, können gleichzeitige Anfragen alle die Schranke passieren und das Kontingent überschreiten.

3. Kostenloser Tarif auf Premium-Pfad

Wenn kostenlose in die Warteschlange gestellte Jobs trotzdem in Anthropic oder einen anderen Premium-Anbieter geleitet werden können, wenn Schlüssel vorhanden sind, handelt es sich um echte Ausgabenleckage, selbst wenn der Benutzer das Premium-Ergebnis nie sieht.

4. App-generierte Branches treten erneut in den Webhook ein

Wenn pull_request.synchronize, Branch-Pushes oder kommentarausgelöste Ausführungen auf App-eigenen Branches ausgelöst werden, kann die App ihre eigene Ausgabe rekursiv analysieren.

5. Teure Arbeit vor Sicherung der Persistenz

Wenn das System Token verbrauchen und dann bei PR-Erstellung, Dateiaktualisierung oder Branch-Kollision fehlschlagen kann, verbrennt es Kosten, ohne einen Wert zu liefern.

Fallstricke

• Beginnen Sie nicht mit breitem Repositorien-Wandern; klären Sie zuerst Webhook -> Queue -> Worker
• Vermischen Sie nicht die Ableitung von Kundenabrechnungen mit codegestützter Produktwahrheit
• Beheben Sie nicht minderwertige Qualitätsprobleme, bevor der Pfad mit dem höchsten Burn-Wert eingedämmt ist
• Behalten Sie nicht, dass der Burn behoben ist, bis der enge Nachweisschritt erneut ausgeführt wurde
• Pushen oder deployen Sie nicht, es sei denn, der Benutzer hat darum gebeten
• Berühren Sie keine nicht verwandten repositorienlokalen Änderungen, wenn diese bereits im Gange sind

Verifizierung

• Ursachen zitieren exakte Dateipfade und Codebereiche
• Fehlerbehebungen sind nach Brennrate geordnet, nicht nach Code-Sauberkeit
• Nachweisbefehle werden benannt
• Endgültiger Status unterscheidet zwischen lokaler Änderung, Verifizierung, Push und Deployment