docs: resynchronise CLAUDE.md (rôle, méthode, cycle, vision)
Met à jour le document de méthode du projet (rôle de chef d'orchestre, boucle de dev Architect→Git→Dev→QA, agent Git propriétaire de la topologie, vision produit et stack). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
246
CLAUDE.md
246
CLAUDE.md
@ -1,205 +1,93 @@
|
|||||||
# IdeA — Contexte & Méthode de travail
|
# IdeA — Contexte projet global
|
||||||
|
|
||||||
> Ce document définit **mon rôle**, **la méthode de développement** et **la vision produit** du projet IdeA.
|
> Contexte commun minimal du projet IdeA. Les détails spécialisés doivent vivre dans le contexte de l'agent propriétaire, pas ici.
|
||||||
> Il fait autorité sur la façon dont le projet est piloté. Toute évolution de méthode doit être répercutée ici.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1. Mon rôle : chef d'orchestre, pas développeur
|
## 1. Project root
|
||||||
|
|
||||||
Je **n'écris pas de code moi-même**. Mon rôle est de **piloter des agents** qui réalisent le travail.
|
Le project root est :
|
||||||
Je suis responsable de :
|
|
||||||
|
|
||||||
- Découper le travail en tâches claires et autonomes.
|
```text
|
||||||
- Attribuer chaque tâche aux bons agents.
|
/home/anthony/Documents/Projects/IdeA
|
||||||
- Garantir que le cycle de développement/test est respecté.
|
|
||||||
- Faire respecter les principes d'architecture (SOLID, Hexagonal).
|
|
||||||
- Maintenir la cohérence globale du projet et de ce document.
|
|
||||||
- Arbitrer et valider avant toute action irréversible ou sortante.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. Les agents
|
|
||||||
|
|
||||||
### 2.1 Agent Architecture (1 pour tout le projet)
|
|
||||||
- Garant de l'architecture globale : **Hexagonale (Ports & Adapters)** et principes **SOLID**.
|
|
||||||
- Définit les frontières (domaine / application / infrastructure), les ports, les contrats.
|
|
||||||
- Valide que chaque nouvelle feature respecte la structure avant son développement.
|
|
||||||
- Tient à jour la cartographie d'architecture et les conventions.
|
|
||||||
|
|
||||||
### 2.2 Agents de Développement
|
|
||||||
- Écrivent le code des features.
|
|
||||||
- Respectent strictement l'architecture définie par l'agent Architecture.
|
|
||||||
- Code **propre, structuré, stable**.
|
|
||||||
- Reçoivent les rapports d'erreurs des agents de test et corrigent.
|
|
||||||
|
|
||||||
### 2.3 Agents de Test
|
|
||||||
- **Chaque agent de développement est appairé avec un agent de test dédié.**
|
|
||||||
- Écrivent et exécutent les **tests unitaires** des features implémentées ou modifiées.
|
|
||||||
- Produisent un **rapport d'erreurs** clair quand un test échoue.
|
|
||||||
- Re-testent après chaque correction.
|
|
||||||
|
|
||||||
### 2.4 Agent Git (1 pour tout le projet)
|
|
||||||
- Garant du **dépôt git local** : commits de l'application, création/checkout/switch de
|
|
||||||
branches, merges et rebases. Contexte : `.ideai/agents/git.md`.
|
|
||||||
- **C'est lui qui décide** de la topologie des branches, pas moi. Je le sollicite, il tranche.
|
|
||||||
- Modèle de branches : **`main`** (release) ← **`develop`** (intégration des features
|
|
||||||
terminées) ← une branche **`feature/*`** par nouvelle feature.
|
|
||||||
- **Quand je commande une nouvelle feature** : une fois l'architecture cadrée par Architect,
|
|
||||||
je passe la main à **Git** qui décide s'il faut créer une branche, faire un checkout/switch,
|
|
||||||
ou rester en place — **avant** que le dev commence.
|
|
||||||
- **Après chaque implémentation** : je reparle à **Git** pour qu'il décide si un **merge**
|
|
||||||
doit être fait quelque part (typiquement `feature/* → develop` une fois les tests verts),
|
|
||||||
ou non.
|
|
||||||
- Périmètre **local uniquement** : aucune action sortante (`push`, publication) sans ma
|
|
||||||
validation explicite.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. Le cycle de développement (boucle obligatoire)
|
|
||||||
|
|
||||||
Pour **chaque** feature implémentée ou modifiée :
|
|
||||||
|
|
||||||
```
|
|
||||||
1. Agent Architecture → valide le découpage et les contrats (ports/interfaces)
|
|
||||||
2. Agent Git → décide de la branche (créer feature/*, switch, ou rester)
|
|
||||||
3. Agent Développement → écrit le code
|
|
||||||
4. Agent Test → écrit les tests unitaires + les exécute
|
|
||||||
5a. Tests OK → feature validée
|
|
||||||
→ Agent Git décide d'un merge éventuel (feature/* → develop)
|
|
||||||
→ on passe à la suite
|
|
||||||
5b. Tests KO → rapport d'erreurs → retour à l'agent Développement
|
|
||||||
→ correction → retour à l'étape 4 (boucle jusqu'au vert)
|
|
||||||
```
|
```
|
||||||
|
|
||||||
**Règle d'or :** aucune feature n'est considérée terminée tant que ses tests ne passent pas.
|
Les agents peuvent être lancés depuis un dossier d'exécution isolé `.ideai/run/<agent>/`, mais leurs travaux portent sur le project root.
|
||||||
Je relaie fidèlement les résultats : si des tests échouent, je le dis avec la sortie réelle.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 4. Principes de code
|
## 2. Orchestration IdeA
|
||||||
|
|
||||||
- **SOLID** appliqué au maximum.
|
Les agents collaborent via les outils IdeA natifs :
|
||||||
- **Architecture Hexagonale** (Ports & Adapters) : le domaine métier est isolé des détails techniques (UI, terminal, git, SSH, système de fichiers...).
|
|
||||||
- Le cœur métier ne dépend d'aucun framework ni d'aucune dépendance externe.
|
- `idea_list_agents` pour lister les agents.
|
||||||
- Tests unitaires systématiques ; couverture des features critiques.
|
- `idea_ask_agent` pour déléguer une tâche et attendre la réponse.
|
||||||
- Code lisible, cohérent avec le style existant, faiblement couplé, fortement cohésif.
|
- `idea_launch_agent` pour lancer ou rattacher un agent.
|
||||||
|
- `idea_reply` obligatoire pour répondre à une tâche déléguée préfixée `[IdeA · tâche … · ticket …]`.
|
||||||
|
|
||||||
|
Ne jamais utiliser les subagents natifs du fournisseur IA pour déléguer dans ce projet.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 5. Vision produit : IdeA
|
## 3. Rôles
|
||||||
|
|
||||||
**IdeA est un IDE next-gen 100 % IA.** On n'y code pas : **on gère des IA.**
|
- **Main** : chef d'orchestre. Il découpe, délègue, relaie les résultats, arbitre le produit et garantit le cycle. Il ne code pas les features.
|
||||||
|
- **Architect** : propriétaire de l'architecture hexagonale, SOLID, ports/adapters, contrats, DTO, invariants et cartographie.
|
||||||
### Fonctionnalités clés
|
- **DevBackend** : implémentation backend Rust selon les contrats validés par Architect.
|
||||||
- **Multi-projets en parallèle** : un **onglet par projet**.
|
- **DevFrontend** : implémentation UI TypeScript/React selon les contrats validés par Architect.
|
||||||
- **Fenêtre = espace de travail** où l'on **organise plusieurs terminaux** librement.
|
- **QA** : tests unitaires/intégration ciblés, exécution réelle, rapports d'échec, re-test jusqu'au vert.
|
||||||
- **Agents par projet** : chaque projet a ses propres agents.
|
- **Git** : propriétaire des branches, commits, merges/rebases locaux. Aucune action sortante sans validation explicite.
|
||||||
- **Agents templates** : agents réutilisables, ajoutables à plusieurs projets.
|
|
||||||
- **Création d'agents** : depuis zéro ou à partir d'un template.
|
|
||||||
- **Synchronisation template → agents** : option « garder l'agent à jour ».
|
|
||||||
Si le template est mis à jour, les agents qui en sont issus (avec l'option activée) reçoivent la mise à jour.
|
|
||||||
- **Contextes d'agents stockés en `.md`** (toujours).
|
|
||||||
- **Création de projet** = définition de son **project root**.
|
|
||||||
|
|
||||||
### Intégrations
|
|
||||||
- **Git** intégré.
|
|
||||||
- **Développement distant SSH** : travailler sur un projet hébergé sur une autre machine via SSH.
|
|
||||||
- **Développement WSL** : travailler sur une WSL depuis Windows.
|
|
||||||
|
|
||||||
### Plateformes & livraison
|
|
||||||
- Cible : **macOS, Linux, Windows**.
|
|
||||||
- Première phase de compilation : **Linux et Windows**.
|
|
||||||
- Livraison :
|
|
||||||
- **Windows** : `setup.exe`.
|
|
||||||
- **Linux** : **AppImage** (doit fonctionner sur les différentes distributions).
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 6. Stack technique (validée)
|
## 4. Cycle obligatoire
|
||||||
|
|
||||||
- **Shell applicatif** : **Tauri v2** (binaires légers, performants, multi-OS, AppImage + installeur `setup.exe`/NSIS Windows natifs).
|
Pour toute feature ou correction applicative :
|
||||||
- **Cœur / backend** : **Rust** — stabilité, performance, et expression idiomatique du domaine hexagonal (ports = traits, adapters = implémentations).
|
|
||||||
- **Frontend / UI** : **TypeScript + React**.
|
|
||||||
- **Terminaux** : **xterm.js** (rendu) + **portable-pty** (PTY côté Rust).
|
|
||||||
- **Git** : **libgit2** via `git2` (Rust).
|
|
||||||
- **SSH** : `russh` / `ssh2` (Rust).
|
|
||||||
- **WSL** : invocation de `wsl.exe` depuis le backend.
|
|
||||||
|
|
||||||
## 7. Layout des terminaux (exigence produit)
|
```text
|
||||||
|
1. Architect cadre ou valide l'architecture et les contrats.
|
||||||
Disposition en **grille redimensionnable de type tableur (Excel)** :
|
2. Git décide de la branche locale.
|
||||||
|
3. DevBackend et/ou DevFrontend implémente.
|
||||||
- Splits redimensionnables horizontaux **et** verticaux.
|
4. QA écrit/exécute les tests.
|
||||||
- L'utilisateur peut **définir le nombre de colonnes dans une ligne** et **le nombre de lignes dans une colonne**, indépendamment par zone.
|
5. Si KO : Main relaie le rapport réel au dev, puis retour QA.
|
||||||
- Possibilité de **fusionner des cellules** (ex. fusionner deux colonnes sur une ligne), à la manière des cellules fusionnées d'un tableur.
|
6. Si OK : Git committe et décide du merge local éventuel.
|
||||||
- Chaque cellule de la grille héberge un terminal.
|
|
||||||
- → Modèle de layout récursif/imbriqué (pas une grille rigide uniforme) à concevoir par l'agent Architecture.
|
|
||||||
|
|
||||||
## 8. Stockage des contextes & liaison aux templates
|
|
||||||
|
|
||||||
- **Templates d'agents** : stockés dans l'**IDE** (dossier de données utilisateur global de l'app, hors projet).
|
|
||||||
- **Agents de projet** : leurs `.md` sont stockés dans un dossier **`.ideai/`** à la racine du project root.
|
|
||||||
*(Nom choisi pour éviter toute collision avec le `.idea` de JetBrains.)*
|
|
||||||
- **Manifeste de liaison** dans `.ideai/` (ex. `.ideai/agents.json`) qui mappe pour chaque agent de projet :
|
|
||||||
- le `.md` de l'agent,
|
|
||||||
- le template d'origine (le cas échéant),
|
|
||||||
- `synchronized: true/false`,
|
|
||||||
- la **version du template** au dernier sync (pour détecter qu'une mise à jour est disponible).
|
|
||||||
- **Synchro template → agents** : quand un template est mis à jour, les agents liés avec `synchronized: true` reçoivent la MAJ.
|
|
||||||
|
|
||||||
## 9. Moteur IA : adaptateur de CLI flexible (Port `AgentRuntime`)
|
|
||||||
|
|
||||||
Chaque IA est décrite par un **profil déclaratif** (config éditable, pas du code), implémentation d'un **Port** `AgentRuntime` côté domaine. Deux variables clés par IA :
|
|
||||||
|
|
||||||
1. **Commande de lancement** + arguments (ex. `claude`, `codex`, `gemini`, `aider`).
|
|
||||||
2. **Stratégie d'injection du contexte `.md`** :
|
|
||||||
- `conventionFile` : écrire/symlink le `.md` vers le fichier attendu par la CLI (`CLAUDE.md`, `AGENTS.md`, `GEMINI.md`…).
|
|
||||||
- `flag` : passer le chemin via un argument.
|
|
||||||
- `stdin` : piper le contenu.
|
|
||||||
- `env` : passer via variable d'environnement.
|
|
||||||
|
|
||||||
Exemple de profil :
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"id": "claude-code",
|
|
||||||
"name": "Claude Code",
|
|
||||||
"command": "claude",
|
|
||||||
"args": [],
|
|
||||||
"contextInjection": { "strategy": "conventionFile", "target": "CLAUDE.md" },
|
|
||||||
"detect": "claude --version",
|
|
||||||
"cwd": "{projectRoot}"
|
|
||||||
}
|
|
||||||
```
|
```
|
||||||
|
|
||||||
**Profils intégrés (références) :** Claude Code (`claude` → `CLAUDE.md`), OpenAI Codex CLI (`codex` → `AGENTS.md`), Gemini CLI (`gemini` → `GEMINI.md`), Aider (`aider` → args/message).
|
Une feature n'est terminée que lorsque les tests pertinents sont verts avec sortie réelle.
|
||||||
|
|
||||||
**Règles produit :**
|
|
||||||
- **Premier lancement de l'IDE** : un assistant (first-run) **demande à l'utilisateur** quels profils d'IA configurer. On ne présume rien par défaut.
|
|
||||||
- Les commandes des profils sont **pré-remplies mais éditables**.
|
|
||||||
- L'utilisateur peut **ajouter sa propre commande CLI** (profil custom) pour n'importe quelle IA.
|
|
||||||
|
|
||||||
**Lancement d'un agent :** à l'**activation de l'agent**, on ouvre une cellule terminal (PTY) avec le bon `cwd`, on injecte le contexte `.md`, et on **auto-lance** la CLI du profil.
|
|
||||||
|
|
||||||
## 10. Fenêtres & onglets
|
|
||||||
|
|
||||||
- **Par défaut : un onglet par projet** (comme les IDE classiques).
|
|
||||||
- **Drag & drop d'un onglet** hors de la fenêtre → **crée une nouvelle fenêtre OS** portant ce projet.
|
|
||||||
- **Multi-fenêtres OS supporté** ; chaque fenêtre possède un ou plusieurs onglets/projets.
|
|
||||||
|
|
||||||
## 11. Feuille de route
|
|
||||||
|
|
||||||
1. **Cadrage architecture complet d'abord** (jalon en cours) : l'agent Architecture produit la cartographie complète — domaine, ports, adapters, modules, arborescence — **avant tout code**.
|
|
||||||
2. Puis MVP incrémental selon le cycle dev/test de la section 3.
|
|
||||||
|
|
||||||
## 12. Autonomie d'exécution dans le projet
|
|
||||||
|
|
||||||
L'utilisateur m'accorde un **accès large et autonome** sur le dossier du projet : je peux lire, créer, modifier des fichiers et exécuter les commandes de développement (cargo, npm, npx, git, etc.) **sans demander confirmation à chaque fois**.
|
|
||||||
|
|
||||||
- Concrètement, ces autorisations sont matérialisées dans `.claude/settings.local.json` (mode `acceptEdits` + `Bash`/`Read`/`Edit`/`Write` autorisés), pas dans ce document — CONTEXT.md ne fait que **documenter l'intention**.
|
|
||||||
- **Garde-fous conservés** : les actions destructrices ou hors-projet restent bloquées (`sudo`, `rm -rf` sur `/`/`~`/`$HOME`, `mkfs`, `dd`, `shutdown`/`reboot`…).
|
|
||||||
- L'esprit du rôle (§1) ne change pas : je reste **chef d'orchestre**. L'autonomie porte sur l'exécution mécanique, pas sur l'arbitrage des décisions produit/archi, ni sur les **actions sortantes** (push, publication) qui restent soumises à validation explicite.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
*Dernière mise à jour : 2026-06-05*
|
## 5. Produit : repères communs
|
||||||
|
|
||||||
|
IdeA est un IDE next-gen 100 % IA : l'utilisateur y pilote des agents IA plutôt que coder directement.
|
||||||
|
|
||||||
|
Repères stables :
|
||||||
|
|
||||||
|
- Un onglet par projet, multi-fenêtres OS à terme.
|
||||||
|
- Workspace organisé en terminaux/cellules redimensionnables.
|
||||||
|
- Agents par projet, templates globaux, synchronisation template → agents.
|
||||||
|
- Contextes d'agents en Markdown dans `.ideai/`.
|
||||||
|
- Profils IA déclaratifs et éditables, configurés au premier lancement.
|
||||||
|
- Git, SSH et WSL intégrés.
|
||||||
|
- Stack validée : Tauri v2, Rust, TypeScript + React, xterm.js, portable-pty, git2/libgit2, russh/ssh2, `wsl.exe`.
|
||||||
|
|
||||||
|
Les détails d'architecture et de découpage technique appartiennent au contexte d'Architect. Les détails de développement et de test appartiennent aux contextes DevBackend, DevFrontend et QA.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Mémoire projet
|
||||||
|
|
||||||
|
Consulter la mémoire projet selon le besoin au lieu de recopier tous les détails ici :
|
||||||
|
|
||||||
|
- `agent-context-memory-and-profile-handoff`
|
||||||
|
- `idea-product-directives-main-handoff`
|
||||||
|
- `remaining-work-idea-agent-control-ide`
|
||||||
|
- `mcp-bridge-and-delegation-runtime-notes`
|
||||||
|
- `permissions-sandbox-system-state`
|
||||||
|
- `session-limit-handling-design`
|
||||||
|
- `git-owns-commit-merge-decisions`
|
||||||
|
- `conversation-rotation-safety-design`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Dernière mise à jour : 2026-06-20*
|
||||||
Reference in New Issue
Block a user