GBrain — thin CLI + SQLite + MCP comme alternative au knowledge base fichier¶
Resume¶
Garry Tan publie la spec de GBrain, l'evolution de son "Karpathy-style git wiki knowledge base" apres que celui-ci ait atteint 2.3 GB (la limite git pratique est 5 GB). L'architecture en trois couches : un CLI mince (~500 lignes TypeScript sur Bun), une base SQLite unique avec FTS5 (recherche texte) + vecteurs 1536D (sqlite-vec), et des skills gras (fichiers Markdown contenant les workflows intelligents). Le modele de donnees suit un pattern "compiled truth + timeline" — contenu actualise en haut, historique append-only en bas. Embeddings estimes a ~0,50 $ pour 50K pages. MIT license a venir. La spec a ete generee en un prompt via son skill /autoplan (qui fait CEO review, Eng review, Developer Experience review) sur GStack, son propre framework Claude Code.
Analyse critique¶
Ce qui est juste
Le point de depart est une contrainte reelle : git n'est pas conçu pour des knowledge bases qui grossissent en continu. 7 471 fichiers Markdown sur 2.3 GB, c'est exactement le regime ou git commence a ramer (pack files qui explosent, clone lent, diff inutile sur du contenu append-only). Garry touche une limite que tous ceux qui font du "second brain" Markdown finiront par rencontrer.
Les choix techniques sont pragmatiques :
| Choix | Alternative evitee | Justification |
|---|---|---|
| SQLite unique | Postgres + pgvector | Pas de serveur, un fichier, backup trivial |
| FTS5 + sqlite-vec | Vector DB externe (Qdrant, Chroma) | Colocation recherche texte + semantique, zero dependance reseau |
| Bun runtime | Node, Deno | Demarrage CLI quasi-instantane |
| Thin CLI / fat skills | CLI monolithique | Les skills (Markdown) pilotent le workflow, le CLI fait juste les primitives |
| MCP pour l'integration | API REST custom | Reutilise le protocole Claude Code natif |
Le pattern "compiled truth + timeline" est la vraie contribution conceptuelle. Au lieu de maintenir une verite unique qui se reecrit (perte d'historique) ou un log append-only qu'il faut reparser (lent), on a les deux : le resume a jour en tete, l'historique immuable en queue. C'est ce que fait un bon journal de bord scientifique.
Ce qui est discutable
- Le "spec en un prompt via /autoplan" est un argument marketing pour GStack plus qu'une caracteristique de GBrain. Une spec architecturale merite une lecture humaine critique, pas un one-shot LLM. C'est coherent avec notre retour sur "LLM = code plausible, pas correct" (fiche katanaquant 2026-04-08).
- Pas encore de code au moment ou on l'archive : c'est une spec, pas une implementation. A reverifier quand le repo MIT sera publie.
- Lock-in SQLite : passer de fichiers plats a SQLite rend le corpus moins inspectable (plus de
greptrivial, plus de diff git lisible). C'est un trade-off reel pour qui veut garder le contenu "human-readable by default". - Embeddings a 0.50 $ / 50K pages suppose OpenAI text-embedding-3-small. Avec BGE-M3 local sur l'IA-Server (cf. mail-search-mcp), ce cout tombe a zero — mais il faut l'infra GPU.
Le signal faible : la spec confirme (avec celle de Linkly AI et AIOS mentionnes dans les commentaires) une convergence de l'industrie vers le meme pattern. Le "thin binary + fat Markdown" est en train de devenir l'architecture par defaut des knowledge bases d'agents.
Pertinence ProbatioVault¶
Impact modere — GBrain n'est pas une urgence, mais c'est une alternative architecturale a surveiller pour notre stockage fichier quand il grossira.
Comparaison directe avec l'existant¶
Notre stack actuelle ressemble deja beaucoup a GBrain, version pre-SQLite :
| Composant | ProbatioVault actuel | GBrain | Delta |
|---|---|---|---|
| Sources brutes | docs/epics/**/*.md (specs, plans, rex) | raw/ | Identique |
| Index structure | data/specs-index/**/*.yaml | DB tables | Plus rigide mais plus inspectable chez nous |
| Recherche plein texte | grep / Grep tool | FTS5 | GBrain gagne a grande echelle |
| Recherche semantique | FAISS + Ollama BGE-M3 (311 learnings, 221 contracts, 106 specs, 102 plans) | sqlite-vec 1536D | On est deja fait |
| Health check | /coherence (Prolog L1+L2, 86.9%) | A implementer chez Garry | On a une longueur d'avance |
| Schema | CLAUDE.md + CONSTITUTIONAL.md | CLAUDE.md (meme nom) | Identique |
| Compounding | /gov-compounder (metrics + learnings) | A implementer | On a une longueur d'avance |
Autrement dit : on est deja GBrain, en version git + FAISS au lieu de SQLite. La question n'est pas "faut-il migrer" mais "a quel moment git deviendra-t-il le goulot".
Quand envisager la bascule SQLite¶
Signaux a surveiller :
- Taille du repo
ia-governance> 2 GB (on est aujourd'hui autour de quelques centaines de MB — marge confortable). - Temps de clone CI qui explose sur GitLab (on n'en est pas la).
- FAISS index qui devient trop volumineux a recharger entre sessions (
data/learnings-index.faiss, actuellement modeste). - Besoin de requetes plein texte cross-fichiers plus frequentes que ce que
grepgere (aujourd'hui,grepsuffit largement).
Tant que ces seuils ne sont pas franchis, migrer est un refactor sans ROI. Notre atout majeur c'est l'inspectabilite git : chaque modification est diffable, blame-able, reviewable en MR. Perdre ca pour gagner de la vitesse n'a de sens qu'au-dela d'un seuil critique.
Ce qu'on peut piquer tout de suite a GBrain¶
Meme sans migrer, deux idees sont directement transposables :
- Le pattern "compiled truth + timeline" dans
data/learnings.jsonl: aujourd'hui on a un log append-only. On pourrait ajouter undata/learnings-compiled.mdqui donne l'etat a jour synthetise (regenerable depuis le JSONL), avec les doublons dedupliques et les contradictions flaggees. Symbiose avec le TODO #25 (confidence scoring) et TODO #28 (mesure compounding). - MCP comme interface unifiee pour exposer
data/specs-index/a Claude Code, au lieu de passer par des scripts shell de lecture. Aligne avec notre usage deja croissant de MCP (Atlassian, potentiellement interne).
Action recommandee¶
Pas de story dediee maintenant. Ajouter une ligne de veille dans le TODO (nouvelle section "Evolutions stockage") : "Reevaluer SQLite FTS5 + sqlite-vec quand data/ > 2 GB OU quand le temps de reindexation FAISS depasse 30 s". Verifier le repo MIT de GBrain quand il est publie pour voir si le code vaut le coup d'etre fork (notamment pour le pattern compiled/timeline en SQL).