RageClick

Was macht RageClick?

Wandle eine URL und ein Benutzerziel in eine kurze, reproduzierbare Sequenz um, die ein versprochenes Verhalten bricht. Nutze das vorhandene Browser-Tool, um die echte Seite zu inspizieren, und dann den gebündelten Playwright-Runner für wiederholbare Beweise. Dieser Skill bewertet kein visuelles Design und erhebt nicht den Anspruch, echte Nutzerforschung zu repräsentieren.

Umfang und Erfolgskriterien

Arbeite nur mit eigenen Fixtures, lokalen Apps oder explizit autorisierten Testumgebungen. Der gebündelte Runner akzeptiert nur Loopback-URLs, startet einen frischen Browser-Kontext und blockiert Anfragen außerhalb der exakten Herkunft. Eine lokale App kann dennoch ein echtes Backend über ihren Server verändern: Stelle synthetische Daten und ein Einwegkonto bereit, bevor du Einreichungen vornimmst. Kaufe nichts, sende keine Nachrichten, lösche keine wertvollen Daten und ändere keine Zugriffseinstellungen. Die bestehende Berechtigung deckt nur den vereinbarten Workflow ab.

Identifiziere aus dem Benutzerziel und der beobachteten UI ein konkretes unveränderliches Merkmal: ein Projekt für eine Einreichungsabsicht, die Wiederherstellung nach einer ungültigen Datei oder einen Entwurf, der eine versprochene Speicherung überlebt. Wenn der Vertrag unklar ist, dokumentiere eine Beobachtung oder frage nach diesem spezifischen Verhalten, anstatt einen Fehler zu erfinden. Notiere die Anwendungsversion oder den Commit; verwende unknown, wenn nicht verfügbar.

Erkunden, stören, wiederholen

1. Inspiziere die aktuelle Seite mit einem verfügbaren Browser-Tool oder der Zielquelle. Wähle stabile Labels, Rollen oder Test-IDs aus den tatsächlichen Beweisen. Führe zuerst den normalen erfolgreichen Workflow aus. Wenn er nicht abgeschlossen werden kann, behebe diese Voraussetzung oder melde sie separat.

2. Lies references/plans.md, um einen JSON-Plan zu schreiben. Wähle die zutreffenden Vorlagen aus references/perturbations.md. Ändere eine Dimension pro Fall. Frische Browser-Kontexte isolieren den Browser-Status, aber Serverdaten erfordern einen bekannten Reset oder ein eindeutiges Einwegkonto. Gehe nicht davon aus, dass ein frischer Browser eine Datenbank zurücksetzt.

3. Führe von diesem Skill-Verzeichnis nach npm ci und npx playwright install chromium aus:

   node scripts/run.mjs --url http://127.0.0.1:3000 --plan /absolute/path/case.json --out /absolute/path/evidence --app-version COMMIT
   

   Das Ausgabeverzeichnis muss neu sein. Der Runner schreibt einen lesbaren Bericht, den genauen Plan, Schrittergebnisse, Screenshots, Trace, Video und ein Wiederholungsskript. Er kann kein Ziel oder Selektoren selbst ableiten; diese Arbeit erledigt der Skill. Bewahre generierte Beweise außerhalb des Ziel-Repositorys auf, es sei denn, sie werden dauerhaft als Beispiel angefordert.

4. Behandle observed_failure als eine Assertion-Diskrepanz, nicht als gesicherte Ursache. Wiederhole denselben Fall in frischem Zustand mindestens zweimal, bevor du ihn als reproduzierbar bezeichnest. Erfasse Fehlschläge und Erfolge; verwerfe niemals widersprüchliche Wiederholungen. execution_error bedeutet, dass eine Aktion, ein Selektor, der Browser oder eine Grenze fehlgeschlagen ist, und stellt keinen Produktbeweis dar. Zeichne subjektive UX-Kommentare getrennt von objektiven Assertionen auf.

5. Minimiere die Sequenz ohne den Fehler zu ändern, verwende dann replay.mjs als Regressionsbefehl (exit 0 für Erfolg, 1 für Assertion-Diskrepanz, 2 für Ausführungs-/Konfigurationsfehler). Wenn du autorisiert bist, die App zu reparieren, führe den identischen Plan erneut gegen die reparierte Version aus und verifiziere, dass der normale Pfad immer noch funktioniert. Ändere niemals die Assertion, um ein erfolgreiches Ergebnis zu erzeugen.

Melde den verletzten Vertrag, den tatsächlichen und erwarteten Zustand, die Anzahl des Auftretens, die App-/Browser-Versionen, die genauen Befehle und Beweispfade. Gib an, wenn Video, Trace, Baseline, Reset oder Wiederholbarkeit fehlt. Schwärze Zugangsdaten und personenbezogene Daten, bevor du Aufnahmen teilst; Traces können vollständige Anfrage-/Antwortdaten enthalten. Dieses Skill impliziert keine Veröffentlichung oder externe Nachrichten.

Grenzen

Der Runner verwendet Chromium, CSS-Selektoren, native Zeigerereignisse, synthetische Inline-Dateien und begrenzte Anforderungsverzögerungen. Eine Anforderungsverzögerung ist keine Bandbreitendrosselung oder kein Paketverlust. Er kann nicht automatisieren: Remote-Staging, HTTP-Weiterleitungen (einschließlich Same-Origin-Weiterleitungen), Streaming-Antworten, Multi-Origin-Login, Service Worker, WebSockets oder beliebiges JavaScript. Antworten werden durch Playwright mit deaktivierten Weiterleitungen und Transport-Wiederholungen gepuffert, sodass Streaming und Netzwerk-Timing-Genauigkeit eingeschränkt sind. Browser-Anmeldedaten- und Set-Cookie-Richtlinientests werden ebenfalls nicht unterstützt: Der API-Transport kann Antwort-Cookies anders speichern als der Browser-Fetch. Verwende für nicht unterstützte Workflows ein bereits verfügbares, autorisiertes Browser-Tool und halte denselben Beweisvertrag ein; markiere nicht unterstützte Störungen explizit. Schwäche nicht die Herkunftsgrenze des Runners, um einen Test bestehen zu lassen.