VianoBugAnalysis/AGENTS.md

Arbeitsregeln für Entwicklung und Tests

Speicherbudget für Testläufe

• Testläufe dürfen zusammen höchstens 20 GB (20.000.000.000 Bytes) auf der Platte belegen. Das ist eine Vorgabe für Entwicklungs- und Testdaten, keine Grenze des Case-Paketformats.
• Vor jedem neuen Testlauf den Gesamtverbrauch der Test-Workspaces und ihrer temporären Kopien prüfen. Während längerer Läufe genügend Reserve berücksichtigen und den Verbrauch überwachen.
• Älteste Testläufe zuerst bereinigen, soweit erforderlich, um die Grenze einzuhalten. Aktuelle Vergleichsläufe nur innerhalb dieses Gesamtbudgets behalten. Vor rekursivem Löschen die aufgelösten Zielpfade prüfen; keine Quelldaten, Projektkonfiguration, Testdatenbank oder Source-Checkouts mitlöschen.
• Langfristig ausschließlich das Ergebnis und eine Beschreibung des Testlaufes archivieren. Die Beschreibung sollte Eingaben/Referenzen, Code- und Konfigurationsstand ohne Geheimnisse, Testziel, Ergebnisbewertung sowie verfügbare Laufzeit-, Token-, Cache- und Kostenmetriken festhalten.
• Vollständige Zwischenstände, Paketgenerationen, Request-/Response-Dumps und temporäre Arbeitskopien sind keine dauerhaften Testarchive. Ein finales Ergebnispaket darf als Ergebnis archiviert werden.
• Ausdrücklich ausgenommen vom Verbot langfristiger Request-/Response-Dumps ist das vom Nutzer beauftragte, kleine und kuratierte Fehlerkorpus unter tests/fixtures/llm_rejections/: ausgewählte abgelehnte Antworten mit benötigtem Prüfkontext und Fehleranalyse dürfen dort dauerhaft versioniert bleiben. Es sind keine vollständigen Testlaufarchive. Das Korpus darf bei der automatischen Testlaufbereinigung nicht mitgelöscht werden und zählt weiterhin zum gesamten Speicherbudget für Entwicklungs-/Testdaten.
• Diese Aufbewahrungsregel erlaubt keine Entfernung einzelner Inhalte aus einer erhaltenen Case-Akte. Paketinhalt und lokale Aufbewahrung vollständiger Testläufe bleiben getrennte Anliegen.

Ausführung

• Kostenpflichtige LLM-Testläufe führt der Nutzer selbst aus, sofern er nicht ausdrücklich eine andere Ausführung beauftragt.
• Lokale Commits sind erlaubt. Nicht pushen; der Nutzer führt Pushes selbst durch.
• docs/architecture.md ist die maßgebliche Designspezifikation und darf ohne ausdrücklichen Auftrag nicht geändert werden.

Dauerhafte Testmetriken

• Nach jeder ausgewerteten LLM-Testausführung die Tokenbilanz unabhängig vom Case-Paket unter docs/test-results/token-usage/ sichern. Vor dem Entfernen eines Test-Workspaces das Vorhandensein des Berichts prüfen.
• Gesamtverbrauch einschließlich Korrektur-/Wiederholungsaufrufen und bereinigte Phasenbilanzen getrennt ausweisen; gemeinsame Aufrufe nur einmal zählen. Fehlende Werte bleiben als unbekannt gekennzeichnet. Denktokens nicht erneut zu Ausgabetokens addieren, wenn sie darin bereits enthalten sind.
• Lauf-/Case-Identität, Ergebnis und Messumfang, Prompt-/Modellversionen, Konfigurations-/Quellenhashes, Cachewerte, verfügbare API-/Falllaufzeiten sowie Kostenstände mit Abrechnungsstatus festhalten. Bereits berichtete Snapshots erhalten, spätere Fortschritte als neue Snapshots ergänzen.
• Berichte enthalten keine Prompts, vollständigen Antworten, Secrets oder Konfigurationsinhalte. Die kleinen Metrikberichte und Vergleiche dürfen langfristig versioniert bleiben; sie zählen zum Speicherbudget für Testdaten.
• Zusätzlich Gesamt- und bereinigte Kostenschätzungen pro Phase und LLM-Aufruf ausweisen. Der erste reguläre Aufruf bleibt in der bereinigten Bilanz, auch wenn er korrigiert werden musste; zusätzliche Reparatur- und Wiederholungsaufrufe bilden den Korrekturaufwand.
• Modell und verwendete Preistabelle mit Währung und Erfassungsstand im Bericht sichern. Ungecachte Eingabe, Cacheeingabe und Ausgabe einschließlich Denktokens getrennt berechnen; Cache-Speicherung separat, fehlende Werte als unbekannt. USD-Schätzungen nicht mit den vom Nutzer gemeldeten EUR-Abrechnungskosten gleichsetzen.