feat: add main features
Agents for developpement added + frontend add + backend added. Git viewer created + agent and template creator + layout and project creator
This commit is contained in:
187
CONTEXT.md
Normal file
187
CONTEXT.md
Normal file
@ -0,0 +1,187 @@
|
||||
# IdeA — Contexte & Méthode de travail
|
||||
|
||||
> Ce document définit **mon rôle**, **la méthode de développement** et **la vision produit** du projet IdeA.
|
||||
> 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
|
||||
|
||||
Je **n'écris pas de code moi-même**. Mon rôle est de **piloter des agents** qui réalisent le travail.
|
||||
Je suis responsable de :
|
||||
|
||||
- Découper le travail en tâches claires et autonomes.
|
||||
- Attribuer chaque tâche aux bons agents.
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
## 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 Développement → écrit le code
|
||||
3. Agent Test → écrit les tests unitaires + les exécute
|
||||
4a. Tests OK → feature validée, on passe à la suite
|
||||
4b. Tests KO → rapport d'erreurs → retour à l'agent Développement
|
||||
→ correction → retour à l'étape 3 (boucle jusqu'au vert)
|
||||
```
|
||||
|
||||
**Règle d'or :** aucune feature n'est considérée terminée tant que ses tests ne passent pas.
|
||||
Je relaie fidèlement les résultats : si des tests échouent, je le dis avec la sortie réelle.
|
||||
|
||||
---
|
||||
|
||||
## 4. Principes de code
|
||||
|
||||
- **SOLID** appliqué au maximum.
|
||||
- **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.
|
||||
- Tests unitaires systématiques ; couverture des features critiques.
|
||||
- Code lisible, cohérent avec le style existant, faiblement couplé, fortement cohésif.
|
||||
|
||||
---
|
||||
|
||||
## 5. Vision produit : IdeA
|
||||
|
||||
**IdeA est un IDE next-gen 100 % IA.** On n'y code pas : **on gère des IA.**
|
||||
|
||||
### Fonctionnalités clés
|
||||
- **Multi-projets en parallèle** : un **onglet par projet**.
|
||||
- **Fenêtre = espace de travail** où l'on **organise plusieurs terminaux** librement.
|
||||
- **Agents par projet** : chaque projet a ses propres agents.
|
||||
- **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)
|
||||
|
||||
- **Shell applicatif** : **Tauri v2** (binaires légers, performants, multi-OS, AppImage + installeur `setup.exe`/NSIS Windows natifs).
|
||||
- **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)
|
||||
|
||||
Disposition en **grille redimensionnable de type tableur (Excel)** :
|
||||
|
||||
- Splits redimensionnables horizontaux **et** verticaux.
|
||||
- L'utilisateur peut **définir le nombre de colonnes dans une ligne** et **le nombre de lignes dans une colonne**, indépendamment par zone.
|
||||
- Possibilité de **fusionner des cellules** (ex. fusionner deux colonnes sur une ligne), à la manière des cellules fusionnées d'un tableur.
|
||||
- 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).
|
||||
|
||||
**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*
|
||||
Reference in New Issue
Block a user