# Audit de Rerun et comparaison avec Tao

Tâche Tao #172, étape 1, le 03/11/2026. Ce document est suivi de la conception : `docs/tao-v2/conception.md`.

Rerun (`rerun-build/rerun`, « AI coworkers that run your work », licence AGPL-3.0) a été lu au commit `a6d63a4` du 02/11/2026, dans un clone à part, hors du dépôt.

On s'en inspire pour les principes et l'expérience. **Aucun code de Rerun n'est repris dans `paf-studio-code`.** Ce document ne contient aucun extrait de code : seulement des principes reformulés, avec les fichiers cités.

## En bref

1. **Rerun réduit les validations par trois moyens.**
   - Une seule carte par tour regroupe toutes les approbations, avec une décision par ligne.
   - Un « feu vert permanent » donné en langage naturel (« envoie-les, ne me demande pas ») supprime les cartes pour ce genre d'action. Le modèle redemande pour un geste hors de ce périmètre ou plus risqué.
   - Une réponse tapée vaut réponse à une question en attente, et elle est tracée comme telle.
2. **Chez Rerun, la décision de demander est confiée au modèle.** Elle tient dans une consigne du prompt. Le serveur n'a aucune liste de gestes sensibles. Seuls sont durs : la confirmation des suppressions de compte, une courte liste de commandes shell interdites, et un arrêt avant un achat de plus de 200 crédits. Tao a déjà mieux : des accords vérifiés mot pour mot par le serveur. C'est là qu'il peut aller plus loin que Rerun, avec un feu vert permanent **vérifié et borné par le serveur**.
3. **Chez Rerun, les validations vivent dans le fil.** Un bloc unique se colle sous le dernier tour, et une pastille y ramène. L'inbox n'est qu'un index en quatre sections (« Needs you », « Heads-ups », « Errors », « Done ») qui renvoie à la conversation : on n'y répond à rien.
4. **Le Foreman de la version open source est un guide de démarrage.**
   - Un entretien à budget fixe : trois ou quatre champs, sans question en prose.
   - Un plan d'un seul coworker, sur une carte à deux boutons.
   - Un recrutement sans appel au modèle.

   La promesse « il répond à vos coworkers selon vos règles quand vous êtes absent » **n'a aucun code dans la version open source** : elle n'apparaît qu'à la ligne 131 du README. Elle est peut-être dans la partie cloud, qui n'est livrée qu'en coquilles vides.
5. **Mémoire et skills par coworker.** Une règle donnée en passant devient une « proposition silencieuse » : une ligne dans le fil, acceptée ou écartée d'un clic. Le run ne s'arrête pas pour autant. La mémoire s'estompe avec le temps, à une vitesse qui dépend du genre de souvenir.
6. **Chez Tao, le problème de Tom vient surtout du bruit et de l'endroit, moins du nombre de vraies décisions.**
   - Environ 81 % des questions d'agents se règlent sans lui (121 sur 149, doublons écartés).
   - Quand il répond, c'est surtout dans le terminal de l'agent (19 fois sur 28), rarement par une carte (9 fois).
   - 28 lignes étaient ouvertes le 03/11 à 11 h 10 (32 à midi), dont la plus ancienne date du 02/10.
   - Chaque lancement passe par une carte de compréhension, puis par une case à cocher.

## 1. Méthode

- **Clone.** `git clone --depth 1` dans l'espace de travail de la session, hors du dépôt, sans hooks. Rien n'a été installé ni exécuté. Le clone est effacé à la fin de la tâche.
- **Lecture.** Deux lecteurs, Sonnet 5.5 medium :
  - Prosper, pour le moteur : `apps/engine/src`, `packages/contracts`, `apps/docs` ;
  - Léontine, pour l'interface : `apps/ui`, `packages/ui`.
