Orchestrated Refactoring

Sélectionné par Skill Harbor : une enveloppe fine et disciplinée sur le moteur partagé orch-pipeline pour le seul travail où le diff ne doit rien changer d'observable. La règle est absolue : même comportement, meilleure structure. L'opération exécute un masque de phases fixe : planifier la restructuration, puis garder le vert, avec deux portes, une sur le plan de restructuration et une pré-commit. Le premier mouvement est toujours de confirmer que les tests pertinents existent et sont verts avant de toucher au code ; où la couverture est mince, des tests de caractérisation sont ajoutés d'abord, car la suite existante est le filet de sécurité et aucun nouveau test de comportement n'est écrit. La restructuration procède par petits pas avec la suite de tests relancée après chacun. Pour les balayages de code mort et de duplication, elle délègue à l'agent refactor-cleaner, qui lance knip, depcheck et ts-prune et retire en sécurité. Le commit atterrit en refactor:, et le diff doit être neutre en comportement. Si le comportement doit changer tant soit peu, ce n'est pas le bon skill ; les frères orch-change-feature et orch-fix-defect couvrent ces cas. Par @affaan-m, listé ici avec crédit à son créateur. Tiré du dépôt affaan-m/ECC (MIT). Bémols honnêtes : des tests verts prouvent que la suite passe, pas que le comportement est vraiment préservé ; une couverture mince signifie un filet plus mince, ajoutez des tests de caractérisation. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.