baratihd/skills

Planificateur Backend Treatment

Ceci est une compétence de planification, partagée entre Codex, OpenCode et Claude Code. Produire un plan actionnable basé sur des preuves vérifiées du dépôt ; ne pas modifier le code de l'application ni exécuter de migrations en mode planification, sauf demande explicite.

Découvrir et vérifier le contexte

1. Identifier le résultat attendu, les critères d'acceptation, la branche de travail, la branche cible (le cas échéant) et l'environnement de déploiement prévu. Ne pas supposer les noms de branches production ou development. Vérifier git status et les références avant de comparer. Ne jamais écraser de travail non commité.
2. Lire les documents produits / métier existants (persan) et les documents techniques / qualité (anglais) lorsqu'ils sont disponibles. En cas d'absence, signaler exactement quelle documentation manque ; ne pas inventer d'exigences métier.
3. Si Graphify est installé et un graphe actuel applicable est disponible, utiliser éventuellement graphify query, path ou explain pour s'orienter ; ne jamais exiger Graphify. Si indisponible ou obsolète, rechercher directement le code source, les migrations, les paramètres et les tests concernés. Traiter les graphes comme des indices, pas des preuves.
4. Vérifier les classes, les sites d'appel, les permissions, les flux de données, la configuration, les contraintes de base de données et les dépendances externes dans le code source réel.
5. Déterminer les versions de Python/Django/runtime à partir de la configuration active du projet et des fichiers de verrouillage. Signaler les incohérences ; ne pas coder en dur des versions historiques du framework.
6. Pour les comparaisons de branches, utiliser les références source et destination réellement spécifiées par l'utilisateur ; distinguer l'historique des commits des modifications de l'arbre de travail. Ne pas récupérer les références distantes sans prendre en compte l'autorisation de l'utilisateur / la disponibilité du réseau.

Examen de l'architecture et de l'impact des modifications

• Identifier l'application propriétaire et les limites ; éviter les abstractions inutiles ou le couplage inter-applications. Appliquer SOLID et un calque propre de manière pragmatique, pas mécanique.
• Vérifier les contrats d'API publique (routes, sérialiseurs, types de champs, formats de statut / erreur, pagination, filtrage), la compatibilité avec le frontend/PWA, et l'authentification / autorisation / isolation des locataires.
• Analyser les coûts des requêtes ORM, les N+1, les transactions et verrous, les contraintes, la concurrence, la cohérence des données, l'ordre des migrations et leur réversibilité.
• Inclure les effets asynchrones et externes (nouvelles tentatives et idempotence Celery, transaction.on_commit, invalidation du cache, Elasticsearch/synchronisation d'index, timeouts et erreurs HTTP, passerelles SMS).
• Analyser l'observabilité, la sécurité et les secrets, les opérations, le déploiement, le rollback, les indicateurs de fonctionnalité et le séquencement du déploiement selon la pertinence.
• Distinguer le comportement actuel vérifié, le comportement prévu documenté, la modification proposée et les questions ouvertes. Identifier clairement toute incohérence.
• Considérer la testabilité et l'infrastructure de test existante ; pas d'envoi réel vers des tiers/SMS/Celery dans les tests automatisés de routine.

Sortie requise

Produire un plan complet de décision avec :

1. Périmètre, objectif, contraintes et critères d'acceptation.
2. Preuves et chemins sources pertinents, plus révision source/cible lorsqu'elle est utilisée.
3. Architecture / flux de données actuel et architecture / flux de données proposé, avec propriété des composants.
4. Étapes d'implémentation ordonnées, interfaces publiques affectées et mesures de compatibilité.
5. Stratégie de migration / backfill, gestion des échecs, observabilité, déploiement et rollback (le cas échéant).
6. Scénarios explicites de test Unitaires / Intégration / API / E2E / Smoke (FireTest), migration, sécurité et performance proportionnés au risque.
7. Mises à jour de documentation nécessaires et pages de documentation affectées.
8. Incertitudes, hypothèses, compromis et décisions bloquées ; poser des questions ciblées uniquement lorsque nécessaire.

Collaboration des compétences

• Lorsque treatment-django-engineer invoque cette compétence, retourner d'abord le plan ; l'ingénieur est responsable de l'implémentation, de l'intégration et du rapport final.
• Recommander django-product-documentation pour mettre à jour la documentation impactée et treatment-backend-testing pour implémenter les tests, mais ne pas prétendre que ces compétences ont été exécutées sauf si elles ont été trouvées et réellement invoquées / lues.
• Si une compétence dépendante est absente, enregistrer la dépendance manquante et fournir un plan de repli utilisable sans inventer ses règles.
• Cette compétence ne s'exécute pas automatiquement pour chaque modification triviale de typo ou de formatage ; adapter l'effort de planification à l'impact.

Garde-fous non négociables

N'inventer jamais de politiques de domaine, de modèles de données, de comportement d'API non documenté ou de résultats de test. Aucune opération de base de données destructive silencieuse, commit, déploiement ou modification de fichiers non liés. Ne pas prétendre à une couverture, une construction, une migration ou un succès d'intégration sans l'avoir exécuté et mesuré.