Jarvis

en attente
Objectif

Organiser ce que l’on veut faire advenir, aider à le piloter dans le temps, et conserver la mémoire de ce qui s’est réellement passé.

Situation

Jalon 1 — un projet réel est compréhensible et réactif attend l’owner. Jalon suivant pourra commencer après sa réponse.

Étapes

Lire un projet, naviguer, comprendre ce qui attend quoi, consigner un fait, voir les conséquences ; sur Pergola et CookEase, desktop et mobile.

En attente de
  • Le jalon 1 est statué par l’owner
Puis
Décisions
Deux environnements tournent — `main` en prod, `dev` en branche de release — et rien de ce dispositif n’est écrit dans le dépôt : ni quand `dev` revient dans `main`, ni sur quoi rebasent les quatre MR ouvertes, aujourd’hui empilées sur une branche déjà mergée
attend l’owner
Le jalon 1 est statué par l’owner
retient « Jalon suivant »
attend l’owner
Questions ouvertes
La veille reste-t-elle silencieuse et sans boucle à l’usage ? C’est un critère de gate, pas un détail technique
à rattacher
Objectif / Situation / Étapes / Projets / Journal est-il un écran universel ? Jarvis le réfute peut-être
à rattacher
Quelle représentation ferait qu’ouvrir Jarvis suffise à voir le chantier courant, ce qui vient d’être terminé et ce qui vient ensuite ? Aujourd’hui l’owner a dû le demander, et les runs d’agents n’apparaissent nulle part
à rattacher
Rien n’indique quel commit l’instance de dev sert : comment savoir qu’elle ne dérive pas de la branche ?
à rattacher
Une boucle qui se relance elle-même entre deux chantiers reste-t-elle silencieuse et bornée, ou finit-elle par tourner à vide sans que personne le voie ? (O-006 tranchée, mécanisme à éprouver)
à rattacher
Une roadmap est une suite ordonnée de chantiers. Les chantiers sont des projets enfants, et entre projets enfants le modèle n’a ni ordre ni dépendance : « ce qui vient ensuite » n’est nulle part
à rattacher
Projets
Lire un projetimplémentéMR · test · endpoint
Comprendre un projet par Objectif, Situation, Étapes, Projets et Journal, sans connaître le modèle.
Dériver la situation depuis les donnéesimplémentéMR · test · fichier
Aucune phrase d’état n’est écrite à la main : la situation, ce qui attend, ce qui retient, se calculent.
Consigner un faitimplémentéMR · test · endpoint
Un seul geste d’écriture : un fait, qui peut répondre à une attente et terminer une étape. L’écran suit.
Voir ce qu’une étape attend et ce qu’elle débloqueimplémentéMR · fichier
Déplier une étape : en attente de, après, puis. La causalité sans le vocabulaire du graphe.
Piloter Jarvis avec JarvisimplémentéMR · fichier · document · lien
Le projet Jarvis dans l’application, avec ses capacités, leur état déclaré et leurs preuves.
Créer et modifier un projet depuis Jarvisprévu
Décrire un projet — au minimum son nom, sa vision et son objectif courant — et le faire évoluer, sans apprendre le modèle. Chantier 3 de la roadmap (D-032).
Faire remonter une conséquence au parentprévu
Le parent rend compte de la conséquence pour son propre objectif — pas une copie du journal de l’enfant.
Observer le dépôt plutôt que déclarerprévu
Jarvis lit les MR mergées, les tests, les endpoints, et propose les faits ; l’humain confirme.
Sécuriser l’accès à Jarvisprévu
Une personne non authentifiée ne peut ni lire ni modifier les données Jarvis, sur l’instance déployée. Chantier 1 de la roadmap (D-031, D-032).
Distinguer vision, objectif courant et jalonsen cours
Comprendre rapidement où en est un projet : sa vision, ce qui compte maintenant, le jalon en cours et ce qui vient ensuite. Chantier 2 de la roadmap (D-027, D-032).
Créer et faire évoluer les jalonsprévu
Définir le jalon courant, le franchir, et voir ce qu’il débloque et ce qui vient ensuite. Chantier 4 de la roadmap (D-032).
Garder l’état saisi dans l’interfaceprévu
Ce qui est décidé dans Jarvis devient la réalité du projet, et cesse d’être écrasé par un seed ou un redéploiement. Chantier 5 de la roadmap (D-032).
Voir les runs d’agents dans Jarvisprévu
Pour chaque run : actif, terminé ou bloqué, l’instruction qui l’a déclenché, la MR ou le résultat associé. Minimal, pas un orchestrateur. Chantier 6 de la roadmap (D-032).
Donner une instruction à Claude depuis Jarvisprévu
Un geste simple dans Jarvis déclenche un run d’agent sur le nœud d’exécution permanent. Chantier 7 de la roadmap (D-029, D-032).
Boucler le dogfooding depuis Jarvisprévu
Voir le jalon, demander une évolution, voir l’agent travailler, voir le résultat, valider, et voir l’état de Jarvis bouger — sans quitter Jarvis. Chantier 8 de la roadmap (D-032).
Journal
6 septembre 2026

