wreck-it

wreck-it: Saccagez votre application avant vos utilisateurs

WRECK ci-dessous signifie npx @miyanishar/wreck-it. La CLI effectue le travail déterministe (configuration, découverte, sweeps, fuzzing, vitesse de page, charge, constatations, score, rapport, tests). Vous pilotez le navigateur via Playwright MCP, jouez les personas, jugez ce qui est un bug et le tracez jusqu'au code.

Rapport uniquement. Ne corrigez pas les bugs pendant une exécution, sauf si l'utilisateur le demande après le rapport.

Règles (toujours)

• Local uniquement. La CLI refuse les cibles non locales. Passez --i-own-this seulement lorsque l'utilisateur déclare posséder une cible distante.
• Données fictives uniquement. Comptes de test, faux noms, jamais de données personnelles ou de paiement réelles. Nommez ce que vous créez wreck-it … et enregistrez-le : WRECK run created "<quoi>" --by <persona> (le rapport le liste pour nettoyage).
• Demandez avant d'écrire. La checklist safety.ask de preflight liste les questions : une base de données hébergée (souvent de production), des clés Stripe live, un email sans boîte de réception lisible, des appels IA/SMS payants. Posez-les toutes dans un seul message avant le passage utilisateur normal, et enregistrez chaque « oui » dans .wreck-it/config.json (allowRemoteDb, testEmail, allowSideEffects). Si la base de données est de production, proposez de vous arrêter pour que l'utilisateur pointe l'application vers un projet de développement.
• Argent et messages. Payez uniquement avec des clés de test Stripe (carte 4242 4242 4242 4242) ; avec des clés live, arrêtez-vous à l'étape de paiement. Déclenchez les actions IA/SMS/email au maximum 2–3 fois par flux, sauf autorisation. fuzz et load sautent ces endpoints eux-mêmes.
• Email. Inscrivez-vous avec des adresses issues de WRECK email new, jamais example.com. Avec une boîte de réception locale, lisez le lien vous-même (WRECK email read --to <adresse>) ; sinon, demandez-le à l'utilisateur ou marquez la vérification « ignorée : pas de boîte de réception lisible ».
• Gardez la session partagée active. Ne vous déconnectez jamais, ne supprimez ni ne modifiez le mot de passe du compte dont la session sauvegardée est utilisée par d'autres étapes : sur Supabase et de nombreuses applications, se déconnecter met fin à toutes les sessions de cet utilisateur. Testez la déconnexion et la suppression en dernier, avec un compte jetable.

Exécution ciblée (une seule fonctionnalité)

Lorsque l'utilisateur nomme une fonctionnalité ou un flux (« teste le checkout », « /wreck focus signup »), testez uniquement cela, en quelques minutes :

