Gate rendu : l’owner a jugé l’écran et fait merger la MR #5 — sans conclure que la représentation de Jarvis est satisfaisante. Il y lit encore mal la vision, la situation réelle, ce qui compte maintenant et ce qui vient ensuite.
Piloter Jarvis avec Jarvis
implémenté MR · fichier · document · lienObjectif
Le projet Jarvis dans l’application, avec ses capacités, leur état déclaré et leurs preuves.
Situation
Tout est terminé.
Une capacité est-elle un projet, ou le mot gêne-t-il ?
concerne « Validation »5 septembre 2026
conséquenceLa capacité est livrée et jugée ; ce qu’elle ne donne pas encore reste l’apprentissage de l’itération, pas un défaut masqué par le merge.
✓ a terminé « Validation »
constaté par Claude
4 septembre 2026
Revue : l’écran Jarvis est un contre-exemple utile — l’objectif affiché est la vision, les étapes mélangent fondation et jalons, la situation est trop pauvre, et une pièce jointe ne vaut pas preuve.
conséquenceLe mot « prouvé » disparaît : une capacité nomme ses éléments de preuve, l’owner juge. Le reste devient une question de cadrage, pas une retouche.
lienrevue du 4 septembredocument
ce que Jarvis-dans-Jarvis révèleconstaté par Claude
4 septembre 2026
La question « ce travail change-t-il ce que Jarvis dit de Jarvis ? » entre dans le workflow ; les données du projet Jarvis sont remises à jour dans la MR #5.
conséquenceUne divergence entre Jarvis et le dépôt est désormais un défaut à corriger.
document
le contrôle de fin de MRMRMR #5constaté par Claude
4 septembre 2026
Le projet Jarvis et ses capacités entrent en fixture ; les preuves sont des pièces sur les faits.
MRMR #5fichier
apps/api/src/fixtures/jarvis.tsconstaté par Claude
3 septembre 2026
Direction owner : Jarvis est le premier projet piloté par Jarvis ; état déclaré ≠ état observé.
conséquenceToute capacité de pilotage sert à piloter Jarvis lui-même.
✓ a terminé « Cadrage »
document
D-024liencommentaire ownerconstaté par Claude