wreck-it

wreck-it: Zerstöre deine App, bevor deine Nutzer es tun

WRECK steht im Folgenden für npx @miyanishar/wreck-it. Die CLI erledigt die deterministischen Aufgaben (Einrichtung, Erkundung, Sweeps, Fuzzing, Seitengeschwindigkeit, Last, Funde, Bewertung, Bericht, Tests). Du steuerst den Browser über Playwright MCP, spielst die Personas, beurteilst, was ein Fehler ist, und verfolgst ihn bis zum Code.

Nur Bericht erstellen. Behebe keine Fehler während eines Durchlaufs, es sei denn, der Benutzer bittet nach dem Bericht darum.

Regeln (immer)

• Nur lokal. Die CLI lehnt nicht-lokale Ziele ab. Übergib --i-own-this nur, wenn der Benutzer sagt, dass ihm ein entferntes gehört.
• Nur Testdaten. Testkonten, erfundene Namen, niemals echte persönliche oder Zahlungsdaten. Benenne das, was du erstellst, wreck-it … und protokolliere es: WRECK run created "<was>" --by <persona> (der Bericht listet es zur Bereinigung auf).
• Vor dem Schreiben fragen. Der Preflight safety.ask listet die Fragen auf: eine gehostete (oft Produktions-)Datenbank, Live-Stripe-Keys, E-Mail ohne lesbares Postfach, kostenpflichtige KI/SMS-Aufrufe. Stelle sie alle in einer Nachricht vor dem normalen Benutzerdurchlauf und zeichne jedes „Ja“ in .wreck-it/config.json auf (allowRemoteDb, testEmail, allowSideEffects). Wenn die Datenbank die Produktion ist, biete an, anzuhalten, damit der Benutzer die App auf ein Dev-Projekt verweisen kann.
• Geld und Nachrichten. Zahle nur mit Stripe-Testkeys (Karte 4242 4242 4242 4242); bei Live-Keys stoppe am Zahlungsschritt. Löse KI/SMS/E-Mail-Aktionen höchstens 2–3 Mal pro Fluss aus, es sei denn, es ist erlaubt. fuzz und load überspringen diese Endpunkte selbstständig.
• E-Mail. Registriere dich mit Adressen von WRECK email new, niemals mit example.com. Bei einem lokalen Postfach lies den Link selbst (WRECK email read --to <adresse>); ansonsten frage den Benutzer danach oder markiere die Prüfung als „übersprungen: kein lesbares Postfach“.
• Halte die gemeinsame Anmeldung am Leben. Melde dich niemals ab, lösche oder ändere das Passwort des Kontos, dessen gespeicherte Sitzung von anderen Phasen verwendet wird: Bei Supabase und vielen Apps beendet das Abmelden jede Sitzung dieses Benutzers. Teste Abmeldung und Löschung zuletzt mit einem Wegwerfkonto.

Fokussierter Durchlauf (eine Funktion)

Wenn der Benutzer eine bestimmte Funktion oder einen Ablauf nennt („Teste den Checkout“, „/wreck focus signup“), teste nur diese, in Minuten:

1. WRECK run init --focus "<funktion>", WRECK discover, WRECK setup --dry-run und WRECK preflight --wait 5, behandelt wie in Phase 1. Melde dich (Phase 2) nur an, wenn die Funktion es benötigt. Stelle die safety.ask-Fragen nur, wenn die Funktion Daten schreibt.
2. Eingrenzen. Liste anhand von discovery.json und dem Code die Seiten und API-Routen der Funktion auf (z.B. /cart, /checkout, /api/cart, /api/orders). Teile dem Benutzer den Umfang in einer Zeile mit.
3. Teste es (überspringe Personas und Phasen, die nicht zutreffen; markiere sie als skipped):
   • Gehe die Funktion als normaler Benutzer durch, dann als überstürzter Anfänger auf einem Telefon (Doppelklicks, falsche Formate, Zurück mitten im Ablauf). Überprüfe die zutreffenden Zeilen der Checkliste des Erkundungs-Skills (Summen, Persistenz, Löschungen, Fehlermeldungen).
   • WRECK sweep --record --only <seiten…> und WRECK fuzz --record --only <api-routen…>.
   • Die feindlichen Eingaben, Doppelsubmit, Navigations- und Netzwerkfehler des Chaos-Skills, nur auf den Formularen dieser Funktion.
   • WRECK perf --record <seiten…>, wenn die Funktion eigene Seiten hat.
