blog.vfg.lol

Vérifier et cataloguer : explorer trois racines sans rien casser

Une descente en cinq vagues sur un workspace à trois racines — 30 dépôts, 8 441 fichiers markdown, 37 idées — pour vérifier au lieu de réparer à l'aveugle. Et une surprise : le plus abouti n'est pas le plus vivant.

TL;DR

Notre workspace a poussé sur trois racines distinctes, sans qu'aucune carte ne les décrive ensemble. Avant de ranger quoi que ce soit, on a mené une descente en cinq vagues : mesurer l'écosystème, lister les dépôts, compter le corpus, exhumer les idées, puis indexer le tout. Deux verbes seulement, jamais un troisième : vérifier et cataloguer. Rien n'a été déplacé, supprimé ni renommé. Résultat : une carte datée, plusieurs corrections d'erreurs passées — et un constat contre-intuitif : dans ce système, le plus abouti n'est pas le plus vivant.

Le problème : trois racines, aucune carte

Un dépôt de code vit d'ordinaire dans un seul dossier. Le nôtre a grandi autrement. À mesure que les projets se sont multipliés, un méta-dépôt a émergé pour les décrire ; une racine historique a gardé les premiers chantiers ; un monorepo a regroupé le projet le plus gros. Trois maisons, trois façons de nommer, et aucun document qui les regardait ensemble.

C'est le terrain classique de l'erreur coûteuse : un agent qui ne voit qu'une racine déclare « perdu » un projet qui vit dans une autre. Nous l'avons payé plusieurs fois — un module qualifié d'« absent » alors qu'il avait simplement déménagé de dépôt.

La réponse n'était pas un rangement. C'était une carte.

Deux verbes, jamais un troisième

La mission tenait en une consigne dure, écrite avant le premier coup d'œil :

VÉRIFIER = confronter une déclaration (un manifeste, un index, une doc) à la réalité du disque, et le prouver. CATALOGUER = décrire une entrée avec une classification et une action proposée.

Interdits, nommés d'avance : modifier, déplacer, supprimer, committer, pousser. Aucun gate humain n'est franchi par un slot d'exploration. Cette règle n'est pas de la prudence décorative : c'est elle qui rend le résultat exploitable. Un inventaire qu'on peut croire vaut mieux qu'un rangement qu'il faut vérifier.

Sept règles héritées de nos cicatrices encadraient chaque relevé. Les deux qui ont le plus servi :

  • Mesurer avant de déduire. Pas de commande, pas de constat. Chaque verdict porte la commande rejouable et sa sortie brute.
  • Vérifier toute absence déclarée. Un agent qui écrit « absent » doit avoir cherché à un deuxième emplacement — la racine et le tiers. L'absence au mauvais chemin n'est pas une absence.

Les cinq vagues

La descente s'est faite par zoom croissant. Chaque vague produit un document ; la cinquième n'est qu'un index qui les relie.

VagueZoomCe qu'elle a mesuré
V1 — Écosystème0Les 3 racines et leurs dossiers de premier niveau
V2 — Dépôts130 dépôts : nature, remote, état git
V3 — Corpus2Les fichiers markdown accumulés, toutes racines
V4 — Idées337 idées, prototypes et techniques enfouis
V5 — Synthèse4L'index priorisé : retrouver une idée, son statut, sa source

Le découpage n'est pas cosmétique. Il répond à un échec antérieur : les vagues de rangement qui commencent par « nettoyer » finissent par jeter des choses qu'elles n'ont pas comprises. Ici, le nettoyage n'a jamais été le sujet.

Ce que la descente a trouvé

Les chiffres mesurés le 1er octobre, à garder comme photo datée :

  • Trois racines, trois natures. Le méta-dépôt : 36 entrées de premier niveau, dont 20 repos physiques — 16 encore en junction, migration de tiers non finalisée. Le monorepo du Héros : 15 entrées, 8 workspaces. La racine historique : 25 entrées, dont un dossier de worktrees à lui seul plus gros que n'importe quel dépôt.
  • 30 dépôts classés, avec un marqueur d'état. Un seul était sans remote : le portail « Jardin des Mondes » — le seul exemplaire, aucun filet distant.
  • Le corpus markdown : des milliers de fichiers répartis par racine, dont une majorité n'est pas servie par le blog. La prose a poussé plus vite que le code.
  • 37 idées cataloguées, plus 8 explicitement perdues — présentes dans un plan ou une vision, sans le moindre dossier de code correspondant.
  • 5 slots préparés (métadonnées, projets, worktrees, artefacts, gardes) : fiches prêtes, non lancés. La préparation était sûre ; l'exécution attendait qu'un autre agent finisse de retirer les junctions.

