rageclick

Que fait rageclick ?

Transformez une URL et un objectif utilisateur en une séquence courte et reproductible qui casse un comportement promis. Utilisez l'outil navigateur existant pour inspecter la page réelle, puis le runner Playwright intégré pour des preuves reproductibles. Ce skill n'évalue pas le design visuel ni ne prétend représenter une recherche utilisateur réelle.

Périmètre et critères de succès

Travaillez uniquement sur des fixtures personnelles, des applications locales ou des environnements de test explicitement autorisés. Le runner intégré n'accepte que des URL en boucle locale, démarre un contexte navigateur frais et bloque les requêtes en dehors de l'origine exacte. Une application locale peut toujours muter un backend réel via son serveur : établissez des données synthétiques et un compte jetable avant de soumettre. N'achetez pas, n'envoyez pas de messages, ne supprimez pas de données importantes et ne modifiez pas les paramètres d'accès. L'autorisation existante ne couvre que le workflow convenu.

À partir de l'objectif utilisateur et de l'interface observée, identifiez un invariant concret : un projet pour un seul objectif de soumission, une récupération après un fichier invalide ou un brouillon survivant à une sauvegarde promise. Si le contrat est ambigu, enregistrez une observation ou demandez des précisions sur ce comportement spécifique plutôt que d'inventer un défaut. Enregistrez la version de l'application ou le commit ; utilisez unknown si indisponible.

Explorer, perturber, rejouer

1. Inspectez la page actuelle à l'aide d'un outil navigateur disponible ou de la source cible. Sélectionnez des étiquettes, rôles ou identifiants de test stables à partir de preuves réelles. Exécutez d'abord le workflow normal réussi. S'il ne peut pas aboutir, résolvez cette condition préalable ou signalez-la séparément.

2. Lisez references/plans.md pour écrire un plan JSON. Choisissez les modèles applicables dans references/perturbations.md. Modifiez une dimension par cas. Les contextes navigateur frais isolent l'état du navigateur, mais les données serveur nécessitent une réinitialisation connue ou un compte jetable unique. Ne supposez pas qu'un navigateur frais réinitialise une base de données.

3. Exécutez depuis ce répertoire de skill après npm ci et npx playwright install chromium :

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

   Le répertoire de sortie doit être nouveau. Le runner écrit un rapport lisible, le plan exact, les résultats des étapes, des captures d'écran, une trace, une vidéo et un script de rejeu. Il ne peut pas déduire un objectif ou des sélecteurs par lui-même ; c'est le skill qui fait ce travail. Gardez les preuves générées en dehors du dépôt cible, sauf si demandé comme exemple durable.

4. Traitez observed_failure comme une divergence d'assertion, pas comme une cause racine établie. Répétez le même cas dans un état frais au moins deux fois avant de le qualifier de reproductible. Capturez les échecs et les réussites ; ne jetez jamais les exécutions contradictoires. execution_error signifie qu'une action, un sélecteur, un navigateur ou une limite a échoué et ne constitue pas une preuve produit. Enregistrez les commentaires subjectifs sur l'UX séparément des assertions objectives.

5. Minimisez la séquence sans modifier l'échec, puis utilisez replay.mjs comme commande de régression (code 0 : succès, 1 : divergence d'assertion, 2 : erreur d'exécution/configuration). Si vous êtes autorisé à corriger l'application, ré-exécutez le plan identique contre la version corrigée et vérifiez que le chemin normal réussit toujours. Ne modifiez jamais l'assertion pour fabriquer un résultat réussi.

Signalez le contrat violé, l'état réel et attendu, le nombre d'occurrences, les versions de l'application/du navigateur, les commandes exactes et les chemins de preuves. Mentionnez quand la vidéo, la trace, la référence, la réinitialisation ou la reproductibilité est absente. Masquez les identifiants et les données personnelles avant de partager les captures ; les traces peuvent contenir des données complètes de requêtes/réponses. Ce skill n'implique aucune publication ni message externe.

Limites

Le runner utilise Chromium, des sélecteurs CSS, des événements de pointeur natifs, des fichiers en ligne synthétiques et des délais de requête limités. Un délai de requête n'est pas une limitation de bande passante ni une perte de paquets. Il ne peut pas automatiser le staging à distance, les redirections HTTP (y compris les redirections vers la même origine), les réponses en streaming, la connexion multi-origine, les service workers, les WebSockets ou du JavaScript arbitraire. Les réponses sont mises en mémoire tampon via Playwright, avec les redirections et les tentatives de transport désactivées, de sorte que la fidélité du streaming et du timing réseau est limitée. Les tests de politique de cookies et de credentials navigateur ne sont pas non plus pris en charge : le transport API peut stocker les cookies de réponse différemment du fetch navigateur. Pour les workflows non pris en charge, utilisez un outil navigateur déjà disponible et autorisé en préservant le même contrat de preuves ; marquez explicitement les perturbations non prises en charge. N'affaiblissez pas la limite d'origine du runner pour faire passer un test.