La reprise d’une modification d’ordonnanceur pourrait commencer par cette fiche :
Objectif : suspendre l’accueil de nouvelles tâches en laissant finir les imports en cours.
Livrable : correctif central enregistré ; interface en ligne de commande encore déconnectée.
Conflit : le correctif annule les tâches actives ; les tests valident également cet ancien comportement.
Suite : corriger le sens de la suspension, puis poursuivre le raccordement.
Exécutant : aucun.
Aucun Agent ne tourne, mais le travail garde un état explicite. Avant même de lire la conversation précédente, la relève peut identifier le défaut principal : le code contredit l’objectif actuel et le raccorder exposerait ce comportement erroné aux utilisateurs.
Cette fiche est un exemple pédagogique du modèle Work proposé par Flowness dans le commit public c9d6abe. Cette version classe encore la continuité complète entre Agents comme conception ; l’exemple ne décrit pas une exécution achevée. Conception et état des preuves
Derrière l’adresse, retrouver les fondements
Work donne une entrée stable pour consulter un travail durable. Un identifiant aide à le trouver, sans garantir que ce qu’on ouvre reflète les faits actuels.
Flowness conçoit Work comme une projection des enregistrements sous-jacents. Le code reste dans le dépôt, les tests pointent vers leur version, jugements et changements dans les événements. La vue les rassemble. Si le correctif change, elle doit préciser quelle version a été testée, au-delà d’un simple voyant vert.
La vue porte aussi une position temporelle. as_of_seq indique jusqu’à quel événement elle a été agrégée. Si elle s’arrête à 147 et que le responsable modifie l’exigence de suspension à 148, le système peut reconnaître qu’elle n’intègre pas cette décision. Conception de WorkView
Cette entrée peut soutenir l’action plus solidement qu’un résumé de passation. Un résumé explique le raisonnement d’alors ; la vue actuelle doit aussi reconnaître les explications remplacées depuis.
Après interruption, il faut d’abord vérifier ce qui subsiste : l’ancienne exécution est-elle arrêtée, le correctif commité, quels fichiers restent temporaires et quels résultats vérifiés ? La reprise dépend de cet état, pas de l’estimation « presque fini » de l’Agent précédent.
Ensuite vient le contexte de la prochaine action. Flowness appelle cet ensemble Context Capsule : à un point factuel déterminé, sélectionner objectif, versions, contraintes valides, livrables et problèmes. Dans l’exemple, la priorité est le conflit sur la suspension ; tout l’historique peut noyer les pièces décisives. Vérification de l’état et compilation du contexte
Un nouvel Agent démarre sa propre exécution sur le même Work. Ses résultats vérifiés alimentent la prochaine consultation.
Quand les prémisses changent, relire ce qui était terminé
La suspension a peut-être d’abord été comprise comme « arrêter toutes les tâches ». Le responsable précise ensuite que les imports actifs doivent finir. Le changement dépasse la description de tâche.
Les anciens tests passent, mais valident l’annulation. Code central, assertions et aide de commande peuvent dépendre de cette même prémisse. Le format de journalisation sans rapport avec la suspension n’a pas forcément à être refait.
Le système doit donc conserver deux dépendances : l’ordre d’exécution des tâches et la version d’interprétation sur laquelle repose chaque livrable. La première dit que le raccordement suit les tests ; la seconde révèle que leur exigence est devenue obsolète.
Flowness nomme Finding une observation qui change la suite, puis Reflow localise prémisses et dépendances affectées pour réorganiser le travail. Ici : « L’implémentation centrale annule les imports en cours, contrairement à l’exigence actuelle. » Le plan revient au comportement central, vérifie ensuite que les tâches en vol finissent, puis raccorde la commande. Relation entre Finding et Reflow
Les livrables existants restent conservés ; ce qu’ils permettent d’affirmer change. L’ancien test explique l’histoire, sans étayer la satisfaction de la nouvelle exigence.
Le gain d’une reprise locale dépend de la précision des dépendances. Une relation manquante demande enquête ; un périmètre incertain peut rendre une vérification élargie moins coûteuse qu’une classification fine. Il faut donc tester cette conception dans des modifications réelles : combien de faux départs évite-t-elle, pour quel coût d’enregistrement ?
L’exécution persistante dispose déjà d’outils mûrs. Temporal reconstruit l’état depuis l’historique et reçoit Signal, Update et autres entrées. LangGraph conserve états de graphe et données entre fils par checkpoints et stockage persistant. Workflows Temporal, messages, persistance LangGraph
Work porte sur l’interprétation de l’état conservé : version de l’objectif, jugements remplacés, livrables touchés, matériaux nécessaires maintenant. Ces règles peuvent reposer sur un moteur existant. Si tickets, dépôt et workflow conservent déjà les relations complètes, une base parallèle ajoute surtout de la synchronisation.
L’adresse reste utile après « terminé »
Corriger la logique centrale ne fait pas disparaître la suite. Flowness distingue quatre états et leurs actions de continuation :
| État | Sens dans l’exemple |
|---|---|
| Construit (built) | Un livrable de suspension vérifiable existe. |
| Intégré (integrated) | La commande et le chemin d’appel réel sont raccordés. |
| Activé en usage réel (activated) | L’usage naturel dans l’environnement cible appelle effectivement la capacité. |
| Accepté (accepted) | La personne chargée de la réception confirme l’adéquation au besoin. |
L’activation exclut tests, démonstrations, répétitions et simple déploiement. L’acceptation doit elle aussi désigner précisément la version reconnue. Définitions d’activation et d’acceptation
L’attente devient concrète : la fonction est intégrée mais aucun besoin de suspension n’est survenu, ou elle a servi sans encore être réceptionnée. Inutile de faire tourner un Agent en continu ; il suffit de conserver événement attendu, personne responsable et condition de réexamen.
Quand la condition arrive, on rouvre le même Work, vérifie la version actuelle et commence l’action suivante. La spécification publique de démonstration prépare justement ce test : un nouvel exécutant peut-il reprendre depuis l’état durable après interruption, sans mémoire temporaire de l’ancien Agent ? Spécification de passation
Pour la maintenance, cette adresse doit finalement répondre à une question pratique : si je reprends l’ordonnanceur aujourd’hui, où commencer ? Continuer à y répondre permet au travail de traverser fins de session, changements de personnes et évolutions du besoin.