JantonioFC/skillsbank

/tc — Gestionnaire de Changements Techniques

Envoyer une commande TC (Changement Technique). Arguments : $ARGUMENTS.

Si $ARGUMENTS est vide, afficher ce menu et s'arrêter :

/tc init                       Initialiser le suivi TC dans ce projet
/tc create <nom>               Créer un nouvel enregistrement TC
/tc update <tc-id> [...]       Mettre à jour les champs, statut, fichiers, transfert
/tc status [tc-id]             Afficher un TC ou le résumé du registre
/tc resume <tc-id>             Reprendre un TC depuis une session précédente
/tc close <tc-id>              Transitionner un TC vers 'déployé'
/tc export                     Ré-évaluer les artefacts dérivés
/tc dashboard                  Afficher le résumé du registre

Sinon, analyser $ARGUMENTS comme <sous-commande> <reste> et dispatcher vers le protocole correspondant ci-dessous. Tous les scripts se trouvent dans engineering/tc-tracker/scripts/.

Sous-commandes

init

1. Exécuter :

   python3 engineering/skills/tc-tracker/scripts/tc_init.py --root . --json
   

2. Si le statut est already_initialized, rapporter les statistiques actuelles et s'arrêter.
3. Sinon, rapporter ce qui a été créé et suggérer /tc create <nom> comme prochaine étape.

create <nom>

1. Analyser <nom> comme un slug en kebab-case. S'il manque, demander à l'utilisateur d'en fournir un.
2. Demander à l'utilisateur (une question à la fois) :
   • Titre (5-120 caractères)
   • Portée : feature | bugfix | refactor | infrastructure | documentation | hotfix | enhancement
   • Priorité : critical | high | medium | low (par défaut medium)
   • Résumé (10+ caractères)
   • Motivation
3. Exécuter :

   python3 engineering/skills/tc-tracker/scripts/tc_create.py --root . \
     --name "<slug>" --title "<titre>" --scope <portée> --priority <priorité> \
     --summary "<résumé>" --motivation "<motivation>" --json
   

4. Rapporter le nouvel ID TC et le chemin vers l'enregistrement.

update <tc-id> [intention]

1. Si <tc-id> est manquant, lister les TC actifs (statut in_progress ou blocked) via tc_status.py --all et demander lequel.
2. Déterminer l'intention de l'utilisateur à partir du langage naturel :
   • Changement de statut → --set-status <état> avec --reason "<pourquoi>"
   • Ajouter des fichiers → un ou plusieurs --add-file chemin:action
   • Ajouter un test → --add-test "<titre>" --test-procedure "<étape>" --test-expected "<résultat>"
   • Mettre à jour le transfert → toute combinaison de --handoff-progress, --handoff-next, --handoff-blocker, --handoff-context
   • Ajouter une note → --note "<texte>"
   • Ajouter un tag → --tag <tag>
3. Exécuter :

   python3 engineering/skills/tc-tracker/scripts/tc_update.py --root . --tc-id <tc-id> [drapeaux] --json
   

4. Si le code de sortie est non nul, remonter l'erreur textuellement. La machine à états et le validateur rejetteront les mouvements invalides — ne pas réessayer aveuglément.

status [tc-id]

• Si <tc-id> est fourni :

  python3 engineering/skills/tc-tracker/scripts/tc_status.py --root . --tc-id <tc-id>
  

• Sinon :

  python3 engineering/skills/tc-tracker/scripts/tc_status.py --root . --all
  

resume <tc-id>

1. Exécuter :

   python3 engineering/skills/tc-tracker/scripts/tc_status.py --root . --tc-id <tc-id> --json
   

2. Afficher le bloc de transfert de manière prominente : progress_summary, next_steps (numérotés), blockers, key_context.
3. Demander : « Reprendre et commencer par l'étape suivante 1 ? (o/n) »
4. Si oui, exécuter une mise à jour pour enregistrer la reprise :

   python3 engineering/skills/tc-tracker/scripts/tc_update.py --root . --tc-id <tc-id> \
     --note "Session reprise" --reason "transfert de session"
   

5. Commencer à exécuter le premier élément de next_steps. NE PAS redériver le contexte — faire confiance au transfert.

close <tc-id>

1. Lire l'enregistrement via tc_status.py --tc-id <tc-id> --json.
2. Vérifier que le statut actuel est tested. Sinon, refuser et indiquer à l'utilisateur quelles transitions sont encore nécessaires.
3. Vérifier test_cases : avertir si l'un d'eux est pending, fail ou blocked.
4. Demander à l'utilisateur :
   • « Qui approuve ? (votre nom, ou 'self') »
   • « Notes d'approbation (optionnel) : »
   • « État de la couverture de test : none / partial / full »
5. Exécuter :

   python3 engineering/skills/tc-tracker/scripts/tc_update.py --root . --tc-id <tc-id> \
     --set-status deployed --reason "Approuvé par <approbateur>" --note "Approbation : <approbateur> — <notes>"
   

   Puis éditer directement le bloc approval via une mise à jour ultérieure si la version du script le supporte ; sinon, instruire l'utilisateur d'enregistrer l'approbation dans notes.
6. Rapporter : « TC-NNN fermé et déployé. »

export

Il n'y a pas d'export HTML automatique dans cette compétence. Re-valider tout à la place :

1. Lire le registre.
2. Pour chaque enregistrement, exécuter :

   python3 engineering/skills/tc-tracker/scripts/tc_validator.py --record <chemin> --json
   

3. Exécuter :

   python3 engineering/skills/tc-tracker/scripts/tc_validator.py --registry docs/TC/tc_registry.json --json
   

4. Rapporter : nombre total d'enregistrements validés, erreurs éventuelles, chemins vers les éléments invalides.

dashboard

Exécuter le résumé de tous les enregistrements :

python3 engineering/skills/tc-tracker/scripts/tc_status.py --root . --all

Règles Impératives

1. Ne jamais éditer tc_record.json à la main. Toujours utiliser tc_update.py pour que l'historique des révisions soit ajouté et que la validation soit exécutée.
2. Ne jamais contourner la machine à états. Avancer à travers les états même si cela semble redondant.
3. Ne jamais supprimer un TC. L'historique est en mode ajout seul — ajouter une révision finale et la taguer [CANCELLED].
4. Tâche de fond administrative. En cours de tâche, lancer un sous-agent en arrière-plan pour mettre à jour le TC. Ne pas interrompre le codage pour de la paperasse.
5. Valider avant de rapporter un succès. Si un script se termine avec un code non nul, remonter l'erreur et s'arrêter.

Compétences Connexes

• engineering/tc-tracker — SKILL.md complet avec référence de schéma, diagrammes de cycle de vie et format de transfert.
• engineering/changelog-generator — À associer au tracker TC : les TC pour la piste d'audit par changement, le changelog pour les notes de version destinées aux utilisateurs.
• engineering/tech-debt-tracker — Pour suivre la dette technique à long terme plutôt que des changements de code discrets.