Se propaga *slog.Logger a todos los componentes impuros del shell:
- shell/bus/ — logs de subscribe, send, reply, timeout, unsubscribe
- shell/effects/ — duración y resultado de cada action ejecutada
- shell/llm/ (anthropic, openai, factory) — request/response con tokens, duración, fallback
- shell/memory/sqlite — open, save, recall, close con detalles
- shell/ssh/ — inicio, fin, errores y duración de comandos SSH
- tools/registry — registro, ejecución y errores de herramientas
Se usa el paquete shell/logger para field names consistentes (FieldDurationMS, FieldTokensUsed, etc.).
Cada componente recibe el logger por inyección de dependencias, sin globals.
Las firmas de New/FromConfig se actualizan para aceptar *slog.Logger.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nuevo paquete shell/logger/ que implementa logging estructurado JSONL
para agentes. Incluye DailyRotatingWriter con rotación diaria y por
tamaño (50MB default), limpieza automática de archivos viejos (7 días),
compresión gzip de logs rotados, y funciones de consulta (ReadLogs,
SearchLogs, ListAgents, ListDates) para que agentes LLM puedan leer
logs de otros agentes. Basado en log/slog de stdlib, sin dependencias
externas. 18 tests unitarios cubren rotación, concurrencia y consultas.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Se añade un mecanismo de detección de repetición para cortar conversaciones
circulares entre agentes cuando hablan sin parar.
- Nuevo campo RepetitionThreshold en OrchestrationCfg (schema.go).
- Función detectRepetition() compara cada nueva respuesta con las anteriores
usando similitud de bigramas (Dice coefficient).
- Si la similitud supera el umbral (default 0.6), el pipeline se detiene
inmediatamente con un log de warning, antes de gastar una llamada LLM
en la evaluación de calidad.
- Funciones auxiliares: similarity() y makeBigrams() para el cálculo.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Actualiza el dashboard TUI y el process manager para el modelo de launcher
unificado donde todos los agentes corren en un solo proceso.
Dashboard (pkg/tui):
- model.go: campos de estado del launcher (PID, uptime, memory, CPU, log size)
- model.go: ServerMenuOptions(running) contextual, AgentActionOptions(enabled)
- messages.go: MsgAgentsLoaded incluye estado del launcher, MsgServerActionDone/MsgRebuildDone simplificados
- update.go: intents nuevos (Enable/Disable agent, Start/Stop/Restart/Kill launcher)
- view.go: vista de servidor muestra stats del launcher, agentes muestran enabled/disabled
Shell adapter (shell/tui):
- adapter.go: reescrito para usar métodos unificados (StartUnified, StopUnified, ToggleEnabled, StatusAllUnified, UnifiedStats, UnifiedLogTail)
Process manager (shell/process):
- manager.go: métodos StartUnified, StopUnified, KillUnified, IsUnifiedRunning, UnifiedPID, UnifiedStats, UnifiedLogTail, StatusAllUnified, ToggleEnabled
Los agentes ya no se inician/detienen individualmente desde el dashboard.
Se habilitan/deshabilitan en config y se reinicia el launcher para aplicar.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implementa el sistema de orquestación para salas Matrix con múltiples bots.
El orquestador es un "special agent" sin identidad Matrix que coordina qué bot
responde y cuándo, usando LLM (Claude) para routing y evaluación de calidad.
Cambios principales:
- pkg/orchestration/task.go: tipos puros (TaskEvent, BotResponse, QualityScore, RoutingDecision)
- shell/orchestration/: runtime del orquestador (orchestrator.go, router.go, evaluator.go)
- agents/specials/orchestrator/: config + prompts (routing, quality, refinement)
- internal/config/: SpecialConfig, OrchestrationCfg, LoadSpecial()
- shell/bus/bus.go: protocolo request-reply (SendAndWait, Reply) para delegación
- shell/matrix/listener.go: InterceptFunc para interceptar eventos en salas orquestadas
- agents/runtime.go: SetBus, listenBus, handleTaskEvent para recibir tareas del orquestador
- cmd/launcher/main.go: creación de bus compartido, arranque del orquestador antes de bots
Incluye deduplicación para evitar que múltiples listeners en la misma sala
disparen el orquestador más de una vez por mensaje.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implementa un dashboard interactivo con bubbletea siguiendo el patrón
pure core / impure shell del proyecto:
- pkg/tui/ (PURE): Model, Update, View — solo fmt y strings, cero I/O.
Update produce Intent[] (datos puros) en vez de side effects.
- shell/tui/ (IMPURE): Adapter convierte Intent[] en tea.Cmd[] con I/O real
(process management, /proc stats, log tail).
- cmd/dashboard/ (composición): Bridge conecta pure Update con shell Adapter
usando la Elm Architecture de bubbletea.
Pantallas: Main Menu → Agent List → Agent Actions (start/stop/restart/kill) → Logs.
Navegación: flechas ↑↓, Enter seleccionar, 0 volver, q salir.
Dependencias añadidas: bubbletea, lipgloss.
Actualiza .gitignore para anclar binarios a raíz (/agentctl, /dashboard).
Documenta nuevos scripts en CLAUDE.md.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Extrae toda la lógica de gestión de procesos (scan, start, stop, kill, stats,
log tail) de cmd/agentctl/main.go a shell/process/manager.go como paquete
reutilizable siguiendo el patrón impure shell del proyecto.
agentctl queda como thin wrapper sobre process.Manager — misma funcionalidad,
mismo comportamiento. El nuevo paquete será compartido por el TUI dashboard.
Añade funcionalidad nueva al Manager: Stats() para métricas de /proc,
LogTail() para últimas N líneas, Stop() con espera graceful + SIGKILL fallback.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
egutierrez