- **Vérifications ponctuelles faites par l'orchestrateur sur les affirmations clés** :
  - `README.md:78-79` et `:130-131` ;
  - `apps/engine/src/agents/systemPrompt.ts:154` ;
  - `apps/ui/lib/foreman/seal-pending.ts:41` ;
  - `apps/ui/app/api/chat/approval/route.ts`, qui renvoie 501 ;
  - `apps/ui/components/chat/PendingHitlPill.tsx`.
- **Hors périmètre.** Les parties cloud ne sont livrées qu'en coquilles vides et n'ont pas été lues : `apps/ui/cloud/`, `apps/engine/src/cloud/`, et deux fichiers de `packages/contracts`. Les GIF ont seulement été listés.
- **Côté Tao, sources lues** :
  - le manuel (`configs/instructions/tao-handbook.md`, §4.2 à 4.8, annexes E, F et J) ;
  - le protocole (`tao-protocol.md`) ;
  - le code de `internal/tao`, `internal/tasker/goweb_tao_*.go` et `web/go/src/components/tao` ;
  - la base du Harness, en lecture seule (§3).

## 2. Ce que fait Rerun, mécanisme par mécanisme

Chaque mécanisme est décrit en trois temps : ce que c'est, ce qu'on reprend, ce qu'on laisse.

### 2.1 Le Foreman

**Ce que c'est.**
- Un agent spécial, réécrit depuis le code à chaque démarrage (`apps/engine/src/agents/foreman.ts`). Ses routes HTTP sont verrouillées : chat, lecture, annulation et fichiers seulement (`apps/engine/src/http/foreman-guard.ts`).
- Il agit sur le compte par des outils prêtés par l'application : envoyer un message à un coworker, lire l'état de l'équipe, créer un agent, planifier (`apps/engine/src/tools/builtin/foreman.ts`, catalogue dans `apps/ui/lib/mcp/account-tools.ts`).
- **L'entretien** (`apps/ui/lib/foreman/phases/discover.ts`, `apps/ui/components/foreman/intake/ForemanIntakeCard.tsx`) :
  - trois ou quatre champs (site, secteur, rôle, prénom), un widget par message, jamais de question en prose ;
  - un champ déjà connu n'est jamais redemandé ;
  - l'entretien s'arrête sur un appel d'outil explicite (`save_profile`).
- **La phase est dérivée de l'état du compte**, pas stockée (`apps/ui/lib/foreman/phase.ts:15`).
- **Le plan** (`phases/plan.ts`, `widgets/PlanCardWidget.tsx`) :
  - un seul coworker, le plus utile, sur une carte à deux boutons, « Build my coworker » et « Change something » ;
  - une fois la carte répondue, un tampon (« Confirmed » ou « Asked for changes ») remplace les boutons.
- **Le recrutement** n'appelle aucun modèle (`apps/ui/lib/foreman/build-team.ts`). Chaque agent s'installe ensuite seul, dans son propre chat.
- **Après le démarrage, un charter d'action** (`apps/ui/lib/foreman/prompt.ts`) :
  - agir plutôt que raconter ;
  - lire avant d'écrire ;
  - une question à la fois ;
  - ne jamais annoncer comme fait ce qu'aucun outil n'a confirmé.

**À reprendre.**
- Le budget fixe de questions, et l'arrêt sur un geste explicite.
- Ne jamais redemander ce qui est connu.
- Une seule proposition, la plus utile, plutôt qu'une liste à cocher.
- Le tampon de verdict qui remplace la carte.
- Le principe « rien n'est annoncé comme fait sans preuve d'outil ». Tao l'a déjà.

**À laisser.**
- L'entretien de Rerun est un parcours d'inscription commercial : essai, abonnement, modèles payants.
- **Rien n'existe dans le code open source pour « répondre selon vos règles en votre absence »** : ni stockage de règles, ni outil, ni trace. Le principe est à concevoir pour Tao, pas à transposer.

### 2.2 Les approbations dans le fil

