# 0027 — Limpiar config schema: eliminar codigo muerto

## Objetivo

Eliminar las secciones del config schema (`internal/config/schema.go`) que no estan implementadas ni referenciadas en el codebase. Reducir de 560 lineas / 61 structs a solo lo que realmente se usa.

## Contexto

- `internal/config/schema.go` tiene 560 lineas y 61 tipos struct
- Secciones **nunca referenciadas** en ningun archivo `.go`:
  - `ObservabilityCfg` (metrics, tracing, health) — 0 usos
  - `ResilienceCfg` (circuit breaker, retry, queue) — 0 usos
  - `AgentsCfg` (peers, delegation, protocol) — 0 usos
  - `PersonalityCfg.Communication` (18 campos: humor, quirks, catchphrases) — 0 usos
- El template `_template/config.yaml` tiene 414 lineas cuando un agente real necesita ~40
- Esto complica el onboarding y crea confusion sobre que es funcional vs especulativo

## Arquitectura

```
internal/config/schema.go     → eliminar structs muertos (~180 lineas)
agents/_template/config.yaml  → reducir a lo esencial (~60 lineas)
```

### Patron pure core / impure shell

- `pkg/` — sin cambios
- `shell/` — sin cambios
- `agents/` — template simplificado
- `internal/config/` — poda de tipos

## Tareas

### Fase 1: Auditar uso real

- [ ] **1.1** Grep cada struct/campo del schema contra todo el codebase para confirmar cuales tienen 0 referencias
- [ ] **1.2** Documentar en este issue la lista final de tipos a eliminar

### Fase 2: Podar schema.go

- [ ] **2.1** Eliminar `ObservabilityCfg` y todos sus sub-structs (LoggingCfg, MetricsCfg, HealthCfg, TracingCfg)
- [ ] **2.2** Eliminar `ResilienceCfg` y sub-structs (CircuitBreakerCfg, RetryCfg, ShutdownCfg, QueueCfg)
- [ ] **2.3** Eliminar `AgentsCfg` y sub-structs (PeerCfg, DelegationCfg)
- [ ] **2.4** Eliminar campos no usados de `PersonalityCfg` (Communication, Humor, Quirks, etc.)
- [ ] **2.5** Verificar que los campos eliminados no rompen el parsing YAML (yaml.v3 ignora campos extra por defecto)

### Fase 3: Simplificar template

- [ ] **3.1** Reescribir `agents/_template/config.yaml` con solo los campos funcionales (~60 lineas)
- [ ] **3.2** Añadir comentarios explicativos en el template para cada seccion

### Fase 4: Tests

- [ ] **4.1** Verificar que los configs existentes (`assistant-bot`, `asistente-2`, `meteorologo`) siguen parseando correctamente
- [ ] **4.2** `go build -tags goolm ./...` compila
- [ ] **4.3** `go test -tags goolm ./...` pasa

### Fase 5: Cleanup

- [ ] **5.1** Actualizar `CLAUDE.md` si se mencionan secciones eliminadas
- [ ] **5.2** Si algun config YAML existente usa campos eliminados, limpiar esas lineas

---

## Ejemplo de uso

Antes (template 414 lineas):
```yaml
personality:
  tone: friendly
  communication:
    formality: informal      # nunca se usa
    humor: light             # nunca se usa
    quirks: ["dice 'vale'"]  # nunca se usa
observability:               # nunca se usa
  logging: ...
  metrics: ...
resilience:                  # nunca se usa
  circuit_breaker: ...
```

Despues (template ~60 lineas):
```yaml
agent:
  id: mi-agente
  description: "Descripcion"
personality:
  tone: friendly
  language: es
llm:
  primary:
    provider: openai
    model: gpt-4o
matrix:
  threads:
    enabled: true
```

## Decisiones de diseno

- **Eliminar, no comentar**: codigo muerto se borra, no se comenta con "// TODO: implement"
- **Si se necesita en el futuro, se re-añade**: Git tiene historial. No mantener especulacion.
- **yaml.v3 es tolerante**: campos extra en YAML no causan error, asi que eliminar structs no rompe configs existentes que tengan esos campos

## Prerequisitos

- Ninguno

## Riesgos

- **Falso negativo en grep**: algun campo podria usarse via reflection o string matching. Mitigacion: buscar tambien por nombre de campo en strings
- **Configs de usuarios existentes**: si alguien tiene un config con `observability:`, no rompera (yaml.v3 ignora), pero el campo sera silenciosamente ignorado. Esto ya era el caso.