auditing-workflow-conventions

Propriété

Cette skill couvre uniquement ce que bwwl ne peut pas vérifier. Pour tout ce que le linter applique, invoquez Skill(bitwarden-devops-engineer:bitwarden-workflow-linter-rules) — cette skill est la source de vérité pour toutes les règles bwwl, y compris leurs déclencheurs et procédures de correction. Ne signalez pas ici un résultat qui duplique une règle du linter.

name_capitalized vérifie uniquement que le premier caractère est en majuscule. Get Package Version passe le linter et dévie toujours de la norme Sentence case ci-dessous. Les deux sont complémentaires.

Standards

Ces trois IDs sont définis par cette skill, pas par bwwl. Étiquetez-les comme des résultats de convention, jamais comme des résultats de linter.

job-id-kebab-case

• S'applique à : chaque clé sous jobs:.
• Standard : kebab-case.
• Conforme : build, test, lint, publish, upload, build-artifacts, deploy-service, check-permissions, calculate-version.
• Dévie : bump_version, cut_branch, deployService, DeployService, BUILD_ARTIFACTS.
• Signalez quand : un ID de job utilise snake_case, camelCase, PascalCase, ou UPPER_SNAKE. Les IDs à un seul mot sont conformes et ne sont jamais un résultat.

Un ID de job est un identifiant, pas une étiquette. Avant de proposer un renommage, résolvez chaque référence :

1. needs: dans le même fichier, sous forme scalaire et liste.
2. Expressions ${{ needs.<job-id>.* }} n'importe où dans le fichier.
3. jobs.<job-id>.outputs au niveau workflow d'un workflow réutilisable.

Les noms de check-run dérivent du name: d'un job, pas de son ID, donc un renommage d'ID de job n'affecte pas les vérifications de statut requises — à moins que le job n'ait pas de name:, auquel cas l'ID devient le nom de check et un renommage peut casser un ruleset qui le requiert. name_exists signale déjà un job sans name:; si vous en rencontrez un, corrigez d'abord cela, puis renommez.

step-name-sentence-case

• S'applique à : chaque name: sous steps:.
• Standard : Sentence case avec un verbe impératif initial — capitalisez le premier mot plus les noms propres et acronymes uniquement. Les noms propres et acronymes gardent leur propre casse : Azure, Docker, Node, .NET, SDK, RC, MSSQL.
• Conforme : Check out repo, Set up .NET, Print environment, Log in to Azure, Generate Docker image tag, Install Node dependencies, Run tests, Push changes, Upload SDK artifacts.
• Dévie : Delete Release Branch, Get Package Version, Build & Package Binaries, Upload SDK Artifacts, Dependency install.
• Signalez quand : un nom d'étape utilise Title Case, ALL CAPS, ou omet le verbe impératif initial.

Les noms d'étape sont d'affichage uniquement — ils ne sont pas adressables depuis des expressions, puisque steps.<id> résout l'id: de l'étape. En modifier un est sûr et ne nécessite aucun balayage de référence. C'est le seul standard ici qu'un agent peut appliquer directement lors d'une édition.

workflow-file-naming

• S'applique à : chaque fichier dans .github/workflows/.
• Standard : kebab-case.yml, avec un préfixe _ si et seulement si le workflow est exclusivement réutilisable. L'extension est toujours .yml, jamais .yaml. Le préfixe et la casse sont indépendants — _deploy_service.yml est correctement préfixé et incorrectement cassé; la forme conforme est _deploy-service.yml.
• Conforme : build-app.yml, scan-dependencies.yml, _version.yml, _deploy-service.yml.
• Dévie : build_only.yml, API_tests.yml, Integration_Tests.yml, deploy-service.yaml, _deploy_service.yml.
• Signalez quand : le nom n'est pas kebab-case, l'extension est .yaml, un workflow exclusivement réutilisable manque du préfixe _, ou un fichier avec préfixe _ n'est pas exclusivement réutilisable.

Exclusivement réutilisable signifie que le bloc on: ne déclare rien en dehors de workflow_call et workflow_dispatch. workflow_dispatch est une échappatoire pour test manuel et opérations, pas un point d'entrée autonome, donc il ne disqualifie pas le préfixe.

