blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
develop
IdeA/.ideai/agents/main.md

9.3 KiB
Raw Permalink Blame History

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 :

{
  "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