Dérive constatée sur l’instance de pilotage : elle servait bien le code de la branche, mais sa base n’avait pas été vidée après le changement de fixtures. L’owner y lisait huit capacités et l’ancien nom d’un chantier, au lieu des quinze que la branche déclare — donc pas la roadmap qu’il avait demandé d’y voir.

conséquenceLe risque écrit dans DEPLOIEMENT.md — « si l’instance dérive, l’owner pilote sur un état faux sans aucun moyen de le voir » — s’est réalisé, et par le pas que la procédure signale déjà. Base vidée et instance reconstruite ; ce qui reste manquant est l’indication du commit et des données servis, à l’écran.
documentmettre à jour l’instancelienl’instance de pilotage
constaté par Claude
6 septembre 2026

Un gate objectif automatisé est entré dans la boucle : Codex a relu cinq commits successifs de la MR #8, rendu quatre fois GATE: CHANGES puis une fois GATE: PASS. L’owner a mergé seize secondes après le PASS.

conséquenceCodex a trouvé quatre défauts que l’auteur n’avait pas vus — une contradiction interne dans ETAT.md, une permission supplantée restée valide dans D-032, un prompt encore aligné sur l’ancienne règle d’escalade, et l’absence de preuve visuelle. Son mandat n’est écrit dans aucune branche mergée : il vit dans les MR #10 et #11, ouvertes, et son script ne tourne que sur le VPS.
lienGATE: PASS du 6 septembreMRMR #11, le mandat non mergé
constaté par Codex
6 septembre 2026

Rétrospective de méthode mergée : la MR #8 remet ETAT.md, la roadmap et Jarvis-dans-Jarvis d’équerre, et inscrit D-031, D-032 et D-033. L’owner l’a rebasée sur `dev` et mergée là, pas sur `main`.

conséquence`main` a dix commits de retard sur `dev`. Le dispositif est cohérent — deux instances, `main` en prod et `dev` en release — mais il ne vit que sur le VPS : le dépôt décrit encore une seule instance, et cinq passages prescrivent une MR « issue de main ». Quatre MR ouvertes attendent de savoir sur quoi rebaser.
MRMR #8, mergée eda14a6documentD-033
constaté par Cyril O.
5 septembre 2026

Correction de gouvernance owner : une roadmap validée est un mandat d’exécution, pas seulement une direction à documenter. Un chantier s’y prend sans redemander l’autorisation, une MR terminée n’est pas un point d’arrêt, et on n’escalade que pour cinq cas — vision ou ordre de roadmap, choix produit ou architecture significatif, opération destructive, risque de sécurité, décision difficilement réversible.

conséquenceLa doctrine était en retard sur le mandat : l’agent avait écrit la roadmap, nommé le trou d’enchaînement, et s’était arrêté en attendant une permission déjà accordée. O-006 est tranchée du même coup : la reprise entre chantiers se mécanise au lieu de rester prescrite.
documentD-033liencorrection owner du 5 septembre
constaté par Cyril O.
5 septembre 2026

Direction owner : une roadmap ordonnée de huit chantiers devient la direction de travail — de l’accès privé jusqu’à la boucle complète de dogfooding — et elle doit se lire dans Jarvis lui-même, pas seulement dans le dépôt. Le mode de travail passe en petits incréments enchaînés, sans arrêt entre chaque micro-étape.

conséquenceLes huit chantiers entrent comme capacités du projet. Leur ordre n’entre pas : entre projets enfants le modèle n’a ni ordre ni dépendance, et faire porter la suite par les jalons referait la confusion tranchée par D-027. La difficulté est consignée en question ouverte, comme l’owner l’a demandé.
documentD-032liendirection owner du 5 septembre
constaté par Cyril O.
5 septembre 2026

La veille GitHub est en service : trois cycles complets — commentaire humain, accusé de réception, agent lancé, réponse sur la MR — ont eu lieu le 5 septembre sans intervention, dont le merge de la MR #7 qui a déclenché seul la rétrospective de méthode.

conséquenceLa même classe de défaut a été trouvée trois fois : ce qui rendait l’environnement correct venait d’ailleurs et n’était pas dit. La chaîne de lancement, ce n’est pas le binaire de l’agent, c’est tout ce dont l’agent a besoin pour tenir ses propres règles.
MRMR #7, mergée 89a2a11documentD-030fichiertools/veille/veille-github.sh
constaté par Claude