Tout autre déclencheur — push, pull_request, pull_request_target, schedule, release, workflow_run, repository_dispatch — rend le workflow à double usage : il s'exécute seul et est appelable par d'autres. Les workflows à double usage ne prennent pas de préfixe. C'est une conception délibérée et commune, pas une déviation. La présence seule de workflow_call ne justifie jamais un résultat de préfixe; vérifiez l'ensemble complet des déclencheurs d'abord.

Renommer un fichier workflow est destructif. Le nom de fichier est l'identifiant public du workflow — il adresse le workflow de l'extérieur du repo, et chaque référence externe casse silencieusement au renommage. Ne renommez jamais un workflow dans le cadre d'un audit ou d'une édition non liée. Signalez-le et laissez le propriétaire du repo planifier.

Si un renommage est explicitement demandé, établissez d'abord l'ensemble des références connu, puis utilisez git mv :

1. Appelants in-repo — grep le repo pour le nom de fichier. Attrape uses: ./.github/workflows/<file> et tout script local qui le nomme.
2. Références à l'échelle de l'org — gh search code "<file>" --owner bitwarden. Attrape uses: bitwarden/<repo>/.github/workflows/<file>@<ref> dans d'autres repos plus tout script ou tooling qui nomme le fichier. Un grep local ne trouvera pas ceux-ci.

Cela établit un minimum, pas un maximum. Rien en dehors du code indexé de l'org n'est découvrable : l'automatisation dans d'autres systèmes, les liens de runbook et documentation, et tout ce qui invoque le workflow par nom de fichier via l'API dispatch. Signalez ce que les deux recherches ont trouvé et énoncez clairement que l'ensemble peut être incomplet — l'inconnu résiduel est exactement pourquoi le renommage appartient au propriétaire du repo et non à un audit.

L'historique d'exécution est indexé par le chemin du fichier et se détache toujours au renommage. Les exécutions antérieures demeurent mais ne se groupent plus sous le workflow renommé. C'est inévitable — exposez-le, ne tentez pas de le préserver.

Conseil : Noms d'étape canoniques

Formulation préférée, pas un standard. Une phraséologie cohérente rend les étapes recherchables dans les repos, mais un nom d'étape en dehors de ce tableau n'est jamais un résultat — la plupart des noms d'étape sont légitimement uniques à leur workflow.

Quand un nom d'étape dévie à la fois de Sentence case et apparaît dans ce tableau (Azure Login), la casse est le résultat et la forme canonique est la correction suggérée.

Appliquer ces standards

• Une déviation est un signal, pas un verdict. Ces standards décrivent l'état cible; ils n'autorisent pas un renommage. Les vrais workflows portent des exceptions délibérées — un ID de job correspondant à un tooling externe, un nom de fichier référencé par un système en dehors de ce repo, un nom d'étape qui lit mieux que la phrase canonique. Exposez la déviation avec ce qu'une forme conforme serait, et laissez le propriétaire décider. Ne traitez pas le silence comme un consentement.
• Seuls les noms d'étape sont sûrs à changer sur place. Les IDs de job et les noms de fichier requièrent d'abord un balayage de référence. Ne fusionnez jamais un renommage de l'un dans un changement non lié.
• Cette skill n'édite pas. Son allowed-tools est en lecture seule — suffisant pour inspecter les workflows et exécuter le balayage de référence à l'échelle de l'org, rien de plus.
• Les renommages sont tout ou rien. Un renommage partiellement appliqué est pire que la déviation d'origine — il produit un workflow cassé au lieu d'un inconsistant. Si l'ensemble complet des références ne peut pas être résolu, ne commencez pas.
• Ne doublez pas les résultats. Si un élément est déjà couvert par name_capitalized, underscore_outputs, ou job_environment_prefix, le résultat appartient au linter. Voir le tableau de propriété.
• Signalez les lacunes honnêtement. Les inputs, la casse des variables bash, et les noms d'artefact n'ont pas de standard appliqué. Dites-le; n'affirmez pas une convention que cette skill ne définit pas.