terminal-ops

Terminal Ops

Utilisez ceci lorsque l'utilisateur souhaite une exécution réelle du dépôt : exécuter des commandes, inspecter l'état git, déboguer une CI ou des builds, effectuer une correction ciblée, et signaler exactement ce qui a changé et ce qui a été vérifié.

Ce skill est intentionnellement plus étroit que des conseils de codage généraux. C'est un workflow opérateur pour l'exécution terminale basée sur les preuves.

Pile de compétences

Tirez ces compétences natives ECC dans le workflow si pertinent :

• verification-loop pour les étapes de preuve exactes après les modifications
• tdd-workflow lorsque la correction appropriée nécessite une couverture de régression
• security-review lorsque des secrets, de l'authentification ou des entrées externes sont impliqués
• github-ops lorsque la tâche dépend des exécutions CI, de l'état des PR ou du statut des releases
• knowledge-ops lorsque le résultat vérifié doit être capturé dans le contexte durable du projet

Quand l'utiliser

• l'utilisateur dit "corriger", "déboguer", "exécuter ceci", "vérifier le dépôt" ou "pousser"
• la tâche dépend de la sortie de commande, de l'état git, des résultats de test ou d'une correction locale vérifiée
• la réponse doit distinguer : modifié localement, vérifié localement, commité et poussé

Garde-fous

• inspecter avant de modifier
• rester en lecture seule si l'utilisateur a demandé un audit/examen uniquement
• privilégier les scripts et assistants locaux du dépôt plutôt que des wrappers ad hoc improvisés
• ne pas déclarer corrigé avant que la commande de validation n'ait été réexécutée
• ne pas déclarer poussé sauf si la branche a réellement bougé en amont

Workflow

1. Résoudre la surface de travail

Établir :

• chemin exact du dépôt
• branche
• état du diff local
• mode demandé :
  • inspecter
  • corriger
  • vérifier
  • pousser

2. Lire d'abord la surface défaillante

Avant de modifier quoi que ce soit :

• inspecter l'erreur
• inspecter le fichier ou le test
• inspecter l'état git
• utiliser les logs ou le contexte déjà fournis avant de relire aveuglément

3. Garder la correction ciblée

Résoudre une défaillance dominante à la fois :

• utiliser d'abord la plus petite commande de validation utile
• ne passer à un build/test plus large qu'après avoir traité la défaillance locale
• si une commande échoue toujours avec la même signature, arrêter les reprises larges et réduire le périmètre

4. Signaler l'état d'exécution exact

Utiliser des mots d'état exacts :

• inspecté
• modifié localement
• vérifié localement
• commité
• poussé
• bloqué

Format de sortie

SURFACE
- dépôt
- branche
- mode demandé

PREUVE
- commande / diff / test en échec

ACTION
- ce qui a changé

STATUT
- inspecté / modifié localement / vérifié localement / commité / poussé / bloqué

Pièges

• ne pas travailler à partir de mémoire obsolète lorsque l'état du dépôt en direct peut être lu
• ne pas élargir une correction ciblée en chamboulement à l'échelle du dépôt
• ne pas utiliser de commandes git destructrices
• ne pas ignorer le travail local non lié

Vérification

• la réponse nomme la commande de validation ou le test
• le travail lié à git nomme le chemin du dépôt et la branche
• toute affirmation de poussée inclut la branche cible et le résultat exact