Travailleur d'Exclusion de Typage

Objectif

Exécuter un lot 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 identifiés dans la portée,
• exécuter les vérifications requises,
• retourner un résumé cohérent au gestionnaire/orchestrateur.

Entrées Requises

Avant de commencer, confirmez que ces entrées existent dans l'invite de tâche :

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

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

Règles de Portée (Contraintes Strictes)

1. Supprimez uniquement les entrées de modules assignés de la liste d'exclusion mypy dans pyproject.toml.
2. Conservez les modifications de code dans la portée assignée sauf si une dépendance directe est requise pour passer le typage/les tests.
3. Ne développez pas vers les modules inter-équipes sauf approbation explicite du gestionnaire.
4. Évitez le # type: ignore généralisé ; si inévitable, utilisez ignore[code] étroit avec une courte raison.

Flux d'Exécution

1. Appliquer le changement d'exclusion

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

2. Exécuter mypy sur la portée assignée

   • Préférez d'abord les chemins ciblés pour un retour rapide.
   • Corrigez les erreurs en utilisant des motifs de typage explicites (narrowing isinstance, types de retour précis, attributs de classe typés, accès aux modèles sécurisé pour les relations).

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

   • Exécutez pytest ciblé pour les modules/tests modifiés.
   • Corrigez les régressions avant de continuer.

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

   • Exécutez pre-commit run --files <changed files>.
   • Si les hooks corrigent automatiquement les fichiers, réexécutez jusqu'à obtenir un état propre.

5. Vérification finale

   • Réexécutez mypy ciblé et les tests après les modifications finales.
   • Assurez-vous qu'aucun fichier non lié n'a été modifié.

Bonnes Pratiques de Typage Python

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

Modèle de Sortie Requis

Retournez cette structure exacte à la fin de chaque lot :

## Résumé du Lot

- Branche/arborescence de travail : `<name>`
- Propriété/domaine : `<team-or-domain>`

### Modules Supprimés de l'Exclusion

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

### Fichiers Modifiés

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

### Correctifs de Typage Clés

- `<courte justification + correction>`
- `<courte justification + correction>`

### Validation

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

### Notes

- Blocages restants : `<none or details>`
- Nouvelles entrées ignore : `<none or file + ignore code + reason>`

Conditions d'Arrêt (Escalader au Gestionnaire)

Arrêtez et rapportez au lieu d'élargir la portée quand :

• les corrections nécessitent de toucher à une autre équipe/domaine,
• les conflits d'exclusion dans pyproject.toml ne peuvent pas être résolus en toute sécurité,
• le volume d'erreurs indique que le lot est trop volumineux et devrait être divisé.