- 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>
El metodo OptionalGetRelatesTo() esta definido con pointer receiver en event.MessageEventContent. Al pasarlo como valor (no puntero) a SendMessageEvent, mautrix-go no puede hacer el cast a event.Relatable, getRelatesTo() retorna nil, y el evento m.room.encrypted exterior queda sin m.relates_to.
Esto causaba que Element Web no viera la relacion de thread en el evento cifrado exterior y mostrara la respuesta del agente en la timeline principal en lugar del thread, incluso cuando el payload descifrado tenia m.relates_to correcto.
Fix: cambiar 'content := event.MessageEventContent{...}' a 'content := &event.MessageEventContent{...}' en los tres metodos de envio. Consistente con el propio uso de mautrix en client.go linea 1161.
Añade un tercer mecanismo de deteccion de thread en listener.go para cubrir el caso en que mautrix-go no propaga m.relates_to al payload descifrado.
El problema ocurria cuando Element Web (matrix-js-sdk versiones antiguas) no incluia m.relates_to en el contenido exterior del evento m.room.encrypted. mautrix-go solo copia m.relates_to al payload descifrado si EncryptedEventContent.RelatesTo != nil, por lo que los dos mecanismos existentes (raw map + typed content) fallaban.
La solucion registra un listener global (OnEvent) que captura m.relates_to del evento cifrado ANTES de que CryptoHelper lo descifre y re-despache (los listeners globales se ejecutan antes que los de tipo especifico segun DefaultSyncer.Dispatch). El valor se guarda en un sync.Map keyed por event ID y se consume con LoadAndDelete en el handler EventMessage.
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>
Tests unitarios:
- runner_test.go: verifica ruteo correcto de ReplyAction segun
ThreadID (plain markdown, reply, thread, thread sin fallback, nil reply)
- thread_test.go: extraccion de ThreadID desde m.relates_to raw
(thread, reply sin thread, plain, m.replace, thread sin event_id)
- thread_relates_test.go: estructura JSON de RelatesTo.SetThread
cumple la spec de Matrix (rel_type, event_id, is_falling_back, m.in_reply_to)
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>
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 soporte para que las respuestas de los bots sean replies nativos
de Matrix (m.in_reply_to) en lugar de mensajes sueltos. Los clientes
Matrix mostrarán el mensaje original citado.
Cambios:
- EventID en MessageContext para capturar el ID del evento entrante
- InReplyTo en ReplyAction para indicar a qué evento responder
- SendReplyMarkdown en el cliente Matrix (shell/matrix/client.go)
- Runner usa SendReplyMarkdown cuando InReplyTo está presente
- runtime.go pasa InReplyTo en todas las respuestas LLM y comandos
- SetPresence online al arrancar, offline al apagar (graceful)
No se tocan: herramientas, TUI, configuración de agentes.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Se configura goldmark con extensiones GFM (tablas, strikethrough,
autolinks, task lists), DefinitionList, Footnote, Typographer y CJK.
Esto reemplaza el parser básico por defecto por uno con soporte completo
de Markdown, mejorando el rendering de mensajes enviados por los bots
en Matrix. Se reutiliza una instancia global del parser para evitar
recrearlo en cada llamada.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Se reemplaza SendText por SendMarkdown en todos los puntos donde el agente
envía respuestas: runtime.go (comandos built-in y tareas orquestadas),
effects/runner.go (acciones Reply) y tools/matrix.go (matrix_send tool).
shell/matrix/client.go ahora usa goldmark para convertir Markdown a HTML real
en el campo FormattedBody del evento Matrix, cumpliendo con la spec de Matrix
para mensajes formateados. El Body conserva el markdown raw como fallback.
Se añade dependencia github.com/yuin/goldmark v1.7.16.
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>
egutierrez