@iaforged/context-code 1.0.77 → 1.0.79

package/README.md

@@ -240,24 +240,24 @@ Esta parte permite usar varios proveedores como si fueran un equipo de trabajo.
 - `workspace`: representa un proveedor dentro del sistema de equipos, por ejemplo `claude`, `openai`, `minimax` u `ollama`.
 - `agent`: es un perfil operativo dentro de un proveedor. Ejemplo: `claude/frontend-lead` o `openai/backend-lead`.
 - `team`: es el equipo completo para un objetivo. Ejemplo: `core-dev`.
-- `domain` (o `dominio`): es un area de trabajo dentro del team. Ejemplos: `frontend`, `backend`, `docs`, `planning`, `tests`, `review`, `database`. Cuando creas un team con `/workspace setup`, el sistema arma 4 dominios por defecto (`frontend`, `backend`, `docs`, `planning`); los que no asignes a un agente quedaran como warnings al ejecutar.
-- `run`: es una ejecucion guardada de un objetivo. Tiene tareas, mensajes, resultados y estado.
+- `equipo interno`: es un grupo de trabajo dentro del team. Ejemplos: `frontend`, `backend`, `docs`, `planning`, `tests`, `review`, `database`. Cuando creas un team con `/workspace setup`, el sistema arma 4 equipos internos por defecto (`frontend`, `backend`, `docs`, `planning`); los que no asignes a un agente quedaran como warnings al ejecutar.
+- `ejecucion` (`run` internamente): es una ejecucion guardada de un objetivo. Tiene tareas, mensajes, resultados y estado. En los comandos veras `<run-id>` porque es el identificador tecnico.
 
 Mini glosario para no confundirse con los roles internos:
 
-- `orquestador global`: el agente que coordina todo el team. Lee el objetivo del usuario, lo descompone, asigna trabajo a cada dominio y consolida los reportes finales para entregartelos a ti.
-- `orquestador local`: por dominio. Recibe la parte del objetivo que le toca, decide como dividirla entre los miembros del dominio (o como hacerla solo en `modo autonomo`) y reporta de vuelta al orquestador global.
-- `lead`: el agente principal de un dominio. En la mayoria de los flujos, el `orquestador local` y el `lead` son el mismo agente.
-- `modo autonomo`: cuando un dominio no tiene miembros extra, el orquestador local asume internamente los roles que necesite (planner, executor, reviewer, etc.) sin necesitar mas agentes configurados.
-- `global-plan` / `squad-plan` / `domain-report` / `run-report`: tipos de mensajes que se guardan en la run. El primero lo emite el orquestador global al planear, el segundo cada orquestador local cuando recibe su tarea, y los reportes son lo que devuelven cuando terminan. Los puedes ver con `/run messages <run-id>`.
+- `orquestador global`: el agente que coordina todo el team. Lee el objetivo del usuario, lo descompone, asigna trabajo a cada equipo interno y consolida los reportes finales para entregartelos a ti.
+- `orquestador local`: por equipo interno. Recibe la parte del objetivo que le toca, decide como dividirla entre los miembros del equipo (o como hacerla solo en `modo autonomo`) y reporta de vuelta al orquestador global.
+- `lead`: el agente principal de un equipo interno. En la mayoria de los flujos, el `orquestador local` y el `lead` son el mismo agente.
+- `modo autonomo`: cuando un equipo interno no tiene miembros extra, el orquestador local asume internamente los roles que necesite (planner, executor, reviewer, etc.) sin necesitar mas agentes configurados.
+- `global-plan` / `squad-plan` / `task.completed` / `run-report`: tipos de mensajes que se guardan en la ejecucion. El primero lo emite el orquestador global al planear, el segundo cada orquestador local cuando recibe su tarea, y los reportes son lo que devuelven cuando terminan. Los puedes ver con `/run messages <run-id>`.
 
 Orden normal de uso:
 
 1. Configuras un proveedor y un perfil con `/provider`, `/login` y `/model`.
 2. Ejecutas `/workspace setup` para crear el equipo base sin hacer todo a mano.
 3. Revisas el equipo con `/team show`.
