Automatiser le chemin d’un ticket. Sans ouvrir l’outil aux agents.

1. 01 Synchroniser mes tâches assignées

   Un navigateur piloté par Playwright garde ma session ouverte sur l’outil de gestion de tâches. Le service relit mes tâches assignées, avec leur détail, leurs commentaires, leurs listes à cocher, leur historique, leurs images et leurs catégories, dans une base SQLite sur mon poste. Les passages se planifient, heures creuses comprises.

2. 02 Sceller une observation à chaque passage

   Chaque passage scelle une observation qui ne bougera plus. On en épingle une, on lit l’écart entre deux. Une empreinte évite de relire en détail ce qui n’a pas bougé : un passage sans changement côté source ne fait aucune requête d’enrichissement ; sinon, deux par tâche.

3. 03 Lire, chercher et voir où tout en est

   La liste des tâches se filtre avec des préréglages et se cherche en plein texte (FTS5 de SQLite). Le tableau de bord agrège par projet et par statut, les métriques suivent le poids des données locales et la tendance de l’arriéré, et la Galaxie met le tout en scène.

4. 04 Préparer : un agent lit chaque nouvelle tâche

   Après un passage, un agent lit chaque nouvelle tâche, explore les dépôts en lecture et rend une compréhension courte : le dépôt et le worktree où la faire. Je la retiens, je l’écarte, je la précise ou je pose une question ; une précision relance l’agent.

5. 05 Réaliser : un agent ouvre la pull request

   Confiée à Relais, une tâche retenue part chez le seul agent qui écrit : il travaille dans un worktree, sur une branche cible choisie parmi celles du dépôt, et ouvre une pull request par dépôt touché. Le service relit l’état des pull requests chez GitHub. Une réalisation se reprend, se relance ou se programme, par exemple pour le soir même.

6. 06 Planifier une tâche complexe

   On y joint des ressources, du texte ou un PDF. Un agent propose une résolution, que je relis pas à pas ; elle s’exécute ensuite par Relais, ou part dans Sillage, où l’assistant compose le graphe d’agents au périmètre du plan.

7. 07 Enchaîner les gestes par des règles aperçu

   Des règles « quand…, alors… », écrites et activées dans les réglages, font les gestes à la place d’un clic. Le moteur passe une fois par minute, fait une étape par tâche, et un quota quotidien borne les lancements d’agent. Aucune règle n’est livrée.

   quand  lecture-proposee      alors  retenir
   quand  lecture-retenue       alors  confier-a-relais
   quand  realisation-reussie   alors  passer-en-relecture

8. 08 Une API locale en lecture seule, et des notifications aperçu

   Un script ou un tableau de bord lit les tâches par une API HTTP locale, ouverte par une clé révocable : des lectures seulement, et toute autre méthode refusée avant même le routage. Des notifications macOS disent ce que les agents ont fini.

   GET /api/public/v1/tasks
   GET /api/public/v1/tasks/overview
   GET /api/public/v1/status
   Authorization: Bearer <clé révocable>
   
   POST, PUT, DELETE…  → 405, avant le routage

Architecture

1. 01 Un service .NET 10, cinq projets, une interface Angular aperçu

   Un service ASP.NET Core en API minimale tient la synchronisation, les agents et l’interface ; la synchronisation, le cœur métier, le serveur MCP et les tests vivent chacun dans leur projet. Les données : SQLite par EF Core, recherche plein texte FTS5, et des magasins JSON écrits d’un bloc pour ce qui ne doit jamais se perdre. L’interface Angular 22 suit le travail des agents en direct par SignalR.

   service .NET 10
   ├▶ navigateur piloté (Playwright)
   │  └▶ outil de gestion de tâches
   │     lit, et n’écrit que le statut
   ├▶ SQLite (EF Core, FTS5)
   ├▶ magasins JSON
   ├▶ interface Angular 22 (SignalR)
   └▶ par HTTP, Relais (agents),
      Sillage (plans), gh (PR)
   serveur MCP, processus à part
   └▶ base en lecture seule ▶ agent IA

2. 02 N’écouter que la machine, par le code aperçu

   L’adresse d’écoute n’est pas un réglage : un appel explicite à la boucle locale l’emporte sur toute variable d’environnement, et seul le port se change. Le service tourne en natif sur macOS, lancé par launchd, sans conteneur ni exposition.

   // L’adresse est dans le code ; seul le port se règle
   builder.WebHost.ConfigureKestrel(serveur =>
       serveur.Listen(IPAddress.Loopback, port)); // l’emporte sur --urls et ASPNETCORE_URLS

