--- name: idea-product-directives-main-handoff description: Directives produit consolidees pour guider Main sur la robustesse, la persistance, le handoff cross-profile et la sobriete UX. metadata: type: project --- # IdeA Product Directives For Main ## Resume Cette note consolide les arbitrages produit explicites donnes par l'utilisateur pour aider `Main` a poursuivre le projet sans ambiguite. See also: - `agent-context-memory-and-profile-handoff` for the structural model of context, durable memory, live state, and handoff. - `remaining-work-idea-agent-control-ide` for the current implementation status and remaining work. Elle ne remplace pas les notes techniques existantes. Elle sert de reference prioritaire sur: - la robustesse attendue, - la persistance et la reprise, - le handoff entre profils IA, - la memoire projet partagee, - le live state projet, - la sobriete UX. ## Priorite Absolue La priorite produit numero un est la robustesse. Ordre de priorite impose: 1. robustesse et solidite avant tout 2. persistance et reprise 3. handoff cross-profile 4. live state projet 5. reste des features et du polish Regle de pilotage: - un systeme incomplet mais solide vaut mieux qu'un systeme riche mais fragile - `Main` doit privilegier les architectures et comportements qui reduisent les crashes, les incoherences d'etat et les flows difficiles a reprendre ## Reprise Et Persistance Quand IdeA redemarre, l'objectif n'est pas seulement de rouvrir une UI ou de restaurer des handles techniques. La cible produit est: - qu'un agent sache compactement sur quoi il travaillait - qu'IdeA fournisse ce materiel de reprise automatiquement - que la reprise soit exploitable meme si la conversation visible precedente n'est pas restauree a l'identique Le bon modele est: - un log canonique IdeA comme source durable - un resume/handoff genere par IdeA comme couche compacte de reprise Le resume/handoff n'est pas un confort secondaire. Il fait partie du comportement normal du produit. ## Handoff Cross-Profile La cible ideale est double: - reprendre correctement le travail - donner si possible une impression de continuite presque sans rupture Mais en cas de compromis, la priorite doit etre: - fidelite operationnelle du travail repris - avant la parfaite illusion de continuite terminale ou conversationnelle Autrement dit: - si un agent passe de Claude a Codex, IdeA doit d'abord garantir que Codex puisse reprendre le plus fidelement possible le travail utile - l'absence de restauration parfaite de l'ancien terminal est acceptable si le handoff reste bon ## Perimetre Profils Le perimetre de reference immediat est: - Claude - Codex Toute fonctionnalite importante doit etre faisable pour ces deux profils. Directive associée: - reduire au maximum les dependances a des commandes, flags ou comportements specifiques a un profil - construire un noyau le plus generique possible tout en restant concretement compatible Claude/Codex - les autres profils pourront etre ajoutes plus tard si possible, mais ne doivent pas detourner le coeur du chantier actuel ## Memoire Projet Partagee La memoire projet partagee doit rester petite, stable et utile. Elle ne doit pas devenir un gros bloc qui siphonne les tokens de l'utilisateur a chaque requete. Ce qu'un agent peut ecrire automatiquement dans la memoire partagee si c'est stable et utile: - decisions durables d'architecture ou d'organisation - preferences utilisateur durables - regles de workflow durables - references importantes a conserver - resumes de handoff utiles a la reprise inter-session ou inter-profil Ce qu'un agent ne doit pas y ecrire automatiquement: - conversations brutes - journaux detailles de travail - etats temporaires - files d'attente - coordination temps reel - essais/erreurs locaux - hypotheses non stabilisees - contenu redondant ou reconstructible ailleurs Principe de fond: - memoire durable = savoir stable - log canonique = historique - handoff = reprise compacte - live state = coordination vivante Ces couches doivent rester separees. ## Live State Projet Le live state projet partage doit exister comme mecanisme interne d'IdeA. Contraintes produit: - il doit rester invisible pour l'utilisateur - il doit survivre au redemarrage d'IdeA Il ne doit pas se transformer en UI verbeuse ni en mecanisme demandant une intervention explicite de l'utilisateur. ## UX Et Philosophie Produit IdeA doit etre tres facile d'utilisation. Objectif UX: - plug and play - pas de sensation de parametrage impose - pas de surcharge de tuto au premier lancement - pas d'impression que le produit force des comportements internes a l'utilisateur Ligne directrice souhaitee: - esprit "maniere Linux" - comportement simple et utile par defaut - pas de contrainte tant qu'il n'y a pas un vrai besoin - suggestion discrete seulement si IdeA detecte qu'une aide ou une optimisation devient utile Le precedent du compactage de contexte est considere comme la bonne direction: - pas de compactage impose d'emblee - une popup proposee seulement si IdeA sent un besoin ## Transparence Des Mecanismes Internes Les mecanismes suivants doivent rester quasi invisibles pour l'utilisateur: - delegations inter-agents - FIFO - handoffs Ils peuvent devenir visibles en debug ou quand le produit a une bonne raison UX de les exposer, mais ils ne doivent pas etre ressentis comme une charge cognitive normale d'utilisation. ## Frontiere Avec Le Chantier Inter-Agents De Main Les choix fins touchant la communication entre agents ne doivent pas etre recadres ici si `Main` est deja en train de les traiter. Cette note ne doit donc pas etre lue comme une specification d'implementation inter-agents detaillee. Elle fixe seulement les invariants produit suivants: - robustesse avant richesse fonctionnelle - reprise automatique par IdeA - log canonique + handoff genere par IdeA - support de reference pour Claude et Codex - memoire durable compacte et curatee - live state interne et persistant - UX discrete, simple et peu intrusive ## Directive Finale Pour Main Si un arbitrage technique oppose: - elegance theorique - ou livraison rapide contre: - robustesse - reprise fiable - sobriete UX alors `Main` doit privilegier: - robustesse - reprise fiable - sobriete UX avant le reste.