-4. Generas una corrida con `/orchestrate`.
-5. Ejecutas o revisas la corrida con `/run`.
+4. Generas una ejecucion con `/orchestrate`.
+5. Ejecutas o revisas la ejecucion con `/run`.
 6. Si quieres seleccion automatica o fallback, usas `/policy`.
 
 ### `/workspace`
@@ -350,7 +350,7 @@ Cuando usarlo:
 
 ### `/team-auto` — wizard automatico
 
-Si todavia no sabes que dominio asignar a cada proveedor, `/team-auto` lo decide por ti. Detecta los perfiles ya logueados y arma un team con dominios estandar (`frontend`, `backend`, `docs`, `planning`):
+Si todavia no sabes que equipo asignar a cada proveedor, `/team-auto` lo decide por ti. Detecta los perfiles ya logueados y arma un team con equipos internos estandar (`frontend`, `backend`, `docs`, `planning`):
 
 ```sh
 /team-auto              # crea un team llamado "default-team"
@@ -360,15 +360,15 @@ Si todavia no sabes que dominio asignar a cada proveedor, `/team-auto` lo decide
 Que pasa al ejecutarlo:
 
 1. Detecta los `provider profile` activos (los que ya tienen credencial).
-2. Aplica una heuristica de reparto: Claude -> `frontend`, OpenAI -> `backend`, MiniMax/Z.AI -> `docs`, Ollama/OpenRouter -> `planning`. Si solo tienes 1 proveedor, ese hace TODOS los dominios en `modo autonomo`.
-3. Te muestra el plan en pantalla (que dominios va a crear, que agentes va a reusar, quien sera el orquestador global).
+2. Aplica una heuristica de reparto: Claude -> `frontend`, OpenAI -> `backend`, MiniMax/Z.AI -> `docs`, Ollama/OpenRouter -> `planning`. Si solo tienes 1 proveedor, ese hace TODOS los equipos internos en `modo autonomo`.
+3. Te muestra el plan en pantalla (que equipos va a crear, que agentes va a reusar, quien sera el orquestador global).
 4. Pulsas `Enter` y aplica los cambios, o `Esc` y cancela sin tocar nada.
 
-Cuando un dominio queda sin agente compatible (por ejemplo no tienes ningun proveedor que mapee a `docs`), se reporta `sin asignar` en el plan y queda como warning. Despues puedes asignarlo manualmente con `/team domain <team> docs <provider>/<agent>`.
+Cuando un equipo interno queda sin agente compatible (por ejemplo no tienes ningun proveedor que mapee a `docs`), se reporta `sin asignar` en el plan y queda como warning. Despues puedes asignarlo manualmente con `/team equipo <team> docs <provider>/<agent>`.
 
 Si el team ya existe, `/team-auto` solo lo actualiza: no borra agentes ni miembros que ya tuvieras.
 
-Cuando quieras configurarlo todo a mano, sigue habiendo `/workspace setup` (wizard guiado, mas detallado) o el formato corto `/workspace setup <team> orchestrator=... <provider/profile:dominio>...`.
+Cuando quieras configurarlo todo a mano, sigue habiendo `/workspace setup` (wizard guiado, mas detallado) o el formato corto `/workspace setup <team> orchestrator=... <provider/profile:equipo>...`.
 
 ### `/agent`
 
@@ -415,7 +415,7 @@ ollama/local-coder
 
 `/team` arma un equipo usando agentes. El team tiene un coordinador principal y puede dividir el trabajo por areas.
 
-En esta documentacion llamamos `dominio` a cada area de trabajo. Ejemplos de dominios: `frontend`, `backend`, `docs`, `review`, `tests`, `database`.
+En esta documentacion llamamos `equipo interno` a cada grupo de trabajo. Ejemplos: `frontend`, `backend`, `docs`, `review`, `tests`, `database`.
 
 Comandos:
 
@@ -425,8 +425,8 @@ Comandos:
 /team create core-dev
 /team orchestrator
 /team orchestrator core-dev claude/frontend-lead
-/team domain core-dev frontend claude/frontend-lead
-/team domain core-dev backend openai/backend-lead
+/team equipo core-dev frontend claude/frontend-lead
+/team equipo core-dev backend openai/backend-lead
 /team add-member core-dev frontend claude/ui-reviewer reviewer
 /team show core-dev
 ```
