Muter ce que j'ai changé

Ferme la boucle locale de développement. Une seule commande pour exécuter Stryker sur chaque fichier source que la branche actuelle a touché (vs origin/master), puis identifier les reds qui ont besoin d'être renforcés.

Quand utiliser

• L'utilisateur dit /mutate-changed, "mute les fichiers que j'ai changés", "vérifie mes changements", "mes tests ont-ils tenu"
• En cours de feature : le dev veut un retour pré-merge avant de pusher
• Pré-PR : moins cher que d'attendre le cron nocturne

Ne pas utiliser :

• Pour un seul fichier spécifique (/n8n:mutation-test <path> est plus rapide)
• Pour des changements en dehors de packages/workflow — Stryker est seulement câblé là pour le moment
• Après que l'utilisateur ait déjà exécuté /n8n:strengthen-tests (qui appelle mutation-test en interne pour vérification — relancer les deux est du calcul gaspillé)

Entrées

• Base par défaut : origin/master. Surcharge avec --base <ref> pour comparer avec une autre branche (ex. --base HEAD~5).
• Portée par défaut : packages/workflow/src/**/*.ts. Le seul package avec Stryker câblé pour le moment.

Étapes

1. Identifier les fichiers source modifiés

git diff --name-only origin/master...HEAD -- 'packages/workflow/src/**/*.ts'

(... est correct — trois points signifient « depuis que la branche a divergé de la base », c'est ce qu'on veut.)

Si git fetch n'a pas été exécuté récemment, suggère à l'utilisateur de lancer git fetch origin master d'abord ; sinon la ref de base est obsolète.

Filtre :

• **/*.d.ts (déclarations, pas de comportement)
• **/*.stories.ts (scaffolding Storybook, absent du workflow mais défensif)
• fichiers index.ts (barrels)
• interfaces.ts, types.ts, constants.ts (même filtre basse valeur que seed-ledger.mjs)

2. Présenter le plan à l'utilisateur

Affiche la liste filtrée avant d'exécuter quoi que ce soit. Chaque run Stryker dure 1–5 minutes ; l'utilisateur doit confirmer s'il y en a beaucoup.

Found N changed source files to mutate:
  - packages/workflow/src/foo.ts
  - packages/workflow/src/bar.ts
  ...

Estimated runtime: ~M-K minutes (M minutes minimum if every Stryker run is fast).
Proceed? (skill default: yes if N ≤ 3, ask if N > 3)

Si la liste filtrée est vide : rapporte « No source files under packages/workflow/src/** changed vs $base — nothing to mutate. » et arrête. Quitte proprement.

Si N > 8 : refuse et demande à l'utilisateur de réduire la portée (une autre ref de base, ou invoquer par fichier). Exécuter 8+ mutations séquentiellement c'est une session de 30+ minutes qui devrait être un choix délibéré.

3. Exécuter le test mutation par fichier

Pour chaque fichier du plan, invoque pnpm --filter=n8n-workflow mutate <package-relative-path>. Le summary.json et autres artefacts sont écrasés à chaque run, donc capture le score par fichier au fur et à mesure.

Après chaque run qui se termine, affiche une ligne :

✓ src/foo.ts   95.12% (39/41 killed)   GREEN
✗ src/bar.ts   54.83% (17/31 killed)   RED  — 13 survivors, top: ConditionalExpression, EqualityOperator

Si un run Stryker échoue durement (sortie 3, pas de summary.json), affiche ! src/foo.ts Stryker failed — see stderr et continue au fichier suivant. N'interromps pas tout le batch.

4. Tableau récapitulatif

Après que tous les fichiers aient été mutés, affiche un tableau compact :

=== Mutation results: N files, M green, K red, J failed ===
| File                        | Score   | Verdict | Survivors |
|-----------------------------|---------|---------|-----------|
| src/foo.ts                  |  95.12% | GREEN   |         2 |
| src/bar.ts                  |  54.83% | RED     |        13 |
| src/baz.ts                  |    n/a  | FAILED  |         - |

5. Proposer l'étape strengthen sur le pire fichier red

S'il y a un fichier red :

The lowest-score red file is src/bar.ts (54.83%, 13 survivors). Run /n8n:strengthen-tests to triage them and write assertion changes? (suggesting; don't auto-invoke)

Suggère un seul fichier à la fois — n8n:strengthen-tests plafonne à 5 survivors par invocation, et relancer cette skill après édits est bon marché.

Si tout est green : rapporte-le et arrête. Pas de suivi nécessaire.

Forme de sortie

Trois sections délivrables par invocation :

1. Plan (avant d'exécuter) — liste des fichiers, durée estimée
2. Progression par fichier (pendant) — une ligne par fichier au fur et à mesure
3. Tableau récapitulatif + recommandation (après) — vue compacte

Ne déverse pas les payloads complets summary.json — les runs de mutate par fichier les écrivent déjà sur disque dans packages/workflow/reports/mutation/ (écrasement à chaque fois, puisque l'orchestrateur utilise des noms de fichier fixes). L'utilisateur peut lire le dernier s'il veut plus de détails.

Contraintes

• Codé en dur pour packages/workflow. Généralise quand Stryker sera câblé à d'autres packages.
• Max 8 fichiers par invocation. Au-delà, demande à l'utilisateur de réduire.
• Ne pas auto-invoquer /n8n:strengthen-tests. Suggère, n'agis pas. Même raison que pour les autres skills : chaque passage doit être une étape délibérément approuvée par l'humain.
• Pas de commits. Les édits restent dans le working tree ; l'utilisateur examine.
• Pas de scores fabriqués. Si un run Stryker échoue, marque FAILED dans le tableau — ne devine jamais une valeur.

Suites fréquentes

• "strengthen them all" → boucle l'utilisateur à travers /n8n:strengthen-tests, un fichier à la fois
• "what changed?" → git diff origin/master...HEAD -- <file> pour le fichier en question
• "ignore <pattern>" → relance avec le filtre d'exclusion de l'utilisateur ajouté

Lié

• n8n:mutation-test — version single-file de cette skill
• n8n:strengthen-tests — l'étape naturelle suivante quand des reds apparaissent