# IdeA — Contexte projet global > Contexte commun minimal du projet IdeA. Les détails spécialisés doivent vivre dans le contexte de l'agent propriétaire, pas ici. --- ## 1. Project root Le project root est : ```text /home/anthony/Documents/Projects/IdeA ``` Les agents peuvent être lancés depuis un dossier d'exécution isolé `.ideai/run//`, mais leurs travaux portent sur le project root. --- ## 2. Orchestration IdeA Les agents collaborent via les outils IdeA natifs : - `idea_list_agents` pour lister les agents. - `idea_ask_agent` pour déléguer une tâche et recevoir la réponse finale capturée par IdeA. - `idea_launch_agent` pour lancer ou rattacher un agent. Quand un agent est sollicité via IdeA, il répond normalement en fin de tour. IdeA capture automatiquement cette réponse finale ; les agents ne gèrent pas de ticket et n'appellent pas d'outil de remise de résultat. Ne jamais utiliser les subagents natifs du fournisseur IA pour déléguer dans ce projet. **La liste des rôles ci-dessous fait foi, mais elle n'est pas la source de vérité des agents réellement déclarés.** Avant de conclure qu'un rôle n'existe pas, appeler `idea_list_agents` : le manifeste du projet fait autorité. Un rôle absent de ce document n'est pas un rôle absent du projet. --- ## 3. Rôles - **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. - **UX** : propriétaire de la conception UI/UX — surfaces, navigation, libellés, hiérarchie de l'information, formulation des erreurs, parcours utilisateur. Décide de la forme ; Architect décide des frontières techniques. - **DevBackend** : implémentation backend Rust selon les contrats validés par Architect. - **DevFrontend** : implémentation UI TypeScript/React selon les contrats validés par Architect et la conception validée par UX. - **QA** : tests unitaires/intégration ciblés, exécution réelle, rapports d'échec, re-test jusqu'au vert. - **Git** : propriétaire des branches, commits, merges/rebases locaux. Aucune action sortante sans validation explicite. --- ## 4. Cycle obligatoire Pour toute feature ou correction applicative : ```text 1. UX conçoit la surface, dès qu'il y a de l'UI (voir ci-dessous). 2. Architect cadre ou valide l'architecture et les contrats. 3. Git décide de la branche locale. 4. DevBackend et/ou DevFrontend implémente. 5. QA écrit/exécute les tests. 6. Si KO : Main relaie le rapport réel au dev, puis retour QA. 7. Si OK : Git committe et décide du merge local éventuel. ``` Une feature n'est terminée que lorsque les tests pertinents sont verts avec sortie réelle. **Quand solliciter UX — la règle.** Dès qu'une demande touche ce que l'utilisateur voit, lit ou manipule : nouvelle surface, nouvel écran, menu, libellé, message d'erreur, parcours, responsive. Ne pas dessiner l'UI à sa place pour « gagner du temps » ni la laisser tomber dans les mains d'un dev par défaut. UX passe **avant** Architect quand la forme conditionne les contrats (ce que l'UI doit exposer détermine les DTO), et **avec** lui quand une contrainte technique borne la conception. UX ne bloque pas les tickets sans surface utilisateur (lots purement backend, seams, refactors internes). --- ## 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. La conception des surfaces appartient au contexte d'UX. 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-07-16*