@@ -436,14 +436,14 @@ Uso practico:
 - `/team create core-dev` crea un equipo llamado `core-dev`.
 - `/team orchestrator` abre un selector para escoger equipo y luego orquestador principal.
 - `/team orchestrator core-dev claude/frontend-lead` define quien coordina todo el equipo.
-- `/team domain core-dev frontend claude/frontend-lead` dice que el area frontend la lidera `claude/frontend-lead`.
-- `/team domain core-dev backend openai/backend-lead` dice que backend lo lidera `openai/backend-lead`.
+- `/team equipo core-dev frontend claude/frontend-lead` dice que el area frontend la lidera `claude/frontend-lead`.
+- `/team equipo core-dev backend openai/backend-lead` dice que backend lo lidera `openai/backend-lead`.
 - `/team add-member core-dev frontend claude/ui-reviewer reviewer` agrega un miembro extra al area frontend.
 - `/team show core-dev` muestra como quedo armado el equipo.
 
-Cuando usas `/team domain`, ese agente queda como orquestador local y lead del dominio al mismo tiempo. Eso significa que usa el perfil/modelo vinculado a ese agente para coordinar su propia area. Por ejemplo, `openai/backend-lead` puede ser el equipo autonomo de backend aunque no tenga miembros extra.
+Cuando usas `/team equipo`, ese agente queda como orquestador local y lead del equipo interno al mismo tiempo. Eso significa que usa el perfil/modelo vinculado a ese agente para coordinar su propia area. Por ejemplo, `openai/backend-lead` puede ser el equipo autonomo de backend aunque no tenga miembros extra.
 
-Si un dominio no tiene miembros extra, no esta roto. En ese caso opera en modo autonomo: el orquestador local divide internamente el trabajo segun su funcion principal. Backend puede asumir roles temporales como API, base de datos, validaciones y pruebas; frontend puede asumir UI, componentes, estado y pruebas; docs puede asumir guia tecnica y README. Los miembros extra son opcionales cuando quieres dividir mas el trabajo.
+Si un equipo interno no tiene miembros extra, no esta roto. En ese caso opera en modo autonomo: el orquestador local divide internamente el trabajo segun su funcion principal. Backend puede asumir roles temporales como API, base de datos, validaciones y pruebas; frontend puede asumir UI, componentes, estado y pruebas; docs puede asumir guia tecnica y README. Los miembros extra son opcionales cuando quieres dividir mas el trabajo.
 
 Ejemplo mental simple:
 
@@ -453,9 +453,9 @@ Ejemplo mental simple:
 - Ollama puede actuar como ejecutor local.
 - El coordinador principal mira el objetivo completo y recibe reportes de cada area.
 
-## Crear y ejecutar una corrida
+## Crear y ejecutar una ejecucion
 
-Una `run` es una ejecucion guardada de un objetivo. Por ejemplo: "crear login con UI y API". La run vive en SQLite, por eso puedes cerrar la app y luego volver a revisarla.
+Una ejecucion es un objetivo guardado con sus tareas, mensajes, resultados y estado. Por ejemplo: "crear login con UI y API". Internamente se guarda como `run` en SQLite, por eso puedes cerrar la app y luego volver a revisarla.
 
 ### `/orchestrate`
 
@@ -467,16 +467,16 @@ Una `run` es una ejecucion guardada de un objetivo. Por ejemplo: "crear login co
 
 Que pasa cuando lo ejecutas:
 