3. 03 Un serveur MCP de treize outils, dix en lecture seule aperçu

   Le serveur MCP parle à l’agent sur l’entrée et la sortie standard. Sa source se choisit à son lancement : le cache vivant, une observation scellée ou un espace de travail, et chaque réponse dit d’où elle vient. Trois outils seulement ne sont pas en lecture seule : deux déposent une analyse, le troisième demande un passage au service, qui seul lit la source.

   lecture   list_my_tasks · get_task · search_tasks · tasks_overview
             get_task_attachment · list_snapshots · list_workspaces
             sync_status · analysis_progress · get_group_plan
   dépôt     submit_task_understanding · submit_task_fix_plan
   passage   trigger_sync

Décisions

1. 04 Des lectures, et une seule écriture vers l’outil source aperçu

   Contrainte

   L’outil garde une session complète sur une application en production.

   Choix

   Chaque appel vers l’outil source passe par une liste blanche : des lectures, plus une seule écriture, le statut d’une tâche, relu dans la source juste avant.

   Effet

   Un défaut de l’outil ne peut modifier qu’un statut.

   GET    toute lecture                 → admis
   PATCH  /…/tâches/{uuid}/statut       → admis, après relecture du statut
   tout le reste                        → refusé, avant le réseau

2. 05 Le serveur MCP n’a pas de plume aperçu

   Contrainte

   Un agent doit lire les tâches sans appeler lui-même la source ni écrire dans la copie locale.

   Choix

   Le serveur MCP tourne dans un processus à part, ouvre la base en lecture seule et ne connaît ni la synchronisation ni le navigateur.

   Effet

   Un test d’architecture le vérifie à chaque passage des tests : la règle n’est pas qu’un commentaire.

   // Le test d’architecture, en substance
   var fermeture = AssembliesTransitives(serveurMcp);
   Assert.DoesNotContain("Microsoft.Playwright", fermeture);
   Assert.DoesNotContain(clientDeLaSource, fermeture);
   // et aucune source du serveur ne nomme une écriture :
   // connexion en écriture, journal des enchaînements, SaveAsync, UpdateAsync

3. 06 Une source figée au lancement, rien qui se perde

   Contrainte

   Un agent doit pouvoir raisonner sur un état figé, et aucune de mes décisions ne doit se perdre.

   Choix

   Chaque passage scelle une observation, et le serveur MCP fixe sa source à son lancement, le cache vivant ou une observation scellée, jamais en cours de session ; chaque réponse dit d’où elle vient. Un fichier de décisions illisible reste intact, en lecture seule, au lieu d’être lu vide puis écrasé.

   Effet

   Sur une observation, deux appels identiques rendent la même réponse, et une décision prise ne se perd pas.

4. 07 Des règles qui ont les gardes d’un clic

   Contrainte

   Enchaîner les gestes d’un ticket sans qu’une règle fasse ce que je n’aurais pas validé.

   Choix

   Les déclencheurs et les actions vivent dans le code, les règles dans mes réglages. Une règle a les gardes d’un clic, relit la tâche dans la source et la pull request chez GitHub, cède au geste qui la contredit et ne défait jamais rien. Son journal s’écrit avant d’agir : une action à l’issue inconnue n’est jamais rejouée à l’aveugle.

   Effet

   Sans règle, l’outil se comporte comme avant, et un test le vérifie.

Garde-fous, tests et limites

1. 08 Les agents qui lisent n’ont que Read, Glob et Grep

   Cinq métiers d’agent (préparer, répartir, rédiger, planifier, réaliser) partagent un seul plafond de sessions simultanées. Ceux qui lisent tournent dans une session Relais en lecture seule, relue après coup ; un seul métier écrit, et seulement dans un worktree, jamais dans le dépôt principal.

2. 09 Plus de deux mille cas de test déclarés

   1 340 cas de test côté serveur (xUnit v3) et 718 côté interface (Vitest), comptés dans le code à la révision lue, sans les exécuter. Il n’y a pas d’intégration continue : les tests tournent sur mon poste.

3. 10 Ce qui n’est pas encore là

   Le « dossier de tâche » unifié, écrit dans les plans, n’a livré que son premier lot. L’outil ne tourne que sur macOS, n’est ni déployé ni partagé, et son interface attend une refonte graphique.