egutierrez
8e089ec07e
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>
105 lines
5.1 KiB
Markdown
105 lines
5.1 KiB
Markdown
# 014 — Agente plantilla + estandarización de config.yaml
|
|
|
|
## Objetivo
|
|
Crear un agente plantilla (no lanzable) que sirva como referencia canónica para la configuración de todos los agentes. Enriquecer `!info` para mostrar metadata completa. Estandarizar los config.yaml existentes.
|
|
|
|
## Contexto
|
|
- El launcher descubre agentes via `agents/*/config.yaml` (glob en cmd/launcher/main.go:55)
|
|
- `!info` existe como built-in en `pkg/command/builtins.go` pero solo muestra: nombre, ID, versión, descripción
|
|
- No hay herencia de configs ni template base — cada config.yaml es autocontenido
|
|
- Agentes actuales: assistant-bot, asistente-2, meteorologo
|
|
|
|
---
|
|
|
|
## Tareas
|
|
|
|
### Fase 1: Agente plantilla
|
|
|
|
- [ ] **1.1** Decidir mecanismo de exclusión del launcher. Opciones:
|
|
- (A) Campo `agent.template: true` en config.yaml → launcher lo ignora
|
|
- (B) Directorio especial fuera de `agents/` (ej: `agents/_template/`)
|
|
- (C) Convención de nombre con prefijo `_` que el glob excluya
|
|
- **Recomendación**: opción (A) es la más explícita y extensible. Añadir campo `Template bool` a `AgentMeta` en schema.go y filtrar en launcher.
|
|
|
|
- [ ] **1.2** Añadir campo `template: true` a `internal/config/schema.go` → `AgentMeta`
|
|
|
|
- [ ] **1.3** Filtrar agentes template en `cmd/launcher/main.go` — skip si `cfg.Agent.Template == true`
|
|
|
|
- [ ] **1.4** Crear `agents/_template/config.yaml` con TODAS las secciones documentadas y valores por defecto comentados. Este archivo es la referencia canónica. Incluir:
|
|
- `agent:` — id, name, description, version, tags, template: true
|
|
- `personality:` — valores estándar (tone, verbosity, language, emoji_style, prefix, templates, behavior)
|
|
- `llm:` — primary con placeholders, tool_use config, fallback
|
|
- `tools:` — todas las subsecciones (memory, knowledge, ssh, http, scripts, file_ops, mcp)
|
|
- `matrix:` — homeserver, user_id, encryption, rooms, filters
|
|
- `agents:` — peers, delegation
|
|
- `security:` — roles, audit
|
|
- `schedules:` — ejemplo de cron
|
|
- `observability:` — logging, metrics, health
|
|
- `resilience:` — circuit breaker, retry, shutdown
|
|
- `storage:` — state, cache, history
|
|
- `memory:` — window config
|
|
|
|
- [ ] **1.5** Crear `agents/_template/agent.go` mínimo con `Rules()` que retorna slice vacío (para que compile, aunque nunca se lance)
|
|
|
|
- [ ] **1.6** Actualizar `dev-scripts/agent/new-agent.sh` para copiar desde `_template/` en lugar de generar inline
|
|
|
|
### Fase 2: Enriquecer `!info`
|
|
|
|
- [ ] **2.1** Modificar el handler de `!info` en `agents/commands.go` para que devuelva:
|
|
- Nombre (`agent.name`)
|
|
- Descripción (`agent.description`)
|
|
- Versión (`agent.version`)
|
|
- Personalidad: tone, verbosity, language, emoji_style
|
|
- LLM: provider + modelo del primary
|
|
- Nº de tools registradas (del toolRegistry)
|
|
- Memoria habilitada (sí/no + window size)
|
|
- Knowledge habilitado (sí/no)
|
|
- Nº de docs en knowledge (si habilitado, contar archivos en knowledge dir)
|
|
- Uptime del agente
|
|
|
|
- [ ] **2.2** Formatear la respuesta como bloque legible (markdown con secciones o tabla)
|
|
|
|
- [ ] **2.3** Asegurar que `!info` no exponga datos sensibles (tokens, API keys, paths internos)
|
|
|
|
### Fase 3: Estandarizar configs existentes
|
|
|
|
- [ ] **3.1** Definir convenciones estándar obligatorias para todo config.yaml:
|
|
- `agent.version` siempre presente (semver)
|
|
- `agent.tags` siempre presente (al menos un tag de categoría)
|
|
- `personality.language` y `personality.languages_supported` siempre explícitos
|
|
- `personality.behavior` siempre con las 6 claves (proactive, ask_confirmation, show_reasoning, thread_replies, typing_indicator, acknowledge_receipt)
|
|
- `llm.tool_use` siempre explícito (enabled true/false, max_iterations)
|
|
- `tools.memory` y `tools.knowledge` siempre presentes (enabled true/false)
|
|
- `matrix.homeserver` y `matrix.encryption` siempre presentes
|
|
- `observability.logging.level` siempre explícito
|
|
|
|
- [ ] **3.2** Actualizar `agents/assistant-bot/config.yaml` según convenciones
|
|
|
|
- [ ] **3.3** Actualizar `agents/asistente-2/config.yaml` según convenciones
|
|
|
|
- [ ] **3.4** Actualizar `agents/meteorologo/config.yaml` según convenciones
|
|
|
|
- [ ] **3.5** Validar que los tres agentes arrancan correctamente tras los cambios
|
|
|
|
### Fase 4: Documentación y tooling
|
|
|
|
- [ ] **4.1** Añadir validación en `internal/config/loader.go` que emita warnings si faltan secciones recomendadas (no bloquear, solo log)
|
|
|
|
- [ ] **4.2** Actualizar `.claude/policies/create_agent.md` para referenciar el template
|
|
|
|
- [ ] **4.3** Actualizar `docs/creating-agents.md` con la nueva referencia del template
|
|
|
|
---
|
|
|
|
## Orden de ejecución recomendado
|
|
1. Fase 1 (template) → base para todo lo demás
|
|
2. Fase 2 (info) → independiente, puede hacerse en paralelo
|
|
3. Fase 3 (estandarizar) → requiere Fase 1 como referencia
|
|
4. Fase 4 (docs) → última, cuando todo esté estable
|
|
|
|
## Decisiones de diseño pendientes
|
|
- ¿El template debería ser un config.yaml real parseable o solo documentación con comentarios?
|
|
→ Recomendación: real parseable con `template: true`, así sirve como test de que el schema está completo
|
|
- ¿Añadir un comando `agentctl validate <config.yaml>` para verificar conformidad?
|
|
→ Nice-to-have, se puede añadir en una fase posterior
|