-1. El sistema valida el team, el orquestador global y los dominios.
-2. Crea la `run` y todas sus `tasks` en estado `ready` o `blocked` segun la configuracion del dominio.
-3. **Te muestra el plan**: tareas por dominio, agentes asignados, advertencias de configuracion.
+1. El sistema valida el team, el orquestador global y los equipos internos.
+2. Crea la ejecucion y todas sus tareas en estado `ready` o `blocked` segun la configuracion del equipo.
+3. **Te muestra el plan**: tareas por equipo, agentes asignados, advertencias de configuracion.
 4. Te ofrece dos teclas:
-   - **`Enter`**: ejecuta inmediatamente las tareas `ready`. Veras progreso en vivo (dominio que esta trabajando, agente activo, fase) y al final un reporte consolidado.
-   - **`Esc`**: deja la run en `planned`. Puedes revisar con `/run show <run-id>` o ejecutar mas tarde con `/run resume <run-id>`.
+   - **`Enter`**: ejecuta inmediatamente las tareas `ready`. Veras progreso en vivo (equipo que esta trabajando, agente activo, fase) y al final un reporte consolidado.
+   - **`Esc`**: deja la ejecucion en `planned`. Puedes revisar con `/run show <run-id>` o ejecutar mas tarde con `/run resume <run-id>`.
 
-Cuando confirmas con Enter, el flujo interno es: orquestador global delega a cada orquestador local -> cada orquestador local ejecuta o subdelega en `modo autonomo` -> cada uno devuelve un `domain-report` -> el orquestador global consolida y emite el `run-report` final que ves tu.
+Cuando confirmas con Enter, el flujo interno es: orquestador global delega a cada orquestador local -> cada orquestador local ejecuta o subdelega en `modo autonomo` -> cada uno devuelve su reporte de tarea -> el orquestador global consolida y emite el `run-report` final que ves tu.
 
-Si pulsas Esc o no hay tareas `ready` (todo quedo bloqueado), la corrida se queda en estado `planned` y el comando termina mostrando los siguientes pasos sugeridos. En ese caso normalmente sigues con:
+Si pulsas Esc o no hay tareas `ready` (todo quedo bloqueado), la ejecucion se queda en estado `planned` y el comando termina mostrando los siguientes pasos sugeridos. En ese caso normalmente sigues con:
 
 ```sh
 /run show <run-id>     # revisar el plan en detalle
@@ -485,7 +485,7 @@ Si pulsas Esc o no hay tareas `ready` (todo quedo bloqueado), la corrida se qued
 
 ### `/run`
 
-`/run` sirve para revisar, ejecutar, reintentar, reasignar o cancelar una corrida.
+`/run` sirve para revisar, ejecutar, reintentar, reasignar o cancelar una ejecucion.
 
 Comandos principales:
 
@@ -496,7 +496,7 @@ Comandos principales:
 /run messages <run-id>
 /run tasks <run-id>
 /run task <task-id>
-/run domain <run-id> <domain>
+/run equipo <run-id> <equipo>
 /run resume <run-id>
 /run cancel <run-id>
 ```
@@ -511,20 +511,20 @@ Comandos de recuperacion:
 
 Que hace cada comando:
 
-- `/run list` muestra las corridas guardadas.
+- `/run list` muestra las ejecuciones guardadas.
 - `/run show <run-id>` muestra resumen, estado, tareas y ultimos mensajes.
-- `/run tasks <run-id>` muestra todas las tareas de la corrida.
+- `/run tasks <run-id>` muestra todas las tareas de la ejecucion.
 - `/run task <task-id>` muestra una tarea concreta con sus mensajes y resultados.
-- `/run domain <run-id> frontend` muestra solo el area `frontend`.
+- `/run equipo <run-id> frontend` muestra solo el area `frontend`.
 - `/run messages <run-id>` muestra la bitacora completa.
 - `/run resume <run-id>` ejecuta tareas listas.
