Collaboration en équipe

AWR permet à plusieurs personnes — et aux Agents avec lesquels elles travaillent — de se coordonner sur un projet partagé : chacun voit les mêmes tâches, réserve le travail qu'il effectue, rapporte sa progression au fil de l'eau, et remet le travail terminé à un relecteur indépendant. Vous pilotez tout cela depuis votre conversation Agent habituelle ; vous n'avez pas besoin de copier des identifiants de tâches dans un navigateur.

Disponibilité : cet article décrit le service Team, encore en développement. Il ne fait pas partie du serveur MCP personnel 0.5.0 publié. Les capacités ci-dessous s'appliquent à un projet d'équipe hébergé par votre administrateur de projet, pas à une installation locale personnelle.

Pour les idées sous-jacentes (éléments de travail, contrats, preuves, sessions), lisez d'abord Concepts. Pour la boucle quotidienne en solo, voir Votre flux de travail quotidien.

Le modèle de collaboration en un coup d'œil

Quatre idées portent tout le modèle :

• Flux de travaux et travail partagé. Le projet distant est l'autorité de travail partagée — l'endroit unique où vivent tâches, dépendances, progression et résultats. Votre checkout local ne sert qu'au code et aux tests ; n'initialisez pas un second registre de tâches local pour remplacer le projet distant.
• Réservation. Avant qu'un Agent commence un travail d'exécution, il prend une réservation active sur la tâche, sous sa session. La réservation active d'une autre personne ne doit pas être remplacée, de sorte que deux Agents ne peuvent pas travailler silencieusement sur la même chose.
• Revue. Livraison et acceptation sont des faits distincts. Une personne autorisée et indépendante relit le travail soumis avant qu'il soit accepté. Un second Agent vous appartenant n'est pas un relecteur indépendant.
• Passation. Les sessions sont durables : elles survivent aux reconnexions MCP, portent des points de contrôle et un état de reprise, et peuvent être reprises — par vous après une pause, ou inspectées par un coéquipier — sans perdre le contexte.

Connectez-vous une fois

Demandez à votre administrateur de projet une URL MCP de projet et votre identifiant individuel. Chaque participant utilise son propre identifiant, et les permissions du dépôt restent séparées des permissions AWR — rejoindre le projet AWR ne donne pas accès à Git, et vice versa.

En coulisses, un administrateur autorisé ouvre Members dans Inspector, vous ajoute, choisit votre rôle de projet et vos flux de travaux, et copie une instruction de connexion personnelle à usage unique contenant le point de terminaison et votre identifiant. Vous la recevez par un canal privé. L'administrateur ne peut pas récupérer son texte en clair après avoir effacé le panneau d'émission ; si vous perdez l'identifiant, il peut être explicitement remplacé.

Ajoutez le serveur MCP distant dans n'importe quel client Agent prenant en charge le MCP distant via Streamable HTTP avec authentification Bearer :

Ce sont des paramètres de connexion, pas un format de fichier de configuration ni une commande shell ; chaque client a ses propres paramètres et exigences de version. Si votre client ne prend en charge que le MCP stdio local, cette URL ne peut pas être utilisée directement — utilisez une version de client ou une intégration prenant en charge le transport distant.

Quelques règles de sécurité pour l'identifiant :

• Utilisez les paramètres de secrets pris en charge par votre client ou une saisie Agent privée de confiance.
• Ne placez jamais l'identifiant dans une URL, une conversation partagée ou le dépôt.
• Reconnectez-vous après un changement de configuration, puis ouvrez votre checkout de code local dans l'Agent.

Donnez le résultat attendu à votre Agent

Vous travaillez dans la même conversation que celle que vous utilisez pour développer. Décrivez le résultat et laissez l'Agent coordonner, par exemple :

Utilise le projet AWR Team connecté pour implémenter l'API des tickets. Rafraîchis les tâches courantes et reprends mon travail existant, ou réserve une tâche éligible correspondant à cette demande. Lis le contrat, les dépendances et le dernier point de contrôle avant d'éditer. Garde la progression et les preuves dans AWR, soumets le changement testé sous forme de PR, et demande une revue indépendante.

L'Agent lit le travail partagé, réserve une tâche éligible et maintient le projet à jour pendant qu'il développe localement. S'il rencontre un vrai conflit de permission, de dépendance ou de propriété, il vous le signale au lieu de le contourner.

Ce que l'Agent fait pour vous

L'Agent parle au service Team via deux outils MCP découverts, awr_team_query pour les lectures et awr_team_command pour les écritures. Chaque requête et chaque commande revérifie vos permissions courantes, de sorte qu'un changement de rôle prend effet sans que personne n'édite de configuration locale.

Une session typique se déroule ainsi :