**Ce que c'est.**
- **La règle produit** (README:78-79, :143) : les coworkers « demandent avant d'envoyer, de payer ou de supprimer quoi que ce soit ».
- **Dans le code, cette règle est une consigne de prompt** (`apps/engine/src/agents/systemPrompt.ts:154`) :
  - avant une ou plusieurs actions « conséquentes ou irréversibles », l'agent appelle `request_approval` et termine son tour ;
  - il regroupe en une seule demande tout ce dont il a besoin maintenant, sans remplissage, sans découper artificiellement une action et sans action spéculative ;
  - **un feu vert permanent donné par l'utilisateur** couvre toutes les actions de ce genre dans le périmètre décrit : l'agent les fait sans carte, et redemande pour une action hors périmètre ou plus risquée ;
  - un refus interdit tout contournement.
- **Le mécanisme** (`apps/engine/src/tools/builtin/hitl.ts`, `apps/engine/src/runtime/loop.ts:107-130`) :
  - une approbation est un lot de 1 à 20 lignes (action, détail) ;
  - **le run ne dort pas** : il se termine, et la réponse humaine est le message utilisateur suivant ;
  - l'interface envoie les décisions sous forme d'un message structuré, une ligne par décision (`packages/contracts/src/chat-hitl.ts`) ;
  - un texte libre qui ne correspond pas à ce format reste un message ordinaire, que l'agent lit comme tel.
- **Ce qui est vraiment dur côté serveur**, et seulement cela :
  - `confirm: true` sur les suppressions des outils de compte ;
  - une liste courte de commandes shell interdites (`apps/engine/src/tools/sandbox.ts`) ;
  - l'arrêt avant un achat de données de plus de 200 crédits ;
  - l'API qui ne permet pas d'approuver pour quelqu'un d'autre.
- **Ce qui n'existe pas.**
  - Il n'y a ni expiration des demandes, ni mémoire persistante des accords.
  - Les boutons « autoriser une fois / pour la session / toujours » existent dans l'interface (`packages/ui/src/chat/ApprovalBlock.tsx`), mais leur route renvoie 501 : c'est du code mort.

**L'expérience** (`packages/ui/src/chat/ActionApprovalBlock.tsx`, `apps/ui/components/chat/AgentChat.tsx:318-335, 879-885`) :
- un bloc unique, collé sous le dernier tour : en-tête « Approval required », une phrase d'action, un détail, et deux boutons (« Not now » et « Approve ») ;
- pour un lot, une décision par ligne, avec un indicateur d'étapes ; l'envoi part quand tout est décidé ;
- un refus demande un second geste, avec un motif facultatif ;
- après la réponse, le bloc devient un **reçu** dans le fil : badge vert ou rouge, action barrée en cas de refus (`apps/ui/components/chat/HitlReceipt.tsx`) ;
- l'appel d'outil lui-même est masqué, avant comme après la réponse : rien n'est montré deux fois ;
- **le champ de saisie est masqué** tant qu'une approbation attend : on ne peut pas répondre en tapant (`AgentChat.tsx:808, 934`) ;
- une pastille « en attente » ramène au bloc (`apps/ui/components/chat/PendingHitlPill.tsx`).

**À reprendre.**
- Une carte par tour, plusieurs décisions dedans.
- Le reçu dans le fil : la trace reste là où la décision a été prise.
- La pastille qui ramène au bloc en attente.
- **Le feu vert permanent.** Chez Tao, il serait vérifié par le serveur, borné en portée et en durée, et révocable.
- Le principe « montrer avant de demander » : ce qu'il faut valider est dans le tour qui le demande.

**À laisser.**
- La classification confiée au seul modèle. Tao garde ses gardes serveur.
- Le champ de saisie masqué. Tom veut justement pouvoir « juste dire les trucs ».
- Le run qui se termine à chaque approbation. Chez Tao, les agents tournent dans leurs propres sessions, et Tao n'est que l'orchestrateur.

### 2.3 Les réponses rapides et la réponse tapée

