Architecture PlanToCode

L'interface bureau est construite avec des composants React. Le contenu des plans d'implémentation est affiché via un visualiseur basé sur Monaco qui virtualise les grands plans, détecte les langages et prend en charge les actions de copie pour que les réviseurs puissent examiner le texte du plan sans problèmes de performance. Les sessions terminal s'affichent dans une vue bufferisée qui se connecte à la sortie PTY et affiche les mises à jour d'état de connexion.

Les providers partagés gèrent les notifications, la configuration d'exécution et l'état des plans. Le panneau Plans d'implémentation conserve les métadonnées du plan, gère la visibilité des modales et demande des estimations de tokens ou du contenu de prompt selon les besoins.

Le côté Rust de l'application expose des commandes pour les workflows, les sessions terminal et les outils de modèle. Les commandes de workflow démarrent des tâches en arrière-plan via le Workflow Orchestrator, validant les entrées et émettant des événements de progression pendant l'exécution du pipeline de découverte de fichiers. Les commandes d'estimation de tokens calculent les tailles de prompt pour le modèle actuellement sélectionné.

Les commandes terminal gèrent les processus PTY, suivent les clients distants et vérifient si les binaires CLI supportés sont disponibles avant de lancer une session. Les vérifications de santé combinent l'état PTY avec les enregistrements de base de données pour signaler si une session est toujours active.

La sortie terminal et les métadonnées de session sont stockées dans SQLite via le repository des sessions terminal. Chaque enregistrement inclut des identifiants, horodatages, répertoires de travail, variables d'environnement et le log accumulé pour que les redémarrages puissent récupérer la sortie précédente. Le même repository émet des événements quand l'état de la session change.

Les valeurs par défaut des modèles résident dans la table de configuration de l'application. Chaque tâche définit un modèle par défaut, une liste d'alternatives autorisées, des budgets de tokens et des préréglages optionnels de boutons de copie. La couche React lit ces paramètres pour alimenter le sélecteur de modèle et les garde-fous.

La transcription vocale est implémentée comme un hook React qui coordonne les permissions média, la sélection du microphone et les requêtes de transcription en streaming. Le hook s'intègre au terminal de plan et aux éditeurs de prompt, insérant le texte reconnu directement dans le composant actif et affichant des notifications si la transcription échoue.

Le serveur gère la configuration des providers (clés API dans un vault chiffré, limites de débit, règles de routage pour OpenAI, Anthropic, Google), le routage de modèle (proxy de requêtes, failover automatique, équilibrage de charge, suivi des coûts par utilisateur/projet), la facturation (gestion des abonnements, mesure de l'utilisation, application des quotas, alertes de coût) et les APIs de recherche web (mise en cache des résultats avec TTL de 30/7 jours, restrictions géographiques, auth JWT).

Les tâches, plans, jobs et sessions circulent entre les composants : (1) Raffinement de tâche : React UI → TextImprovementPopover → commande Tauri → WorkflowOrchestrator → prompt text_improvement → SQLite → le provider React remplace le texte. (2) Découverte de fichiers : panneau Plans d'implémentation → commande Tauri → 4 jobs séquentiels → événements de progression → SQLite → affichage UI. (3) Plans d'implémentation : Découverte de fichiers → Générer Plan → commande Tauri → streaming LLM → SQLite → visualiseur Monaco → révision/approbation → export. (4) Exécution terminal : session PTY → SQLite → exécution de commande → streaming de sortie → injection de transcription vocale → détection d'attention de l'agent → logs d'audit.