1. Démarrage ou reconnexion. L'Agent interroge capabilities pour confirmer son identité et ses permissions, puis work.next pour reprendre vos propres sessions ou découvrir le travail visible inachevé, en suivant le next_query renvoyé. (Sur les serveurs plus anciens sans work.next, il se rabat sur workstreams.list et les work.list / work.search à périmètre limité.)
2. Préparation. Pour une tâche sélectionnée, work.prepare renvoie le contrat courant, les spécifications requises, les dépendances, l'état de reprise et un hash de contexte — un instantané que l'Agent doit réellement consommer avant d'éditer. work.prepare et work.observe peuvent aussi renvoyer un court élément guidance (sa condition, sa base factuelle, son action suivante et son déclencheur de réévaluation) ; c'est un conseil, pas un droit d'exécution.
3. Réservation. L'Agent inspecte les réservations existantes avec claim.inspect, puis acquiert ou renouvelle une réservation active sous sa session.
4. Exécution. Avec execution.prepare et une réponse execution.start fraîche portant execution_authorized=true, l'Agent peut effectuer une exécution dans le périmètre déclaré. Votre machine exécute le code et les outils — le service n'exécute jamais rien lui-même. Une réservation seule n'est pas une admission d'exécution.
5. Rapport de progression. L'Agent envoie session.checkpoint avec le hash de contexte consommé, l'action suivante, les boucles ouvertes et un court résumé progress, en regroupant les mises à jour quand une phase ou un test se termine, qu'un blocage change, que votre intervention est nécessaire ou que la livraison est prête — pas à chaque appel d'outil. Gardez à l'esprit que les résumés de points de contrôle sont partagés avec les lecteurs de travail autorisés, donc les journaux bruts sensibles n'y ont pas leur place.
6. Fin ou arrêt. execution.report enregistre un résultat terminal avec des preuves liées à une version. Les réservations ne sont libérées et les sessions terminées qu'une fois le travail actif et les résultats inconnus réglés.

Revue et acceptation

Quand le travail est prêt, l'Agent soumet les preuves et demande une revue via delivery.submit_and_request_review ou review.open. Une personne autorisée et indépendante relit la livraison, et une finalisation autorisée suit la politique d'acceptation du projet.

Gardez ces faits distincts : implémentation, vérification, fusion GitHub et acceptation AWR. Fusionner une PR n'est pas la même chose que l'acceptation de la tâche par AWR, et votre propre second Agent ne compte pas comme un relecteur indépendant.

Passation et reprise

La passation fonctionne parce que les sessions et les points de contrôle vivent sur le projet partagé, pas dans l'historique de chat d'une personne :

• Reconnecter MCP ne termine pas une session de travail durable et ne renouvelle pas son bail.
• L'état de reprise et les livraisons enregistrées priment sur les anciennes instructions de points de contrôle, de sorte qu'un Agent de retour se fie à ce qui s'est réellement passé.
• Si une écriture expire, l'Agent inspecte le résultat de la commande originale avant de réessayer à l'identique ; les reçus rejoués sont des faits historiques, pas une permission de réexécuter des effets.
• Si les effets d'exécution sont inconnus (une interruption en pleine tâche), ils exigent une inspection et une réconciliation autorisée. Créer une nouvelle session ne contourne pas cette exigence.

Deux limites pratiques à connaître : AWR ne peut pas réveiller un Agent inactif (le renouvellement du bail utilise la planification de votre hôte, séparée des points de contrôle), et une phase bloquée ou en attente est un rapport — elle ne crée pas d'élément d'attente ni ne renouvelle une réservation d'elle-même.

Inspector : la vue d'espace de travail optionnelle

Inspector est une vue web sur le même projet. Se connecter ou réserver via un site web n'est un prérequis pour rien de ce qui précède — l'Agent reste la surface de coordination. Utilisez Inspector quand vous voulez :

• Inspecter les relations entre tâches, la propriété, la progression et les résultats enregistrés.
• Copier des paramètres MCP neutres vis-à-vis du client et une instruction de projet depuis Connect Agent, ou un brief par tâche (copier du texte ne crée ni session ni réservation).
• En tant qu'administrateur, gérer les membres et les identifiants à périmètre projet dans Members.
• Consulter Activity, qui sépare les enregistrements d'accès authentifiés de l'historique de développement validé. Les membres ordinaires voient leur propre activité autorisée ; les auditeurs de projet peuvent filtrer par membre ou par tâche. Les enregistrements d'audit excluent les valeurs d'identifiants, les conversations et les entrées/sorties arbitraires d'outils, et les métadonnées de requêtes ont une rétention bornée — ce n'est pas une archive de conformité permanente.

Les permissions d'administration et de revue sont appliquées par le service central quel que soit le client utilisé, donc les règles tiennent que l'on travaille via un Agent, Inspector, ou les deux.

Prochaines étapes

• Nouveau sur AWR ? Commencez par Qu'est-ce qu'AWR et le Démarrage rapide.
• Connectez vos propres outils via MCP : MCP.
• Travailler avec des Agents au quotidien : Agents et Votre flux de travail quotidien.
• Quelque chose ne fonctionne pas ? Voir Dépannage.