09.03.02 — Skills Analyse#

Analyses dynamiques : utilisent les logs / les rapports d’une exécution récente pour diagnostiquer un échec. Deux skills de diagnostic de cause racine ouvrent la famille — diagnose-root-cause pour un rouge déterministe, diagnose-flake-root-cause pour un échec intermittent — et aiguillent vers les expériences contrôlées analyse-*.

Listing (potentiellement non exhaustif)#

diagnose-root-cause#

input  : un rouge déterministe (échoue à chaque exécution)
output : analyse de cause racine structurée :
            - reprend l'analyse de zéro, sans réutiliser les hypothèses précédentes
            - remonte du synthétique vers le réel (faux driver → vrai navigateur)
            - lit la source, confirme avec une sonde
            - cause racine triée en cinq familles
         passe la main à diagnose-flake-root-cause si l'échec se révèle intermittent

diagnose-flake-root-cause#

input  : un échec intermittent (un flake)
output : analyse de cause racine fondée sur la distribution :
            - établit un taux d'échec (la distribution est la preuve)
            - fixe la signature, corrèle
            - aiguille vers la bonne expérience analyse-*, augmente le taux pour confirmer
            - classe en cinq familles de flakes
         l'orchestrateur de la famille analyse-*

analyse-flakiness#

input  : logs des N dernières exécutions
output : liste de tests qui retry souvent (par % de retries)
         + recommandation :
            - ajouter une exception au tuple transient_errors
            - investiguer un test particulier (peut-être que le problème vient directement du test)

analyse-fixture-flakiness#

input  : tests avec setup/teardown
output : tests dont le setup fail souvent
         + recommandation :
            - vérifier l'idempotence du setup
            - voir si teardown propre (sinon contamination entre tests)
            - sortir le seed du setup vers une init manuelle si trop fragile

analyse-watcher-flakiness#

input  : logs des watcher.report(...) sur N runs
output : watchers à reporting anormal :
            - trop d'émissions (problème de dedupe)
            - aucune émission (le watcher est inutile)
            - faux positifs (élément attendu reporté comme intrus)

analyse-screenshot-flakiness#

input  : screenshots de N runs, groupés par (test, step, browser)
output : flakiness visuelle :
            - tests dont les screenshots varient anormalement entre runs
            - tests qui passent mais dont l'aspect change
            - identifier si la variation est sémantique (vraie diff) ou cosmétique

Utilise des heuristiques (hash, dimensions, palette dominante). Pas une vraie image diff.

Rôle#

• Consommer une exécution (runtime).
• Détecter des patterns sur la durée (N runs).
• Proposer des actions (élargir transient_errors, refactor un watcher, etc.).

Rappel du Holy Book :

Cycle en échec : review-report → analyse-* → write-a-probe → trouvailles propagées dans IDENTIFIED_GAPS.md / les SFD / un commentaire de scénario → sonde supprimée.