Bricks Intel — Monorepo Intelligence¶

Un index structuré du monorepo, accessible aux agents IA et aux devs.

Le problème¶

Notre monorepo grandit :

	Aujourd'hui
Packages	18
Modules API	57
Conventions (Cursor rules `.mdc`)	17
API Endpoints	71
Fichiers utilisant uimmo	488

Trois problèmes concrets :

1. Les agents IA redécouvrent tout à chaque conversation¶

Quand on demande à Claude ou Cursor de créer un module, l'agent fait ~18 appels d'outils pour explorer la codebase : grep les conventions, lire des fichiers exemples, deviner les patterns. À chaque conversation. Depuis zéro.

2. Les conventions existent, mais sont dispersées¶

15 fichiers .mdc dans .cursor/rules/ (racine + bo/)
2 fichiers .mdc dans projects/api/.cursor/rules/
Des CLAUDE.md par projet
Les conventions dans la tête des devs

L'agent ne sait pas où chercher, et il ne trouve pas toujours la bonne convention.

3. Le onboarding est lent¶

Un nouveau dev doit absorber 18 packages, 57 modules, des conventions de styling (Uniwind), des patterns spécifiques (useModals, pas BricksBottomSheet), une stack backend en migration (Kysely+Zod vs legacy)... sans carte.

La vision : Bricks Intel¶

Un outil qui indexe le monorepo et expose un accès structuré à son intelligence :

┌─────────────┐     ┌──────────────┐     ┌─────────────────┐
│  Monorepo   │────▶│   Indexer    │────▶│  Index structuré │
│  (fichiers) │     │  (scanners)  │     │   (en mémoire)  │
└─────────────┘     └──────────────┘     └────────┬────────┘
                                                  │
                         ┌────────────────────────┼────────────────────┐
                         │                        │                    │
                    ┌────▼─────┐           ┌──────▼──────┐     ┌──────▼──────┐
                    │ MCP Tools │           │     CLI     │     │  Dashboard  │
                    │ (agents)  │           │   (devs)    │     │  (visuel)   │
                    └──────────┘           └─────────────┘     └─────────────┘
                     Priorité 1              Priorité 2          Priorité 3

Priorité immédiate : le MCP server — c'est ce qui a le plus d'impact pour la productivité quotidienne avec les agents IA.

Ce que ça change concrètement¶

Exemple 1 : "Crée un nouveau module espace-fi-borrower"¶

Aujourd'hui (sans Bricks Intel) :

Agent : grep pour trouver un module existant         → 5 tool calls
Agent : grep les conventions backend                  → 3 tool calls
Agent : lire les fichiers un par un                   → 10 tool calls
Agent : deviner les patterns (parfois faux)
Total : ~18 tool calls, contexte partiel, risque d'erreur

Avec Bricks Intel :

Agent : bricks-intel:get-convention("backend-practices")     → stack complète
Agent : bricks-intel:get-module-structure("espace-fi-project") → exemple réel
Agent : code directement                                      → correct du premier coup
Total : 2 tool calls, contexte complet et fiable

Aujourd'hui : L'agent grep "modal" dans la codebase, trouve 50 résultats mélangés (anciens patterns BricksBottomSheet + nouveaux useModals), ne sait pas lequel est le bon.

Avec Bricks Intel : L'agent appelle get-convention("front-modals") et obtient immédiatement : - Le pattern actuel : useModals().openModal() + useCloseModal() - Ce qu'il ne faut PAS faire : pas de BricksBottomSheet, pas de state local - Des exemples de code validés

Exemple 3 : "Ce composant Box est-il OK ?"¶

Avec Bricks Intel : get-component-usage("Box") retourne : - 51 utilisations restantes - Warning : deprecated — utiliser View avec className à la place - Convention associée : Uniwind Styling

Les 15 MCP Tools¶

Tool	Input	Ce qu'il retourne
`re-index`	`{}`	Relance tous les scanners et reconstruit l'index en mémoire
`search`	`{ query: "modal" }`	Résultats cross-domain : conventions, composants, modules, endpoints qui matchent
`get-convention`	`{ name: "front-modals" }`	Contenu complet de la convention avec exemples de code
`get-module-structure`	`{ module: "primary-purchase" }`	Fichiers, couches (business/repo/service/controller), stack (Kysely ou legacy)
`get-component-usage`	`{ component: "Button" }`	289 imports, répartition par app, deprecated ou non
`get-endpoint-schema`	`{ name: "getProjectBorrower" }`	Path HTTP, method, types request/response, fichier source
`get-dependency-graph`	`{ package: "front-app" }`	Dépendances directes + qui dépend de ce package
`get-routes`	`{ app: "front-app" }`	Routes de l'app et leurs fichiers
`get-hooks`	`{ name: "useModals" }`	Hooks custom indexés et leur source
`get-stores`	`{ name: "..." }`	Stores d'état (Jotai) indexés
`get-migration-status`	`{}`	État de migration backend (Kysely+Zod vs legacy)
`get-module-map`	`{}`	Carte de tous les modules API
`get-impact-map`	`{ target: "..." }`	Ce qui est impacté par un changement
`analyze-patterns`	`{}`	Analyse transversale des patterns du monorepo
`create-convention`	`{ ... }`	Crée une nouvelle convention