1. WRECK run init --focus "<fonctionnalité>", WRECK discover, WRECK setup --dry-run et WRECK preflight --wait 5, traités comme à l'étape 1. Connectez-vous (étape 2) uniquement si la fonctionnalité en a besoin. Posez les questions safety.ask uniquement si la fonctionnalité écrit des données.
2. Délimitez. À partir de discovery.json et du code, listez les pages et routes API de la fonctionnalité (par ex. /cart, /checkout, /api/cart, /api/orders). Dites à l'utilisateur le périmètre en une seule ligne.
3. Testez-la (ignorez les personas et étapes qui ne s'appliquent pas ; marquez-les skipped) :
   • Parcourez la fonctionnalité en tant qu'utilisateur normal, puis en tant que débutant pressé sur un téléphone (doubles clics, mauvais formats, retour en plein flux). Vérifiez les lignes de la checklist de la compétence explore qui s'appliquent (totaux, persistance, suppressions, messages d'erreur).
   • WRECK sweep --record --only <pages…> et WRECK fuzz --record --only <routes api…>.
   • Les entrées hostiles de la compétence chaos, les doubles soumissions, les fautes de navigation et de réseau, sur les formulaires de cette fonctionnalité uniquement.
   • WRECK perf --record <pages…> si la fonctionnalité a ses propres pages.
4. Reproduisez et tracez chaque constatation (étape 9), puis WRECK report && WRECK gen-tests. Le rapport est étiqueté comme exécution ciblée : dites « score de fonctionnalité », pas « état de préparation ».

Pipeline

Marquez les étapes avec WRECK run stage <etape> running|done|skipped|failed. Les constatations sont sauvegardées au fur et à mesure.

1. Configuration et prévol

WRECK run init               # --fresh supprime les constatations d'une exécution précédente
WRECK discover
WRECK setup --dry-run        # ce qui est installé, ce qui manque
WRECK preflight --wait 5

• Si setup --dry-run liste quelque chose à installer, affichez-le et demandez une fois ; sur oui, lancez WRECK setup. Si cela a ajouté des serveurs MCP, les outils navigateur n'apparaissent que lorsque l'utilisateur redémarre l'agent : dites-le, et proposez une exécution CLI uniquement entre-temps.
• Un outil navigateur disant « Browser … is not installed » : WRECK setup --skip playwright-mcp devtools-mcp, puis réessayez.
• Prévol sortie 4 (application non joignable) : proposez de lancer devScript en arrière-plan, puis WRECK preflight --wait 60. Sortie 3 (cible refusée) : arrêtez et expliquez.
• Pas de .wreck-it/config.json : créez {"baseUrl": "http://localhost:3000"} (utilisez le vrai port).
• Exécution CLI uniquement (pas d'outils navigateur) : sweep --record, fuzz --record, perf --record, étape 7 et le rapport ; marquez personas, normal, explore, chaos comme ignorés et dites pourquoi. Ne simulez jamais un clic dans l'application.

2. Connexion

• Google, GitHub, SSO, connexion hébergée, liens magiques, 2FA (discovery.json auth.sso est défini, ou il n'y a pas de champ mot de passe) : dites à l'utilisateur « Une fenêtre de navigateur va s'ouvrir. Connectez-vous en tant qu'utilisateur de test ; elle se fermera toute seule une fois connecté. » Lancez WRECK login (il attend jusqu'à 10 minutes ; utilisez un délai d'attente long). Sa sortie doit indiquer check: valid. Pour les vérifications à deux utilisateurs, demandez WRECK login --label second ; pour les vérifications de nouveau compte, --label fresh, ou marquez-les comme ignorées.
• Email et mot de passe : créez un compte de test (ou utilisez celui de l'utilisateur) et ajoutez "accounts": [{"label": "main", "email": "…", "password": "…"}] à la configuration.
• À partir de là : sweep, fuzz et perf se connectent automatiquement. Dans le navigateur, appelez browser_set_storage_state avec {"filename": ".wreck-it/auth/<label>.json"} avant de visiter les pages connectées. Les constatations enregistrées connectées reçoivent "auth": "<label>" et des étapes qui commencent après la connexion.
• Si la prévol ou WRECK login --check indique expired, demandez à l'utilisateur de relancer login.

3. Personas

Utilisez la compétence wreck-personas.

4–5. Utilisateur normal, puis personas

Utilisez la compétence wreck-explore. Dans Claude Code avec le plugin, exécutez jusqu'à 3 personas en parallèle en tant que sous-agents wreck-persona, un navigateur chacun (wreck-browser-1..3) ; n'utilisez pas de navigateur vous-même pendant ce temps, et attendez-les tous avant l'étape 6. Autres agents : un persona après l'autre.

6. Chaos

Utilisez la compétence wreck-chaos (sweep, fuzz API, entrées hostiles, doubles soumissions, navigation, fautes réseau, falsification de session, clavier).

7. Vitesse de page et charge

Utilisez la compétence wreck-load.

8. Sécurité

Pas dans v1 : WRECK run stage security skipped.

9. Reproduire, puis tracer

WRECK finding list : rejouez chaque constatation ? dans un contexte frais et définissez reproduced: true si elle se reproduit (les constatations non reproduites ne donnent aucun point). Utilisez ensuite la compétence wreck-trace sur chaque constatation reproduite sans source.

10. Rapport

Avant de générer le rapport, vérifiez chaque constatation de navigateur reproduite pour une capture d'écran montrant l'échec réel. Revisitez également les constatations provenant des sweeps CLI ; suivez les recommandations de captures d'écran dans references/recording-findings.md. Vérifiez que les fichiers image sauvegardés existent et résolvez tout avertissement de capture manquante. Les constatations API uniquement ou de charge peuvent utiliser des preuves de requête/métrique à la place ; dites quand une capture d'écran n'est pas applicable ou n'a pas pu être capturée.

Générez le rapport et les tests après la dernière mise à jour de constatation. Si vous modifiez une constatation par la suite, regénérez les deux avant de présenter les résultats. Lisez references/regression-tests.md : inspectez les avertissements de spécifications préservées et réconciliez ces tests avec les constatations mises à jour ; la régénération conserve délibérément les modifications de l'agent et les fixtures. Exécutez les spécifications prises en charge contre l'application buggée et vérifiez que les échecs atteignent les assertions prévues. Divulguez les sauts, les échecs de configuration, les délais d'attente ou les tests non vérifiés dans le rapport ; lorsqu'une copie corrigée existe, testez les mêmes spécifications contre elle aussi.

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

Pendant l'exploration (étapes 4–6)

• Enregistrez les bugs exactement comme dans references/recording-findings.md : WRECK finding add, étapes structurées, cibles rôle/étiquette, assertions décrivant le comportement correct, puis rejouez dans un contexte frais et définissez reproduced: true.
• Après chaque navigation, exécutez le script d'anomalie (WRECK oddity-script, une fois) via browser_evaluate, et vérifiez browser_console_messages et browser_network_requests (4xx/5xx). Cherchez aussi ce que les scripts ne peuvent pas juger : mise en page cassée, états vides sans indication, spinners infinis, boutons morts, dates ou prix incohérents. Enregistrez les vrais comme oddity.
• Journal de couverture : WRECK run visit <route> --persona <nom>.

Message final

Court : le score et le bandeau, la constatation « à corriger en priorité » avec son fichier:ligne, les comptes par sévérité, les étapes incomplètes, les chemins .wreck-it/report.html, .wreck-it/report.md, tests/wreck-it/, et npx playwright test tests/wreck-it. Proposez de corriger les constatations principales ; attendez un oui.

Lorsque vous présentez un bug, joignez sa capture d'écran pertinente à côté de l'ID de constatation et de l'explication. Utilisez le support d'image jointe du chat ou une image Markdown avec le chemin de fichier réel sauvegardé ; un chemin de rapport seul ne montre pas la preuve. Présentez les constatations principales dans le chat avec leurs captures et conservez l'ensemble complet dans les rapports. Si une image est indisponible ou non applicable, dites pourquoi et liez la requête, la trace ou les métriques à la place. Résolvez les chemins shots/... stockés par rapport à .wreck-it/.

Utilisez cette forme pour chaque constatation de navigateur que vous incluez dans le chat (remplacez l'exemple par la constatation réelle et le chemin d'image absolu vérifié) :

**WR-007 — Le sous-total du panier ignore la quantité** (`lib/cart.ts:19`)
Trois articles à 79,99 € chacun devraient totaliser 239,97 € ; la page affiche 79,99 €.
![WR-007 : quantité 3 avec un sous-total incorrect](/chemin/absolu/vers/projet/.wreck-it/shots/WR-007-cart.png)

Avant d'envoyer, ouvrez chaque image que vous prévoyez de présenter et décrivez l'état et les valeurs qu'elle montre réellement. Vérifiez que chaque constatation de navigateur que vous présentez a une image jointe ou intégrée. Une liste de noms de fichiers image ou une déclaration indiquant que les captures sont sauvegardées n'est pas une pièce jointe. Gardez la réponse concise en présentant moins de constatations, avec leurs preuves, et en liant le rapport complet ; laissez les autres constatations de navigateur dans ce rapport au lieu d'ajouter une liste non illustrée dans le chat.