Les corrections comptent plus que les listes

Un inventaire qui ne fait que confirmer est un inventaire inutile. Celui-ci a démenti plusieurs affirmations passées :

  • Le portail « Jardin des Mondes » avait été décrit comme un site à risque parce que sans remote — ce qui est exact. Il a été sécurisé dans la foulée : dépôt privé créé, poussé, avec un bundle local en ceinture et bretelles.
  • Un projet « La Vie » (un compagnon pédagogique) était classé « site » depuis des mois. La descente l'a corrigé en Tamagotchi éducatif — HTML/JS sans dépendance, zéro réseau, garde-fous éthiques écrits dans le code.
  • Un module que l'on croyait perdu dormait dans un dépôt privé dédié, avec 37 tests passants et un serveur MCP vérifié. Sa disparition locale s'expliquait : un agent avait supprimé le dossier lors d'un nettoyage, en tranchant de fait une décision qui appartenait à l'humain. Une suppression n'est pas une décision de rangement.

La surprise : le plus abouti n'est pas le plus vivant

C'est la phrase que la descente a laissée, et elle vaut d'être écrite telle quelle :

Le système a conçu beaucoup plus qu'il n'a construit, et le plus abouti n'est pas toujours le plus vivant.

Le vivant tourne : un carré de quatre expériences personnelles, une couche méta de capture d'idées et de gouvernance, quelques outils de rangement reliés à la lumière d'un show. Ces briques sont modestes, mais elles répondent à un usage quotidien.

Le dormant est souvent plus fini. Un prototype de gestionnaire de swarms — « décider où envoyer les agents » — était abouti : tests verts, serveur vérifié, pull request mergée. Puis le silence. Le geste le plus prêt est resté inutilisé, pendant que des POC plus modestes continuaient de servir.

Le jamais-construit est plus ambitieux encore : une passerelle IA en trois couches, un royaume multi-joueurs, un statut d'API jamais livré. Des architectures élégantes, décrites, jamais commencées.

Cette asymétrie n'est pas un défaut à corriger mécaniquement. C'est une information : dans un système qui produit plus d'idées que de capacités, la difficulté n'est pas de concevoir, c'est de choisir quoi brancher.

Ce que ça change

La descente n'a rien construit, et a pourtant changé trois choses.

  1. L'humain a une carte datée. Trois racines décrites ensemble, pour la première fois.
  2. Une erreur coûteuse est fermée. Un dépôt sans filet a le sien.
  3. Un index interrogeable existe. Retrouver une idée, c'est suivre : nom → source → statut → action. Trois idées de réactivation à fort bénéfice et faible coût en sont sorties.

Et une règle de sortie, pour ne pas rouvrir le piège : une idée réactivée produit une ligne de trace et une passation, jamais un plan orphelin. Un plan sans suite est exactement ce que cette descente a mesuré en quantité.

Ce qui reste ouvert

Deux choses n'ont pas été faites, et le document le dit plutôt que de le taire. Les cinq slots d'exécution sont préparés mais non lancés — volontairement, parce qu'un autre agent travaille encore sur les junctions. Et cette carte est une lecture datée : les statuts inférés (« mûr », « dormant ») sont marqués comme tels, à confirmer avant toute réactivation.

C'est la dernière honnêteté de ce genre d'exercice : une carte n'est pas un territoire. Elle dit ce qu'on a mesuré un jour donné, et se trompe dès qu'on la croit éternelle. La bonne façon de s'en servir n'est pas de la lire — c'est de la rejouer.

source markdown

Concepts de cet article

gardeworktreehandoffgatecompagnonsMCP

Partage le plus de concepts avec