@jmanuelcorral/openteam 0.18.1 → 0.20.0

package/README.es.md

@@ -2,7 +2,7 @@
 
 > 🌐 **Language / Idioma:** [English](README.md) · **Español** (este documento)
 
-**openteam — plugin de opencode con routing coste-consciente local-first, fallback FRONTIER cheapest-capable y orquestación multiagente a demanda.**
+**openteam — ejecución de modelos local, frontier y mixed controlada por el operador para opencode, con selección automática cheapest-capable y orquestación multiagente a demanda.**
 
 > 📖 **Sitio de documentación:** <https://jmanuelcorral.github.io/openteam/es/> (también en [English](https://jmanuelcorral.github.io/openteam/))
 
@@ -13,6 +13,7 @@
 - [Requisitos](#requisitos)
 - [Instalación](#instalación)
 - [Quickstart: `openteam setup`](#quickstart-openteam-setup)
+- [El agente `openteam`](#el-agente-openteam)
 - [Probar en otra máquina](#probar-en-otra-máquina)
 - [Actualizar openteam](#actualizar-openteam)
 - [Configuración](#configuración)
@@ -28,21 +29,29 @@
 
 ## Qué es y por qué existe
 
-openteam añade a opencode una capa de routing y orquestación para ahorrar tokens y coste frontier sin perder calidad ni privacidad. La estrategia por defecto es **local-first**: tareas triviales, resúmenes, documentación sencilla y diffs pequeños intentan usar runtimes locales; tareas de arquitectura, seguridad, refactors multiarchivo, tool calling crítico o debugging ambiguo escalan a **FRONTIER cheapest-capable**.
+openteam añade a opencode una capa de routing y orquestación. El operador elige
+un dominio global **local**, **frontier** o **mixed**; las políticas del
+coordinador y de los workers pueden fijar un modelo exacto o usar selección
+`"auto"` cheapest-capable dentro de ese dominio.
 
-El router mantiene una garantía de privacidad: con `privacyMode: "forceLocalOnSensitive"`, una tarea marcada como `privacySensitive` no escala a frontier.
+openteam **no** inspecciona el contenido del prompt para inferir sensibilidad
+antes de una llamada frontier. Para prohibir frontier, usa `local` globalmente o
+estrecha un agente a `local` bajo el modo global `mixed`.
 
 ## Características
 
 - Routing por turno desde el hook `chat.message`, mutando `output.message.model` antes de que opencode persista el mensaje.
 - Registro de runtimes locales OpenAI-compatible: Ollama, LM Studio, Lemonade Server y Foundry Local.
-- Clasificador local JSON con fallback heurístico determinista.
 - Perfiles de capacidad desde Models.dev, con cache y fallback curado cuando el catálogo no está disponible.
-- Selección frontier **cheapest-capable** por coste blended `0.75 * inputUSD + 0.25 * outputUSD`.
+- Selección automática **cheapest-capable** por coste, disponibilidad, soporte de tools y contexto dentro del dominio permitido.
 - Presupuestos por sesión, mes y tokens frontier por sesión.
 - Telemetría `CostRecord` JSONL hash-only: guarda `promptHash`, métricas de coste y decisión, nunca prompts crudos.
-- Orquestación multiagente con `runRoleTask` / `runRoleTasks`, subsesiones SDK y modelo explícito en `client.session.prompt({ body: { model } })`.
+- Pines exactos o `"auto"` por agente, fallbacks ordenados opcionales y relevo acotado de modelo para nodos incompletos.
+- Orquestación multiagente con subsesiones SDK y modelo explícito en `client.session.prompt({ body: { model } })`.
 - Refresh de disponibilidad local al arrancar y en eventos `session.created` / `session.idle`.
+- Una [línea de tiempo de agentes](docs/es/guide/agent-timeline.md) solo de
+  metadatos, con historial duradero del coordinador y los intentos, cursor
+  histórico y avisos de actualización en vivo.
 
 ## Requisitos
 
@@ -78,99 +87,16 @@ Para la carga directa desde opencode, basta con referenciar el paquete:
   "$schema": "https://opencode.ai/config.json",
   "model": "anthropic/claude-sonnet-4-5",
   "small_model": "ollama/qwen3:8b",
-  "plugin": [
-    [
-      "@jmanuelcorral/openteam",
-      {
-        "baseline": {
-          "mode": "auto",
-          "pinnedModel": null,
-          "hardDefault": {
-            "providerID": "anthropic",
-            "modelID": "claude-sonnet-4-5"
-          }
-        },
-        "router": {
-          "mode": "balanced",
-          "localDefault": {
-            "providerID": "ollama",
-            "modelID": "qwen3:8b"
-          },
-          "trivialPromptMaxChars": 280,
-          "frontierPromptMinChars": 2000
-        },
-        "local": {
-          "runtimes": [
-            {
-              "id": "ollama",
-              "enabled": true,
-              "baseURL": "http://localhost:11434/v1",
-              "defaultModel": {
-                "providerID": "ollama",
-                "modelID": "qwen3:8b"
-              }
-            },
-            {
-              "id": "lmstudio",
-              "enabled": true,
-              "baseURL": "http://localhost:1234/v1",
-              "defaultModel": {
-                "providerID": "lmstudio",
-                "modelID": "qwen2.5-coder-local"
-              }
-            }
-          ]
-        },
-        "budgets": {
-          "sessionUSD": 2,
-          "monthlyUSD": 30,
-          "frontierTokensPerSession": 250000,
-          "hardStopOnBudgetExhaustion": false
-        },
-        "privacyMode": "forceLocalOnSensitive",
-        "telemetry": {
-          "enabled": true,
-          "path": ".opencode/openteam-local/telemetry.jsonl"
-        }
-      }
-    ]
-  ],
-  "provider": {
-    "ollama": {
-      "npm": "@ai-sdk/openai-compatible",
-      "name": "Ollama (local)",
-      "options": {
-        "baseURL": "http://localhost:11434/v1",
-        "apiKey": "ollama",
-        "chunkTimeout": 60000
-      },
-      "models": {
-        "qwen3:8b": {
-          "name": "Qwen3 8B (Ollama)",
-          "tool_call": true,
-          "limit": { "context": 32768, "output": 8192 }
-        }
-      }
-    },
-    "lmstudio": {
-      "npm": "@ai-sdk/openai-compatible",
-      "name": "LM Studio (local)",
-      "options": {
-        "baseURL": "http://localhost:1234/v1",
-        "apiKey": "lm-studio"
-      },
-      "models": {
-        "qwen2.5-coder-local": {
-          "name": "Qwen2.5 Coder Local",
-          "tool_call": true,
-          "limit": { "context": 32768, "output": 8192 }
-        }
-      }
-    }
-  }
+  "plugin": ["@jmanuelcorral/openteam"]
 }
 ```
 
+Esos modelos deben existir en tus providers configurados en opencode;
+sustitúyelos por equivalentes disponibles cuando sea necesario.
+
+Mantén la política del operador en `.opencode/openteam.json`, no dentro de la
+declaración del plugin. `openteam setup` crea ambos archivos.
+
 ### Opción B: ruta de desarrollo
 
 Durante desarrollo puedes cargar un plugin local desde `.opencode/plugins/openteam.ts`:
@@ -178,33 +104,29 @@ Durante desarrollo puedes cargar un plugin local desde `.opencode/plugins/opente
 ```jsonc
 {
   "$schema": "https://opencode.ai/config.json",
-  "plugin": [
-    [
-      "./.opencode/plugins/openteam.ts",
-      {
-        "router": {
-          "mode": "balanced",
-          "localDefault": {
-            "providerID": "ollama",
-            "modelID": "qwen3:8b"
-          }
-        },
-        "telemetry": {
-          "path": ".opencode/openteam-local/telemetry.jsonl"
-        }
-      }
-    ]
-  ]
+  "plugin": ["./.opencode/plugins/openteam.ts"]
 }
 ```
 
-## Quickstart: `openteam setup`
+La carga por ruta de desarrollo no cambia el límite de configuración: conserva
+la política del operador en `.opencode/openteam.json`.
 
-La forma más rápida de dejar un repositorio listo para opencode + openteam es el comando interactivo `openteam setup`. Detecta los runtimes locales instalados (Ollama, LM Studio, Lemonade Server, Foundry Local) —que son **opcionales**: puedes usar openteam **solo con frontier**, o apuntar a un Ollama/LM Studio/Lemonade Server que corra en **otra máquina de la red local**—, te deja elegir los modelos locales y el modelo **frontier baseline** (ordenados de más barato-capaz a más caro), y genera tres ficheros:
+## Quickstart: `openteam setup`
 
-- `opencode.json` en la raíz: declara el plugin `@jmanuelcorral/openteam`, los `provider` locales OpenAI-compatible, el `model` frontier y el `small_model` local.
-- `.opencode/openteam.json`: la configuración runtime validada de openteam (baseline, routing, runtimes locales, roles del orquestador y privacidad).
+La forma más rápida de dejar un repositorio listo es `openteam setup`. Detecta
+Ollama, LM Studio, Lemonade Server y Foundry Local —todos opcionales—, permite
+elegir modelos locales y el **frontier baseline** (cheapest-capable primero), y
+genera la configuración y los artefactos de agentes/comandos:
+
+- `.opencode/opencode.json` en proyectos nuevos, o el
+  `.opencode/opencode.json` / `opencode.json` raíz ya existente: declara el
+  plugin, los providers locales, el `model` frontier y el `small_model` local.
+- `.opencode/openteam.json`: la configuración runtime validada de openteam
+  (dominio, runtimes locales, políticas de modelo del primary/roles, presupuestos
+  y reintentos/relevos acotados).
 - `.opencode/agent/openteam.md`: el **agente primario `openteam`**, visible en el Tab-switcher.
+- `.opencode/agent/<rol>.md` para los destinos estándar, además de entradas
+  `.opencode/command/*.md` y el `.opencode/.gitignore` local.
 
 ```powershell
 # Ejecución puntual, sin instalación global
@@ -217,25 +139,60 @@ openteam setup
 
 El asistente:
 
-1. Sondea los runtimes locales y marca los detectados.
-2. Te deja habilitar runtimes (o **ninguno**: puedes usar openteam **solo con modelos frontier**) y, por cada runtime que habilites, elegir si corre **en esta máquina** o **en otra máquina de la red local** (introduciendo su URL, p. ej. `http://192.168.1.50:11434/v1`); luego eliges el modelo por defecto de cada uno (o lo escribes si no se detectan modelos). Si tienes **más de una máquina del mismo tipo** (p. ej. dos hosts LM Studio), declara cada una como una instancia aparte con su propio id (`lmstudio-a`, `lmstudio-b`), URL y modelos. Para cada instancia también pregunta cuántos **slots de generación concurrente** tiene el runtime (por defecto `4`), para que puedas dejar un slot libre para el trabajo interactivo en vez de saturar el servidor.
-3. Ofrece el modelo frontier baseline a partir del **catálogo completo de [Models.dev](https://models.dev)** que openteam ya integra: una lista rápida con los más **baratos-capaces primero** (incluidos los **gratuitos**, etiquetados como `gratis`), una opción **«Ver todos los modelos por proveedor…»** para navegar el catálogo completo, y **«Otro (custom)»** para escribir un `provider/model`. Si el catálogo no se puede cargar (offline), cae a la lista curada.
-4. Pregunta el modo de routing (`balanced`/`economy`/`quality`), la política de privacidad y si quieres activar el **modo YOLO** (auto-aprobar permisos de opencode). Si no habilitas ningún runtime local, avisa de que estás en **modo solo frontier** y recomienda `consentBeforeFrontier` (porque `forceLocalOnSensitive` no tendría destino local).
-5. Si ya existe `opencode.json` o `.opencode/openteam.json`, pide confirmación antes de sobrescribir.
-
-Tras `setup`, autentica el provider frontier (`opencode auth login`), asegúrate de que tu runtime local (en esta máquina o en la red) esté accesible si lo habilitaste, y abre opencode en el repositorio: openteam enruta local-first automáticamente. Puedes reajustar el baseline después con `openteam baseline set <provider/model>` o `openteam baseline auto`.
+1. Sondea runtimes locales y primero pregunta cuáles habilitar. Elegir
+   **Ninguno** selecciona global `frontier` directamente, sin una pregunta
+   redundante sobre los tres modos, y continúa con la selección frontier.
+2. Para cada runtime habilitado, configura esta máquina u otro host LAN,
+   modelos default/thinking/coder y concurrencia. Varias instancias conservan
+   identidades distintas de runtime y provider.
+3. Si hay algún runtime local, elige el modo del equipo (default `mixed`).
+   `local` fija el primario al modelo thinking o default del primer runtime;
+   `frontier` pide un modelo frontier; `mixed` pregunta si el primario usa ese
+   modelo local o el frontier elegido. Las opciones frontier usan el orden
+   cheapest-capable de Models.dev, exploración/custom y fallback curado offline.
+4. Setup escribe una política primaria exacta con `fallbacks: []`, persiste
+   cada worker como política parcial compacta `{ "model": "auto" }` y escribe
+   límites `2`/`2`. El schema/config manual permiten primary `"auto"` y
+   fallbacks primarios, pero setup no los pregunta.
+5. Elige si activar **YOLO**. Los archivos existentes requieren confirmación
+   antes de sobrescribir.
+
+Tras `setup`, autentica un provider frontier si las políticas lo permiten,
+comprueba cada runtime local configurado y abre opencode. Reajusta el baseline
+con `openteam baseline set <provider/model>` o `openteam baseline auto`.
+
+> **Nota de upgrade:** `privacyMode` es metadata obsoleta e ignorada y ya no impide ejecución
+> frontier. Convierte cualquier restricción necesaria a
+> `router.executionMode: "local"` o a un `executionMode: "local"` por agente
+> bajo el modo global `mixed`.
 
 ## El agente `openteam`
 
-`openteam setup` genera un único **agente primario** llamado `openteam` (`.opencode/agent/openteam.md`). Pulsa **Tab** en opencode para seleccionarlo: así sabes explícitamente que estás en modo openteam, mientras el plugin sigue optimizando el modelo por debajo.
+`openteam setup` genera un único **agente primario** llamado `openteam`
+(`.opencode/agent/openteam.md`). Pulsa **Tab** en opencode para seleccionarlo:
+así sabes explícitamente que estás en modo openteam. Su modelo sigue las
+políticas global y del primario; el prompt no elige dominio por ser juzgado
+sensible o complejo.
 
-Ese orquestador **no trae subagentes precreados**. En **cada petición** su primera acción es comprobar si ya existe equipo (`.opencode/openteam/roster.md` + subagentes en `.opencode/agent/`). Si **existe**, reparte el trabajo entre los especialistas adecuados; si **no existe**, entiende las tareas que implica tu petición, diseña el equipo mínimo y **lo crea a demanda** —sin que tengas que pedírselo explícitamente— antes de pasarle esas tareas (escribiendo `.opencode/agent/<nombre>.md` con `mode: subagent`), reutilizando los existentes antes de crear nuevos. Los roles mecánicos/bulk se dejan enrutar a modelos locales y solo se escala a frontier para arquitectura, seguridad o debugging ambiguo. (Este modelo de equipo temático creado a demanda está inspirado en [Squad](https://bradygaster.github.io/squad/); ver [Agradecimientos](#agradecimientos-e-inspiración).)
+El frontmatter primario generado y `opencode.json.model` usan el mismo modelo
+bootstrap exacto. Los workers generados omiten `model` en frontmatter: manda su
+política en `.opencode/openteam.json`. Guardian, scribe y ralph no están
+forzados a local por nombre.
+
+Ese orquestador no trae subagentes específicos del proyecto precreados. En cada
+petición comprueba el roster, reutiliza especialistas existentes y crea el equipo
+mínimo a demanda cuando haga falta. La ubicación de modelos viene de las
+políticas globales y por agente, no de clasificar sensibilidad. El router
+unificado puede seguir derivando requisitos de capacidad y complejidad dentro
+del dominio permitido.
 
 El equipo tiene **identidad temática**: el orquestador elige (o te pregunta) un **universo** y nombra a cada agente con un personaje de ese universo, registrando el reparto en `.opencode/openteam/roster.md` (fuera de `.opencode/agent/`, para que opencode no lo cargue como un agente fantasma) para que los nombres **persistan** entre sesiones. Además de los roles específicos del proyecto, contempla tres **roles estándar** creados a demanda:
 
-- **scribe** — memoria silenciosa: registra decisiones y aprendizajes en `.opencode/openteam/decisions.md` sin tocar el código (modelo local).
+- **scribe** — memoria silenciosa: registra decisiones y aprendizajes en `.opencode/openteam/decisions.md` sin tocar el código.
 - **ralph** — automatización y triage: monitoriza el trabajo pendiente, lo prioriza, coordina la ejecución y **escala al humano** ante bloqueos o aprobaciones.
-- **guardian** — seguridad y privacidad: **detecta y enmascara datos sensibles** (PII, secretos, API keys, tokens) antes de que salgan a frontier y hace revisión de seguridad; corre siempre en local y respeta `forceLocalOnSensitive`.
+- **guardian** — revisión de seguridad y consejo sobre política. No es un gate
+  automático previo a frontier y no tiene requisito local integrado. Configura
+  `executionMode: "local"` si debe quedarse local.
 
 Antes de delegar, el orquestador **planifica dependencias y paraleliza**: descompone la petición en tareas, y como opencode ejecuta en paralelo todas las llamadas `task` emitidas en un mismo turno (Vercel AI SDK), lanza a la vez las tareas independientes y secuencia por olas solo las que dependen de un resultado previo. El trabajo que colisiona sobre los mismos ficheros se separa en olas distintas para evitar conflictos.
 
@@ -273,7 +230,9 @@ Para instalar y probar openteam en otro equipo que ya tenga [opencode](https://o
 
 4. **Arranca tu runtime local** si lo habilitaste y no estaba activo (p. ej. `ollama serve`, o abre LM Studio / Foundry Local). Si apuntaste a un runtime en **otra máquina de la red**, asegúrate de que sea accesible desde este equipo (host expuesto y puerto abierto); para Ollama esto normalmente implica arrancarlo con `OLLAMA_HOST=0.0.0.0 ollama serve` en la máquina remota. Si configuraste **solo frontier**, sáltate este paso.
 
-5. **Abre opencode en el repo**, pulsa **Tab** y elige el agente `openteam`. Dale el primer prompt: creará el equipo de subagentes a demanda y enrutará local-first automáticamente.
+5. **Abre opencode en el repo**, pulsa **Tab** y elige el agente `openteam`.
+   Dale el primer prompt: creará el equipo a demanda y ejecutará cada agente
+   dentro del dominio configurado.
 
 Comprueba el estado con `openteam doctor` (runtimes + config) y el ahorro con `openteam report`.
 
@@ -303,11 +262,19 @@ Notas al actualizar:
 
 ## Configuración
 
-La configuración runtime canónica vive en `.opencode/openteam.json`; este repositorio incluye `.opencode/openteam.example.json` como ejemplo completo. La forma validada por Zod es la de `src/config/schema.ts`. `telemetry` es una opción del plugin leída por `src/index.ts`, no parte del objeto `OpenTeamConfig` persistido.
+La configuración runtime canónica vive en `.opencode/openteam.json`; este
+repositorio incluye `.opencode/openteam.example.json` como ejemplo v2 mínimo y
+completo, no como contrato byte-for-byte para todas las decisiones de setup.
+La serialización canónica v2 es compacta: omite los valores default de las
+heurísticas legacy, conserva overrides no-default para compatibilidad sin
+política y compacta perfiles resueltos a políticas parciales respecto de su
+baseline integrado o sintetizado. La forma validada por Zod es la de
+`src/config/schema.ts`. `telemetry` es una opción del plugin leída por
+`src/index.ts`, no parte del objeto `OpenTeamConfig` persistido.
 
 Los archivos de configuración son estrictos: las claves desconocidas fallan
 cerrado tanto en la CLI como en el plugin en vez de ignorarse en silencio. Los
-errores nombran cada ruta rechazada (por ejemplo `router.trivialPromptMxChars`)
+errores nombran cada ruta rechazada (por ejemplo `router.executionMod`)
 e incluyen una sugerencia de la clave más cercana cuando existe.
 Esta validación estricta se aplica al archivo de configuración en ambas rutas;
 las opciones programáticas del plugin son una superficie separada y aún no se
@@ -358,13 +325,15 @@ ejecutas desde un subdirectorio verás "provider not configured" y debes hacer
 
 | Key | Tipo | Default | Descripción |
 | --- | --- | --- | --- |
+| `configVersion` | `2`, input opcional | canónico `2` | Si falta, se trata como v1 y se migra. Un valor no entero o menor que `1` es desconocido; mayor que `2` no está soportado. |
 | `baseline.mode` | `"auto" \| "pinned"` | `"auto"` | En `auto`, usa perfiles frontier cheapest-capable cuando se pasan al router; en `pinned`, usa `baseline.pinnedModel` si existe. |
 | `baseline.pinnedModel` | `ModelRef \| null` | `null` | Modelo frontier fijado explícitamente. `ModelRef` usa `{ "providerID": string, "modelID": string }`. |
-| `baseline.hardDefault` | `ModelRef` | `{ "providerID": "anthropic", "modelID": "claude-sonnet-4-5" }` | Fallback frontier si no hay perfiles cheapest-capable o pin válido. |
-| `router.mode` | `"economy" \| "balanced" \| "quality"` | `"balanced"` | Modo de routing validado y reservado para política. |
+| `baseline.hardDefault` | `ModelRef` | `{ "providerID": "google", "modelID": "gemini-3.5-flash" }` | Fallback offline/de lista curada configurable cuando ningún perfil live o de catálogo utilizable guía la selección automática. No prevalece sobre los perfiles suministrados; `setup` puede escribir el frontier elegido y siguen permitidos los pins explícitos por agente. |
+| `router.executionMode` | `"local" \| "frontier" \| "mixed"`, opcional | efectivo `"mixed"` | Límite duro global. La serialización canónica escribe `"mixed"` si falta. La política de agente puede estrechar `mixed`, nunca ampliar `local` o `frontier`. |
+| `router.mode` | `"economy" \| "balanced" \| "quality"` | `"balanced"` | Ajuste canónico de heurística legacy para callers sin política de agente v2. No selecciona modelos por agente ni sobreescribe `executionMode` ni añade routing por sensibilidad. |
+| `router.trivialPromptMaxChars` | entero positivo | `280` | Umbral legacy de routing mixed sin política. Se conserva para callers compatibles sin política de agente v2; las políticas v2 generadas no dependen de él. |
+| `router.frontierPromptMinChars` | entero positivo | `2000` | Umbral legacy de routing mixed sin política. Se conserva para callers compatibles sin política de agente v2; las políticas v2 generadas no dependen de él. |
 | `router.localDefault` | `ModelRef \| null` | `null` | Modelo local principal. No configurado por defecto — ningún modelo local se enruta hasta que configures uno con `openteam setup` o manualmente. |
-| `router.trivialPromptMaxChars` | `number` entero positivo | `280` | Prompts sin código hasta este tamaño prefieren local. |
-| `router.frontierPromptMinChars` | `number` entero positivo | `2000` | Prompts desde este tamaño se tratan como candidatos a frontier si no aplican guards. |
 | `local.runtimes` | `LocalRuntime[]` | `[]` | Runtimes locales a sondear. Vacío por defecto — ningún runtime está configurado hasta que ejecutes `openteam setup` o añadas una entrada manualmente. |
 | `local.runtimes[].id` | `string` | requerido | Identidad de instancia, única dentro del array. Libre (`lmstudio-a`, `lemonade-lan`) para que dos máquinas del mismo tipo sean distintas; si se omite `kind`, debe ser en sí mismo un tipo de runtime (retrocompatibilidad). |
 | `local.runtimes[].kind` | `"ollama" \| "lmstudio" \| "foundry-local" \| "lemonade"` opcional | migra desde `id` | Tipo de runtime que selecciona el adaptador. Opcional: si falta, se usa `id` como tipo, así toda config previa sigue funcionando sin cambios. |
@@ -377,57 +346,121 @@ ejecutas desde un subdirectorio verás "provider not configured" y debes hacer
 | `budgets.sessionUSD` | `number` positivo opcional | sin límite | Presupuesto frontier por sesión. |
 | `budgets.monthlyUSD` | `number` positivo opcional | sin límite | Presupuesto frontier mensual. |
 | `budgets.frontierTokensPerSession` | `number` entero positivo opcional | sin límite | Límite de tokens frontier por sesión. |
-| `budgets.hardStopOnBudgetExhaustion` | `boolean` | `false` | Si es `true`, agotar presupuesto devuelve `blockFrontier`; si es `false`, fuerza local. |
-| `privacyMode` | `"forceLocalOnSensitive" \| "consentBeforeFrontier" \| "off"` | `"forceLocalOnSensitive"` | Política de privacidad para tareas sensibles. |
-| `orchestrator.roles` | `Record<string, AgentRoleProfile>` | `{}` | Perfiles de rol personalizados o sobrescritos, indexados por role ID. Las entradas de config se validan con el mismo schema estricto que los roles integrados y tienen prioridad sobre `TEAM_ROLES`; si una entrada omite `roleID`, se usa la clave del mapa. Los roles desconocidos no declarados aquí siguen usando el fallback neutral y avisan una vez. |
+| `budgets.hardStopOnBudgetExhaustion` | `boolean` | `false` | Controla la acción de presupuesto; nunca permite salir del dominio. |
+| `orchestrator` | objeto opcional | ausente | Contiene políticas de primary/roles y límites de pasadas. |
+| `orchestrator.maxRetries` | entero no negativo opcional | efectivo `2` | Límite superior de pasadas openteam extra por modelo autorizado; `2` efectivo permite hasta tres pasadas. El default se aplica en runtime, no se materializa en el schema. |
+| `orchestrator.maxModelsPerNode` | entero positivo opcional | efectivo `2` | Total de candidatos por nodo: el seleccionado más como máximo un fallback por defecto. El default de runtime no se materializa; combinado con reintentos permite como máximo seis intentos. |
+| `orchestrator.primary` | `ExecutionPolicy` parcial opcional | ausente | Política del coordinador primario; todos sus campos son opcionales. |
+| `orchestrator.roles` | `Record<string, AgentRoleProfile parcial>` raw | `{}` si existe `orchestrator` | Las entradas raw pueden ser parciales. Las cargadas quedan totalmente fusionadas y validadas: primero perfil integrado o, si no existe, sintetizado; después prevalece el override raw. |
 | `orchestrator.roles.<role>.opencodeAgent` | `string` no vacío opcional | role ID | Nombre del agente opencode al que se despacha ese rol. |
-| `orchestrator.roles.<role>.defaultTier` | `"trivial" \| "simple" \| "moderate" \| "hard"` | requerido | Tier base de complejidad antes de aplicar heurística y elevación por permisos. |
-| `orchestrator.roles.<role>.minReasoningTier` | `1`–`5` | requerido | Capacidad mínima de razonamiento para candidatos frontier. |
-| `orchestrator.roles.<role>.minCodeQualityTier` | `1`–`5` | requerido | Capacidad mínima de calidad de código para candidatos frontier. |
-| `orchestrator.roles.<role>.needsToolCallingByDefault` | `boolean` | requerido | Si el rol requiere tool calling salvo que la tarea indique otra cosa. |
-| `orchestrator.roles.<role>.preferredFrontierModels` | `Array<ModelRef \| "auto">` | requerido | Modelos frontier preferidos; usa `[]` para un rol local-first sin preferencia frontier explícita. |
-| `orchestrator.roles.<role>.localFirst` | `boolean` | requerido | Si el rol conserva la postura local-first normal en vez de forzar frontier para tareas hard. |
+| `orchestrator.primary.executionMode` / `orchestrator.roles.<role>.executionMode` | `"local" \| "frontier" \| "mixed"`, opcional | heredado | Puede estrechar global `mixed`; no contradecir global `local`/`frontier`. |
+| `orchestrator.primary.model` / `orchestrator.roles.<role>.model` | `ModelRef \| "auto"`, opcional | omitir equivale a `"auto"` | Selección exacta o automática determinista entre modelos capaces, disponibles y dentro del dominio. `mixed` prioriza local si es capaz y después cheapest-capable cuando existe coste de catálogo. Pins estáticamente no configurados, fuera del dominio o incapaces conocidos fallan; candidatos temporalmente offline se omiten solo en runtime. Un coste ausente no se inventa como cero. |
+| `orchestrator.primary.fallbacks` / `orchestrator.roles.<role>.fallbacks` | `ModelRef[]`, opcional | derivados para auto; ninguno para pin exacto | Una lista explícita sustituye fallbacks derivados y conserva orden tras deduplicar y omitir el seleccionado. Cada entrada recibe validación estática de identidad/dominio/capacidad antes del límite. Un backup temporalmente offline no invalida un primary sano: se omite para probar el siguiente candidato autorizado. |
+| `privacyMode` | legacy/obsoleto | ninguno | Solo metadata compatible ignorada; se elimina al persistir canónicamente. Al cargarla emite una vez el aviso de migración `privacy-mode-ignored` con el riesgo de egress frontier y el remedio `executionMode: "local"`; el aviso nunca cambia el routing. |
 | `telemetry.enabled` | `boolean` plugin option | `true` | Activa/desactiva escritura JSONL. |
 | `telemetry.path` | `string` plugin option | `.opencode/openteam-local/telemetry.jsonl` | Ruta del log `CostRecord` JSONL. |
 
-Ejemplo de auditor de privacidad/seguridad personalizado:
+`router.localOnly` y `router.frontierOnly` siguen como aliases opcionales de
+parseo para cargar archivos antiguos; la migración y las escrituras canónicas
+los sustituyen por `executionMode`. `TaskSignals.privacySensitive?` también
+sigue como campo histórico opcional, pero clasificación, score, rationale y
+routing lo ignoran.
+
+Ejemplo de políticas explícitas para coordinador y workers:
+
+Los modelos exactos de política siempre son objetos como
+`{ "providerID": "anthropic", "modelID": "claude-sonnet-4-5" }`, nunca un
+scalar `"provider/model"`. El comando baseline de slash/CLI y el campo `model`
+propio de opencode sí usan la notación scalar. Cada modelo del ejemplo debe
+existir en los providers configurados por el operador. Un ID de instancia como
+`lmstudio-b` y un provider ID como `lmstudio` son conceptos distintos; usa la
+identidad de provider configurada para opencode.
 
 ```jsonc
 {
+  "configVersion": 2,
+  "router": { "executionMode": "mixed" },
   "orchestrator": {
+    "maxRetries": 2,
+    "maxModelsPerNode": 2,
+    "primary": {
+      "executionMode": "frontier",
+      "model": "auto"
+    },
     "roles": {
-      "galadriel": {
-        "opencodeAgent": "galadriel",
-        "defaultTier": "moderate",
-        "minReasoningTier": 3,
-        "minCodeQualityTier": 3,
-        "needsToolCallingByDefault": true,
-        "preferredFrontierModels": [],
-        "localFirst": true
+      "scribe": {
+        "executionMode": "local",
+        "model": { "providerID": "ollama", "modelID": "qwen3:8b" }
+      },
+      "integration": {
+        "executionMode": "frontier",
+        "model": { "providerID": "anthropic", "modelID": "claude-sonnet-4-5" },
+        "fallbacks": [
+          { "providerID": "google", "modelID": "gemini-3.5-flash" }
+        ]
       }
     }
   }
 }
 ```
 
+El `routeKind` resuelto siempre es `local`, `frontier` o `blocked`, nunca
+`mixed`. Solo pueden ejecutarse el modelo seleccionado y la cadena de fallback
+devuelta. Una decisión bloqueada no despacha; su identidad seleccionada es solo
+un valor de coste/referencia. El estrechamiento por presupuesto no puede
+sustituir un modelo local no aprobado: si no queda ningún candidato autorizado,
+el routing bloquea.
+
 ## Uso
 
-En cada turno, openteam deriva señales del prompt (`promptChars`, `hasCode`, `privacySensitive`, `requiresTools` y override de modelo si existe), ejecuta `chooseModel` y asigna `output.message.model`.
+En cada turno, openteam resuelve las políticas global y por agente, filtra por
+dominio, tools y contexto, ordena los candidatos `"auto"` por coste según los
+requisitos de capacidad/complejidad del router unificado y asigna
+`output.message.model`. La sensibilidad del prompt y los metadatos de privacidad
+de Graph no son entradas de routing.
 
 La orquestación multiagente usa roles estáticos y subsesiones opencode:
 
-| Rol | Agent opencode | Tier base | Política |
-| --- | --- | --- | --- |
-| `rusty` | `architect` | `hard` | Arquitectura y decisiones de alto riesgo; frontier auto. |
-| `livingston` | `integration` | `moderate` | Integración TS/opencode; tool calling por defecto. |
-| `yen` | `local-runtime` | `moderate` | Runtimes locales; local-first con fallback frontier. |
-| `basher` | `routing-cost` | `moderate` | Router, coste y presupuesto; local-first. |
-| `scribe` | `scribe` | `trivial` | Documentación y resúmenes; local-first. |
-| `linus` | `tester` | `simple` | Tests y contratos; local-first con tools. |
+En el trabajo del coordinador, `defaultTier` y los mínimos de capacidad del rol
+son suelos. La clasificación ordinaria de capacidad/complejidad de la tarea
+puede elevar el requisito efectivo para trabajo más difícil, pero no debilitar
+el requisito del rol. El tier efectivo guía routing y telemetría. El vocabulario
+de sensibilidad y la metadata de privacidad de Graph no afectan al routing.
 
-`runRoleTask` ejecuta una subsesión; `runRoleTasks` ejecuta varias con `batchID`. Los roles con `destructive` o `multiFileEdit` elevan el tier antes de elegir modelo.
-
-Para ver ahorro y decisiones, revisa el JSONL de telemetría. Campos clave: `promptHash`, `promptChars`, `tier`, `routeKind`, `selected`, `rationale`, `estimatedCostUSD`, `baselineCostUSD`, `estimatedSavingsUSD`, `budgetAction`, `tokensIn` y `tokensOut`.
+| Rol | Agent opencode | Política típica |
+| --- | --- | --- |
+| `rusty` | `architect` | Configura `"auto"` o un modelo exacto del dominio. |
+| `livingston` | `integration` | Suele necesitar tools; el dominio es explícito. |
+| `yen` | `local-runtime` | Puede estrecharse a `local` bajo `mixed`. |
+| `basher` | `routing-cost` | Auto puede optimizar coste dentro del dominio. |
+| `scribe` | `scribe` | Sin restricción local integrada; configúrala si procede. |
+| `linus` | `tester` | Configura modelos con tools/contexto suficientes. |
+
+`runRoleTask` ejecuta una subsesión; `runRoleTasks` ejecuta varias con
+`batchID`. Los intentos directos y en batch usan la misma ruta lógica estable
+de reporte y deben probar un reporte actual, cambiado cuando proceda,
+sustantivo y duradero antes del éxito. La política de permisos/review está
+separada de la ubicación de modelo.
+
+El dispatch SDK de un hijo usa una autorización de modelo de un solo uso y
+acotada a la instancia del plugin, identificada por la sesión hija, el alias de
+agente y el modelo exactos. Cuando el prompt del SDK público vuelve a entrar por
+`chat.message`, solo esa coincidencia conserva el modelo worker autorizado por
+el coordinador; la autorización se libera al terminar el prompt. Los mensajes
+sin coincidencia y los iniciados por el usuario siguen el routing normal. Este
+mecanismo no amplía dominios ni autoriza modelos fuera de `selected` y
+`fallbackChain`.
+
+Para consultar el modelo realmente usado, las razones del relevo y las
+estimaciones de coste/ahorro cuando estén disponibles, revisa el JSONL de
+telemetría. Los campos clave incluyen `promptHash`, `promptChars`, `routeKind`,
+`selected`, `rationale`, `estimatedCostUSD`, `baselineCostUSD`,
+`estimatedSavingsUSD`, `budgetAction`, `tokensIn` y `tokensOut`. Un coste de
+modelo desconocido permanece `null`/desconocido, no se convierte en gratis; el
+ahorro es desconocido si falta alguna estimación necesaria. En auto del
+coordinador, el requisito efectivo de capacidad —el suelo del rol más cualquier
+elevación por clasificación de la tarea— determina tanto la capacidad de los
+candidatos como el baseline frontier capaz usado para comparar costes.
 
 ## Comandos runtime
 
@@ -440,8 +473,9 @@ El plugin registra la herramienta `openteam`. Pídele al agente que la use, o in
 - `show` — muestra el baseline efectivo.
 - `set` (con `model` en formato `provider/model`) — fija el baseline (modo `pinned`).
 - `auto` — vuelve a cheapest-capable (modo `auto`).
-- `doctor` — diagnóstico de runtimes locales, privacidad y telemetría.
-- `report` — resumen de coste y ahorro desde la telemetría.
+- `doctor` — diagnóstico de dominio, política de modelos, runtimes y telemetría.
+- `report` — estimaciones disponibles de coste y ahorro desde la telemetría;
+  los valores desconocidos siguen siendo desconocidos.
 
 Los cambios de `set`/`auto` se persisten en `.opencode/openteam.json` y aplican en el siguiente arranque del plugin.
 
@@ -468,7 +502,7 @@ El paquete expone el binario `openteam`. Con instalación global:
 ```powershell
 bun add --global @jmanuelcorral/openteam@latest
 openteam baseline show
-openteam baseline set openai/gpt-5-mini
+openteam baseline set anthropic/claude-sonnet-4-5
 openteam doctor --config .opencode/openteam.json
 openteam agents
 openteam console
@@ -487,25 +521,10 @@ Flags: `--config <path>` y `--telemetry <path>` sobrescriben las rutas por defec
 
 ### Ver el LLM de cada agente: `openteam agents`
 
-Lista los agentes de `.opencode/agent/` indicando **qué LLM usa cada uno**: si es **local** (Ollama/LM Studio/Lemonade/Foundry, sin coste de tokens) o **frontier** (consume tu suscripción), y el **proveedor** (Anthropic, OpenAI, GitHub Copilot, Google…). Los agentes sin `model` propio **heredan** el default de `opencode.json` (que openteam enruta local-first por mensaje).
-
-```powershell
-openteam agents
-```
-
-```text
-openteam agents — LLM por agente:
-
-  ● openteam  [primary ]  frontier · Anthropic (consume tu suscripción) (anthropic/claude-sonnet-4-5)
-  ○ basher    [subagent]  local · Ollama (sin coste de tokens) (ollama/qwen3:8b)
-  ○ scribe    [subagent]  hereda default → frontier · Anthropic (consume tu suscripción) · openteam enruta local-first por mensaje
-
-Default de opencode.json: anthropic/claude-sonnet-4-5 (frontier · Anthropic)
-Leyenda: ● primary · ○ subagent · local = sin coste de tokens · frontier = consume tu suscripción.
-```
-
-También está disponible **dentro de opencode**: pídele a openteam la lista de agentes y ejecutará la acción `agents` de su herramienta de comandos.
-
+Lista los agentes de `.opencode/agent/` con su modelo y proveedor configurados.
+Los agentes sin `model` propio heredan el default de `opencode.json`. Ese
+default no autoriza salir del dominio resuelto: prevalecen las políticas
+efectivas de `.opencode/openteam.json`.
 
 ### Modo YOLO (auto-aprobar permisos)
 
@@ -521,20 +540,30 @@ También puedes activarlo durante `openteam setup` (te lo pregunta), o al vuelo
 
 > **Importante: el permiso del agente anula al global.** opencode fusiona el permiso del frontmatter de cada agente **después** del global y gana la última regla que casa; por eso `openteam yolo on/off` regenera `.opencode/agent/openteam.md` para que su `permission` coincida con el estado YOLO. Sin esto, un `bash: ask`/`external_directory: deny` en el agente seguiría pidiendo confirmación aunque el global fuese `"*": allow`. Tras cambiar el modo, **reinicia o recarga opencode** para que los agentes tomen los nuevos permisos, y crea los subagentes con el mismo comodín cuando YOLO esté activo (el orquestador ya lo hace).
 
-> **YOLO no desactiva la privacidad de openteam.** Solo afecta a las aprobaciones de permisos de opencode; con `privacyMode: "forceLocalOnSensitive"`, los prompts sensibles siguen sin salir a frontier. Úsalo solo en entornos de confianza: auto-aprueba también `bash`, escrituras y accesos fuera del workspace (salvo reglas `deny` explícitas).
+> **YOLO no cambia el dominio de ejecución.** Solo afecta a las aprobaciones de
+> opencode y no añade un filtro de sensibilidad. En `frontier` o `mixed`, el
+> contenido del prompt puede enviarse a frontier. Úsalo solo en entornos de
+> confianza.
 
 ### Modo de routing: `openteam local`
 
 Usa `openteam local` para alternar entre los tres modos globales de routing sin repetir el setup:
 
 ```powershell
-openteam local status   # ¿local-first, solo local o solo frontier? + runtimes configurados
-openteam local off      # solo frontier (desactiva el routing local-first)
+openteam local status   # ¿mixed, local o frontier? + runtimes configurados
+openteam local off      # frontier
 openteam local only     # solo local (nunca escala a frontier)
-openteam local on       # vuelve al routing local-first
+openteam local on       # mixed
 ```
 
-`local off` persiste `router.frontierOnly=true`: el router escoge el **frontier cheapest-capable**, pero respeta privacidad, presupuestos y overrides explícitos por tarea. Los prompts sensibles con `forceLocalOnSensitive` no salen a frontier; `local off` degrada esa política a `consentBeforeFrontier` (imposible forzar local sin runtime) e informa del cambio. `local only` persiste `router.localOnly=true` y limpia `frontierOnly`; se niega a escribir la config salvo que haya al menos un runtime local habilitado.
+Los comandos persisten `router.executionMode`. `local only` es un límite duro:
+ningún pin o fallback de agente puede llegar a frontier, y el comando se rechaza
+sin runtime local habilitado. `local off` no necesita runtime local. `local on`
+permite ambos dominios y cada agente puede estrechar el suyo. Toda escritura
+valida primero las políticas exactas de primary, roles y fallbacks contra el
+dominio propuesto; un conflicto rechaza el comando y deja la config sin cambios.
+También elimina `localOnly`, `frontierOnly` y `privacyMode` raíz; `local status`
+muestra el modo efectivo y las identidades de runtimes habilitados.
 
 ### Actualizar el plugin y limpiar la caché: `openteam clear-cache`
 
@@ -565,7 +594,47 @@ de actualización paso a paso.
 
 ### Trabajo iterativo bajo `openteam-orchestrate` 🎯
 
-El trabajo desatendido y de tipo backlog se gestiona **enteramente desde la orquestación** — la iteración es una propiedad del grafo, no un comando aparte. Cuando el coordinador despacha un rol, ese nodo del grafo sigue trabajando en pasadas sucesivas hasta que declara `openteam-status: done` en su artefacto de reporte (el **contrato de salida**) o alcanza su tope de reintentos. El tope es configurable vía `orchestrator.maxRetries` en `.opencode/openteam.json`: cuenta reintentos, así que el valor por defecto `2` significa **tres pasadas por nodo** y `0` desactiva la iteración (una sola pasada). Un nodo que nunca declara completitud se vuelve a despachar hasta el tope en lugar de asumirse terminado, y un **gate de durabilidad** verifica en código que cada rol persistió realmente un reporte no vacío — así ninguna pasada descarta trabajo en silencio. La concurrencia por oleada y la cancelación por dependencias no cambian. Consulta **[docs/es/guide/commands.md](docs/es/guide/commands.md)** para el contrato completo.
+El trabajo desatendido se gestiona desde la orquestación. El modelo actual
+recibe `orchestrator.maxRetries` pasadas extra (default efectivo de runtime `2`,
+tres pasadas como máximo por modelo). La incompletitud persistente consume el
+presupuesto de pasadas del modelo antes de entregar el **mismo nodo** al
+siguiente modelo autorizado. Un fallo retry-safe reconocido de
+transporte/capacidad del prompt (`prompt-timeout`, `prompt-rate-limited`,
+`prompt-connection`, `prompt-server` o `prompt-context-length`) se reintenta en
+ese mismo modelo dentro de su presupuesto de pasadas; en create se reconocen
+las mismas clases salvo context length. `maxRetries` es un límite superior, no
+un mínimo obligatorio de repeticiones: tras confirmar la parada, un fallo de
+transporte elegible puede consumir el presupuesto restante del mismo modelo o
+entregar antes el nodo al siguiente candidato autorizado. Auth,
+content-filter, validation/modelo inválido, rechazo genérico, session ID ausente
+y fallos sin clasificar son terminales. Un candidato detectado como no
+disponible antes del dispatch puede omitirse porque no empezó ningún intento.
+`maxModelsPerNode` tiene
+default efectivo de runtime `2`; juntos, ambos defaults limitan el nodo a hasta
+seis pasadas openteam. Ninguno se materializa en el schema. No es una cuenta
+garantizada de pasadas/llamadas HTTP ni una afirmación sobre reintentos internos
+del SDK/provider.
+
+El relevo conserva batch, objetivo, ruta de reporte y estado duradero. Un pin
+exacto sin `fallbacks` no autoriza un segundo modelo. Cada pasada, incluso con
+`maxRetries: 0`, necesita una declaración independiente
+`openteam-status: done` y un reporte duradero con al menos 40 caracteres
+sustantivos tras retirar las líneas de declaración reales. Gana la última
+declaración independiente fuera de bloques de código; los ejemplos citados o
+dentro de fences siguen siendo cuerpo y no declaran completitud. El marcador
+solo no basta. El coordinador lee el texto únicamente para parsear ese estado y
+comprobar sustancia; no copia el cuerpo a resultados de rol, telemetría de
+routing, diagnósticos ni a la proyección solo-referencia.
+
+Tras un dispatch de prompt con timeout o excepción/incertidumbre, la petición
+SDK anterior debe terminar y la parada del servidor debe confirmarse antes de
+cualquier reintento o relevo. Tras un abort correcto, el polling acotado
+confirma la parada si la sesión exacta está `idle` o no aparece en un snapshot
+de estado disperso válido; un payload ausente/malformado o una sesión que sigue
+`busy`/`retry` bloquean la continuación. La evidencia de estado no sustituye la
+terminación de la petición. Agotar la cadena termina en fallo/incompleto y no
+ejecuta dependientes. Consulta
+**[docs/es/guide/commands.md](docs/es/guide/commands.md)**.
 
 ### Console web multi-sesión (se lanza desde la CLI)
 
@@ -576,12 +645,11 @@ de opencode abiertas y todas aparecen en la **misma** Console, con una pestaña
 sesión (más "Todas"), porque cada plugin **escribe eventos redactados** en logs
 JSONL por sesión y la Console los vigila (`fs.watch`) y **agrega**.
 
-Muestra en vivo: **coste y tokens reales por mensaje** (input/output/reasoning/
-cache), **toolcalls con duración** y ok/fallo, ruteo reciente (coste/ahorro y
-modelo elegido, **solo hashes de prompt, nunca el texto**), **decisiones** de los
-agentes (scribe) y **reuniones** (batches multi-agente del orquestador), progreso
-de orquestación e iteración, el equipo de agentes (LLM local/frontier de cada uno) y
-últimos commits. Se actualiza por **SSE** (con *polling* de respaldo).
+Muestra en vivo: **uso de tokens registrado y estimaciones de coste por
+mensaje** (input/output/reasoning/cache), toolcalls con duración, routing
+reciente, decisiones, reuniones, progreso, equipo y commits. Solo muestra hashes
+de prompt, nunca el texto. Los límites y estimaciones son finitos y auditables,
+pero no sustituyen la factura del provider. Se actualiza por **SSE**.
 
 Cada pestaña de sesión incluye además una **vista "Sesión"**: una consola por la
 que puedes **ver la salida en vivo** (SSE) y **enviar prompts** o **responder
@@ -622,7 +690,12 @@ Puedes ajustar host/puerto y la terminal en `.opencode/openteam.json` (bloque
 }
 ```
 
-**Vista del grafo de agentes en vivo.** La Console también puede renderizar un **grafo de agentes** en vivo de una ejecución de Graph; está **activada por defecto en modo shadow** y se puede ocultar con `console.graphView.enabled: false` — consulta [Graph observability web](docs/es/guide/graph-observability-web.md) para la configuración y los requisitos completos.
+**Árbol de agentes y línea de tiempo.**
+`console.graphView.enabled` vale `true` por defecto. El historial nativo del
+ciclo de vida se compone con independencia de la autoridad de ejecución de
+Graph; el DAG separado de Graph sigue el `graph.mode` efectivo. Consulta
+[Línea de tiempo de agentes](docs/es/guide/agent-timeline.md) y
+[Web de observabilidad del grafo](docs/es/guide/graph-observability-web.md).
 
 > **Seguridad**: el servidor escucha **solo en loopback** (`127.0.0.1`/`localhost`, validado por Zod) y **nunca expone prompts** (solo `promptHash`), args de toolcall ni contenido de mensajes: solo contadores, costes y resúmenes redactados. La vista "Sesión"/"Terminal" exige el token efímero. Si el puerto está ocupado y `autoPortFallback` es `true`, prueba el siguiente libre. El acceso remoto mediante `openteam tunnel` se **eliminó del MVP** (2026-08-31) y se redefinirá más adelante; la Console no tiene camino de exposición remota integrado.
 
@@ -635,8 +708,10 @@ stdio, sin dependencias) que expone la memoria del equipo agregada desde los
 eventos por sesión para que agentes/herramientas la consulten. Se apoya en el
 mismo `StorageProvider` que la Console y **nunca** expone prompts crudos, solo el
 estado ya redactado. Tools disponibles: `list_decisions` (filtrable por
-`agent`/`tag`), `list_meetings`, `list_sessions` y `cost_summary` (coste/tokens
-reales + ahorro estimado vs baseline all-frontier).
+`agent`/`tag`), `list_meetings`, `list_sessions` y `cost_summary` (uso
+registrado y estimaciones disponibles de coste/ahorro frente al baseline
+all-frontier; los costes desconocidos siguen siendo desconocidos y no es una
+factura).
 
 Regístralo en `opencode.json` como cualquier MCP server local:
 
@@ -651,6 +726,13 @@ Regístralo en `opencode.json` como cualquier MCP server local:
 }
 ```
 
+La **tool de escritura `openteam-memory`** del plugin está separada de este
+servidor MCP de solo lectura y de la política de modelo del rol scribe general.
+Su transporte de extracción es explícitamente solo-local y exige un runtime
+local configurado y alcanzable. El modo global `frontier` rechaza la llamada al
+modelo de memoria; la tool no añade memoria frontier ni hace fallback
+silencioso a frontier.
+
 #### Recall semántico (opt-in): `recall_facts`, `recall_preferences`, `similar_tasks`
 
 Además de la memoria de equipo, `openteam mcp` puede exponer **recall semántico**
@@ -803,17 +885,24 @@ GitHub Actions.
 
 ## Privacidad
 
-Con `privacyMode: "forceLocalOnSensitive"`, si `TaskSignals.privacySensitive` es `true`, `chooseModel` usa local y no permite fallback frontier. Si no hay local utilizable, la decisión conserva la ruta local y registra la razón en `rationale`.
+openteam **no** detecta sensibilidad ni promete interceptar contenido antes de
+una llamada frontier. `privacyMode` está obsoleto y no tiene autoridad de
+routing. `frontier` y `mixed` permiten egress según la política configurada.
+Para prohibirlo, usa `router.executionMode: "local"` globalmente o estrecha el
+agente a `local` bajo `mixed`.
 
-La telemetría usa `hashPrompt`, actualmente `fnv1a32:<hash>`, y no serializa el prompt completo.
+La redacción de credenciales, la telemetría con hash, el almacenamiento
+solo-referencia, los controles de acceso y los límites finitos de
+presupuesto/modelos/pasadas siguen vigentes. La telemetría usa `hashPrompt`,
+actualmente `fnv1a32:<hash>`, y no serializa el prompt completo.
 
 ## Calidad
 
 Gates no negociables:
 
 - `bun test`
-- Coverage global: líneas `>= 85%`, branches `>= 80%`.
-- Coverage de `src/router/**`: `100%` lines, branches, statements y functions.
+- Coverage global: líneas/funciones `>= 85%`.
+- Coverage de `src/router/**`: `100%` líneas y funciones.
 - `bun run typecheck`
 - `biome check .` o `bun run lint` + `bun run format:check`
 - Test de determinismo del router.
@@ -825,7 +914,7 @@ Consulta [docs/compatibility.md](docs/compatibility.md). Resumen verificado el `
 
 | Superficie | Versión / contrato |
 | --- | --- |
-| openteam | `0.18.1`; versión actual del paquete |
+| openteam | `0.20.0`; versión actual del paquete |
 | `@opencode-ai/plugin` | `1.18.19` |
 | `@opencode-ai/sdk` | `1.18.19` |
 | Hook de routing | `chat.message`; no `chat.params` para cambiar modelo |
@@ -840,11 +929,13 @@ Las contribuciones son bienvenidas. Lee [CONTRIBUTING.md](CONTRIBUTING.md) para
 | Fase | Estado | Entregables |
 | --- | --- | --- |
 | 0. Scaffold/PoC | Hecha | TS/Bun, plugin mínimo, hook `chat.message`. |
-| 1. Local registry + router heurístico | Hecha | Ollama/LM Studio/Lemonade/Foundry, probes y `chooseModel` determinista. |
-| 2. Clasificador + perfiles + presupuesto + telemetría | Hecha | Clasificador local, `ModelCapabilityProfile`, budgets y `CostRecord`. |
+| 1. Local registry + router | Hecha | Ollama/LM Studio/Lemonade/Foundry, probes y `chooseModel` determinista. |
+| 2. Perfiles + presupuesto + telemetría | Hecha | `ModelCapabilityProfile`, budgets y `CostRecord`. |
 | 3. Orquestación multiagente | Hecha | Coordinator, roles, child sessions y permisos. |
 | 4. Empaquetado npm + docs | Hecha | Package exportable, README, ejemplos Windows y matriz de compatibilidad. |
 | 5. Comandos runtime | Hecha | `baseline show/set/auto`, `doctor` y `report` vía tool, `/openteam` y CLI `bin`. |
+| 6. Console web + memoria MCP | Hecha | Console multi-sesión solo-loopback, MCP de solo lectura y recall semántico opt-in. |
+| MVP del agent stack | En curso | Config v2 con dominios, políticas por agente, relevo acotado, retirada del routing por sensibilidad y eliminación de la resolución duplicada de política dentro de Graph. El routing unificado por capacidad/complejidad permanece. La migración LangGraph sigue pendiente por separado. |
 
 ## Licencia