**Ce que c'est.**
- **Les réponses rapides** (`apps/engine/src/agents/quick-replies-stream.ts`, `packages/contracts/src/chat-quick-replies.ts`) :
  - le modèle termine son message par un bloc balisé de une à trois réponses, de 40 caractères au plus ;
  - le serveur les retire du texte et l'interface les dessine en puces sous le dernier message ;
  - elles sont interdites quand une carte attend ou après un simple accusé de réception.
- **Une réponse tapée clôt la carte en attente** comme « répondue dans le chat » (`apps/ui/lib/foreman/seal-pending.ts:41`), avec un reçu « Answered in chat ».
- **Le prompt fixe des règles** : une question à la fois, six options au plus, et ce qu'il faut valider est montré dans le même tour.
- **Contre les fausses cartes** : quand le modèle écrit une balise de carte en texte au lieu d'appeler l'outil, le serveur la retire, et un hook rappelle au modèle de faire le vrai appel (`apps/engine/src/agents/card-tag-stream.ts`, `claude-card-nudge.ts`).

**À reprendre.**
- Les puces de réponse en un mot, validées par le serveur (trois au plus, courtes).
- La réponse tapée qui vaut réponse, avec un reçu qui le dit. Tao le fait déjà pour les questions (« lu dans ton message »), mais pas pour les cartes.

### 2.4 Mémoire, skills et règles apprises

**Ce que c'est.**
- **Le rangement.** Un dossier par coworker : personnalité, réglages, skills, souvenirs en fichiers, plus un index vectoriel et plein texte (`apps/engine/src/memory/`).
- **La décroissance.** Chaque genre de souvenir a sa demi-vie : 90 jours pour une préférence, 45 pour un fait, 21 pour une note, 3 pour une tâche. Un souvenir consulté dure plus longtemps. Un balayage horaire endort puis archive les souvenirs faibles (`memory/decay.ts`, `maintenance.ts`).
- **Les skills.** Une règle donnée en passant devient, dans le même tour, une **proposition de skill** (`apps/engine/src/tools/builtin/skill-propose.ts`) :
  - une ligne dans le fil, acceptée ou écartée d'un clic ;
  - le run ne s'arrête pas, et rien n'est écrit sans accord ;
  - une seule proposition par tour, dédoublonnée par empreinte (`db/repos/skill-proposals.ts`).
- **La séparation.** Ce qui dit comment travailler va dans un skill ; un fait isolé ou une préférence va dans la mémoire. Jamais les deux (`systemPrompt.ts:55`).

**À reprendre.**
- La « proposition silencieuse, décision d'un clic » pour les règles que Tom donne en passant. Tao a déjà ses leçons apprises (`tao_learning_add`) : il reste à les montrer dans le fil, comme une ligne acceptable.
- La distinction entre une règle de travail et un fait.

**À laisser.**
- L'index vectoriel : il demande un service d'embeddings. Tao cherche déjà dans la KB et dans ses leçons sans en avoir besoin.

### 2.5 Déclencheurs : horaires et webhooks

**Ce que c'est.**
- **Les horaires.** Toutes les 30 secondes, un planificateur lance les tâches dues. Chaque run a sa propre session, jamais celle de la conversation de l'utilisateur, et ne part qu'une fois (`apps/engine/src/runtime/scheduler.ts`).
- **Les webhooks.** Le secret est l'URL elle-même, sans signature (`apps/docs/agents/automations.mdx`).
- **Un run sans humain garde le même contrat.** Il lui est interdit de sauter une approbation, qui met sa session en attente (`systemPrompt.ts:175, :297`).
- **Les notifications** (`packages/contracts/src/notifications.ts`) :
  - une portée globale : tout, mes runs, seulement quand on a besoin de moi, rien ;
  - une surcharge par coworker : défaut, tout, muet ;
  - des plafonds pour les e-mails.