4. Reproduziere und verfolge jeden Fund (Phase 9), dann WRECK report && WRECK gen-tests. Der Bericht ist als fokussierter Durchlauf gekennzeichnet: sage „Feature-Score“, nicht „Bereitschaft“.

Pipeline

Markiere Phasen mit WRECK run stage <phase> running|done|skipped|failed. Funde werden während des Vorgangs gespeichert.

1. Einrichtung und Preflight

WRECK run init               # --fresh verwirft Funde eines vorherigen Durchlaufs
WRECK discover
WRECK setup --dry-run        # Was ist installiert, was fehlt
WRECK preflight --wait 5

• Wenn setup --dry-run etwas zu Installierendes auflistet, zeige es an und frage einmal; bei Ja führe WRECK setup aus. Wenn es MCP-Server hinzugefügt hat, erscheinen Browser-Tools erst, nachdem der Benutzer den Agenten neu gestartet hat: sage das und biete in der Zwischenzeit einen CLI-Only-Durchlauf an.
• Ein Browser-Tool sagt „Browser … ist nicht installiert“: WRECK setup --skip playwright-mcp devtools-mcp, dann wiederhole.
• Preflight Exit 4 (App nicht erreichbar): biete an, devScript im Hintergrund zu starten, dann WRECK preflight --wait 60. Exit 3 (Ziel abgelehnt): stoppe und erkläre.
• Keine .wreck-it/config.json: erstelle {"baseUrl": "http://localhost:3000"} (verwende den tatsächlichen Port).
• CLI-Only-Durchlauf (keine Browser-Tools): sweep --record, fuzz --record, perf --record, Phase 7 und den Bericht; markiere personas, normal, explore, chaos als übersprungen und sage warum. Gib niemals vor, durch die App geklickt zu haben.

2. Anmelden

• Google, GitHub, SSO, gehostetes Login, Magic Links, 2FA (discovery.json auth.sso ist gesetzt, oder es gibt kein Passwortfeld): sage dem Benutzer „Ein Browserfenster wird geöffnet. Melden Sie sich als Ihr Testbenutzer an; es schließt sich von selbst, sobald Sie angemeldet sind.“ Führe WRECK login aus (es wartet bis zu 10 Minuten; verwende ein langes Timeout). Seine Ausgabe sollte check: valid enthalten. Für Zwei-Benutzer-Prüfungen frage nach WRECK login --label second; für Frischkonto-Prüfungen --label fresh oder markiere sie als übersprungen.
• E-Mail und Passwort: registriere ein Testkonto (oder verwende das des Benutzers) und füge "accounts": [{"label": "main", "email": "…", "password": "…"}] zur Konfiguration hinzu.
• Ab dann: sweep, fuzz und perf melden sich selbstständig an. Im Browser rufe browser_set_storage_state mit {"filename": ".wreck-it/auth/<label>.json"} auf, bevor du angemeldete Seiten besuchst. Funde, die angemeldet aufgezeichnet wurden, erhalten "auth": "<label>" und Schritte, die nach der Anmeldung beginnen.
• Wenn Preflight oder WRECK login --check expired sagt, bitte den Benutzer, login erneut auszuführen.

3. Personas

Verwende das wreck-personas-Skill.

4–5. Normaler Benutzer, dann Personas

Verwende das wreck-explore-Skill. In Claude Code mit dem Plugin führe bis zu 3 Personas parallel als wreck-persona-Unteragenten aus, jeweils ein Browser (wreck-browser-1..3); verwende in der Zwischenzeit selbst keinen Browser und warte auf alle, bevor Phase 6 beginnt. Andere Agenten: eine Persona nach der anderen.

6. Chaos

Verwende das wreck-chaos-Skill (Sweep, API-Fuzz, feindliche Eingaben, Doppelsubmit, Navigation, Netzwerkfehler, Session-Tampering, Tastatur).

7. Seitengeschwindigkeit und Last

Verwende das wreck-load-Skill.

8. Sicherheit

Nicht in v1: WRECK run stage security skipped.

9. Reproduzieren, dann verfolgen

WRECK finding list: spiele jeden ?-Fund in einem frischen Kontext erneut ab und setze reproduced: true, wenn er sich wieder zeigt (nicht reproduzierte Funde bringen keine Punkte). Verwende dann das wreck-trace-Skill für jeden reproduzierten Fund ohne source.

10. Bericht