-- `/run cancel <run-id>` detiene la corrida.
+- `/run cancel <run-id>` detiene la ejecucion.
 - `/run retry <run-id>` reintenta tareas fallidas o bloqueadas.
 - `/run retry <run-id> <task-id>` reintenta una tarea concreta.
 - `/run cancel-task <task-id>` bloquea una tarea para que no continue.
 - `/run reassign <task-id> openai/backend-lead` cambia el agente responsable.
 
-Estados de una corrida:
+Estados de una ejecucion:
 
 - `planned`: fue creada pero aun no se ejecuto.
 - `in_progress`: esta en ejecucion.
@@ -570,8 +570,8 @@ Estados de una tarea:
 
 Notas importantes:
 
-- Si `/workspace setup` solo asigno agente a `frontend` y `backend`, los dominios `docs` y `planning` apareceran como `blocked` con warnings al planear. **No es un error**: las tareas ready se ejecutan igual al pulsar Enter, y las bloqueadas las puedes asignar despues con `/team domain core-dev docs <provider>/<agent>` y reintentar con `/run retry <run-id>`.
-- El reporte final que ves al terminar viene del orquestador global. Si quieres ver lo que cada orquestador local respondio, usa `/run messages <run-id>` o `/run domain <run-id> <dominio>`.
+- Si `/workspace setup` solo asigno agente a `frontend` y `backend`, los equipos `docs` y `planning` apareceran como `blocked` con warnings al planear. **No es un error**: las tareas ready se ejecutan igual al pulsar Enter, y las bloqueadas las puedes asignar despues con `/team equipo core-dev docs <provider>/<agent>` y reintentar con `/run retry <run-id>`.
+- El reporte final que ves al terminar viene del orquestador global. Si quieres ver lo que cada orquestador local respondio, usa `/run messages <run-id>` o `/run equipo <run-id> <equipo>`.
 
 ## Seleccion automatica y fallback
 
@@ -656,14 +656,14 @@ Ademas de perfiles y credenciales de providers, ahi se guardan:
 - `provider_agents`: agentes por proveedor/perfil
 - `provider_agent_capabilities`: capacidades declaradas de agentes
 - `teams`: equipos
-- `team_domains`: areas de trabajo dentro de un equipo
-- `team_domain_members`: miembros de cada area
-- `orchestration_runs`: corridas
+- `team_units`: equipos internos dentro de un team
+- `team_unit_members`: miembros de cada equipo interno
+- `orchestration_runs`: ejecuciones
 - `orchestration_tasks`: tareas
 - `orchestration_messages`: bitacora de decisiones y eventos
 - `orchestration_task_results`: resultados por tarea
-- `orchestration_domain_reports`: reportes por area
-- `orchestration_run_reports`: reporte consolidado de una corrida
+- `orchestration_team_reports`: reportes por equipo interno
+- `orchestration_run_reports`: reporte consolidado de una ejecucion
 - `secure_storage`: credenciales cifradas y configuracion sensible de providers, Telegram y WhatsApp en Windows/Linux
 
 ## Limitaciones actuales
@@ -671,7 +671,7 @@ Ademas de perfiles y credenciales de providers, ahi se guardan:
 - La calidad de la ejecucion depende de que cada agente tenga perfil, modelo y credenciales validas.
 - La seleccion automatica ya existe, pero las politicas personalizadas editables todavia no estan persistidas con `/policy create`.
 - El fallback es auditable y controlado, no un sistema de retries infinitos.
-- Si varios proveedores producen respuestas incompatibles, el usuario debe revisar el consolidado antes de cerrar la corrida.
+- Si varios proveedores producen respuestas incompatibles, el usuario debe revisar el consolidado antes de cerrar la ejecucion.
 
 ## Puentes con mensajería móvil
 
@@ -832,23 +832,23 @@ En este ejemplo:
 - `frontend` queda asignado a Claude.
 - `backend` queda asignado a OpenAI.
 
