baratihd/skills

Note de version du Backend de Traitement (Treatment Backend)

Générer une note de version anglaise précise et vérifiable à partir de preuves concrètes du dépôt lors de la promotion d'une branche source vers une branche cible, en particulier stage ou production. Après avoir rédigé la note de version, produire un résumé séparé en persan dans la conversation uniquement. Ne jamais ajouter, intégrer ou écrire le résumé persan dans la note de version ou tout autre fichier du projet.

Contrat d'exécution inter-agents

• Cette compétence est portable entre Codex, OpenCode et Claude Code ; aucun outil spécifique à un fournisseur n'est requis. Lisez ce fichier SKILL.md et les fichiers references/ liés lorsqu'elle est invoquée.
• Une copie canonique unique est stockée dans .agents/skills/treatment-backend-release-note/ ; .claude/skills/ et .opencode/skills/ pointent vers la même copie lors de l'utilisation de l'installeur groupé. Ne maintenez pas de copies divergentes.
• Si des outils ou des permissions ne sont pas disponibles, signalez la limitation avec précision ; ne fabriquez pas de preuves Git ni de statut de version.
• Acceptez une invocation en langage naturel, ou $treatment-backend-release-note dans Codex, /treatment-backend-release-note dans Claude Code et les configurations OpenCode prises en charge. Toutes les invocations suivent exactement le même flux de travail et la même politique de sortie.

Entrées et périmètre

• Requis : source_branch, target_branch (cible par défaut uniquement si l'utilisateur établit explicitement une convention de projet ; sinon, demandez-la lorsqu'elle est réellement indisponible).
• Optionnel : version de la version, fenêtre de déploiement, références de ticket, nom de fichier de sortie (stocké sous docs/releases/), méthode de déploiement, responsable.
• Détectez les dépôts distants et validez les références, l'état de l'arbre de travail et la racine du dépôt avant de collecter les modifications. Ne changez pas de branche, ne faites pas de pull, fetch, commit, merge, tag, déploiement ou ne modifiez pas le code de l'application sans autorisation explicite.
• Si la source/cible n'est pas spécifiée, tentez de les déduire du contexte clair (par exemple, l'utilisateur dit "release develop to stage") ; sinon, demandez. Ne présumez jamais silencieusement que la branche actuellement extraite est la source.
• Les deux références peuvent être des branches locales ou des branches de suivi à distance ; spécifiez exactement quelles références résolues et quels hachages de commit ont été analysés.
• Interprétez le rapport comme les modifications introduites par la source dans la cible, pas tout ce qui a été commité sur la branche source.

Flux de travail

1. Pré-vol et preuves Git

Depuis la racine du dépôt, inspectez ces commandes (adaptez les noms de référence en toute sécurité ; n'interpolez pas d'arguments shell non fiables) :

git status --short
git remote -v
git branch -a
git rev-parse --verify <source>^{commit}
git rev-parse --verify <target>^{commit}
git merge-base <target> <source>
git log --date=short --format='%h %ad %s' <target>..<source>
git diff --stat <target>...<source>
git diff --name-status <target>...<source>
git diff <target>...<source> -- <relevant-paths>

target..source identifie les commits non atteignables depuis la cible. target...source dans git diff compare le merge-base à la source, en approximant les modifications proposées par la branche source. Ceux-ci peuvent ne pas correspondre exactement au diff de fusion résultant pour des branches divergentes, des cherry-picks ou des rebases. Pour une version proposée, inspectez les deux perspectives (commits et diff), identifiez les anomalies et, si nécessaire, utilisez un espace de travail jetable/une fusion temporaire uniquement avec autorisation. N'affirmez pas un résultat de fusion définitif à partir d'un diff non vérifié à trois points. Pour une version déjà terminée, privilégiez le commit de fusion enregistré, le tag, le SHA déployé ou les références réelles avant/après le déploiement, si disponibles.

Examinez les fichiers sources significatifs, les migrations, la configuration, les schémas d'API, les sérialiseurs, les permissions, les tâches en arrière-plan, les intégrations, les tests et les manifestes de déploiement ; évitez de vous fier uniquement aux sujets des commits. Excluez les fichiers générés/bruités du récit le cas échéant, mais ne cachez pas les migrations générées ayant un impact ou les modifications de fichiers de verrouillage. Recherchez les modifications ayant des effets commerciaux couvrant plusieurs commits. Regroupez par capacité métier plutôt que de lister chaque fichier modifié. Liez le code aux tickets/PR lorsque cela est démontrable.

2. Classification des modifications et de leur impact

Séparez et décrivez :

