PlanToCodeRevoir et fusionner des plans d'implementation
PlanToCode transforme les taches en plans d'implementation structures que vous pouvez lire, comparer et modifier avant qu'un agent n'agisse. Generez plusieurs brouillons, fusionnez la meilleure approche et transferez vers Claude Code ou votre terminal avec tout le contexte.
Ce site est la page d'accueil du dépôt PlanToCode. Consultez le code, la documentation et l'architecture ici.
Apercu du workflow plan-first
Un court walkthrough de la saisie de tache a la revue de plan, aux merge instructions et a l'execution handoff.
- Lancer plusieurs brouillons avec le meme contexte de fichiers
- Fusionner les meilleures idees avec des instructions explicites
- Revoir et modifier les plans sur desktop ou mobile
- Transmettre a Claude Code ou a un terminal local avec logs
Revue de plan avant execution
Plans are artifacts you can review, edit, and approve before any agent runs. Logs and history keep changes traceable.
Plans fichier par fichier avec chemins exacts
Les plans d'implementation decrivent les changements par fichier et operation pour clarifier le perimetre.
Revoir, modifier, approuver
Plans modifiables sur desktop ou mobile; chaque revision est conservee.
Transfert d'execution
Les plans approuves sont transmis aux terminaux ou aux CLI d'agents avec tout le contexte et les journaux d'audit.
Workflow de revue de plans dans l'app
See how file discovery, multi-model planning, merge instructions, and execution handoff keep agent work transparent and traceable.
Apercu du workflow plan-first
Un court walkthrough de la saisie de tache a la revue de plan, aux merge instructions et a l'execution handoff.
- ✓Lancer plusieurs brouillons avec le meme contexte de fichiers
- ✓Fusionner les meilleures idees avec des instructions explicites
- ✓Revoir et modifier les plans sur desktop ou mobile
- ✓Transmettre a Claude Code ou a un terminal local avec logs
Génération de plans multi-modèles
ImplementationPlanProcessor diffuse des brouillons de plans à partir du contenu complet des fichiers ; les jobs de fusion consolident plusieurs brouillons en un seul plan.
- ✓Les jobs de plan incluent le contenu des fichiers sélectionnés + l'arborescence
- ✓Métadonnées de plan structurées capturées par job
- ✓Le prompt de fusion utilise <source_plans> et <user_instructions>
- ✓Le plan final est stocké avec les brouillons sources
Instructions de fusion de plans
ImplementationPlanMergeProcessor fusionne plusieurs brouillons de plans en utilisant des plans sources balisés XML et des instructions optionnelles.
- ✓Plans sources récupérés par ID de job
- ✓Instructions de fusion stockées dans les métadonnées
- ✓Le contenu des fichiers + l'arborescence ajoutent du contexte
- ✓Le plan fusionné est stocké avec les entrées
Boutons d'automatisation de workflow
Les boutons de copie insèrent des prompts basés sur des modèles avec le contexte de la tâche pour le transfert vers des terminaux ou des outils externes.
- ✓Modèles provenant de la configuration du modèle de tâche
- ✓Placeholders résolus contre le plan actif
- ✓Transfert vers des sessions PTY ou le presse-papiers
- ✓Actions liées aux métadonnées de job pour l'audit
Pipeline de découverte de fichiers
Un workflow Rust en quatre étapes : sélection de racine assistée par LLM, filtrage regex, scoring de pertinence et recherche de chemins étendue pour construire un ensemble de fichiers ciblé.
- ✓La sélection du dossier racine utilise l'arborescence et la description de la tâche
- ✓Le filtre regex génère des groupes de motifs et applique git ls-files
- ✓Le scoring de pertinence découpe le contenu des fichiers avec des estimations de tokens
- ✓Le chercheur de chemins étendu élargit le contexte avec les données de fichiers et d'arborescence
Plan history and logs
Chaque étape du workflow écrit les résultats dans background_jobs pour que les ensembles de fichiers puissent être réutilisés entre les sessions et inspectés ultérieurement.
- ✓Étapes du workflow stockées comme enregistrements de jobs
- ✓Listes de fichiers sélectionnés persistées en réponses JSON
- ✓Les included_files de session réutilisés entre les jobs
- ✓L'historique SQLite survit aux redémarrages
Configuration des prompts et modèles
Les paramètres de modèle runtime sont récupérés depuis `/api/config/desktop-runtime-config` ; les substitutions de prompts sont stockées dans SQLite.
- ✓Modèles autorisés et valeurs par défaut par tâche
- ✓Prompts système servis par l'API du serveur
- ✓Substitutions de prompts au niveau projet dans project_system_prompts
- ✓key_value_store local pour les préférences runtime
Surveillance des jobs en arrière-plan
Les processeurs de jobs Rust diffusent la progression et les transitions d'état vers l'interface tout en persistant l'historique des jobs dans SQLite.
- ✓Created, queued, preparing, running, completed/failed/canceled
- ✓Mises à jour en streaming via les événements Tauri
- ✓Utilisation des tokens capturée par exécution
- ✓Annuler les jobs de longue durée
Optional screen recording analysis
Screen recordings can be sent to the /api/llm/video/analyze endpoint with a focus prompt and FPS hint to generate analysis summaries.
- ✓Multipart upload includes durationMs and framerate
- ✓Model format is provider/model (google/* required)
- ✓Usage and cost recorded per job
- ✓Summary stored in background_jobs response and can be applied to the task description
Registre d'utilisation et de coûts
Les entrées d'utilisation côté serveur et les métadonnées de job capturent l'utilisation des modèles à travers les fournisseurs.
- ✓Métadonnées de tokens et de coûts par job
- ✓Entrées d'utilisation conscientes du fournisseur
- ✓Les endpoints de facturation exposent des résumés d'utilisation
- ✓Usage history for model spend
Pret a revoir les plans avant l'execution des agents ?
Telechargez l'app desktop pour tester la planification multi-modele, la fusion de plans et l'execution handoff.
Transparence et controle
System prompts, code source et self-hosting sont visibles et documentes.
System prompts consultables
Les prompts par defaut sont dans le repo et la base serveur pour inspection et edition.
Docs des types de prompts ->Source available (BSL 1.1)
Le systeme complet est sur GitHub sous la Business Source License pour audit de l'architecture.
Voir le repo GitHub ->Self-hosting et BYOK
Hebergez le serveur vous-meme pour controler le routage des providers et fournir vos propres keys.
Guide de configuration serveur ->Questions fréquemment posées
Tout ce que vous devez savoir sur PlanToCode