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
Le jalon 1 est statué par l’owner
retient « Jalon suivant »
attend l’owner
Questions ouvertes
Faut-il automatiser la veille des retours sur les MR ? Le mécanisme est cadré (O-005), il revient sur une règle écrite
à rattacher
Objectif / Situation / Étapes / Projets / Journal est-il un écran universel ? Jarvis le réfute peut-être
à rattacher
Rien n’indique quel commit l’instance de dev sert : comment savoir qu’elle ne dérive pas de la branche ?
à 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 Jarvisen cours
Le projet Jarvis dans l’application, avec ses capacités, leur état déclaré et leurs preuves.
Créer un projet depuis l’interfaceprévu
Décrire ce qu’on veut faire advenir et obtenir une organisation, sans apprendre le modèle.
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.
Journal
5 septembre 2026

Direction owner : une instance de dev déployée sert la branche de l’itération en cours, et c’est là que l’owner juge — il ne lance pas la stack lui-même.

conséquenceLe gate produit devient praticable sans machine de développement ; la surface de pilotage cesse d’être du périmètre d’expérience, et les règles qui la bloquaient sont corrigées.
documentD-029lienl’instance de dev
constaté par Cyril O.
4 septembre 2026

Direction owner : une MR validée se termine par une rétrospective de méthode — qu’avons-nous appris qui doit changer la façon de travailler ? Et un élément de preuve n’est pas une validation.

conséquenceLa boucle gagne un pas après la décision owner ; « prouvé » quitte le vocabulaire.
documentD-028lienrevue
constaté par Cyril O.
4 septembre 2026

Arbitrage owner : un projet a une vision et un objectif courant ; un jalon n’est pas une étape de travail — il débloque des éléments et des actions.

conséquenceLa question passe de « faut-il distinguer » à « comment ça entre dans la primitive » : cadrage de l’itération 4.
documentD-027
constaté par Cyril O.
4 septembre 2026

Direction owner : Jarvis est la représentation exécutable de son propre état. Chaque MR se demande si elle change ce que Jarvis dit de Jarvis, et met à jour ses données.

conséquenceLes fixtures sont le snapshot de l’état du projet sur la branche ; la synchronisation reste manuelle, avant toute automatisation.
documentD-025liencommentaire owner
constaté par Cyril O.
4 septembre 2026

Gate produit de l’itération 2 validé par l’owner ; MR #4 mergée.

conséquenceLe statut du jalon 1 reste à énoncer.
MRMR #4
constaté par Cyril O.
2 septembre 2026

Itération 1 close : le mécanisme est validé, le produit ne l’est pas, le code n’entre pas dans main.

conséquenceUne expérience peut apprendre sans mériter le merge (D-021).
MRMR #2, ferméeMRMR #3, apprentissages
constaté par Cyril O.