Tutorial de Ejecución

• 1.El usuario ingresa o dicta una descripción de tarea en la UI de escritorio a través del componente TaskDescriptionEditor.
• 2.Opcional: el trabajo text_improvement refina la entrada sin procesar a través de TextImprovementProcessor.
• 3.El usuario activa el flujo de trabajo de descubrimiento de archivos a través del comando start_file_finder_workflow del panel de Planes de Implementación.
• 4.WorkflowOrchestrator en desktop/src-tauri/src/jobs/workflow_orchestrator/ crea un registro de flujo de trabajo y programa la etapa 1.
• 5.Etapa 1 (root_folder_selection): RootFolderSelectionProcessor envía el árbol de directorios al LLM, almacena las raíces seleccionadas en IntermediateData.selectedRoots.
• 6.Etapa 2 (regex_file_filter): RegexFileFilterProcessor genera patrones, ejecuta git ls-files, almacena coincidencias en IntermediateData.locallyFilteredFiles.
• 7.Etapa 3 (file_relevance_assessment): FileRelevanceAssessmentProcessor fragmenta contenidos de archivos, puntúa relevancia, almacena en IntermediateData.aiFilteredFiles.
• 8.Etapa 4 (extended_path_finder): ExtendedPathFinderProcessor expande el contexto con imports y dependencias, almacena en IntermediateData.verifiedPaths.
• 9.La UI recibe el evento workflow-completed a través de event_emitter.rs, actualiza la visualización de selección de archivos.
• 10.El usuario activa la generación de planes con los archivos seleccionados a través del comando generate_implementation_plan.
• 11.ImplementationPlanProcessor en desktop/src-tauri/src/jobs/processors/implementation_plan_processor.rs transmite contenido del plan XML al visor Monaco a través de eventos job:stream-progress.
• 12.El usuario revisa el plan en el componente VirtualizedCodeViewer, puede editar directamente o solicitar fusión.
• 13.El plan aprobado se copia al terminal a través de plantillas de botones de copiado o se exporta para agentes externos.
• 14.La sesión de terminal en terminal_commands.rs captura la salida PTY, detecta estados de atención del agente.
• 15.Todos los artefactos persisten en las tablas SQLite background_jobs y terminal_sessions para auditoría y recuperación de sesión.

• text_improvement → TextImprovementProcessor → descripciones de tareas refinadas
• root_folder_selection → RootFolderSelectionProcessor → directorios seleccionados
• regex_file_filter → RegexFileFilterProcessor → archivos coincidentes por patrón
• file_relevance_assessment → FileRelevanceAssessmentProcessor → archivos puntuados
• extended_path_finder → ExtendedPathFinderProcessor → contexto expandido
• implementation_plan → ImplementationPlanProcessor → documentos de plan XML
• implementation_plan_merge → ImplementationPlanMergeProcessor → planes fusionados

Las tareas ingresan al sistema a través de múltiples superficies de entrada: texto escrito en TaskDescriptionEditor, dictado de voz a través del hook useVoiceTranscription, o análisis de video a través de VideoAnalysisDialog.

Cada tipo de entrada produce artefactos almacenados en SQLite - task_description en la tabla sessions, resultados de transcripción en background_jobs, y fotogramas de video en metadatos del trabajo asociado.

El tipo de trabajo text_improvement refina la entrada sin procesar a través de TextImprovementProcessor, envolviendo texto en XML y enviándolo al LLM para mejoras de gramática, claridad y estructura.

El texto refinado se almacena en background_jobs.response y puede actualizar sessions.task_description a través del proveedor React.

FileFinderWorkflow ejecuta cuatro etapas secuenciales: root_folder_selection reduce directorios, regex_file_filter aplica patrones, file_relevance_assessment puntúa contenido, y extended_path_finder expande con dependencias.

Cada etapa almacena resultados en estructuras IntermediateData pasadas entre procesadores, con selecciones finales de archivos persistidas en sessions.included_files.

El tipo de trabajo implementation_plan usa ImplementationPlanProcessor para generar planes formateados en XML con elementos plan_step conteniendo rutas de archivos, tipos de operación y cambios de código.

El contenido del plan se transmite a la UI a través de eventos Tauri job:stream-progress, mostrado en el componente VirtualizedCodeViewer Monaco con resaltado de sintaxis.

El trabajo implementation_plan_merge combina múltiples planes usando etiquetas XML source_plans e instrucciones de fusión proporcionadas por el usuario para resolver conflictos y consolidar cambios.

Los planes fusionados mantienen trazabilidad a los planes fuente e incluyen metadatos merged_from en el registro final de background_jobs.

Los planes se abren en el VirtualizedCodeViewer basado en Monaco para revisión. Los usuarios pueden editar el texto del plan directamente, solicitar modificaciones o aprobar para ejecución.

Todas las acciones de revisión se registran con marcas de tiempo y contexto del usuario, proporcionando una pista de auditoría de la evolución del plan.

Los planes aprobados se copian al terminal integrado a través de plantillas de botones de copiado, o se exportan para agentes externos como Claude Code, Cursor o Codex.

Las sesiones de terminal en terminal_commands.rs capturan salida PTY, detectan estados de atención del agente y registran toda la actividad de ejecución en la tabla terminal_sessions.

Todos los artefactos de trabajos persisten en la tabla background_jobs con session_id, task_type, status, prompt, response, conteos de tokens y seguimiento de costos.

Al reiniciar la aplicación, el núcleo Rust rehidrata el estado de sesión desde SQLite, marca trabajos en ejecución obsoletos como fallidos y restaura logs de salida del terminal.