AWR est une plateforme open source de livraison de projets pour les humains et l'IA. Elle relie objectifs, flux de travaux, dépendances, contexte et acceptation au sein d'un même processus de livraison de projet, afin qu'un projet puisse passer d'un objectif convenu à une livraison vérifiée — même lorsque le travail est réparti entre plusieurs agents, sessions et collaborateurs.
AWR est conçu pour deux situations qui partagent le même problème sous-jacent :
- Une personne qui coordonne plusieurs agents sur un projet complexe.
- Une équipe qui livre un projet commun, à commencer par des projets logiciels complexes.
Dans les deux cas, les humains fixent le cap et examinent les résultats ; les agents font le travail. AWR relie leur travail au même état de projet via son CLI et son service MCP.
Le problème que résout AWR
Quand vous travaillez avec des agents de codage IA, la connaissance du projet vit généralement dans la conversation privée de l'agent. Quand la session se termine, que le modèle change, ou qu'une autre personne ou un autre agent reprend le travail, ce contexte est perdu. Les efforts parallèles dérivent les uns des autres, et « terminé » signifie ce que le dernier agent a bien voulu dire.
AWR est conçu autour de ce qui devrait être vrai à la place :
- Changer de session, de modèle ou de collaborateur préserve le projet. Les objectifs, les contraintes et la progression vérifiée survivent à la passation. Un successeur reçoit le contexte requis de la tâche courante et son point de contrôle, de sorte que le projet peut continuer à travers les sessions et les agents.
- Le travail parallèle a une propriété claire et des passations claires. Des flux de travaux indépendants (par exemple frontend, backend et tests) conservent leurs propres tâches, leur contexte et leur propriété tout en partageant les contraintes du projet.
- « Terminé » est vérifiable. Les déclarations d'achèvement sont reliées à des preuves liées à une version. L'implémentation, la vérification, la fusion et la publication sont suivies comme des faits distincts, et non fusionnées en une seule déclaration.
- L'effort est visible. À chaque étape, vous pouvez dire ce qui est prêt, ce qui est en attente, ce qui a été vérifié et où l'effort est allé.
En résumé : AWR préserve la continuité du projet à travers des fenêtres de contexte finies. La fenêtre de contexte d'un agent est limitée, et la compaction (quand un hôte raccourcit la conversation pour la faire tenir) est l'affaire de l'hôte — les points de contrôle d'AWR portent à la place les faits de projet enregistrés.
Comment ça fonctionne : vos fichiers restent la source de vérité
L'architecture d'AWR comporte trois parties :
- Vos fichiers portent l'intention. Des fichiers Markdown et YAML dans votre projet décrivent les objectifs, les plans, le travail, les contraintes et les décisions. AWR indexe ces sources sans les remplacer silencieusement.
- AWR maintient la continuité. Un état local (un projet SQLite) contient des projections de ces sources, plus les sessions, réservations, points de contrôle et preuves. La compilation de contexte — l'assemblage des objectifs, règles, dépendances et preuves pertinents pour la tâche courante — s'exécute localement et ne fait aucun appel à un modèle. Des contrôles de révision protègent les écritures contre un état obsolète.
- Les humains et les agents font le travail. Le CLI et le service MCP relient les faits du projet à l'hôte que vous utilisez. Les agents apportent leurs propres modèles, outils et conversations ; les changements revus et la progression retournent vers les sources du projet.
Parce que les points de contrôle enregistrés ne portent que des faits enregistrés, ils ne reconstruisent pas l'historique de conversation non enregistré d'un agent — cela reste la responsabilité de l'hôte.
Les composants et leur articulation
Vous interagissez avec AWR par deux points d'entrée, tous deux installés depuis le même paquet :
- Le CLI
awr— initialise un projet, inspecte l'état et pilote le processus de session explicite : réserver une unité de travail, obtenir son contexte ciblé et enregistrer un point de contrôle avant de s'arrêter. Tout agent capable d'exécuter des commandes shell peut l'utiliser. - Le service MCP
awr-mcp— expose le même état de projet sous forme d'outils MCP (MCP, le Model Context Protocol, est la manière dont les clients IA appellent des outils externes). Un client se connecte soit à un projet unique via stdio, soit à un service MCP HTTP partagé qui sert plusieurs clients et projets.
Au-delà de cela, AWR prend en charge l'agent avec lequel vous travaillez déjà. Les intégrations se présentent en couches :
- Contrat générique (par défaut, entièrement pris en charge). Tout hôte capable d'exécuter un CLI ou de parler MCP utilise le même état de projet via le processus de session partagé. Cela inclut Claude Code, Cursor, Windsurf et des hôtes similaires — aucun installateur spécial n'est nécessaire.
- Notes par hôte. Pour certains hôtes (Cursor, Kimi Code, Grok Build), AWR documente les chemins exacts de fusion de configuration et les options de session natives, vérifiés contre une version datée de l'hôte. Ces notes n'ajoutent aucune fonctionnalité d'exécution.
- Adaptateur de cycle de vie optionnel. Lorsque les hooks de cycle de vie natifs d'un hôte sont stables, un adaptateur peut déclencher les points de contrôle AWR à partir des événements de l'hôte. Aujourd'hui, cela existe pour Codex. Un adaptateur ne transforme jamais AWR en moteur d'exécution de cet hôte.
Pour une personne qui coordonne plusieurs agents, la même discipline de dépendances, de revue et de comptabilisation s'applique que pour une équipe plus grande — c'est un seul modèle de projet, pas deux produits.
Ce qu'AWR N'est PAS
AWR est délibérément circonscrit. C'est un moteur de travail indépendant de l'hôte, et sa frontière produit est le contrat CLI/MCP partagé — pas un éditeur ou un agent en particulier.
- AWR n'est pas un agent IA. Il ne sélectionne, ne démarre ni ne configure un agent de codage. Les agents apportent leurs propres modèles, outils et conversations ; les chaînes de fournisseur et de modèle stockées par AWR ne sont que des étiquettes d'affichage.
- AWR n'est ni un éditeur, ni une interface de chat, ni un fournisseur de modèles. L'interface de l'agent, les identifiants de conversation natifs et la compaction appartiennent à l'hôte.
- AWR ne remplace pas vos fichiers de projet. Les sources Markdown/YAML restent faisant autorité ; l'état local d'AWR est un index plus des enregistrements de continuité, et il ne doit pas remplacer silencieusement vos sources.
- AWR n'est pas lié à un seul transport. Que MCP fonctionne via stdio, HTTP ou soit absent relève du choix de l'hôte ; si un hôte n'a pas de hooks natifs, vous enregistrez vos points de contrôle manuellement via le CLI.
- AWR n'isole pas physiquement les flux de travaux. L'isolation des flux de travaux couvre l'état du projet et les opérations prises en charge ; l'isolation physique des processus dépend de l'hôte d'exécution.
Périmètre actuel : version publiée et développement
AWR est honnête sur ce qui est livré par rapport à ce qui est en construction. Les paquets CLI/MCP publiés en version 0.5.1 fournissent :
- Des objectifs et des tâches adossés aux sources, avec navigation des dépendances
- Une compilation de contexte ciblée pour la tâche courante
- Des réservations et des points de contrôle de session
- Des preuves liées à une version
- Un service MCP HTTP partagé pour plusieurs clients et projets
- L'échange de fichiers Personal Workspace
- Une base de flux de travaux personnel : propriété explicite des sources, attribution des sessions et contexte limité dans un projet SQLite local
Cette version ne fournit pas de service Team authentifié ni d'isolation complète multi-clients. Encore en développement sur main :
- L'adoption versionnée de livraisons entre flux de travaux (lier le travail en aval à un artefact accepté et à une version de contrat ; revérifier les consommateurs quand il change)
- La collaboration d'équipe et la revue de livraison (relecteur explicite et enregistrements d'approbation)
- La comptabilisation de l'utilisation, du temps et des ETA des flux de travaux
Les notes de version de chaque version publiée définissent la frontière réelle du paquet.
Ce que cela signifie pour vous
Si vous évaluez AWR : vous gardez votre agent actuel et vos fichiers actuels. Vous initialisez AWR dans votre projet, vous donnez à votre agent un accord de travail, et dès lors chaque session démarre à partir d'objectifs, de règles, de dépendances et de points de contrôle enregistrés plutôt que de zéro. Vous pouvez inspecter la progression à tout moment.
Si vous l'adoptez en équipe : la même base CLI/MCP s'étend vers la livraison et la revue partagées à mesure que ces capacités sont livrées — la version publiée vous donne déjà le cœur mono-utilisateur et multi-agents.
Pour aller plus loin
- Démarrage rapide — installez AWR, connectez un projet et exécutez votre première session.
- Concepts — le modèle de projet en détail : objectifs, flux de travaux, sessions, réservations, points de contrôle et preuves.
- CLI et service MCP — les deux points d'entrée en profondeur.
- Intégrations d'agents — connectez l'agent que vous utilisez déjà.