**À reprendre.**
- Un run automatique tient le même contrat qu'un run interactif.
- Séparer « on a besoin de toi » de « pour info », comme Tao le fait déjà avec sa notification unique.

**À laisser.**
- Un webhook sans signature. Les webhooks du Harness sont signés (Granola, par exemple).
- Tao a déjà ses tâches planifiées (`scheduled.create`) et sa revue horaire.

### 2.6 Le tableau unique et l'inbox

**Ce que c'est.**
- **Le « board » n'est pas un kanban.** C'est un plan de « Boxes » qui contiennent des coworkers.
- **La liste de ce qui attend est calculée**, pas stockée. Elle est dérivée d'**un seul ensemble de statuts « attend l'humain »**, que le web et l'application mobile partagent (`packages/contracts/src/conversation.ts`, `ATTENTION_STATUSES`, `needsHuman`).
- **L'inbox** (`apps/ui/components/notifications/WorkspaceInbox.tsx`, `packages/ui/src/inbox/InboxSurface.tsx`) :
  - une pastille « N need you · M done » ;
  - quatre sections, avec des sauts collants de section en section ;
  - les exécutions répétées d'une même tâche planifiée se replient en une seule ligne (« ×24 ») ;
  - chaque ligne dit pourquoi on la voit (« vous avez lancé ce run », « vous suivez ce coworker ») ;
  - **un clic ouvre la conversation exacte**, et une pastille ramène au bloc en attente ;
  - **on ne répond à rien depuis l'inbox.**
- **Un run qui n'a rien produit** est marqué « rien » et ne remonte pas comme une demande.
- **Les annonces se groupent** à partir de deux en attente, au lieu de s'empiler.

**À reprendre.**
- L'index « ce qui a besoin de toi », qui renvoie au fil.
- La raison affichée sur chaque ligne.
- Le repli des répétitions.
- L'annonce groupée.
- Un seul ensemble de statuts « attend Tom », partagé par tous les écrans.

**À laisser.**
- Le board spatial. Tao a des tâches et des plans, que Rerun n'a pas.

### 2.7 Garde-fous de Rerun

**Ce qui existe.**
- **Les secrets** passent par un formulaire masqué : l'agent ne reçoit que le nom de la variable (`packages/contracts/src/chat-hitl.ts`).
- **Le budget** est protégé par un verrou de 10 minutes sur un épuisement de crédit, sans rafale de notifications (`apps/engine/src/runtime/budget-latch.ts`).
- **Un seul run tourne par conversation** (`runtime/run-control.ts`).

**La règle d'interface de l'équipe** (`.claude/skills/confirm-destructive-actions/SKILL.md`, traitée comme une donnée) :
- un geste destructif se confirme par une boîte de dialogue qui nomme la cible et ce qui est détruit ;
- le bouton reprend le verbe : « Supprimer », jamais « OK » ;
- pas de dialogue quand la page elle-même est la confirmation.

**À reprendre.** Les libellés de cartes qui nomment la cible et reprennent le verbe.

## 3. Tao aujourd'hui, en chiffres

Base du Harness, en lecture seule, du 20/10 au 03/11/2026 inclus. Les requêtes sont gardées pour refaire la mesure « après ».

