workflow-fix

Règles

• Pas d'appels API mutants sans confirmation. Les requêtes gh api GET sont autorisées librement. Tout appel utilisant -X POST, -X PUT, -X PATCH ou -X DELETE doit être montré à l'utilisateur et approuvé avant exécution.
• Ne jamais force-push, supprimer de branches ou supprimer de repositories.
• Modifier uniquement les fichiers sous .github/. Ne pas toucher au code applicatif, aux scripts ou à la configuration en dehors des fichiers workflow.
• Afficher un diff et obtenir une confirmation avant chaque commit.
• Tous les PRs doivent être créés en brouillon.
• Signaler l'incertitude. Si une finding est ambiguë ou qu'une correction pourrait casser un workflow, s'arrêter et demander plutôt que de deviner.

Étape 1 : Vérifier les prérequis

Vérifier que bwwl est disponible :

bwwl --version

Si la commande n'est pas trouvée, s'arrêter et informer l'utilisateur que bwwl doit être installé avant de continuer. Ne pas tenter de l'installer.

Étape 2 : Déterminer la portée

Analyser la demande de l'utilisateur pour déterminer ce qu'il faut corriger :

• Fichier ou répertoire unique : Opérer sur le repo actuel uniquement.
• Plusieurs repos (ex. « server, clients, android ») : Opérer sur chaque repo séquentiellement. Demander à l'utilisateur le répertoire de base où ses repos sont clonés. Pour chaque repo, chercher son clone local à <base-dir>/<repo>. Si un clone n'est pas trouvé, informer l'utilisateur et passer ce repo.
• Aucune cible spécifiée : Corriger toutes les findings dans .github/workflows/ du répertoire actuel.

Si l'utilisateur n'a pas exécuté la skill workflow-audit en premier, lancer le linter maintenant pour identifier les findings avant de procéder.

Étape 3 : Pour chaque repo dans la portée

Répéter les étapes 4–7 pour chaque repo. Annoncer le repo en cours de traitement.

Étape 4 : Créer une branche de correction

Créer la branche de correction uniquement s'il y a des findings à corriger :

git checkout -b fix/workflow-linter-findings

Étape 5 : Appliquer les corrections

Consulter la skill bitwarden-workflow-linter-rules pour la bonne correction de chaque règle.

Pour les findings mécaniques : Appliquer toutes les corrections sans demander de confirmation.

Exception — step_pinned : Avant d'appliquer chaque hash pin, suivre la procédure de correction step_pinned de la skill bitwarden-workflow-linter-rules (résoudre le SHA via gh api, afficher le lien de vérification, attendre la confirmation de l'utilisateur).

Pour les findings de jugement : Pour chacun, faire une pause et présenter la finding clairement. Demander à l'utilisateur quelle option il veut (selon la skill bitwarden-workflow-linter-rules), puis appliquer son choix.

Étape 6 : Vérifier les corrections

Relancer le linter pour confirmer que toutes les findings sont résolues :

bwwl lint -f .github/workflows/

S'il reste des erreurs, les analyser et les corriger. Répéter jusqu'à avoir un résultat propre.

Étape 7 : Réviser et créer un PR

Après que toutes les corrections sont appliquées :

1. Afficher un git diff de tous les changements effectués.
2. Demander à l'utilisateur de confirmer qu'il veut procéder avec un PR.
3. Si confirmé :

git add .github/workflows/
git commit -m "Fix workflow linter findings"
gh pr create \
  --title "Fix workflow linter findings" \
  --body "Automated fixes for findings from the Bitwarden workflow linter (bwwl)." \
  --draft

Étape 8 : Résumé

Après le traitement de tous les repos, afficher un tableau récapitulatif :