Aplicar los contenidos reales de agent.go, config.yaml y prompts/system.md
a los dos agentes creados previamente, usando el nuevo personalize.sh.
- wikipedia-bot: tone=professional, prefix=📖, descripcion y system prompt
- exchange-bot: tone=professional, prefix=💱, tool_use=true, system prompt
Ahora ambos tienen la sección de seguridad anti-injection en su system.md.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
wikipedia-bot: agente GPT-4o con tool wikipedia_search para consultar
información de Wikipedia. Responde en español, tono profesional.
exchange-bot: agente GPT-4o con 4 tools de exchange rate para consultar
tasas de cambio, convertir entre monedas, listar monedas disponibles
y ver historial. Requiere EXCHANGERATE_API_KEY en .env.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Father Bot ya no tiene restricciones artificiales. Ahora puede:
- Crear, modificar y desactivar agentes
- Configurar tools con allowlists reales (no solo vacias)
- Gestionar permisos en security/
- Diagnosticar problemas leyendo logs
- Sin limite de agentes por sesion
Se eliminaron: restricciones de paths, rate limiting de creacion,
deny-by-default obligatorio en tools, prohibicion de modificar
agentes existentes, prohibicion de eliminar agentes.
Se mantienen: ACL admin-only, proteccion anti-injection del propio
Father Bot, prohibicion de mostrar .env, seccion de seguridad en
prompts de agentes creados.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Informa a Father Bot que el sistema muestra automaticamente progreso
al usuario en tiempo real, y que no necesita enviar mensajes
intermedios manuales. Esto evita duplicacion de feedback.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Issue para que Father Bot muestre feedback visual durante la creacion
de agentes. Incluye: habilitar streaming en config, mejorar formateo
del ProgressReporter con nombres de pasos legibles, y tests.
Tambien habilita streaming + show_tool_progress en el config de
Father Bot (quick win que activa el ProgressReporter existente).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Agrega campos streaming y show_tool_progress al template de config
del agente para documentar las nuevas opciones de claude-code.
Ambos desactivados por defecto (backward compatible).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Actualiza create_agent.md con el pipeline completo (12 pasos) al inicio
de la guia, referenciando los scripts de cada paso.
Actualiza system prompt de father-bot con:
- Pipeline de 12 pasos explicito con "nunca saltar pasos"
- Health check (paso 11) via health-check.sh antes de confirmar
- Self-introduce (paso 12) via notify-developer.sh
- Paso de reporte incluye confirmacion de health check y notify
- Manejo de errores para health check y notify
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Implementa restricciones adicionales de seguridad para father-bot,
el agente privilegiado que crea otros agentes. Los guardrails se
implementan como instrucciones en el system prompt (primera linea
de defensa) complementando el ACL admin-only existente.
Guardrails agregados:
- Control de acceso: verificacion explicita de admin antes de operar,
deny-by-default si no hay admins configurados (fase 1)
- Path scoping: allowlist de escritura (agents/, cmd/launcher/main.go),
denylist explicita (.env, security/, .git/) (fase 2)
- Rate limiting: maximo 3 agentes por sesion de conversacion,
verificacion de duplicados antes de crear (fase 3)
- Validacion post-creacion: checklist de seguridad obligatorio antes
de reiniciar launcher — sin sanitize deshabilitado, sin wildcards
en SSH/file, sin bypassPermissions, con seccion de seguridad en
prompt (fase 4)
- Paso 5.5 en el flujo de trabajo para ejecutar validacion de
seguridad despues de compilar y antes de reiniciar (fase 4)
- Audit ya estaba habilitado en config.yaml, verificado correcto (fase 5)
Issue: 0043
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>
egutierrez