@iaforged/context-code 1.0.62 → 1.0.65

package/LICENSE.md

@@ -1 +1 @@
-© Anthropic PBC. All rights reserved. Use is subject to the Legal Agreements outlined here: https://code.claude.com/docs/en/legal-and-compliance.
+© Anthropic PBC. All rights reserved. Use is subject to the Legal Agreements outlined here: https://code.claude.com/docs/en/legal-and-compliance.

package/README.md

@@ -27,6 +27,34 @@ context
 
 - [Resumen general](https://code.iaforged.com/docs/en/overview)
 
+## Skills de Context
+
+Context usa `.context/skills` como carpeta oficial de skills del proyecto y `~/.context/skills` como carpeta global de usuario.
+
+Formato:
+
+```text
+.context/skills/<nombre-skill>/SKILL.md
+```
+
+Comandos:
+
+```sh
+/skills
+/skills import
+/skills import .claude
+/skills import .codex
+/skills import .agents
+```
+
+Uso practico:
+
+- `/skills` lista las skills disponibles.
+- `/skills import` busca skills legacy en `.claude/skills`, `.codex/skills` y `.agents/skills`, y las copia a `.context/skills`.
+- `/skills import .claude` importa solo desde `.claude/skills`.
+- Las nuevas skills deben crearse en `.context/skills/<nombre>/SKILL.md`.
+- `CONTEXT_CONFIG_DIR` es la variable principal para cambiar la carpeta global; `CLAUDE_CONFIG_DIR` queda como fallback temporal de compatibilidad.
+
 ## Sistema multi-proveedor y multi-perfil
 
 Context Code ya funciona con una capa de proveedores mas flexible. La idea base es separar:
@@ -128,7 +156,7 @@ La metadata de proveedores y perfiles ahora se apoya en una base SQLite autogene
 
 - archivo: `~/.context/provider-state.sqlite3`
 - se crea sola al arrancar si no existe
-- si hay configuracion legacy previa, intenta migrarla en el primer arranque
+- si hay configuracion legacy previa, puede migrarla con `/profile migrate`
 - en Windows/Linux, las credenciales de proveedores tambien se almacenan en esta misma DB
 - esas credenciales se guardan cifradas localmente antes de persistirse en `secure_storage`
 
@@ -148,10 +176,11 @@ Migracion de credenciales:
 - si la importacion termina bien, el archivo legacy `.credentials.json` se elimina para evitar dos fuentes de verdad
 - en macOS se mantiene el flujo de keychain con fallback, segun el backend disponible
 
-Compatibilidad:
+Estado actual:
 
-- el sistema sigue manteniendo fallback a la configuracion anterior mientras termina la migracion
-- si el runtime no soporta `node:sqlite`, cae temporalmente al flujo legacy para no romper instalaciones
+- Windows/Linux ya trabajan en modo `SQLite-only` para providers, perfiles, modelos, base URLs y credenciales
+- `/status` y `/profile migrate` muestran si el runtime quedo completamente migrado
+- macOS sigue usando keychain/fallback por diseno; esa ruta queda fuera de esta migracion
 
 ### Proveedores actuales
 
@@ -169,9 +198,9 @@ Estos son los proveedores visibles hoy y su estado general:
 
 La migracion esta pensada para no romper la configuracion anterior:
 
-- la configuracion vieja sigue leyendose como fallback
-- los valores anteriores pueden servir de base para crear el perfil por defecto
-- `activeProvider` sigue existiendo como referencia general mientras la migracion termina
+- los valores anteriores pueden servir de base para crear el perfil por defecto durante la migracion inicial
+- `/profile migrate` limpia el remanente legacy cuando la DB ya quedo consistente
+- en Windows/Linux el objetivo final ya es `SQLite-only`
 
 ### Notas de uso
 
@@ -180,6 +209,400 @@ La migracion esta pensada para no romper la configuracion anterior:
 - `Claude`, `OpenAI`, `OpenRouter`, `MiniMax` y `Ollama Cloud` ya resuelven su estado desde la arquitectura nueva con fallback a la configuracion anterior.
 - El comando `/model` sigue existiendo y ahora debe entenderse junto con el perfil activo.
 
+## Equipos con varios proveedores
+
+Esta parte permite usar varios proveedores como si fueran un equipo de trabajo. No necesitas aprender terminos internos: piensa en cuatro niveles simples.
+
+- `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`.
+- `run`: es una ejecucion guardada de un objetivo. Tiene tareas, mensajes, resultados y estado.
+
+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`.
+6. Si quieres seleccion automatica o fallback, usas `/policy`.
+
+### `/workspace`
+
+`/workspace` sirve para revisar que proveedores pueden participar en equipos. Un workspace no es una carpeta del proyecto; aqui significa "este proveedor esta disponible para tener agentes".
+
+Comandos:
+
+```sh
+/workspace
+/workspace list
+/workspace show minimax
+/workspace enable claude
+/workspace disable openrouter
+/workspace setup
+/workspace orchestrator
+/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
+```
+
+Uso practico:
+
+- `/workspace list` muestra los proveedores registrados para equipos.
+- `/workspace show minimax` muestra si MiniMax esta habilitado para equipos.
+- `/workspace enable claude` permite que agentes de Claude participen en equipos.
+- `/workspace disable openrouter` evita que OpenRouter sea usado por la orquestacion.
+- `/workspace setup` abre el wizard interactivo.
+- `/workspace orchestrator` abre un selector para elegir equipo y cambiar su orquestador principal.
+- `/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend` salta el wizard y crea una base de equipo lista para usar.
+
+El wizard de `/workspace setup` tiene opciones para:
+
+- preparar un proveedor/perfil
+- abrir login o configuracion si faltan credenciales
+- llevarte a seleccionar modelo usando `/model`
+- escribir el nombre del equipo
+- escoger el orquestador principal desde perfiles existentes, crear/activar un perfil nuevo, elegir un area o usar un valor personalizado
+- crear el comando base para armar el equipo con autocompletado
+- mostrar workspaces disponibles
+- mostrar ayuda y ejemplo
+
+Cuando ya tienes perfiles listos, el modo rapido hace esto por ti:
+
+1. Habilita cada proveedor como workspace.
+2. Crea un agente por area con nombre `<area>-lead`.
+3. Conecta cada agente al perfil que escribiste.
+4. Crea el equipo si todavia no existe.
+5. Usa `orchestrator=...` como coordinador principal, o el primer agente si no lo indicas.
+6. Crea o actualiza las areas del equipo.
+
+El input tambien ayuda con autocompletado para `/workspace`: subcomandos, proveedores, perfiles guardados y areas comunes como `frontend`, `backend`, `docs`, `tests`, `review`, `database` y `devops`.
+
+Para cambiar el orquestador principal despues de crear el equipo:
+
+```sh
+/workspace orchestrator
+```
+
+Ese wizard primero muestra los equipos guardados y luego los agentes disponibles para asignar uno como coordinador global. Si prefieres hacerlo directo:
+
+```sh
+/workspace orchestrator core-dev openai/backend-lead
+```
+
+Formato rapido:
+
+```text
+/workspace setup <equipo> [orchestrator=<area|proveedor/agente>] <proveedor/perfil:area> [...]
+```
+
+Ejemplo:
+
+```sh
+/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend minimax/main:docs
+```
+
+En ese ejemplo:
+
+- `core-dev` es el equipo.
+- `claude/main:frontend` crea o reutiliza `claude/frontend-lead`.
+- `openai/work:backend` crea o reutiliza `openai/backend-lead`.
+- `minimax/main:docs` crea o reutiliza `minimax/docs-lead`.
+- `orchestrator=backend` pone a `openai/backend-lead` como coordinador principal.
+
+Cuando usarlo:
+
+- si un proveedor no aparece como opcion para agentes
+- si quieres desactivar temporalmente un proveedor
+- si quieres confirmar que el sistema reconoce un proveedor antes de crear agentes
+- si quieres armar un equipo rapido sin recordar `/agent` y `/team`
+
+### `/agent`
+
+`/agent` crea nombres de trabajo dentro de cada proveedor. Un agente siempre apunta a un provider profile real.
+
+Ejemplo: si tienes `claude/main`, puedes crear `claude/frontend-lead`. Ese agente usara las credenciales y modelo del perfil `main`, salvo que le pongas un modelo propio.
+
+Comandos:
+
+```sh
+/agent
+/agent list
+/agent list claude
+/agent create claude frontend-lead main
+/agent show claude frontend-lead
+/agent set-role claude frontend-lead frontend
+/agent set-orchestrator claude frontend-lead true
+/agent set-model claude frontend-lead claude-sonnet-4-6
+```
+
+Uso practico:
+
+- `/agent create claude frontend-lead main` crea un agente llamado `frontend-lead` dentro de Claude usando el perfil `main`.
+- `/agent set-role claude frontend-lead frontend` indica que ese agente se especializa en frontend.
+- `/agent set-orchestrator claude frontend-lead true` permite que ese agente coordine trabajo.
+- `/agent set-model claude frontend-lead <modelo>` fuerza un modelo solo para ese agente.
+
+Formato para referirse a un agente:
+
+```text
+provider/agent
+```
+
+Ejemplos:
+
+```text
+claude/frontend-lead
+openai/backend-lead
+minimax/docs-runner
+ollama/local-coder
+```
+
+### `/team`
+
+`/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`.
+
+Comandos:
+
+```sh
+/team
+/team list
+/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 add-member core-dev frontend claude/ui-reviewer reviewer
+/team show core-dev
+```
+
+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 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.
+
+Ejemplo mental simple:
+
+- Claude puede coordinar frontend.
+- OpenAI puede coordinar backend.
+- MiniMax puede hacer documentacion o tareas rapidas.
+- Ollama puede actuar como ejecutor local.
+- El coordinador principal mira el objetivo completo y recibe reportes de cada area.
+
+## Crear y ejecutar una corrida
+
+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.
+
+### `/orchestrate`
+
+`/orchestrate` toma un team y crea tareas iniciales para cada dominio.
+
+```sh
+/orchestrate core-dev crear endpoint de login y UI de acceso
+```
+
+Que hace:
+
+- revisa que el team exista
+- revisa que tenga coordinador principal
+- revisa que cada dominio tenga agente responsable
+- crea una `orchestration_run`
+- crea tareas en `orchestration_tasks`
+- crea mensajes de planeacion en `orchestration_messages`
+- deja cada tarea como `ready` si puede ejecutarse o `blocked` si falta configuracion
+
+Despues de usar `/orchestrate`, normalmente sigues con:
+
+```sh
+/run list
+/run show <run-id>
+/run resume <run-id>
+```
+
+### `/run`
+
+`/run` sirve para revisar, ejecutar, reintentar, reasignar o cancelar una corrida.
+
+Comandos principales:
+
+```sh
+/run
+/run list
+/run show <run-id>
+/run messages <run-id>
+/run tasks <run-id>
+/run task <task-id>
+/run domain <run-id> <domain>
+/run resume <run-id>
+/run cancel <run-id>
+```
+
+Comandos de recuperacion:
+
+```sh
+/run retry <run-id> [task-id]
+/run cancel-task <task-id>
+/run reassign <task-id> <provider>/<agent>
+```
+
+Que hace cada comando:
+
+- `/run list` muestra las corridas guardadas.
+- `/run show <run-id>` muestra resumen, estado, tareas y ultimos mensajes.
+- `/run tasks <run-id>` muestra todas las tareas de la corrida.
+- `/run task <task-id>` muestra una tarea concreta con sus mensajes y resultados.
+- `/run domain <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 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:
+
+- `planned`: fue creada pero aun no se ejecuto.
+- `in_progress`: esta en ejecucion.
+- `completed`: termino sin tareas abiertas.
+- `failed`: alguna tarea fallo o quedo bloqueada.
+- `cancelled`: fue cancelada por el usuario.
+
+Estados de una tarea:
+
+- `pending`: aun no esta lista.
+- `ready`: puede ejecutarse.
+- `in_progress`: esta ejecutandose.
+- `completed`: termino con resultado.
+- `failed`: fallo al ejecutar.
+- `blocked`: falta configuracion, credenciales, modelo, endpoint o agente valido.
+
+### Ejemplo completo
+
+```sh
+/provider claude profile main
+/login
+/model
+
+/provider openai profile work
+/login
+/model
+
+/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
+/team show core-dev
+
+/orchestrate core-dev crear login con UI y API
+/run list
+/run show <run-id>
+/run resume <run-id>
+/run messages <run-id>
+```
+
+## Seleccion automatica y fallback
+
+La seleccion automatica permite que Context Code recomiende o aplique que agente debe tomar una tarea. El fallback permite cambiar una tarea fallida o bloqueada a otro agente compatible.
+
+### `/policy`
+
+`/policy` muestra politicas predefinidas. Una politica indica como elegir agentes.
+
+```sh
+/policy list
+/policy show score-with-fallback:quality
+```
+
+Modos disponibles:
+
+- `manual`: usa el agente que ya estaba asignado.
+- `score`: elige el mejor agente por puntaje.
+- `score-with-fallback`: elige el mejor agente y guarda candidatos alternos.
+- `fallback-only`: mantiene la asignacion inicial y solo cambia si algo falla.
+
+Objetivos disponibles:
+
+- `balanced`: equilibrio general.
+- `cost`: prioriza costo.
+- `latency`: prioriza velocidad.
+- `quality`: prioriza calidad.
+- `capability`: prioriza especialidad declarada.
+- `resilience`: prioriza estabilidad y opciones de recuperacion.
+
+Formato:
+
+```text
+modo:objetivo
+```
+
+Ejemplos:
+
+```text
+score-with-fallback:quality
+score:capability
+score-with-fallback:resilience
+manual:balanced
+```
+
+### Comandos de Fase 4
+
+```sh
+/run optimize <run-id> [policy]
+/run assign <run-id> [policy]
+/run fallback <run-id> [task-id] [policy]
+/run explain <run-id>
+```
+
+Que hace cada uno:
+
+- `/run optimize <run-id> score-with-fallback:quality` simula la seleccion y muestra candidatos. No cambia tareas.
+- `/run assign <run-id> score:capability` aplica la seleccion y asigna tareas abiertas.
+- `/run fallback <run-id> <task-id> score-with-fallback:resilience` busca otro agente para una tarea fallida o bloqueada.
+- `/run explain <run-id>` muestra las decisiones guardadas como mensajes `policy.*`.
+
+Reglas importantes:
+
+- cada decision automatica queda guardada en SQLite
+- `/run optimize` es seguro porque solo muestra recomendaciones
+- `/run assign` y `/run fallback` si cambian tareas
+- un agente deshabilitado no debe ser elegido
+- si falta perfil, modelo o credenciales, la tarea puede quedar `blocked`
+- errores de autenticacion no deben reintentarse agresivamente
+
+## Datos guardados en SQLite
+
+La base se crea automaticamente en:
+
+```text
+~/.context/provider-state.sqlite3
+```
+
+Ademas de perfiles y credenciales de providers, ahi se guardan:
+
+- `provider_workspaces`: proveedores disponibles para equipos
+- `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
+- `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
+- `secure_storage`: credenciales cifradas y configuracion sensible de providers, Telegram y WhatsApp en Windows/Linux
+
+## Limitaciones actuales
+
+- 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.
+
 ## Puentes con mensajería móvil
 
 Context Code puede conectarse con **Telegram** y **WhatsApp** para que veas y respondas la conversación completa desde tu móvil. Cada mensaje que escribes en la terminal se refleja en el chat, cada respuesta del modelo llega de vuelta, y cada herramienta que ejecuta el asistente (Bash, Read, Edit…) se resume en una línea. También puedes escribir **desde el móvil** y el texto se inyecta al REPL como si lo hubieras tecleado en la terminal — la conversación es la misma, da igual por dónde entres.
@@ -235,11 +658,11 @@ Comandos dentro de la CLI:
 /whatsapp   # abre el wizard (alias: /wa, /whats)
 ```
 
-Las credenciales de WhatsApp se guardan en `~/.context/whatsapp-auth/` (respetando `CLAUDE_CONFIG_DIR` si está definido). La allowlist y el destinatario primario viven en la config global.
+Las credenciales de sesión de WhatsApp Web se guardan como archivos en `~/.context/whatsapp-auth/` (respetando `CLAUDE_CONFIG_DIR` si está definido), porque Baileys necesita manejar ese directorio de auth. La configuracion lógica del bridge, como destinatario primario, allowlist, identidad vinculada y estado `running`, se guarda en SQLite mediante `secure_storage` en Windows/Linux.
 
 ### Configuración guardada
 
-Ambos bridges persisten su estado en el config global (archivo JSON en `~/.context/`):
+Ambos bridges persisten su configuracion en el storage seguro. En Windows/Linux esto vive cifrado dentro de `~/.context/provider-state.sqlite3`; en macOS se mantiene el backend de keychain/fallback disponible.
 
 ```jsonc
 {
@@ -260,6 +683,8 @@ Ambos bridges persisten su estado en el config global (archivo JSON en `~/.conte
 }
 ```
 
+Si existe configuracion vieja en el archivo JSON global, se migra automaticamente al leer o actualizar el bridge y se elimina esa clave legacy para evitar dos fuentes de verdad.
+
 ### Ritmo de envío
 
 Cada canal usa una cola con throttling para no dispararse contra los rate limits de la plataforma:
@@ -269,6 +694,205 @@ Cada canal usa una cola con throttling para no dispararse contra los rate limits
 
 Si escribes prompts muy rápido la cola se llena hasta 200 items, y a partir de ahí descarta el más viejo para no crecer sin límite.
 
+## Ejemplo completo de flujo de trabajo
+
+Este ejemplo muestra un flujo real de principio a fin. Puedes cambiar `claude`, `openai`, `minimax` u `ollama` por los proveedores que tengas configurados.
+
+### 1. Preparar el primer proveedor
+
+Activa el proveedor, inicia sesion y elige modelo.
+
+```sh
+/provider claude profile main
+/login
+/model
+```
+
+Verifica que quedo activo:
+
+```sh
+/status
+```
+
+Debes revisar que aparezcan proveedor, perfil activo, modelo guardado y credenciales configuradas.
+
+### 2. Preparar otro proveedor
+
+Repite el proceso para otro proveedor. En este ejemplo OpenAI sera backend.
+
+```sh
+/provider openai profile work
+/login
+/model
+/status
+```
+
+Si usas Ollama local, normalmente seria:
+
+```sh
+/provider ollama profile local
+/model
+/status
+```
+
+### 3. Crear el equipo con el wizard
+
+Abre el wizard:
+
+```sh
+/workspace setup
+```
+
+Desde ahi puedes elegir:
+
+- `Preparar proveedor/perfil`: seleccionas proveedor, escribes perfil y el sistema lanza `/provider`. Si faltan credenciales, se abre login/configuracion; despues te lleva a `/model`.
+- `Crear equipo y elegir orquestador`: escribes el nombre del equipo, eliges si el orquestador sale de un perfil existente, de un perfil nuevo, de un area o de un agente ya creado, y luego el input queda listo para completar proveedores, perfiles y areas con autocompletado.
+
+Si ya sabes los perfiles y areas, puedes saltarte el wizard y crear el equipo base en un solo comando:
+
+```sh
+/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
+/team show core-dev
+```
+
+En este ejemplo:
+
+- `core-dev` es el equipo.
+- `claude/frontend-lead` coordina el equipo completo.
+- `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.
+
+### 4. Crear una corrida de trabajo
+
+```sh
+/orchestrate core-dev crear login con UI y API
+```
+
+Luego busca el identificador de la corrida:
+
+```sh
+/run list
+```
+
+Usa el `run-id` que aparezca en los siguientes comandos.
+
+### 5. Revisar antes de ejecutar
+
+```sh
+/run show <run-id>
+/run tasks <run-id>
+/run domain <run-id> frontend
+/run domain <run-id> backend
+```
+
+Antes de ejecutar, revisa que las tareas esten en `ready`. Si alguna aparece `blocked`, normalmente falta agente, perfil, modelo o credencial.
+
+### 6. Ejecutar la corrida
+
+```sh
+/run resume <run-id>
+```
+
+Luego revisa resultados:
+
+```sh
+/run show <run-id>
+/run messages <run-id>
+```
+
+Si quieres ver una tarea concreta:
+
+```sh
+/run task <task-id>
+```
+
+### 7. Usar seleccion automatica antes de reasignar
+
+Si quieres ver que agente recomienda el sistema sin cambiar nada:
+
+```sh
+/policy list
+/policy show score-with-fallback:quality
+/run optimize <run-id> score-with-fallback:quality
+```
+
+Si la recomendacion te parece correcta, puedes aplicarla:
+
+```sh
+/run assign <run-id> score:capability
+```
+
+Para ver por que se tomaron decisiones:
+
+```sh
+/run explain <run-id>
+```
+
+### 8. Recuperar errores o bloqueos
+
+Si una tarea fallo o quedo bloqueada, puedes reintentar:
+
+```sh
+/run retry <run-id>
+```
+
+O reintentar solo una tarea:
+
+```sh
+/run retry <run-id> <task-id>
+```
+
+Si quieres cambiarla a otro agente manualmente:
+
+```sh
+/run reassign <task-id> claude/frontend-lead
+/run resume <run-id>
+```
+
+Si quieres que el sistema busque otro agente compatible:
+
+```sh
+/run fallback <run-id> <task-id> score-with-fallback:resilience
+/run resume <run-id>
+```
+
+### 9. Cerrar o cancelar
+
+Si todo termino bien:
+
+```sh
+/run show <run-id>
+```
+
+Si necesitas detener la corrida:
+
+```sh
+/run cancel <run-id>
+```
+
+### Resumen corto
+
+```sh
+/provider claude profile main
+/login
+/model
+
+/provider openai profile work
+/login
+/model
+
+/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
+/team show core-dev
+
+/orchestrate core-dev crear login con UI y API
+/run list
+/run show <run-id>
+/run resume <run-id>
+/run messages <run-id>
+```
+
 ## Reporte de errores
 
 Usa el comando `/bug` dentro de Context Code.