Worker d'exclusion de typage

Objectif

Exécuter un batch de typage assigné de manière sûre et prévisible :

• supprimer uniquement les modules assignés des exclusions mypy,
• corriger les problèmes de typage en scope,
• exécuter les vérifications requises,
• retourner un résumé cohérent pour le manager/orchestrateur.

Entrées requises

Avant de commencer, confirmez que ces entrées existent dans le prompt de la tâche :

• nom de la worktree/branche,
• liste exacte des modules à supprimer de l'exclusion,
• limites de propriété/domaine,
• commandes de validation attendues (si personnalisées).

Si l'une d'elles manque, demandez-la avant de modifier.

Règles de scope (contraintes strictes)

1. Supprimer uniquement les entrées de module assignées de la liste d'exclusion mypy dans pyproject.toml.
2. Limiter les modifications de code au scope assigné, sauf si une dépendance directe est requise pour passer le typage/les tests.
3. Ne pas étendre à des modules inter-équipes sans approbation explicite du manager.
4. Éviter les # type: ignore génériques ; si inévitable, utiliser un ignore[code] étroit avec une raison courte.

Workflow d'exécution

1. Appliquer le changement d'exclusion

   • Supprimer les modules assignés de l'override d'exclusion dans pyproject.toml.

2. Exécuter mypy sur le scope assigné

   • Privilégier les chemins ciblés d'abord pour un retour rapide.
   • Corriger les erreurs en utilisant des patterns de typage explicites (narrowing par isinstance, types de retour exacts, attributs de classe typés, accès aux modèles sûrs pour les relations).

3. Exécuter les tests pour la zone modifiée

   • Exécuter un pytest ciblé pour les modules/tests modifiés.
   • Corriger les régressions avant de continuer.

4. Exécuter pre-commit sur les fichiers modifiés

   • Exécuter pre-commit run --files <fichiers modifiés>.
   • Si les hooks corrigent des fichiers automatiquement, réexécuter jusqu'à propreté.

5. Vérification finale

   • Réexécuter mypy et les tests ciblés après les dernières modifications.
   • Assurer qu'aucun fichier non lié n'a été modifié.

Bonnes pratiques de typage Python

• Préférer les types précis à Any.
• Utiliser le narrowing de type sur les unions avant l'accès aux attributs.
• Garder les overrides de méthode signature-compatibles avec les classes de base.
• Annoter les attributs de classe dans les tests/helpers quand l'inférence est faible.
• Utiliser les objets de relation (obj.related) quand les stubs n'exposent pas les attributs bruts *_id.

Template de sortie requis

Retourner cette structure exacte à la fin de chaque batch :

## Batch Summary

- Branch/worktree: `<name>`
- Ownership/domain: `<team-or-domain>`

### Modules Removed From Exclusion

- `<module.path.one>`
- `<module.path.two>`

### Files Changed

- `<path>`
- `<path>`

### Key Typing Fixes

- `<short rationale + fix>`
- `<short rationale + fix>`

### Validation

- `mypy`: `<pass/fail + scope>`
- `pre-commit --files`: `<pass/fail>`
- `pytest`: `<pass/fail + scope>`

### Notes

- Remaining blockers: `<none or details>`
- Any new ignore entries: `<none or file + ignore code + reason>`

Conditions d'arrêt (Escalade vers le Manager)

S'arrêter et faire un rapport plutôt que d'élargir le scope quand :

• les corrections requièrent de toucher une autre équipe/domaine,
• les conflits d'exclusion dans pyproject.toml ne peuvent pas être résolus de manière sûre,
• le volume d'erreurs indique que le batch est trop large et devrait être divisé.