GenCodeDoc

Idée

L'historique d'un projet est une mémoire exploitable par les agents, pas seulement un journal de sauvegardes.

Problème

Les agents et les humains perdent le fil des états successifs d'un projet : rejouer, comparer ou restaurer une partie précise du travail devient impossible sans historique structuré.

Pourquoi une solution classique ne suffisait pas

Le versionnage classique suit des fichiers, pas l'état du projet tel qu'un agent le perçoit ; la restauration est totale ou rien, et rien n'est prévu pour qu'un agent interroge l'historique.

Mécanisme original

Snapshots content-addressed avec déduplication : chaque état est adressé par son contenu, les différences sont calculées, et un agent peut restaurer une partie précise du contexte via un accès dédié (MCP).

Difficultés

• Déduplication sans perdre l'information de temporalité
• Diff fiable entre états de projet hétérogènes
• Restauration partielle sans casser les dépendances

Choix techniques

Résultat actuel

Les snapshots, diffs et restaurations fonctionnent ; les checkpoints automatiques sont actifs. La documentation projet est générée à partir de ces états. (Les fonctions de markdown dynamique futures ne sont pas encore implémentées.)

Ce que ce projet nous a appris

Les snapshots, diffs et restaurations fonctionnent ; les checkpoints automatiques sont actifs. La documentation projet est générée à partir de ces états. (Les fonctions de markdown dynamique futures ne sont pas encore implémentées.)

Agents -> API snapshots (content-addressed) -> index dédupliqué -> diff / restauration scopée