Cursor et Claude Code connectés à CodeGraph via MCP pour Vue et Spring Boot

Vous changez une API avec Cursor ou Claude Code, le backend part en prod, le front reste ancien — classique. Cet article ne traite que de trois points : pourquoi ça rate, comment le cas OrderDTO se manifeste, comment CodeGraph aide. Stack Vue 3 + Spring Boot séparé ; outil CodeGraph via MCP.

En bref : avant de modifier OrderDTO.amount, lancez codegraph_impact — services Java, createOrder Vue et store Pinia en une passe ; la couche que les agents oublient le plus souvent.

Pourquoi Cursor oublie le front

Les oublis viennent rarement d’un modèle « qui ne sait pas coder ». Les outils AI Coding ne voient pas bien les références cross-dossiers et cross-langages. Sur Vue + Spring Boot, trois causes suffisent souvent :

1. Fenêtre de contexte : le fichier ouvert seulement

Les @-fichiers Cursor et les Read Claude Code sont bornés. L’agent fixe OrderController.java sans voir que frontend/src/api/order.ts partage le même champ DTO. Nouveau chat, nouvelle branche — « où en étions-nous » se perd (pire avec l’amnésie Cursor sur plusieurs semaines).

2. grep : du texte, pas des appels

L’exploration passe par grep. Chercher amount remonte logs, tests, constantes mortes — pas qui appelle OrderService.createOrder ni quel handler @PostMapping répond. Les tokens partent en « trouver l’entrée », pas en « corriger tout le rayon d’impact ».

3. Pas d’impact : un fichier corrigé, dix orphelins

On se demande : si je change ce champ, quoi d’autre casse ? Sans impact structuré, l’agent « finit le Java » et repousse TypeScript, Pinia et tests — un chat semble terminé, vous avez en réalité deux tours de dette.

Il faut surtout des graphes d’appels, arêtes, entrées de routes interrogeables. L’API commande ci-dessous l’illustre.

Cas réel : OrderDTO.amount

Besoin : sur POST /api/orders, passer amount de number à string (gros montants, chaînes formatées, etc.). Dépôt : backend/ (Controller → Service → OrderDTO), frontend/ (api/order.ts → Pinia → page commande).

Sans CodeGraph : ce que Cursor / Claude Code oublient souvent

Description métier seule, pas de @ fichiers. Résultat typique :

  • ✅ OrderDTO.java, OrderService mis à jour
  • ❌ types payload dans frontend/src/api/order.ts pour createOrder
  • ❌ mapping amount dans useOrderStore
  • ❌ v-model de commande encore validé en numérique

mvn compile peut passer, pnpm build aussi parfois — c’est en intégration ou en prod que ça casse. Voilà « API changée, front oublié ».

À comparer : liste impact (extrait)

codegraph_impact
  symbol: "OrderDTO.amount"

→ OrderService.createOrder
→ OrderController.create
→ frontend/src/api/order.ts :: createOrder
→ stores/order.ts :: useOrderStore

La dernière ligne est le Pinia que grep manquait le plus. Travailler la liste dans Cursor / Claude Code réduit les oublis.

Comment CodeGraph expose l’impact

CodeGraph indexe en local (Tree-sitter, Java / TS / Vue script), stocke les appels dans .codegraph/, expose codegraph_* en MCP. Les données restent sur la machine par défaut.

Pour cette commande, ordre fixe :

  1. codegraph_context — paquet tâche Controller, DTO, entrée API front (sans @ chemins)
  2. codegraph_trace — Spring : OrderController.create → OrderMapper.insert
  3. codegraph_impact — depuis OrderDTO.amount vers Java + Vue + store
  4. codegraph_explore — méthodes liées seulement, pas un service de 800 lignes entier

Sans arête symbol entre chemin HTTP et chaîne axios, l’impact depuis le DTO atteint quand même le front — le pas « mieux qu’attendu » ici. Comparatif outils : graphe de connaissances code ; installation ci-dessous.

Dans AGENTS.md : impact obligatoire avant DTO, lister frontend/src/api et Pinia — plus fiable que « n’oublie pas le front ».

Installation (~5 min)

À la racine avec frontend/ + backend/ (macOS) :

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh
# ou : npx @colbymchenry/codegraph

codegraph install --target=cursor --yes
cd /path/to/your-repo
codegraph init -i
codegraph status

Premier index complet : ~10–20 min selon taille ; exclure node_modules, target, dist. Sauvegarde ~2s debounce ; sur ⚠️ Pending sync, faire Read la source.

Comparaison

MéthodeAppels outils (même tâche, ressenti)Front sur la liste ?
grep + Read seuls~15+Pinia / API souvent absents
CodeGraph MCP d’abord~5–6impact front + back ensemble

Benchmark Java officiel (OkHttp ~645 fichiers) : médiane 10→3 (2026-05-29). Vue + Spring : exploration divisée au moins par deux en ressenti. Le graphe ne remplace pas les tests — mvn test + pnpm test:unit avant merge.

Où indexer les gros dépôts

Premier codegraph index : CPU élevé, écritures SQLite, ventilateur — IDEA compile Spring, pnpm build Vue, et les requêtes Cursor MCP rament.

Beaucoup mettent clone + index complet + rebuilds planifiés sur Mac mini, nœud CI ou Cloud Mac ; le portable ne fait que code et MCP. J’indexe sur un M4 Macstripe à la journée, décalé du build local ; worktree : FAQ CI Mac entreprise.

« CodeGraph sur Cloud Mac » mérite son propre article — ici : séparer indexation et interaction stabilise l’expérience.

Synthèse

Cursor oublie le front sur changement d’API quand contexte limité + grep sans appels + pas d’impact s’additionnent. Sur Vue + Spring Boot, MCP CodeGraph context → trace → impact aligne la liste front/back pour un DTO ; l’exploration passe de nombreux grep à quelques requêtes structurées.

Routine : init → impact (avant DTO) → corriger la liste → tests. Posts concept, Claude Code sur énormes dépôts, déploiement Cloud Mac en série — liens ci-dessous.

À lire aussi