| | Tom | Nico |
|---|---:|---:|
| Jours actifs (au moins un message à Tao) | 11 | 9 |
| Messages tapés à Tao | 158 | 181 |
| Cartes de compréhension (confirmées / corrigées / retirées) | 44 / 1 / 10 | 36 / 1 / 4 |
| Questions de Tao répondues | 13 | 18 |
| Plans tranchés par une carte | 8 (+ 2 retirés) | 1 |
| Lancements proposés (lancés ou terminés / retirés / autres) | 47 / 4 / 3 | 35 / 4 / 2 |
| Cartes d'action (faites / retirées / encore ouvertes) | 9 / 16 / 6 | 33 / 1 / 2 |
| Cartes « Merge à valider » | 23 | 26 |
| Lignes « À traiter » créées | 229 | 88 |
| … dont questions d'agents ou du pilote | 170 | 54 |
| Lignes fermées par le geste du développeur (carte, sélecteur de l'agent, phrase dans le terminal, plan, main, merge de sa main) | 38 | 59 |
| **Cartes et lignes montrées par jour actif** | **36** | **26** |
| **Gestes estimés dans Tao par jour actif** (un clic par carte tranchée, deux pour un merge) | **15** | **23** |
| Lignes « À traiter » encore ouvertes (03/11, 11 h 10) | 28 | 7 |
| Questions du tri du matin sans réponse | 17 | 2 |

**Comment se ferment les questions de Tom.** Il y en a 158 fermées, dont 9 doublons, donc 149 distinctes. Le décompte suit la raison de fermeture enregistrée, pas l'acteur affiché. La relecture contradictoire a montré que l'acteur trompe : un choix fait par Tom dans le sélecteur de l'agent est noté « serveur ».

| Raison | Nombre |
|---|---:|
| L'agent a poursuivi ou accusé réception de lui-même | 94 |
| Tao a répondu à l'agent, ou l'a vu retravailler | 19 |
| Tâche terminée ou session fermée | 7 |
| Autre geste de Tao | 1 |
| Doublon écarté par Tao | 9 |
| **Tom** : dans le sélecteur de l'agent | **14** |
| **Tom** : par une phrase dans le terminal | **5** |
| **Tom** : par une carte (dont 1 écartée) | **9** |

Environ 81 % des questions distinctes (121 sur 149) se règlent donc sans Tom. Sur 28 réponses de Tom, 19 se font dans le terminal de l'agent et 9 par une carte de Tao.

**Les 28 lignes ouvertes de Tom le 03/11 à 11 h 10** (il y en avait 32 à midi) :
- 10 merges : 5 sur des tâches terminées ou des sessions fermées (du 02/10 au 12/10), 5 sur des tâches encore en relecture de merge (PR Covalba #99 à #102 du 21/10, et une PR du 26/10) ;
- 4 questions de la tâche #80, du 09/10 au 16/10, sans aucun événement depuis le 26/10 ;
- 1 blocage du 22/10 ;
- 13 questions de moins d'une semaine.

**Lecture.**
- Tom ne tranche qu'environ 15 gestes par jour dans Tao, mais il voit 36 cartes et lignes, dont la plupart se règlent sans lui ou ont vieilli.
- Quand une question lui parvient vraiment, il y répond surtout là où travaille l'agent : l'en-tête du terminal est le bon endroit et doit le rester.
- Nico, lui, répond dans les cartes : 29 questions et 21 merges fermés de sa main. Le mode doit donc rester un choix par développeur.

**Limites de la mesure.**
- Les gestes dans Tao sont estimés d'après les états des cartes, car aucun compteur de clics n'existe aujourd'hui. Le lot 1 en ajoutera un.
- Un merge fait hors de Tao, puis vu par le serveur, compte comme « fermé par le serveur ».
- Les accords purs tapés dans le chat sont rares aujourd'hui : 2 sur 162 messages (« go », « oui 127 »). Mais un « oui » tapé ne lance rien aujourd'hui, et sa valeur n'est donc pas mesurable avant d'exister.

## 4. Comparaison

| Sujet | Rerun | Tao aujourd'hui | Écart, et piste pour Tao |
|---|---|---|---|
| Qui décide qu'un accord est nécessaire | Le modèle, par une consigne du prompt ; peu de gardes serveur | Le serveur : cartes obligatoires, types qui ne se valident que par un clic (`pr.merge`, `deploy.grant`, `planning.place`, `learning.compact`), compréhension avant tout lancement | Tao est plus sûr, mais il demande tout. **Une table de risque serveur à trois niveaux** au lieu d'une carte pour tout |
| Feu vert permanent | Phrase de l'utilisateur, appliquée par le modèle, sans trace | Seulement l'accord de merge et déploiement pour toute une tâche (case au lancement, ou phrase relayée `portee=tache`) | **Un feu vert vérifié** (phrase mot pour mot, portée, durée, révocable) pour les gestes à risque modéré |
| Réponse tapée | Clôt une question ; impossible pour une approbation (champ masqué) | Clôt une question (« lu dans ton message »). Un « oui » court confirme une compréhension, mais ne lance rien (décision E9) | **Un « oui / vas-y » vérifié** qui tranche la seule carte ouverte du tour précédent |
| Où sont les validations | Dans le fil, un bloc sous le dernier tour, et une pastille | Dans « À traiter » (une liste à part) et « Propositions à cocher ». Le fil n'a qu'un résumé d'une ligne, sauf sur mobile | **Les cartes dans le fil**, une pastille « N en attente », et « À traiter » réduit à un index |
| Lot de décisions | Une carte par tour, une décision par ligne | La carte unique « compris et lancé » regroupe déjà les lancements d'un tour ; les autres cartes sont séparées | Étendre le lot aux cartes d'action du même tour |
| Ce qui remonte | Un seul ensemble de statuts « attend l'humain » | Toute question d'agent ouvre une ligne, même si l'agent continue ou si le pilote répond | **Ne remonter que ce qui attend vraiment Tom** : question à l'écran, question remontée par Tao, plan, merge, blocage, et question d'agent au repos depuis 10 min |
| Vieillissement | Pas d'expiration | Les cartes expirent à minuit. Le serveur ferme déjà les questions d'une session fermée, mais pas les merges : un merge du 02/10 est toujours là | **Ranger d'office** les merges d'une tâche finie et ce qui n'a pas bougé depuis 7 jours, avec une trace et « Rouvrir » |
| Reçu | La carte répondue devient un reçu dans le fil | La carte traitée devient une ligne dans le fil (« Plan validé par toi · 14:41 ») | Déjà proche. À garder |
| Entretien et compréhension | Budget fixe, jamais en prose, jamais redemander | Une carte de compréhension avant chaque lancement (55 en 11 jours) | **Une compréhension légère** : reformulation en une à trois lignes dans la réponse, et carte seulement pour plusieurs points ou une ambiguïté |
| Règles apprises | Proposition de skill dans le fil, d'un clic, sans arrêt | Leçons de Tao (`tao_learning_add`), compactées par une carte | Montrer la leçon proposée dans le fil, d'un clic |
| Agir en l'absence de l'utilisateur | Annoncé, mais absent du code open source | Le pilote de Tao répond déjà aux agents selon la main, la présence et le réglage de la tâche ; il a tranché 34 questions | **Expliciter les règles** que Tao applique, et faire un résumé au retour de Tom |
| Secrets | Formulaire masqué ; l'agent ne voit que le nom | Coffre `paf-vault`, `api_key_call` ; jamais dans le chat | Déjà au niveau. Rien à changer |
| Merge et mise en prod | Sans objet | Clic en deux temps ; garde qui observe ; accord pour toute la tâche | Non négociable : la décision reste à Tom |

## 5. Ce qu'on ne reprend pas, et pourquoi

- **La classification confiée au seul modèle.** Le serveur de Tao vérifie, et il continuera de le faire : merge, mise en prod, gestes destructifs, coffre, envois.
- **Le champ de saisie masqué pendant une approbation.** C'est l'inverse de « juste dire les trucs ».
- **L'inbox où l'on ne peut rien faire.** Le principe d'un index est repris, mais une ligne de Tao garde un bouton quand la décision tient en un geste (un merge en deux temps, par exemple).
- **Les webhooks sans signature, l'index vectoriel, le board spatial et le parcours commercial du Foreman.**
- **Tout code.** Rerun est sous AGPL-3.0 : les principes sont repris, et l'implémentation de Tao est écrite à partir de son propre code.