D'un objectif à un plan que tu peux suivreD'un objectif à un plan que tu peux suivre

Le résultat est enregistré comme un plan avec une priorité et ses contraintes, puis découpé en tâches. Chaque tâche dit de quoi elle dépend et liste ses étapes. Chaque étape porte la vérification qui prouve qu'elle est faite.

Les plans, les tâches et les étapes sont enregistrés comme des données, pas comme du texte libre dans une conversation. Les écrans et l'exécuteur lisent les mêmes statuts.

Une tâche ne démarre que quand tout ce dont elle dépend est terminé. PO transforme ces liens en vagues : la vague 1 contient chaque tâche sans prérequis en attente, la vague 2 ce que la vague 1 débloque, et ainsi de suite.

Les tâches d'une même vague sont indépendantes, donc elles tournent en même temps. La plus longue chaîne de dépendances, le chemin critique, fixe le nombre minimal de vagues.

Avant une tâche, l'assistant lit la mémoire du projet : les notes (avertissements, consignes, modèles), les décisions avec leurs raisons et, pour un projet de code, le code autour des fichiers qu'il va toucher. Une recherche par le sens trouve d'abord les meilleurs résultats.

Ensuite PO suit les liens entre les notes. Une note qui ne correspondait pas à la question peut quand même apparaître, parce qu'une note qui correspondait lui est fortement liée. Le lien s'affaiblit à chaque pas, et les notes éteintes sont écartées.

plan(action: "run") lance l'exécuteur sur sa propre branche git. Pour chaque vague, il démarre une session d'agent par tâche éligible et les lance en parallèle, jusqu'à une limite (4 par défaut).

Chaque tâche reçoit une consigne construite à partir de la mémoire du projet : sa description, ses étapes et ses contraintes, les notes qui lui sont liées, la persona et les skills qui correspondent, et un résumé de ce que les vagues précédentes ont fait. Un garde-fou surveille la session (inactivité, appels répétés, délais) et envoie un indice quand l'agent dérive.

Quand une vague se termine, l'exécuteur la vérifie avant de lancer la suivante. Il contrôle que les agents ont produit des commits, que chaque étape est terminée ou sautée, que le projet compile et que le diff ne contient aucun fichier sensible.

L'exécution elle-même est une machine à états. Un protocole de cycle de vie passe de approved à executing puis à post_run, et chaque passage exige un déclencheur explicite. Une tâche dont l'agent échoue ou dépasse le délai est relancée une fois par défaut, avec l'erreur comme contexte.

Quand une tâche se termine, l'exécuteur réécrit sans appeler de modèle : il relie les commits à la tâche et au plan, crée une note de contexte à partir du journal git, et rattache les décisions aux fichiers qu'elles touchent.

L'assistant ajoute ce que lui seul sait : les décisions avec leurs alternatives, les avertissements, les modèles. Les notes utilisées ensemble se rapprochent. Les notes jamais utilisées perdent de l'énergie et deviennent périmées. Un épisode garde la demande, le chemin à travers les états et le résultat. Le plan suivant démarre à l'étape 3 avec tout cela.