-Si quieres hacerlo a mano, todavia puedes usar `/workspace enable`, `/agent create`, `/agent set-role`, `/team create`, `/team orchestrator` y `/team domain`. El wizard solo junta esos pasos para evitar errores.
+Si quieres hacerlo a mano, todavia puedes usar `/workspace enable`, `/agent create`, `/agent set-role`, `/team create`, `/team orchestrator` y `/team equipo`. El wizard solo junta esos pasos para evitar errores.
 
-### 4. Crear una corrida y revisar el plan en pantalla
+### 4. Crear una ejecucion y revisar el plan en pantalla
 
 ```sh
 /orchestrate core-dev crear login con UI y API
 ```
 
-A diferencia de versiones anteriores, **`/orchestrate` no se queda en silencio**: te muestra una vista resumen con la run creada, las tareas por dominio, advertencias y un prompt:
+A diferencia de versiones anteriores, **`/orchestrate` no se queda en silencio**: te muestra una vista resumen con la ejecucion creada, las tareas por equipo, advertencias y un prompt:
 
 ```text
 Plan listo para core-dev
-Run: 1b4fb901-...
+Ejecucion: 1b4fb901-...
 Objetivo: crear login con UI y API
 Orquestador global: openai/backend-lead
 
-Tareas por dominio
+Tareas por equipo
 - backend  -> ready   | assigned=openai/backend-lead
 - docs     -> blocked | assigned=sin asignar
 - frontend -> ready   | assigned=claude/frontend-lead
@@ -857,22 +857,22 @@ Tareas por dominio
 Listas: 2 | Bloqueadas: 2
 
 Advertencias
-- docs: warning -> No hay agente asignable para este dominio.
-- planning: warning -> No hay agente asignable para este dominio.
+- docs: warning -> No hay agente asignable para este equipo.
+- planning: warning -> No hay agente asignable para este equipo.
 
 [Enter] Ejecutar ahora (las bloqueadas se omiten)  |  [Esc] Solo planificar
 ```
 
 ### 5. Decidir: ejecutar ya, o revisar y ejecutar despues
 
-- **Pulsa `Enter`** y empezara la ejecucion al instante. Solo se disparan las tareas `ready`. Mientras corren, veras lineas de progreso por dominio. Al final llega el reporte consolidado.
-- **Pulsa `Esc`** si prefieres revisar antes. La run queda en `planned`. Despues puedes inspeccionarla con:
+- **Pulsa `Enter`** y empezara la ejecucion al instante. Solo se disparan las tareas `ready`. Mientras corren, veras lineas de progreso por equipo. Al final llega el reporte consolidado.
+- **Pulsa `Esc`** si prefieres revisar antes. La ejecucion queda en `planned`. Despues puedes inspeccionarla con:
 
 ```sh
 /run show <run-id>
 /run tasks <run-id>
-/run domain <run-id> frontend
-/run domain <run-id> backend
+/run equipo <run-id> frontend
+/run equipo <run-id> backend
 ```
 
 Si una tarea aparece `blocked`, normalmente falta agente, workspace, perfil, modelo o credencial. Asigna lo que falte y vuelve.
@@ -954,7 +954,7 @@ Si todo termino bien:
 /run show <run-id>
 ```
 
-Si necesitas detener la corrida:
+Si necesitas detener la ejecucion:
 
 ```sh
 /run cancel <run-id>
@@ -977,7 +977,7 @@ Si necesitas detener la corrida:
 /orchestrate core-dev crear login con UI y API
 # Aqui ves el plan en pantalla.
 # [Enter] ejecuta ya y muestra el reporte final.
