tjrtm/the-team-loop

The Team Loop

Utilisez cette compétence lorsque deux équipes ou agents coopérants travaillent dans un même dépôt. Remplacez Team A et Team B par les noms configurés. Le Propriétaire est un humain et constitue l'autorité pour les décisions de priorité, fusion, déploiement, gel et politique.

Intégration : configuration en cinq minutes

1. Copiez cette compétence dans le dépôt cible et installez l'adaptateur pour l'outil d'agent actif.
2. Copiez templates/team-loop.yml vers .team-loop.yml ; définissez les noms d'équipe et gate_command.
3. Exécutez scripts/setup-labels.sh --repo OWNER/REPO.
4. Demandez au Propriétaire de créer un ticket de coordination épinglé et un ticket étiqueté ready.
5. Chaque équipe lit ce fichier, revendique au plus un élément et utilise l'en-tête de statut configuré.

Rôles

• Propriétaire : crée ou promeut du travail prêt ; publie des décisions Owner: directes dans ses propres mots ; autorise les fusions et les déploiements, sauf dans le cadre d'un mandat écrit avec périmètre et heure de fin UTC.
• Équipe A / Équipe B : construit, teste, révise, revendique, transfère et fait rapport. Utilisez des identités GitHub séparées si disponibles.
• Relecteur (optionnel) : effectue une relecture en contexte frais. Exigez-le pour les chemins ou catégories de risque configurés.

États de la boucle

backlog -> ready -> in-progress -> blocked ou needs-owner -> PR d'implémentation -> ready-for-owner -> fusionné -> deployed.

• backlog n'est pas réclamable. Regroupez chaque semaine le travail à faible sévérité du backlog pour promotion par le propriétaire.
• ready autorise l'implémentation, les tests et l'ouverture d'une PR. Il n'autorise jamais la fusion ou le déploiement.
• En fermant un ticket, retirez les étiquettes d'état obsolètes telles que in-progress, ready, blocked et needs-owner.

Protocole de réclamation

1. Relisez les étiquettes immédiatement avant d'agir. Ne réclamez pas de travail in-progress, blocked ou non ready.
2. Exécutez scripts/claim.sh --repo OWNER/REPO --issue N --team "Team A" --plan "court plan".
3. Le script ajoute in-progress et une étiquette d'équipe, publie la réclamation, puis revérifie l'état. En cas de perte de course, il recule.
4. Gardez le travail en cours à ou en dessous de wip_limit par équipe. Terminez, transférez ou bloquez explicitement un élément avant d'en réclamer un autre.
5. Pour team:any, le commentaire de réclamation valide le plus ancien gagne ; l'autre équipe recule. Ne résolvez pas une égalité par une implémentation en double.

Commentaires et communication

Chaque commentaire d'équipe commence sur sa première ligne par :

Status: <état> | Team: <équipe configurée> | <contexte court>

Postez uniquement une réclamation avec plan, verdict de relecture, résultat de passerelle, transfert, question, escalade vers le propriétaire, accord ou rapport de version. Ne postez pas de commentaires de cérémonie tels que démarré, en file d'attente, encore en attente, réarmé ou autres. Limitez les commentaires ordinaires à cinq lignes courtes ; placez les preuves dans la description de la PR ou dans des détails réduits.

Seul le Propriétaire écrit des décisions Owner:. Les équipes doivent lier ou demander un commentaire direct du propriétaire, jamais relayer une décision comme autorité.

Étiquettes et routage

Utilisez les étiquettes dans reference/labels.md. Un ticket prêt non assigné revient par défaut à l'Équipe A sauf indication contraire de la configuration. team:any permet aux deux équipes de réclamer. En période d'inactivité, aidez l'autre équipe dans cet ordre : relectures demandées, préparation ou rebasage de train, puis lots hebdomadaires du backlog. Ne menez pas de chasse aux bugs ouverte sans demande du Propriétaire.

Relecture, train, passerelle, certificat

1. Chaque PR exécute des vérifications légères et ciblées et reçoit le niveau de relecture requis par son risque.

2. Un relecteur étiquette les PR complètes ready-for-owner.

3. L'exécuteur de train rassemble les PR relues disponibles à ce moment. Il exécute :

   scripts/train.sh --repo OWNER/REPO --name train-YYYYMMDD-N PR_NUMBER...
   

4. train.sh ajoute train-running à chaque PR incluse, enregistre la base et les têtes, effectue un écran de conflit, construit un résultat de fusion temporaire et invoque gate.sh une fois.

5. gate.sh lie le certificat à git rev-parse HEAD^{tree}. Un certificat existant correspondant constitue une preuve réussie sauf si --force est utilisé.

6. Si la base ou une tête de PR change, ou si l'écran/la passerelle échoue, le train est invalide. Retirez ou scindez les PR fautives, puis reconstruisez le train. Ne fusionnez pas de travail non lié pendant que train-running retient le train.

7. Après approbation directe du propriétaire ou mandat actif, exécutez à nouveau train.sh avec --merge --owner-authorization "Owner: ..." pour fusionner les têtes de PR enregistrées dans l'ordre. Il refuse si la base ou une tête a changé, et vérifie l'arbre de la branche protégée après chaque fusion.

Déploiement, gel, retenue et pause

• Déployez uniquement la branche protégée configurée et uniquement avec un certificat d'arbre correspondant, sauf si le Propriétaire fournit une exception enregistrée.
• Produisez un rapport de déploiement pour la version. Étiquetez les PR et tickets livrés deployed ; liez-les au rapport unique sans les dupliquer.
• freeze arrête les nouvelles fusions et déploiements. Traitez les lectures d'étiquettes échouées comme gelées pour les actions irréversibles.
• Une retenue de train bloque les fusions en dehors de ce train jusqu'à sa sortie.
• En pause, arrêtez les réclamations, trains, fusions et déploiements. Le Propriétaire poste une liste de redémarrage qui nomme les éléments autorisés à reprendre. Revérifiez les étiquettes, têtes de PR, base et certificats avant de redémarrer.

Escalade et mandats

Utilisez needs-owner lorsqu'une décision produit, sécurité, juridique, version ou de propriété ambiguë bloque le travail. Indiquez le comportement observé, les options, la recommandation et la date limite si elle existe. Continuez le travail indépendant.

Un mandat doit indiquer son périmètre exact et son expiration UTC, par exemple :

Owner: Team A peut fusionner et déployer les PR de documentation relues 41 et 42 jusqu'au 2026-05-01T18:00:00Z.

Tout ce qui est en dehors de ce périmètre ou après expiration nécessite une décision directe fraîche.

Rétrospective

Au moins une fois par semaine, exécutez scripts/scorecard.sh et discutez des définitions dans reference/metrics.md. Améliorez un goulot d'étranglement mesurable à la fois. Examinez les exécutions de passerelle par PR fusionnée, la latence de réclamation, le temps de cycle, la variation nette de la file d'attente, la taille moyenne de lot, la part certifiée et le taux d'échec des changements.

Lisez reference/rules.md pour les règles normatives numérotées et reference/comment-templates.md avant de poster un statut.