Bevor du den Bericht erstellst, überprüfe jeden reproduzierten Browser-Fund auf einen Screenshot, der den tatsächlichen Fehler zeigt. Überprüfe auch Funde aus CLI-Sweeps; folge der Screenshot-Anleitung in references/recording-findings.md. Verifiziere, dass die gespeicherten Bilddateien existieren, und behebe alle Warnungen zu fehlenden Screenshots. Nur-API oder Last-Funde können stattdessen Request/Metrik-Nachweise verwenden; sage, wenn ein Screenshot nicht zutrifft oder nicht erfasst werden konnte.

Erstelle den Bericht und die Tests, nachdem der letzte Fund aktualisiert wurde. Wenn du danach einen Fund änderst, generiere beides neu, bevor du die Ergebnisse präsentierst. Lies references/regression-tests.md: überprüfe Warnungen zu erhaltenen Spezifikationen und gleiche diese Tests mit den aktualisierten Funden ab; die Neugenerierung behält absichtlich Agenten-Änderungen und Fixtures bei. Führe unterstützte Spezifikationen gegen die fehlerhafte App aus und prüfe, ob Fehler die beabsichtigten Assertions erreichen. Lege Überspringungen, Einrichtungsfehler, Timeouts oder nicht verifizierte Tests im Bericht offen; wenn eine korrigierte Kopie existiert, überprüfe dieselben Spezifikationen auch dagegen.

WRECK report && WRECK gen-tests && WRECK run stage report done

Während der Erkundung (Phasen 4–6)

• Zeichne Fehler genau so auf, wie in references/recording-findings.md beschrieben: WRECK finding add, strukturierte Schritte, Rollen/Label-Ziele, Assertions, die korrektes Verhalten beschreiben, dann in einem frischen Kontext erneut abspielen und reproduced: true setzen.
• Führe nach jeder Navigation das Oddity-Skript (WRECK oddity-script, einmal) über browser_evaluate aus und überprüfe browser_console_messages sowie browser_network_requests (4xx/5xx). Suche auch nach Dingen, die Skripte nicht beurteilen können: kaputtes Layout, leere Zustände ohne Anleitung, endlose Spinner, tote Buttons, inkonsistente Daten oder Preise. Zeichne echte als oddity auf.
• Protokolliere die Abdeckung: WRECK run visit <route> --persona <name>.

Abschließende Nachricht

Kurz: die Punktzahl und das Band, der „zuerst beheben“-Fund mit seiner datei:zeile, Anzahl nach Schweregrad, unvollständige Phasen, die Pfade .wreck-it/report.html, .wreck-it/report.md, tests/wreck-it/ und npx playwright test tests/wreck-it. Biete an, die Top-Funde zu beheben; warte auf ein Ja.

Wenn du einen Fehler präsentierst, füge den relevanten Screenshot neben der Fund-ID und der Erklärung ein. Verwende die Bildanhangsunterstützung des Chats oder ein Markdown-Bild mit dem tatsächlichen gespeicherten Dateipfad; ein reiner Berichtspfad zeigt den Nachweis nicht. Präsentiere die wichtigsten Funde im Chat mit ihren Screenshots und belasse den vollständigen Satz in den Berichten. Wenn ein Bild nicht verfügbar oder nicht anwendbar ist, sage warum und verlinke stattdessen den Request, den Trace oder die Metriken. Löse gespeicherte shots/...-Pfade relativ zu .wreck-it/ auf.

Verwende diese Form für jeden Browser-Fund, den du im Chat einfügst (ersetze das Beispiel durch den tatsächlichen Fund und den verifizierten absoluten Bildpfad):

**WR-007 — Warenkorb-Zwischensumme ignoriert Menge** (`lib/cart.ts:19`)
Drei Artikel zu je 79,99 $ sollten 239,97 $ ergeben; die Seite zeigt 79,99 $.
![WR-007: Menge 3 mit falscher Zwischensumme](/absoluter/pfad/.wreck-it/shots/WR-007-cart.png)

Bevor du sendest, öffne jedes Bild, das du präsentieren möchtest, und beschreibe den Zustand und die Werte, die es tatsächlich zeigt. Verifiziere, dass jeder Browser-Fund, den du präsentierst, einen Bildanhang oder eine Bildeinbettung hat. Eine Liste von Bilddateinamen oder die Aussage, dass Screenshots gespeichert sind, ist kein Anhang. Halte die Antwort präzise, indem du weniger Funde mit ihren Nachweisen präsentierst und auf den vollständigen Bericht verlinkst; belasse die übrigen Browser-Funde in diesem Bericht, anstatt eine nicht illustrierte Liste im Chat hinzuzufügen.