-# [Esc]   te deja la run en 'planned'; ejecuta despues con /run resume <run-id>.
+# [Esc]   te deja la ejecucion en 'planned'; ejecuta despues con /run resume <run-id>.
 
 /run messages <run-id>   # bitacora completa cuando quieras revisarla
 ```
@@ -988,21 +988,21 @@ Sintomas comunes despues de `/orchestrate` o `/run resume`, y como salir de cada
 
 ### "El plan se quedo en `planned` y no pasa nada"
 
-Pulsaste `Esc` (o cerraste la vista) en lugar de `Enter`. La run existe pero no se ejecuto. Reanuda cuando quieras:
+Pulsaste `Esc` (o cerraste la vista) en lugar de `Enter`. La ejecucion existe pero no se ejecuto. Reanuda cuando quieras:
 
 ```sh
 /run resume <run-id>
 ```
 
-### "Aparecen dominios `blocked` que yo no pedi"
+### "Aparecen equipos `blocked` que yo no pedi"
 
-Cuando creas un team con `/workspace setup` y solo das agente a algunos dominios (por ejemplo `frontend` y `backend`), los demas (`docs`, `planning`, etc.) se crean igual y quedan sin asignar. Al planear se reportan como `blocked` con el warning `No hay agente asignable para este dominio.`. Tienes dos salidas:
+Cuando creas un team con `/workspace setup` y solo das agente a algunos equipos (por ejemplo `frontend` y `backend`), los demas (`docs`, `planning`, etc.) se crean igual y quedan sin asignar. Al planear se reportan como `blocked` con el warning `No hay agente asignable para este equipo.`. Tienes dos salidas:
 
-- **Ignorarlos**: pulsas Enter, las tareas `ready` se ejecutan y las `blocked` se quedan asi. La run se reporta como `failed` o `completed` segun lo que avance.
+- **Ignorarlos**: pulsas Enter, las tareas `ready` se ejecutan y las `blocked` se quedan asi. La ejecucion se reporta como `failed` o `completed` segun lo que avance.
 - **Asignar agente y reintentar**:
   ```sh
-  /team domain <team> docs <provider>/<agent>
-  /team domain <team> planning <provider>/<agent>
+  /team equipo <team> docs <provider>/<agent>
+  /team equipo <team> planning <provider>/<agent>
   /run retry <run-id>
   ```
 
@@ -1032,7 +1032,7 @@ Verifica el estado del perfil:
 
 Si falta token, modelo o base URL, vuelve a `/login` y `/model` para ese perfil. La tarea queda `blocked` hasta que el agente tenga todo lo que necesita.
 
-### "Quiero detener una corrida en marcha"
+### "Quiero detener una ejecucion en marcha"
 
 ```sh
 /run cancel <run-id>
@@ -1042,11 +1042,11 @@ Si falta token, modelo o base URL, vuelve a `/login` y `/model` para ese perfil.
 
 ```sh
 /run messages <run-id>
-/run domain <run-id> <dominio>
+/run equipo <run-id> <equipo>
 /run task <task-id>
 ```
 
-`/run messages` te lista en orden cronologico todos los `global-plan`, `squad-plan`, `domain-report`, `run-report` y eventos de policy de la corrida.
+`/run messages` te lista en orden cronologico todos los `global-plan`, `squad-plan`, `task.completed`, `run-report` y eventos de policy de la ejecucion.
 
 ## Servidores MCP externos
 
@@ -1094,7 +1094,7 @@ Pasos a tener en cuenta:
 - Los servidores MCP corren con tus permisos. Si conectas a una DB de produccion, considera dar al servidor solo credenciales de lectura.
 - Variables sensibles: usa `-e VAR=valor` al registrar el server stdio para inyectar tokens sin que queden en el comando visible.
 - Las herramientas MCP aparecen en los agentes con prefijo `mcp__<name>__<tool>`. Puedes restringir cuales se autorizan con `--allowedTools` al iniciar la sesion.
-- Si un dominio (`database`, por ejemplo) tendria que usar este MCP, asignale un agente con `/team domain <team> database <provider>/<agent>` y el orquestador local lo invocara cuando el plan lo requiera.
+- Si un equipo (`database`, por ejemplo) tendria que usar este MCP, asignale un agente con `/team equipo <team> database <provider>/<agent>` y el orquestador local lo invocara cuando el plan lo requiera.
 
 ### Diferencia con el storage interno