L'agent appelle ces tools automatiquement quand c'est pertinent — le dev n'a rien à faire.

Architecture technique¶

Stack¶

tools/bricks-intel/           ← Dossier isolé (hors pnpm workspace)
  src/
    index.ts                  ← MCP server (stdio transport)
    scanners/                 ← 10 scanners qui construisent l'index
      packages.ts               Parse les package.json des workspaces
      conventions.ts            Parse .cursor/rules + CLAUDE.md
      api-modules.ts            Liste api/src/__new/modules/, détecte les couches
      components.ts             Grep imports uimmo dans *.tsx
      endpoints.ts              Parse *.endpoint.ts
      dependencies.ts           Construit le graphe de deps internes
      hooks.ts                  Indexe les hooks custom
      migration.ts              Calcule l'état de migration backend
      routes.ts                 Indexe les routes des apps
      stores.ts                 Indexe les stores d'état (Jotai)
    tools/                    ← 15 tools exposés via MCP

Principes¶

TypeScript + tsx — exécution directe, zéro build
Dépendances minimales — prod : @modelcontextprotocol/sdk, zod ; dev : @types/node, tsx, typescript
Index en mémoire — re-scan au démarrage du server (~2 secondes pour tout indexer)
~2 250 lignes de code au total
Pas de base de données, pas de service externe

Comment les scanners fonctionnent¶

Chaque scanner lit des fichiers et retourne des données structurées :

// Exemple : scanner de conventions
// 1. Glob .cursor/rules/*.mdc
// 2. Pour chaque fichier : extraire le frontmatter YAML + le body markdown
// 3. Retourner un tableau de Convention[]

// Exemple : scanner de modules
// 1. Lister les dossiers dans api/src/__new/modules/
// 2. Pour chaque module : lister les fichiers, détecter les couches
// 3. Détecter la stack (import zod = Kysely, import idonttrustlikethat = legacy)

Configuration¶

Un fichier .mcp.json à la racine du monorepo :

{
  "mcpServers": {
    "bricks-intel": {
      "command": "sh",
      "args": ["tools/bricks-intel/start.sh"]
    }
  }
}

Compatible Claude Code et Cursor.

Données réelles du monorepo¶

Les 18 packages¶

Package	Type
`@bricks/front-app`	App web
`@bricks/mobile-app`	App mobile
`@bricks/app-pdp-financement`	App PDP
`@bricks/bricksoffice-invest`	App back-office invest
`@bricks/bricksoffice-projects`	App back-office projets
`@bricks/api`	API NestJS
`@bricks-common/storybook`	Storybook
`@bricks-common/storybook-native`	Storybook natif (on-device)
`@bricks-common/uimmo`	Design system
`@bricks-common/bo`	Lib back-office partagée
`@bricks-common/api-communication`	Types/schemas partagés
`@bricks-common/api-communication-bricksoffice`	Types/schemas back-office
`@bricks-common/api-communication-project-owner`	Types/schemas project owner
`@bricks-common/helpers`	Helpers partagés
`@bricks-common-front/helpers`	Helpers front
`@bricks-common-front/theme`	Thème Uniwind
`@bricks-common-web/helpers`	Helpers web
`@bricks-common-web/ui-kit`	UI Kit web

Top composants uimmo¶

Composant	Imports	Status
Text	847	OK
TouchableArea	312	OK
Button	289	OK
Icon	196	OK
cn (util)	156	OK
BottomSheetModal	64	OK
Box	51	Deprecated

Les 17 conventions actives¶

Cursor Rules (7) — .cursor/rules/ - bricks-intel-mcp — Usage du MCP Bricks Intel - claude-root — Règles agent monorepo-wide - front-conventions — Styling Uniwind, composants, modals, forms, data fetching, i18n, routing, state, perf - front-domain-map — Architecture front, modules, routes, packages, alias d'import - generic-monorepo-rules — pnpm, Turborepo, ts-pattern, zod, branded types - pr-changelog — Conventions PR / changelog - test-conventions — Vitest (API + packages), Jest (front apps)

Cursor Rules BO (8) — .cursor/rules/bo/ - claude-bo-projects, @bricks-common-bo, data-fetching, form, i18n, modal, styling, table

Conventions API — projects/api/.cursor/rules/ - api-conventions — Conventions et patterns de l'API - domain-map — Entités de domaine et leurs relations

Roadmap¶

Version	Contenu	Pour qui
v0.1	MCP server avec 15 tools	Agents IA (Claude Code, Cursor)
v0.2	CLI (`bricks-intel search "modal"`)	Devs en terminal
v0.3	Dashboard HTML interactif	Devs, newcomers
v0.4	CI integration (lint conventions, check deps)	Pipeline
v0.5+	File watcher (auto-refresh), métriques, tests coverage	Tout le monde

Prochaines étapes¶

Valider le concept avec l'équipe (cette présentation)
Implémenter le MCP server v0.1 (~4 phases, plan technique prêt)
Configurer pour Claude Code + Cursor
Itérer sur les tools en fonction des usages réels de l'équipe
Mesurer : comparer le nombre de tool calls avant/après sur des tâches types