# Tao V2 : le plan Tâche Tao #38, étape 2. À valider par Tom avant tout code. Il s'appuie sur le diagnostic `docs/tao-v2/audit-diagnostic-2026-09-30.md` ; les numéros de friction y renvoient. Maquettes cliquables : https://paf-studio-code-tom-tao-v2.paf-studio.dev (chat, mobile, détail d'une tâche, terminal ; données d'exemple). ## En bref La V2 garde Tao tel qu'il est (cartes, pilote, plans, main) et change cinq choses : 1. **Une seule ligne « à traiter » par tâche.** Plus de cartes empilées : la ligne se met à jour quand la tâche bouge et disparaît quand il n'y a plus rien à faire. 2. **Le terminal compte.** Un plan validé, un choix donné ou un merge faits dans le terminal ferment ce qui attendait dans Tao. Une phrase libre ne ferme rien toute seule : Tao la lit et range, avec ta phrase comme preuve. 3. **L'état affiché est vérifié sur des faits** toutes les minutes : PR mergée, agent au repos, session fermée. 4. **Tao se met en retrait quand tu parles à un agent**, sans toucher à la main, et l'agent sait à tout moment qui a la main. 5. **Tao range** : il ferme et corrige, en tâche de fond ou à ta demande, avec une preuve à chaque fois. Huit décisions te reviennent, en section 4. Chacune a une proposition par défaut : « ok » les accepte toutes. Le plan a été confronté au code par Apollon (Opus 5.5 xhigh). Ses quatre objections bloquantes sont corrigées ici ; les risques qui restent sont en section 7. ## 1. Ce que tu verras ### 1.1 Le chat ``` ┌ Conversation ─────────────────────────────────────────────┐ │ Toi 11:20 Aujourd'hui, pour Body Expert… │ │ Tao 11:22 Deux lancements proposés. Rien d'autre │ │ ne t'attend. │ │ ✓ 2 propositions : 2 lancées │ │ │ ├ À traiter (2) ────────────────────────────────────────────┤ │ ● Site avocate · PR #10 à relire et merger [ Merger ] ▾│ │ ● Body Expert · l'agent demande un accès [ Répondre ]▾│ │ ▸ Réglé depuis 24 h (5) │ ├───────────────────────────────────────────────────────────┤ │ [ Écris à Tao… Envoyer ]│ └───────────────────────────────────────────────────────────┘ ``` - **Le bloc « À traiter »** est le seul endroit où quelque chose t'attend. Il est fixé au-dessus du champ de saisie, replié s'il est vide. - **Il contient deux sortes de lignes.** Celles de la conversation en cours : la question que Tao te pose, la carte de compréhension, les lancements à cocher. Et celles des tâches : une ligne par tâche. - **Une ligne de tâche** donne le nom de la tâche, ce qui est attendu en une phrase et un bouton. La flèche déplie le détail sur place : étapes du plan, choix de la question, lien vers la PR. - **Une tâche peut avoir plusieurs demandes** (une question et une PR à merger). La ligne montre la plus urgente et leur nombre ; le détail les liste toutes. Rien n'est remplacé en silence. - **Une demande se met à jour au lieu de se dédoubler.** Nouvelle version du plan, question précisée par Tao, deuxième fichier livré : même demande. - **« Réglé depuis 24 h »** liste, repliée, ce qui s'est fermé sans ton clic, avec la raison (« PR mergée à 10:55 », « validé dans le terminal à 17:29 ») et un bouton « Rouvrir ». Rien ne disparaît sans trace. - **Dans le fil**, une carte traitée devient une ligne (« Plan validé par toi · 14:41 »). Les propositions d'un ancien tour aussi. Aucune carte ouverte d'un jour précédent n'est rendue dans le fil. - **Plus de bandeau d'alertes.** Ce qui demande un geste devient une ligne « À traiter ». Le reste (fichier livré, merge vu, étape franchie) va dans l'activité de la tâche, sans épingle. - **À l'ouverture**, le fil montre la dernière réponse de Tao, pas le bas d'une pile. ### 1.2 La colonne des tâches ``` ┌ Tâches ─────────────────────────────┐ │ À TOI (2) │ │ Site avocate · proposition 2 │ │ PR #10 à merger [Merger] │ │ Body Expert · images │ │ Question de l'agent [Répondre] │ │ EN COURS (3) │ │ Tao V2 · étape 2/6 · Tao suit │ │ AMI · base Ops · tu as la main │ │ La Fée Clochette · étape 3/5 │ │ AU REPOS (2) │ │ AMI · cahier des charges │ │ agent au repos depuis 14 h │ └─────────────────────────────────────┘ ``` - **Trois groupes** au lieu d'une liste par date : « À toi », « En cours », « Au repos ». Les terminées gardent leur onglet. - **Six libellés** remplacent les dix actuels. C'est un changement d'affichage : les états internes ne bougent pas. | Affiché | Veut dire | |---|---| | À toi | Un plan, une question, un merge ou un blocage t'attend ; la ligne dit lequel | | En cours | L'agent travaille en ce moment | | Au repos | L'agent a fini son tour et rien ne t'est demandé ; la ligne dit depuis quand | | Terminée | La fin est annoncée et toutes les PR de la tâche sont mergées ou fermées | | Session fermée | La session s'est arrêtée avant la fin annoncée | | Abandonnée | Inchangé | - **Une carte tient en deux lignes** : titre, puis soit ce qui t'attend, soit l'étape et qui suit la tâche. - **Qui suit la tâche** s'affiche en clair : « Tao suit », « Tu as la main », « Tao en retrait » (tu es dans le terminal), « Tao a atteint son plafond ». ### 1.3 Le détail d'une tâche - En tête : l'état, qui suit, et les demandes de la tâche avec leurs boutons. - **Toutes les PR de la tâche**, avec leur état lu sur GitHub (ouverte, mergée, brouillon, fermée), et pas seulement la dernière. - Le plan et ses étapes. - L'activité : livraisons regroupées (« 4 fichiers livrés à 18:42 »), merges vus, messages de Tao à l'agent avec leur statut daté (« remis à 09:16 », « en attente depuis 12 min », « retiré »). - Le journal complet reste accessible, replié. ### 1.4 Le terminal d'une discussion ``` Tâche #26 · AMI base Ops Tu as la main Tao en retrait tant que tu écris ici À traiter : l'agent demande le feu vert pour renommer les bases [ Oui ] [ Non ] [ Voir ] ``` - L'en-tête dit qui a la main et si Tao est en retrait. - La demande de la tâche s'affiche là, avec ses boutons : tu réponds sans repasser par le chat. - Exception : une question à choix affichée par Codex dans son propre sélecteur se répond dans le terminal, comme aujourd'hui. L'en-tête le dit, sans bouton. - Un plan rendu pendant que tu es dans le terminal se valide **dans le terminal**, avec le dialogue habituel de Claude Code ou de Codex. Aucune carte n'est créée. ### 1.5 Mobile Quatre onglets : Conversation, À traiter (avec le compteur), Tâches, Calendrier. Sur mobile, « À traiter » a son onglet au lieu d'être dans le fil. ### 1.6 Petits plus, hors du chemin critique - Les échéances quittent la colonne pour un onglet « Calendrier » (retour n° 8 de Nico). - « Ouvrir la discussion » ouvre un nouvel onglet (retour n° 10). - Retours de l'équipe : un bouton « Traité » ; un retour traité sort de la liste. Un agent qui livre la correction le marque lui-même, avec la PR. Les retours n° 3 à n° 7, déjà livrés, sont marqués à cette occasion. ## 2. Les règles ### 2.1 Les demandes d'une tâche Une **demande** est ce qu'une tâche attend de Tom : valider un plan, répondre, merger une PR, débloquer, relire. | Quand | Effet | |---|---| | L'agent pose une question, puis Tao la précise | Même demande, texte mis à jour | | Nouvelle version d'un plan | La demande montre la dernière version | | L'agent ouvre une deuxième PR | Une demande de merge par PR | | Tu réponds par un bouton ou dans le chat de Tao | La demande se ferme ; le serveur remet ta réponse à l'agent, sans passer par un tour de Tao | | La PR est mergée, où que ce soit | La demande de merge se ferme | | La PR est fermée sans merge | La demande se ferme ; la tâche ne passe pas « terminée » pour autant | | L'agent signale qu'il a reçu ce qu'il attendait | Sa demande se ferme | | L'agent reprend le travail après sa propre question | Sa question se ferme : « l'agent a poursuivi » | | La tâche se termine, est abandonnée, ou sa session se ferme | Ses demandes se ferment, avec la raison | | Une demande a plus de 24 heures | Elle reste ouverte, rangée sous « Depuis hier », repliée | Toute fermeture sans clic de ta part est écrite au journal avec sa raison et peut être rouverte pendant 24 heures. ### 2.2 Ce que tu fais dans le terminal Trois cas ferment une demande tout de suite, sans jugement : - tu valides un plan par le dialogue natif ; - ton message reprend un des choix proposés (« B », « oui pour option B ») ; - un merge est constaté sur GitHub. Une phrase libre ne ferme rien toute seule. Le 29/09, un message de ta part sans rapport avec la question a effacé un besoin à tort (#30, 11:11) ; la même règle appliquée aux questions aurait fermé la n° 17, jamais répondue. À la place : - la demande affiche « tu as écrit dans le terminal à 11:10 », avec un bouton « Fermer » ; - Tao lit ta phrase dans la minute et ferme la demande s'il y trouve la réponse, en la citant. Sinon il la laisse. Les messages tapés pendant que l'agent travaille sont lus comme les autres. Aujourd'hui ils sont ignorés (friction 5). ### 2.3 L'état d'une tâche Un balayage de fond, toutes les minutes, confronte chaque tâche vivante à des faits : - **PR** : l'état de chaque PR ouverte de la tâche est lu sur GitHub. Un jalon de fin qui cite une PR déjà mergée ne crée pas de demande de merge. - **Terminée** veut dire : fin annoncée par l'agent, et plus aucune PR ouverte. Une tâche terminée qui reçoit un nouveau jalon se rouvre, au lieu de le refuser. - **Au repos** : l'agent a fini son tour et n'a rien écrit depuis 3 minutes, sous-agents compris. - **Session fermée** : seulement après 3 minutes d'absence, pour ne plus basculer huit tâches pendant un déploiement. - **Réouverture** : un message de ta part sur une tâche terminée la rouvre, comme aujourd'hui. Elle se referme seule si l'agent a répondu sans nouveau jalon, sans question, et que tu n'as rien écrit depuis 15 minutes. - **Besoin** : c'est le texte de la demande ouverte. Pas de demande, pas de besoin affiché. Le balayage travaille à partir du journal des tâches. Il vaut donc aussi pour les sessions d'agents ouvertes avant le déploiement. ### 2.4 Les plans - **Tu es dans la discussion** (tu as écrit à l'agent depuis moins de 15 minutes) : le plan se valide dans le terminal, par le dialogue natif. Pas de carte, pas de relecture par Tao. Le serveur lit ta validation dans le transcript et passe la tâche « en cours ». - **Tu n'y es pas et Tao suit la tâche** : Tao relit et valide comme aujourd'hui. S'il a un vrai doute, il crée une demande « plan à valider ». - **Tu n'y es pas et tu as la main** : demande « plan à valider », comme aujourd'hui. - **Le dialogue natif reste sans réponse 5 minutes** : une demande « plan à valider » apparaît, pour que l'agent ne reste pas bloqué sans que tu le saches. - **Après une validation native**, le serveur vérifie que la session est restée en mode sans confirmation. Sinon il le signale : l'agent s'arrêterait à chaque commande. - Les étapes viennent de la liste que l'agent déclare. Elles ne sont plus devinées dans le texte du plan. Cette partie commence par un essai technique sur une session jetable, Claude puis Codex. Si l'essai échoue, repli : la carte reste, et se ferme dès que tu valides dans le terminal. ### 2.5 La main et ta présence - **La main reste ta décision** (ta règle du 28/09). Rien ne la change à ta place. - **Nouveau : le retrait.** Quand tu écris à un agent, Tao se met en retrait sur cette tâche jusqu'à 15 minutes après ton dernier message : ni verdict, ni relance, ni question, ni correction. Ce que l'agent signale pendant ce temps est noté ; une question de l'agent devient une demande, visible dans l'en-tête du terminal. Le retrait ne change pas la main. - **Fin du retrait** : Tao reçoit un seul résumé de ce qui s'est passé, tes consignes en tête. Il n'agit que si quelque chose est resté sans réponse. - **Main à Tom et agent qui attend** : une seule demande, « tu as la main, l'agent attend depuis 3 h », au lieu de vingt « écart signalé ». - **L'agent sait qui a la main.** Chaque réponse des outils de tâche la donne. Un changement de main lui laisse un message qu'il lit à son tour suivant, sans rien taper dans son invite. Avec la main à Tom, l'agent pose ses questions dans le terminal et n'attend aucune validation de Tao. ### 2.6 Tao en tâche de fond et la revue horaire - **Le plafond ne marque plus la tâche « bloquée ».** Au-delà de 6 actions par heure, Tao ne se réveille plus sur cette tâche jusqu'à l'heure suivante, sauf pour ta réponse. L'écran le dit. - **Ta réponse ne dépend plus de Tao** : le serveur la remet lui-même à l'agent, que Tao soit plafonné, en pause, ou que tu aies la main. - **Trois relances sans résultat** : une demande « l'agent ne répond pas aux relances », au lieu d'un arrêt. - **Une question reformulée deux fois dans l'heure** ne l'est plus une troisième. - **Tao voit les demandes ouvertes de tes autres tâches** avant de poser une question : il s'y rattache au lieu d'en ouvrir une seconde. - **Il reçoit tes consignes récentes** (messages à l'agent, accord donné au lancement) en tête de chaque tour, et le plan en entier, étapes et doutes en premier. - **Moins de tours pour rien** : un jalon sans question, sans blocage et sans fin ne le réveille plus. - **La revue horaire** ne compte plus tes messages comme des oublis, ne relance pas un agent qui a fini, ne change plus un état « à merger », et propose « terminé » dans sa relance. Elle garde ce qu'elle fait bien : repérer une question posée en texte libre. ### 2.7 Alertes et notifications - **Livraisons** : une entrée d'activité par tâche, mise à jour (« 5 fichiers, PR #8 »). Pas d'épingle. La fin d'une tâche reste annoncée une fois. - **Merges et mises en prod des agents** : aucune alerte quand tu l'as autorisé, par la case du lancement (décision 4), dans le terminal ou par Tao. Sans accord : une seule ligne par acte, jamais deux. - **Une lecture** (`vercel env ls`, `gh api`) ne déclenche rien. - **Notifications push** : voir décision 6. ### 2.8 Les messages entre Tao et les agents - **Chaque message a un statut daté** visible dans la tâche : remis, en attente, retiré. - **Claude** : un message en attente qui n'a plus de sens est retiré. - **Codex** : sa file ne permet pas de retirer un message. Le serveur garde donc le message chez lui tant que Codex est occupé, et ne l'envoie qu'au repos ; d'ici là il peut encore l'annuler. - **« Remis » n'est écrit que sur preuve** dans le transcript, avec l'heure d'arrivée réelle. - **Un merge fait par le serveur est annoncé à l'agent**, avec le commit. - **Une session qui n'a pas démarré** est signalée dans les deux minutes, au lieu d'une tâche « en cours » pendant des heures. ### 2.9 Ce que Tao peut ranger Deux nouveaux gestes pour Tao, dans le chat comme en tâche de fond : - **Fermer ou reformuler une demande**, avec la preuve : ta phrase, vérifiée mot pour mot dans le chat ou le transcript depuis la création de la demande, ou un fait (PR mergée, tâche finie). - **Corriger l'état d'une tâche** quand un fait le prouve. Ce que le serveur peut fermer sur un fait, il le ferme seul, en continu. Tao ne juge que le reste, en tâche de fond : jamais au début d'une réponse dans le chat, pour ne pas l'alourdir. Il ne peut pas fermer une demande de merge ou de mise en prod sans le fait constaté, ni répondre à ta place. ### 2.10 Ce que Tao dit dans le chat - Réponse courte par défaut : ce que tu dois décider maintenant, rien d'autre. - Il ne redonne pas la liste de ce qui attend : le bloc « À traiter » la montre. - Avant d'annoncer qu'une action t'attend, il lit la demande ouverte, pas sa mémoire. - Une question du chat n'est plus close par défaut parce que tu as cliqué sur une autre carte. - Un tour long affiche ce qu'il fait ; le délai de 4 minutes ne coupe plus un tour qui avance (retour n° 9). ### 2.11 Le protocole des agents - **Une PR s'annonce par un jalon avec son lien**, sans fermer la tâche. - **La fin s'annonce une fois**, quand tout est livré. - **Seul l'agent principal** déclare des jalons ; un sous-agent est refusé. - Le guide des agents, le contexte injecté et le manuel de Tao sont mis à jour dans chaque lot. Les agents déjà lancés ne reçoivent pas de diffusion générale : celle du 28/09 avait fait redéclarer « terminé » à des tâches finies. ## 3. Cas de panne | Situation | Ce que tu vois | Ce que fait le système | |---|---|---| | L'agent ne déclare rien | « En cours » tant qu'il travaille, puis « Au repos depuis… » | Le balayage lit son activité dans le transcript | | L'agent travaille en fond (sous-agents, commande longue) | « En cours » | « Au repos » exige 3 minutes sans aucune écriture | | La session meurt | « Session fermée », demandes fermées avec la raison | Rien n'est relancé sans toi | | Déploiement du Harness | Rien ne change | 3 minutes d'absence avant de dire « fermée » | | Tao est déconnecté | Les demandes des agents s'affichent quand même | Le balayage tourne sans Tao ; tes réponses partent ; le bilan arrive à la reprise | | Tao a atteint son plafond | « Tao a atteint son plafond jusqu'à 12:00 » | Tes réponses partent quand même | | Tu cliques une ligne qui vient de changer | « Cette demande a changé, relis-la » | Le clic porte la version de la ligne ; une version périmée est refusée | | Deux demandes sur une tâche | Une ligne, « 2 demandes », détail dépliable | Aucune n'en remplace une autre | | Plan : dialogue natif sans réponse | Demande « plan à valider » après 5 minutes | Repli sur la validation par carte | | Plan validé, mauvais mode choisi dans le dialogue | « L'agent demandera une confirmation à chaque commande » | Signalé sur la tâche, avec la marche à suivre | | Message à un agent Codex en retard | « En attente depuis 12 min » sur la tâche | Gardé par le serveur jusqu'au repos de Codex, annulable | | GitHub injoignable ou jeton expiré | « État de la PR non vérifié depuis 10:40 » | Dernier état connu gardé ; le balayage des PR s'arrête au premier échec et réessaie au tour suivant | | PR en brouillon | « PR #3 en brouillon », sans bouton Merger | Pas de demande de merge tant qu'elle est en brouillon | | Tu réponds dans le terminal puis sur la carte | « Déjà répondu dans le terminal à 10:58 » | La première réponse fait foi | | Fermeture à tort | La ligne est dans « Réglé depuis 24 h » | « Rouvrir » ; le cas est noté pour corriger la règle | | Transcript illisible | Pas de fermeture par le terminal | Les boutons restent ; la tâche le dit | | Fusion de deux tâches d'une même discussion | Une tâche, toutes les demandes | Les demandes suivent la tâche gardée | | Session ouverte avant le déploiement | Ses demandes s'affichent | Le balayage les tire du journal ; la main ne lui est donnée qu'à sa relance | | Session fantôme d'une tâche abandonnée | « Une session tourne encore » sur la tâche | Tu décides de l'arrêter ; plus de notification quotidienne | ## 4. Tes décisions Chaque point a une proposition. « Ok » les accepte toutes ; sinon donne les numéros à changer. 1. **Retrait de Tao quand tu écris à un agent.** Proposition : 15 minutes après ton dernier message, sans exception ; une question de l'agent pendant ce temps s'affiche dans l'en-tête du terminal. 2. **Plan validé dans le terminal** quand tu y as écrit depuis moins de 15 minutes. Proposition : oui, après l'essai technique. 3. **Compréhension et lancement en une seule carte.** Aujourd'hui il te faut quatre gestes en médiane entre une demande et son lancement. Proposition : une carte unique « ce que j'ai compris et ce que je lance », confirmée en un clic. Cela assouplit ta règle du 27/09 (reformulation confirmée avant toute carte). Peut aussi attendre après la V2. 4. **Accord de merge et de mise en prod donné au lancement.** Proposition : une case sur la carte de lancement, décochée par défaut, « l'agent peut merger et déployer sans me demander ». Toi seul la coches ; elle vaut pour toute la tâche ; plus d'alerte ensuite. 5. **Demande de merge.** Aujourd'hui une carte de merge expire le soir. Proposition : la demande reste tant que la PR est ouverte ; « Merger » demande une confirmation, comme aujourd'hui. 6. **Notifications push.** Aucune n'est jamais partie, faute d'appareil abonné. Proposition : les garder pour un seul cas, une tâche passe « à toi », et vider la file actuelle. Ou les retirer. 7. **Retours de l'équipe traités.** Proposition : sortis de la liste, gardés en base, consultables par un filtre. Ou supprimés pour de bon. 8. **Rythme.** Cinq lots, donc cinq PR. Proposition : tu valides chaque merge. Ou une autorisation d'avance pour les lots dont le rejeu sur copie est vert. ## 5. Les lots Chaque lot porte ses tests et sa documentation (consignes du VPS, contexte injecté, protocole, manuel de Tao) dans la même PR. L'écran actuel continue de marcher jusqu'au lot 4 : les routes qu'il utilise sont gardées, servies depuis le nouveau modèle. ### Lot 1 : les faits Aucun changement d'écran. Les états se corrigent, le bruit baisse. - Lecture des messages tapés pendant un tour d'agent. - Balayage de fond : PR de chaque tâche, activité de l'agent, session (3 minutes), réouvertures refermées. - Jalon de fin avec PR déjà mergée ; tâche terminée qui accepte un nouveau jalon. - Revue horaire : les quatre corrections de la section 2.6. - Merges : une alerte par acte, lectures ignorées. - Plan transmis entier à Tao. - Contrôle, sur une copie figée de la base du 30/09 : #31 terminée ; #20 au repos avec sa PR #7 signalée ; #12 au repos ; plus de « session fermée » transitoire. ### Lot 2 : les demandes et le rangement Les cartes périmées se ferment, sans changer l'écran. - Demandes : modèle, cycle de vie de la section 2.1, journal des fermetures, « Rouvrir ». - Routes actuelles servies depuis les demandes ; ta réponse remise par le serveur. - Fermeture sur choix tapé dans le terminal ; annotation « tu as écrit dans le terminal ». - Outils de rangement de Tao et passe de fond. - Contrôle, sur la même copie : cartes de plan n° 63, 71 et 73 fermées ; questions n° 14, 15 et 16 fermées par Tao avec ta phrase du terminal en preuve ; question n° 17 toujours ouverte ; besoin de #27 fermé sur ta décision du 29/09. ### Lot 3 : le terminal, la main, Tao en tâche de fond - Essai technique puis validation native du plan ; présence par message tapé. - Retrait de Tao ; demande unique quand tu as la main et que l'agent attend. - La main donnée à l'agent dans chaque réponse d'outil, et par message à chaque changement. - Plafond revu ; consignes récentes en tête des tours ; réveils filtrés. - Messages aux agents : statut daté, retrait (Claude), retenue jusqu'au repos (Codex), annonce des merges du serveur, session non démarrée. - Case d'accord au lancement. - Protocole des agents : PR sans fin de tâche, fin unique, sous-agents refusés. ### Lot 4 : l'écran - Bloc « À traiter », « Réglé depuis 24 h », fil allégé. - Colonne des tâches en trois groupes, six libellés, carte en deux lignes. - Détail de la tâche : PR, activité, messages datés. En-tête du terminal avec la demande. - Onglets mobile. - Règles d'écriture de Tao dans le chat ; tour long qui ne se coupe plus. - Retrait des anciennes routes. - Contrôle : capture du même écran qu'au 30/09, bureau et mobile. ### Lot 5 : les petits plus Onglet Calendrier, discussion dans un nouvel onglet, retours « Traité », carte unique de la décision 3 si tu la retiens. ### Après les lots Contrôle en prod sur ton écran réel, et mesure des mêmes chiffres que l'audit. ## 6. Ce qu'on mesurera | Mesure | 30/09 | Cible | |---|---|---| | Cartes de la veille sous la dernière réponse | 7 (6 écrans sur bureau, 10 sur mobile) | 0 | | Tâches dont l'état affiché est faux | 11 sur 25 chez Tom | 0 sur les faits vérifiables (PR, session, activité) | | Plans envoyés en carte pendant que le développeur est dans le terminal | 4 relevés en quatre jours | 0 | | Éléments épinglés par jour | 51 alertes | Moins de 10 lignes « À traiter » | | Questions en double | 10 | 0 | | Tours de fond « rien à faire » | 230 sur 576 | Les 89 réveils sur jalon supprimés ; le reste mesuré | | « Oublis » de la revue qui sont des messages du développeur | 48 sur 136 | 0 | | Gestes entre une demande et son lancement | 4 en médiane | 2, si la décision 3 est retenue | | Messages de Tao arrivés après coup sans être annulés | 3 relevés | 0 | ## 7. Ce que ce plan ne règle pas, et les risques acceptés - **Étape courante fausse quand le travail change** (#25, #32) : repose sur l'agent, qui doit mettre son plan à jour. Le balayage ne sait que dire « au repos » ou « en cours ». - **Discipline des agents** : fin annoncée une fois, jalon par PR. Les règles sont dans le protocole ; le balayage rattrape les faits, pas les oublis de plan. - **Ton de Tao** (section 2.10) et « ne pas contredire une consigne récente » sont des consignes données au modèle. Elles se mesurent, elles ne se garantissent pas. - **Un collègue qui tape dans ton terminal** compte comme toi. - **Validation native du plan** : dépend de l'essai technique ; le repli est décrit en 2.4. - **Codex** : l'identifiant de tâche gardé par une vieille session (#18) et le plan non enregistré (#6) sont traités au lot 3 si l'essai Codex les reproduit ; sinon ils restent ouverts. - **Sessions ouvertes avant un déploiement** : elles gardent l'ancien comportement côté agent (pas de main dans les réponses d'outils) jusqu'à leur relance. - **Rejeu** : il se fait sur une copie figée de la base et des transcripts, avec des états de PR enregistrés, pour ne pas dépendre de GitHub le jour du test. ## Annexe technique Pour les agents qui coderont ; les références viennent du diagnostic et de la relecture d'Apollon. **Modèle de données (migrations 0051 et suivantes).** - `tao_waits` : une ligne par demande. Champs : tâche, utilisateur, nature (`plan`, `question`, `merge`, `deploy`, `blocage`, `relecture`, `main`), référence (PR, revue de plan, sujet), version, titre, texte, choix, défaut, source (`agent`, `pilote`, `serveur`), statut (`open`, `answered`, `closed`, `replaced`), réponse, canal de la réponse (`carte`, `chat`, `terminal`, `fait`), preuve, annotation « écrit dans le terminal à… », dates, auteur et raison de la fermeture. Unicité sur (tâche, nature, référence) pour les lignes ouvertes. L'affichage regroupe par tâche. - `tao_task_prs` : les PR d'une tâche (sources : jalons, garde, détection de la revue `review.go:384-400`), état lu sur GitHub, date de lecture. - `tao_tasks` : `agent_turn_at` existe (`pilot.go:110,195`) ; ajouter la date de la dernière écriture de l'agent et du dernier message tapé par Tom. Les dix états internes ne changent pas ; les six libellés sont une table d'affichage. `needs` reste en colonne, alimenté par la demande ouverte. - `tao_plan_reviews` reste le support de la porte de plan. `tao_task_asks` et les cartes `kind=plan` de `tao_chat_prompts` gardent leurs identifiants jusqu'au lot 4 : les routes `GET /api/tao/task-cards`, `GET /api/tao/prompts`, `POST /tasks/{id}/asks/{ask}` et `/tasks/{id}/plan` sont servies depuis `tao_waits`. - `mergeTasks` (`tasks_dedup.go:243-279`) : traitement dédié des demandes, comme pour `tao_plan_reviews`. **Balayage.** - Goroutine à part de `runTaoGuardTick` (`goweb_tao_guard.go:171-188`), qui lit aussi les messages de Tom : `gh` avec délai de 10 s, arrêt au premier échec, PR ouvertes seulement. - Il dérive les demandes du journal `tao_task_events` par curseur, pour couvrir les sessions dont le processus MCP est figé sur un ancien binaire (`harness/task_tools.go`, `tao/db.go:24`). - La réconciliation avec tmux quitte le `GET /api/tao/tasks` (`goweb_tao_tasks.go:85`). - `claudeTurnOpen` (`deliveryproof.go:145-190`) passe par un curseur au lieu de relire le fichier. **Terminal.** - `internal/transcript/read.go:455` : lecture des lignes `attachment` de type `queued_command`, origine humaine seulement ; lecture du résultat d'`ExitPlanMode` (l. 492-496) et de la ligne `permission-mode`. - `reconcileHand` (`hand.go:92`) : choix reconnu, annotation, date du dernier message de Tom. Le transcript est relu avant chaque geste de Tao (modèle `tasks.go:807-813`), car un message tapé en plein tour n'entre au transcript qu'à son absorption. - Porte de plan (`cmd/paf-agent/tao_hooks.go`, `runPlanGate`) : lit la fin du transcript (`transcript_path`) pour la présence ; présente = elle enregistre le plan et ne décide pas. Codex : « Implement the plan. » dans le rollout (`deliver.go:273-275`) clôt la revue. - `AgentBlockingScreen` (`pilot.go:779-797`) : reconnaître l'écran de confirmation par commande. **Tao en tâche de fond.** - État « plafonné » qui arrête la mise en file (`pilot.go:150`) sauf `tom_answer` ; `pilotGuard` et `haltPilot` (`pilot.go:396-431`) ne posent plus `blocked`. - Réponse de Tom remise par le serveur (`DeliverConfirmed`, modèle `relay.go`), hors `CanTaoDrive` (`guard.go:137-140`) et hors pause (`pause.go:311`). - Retrait : réveils retenus et regroupés (`PilotHold`). - Plan non coupé (`prompt_task.go:169`) ; réveils filtrés dans `EnqueuePilot` (`pilot.go:146`). - Revue : `tomSeen` (`review.go:359`), texte de relance (`review.go:601`). - Message de changement de main : remise passive, émetteur système (le réveil actuel colle dans l'invite, `confirmdelivery.go:295-318`). **Garde et remise.** - Accord du lancement : champ posé par le clic de Tom sur la carte, jamais par le texte de Tao (`gestures.go:31`). Un acte par commande. - Codex : message retenu tant que la session est occupée (`confirmdelivery.go:370-379`). Claude : `peers.Withdraw` (`peers/store.go:578-586`). - Message à l'agent après `MarkTaskMerged` (`merge.go:458`). **Outils.** - Tao : `tao_wait_close`, `tao_wait_update`, `tao_task_fix` (`ToolNames`, `tao.go:136` ; `TaskToolNames`, `pilot.go:72`). Vérification de l'extrait : `verifyTomExcerpt` (`plan_update.go:244-262`) étendue aux messages depuis la création de la demande ; `typedByTom` (`tomorder.go:101-154`) réutilisé. - Agents : la main dans les réponses de `internal/harness/task_tools.go` ; refus des sous-agents par hook (`tao_hooks.go:59`) ; `feedback_resolve`. **Interface (lot 4).** `GET /api/tao/waits`, `POST /api/tao/waits/{id}/answer|close|reopen` avec la version de la ligne. `TaoChat.vue` (le calcul `placement` perd les cartes orphelines), nouveau `TaoWaits.vue`, `TaoTasks.vue`, `TaoTaskCard.vue`, `TaoTaskDetail.vue`, `TerminalTaoHand.vue`, `TaoPromptCard.vue` réutilisé pour le détail déplié. **Tests.** - Go : un test par ligne du tableau 2.1 et par cas de panne, sur le modèle de `needs_test.go` et `guard_test.go` ; test de migration et de `mergeTasks` sur un jeu tiré de la base du 30/09 (#26 arrive avec trois lignes ouvertes). - Playwright : nouvelle spec `tao-waits`, mise à jour de `tao-final`, `tao-tasks`, `tao-chat-cards`. - Rejeu sur copie figée avant chaque PR ; suite complète par `paf-test-queue`.