Primer agente privilegiado en agents/_specials/. Usa provider claude-code
con acceso completo al repositorio para ejecutar el pipeline de creacion
de agentes de forma autonoma (scaffold, build, register, verify, restart).
Archivos:
- agent.go: reglas puras (DM/mention → LLM)
- config.yaml: claude-code provider, bypassPermissions, E2EE, audit
- prompts/system.md: guia completa de creacion con decision tree,
convencion de IDs, validaciones y seccion anti-injection
Config: claude-code con working_dir al repo, allowed_tools restringido,
model sonnet, timeout 10m, add_dirs con templates y referencias.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Establece la convención de que directorios con prefijo _ en agents/
son del sistema (templates, specials), no agentes desplegables.
Cambios:
- Renombrar agents/specials/ → agents/_specials/
- Actualizar path en cmd/launcher/main.go (startOrchestrator)
- Documentar convención _ en CLAUDE.md
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Issues planificados:
- 0036: Claude Code streaming de progreso en Matrix
- 0037: Agente que crea otros agentes/bots via Matrix
- 0038: Webapps y dashboards embebidos en Element via widgets
- 0039: Recordatorios dinámicos y crons que invocan agentes
- 0040: Soporte para mensajes de voz (audio → STT)
- 0041: Videollamadas con agentes via LiveKit
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- internal/config/loader.go: skip validacion de LLM provider cuando
agent.type es "robot" — los robots no usan LLM
- agents/test-bot/config.yaml: usar command_prefix: "" para que acepte
comandos sin prefijo ! (feature del issue 0033)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- !echo <texto>: repite el texto recibido (util para assertions exactas)
- !dice / !dado: lanza un dado aleatorio (1-6)
- Registro en cmd/launcher/main.go via testbot.Commands()
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tambien resuelve conflicto de test helper newTestAgent entre
runtime_test.go (issue 0029) y commands_metrics_test.go (issue 0035)
renombrando el segundo a newMetricsTestAgent.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Implementa el comando built-in !metrics que lee los JSONL logs del dia
actual usando shell/logger/query.go y calcula agregados en memoria:
- Mensajes recibidos (handling event)
- Comandos ejecutados (command_received)
- Llamadas LLM (count, tokens totales, latencia media)
- Llamadas a tools (count, errores)
- Errores totales (nivel ERROR)
- Total de entradas de log
El comando se registra como built-in disponible para todos los agentes.
Recibe logDir via Option pattern (WithLogDir) para no romper la firma
de agents.New(). El launcher pasa logDir al crear cada agente.
Formatea la salida como tabla markdown para Matrix.
Incluye tests unitarios con logs JSONL sinteticos.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Crea shell/audit/ con Writer que escribe eventos de auditoria a archivo
JSONL y opcionalmente a un room Matrix. Integra la emision de eventos
en los puntos clave del runtime:
- message_received: al recibir cualquier evento Matrix (handler.go)
- command_exec: al ejecutar un comando (handler.go)
- tool_exec: al ejecutar una tool (tools/registry.go via AuditFunc callback)
- llm_request / llm_error: al llamar al LLM (llm.go)
El Writer se inicializa en agents/runtime.go si security.audit.enabled=true.
Usa patron de inyeccion de dependencias (MatrixSender como funcion,
AuditFunc como callback) para evitar acoplamiento entre packages.
Incluye tests completos para el Writer: escritura JSONL, filtrado por
Include, modo solo-file, modo solo-room, auto-set de timestamp.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tests del parser (pkg/message/parse_test.go):
- Con prefijo !: comando estandar, con args, sin prefijo no detecta, lowercase
- Sin prefijo: comando bare, con args, ! retrocompatible, primer token, lowercase
- Casos borde: mensaje vacio, solo espacios, solo "!"
- Retrocompatibilidad: "!help" con prefix="" produce mismo resultado que con "!"
- Deteccion de menciones independiente del modo de prefijo
Tests del robot (agents/robot_test.go):
- !help muestra comandos sin ! cuando command_prefix es ""
- Comandos custom en modo sin prefijo
- Mismo conjunto de built-ins en ambos modos
- newTestRobot ahora configura command_prefix: "!" explicitamente
Cuando command_prefix es "" en el config, el parser trata el primer token
del mensaje como nombre de comando sin requerir el prefijo !. Si el token
empieza con !, se le quita igualmente para retrocompatibilidad.
Cambios:
- pkg/message/parse.go: modo sin prefijo en Parse() (puro, sin side effects)
- agents/robot.go: mensaje "comando desconocido" y !help adaptados al prefijo
- agents/handler.go: mensaje "comando desconocido" adaptado al prefijo
- internal/config/schema.go: documentar command_prefix: "" en FiltersCfg
- agents/_template_robot/config.yaml: ejemplo comentado de command_prefix: ""
El comportamiento con command_prefix: "!" no cambia (retrocompatible).
Tests de command routing: builtin help/ping, comando desconocido,
RegisterCommand, alias, ACL deniega comando.
Tests de reglas + LLM: DM sin reglas cae a LLM, DM sin LLM ignora,
regla matchea ejecuta accion, ActionKindReply estatico, ActionKindLLM
invoca CompleteFunc, mencion sin reglas cae a LLM, mensaje sin match
ni mencion se ignora, LLM action sin LLM configurado.
Tests de tool-use loop: tool call ejecuta y retorna, tool call falla
pasa error al LLM, max iterations se respeta, RBAC deniega tool call,
error de LLM se propaga.
Infraestructura: mockCompleteFunc con respuestas configurables,
spyMatrixSender que graba mensajes, newTestAgent minimal.
Cobertura: handleEvent 86%, executeActions 79%, runLLM 85%
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Añade un campo `sender effects.MatrixSender` al struct Agent que reemplaza
las llamadas directas a `a.matrix` para enviar mensajes (sendReply, typing,
SendMarkdown en handleTaskEvent). En produccion, sender apunta al mismo
*matrix.Client. Esto permite inyectar un spy en tests sin requerir una
conexion real a Matrix.
El campo `a.matrix` se mantiene para operaciones que no son de envio
(SetPresence, Raw, etc.).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Incluye 12 tests que cubren:
- Comandos built-in del Robot (help, ping, status, info, version)
- Verificacion de que !help muestra solo comandos de robot (no tools/clear/prompts)
- Registro y ejecucion de comandos custom via RegisterCommand
- Aliases de comandos
- Robot ignora mensajes sin comando (no hay LLM)
- Ciclo de vida: Stop/Done
- Stop seguro con cancel nil
- Verificacion compile-time de que Agent y Robot satisfacen Runner interface
- Conteo exacto de comandos built-in (5, no mas)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduce la separacion Robot vs Agent en el sistema:
- agents/types.go: interfaz Runner comun (Run, Stop, Done, RegisterCommand)
que tanto Agent como Robot satisfacen
- agents/robot.go: struct Robot — runtime minimo que solo conecta a Matrix
y despacha comandos. Sin LLM, reglas, memoria, knowledge, skills ni tools.
Mensajes normales se ignoran silenciosamente
- internal/config/schema.go: campo Type en AgentMeta ("agent"|"robot")
- cmd/launcher: usa Runner interface para manejar ambos tipos uniformemente.
Si cfg.Agent.Type == "robot" crea NewRobot en vez de New (tanto en
arranque como en hot-reload)
- agents/_template_robot/config.yaml: plantilla minima (~55 lineas) para
robots command-only
El Robot soporta built-in commands reducidos (help, ping, status, info,
version) y comandos custom via RegisterCommand. No incluye tools, tool,
clear ni prompts ya que no tiene LLM ni memoria.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Agrega 8 tests para buildToolRegistry() que verifican:
- Config minima: solo tools always-on (current_time, get_weather, matrix_send)
- HTTP habilitado/deshabilitado: http_get y http_post
- FileOps read-only: registra read_file y list_directory pero NO write/append/delete
- FileOps read-write: registra todas las 5 file tools
- IMDb habilitado: imdb_search
- SSH habilitado: ssh_command
- Conteo total: 12 tools con todo habilitado (sin deps externas)
Estos tests validan la logica condicional de registro que ahora vive
en registry_build.go, separada del runtime principal.
Expande el paquete tools/file/ con 4 operaciones nuevas para que los agentes
puedan interactuar con carpetas de trabajo (workspaces, outputs).
Cambios:
- Extraer validatePath() y resolveReal() a validate.go para reutilizarlos
- Agregar validateWritePath() que verifica ReadOnly == false
- write_file: crea/sobreescribe archivos, crea dirs padre, limite 1MB
- list_directory: lista archivos con metadata, modo recursivo, limite 500 entries
- append_file: agrega contenido al final, crea si no existe, limite 10MB total
- delete_file: borra solo archivos (nunca directorios), previene rm -rf accidental
- Registrar las 4 tools nuevas en runtime.go condicionalmente:
- list_directory: siempre (no requiere escritura)
- write/append/delete: solo si ReadOnly == false
Seguridad: todas las tools reutilizan validatePath() con deny-by-default,
resolucion de symlinks y proteccion contra path traversal.
Cobertura completa del registro global de reglas:
- Register + GetRules: registro exitoso y recuperacion
- GetRules con ID inexistente: retorna nil
- Register duplicado: panic con mensaje descriptivo
- RegisteredIDs: retorna todos los IDs registrados
- resetRegistry: limpia el registro (helper para tests)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduce un registro global de reglas en agents/registry.go con
Register() y GetRules(). Cada paquete de agente se auto-registra
via init(), eliminando la necesidad de editar manualmente el map
rulesRegistry en cmd/launcher/main.go.
Cambios:
- agents/registry.go: nuevo registro global con sync.RWMutex
- agents/*/agent.go: cada agente llama agents.Register() en init()
- agents/_template/agent.go: placeholder AGENT_ID_PLACEHOLDER para scaffold
- cmd/launcher/main.go: elimina rulesRegistry, usa blank imports +
agents.GetRules() para obtener reglas por agent ID
Patron: init() + blank import (estandar Go: database/sql, image codecs)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Elimina 14 structs nunca referenciados en el codebase:
- ObservabilityCfg y sub-structs (LoggingCfg, MetricsCfg, HealthCfg, TracingCfg)
- ResilienceCfg y sub-structs (CircuitBreakerCfg, RetryCfg, ShutdownCfg, QueueCfg)
- AgentsCfg y sub-structs (PeerCfg, DelegationCfg, ProtocolCfg)
Se eliminan los campos Agents, Observability y Resilience del AgentConfig root.
CommunicationCfg se mantiene porque esta activamente usada por pkg/personality/
y agents/commands.go.
schema.go pasa de 561 lineas / 61 structs a 460 lineas / 47 structs.
El template _template/config.yaml se reduce de 414 a ~220 lineas.
Los configs de assistant-bot y asistente-2 se limpian de secciones muertas.
yaml.v3 ignora campos extra, asi que YAMLs antiguos siguen parseando sin error.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Implementa una nueva tool que permite buscar películas y series en IMDb
usando la API de OMDb. Retorna hasta 5 resultados con título, año, tipo,
poster URL e IMDb ID.
Cambios:
- tools/imdb/imdb.go: tool imdb_search con integración a OMDb API
- internal/config/schema.go: IMDbToolCfg con api_key, api_key_env y timeout
- agents/runtime.go: registro de tool en buildToolRegistry
- agents/asistente-2/config.yaml: habilitación de tool imdb
- .env.example: OMDB_API_KEY para configuración
La tool soporta parámetros:
- query (requerido): título de película/serie a buscar
- year (opcional): año para filtrar resultados
Configuración via api_key directa o variable de entorno OMDB_API_KEY.
API key gratuita disponible en http://www.omdbapi.com/🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Se crea template_para_llm.md en agents/_template/ con los campos mínimos necesarios para que Claude genere un agente completo:
- Campos obligatorios: id, name, description, system prompt
- Campos opcionales con defaults: provider LLM, model, tool_use, personalidad
- Checkboxes para capacidades específicas (HTTP, SSH, files, etc.)
- Ejemplo completado para referencia
El template permite crear agentes solo proporcionando lo esencial, sin necesidad de entender toda la estructura interna del sistema.
Fase 1: Sistema de personalidades enriquecido
- Ampliar PersonalityCfg con role, backstory, expertise, limitations
- Añadir CommunicationCfg (formality, humor, personality, response_style, quirks, catchphrases)
- Crear tipos puros en pkg/personality/traits.go
- Implementar BuildPersonalityPrompt() para generar bloque de system prompt
- Integrar personalidad en agents/runtime.go (FromConfig + concatenacion al system prompt)
Fase 2: Agente plantilla
- Añadir campo Template bool a AgentMeta
- Filtrar agentes template en launcher (skip si template: true)
- Crear agents/_template/ con config.yaml completo y documentado
- Incluir TODAS las secciones (skills, shared_knowledge, schedules, security)
- agent.go minimo + prompts/system.md plantilla
- Actualizar dev-scripts/agent/new-agent.sh para copiar desde _template/
Fase 3: Ejemplos de personalidades
- Crear agents/_template/PERSONALITIES.md con 4 perfiles:
* DevOps pragmatico
* Analista meticuloso
* Asistente amigable
* Guardian de seguridad
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Integrar sistema de skills en agents/runtime.go:
- Agregar skillLoader al struct Agent
- Inicializar loader y executor cuando skills.enabled = true
- Registrar skill tools en buildToolRegistry
- Respetar filtro de categorias configurado
- Aplicar timeout configurado para scripts
Las skills quedan disponibles automaticamente para agentes que
las habiliten en su config YAML.
Arquitectura: skills como extension opcional, no dependencia core.
- Separar herramientas en dos secciones
- Explicar diferencia entre knowledge privado y shared
- Guía de cuándo usar cada una
- Issue 0018: Shared Knowledge (fase 5)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Agregar campo sharedKnowledgeStore al Agent struct
- Inicializar shared store si cfg.Tools.SharedKnowledge.Enabled
- Registrar shared tools en buildToolRegistry
- Cerrar shared store en Run defer
- Defaults: dir=knowledges, db=knowledges/data/knowledge.db
- Issue 0018: Shared Knowledge (fase 3)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implementa el cliente MCP que permite a los agentes conectarse a servidores
MCP externos y usar sus tools como si fueran tools nativas del agente.
Arquitectura implementada:
- shell/mcp/client.go: Cliente MCP con soporte stdio y SSE
- shell/mcp/manager.go: Gestor de múltiples clientes MCP
- tools/mcptools/mcp.go: Bridge que convierte MCP tools → tools.Tool
- shell/mcp/server.go: Movido desde shell/protocols/ para colocación junto al client
Cambios en config:
- MCPServerCfg extendido con campos Transport, Command, Args, Env, Headers,
Prefix, Timeout para soportar stdio y SSE transport
Integración en runtime:
- agents/runtime.go: Inicializa MCP manager si config.Tools.MCP.Enabled
- buildToolRegistry: Registra tools MCP automáticamente con prefijos configurables
- Agent: Campo mcpManager que se cierra en shutdown
Transportes soportados:
- stdio: Lanza subproceso (ej: npx -y @anthropic/mcp-server-brave-search)
- SSE: Se conecta a servidor HTTP MCP
Las tools MCP son indistinguibles de tools nativas desde el punto de vista
del LLM. Auto-discovery via ListTools(), conversión de JSON Schema a tools.Param.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Migrar admin a security/user-groups.yaml (admins group)
- agents.New() ahora acepta acl.ACL pre-resuelta como parámetro;
elimina construcción interna desde cfg.Security.Roles
- cmd/launcher: carga shellsecurity.Load("security/") al arranque;
si falla, WARN + política vacía (open access). Para cada agente
llama pksecurity.ResolveACL y pasa la ACL a agents.New()
- cmd/launcher/registry.go: stores secPolicy en launchDeps para
que reload() también resuelva ACL centralmente
- shell/matrix/listener.go: elimina invite gating y allowlist check
basados en AllowedUsers; el control de acceso lo hace el runtime
- internal/config/schema.go: depreca campos Roles y AllowedUsers
(backward compat, no eliminados)
- agents/*/config.yaml: elimina bloques security.roles y allowed_users
- dev/feature_flags.json: activa centralized-security-groups (enabled: true)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Se instancia shellcron.Scheduler en agents.New() cuando cfg.Schedules tiene
entradas (scheduler queda nil en agentes sin schedules, sin overhead).
En agents.Run() se arranca el scheduler en una goroutine independiente que
termina cuando el ctx del agente es cancelado — el shutdown es limpio gracias
a cron.Stop() que devuelve un contexto que se espera.
La integración no rompe agentes existentes: el campo scheduler es nil por
defecto y todo el código nuevo está tras if a.scheduler != nil.
- shell/bus/bus_test.go: tests de Subscribe/Send/Unsubscribe incluyendo
idempotencia, canal cerrado tras unsubscribe y resubscribe posterior.
- cmd/launcher/registry_test.go: tests para readReloadTarget (archivo
ausente, vacío, '*', agentID, whitespace).
- agents/lifecycle_test.go: tests para Agent.Stop()/Done() verificando
que Stop() desbloquea Run y que es seguro llamarlo múltiples veces o
con cancel nil.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Implementa el mecanismo de hot-reload descrito en el issue 0013:
- agents/runtime.go: añade Agent.Stop() y Agent.Done() para ciclo de vida
individual. Run() crea un contexto hijo cancelable y cierra el canal
done al retornar.
- cmd/launcher/registry.go (nuevo): agentRegistry rastrea agentes vivos
por ID. Métodos: register, stopAndWait, reload, reloadAll, waitAll,
cleanupLogs. reload() sigue el flujo completo: stop→wait→unsubscribe
→reload config→recreate→rewire bus/orch→start nueva goroutine.
- cmd/launcher/main.go: usa agentRegistry en lugar de sync.WaitGroup.
Añade handler de SIGHUP en goroutine separada que lee run/reload.txt
para determinar el agente objetivo (* o vacío = todos). Tras leer,
borra run/reload.txt para no afectar el siguiente SIGHUP.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Dos problemas corregidos:
1. Detección de threads con E2EE: después de desencriptar un evento,
evt.Content.Raw puede no contener m.relates_to. Se añade fallback
usando el contenido tipado (evt.Content.Parsed) que es más robusto
tras la desencriptación de mautrix.
2. Notificaciones de tools fuera del thread: la notificación "🔨 tool"
se enviaba con SendMarkdown directo a la sala, ignorando el contexto
de thread. Ahora usa sendReply que respeta ThreadID.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Añade la seccion matrix.threads con enabled: true a los 3 agentes
existentes (assistant-bot, asistente-2, meteorologo). Esto activa
el soporte de threads implementado en issue 0012, permitiendo que
los bots respondan dentro de threads cuando reciben mensajes en uno.
auto_thread queda en false para no cambiar el comportamiento actual.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implementa el soporte completo de threads de Matrix:
- Listener extrae ThreadID de m.relates_to con rel_type=m.thread
- Client.SendThreadMarkdown envia mensajes como parte de un thread
usando SetThread de mautrix con fallback m.in_reply_to
- Runner detecta ThreadID en ReplyAction y rutea a SendThreadMarkdown
- MatrixSender interfaz actualizada con SendThreadMarkdown
- runtime.go propaga ThreadID en todas las respuestas (comandos, LLM, RBAC)
- sendReply helper centraliza la logica de envio con/sin thread
- Auto-thread: si matrix.threads.auto_thread=true, crea thread nuevo
para cada conversacion que no esta ya en un thread
- Memoria por thread: usa ThreadID como clave de window cuando el mensaje
esta en un thread, permitiendo conversaciones paralelas independientes
- Config: matrix.threads.enabled y matrix.threads.auto_thread en ThreadsCfg
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Setear working_dir a /tmp/claude-agents/<agent-id> en assistant-bot
y asistente-2, evitando que claude -p herede el CWD del launcher
(raiz del repo). El directorio se crea automaticamente al arrancar
gracias al MkdirAll añadido en el commit anterior.
Se mantiene bypassPermissions ya que el aislamiento real viene del
working_dir — sin acceso al repo, el bypass no expone codigo fuente.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Crea template reutilizable en .claude/templates/security-prompt.md y
aplica seccion de seguridad obligatoria a todos los system prompts:
- assistant-bot/prompts/assistant-system.md
- asistente-2/prompts/system.md
- meteorologo/prompts/system.md
Las instrucciones cubren:
- Rechazo de acciones fuera del rol
- Proteccion del system prompt (no revelar)
- Rechazo de comandos destructivos
- Validacion de coherencia contextual de tool calls
- Resistencia a redefinicion de identidad
- Prohibicion de generar contenido para ataques
Tareas 3.1, 3.2, 3.3 del issue 0019.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Añade BasePath a StorageCfg y resolveDataBase() en runtime.go para
centralizar la resolucion del directorio base de datos del agente.
Prioridad: config storage.base_path > $AGENTS_DATA_DIR/<id> > agents/<id>/data
Esto permite mover los datos de runtime fuera del arbol del proyecto,
evitando que herramientas de desarrollo lean bases de datos, logs o
crypto stores por accidente.
Los paths de memory.db y knowledge.db ahora usan el base resuelto.
Los configs existentes no se rompen (fallback al path original).
Tareas 1.1 y 1.2 del issue 0019.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Añade rate limiting de tool calls por room usando sliding window:
- tools/ratelimit.go: RateLimiter con sliding window per key (room),
Allow() para verificar/registrar llamadas, Cleanup() para limpiar
entries expiradas
- tools/registry.go: SetRateLimiter() y ExecuteForRoom() que verifica
el rate limit antes de ejecutar, logueando tool_rate_limited si excede
- internal/config/schema.go: ToolRateLimitCfg en SecurityCfg con
enabled, max_calls_per_min y cleanup_interval_s
- agents/runtime.go: inicializa rate limiter desde config y arranca
goroutine de cleanup periodico
- agents/commands.go: usa ExecuteForRoom en !tool command
Config YAML:
security:
tool_rate_limit:
enabled: true
max_calls_per_min: 10
Parte de issue 0019c (prompt injection hardening — rate limiting).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- agents/runtime.go: campo sanitizeOpts en Agent, sanitizeInput() que
llama a sanitize.Sanitize() y loguea warnings. Integrado en
executeActions() y handleTaskEvent() antes de enviar al LLM.
En modo reject, responde al usuario y corta el flujo.
- internal/config/schema.go: nuevo tipo SanitizeCfg dentro de SecurityCfg
con campos enabled, mode, min_severity, disabled_patterns.
Protegido por feature flag prompt-injection-hardening (OFF).
Se activa por agente via security.sanitize.enabled en config.yaml.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios de seguridad en las 4 herramientas de agentes:
- tools/file: deny-by-default (AllowedPaths vacío = todo denegado),
resolución de symlinks con EvalSymlinks, protección contra path
traversal (../) y confusión de prefijos (/opt vs /opt1234)
- tools/ssh: nuevo AllowedCommands allowlist (complementa ForbiddenCommands),
validación de sintaxis shell (bloquea pipes, subshells, redirects, chains)
- tools/http: protección SSRF bloqueando IPs privadas, loopback, link-local,
metadata (169.254.169.254). Validación de dominio case-insensitive.
- tools/matrix: nuevo parámetro AllowedRooms para restringir rooms destino
- internal/config/schema: AllowedCommands en SSHToolCfg, MatrixToolCfg nueva
- agents/runtime: pasa MatrixToolCfg al constructor de matrix_send
Parte de issue 0019 (prompt injection hardening). Feature flag OFF.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Conectar el campo unauthorized_response de FiltersCfg al shouldHandle()
del listener. Cuando está configurado como "explicit", el bot responde
con un mensaje de permisos denegados en lugar de ignorar silenciosamente.
También se añaden los campos allowed_users y unauthorized_response
(comentados como ejemplo) a los configs de assistant-bot y asistente-2.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios en 3 archivos:
- agents/runtime.go: construye ACL desde config de roles, verifica permisos
antes de ejecutar comandos (command:<name>), interacción LLM (ask) y
ejecución de tools (tool:<name>). Mensajes denegados se loguean y
responden al usuario.
- shell/matrix/listener.go: filtra invites y mensajes de usuarios no
autorizados cuando se configura allowed_users (allowlist vacía = todos).
- internal/config/schema.go: añade campos AllowedUsers y
UnauthorizedResponse a FiltersCfg para soportar la allowlist en config.
Esto conecta el paquete pkg/acl con el runtime para dar soporte completo
a control de acceso por rol, sin romper la compatibilidad (ACL vacío
permite todo como antes).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Añade pkg/command/prompts.go para cargar prompts desde archivos .md externos
en el directorio prompts/. Mejoras en agents/runtime.go para el manejo de
herramientas y flujo de ejecución. Nuevos comandos en agents/commands.go.
Ajustes menores en pkg/command/builtins.go para integrar las nuevas capacidades.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Renumera todos los archivos de tasks de 2 dígitos (01-, 02-...) a
3 dígitos (001-, 002-...) para mejor ordenación. Añade tres nuevas
tasks pendientes: 012-threads, 013-hot-reload, 014-template-agent.
Deshabilita memory temporalmente en assistant-bot config mientras
se estabiliza el sistema de memoria.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Mejora la salida de !help, !tools, !status e !info para usar markdown
nativo: encabezados en negrita, listas con bullet points, código inline
con backticks. Aprovecha el rendering HTML que ya hace el bot para que
los clientes Matrix muestren la información formateada correctamente.
No se cambia lógica de comandos, solo formato de texto de salida.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
egutierrez