1. Modifications métier — nouveaux workflows modifiés, règles d'éligibilité, couverture, traitement des dépenses/réclamations, rapports, notifications et comportement observable. Écrivez uniquement lorsque cela est étayé par le code, les tests ou le contexte produit fourni par l'utilisateur ; étiquetez clairement les inférences ou les confirmations manquantes.
2. Modifications techniques — API, modèles Django/migrations, tâches/Celery, base de données/index, intégrations externes, paramètres, sécurité/permissions, fiabilité, performances, observabilité, CI/CD et remaniement de code.
3. Compatibilité et consommateurs — points de terminaison REST/méthodes, champs de requête/réponse, codes de statut, authentification, clients web/mobile, appelants internes, travailleurs, systèmes tiers, base de données et événements. Indiquez Changement cassant : Oui / Non / Inconnu avec des preuves. Distinguez la compatibilité API de la compatibilité de déploiement/données. Expliquez les actions consommateur requises et l'ordre de déploiement le cas échéant.
4. Validation et traçabilité — références source/cible exactes + SHA, SHA de base, commits notables, liens vers tickets/PR lorsqu'ils sont trouvés, tests et leur statut observé réel, plans de migration, approbateurs/statut si fournis. N'affirmez pas qu'un test a réussi sans l'avoir exécuté ou obtenir des résultats de test fiables.
5. Annulation / rollback — décrivez les étapes appropriées à la cible et les prérequis, avec un traitement distinct pour le rollback de l'application, les migrations de schéma réversibles, les migrations de données irréversibles, les tâches rejouables, les messages, l'idempotence et les effets secondaires tiers. Distinguez toujours un revert Git d'un rollback opérationnel. N'affirmez jamais qu'un rollback est sûr sans vérifier les migrations et les effets secondaires.

Consultez la liste de contrôle complète dans references/review-checklist.md.

3. Rédigez et sauvegardez la note de version en anglais

Suivez references/release-note-template.md. Utilisez l'anglais pour tout le contenu sauvegardé dans la note de version, y compris les titres. Restez concis mais informatif et approprié pour un examen à la fois technique et commercial. Utilisez "Non vérifié", "Inconnu" ou "Nécessite confirmation" plutôt que d'inventer des détails.

Le répertoire de sortie canonique du projet est docs/releases/. Sauvegardez chaque note de version là-bas ; ne créez pas de répertoire release-notes/ à la racine. La sortie par défaut est docs/releases/YYYY-MM-DD-<source>-to-<target>.md, avec les barres obliques des branches remplacées par des traits d'union. Respectez un nom de fichier explicitement demandé tout en le gardant sous docs/releases/. Évitez d'écraser une note de version existante. Si la destination existe, choisissez un nom de fichier unique ou demandez une approbation explicite pour le remplacement. Utilisez la date de génération uniquement comme date de documentation, pas une date de déploiement fabriquée. La note de version est une version proposée jusqu'à ce que le déploiement soit vérifié.

Après la sauvegarde, relisez le fichier et validez : direction de la branche et identités des commits, modifications commerciales/techniques, compatibilité, vérification, traçabilité, rollback et absence de résumé persan. Ne mettez pas en staging ou ne commitez pas automatiquement la note de version sauf si demandé. Signalez le chemin relatif sauvegardé.

4. Résumé persan dans le chat (obligatoire)

Uniquement après une sauvegarde et une validation réussies, présentez un bref résumé de type titres en persan dans la réponse finale de l'agent. Concentrez-vous sur les résultats compréhensibles par le métier, les risques significatifs, les actions consommateurs/déploiement requises et l'état de préparation/les inconnues. Généralement 3 à 7 puces courtes, sans détails d'implémentation de bas niveau sauf si nécessaire. Exemple de format :

خلاصه برای ارائه به بیزینس (فقط در پاسخ Agent، خارج از فایل):
- بهبود فرآیند ...
- تغییر در رفتار ...
- نیاز به هماهنگی با ...
- وضعیت اعتبارسنجی: ...
- ریسک و برنامه بازگشت: ...

Incluez uniquement les déclarations établies lors de l'examen. Ne sauvegardez ce résumé dans aucun fichier, journal, message de commit ou annexe de note de version. Si l'écriture échoue, n'affirmez pas que la note de version a été enregistrée ; expliquez l'obstacle et, si utile, fournissez un résumé provisoire clairement marqué comme provisoire.

Critères de qualité

• Basez chaque modification et affirmation sur le diff inspecté, les tests, l'historique Git ou le contexte de version explicitement fourni ; distinguez les faits vérifiés des inférences.
• N'imprimez pas de secrets, jetons, mots de passe, données client privées ou informations d'identification brutes trouvés dans les diffs. Masquez les exemples.
• N'assimilez pas le code commité à une fonctionnalité déployée, et n'assimilez pas un test non exécuté à un test réussi.
• Lorsqu'une branche inclut des modifications non liées, documentez le périmètre et le risque plutôt que de supprimer silencieusement des modifications importantes.
• Utilisez Aucun identifié explicite uniquement après vérification ; sinon, utilisez Inconnu / Non vérifié.
• N'exécutez jamais de migrations, ne manipulez pas de données de production et n'effectuez pas de rollback dans le cadre de leur documentation.