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>
- new-agent.sh: reemplaza edicion del rulesRegistry map con insercion
de un blank import simple. Ahora tambien sustituye AGENT_ID_PLACEHOLDER
en agent.go con el ID real del agente.
- create_agent.md: actualiza template de agent.go con patron init() +
agents.Register(), secciones de registro en launcher y checklist.
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>
Mover issue 0027-prune-config-schema a completed/ y actualizar indice.
Todas las tareas implementadas: schema podado, template simplificado,
configs de agentes limpiados, tests de parsing agregados.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tres tests para internal/config:
- TestAgentConfigParseMinimal: config minimo con campos requeridos
- TestAgentConfigIgnoresRemovedSections: YAMLs antiguos con agents/observability/
resilience siguen parseando sin error (yaml.v3 ignora campos desconocidos)
- TestAgentConfigParseFull: config completo con todas las secciones activas
incluyendo personality.communication, tools, security, storage, memory y skills
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>
Registra los nuevos issues pendientes en el indice y excluye
la carpeta worktrees/ del control de versiones.
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.
Sistema de personalidades enriquecido con traits y prompts dinamicos. Agente template completo con configuracion estandarizada. Comando !info mejorado con metadata completa.
Issue 0014 completado:
✅ Fase 1: Sistema de personalidades enriquecido
- PersonalityCfg ampliado con role, backstory, expertise, limitations
- CommunicationCfg con formality, humor, personality, response_style, quirks
- BuildPersonalityPrompt() genera bloque para system prompt
- Integrado en runtime con FromConfig + concatenacion automatica
✅ Fase 2: Agente plantilla (_template)
- Campo Template bool en AgentMeta (launcher lo filtra)
- agents/_template/ completo con todas las secciones documentadas
- agent.go + prompts/system.md + config.yaml canonica
- new-agent.sh actualizado para copiar desde _template/
✅ Fase 3: Ejemplos de personalidades
- PERSONALITIES.md con 4 perfiles: DevOps pragmatico, Analista meticuloso,
Asistente amigable, Guardian de seguridad
✅ Fase 4: Comando !info enriquecido
- Metadata completa: identidad, personalidad, LLM, tools, skills,
knowledge, memoria, schedules, uptime
Fase 5 (estandarizar configs existentes): aplazada — los agentes actuales
funcionan correctamente. Los nuevos agentes usaran el template completo.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
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>
Sistema completo de skills reutilizables que permiten a los agentes
ejecutar flujos multi-paso complejos combinando tools, logica condicional
y conocimiento de dominio.
Componentes implementados:
- pkg/skills/: tipos puros (SkillMeta, Skill, matching)
- shell/skills/: loader (filesystem) + executor (scripts seguros)
- tools/skilltools/: 4 tools de function calling (search, load, read, run)
- internal/config/: SkillsCfg con filtros de categoria
- agents/runtime.go: integracion opcional con agentes
- skills/: 4 skills de ejemplo (deploy, log-analyzer, health-check, daily-report)
- .claude/rules/create_skill.md: guia completa para crear skills
Diferencia clave: tools son atomicas, skills son flujos declarativos.
Arquitectura: pure core (pkg/), impure shell (shell/), contenido declarativo (skills/).
Tests: matching, loader con path traversal protection, executor con allowlist.
Commits del merge:
- feat: tipos puros para sistema de skills
- feat: loader y executor de skills en shell
- feat: configuracion de skills en schema
- feat: tools de function calling para skills
- feat: integrar skills en runtime de agentes
- feat: skills de ejemplo y README del sistema
- docs: documentar sistema de skills
- chore: cerrar issue 0016 — sistema de skills
Mover issue 0016 a completed/ y actualizar README:
El issue 0016-skills-system ha sido completado con todas las fases:
- Estructura de directorios y skills de ejemplo
- Tipos puros (pkg/skills/)
- Loader y executor (shell/skills/)
- Configuracion en schema
- Tools de function calling
- Integracion con runtime
- Tests unitarios completos
- Documentacion completa
Estado en dev/issues/README.md: pendiente → completado
Sistema de skills operativo y listo para usar.
Documentar sistema de skills en .claude/:
CLAUDE.md:
- Agregar pkg/skills/, shell/skills/, tools/skilltools/ y skills/ a estructura
- skills/ como contenido declarativo (SKILL.md + recursos)
.claude/rules/create_skill.md:
- Guia completa para crear nuevas skills
- Template de SKILL.md con frontmatter
- Proceso paso a paso (categoria → estructura → SKILL.md → recursos → tests)
- Reglas criticas: skills != tools, < 500 lineas, idempotencia
- Ejemplos y anti-patrones
.claude/rules/index.md:
- Agregar regla "Crear skill" al indice
- Explicar cuando usar skills vs tools
La regla create_skill.md es la guia oficial para añadir skills.
Agregar 4 skills de ejemplo funcionales y README del sistema:
Skills de ejemplo:
- devops/deploy-service: deploy completo con rollback
- analysis/log-analyzer: analisis de logs con metricas
- communication/daily-report: reportes diarios automaticos
- system/health-check: verificacion de salud multi-servicio
Cada skill incluye:
- SKILL.md con frontmatter YAML + instrucciones markdown
- Descripcion de parametros y proceso paso a paso
- Ejemplos de uso y consideraciones de seguridad
skills/README.md documenta:
- Diferencia entre tools (atomicas) y skills (flujos multi-paso)
- Formato de SKILL.md y carga progresiva (3 niveles)
- Categorias disponibles y uso desde agentes
Las skills son contenido declarativo, no codigo Go.
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.
Agregar tools en tools/skilltools/ para interactuar con skills:
- skill_search: busca skills relevantes por query
- skill_load: carga instrucciones completas de una skill
- skill_read_resource: lee recursos especificos (scripts, references, templates)
- skill_run_script: ejecuta scripts de skills con argumentos
Las tools permiten al LLM descubrir, cargar y ejecutar skills
de forma progresiva (metadata → instrucciones → recursos).
Patron standard: Def (puro) + Exec (impuro).
Agregar SkillsCfg y SkillsToolCfg al config schema:
SkillsCfg (nivel agente):
- enabled: activar/desactivar skills
- path: directorio de skills (default: skills/)
- categories: filtro de categorias a cargar
- timeout: timeout de ejecucion de scripts
SkillsToolCfg (nivel tools):
- allowed_interpreters: allowlist de interpreters (bash, python3, etc.)
Permite configurar skills por agente de forma granular.
Agregar componentes impuros para manejo de skills en shell/skills/:
Loader (filesystem I/O):
- LoadMeta(): carga metadata de todas las skills
- LoadSkill(): carga skill completa con instrucciones
- ReadResource(): lee recursos con path traversal protection
- Parsing de SKILL.md con frontmatter YAML
Executor (script execution):
- Ejecucion segura de scripts con allowlist de interpreters
- Timeout obligatorio por script
- Inferencia de interpreter desde extension
- Proteccion contra scripts maliciosos
Incluye tests completos con tmpdir para loader y executor.
Arquitectura: impure shell, todo I/O aislado en shell/.
Agregar tipos puros en pkg/skills/ para el sistema de skills:
- SkillMeta: metadata de skills (name, description, category)
- Skill: representacion completa con instrucciones y recursos
- SkillMatch: resultado de matching con confidence score
- Match(): funcion pura de matching por keywords
- FilterByCategory(): filtrado de skills por categorias
Incluye tests unitarios completos para matching y filtrado.
Arquitectura: pure core, cero side effects en pkg/.
Sistema completo de shared knowledge que permite colaboración entre agentes:
**Implementado:**
- Config SharedKnowledge en schema.go (enabled, dir, db_path)
- WAL mode en FileStore para concurrencia entre procesos
- Tools compartidas: shared_knowledge_{search,read,write,list}
- Integración en agents/runtime.go con instanciación y registro
- Carpeta knowledges/ con README explicativo
- Documentación en prompts de agentes
- Tests completos con coexistencia privado/compartido
- .gitignore actualizado (knowledges/data/)
- Estructura actualizada en CLAUDE.md
**Arquitectura:**
- Reutiliza FileStore existente con directorio compartido
- WAL mode permite múltiples lectores + single writer
- Tools prefijadas shared_knowledge_* vs knowledge_* (privado)
- Los .md se commitean, la DB se reconstruye con Sync()
Issue: dev/issues/completed/0018-shared-knowledge.md
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Mover dev/issues/0018-shared-knowledge.md a completed/
- Actualizar dev/issues/README.md: estado completado
- Sistema de conocimiento compartido completamente implementado
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Agregar knowledges/data/ a .gitignore (DB no se commitea)
- Agregar knowledges/ a estructura en CLAUDE.md
- Los .md compartidos sí se commitean
- Issue 0018: Shared Knowledge (fase 7)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- 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>
- Carpeta raiz para documentos compartidos entre agentes
- README explica proposito, funcionamiento, diferencia con privado
- Ejemplo de flujo de colaboracion entre agentes
- Issue 0018: Shared Knowledge (fase 4)
🤖 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>
- Ejecutar PRAGMA journal_mode=WAL al abrir la DB
- Permite múltiples lectores + single writer concurrentes
- Mejora el rendimiento del shared knowledge compartido
- Issue 0018: Shared Knowledge (fase 2a)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Nuevo tipo SharedKnowledgeToolCfg con enabled, dir, db_path
- Agregar campo SharedKnowledge a ToolsCfg
- Issue 0018: Shared Knowledge (fase 1)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Integra soporte para conectarse a servidores MCP externos y consumir sus tools. El cliente MCP permite descubrir y ejecutar tools remotas, ampliando las capacidades de los agentes sin modificar el core. Esta implementación mantiene la separación pure/impure y se integra con el sistema de tools existente.
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>
Conecta el sistema centralizado de grupos y permisos al launcher y runtime.
Elimina controles per-agente obsoletos. Activa feature flag. Docs actualizados.
- Actualiza docs/security.md: nueva sección "Sistema de grupos centralizados"
con estructura de los 3 YAML, acciones disponibles, campos deprecados
- Actualiza .claude/CLAUDE.md: añade security/ en la estructura del proyecto
- Mueve 0024 y 0024c a dev/issues/completed/
- Actualiza dev/issues/README.md: marca 0024, 0024a, 0024b, 0024c como completado
Co-Authored-By: Claude Sonnet 4.6 <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>
Crea los tres archivos YAML de configuración de seguridad centralizada en
security/ (user-groups.yaml, agent-groups.yaml, permissions.yaml) y el
loader impuro shell/security/loader.go que los lee y construye un
security.SecurityPolicy puro.
- security/user-groups.yaml: grupos de usuarios (admins, everyone)
- security/agent-groups.yaml: grupos de agentes (assistants, all)
- security/permissions.yaml: políticas de permisos por grupo de agentes
- shell/security/loader.go: Load(dir) → SecurityPolicy; usa structs YAML
intermedios para mantener pkg/security/ libre de gopkg.in/yaml.v3
- shell/security/loader_test.go: 6 tests cubren los casos del issue
(dir inexistente, vacío, 3 YAMLs, solo uno, malformado, wildcards)
El código se mergea con feature flag centralized-security-groups = false
(loader creado, todavía no wired al launcher — eso es 0024c).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Crea el paquete puro pkg/security/ con los tipos base del sistema
centralizado de permisos y la función ResolveACL.
Cambios:
- pkg/acl/config.go: añade FromRoles([]Role) ACL como constructor directo
- pkg/security/groups.go: UserGroup, AgentGroup
- pkg/security/policy.go: Permission, AgentPolicy, SecurityPolicy
- pkg/security/resolver.go: ResolveACL(agentID, SecurityPolicy) → acl.ACL
* soporte wildcard de agente ("*") y de usuario ("*")
* políticas acumulativas: unión de permisos entre grupos
* referencia directa por agentID sin definir grupo
- pkg/security/security_test.go: 7 tests cubriendo todos los casos del issue
El paquete es pure core: cero I/O, cero side effects.
Mergeado con feature flag centralized-security-groups = false (no wired).
Registra el flag 'centralized-security-groups' desactivado. Protege el
código del issue 0024 (sistema centralizado de grupos de usuarios y
agentes) hasta que todas las sub-issues estén completas.
Simplifica el flujo de fix-issue para crear la rama directamente con
git checkout -b en lugar de invocar /git-branch, que añadía una capa
de indirección innecesaria. Añade lógica para detectar si ya estamos
en la rama correcta y continuar sin recrearla.
egutierrez