@iaforged/context-code 1.0.84 → 1.0.86
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +8 -1118
- package/docs/BRIDGES.md +90 -0
- package/docs/Contex.md +70 -0
- package/docs/LIMITS.md +37 -0
- package/docs/MCP_SERVERS.md +51 -0
- package/docs/MULTI_PROVIDER.md +201 -0
- package/docs/MULTI_SQUAD_ORCHESTRATION_PLAN.md +639 -0
- package/docs/PHASE_1_WORKSPACES_AGENTS_TEAMS.md +161 -0
- package/docs/PHASE_2_SQLITE_ORCHESTRATION.md +127 -0
- package/docs/PHASE_3_DOMAIN_EXECUTION.md +215 -0
- package/docs/PHASE_3_VALIDATION.md +136 -0
- package/docs/PHASE_4_RISKS_AND_TESTS.md +182 -0
- package/docs/RECOVERY_NOTES.md +78 -0
- package/docs/RENAMING_NOTES.md +25 -0
- package/docs/SKILLS.md +27 -0
- package/docs/TEAMS_AND_ORCHESTRATION.md +626 -0
- package/docs/TROUBLESHOOTING.md +72 -0
- package/docs/comandos.md +121 -0
- package/docs/index.md +37 -0
- package/package.json +2 -1
|
@@ -0,0 +1,626 @@
|
|
|
1
|
+
## Equipos con varios proveedores
|
|
2
|
+
|
|
3
|
+
Esta parte permite usar varios proveedores como si fueran un equipo de trabajo. No necesitas aprender terminos internos: piensa en cuatro niveles simples.
|
|
4
|
+
|
|
5
|
+
- `workspace`: representa un proveedor dentro del sistema de equipos, por ejemplo `claude`, `openai`, `minimax` u `ollama`.
|
|
6
|
+
- `agent`: es un perfil operativo dentro de un proveedor. Ejemplo: `claude/frontend-lead` o `openai/backend-lead`.
|
|
7
|
+
- `team`: es el equipo completo para un objetivo. Ejemplo: `core-dev`.
|
|
8
|
+
- `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.
|
|
9
|
+
- `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.
|
|
10
|
+
|
|
11
|
+
Mini glosario para no confundirse con los roles internos:
|
|
12
|
+
|
|
13
|
+
- `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.
|
|
14
|
+
- `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.
|
|
15
|
+
- `lead`: el agente principal de un equipo interno. En la mayoria de los flujos, el `orquestador local` y el `lead` son el mismo agente.
|
|
16
|
+
- `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.
|
|
17
|
+
- `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>`.
|
|
18
|
+
|
|
19
|
+
Orden normal de uso:
|
|
20
|
+
|
|
21
|
+
1. Configuras un proveedor y un perfil con `/provider`, `/login` y `/model`.
|
|
22
|
+
2. Ejecutas `/workspace setup` para crear el equipo base sin hacer todo a mano.
|
|
23
|
+
3. Revisas el equipo con `/team show`.
|
|
24
|
+
4. Generas una ejecucion con `/orchestrate`.
|
|
25
|
+
5. Ejecutas o revisas la ejecucion con `/run`.
|
|
26
|
+
6. Si quieres seleccion automatica o fallback, usas `/policy`.
|
|
27
|
+
|
|
28
|
+
### `/workspace`
|
|
29
|
+
|
|
30
|
+
`/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".
|
|
31
|
+
|
|
32
|
+
Comandos:
|
|
33
|
+
|
|
34
|
+
```sh
|
|
35
|
+
/workspace
|
|
36
|
+
/workspace list
|
|
37
|
+
/workspace show minimax
|
|
38
|
+
/workspace enable claude
|
|
39
|
+
/workspace disable openrouter
|
|
40
|
+
/workspace setup
|
|
41
|
+
/workspace orchestrator
|
|
42
|
+
/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
Uso practico:
|
|
46
|
+
|
|
47
|
+
- `/workspace list` muestra los proveedores registrados para equipos.
|
|
48
|
+
- `/workspace show minimax` muestra si MiniMax esta habilitado para equipos.
|
|
49
|
+
- `/workspace enable claude` permite que agentes de Claude participen en equipos.
|
|
50
|
+
- `/workspace disable openrouter` evita que OpenRouter sea usado por la orquestacion.
|
|
51
|
+
- `/workspace setup` abre el wizard interactivo.
|
|
52
|
+
- `/workspace orchestrator` abre un selector para elegir equipo y cambiar su orquestador principal.
|
|
53
|
+
- `/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend` salta el wizard y crea una base de equipo lista para usar.
|
|
54
|
+
|
|
55
|
+
El wizard de `/workspace setup` tiene opciones para:
|
|
56
|
+
|
|
57
|
+
- preparar un proveedor/perfil
|
|
58
|
+
- abrir login o configuracion si faltan credenciales
|
|
59
|
+
- llevarte a seleccionar modelo usando `/model`
|
|
60
|
+
- escribir el nombre del equipo
|
|
61
|
+
- escoger el orquestador principal desde perfiles existentes, crear/activar un perfil nuevo, elegir un area o usar un valor personalizado
|
|
62
|
+
- crear el comando base para armar el equipo con autocompletado
|
|
63
|
+
- mostrar workspaces disponibles
|
|
64
|
+
- mostrar ayuda y ejemplo
|
|
65
|
+
|
|
66
|
+
Cuando ya tienes perfiles listos, el modo rapido hace esto por ti:
|
|
67
|
+
|
|
68
|
+
1. Habilita cada proveedor como workspace.
|
|
69
|
+
2. Crea un agente por area con nombre `<area>-lead`.
|
|
70
|
+
3. Conecta cada agente al perfil que escribiste.
|
|
71
|
+
4. Crea el equipo si todavia no existe.
|
|
72
|
+
5. Usa `orchestrator=...` como coordinador principal, o el primer agente si no lo indicas.
|
|
73
|
+
6. Crea o actualiza las areas del equipo.
|
|
74
|
+
|
|
75
|
+
El input tambien ayuda con autocompletado para `/workspace`: subcomandos, proveedores, perfiles guardados y areas comunes como `frontend`, `backend`, `docs`, `tests`, `review`, `database` y `devops`.
|
|
76
|
+
|
|
77
|
+
Para cambiar el orquestador principal despues de crear el equipo:
|
|
78
|
+
|
|
79
|
+
```sh
|
|
80
|
+
/workspace orchestrator
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
Ese wizard primero muestra los equipos guardados y luego los agentes disponibles para asignar uno como coordinador global. Si prefieres hacerlo directo:
|
|
84
|
+
|
|
85
|
+
```sh
|
|
86
|
+
/workspace orchestrator core-dev openai/backend-lead
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
Formato rapido:
|
|
90
|
+
|
|
91
|
+
```text
|
|
92
|
+
/workspace setup <equipo> [orchestrator=<area|proveedor/agente>] <proveedor/perfil:area> [...]
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
Ejemplo:
|
|
96
|
+
|
|
97
|
+
```sh
|
|
98
|
+
/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend minimax/main:docs
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
En ese ejemplo:
|
|
102
|
+
|
|
103
|
+
- `core-dev` es el equipo.
|
|
104
|
+
- `claude/main:frontend` crea o reutiliza `claude/frontend-lead`.
|
|
105
|
+
- `openai/work:backend` crea o reutiliza `openai/backend-lead`.
|
|
106
|
+
- `minimax/main:docs` crea o reutiliza `minimax/docs-lead`.
|
|
107
|
+
- `orchestrator=backend` pone a `openai/backend-lead` como coordinador principal.
|
|
108
|
+
|
|
109
|
+
Cuando usarlo:
|
|
110
|
+
|
|
111
|
+
- si un proveedor no aparece como opcion para agentes
|
|
112
|
+
- si quieres desactivar temporalmente un proveedor
|
|
113
|
+
- si quieres confirmar que el sistema reconoce un proveedor antes de crear agentes
|
|
114
|
+
- si quieres armar un equipo rapido sin recordar `/agent` y `/team`
|
|
115
|
+
|
|
116
|
+
### `/team-auto` — wizard automatico
|
|
117
|
+
|
|
118
|
+
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`):
|
|
119
|
+
|
|
120
|
+
```sh
|
|
121
|
+
/team-auto # crea un team llamado "default-team"
|
|
122
|
+
/team-auto core-dev # crea (o actualiza) un team llamado "core-dev"
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
Que pasa al ejecutarlo:
|
|
126
|
+
|
|
127
|
+
1. Detecta los `provider profile` activos (los que ya tienen credencial).
|
|
128
|
+
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`.
|
|
129
|
+
3. Te muestra el plan en pantalla (que equipos va a crear, que agentes va a reusar, quien sera el orquestador global).
|
|
130
|
+
4. Pulsas `Enter` y aplica los cambios, o `Esc` y cancela sin tocar nada.
|
|
131
|
+
|
|
132
|
+
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>`.
|
|
133
|
+
|
|
134
|
+
Si el team ya existe, `/team-auto` solo lo actualiza: no borra agentes ni miembros que ya tuvieras.
|
|
135
|
+
|
|
136
|
+
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>...`.
|
|
137
|
+
|
|
138
|
+
### `/agent`
|
|
139
|
+
|
|
140
|
+
`/agent` crea nombres de trabajo dentro de cada proveedor. Un agente siempre apunta a un provider profile real.
|
|
141
|
+
|
|
142
|
+
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.
|
|
143
|
+
|
|
144
|
+
Comandos:
|
|
145
|
+
|
|
146
|
+
```sh
|
|
147
|
+
/agent
|
|
148
|
+
/agent list
|
|
149
|
+
/agent list claude
|
|
150
|
+
/agent create claude frontend-lead main
|
|
151
|
+
/agent show claude frontend-lead
|
|
152
|
+
/agent set-role claude frontend-lead frontend
|
|
153
|
+
/agent set-orchestrator claude frontend-lead true
|
|
154
|
+
/agent set-model claude frontend-lead claude-sonnet-4-6
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
Uso practico:
|
|
158
|
+
|
|
159
|
+
- `/agent create claude frontend-lead main` crea un agente llamado `frontend-lead` dentro de Claude usando el perfil `main`.
|
|
160
|
+
- `/agent set-role claude frontend-lead frontend` indica que ese agente se especializa en frontend.
|
|
161
|
+
- `/agent set-orchestrator claude frontend-lead true` permite que ese agente coordine trabajo.
|
|
162
|
+
- `/agent set-model claude frontend-lead <modelo>` fuerza un modelo solo para ese agente.
|
|
163
|
+
|
|
164
|
+
Formato para referirse a un agente:
|
|
165
|
+
|
|
166
|
+
```text
|
|
167
|
+
provider/agent
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
Ejemplos:
|
|
171
|
+
|
|
172
|
+
```text
|
|
173
|
+
claude/frontend-lead
|
|
174
|
+
openai/backend-lead
|
|
175
|
+
minimax/docs-runner
|
|
176
|
+
ollama/local-coder
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
### `/team`
|
|
180
|
+
|
|
181
|
+
`/team` arma un equipo usando agentes. El team tiene un coordinador principal y puede dividir el trabajo por areas.
|
|
182
|
+
|
|
183
|
+
En esta documentacion llamamos `equipo interno` a cada grupo de trabajo. Ejemplos: `frontend`, `backend`, `docs`, `review`, `tests`, `database`.
|
|
184
|
+
|
|
185
|
+
Comandos:
|
|
186
|
+
|
|
187
|
+
```sh
|
|
188
|
+
/team
|
|
189
|
+
/team list
|
|
190
|
+
/team create core-dev
|
|
191
|
+
/team orchestrator
|
|
192
|
+
/team orchestrator core-dev claude/frontend-lead
|
|
193
|
+
/team equipo core-dev frontend claude/frontend-lead
|
|
194
|
+
/team equipo core-dev backend openai/backend-lead
|
|
195
|
+
/team add-member core-dev frontend claude/ui-reviewer reviewer
|
|
196
|
+
/team show core-dev
|
|
197
|
+
```
|
|
198
|
+
|
|
199
|
+
Uso practico:
|
|
200
|
+
|
|
201
|
+
- `/team create core-dev` crea un equipo llamado `core-dev`.
|
|
202
|
+
- `/team orchestrator` abre un selector para escoger equipo y luego orquestador principal.
|
|
203
|
+
- `/team orchestrator core-dev claude/frontend-lead` define quien coordina todo el equipo.
|
|
204
|
+
- `/team equipo core-dev frontend claude/frontend-lead` dice que el area frontend la lidera `claude/frontend-lead`.
|
|
205
|
+
- `/team equipo core-dev backend openai/backend-lead` dice que backend lo lidera `openai/backend-lead`.
|
|
206
|
+
- `/team add-member core-dev frontend claude/ui-reviewer reviewer` agrega un miembro extra al area frontend.
|
|
207
|
+
- `/team show core-dev` muestra como quedo armado el equipo.
|
|
208
|
+
|
|
209
|
+
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.
|
|
210
|
+
|
|
211
|
+
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.
|
|
212
|
+
|
|
213
|
+
Ejemplo mental simple:
|
|
214
|
+
|
|
215
|
+
- Claude puede coordinar frontend.
|
|
216
|
+
- OpenAI puede coordinar backend.
|
|
217
|
+
- MiniMax puede hacer documentacion o tareas rapidas.
|
|
218
|
+
- Ollama puede actuar como ejecutor local.
|
|
219
|
+
- El coordinador principal mira el objetivo completo y recibe reportes de cada area.
|
|
220
|
+
|
|
221
|
+
## Crear y ejecutar una ejecucion
|
|
222
|
+
|
|
223
|
+
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.
|
|
224
|
+
|
|
225
|
+
### `/orchestrate`
|
|
226
|
+
|
|
227
|
+
`/orchestrate` toma un team y un objetivo, planifica el trabajo, **te muestra el plan en pantalla** y te pregunta si quieres ejecutarlo ya:
|
|
228
|
+
|
|
229
|
+
```sh
|
|
230
|
+
/orchestrate core-dev crear endpoint de login y UI de acceso
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
Que pasa cuando lo ejecutas:
|
|
234
|
+
|
|
235
|
+
1. El sistema valida el team, el orquestador global y los equipos internos.
|
|
236
|
+
2. Crea la ejecucion y todas sus tareas en estado `ready` o `blocked` segun la configuracion del equipo.
|
|
237
|
+
3. **Te muestra el plan**: tareas por equipo, agentes asignados, advertencias de configuracion.
|
|
238
|
+
4. Te ofrece dos teclas:
|
|
239
|
+
- **`Enter`**: ejecuta inmediatamente las tareas `ready`. Veras progreso en vivo (equipo que esta trabajando, agente activo, fase) y al final un reporte consolidado.
|
|
240
|
+
- **`Esc`**: deja la ejecucion en `planned`. Puedes revisar con `/run show <run-id>` o ejecutar mas tarde con `/run resume <run-id>`.
|
|
241
|
+
|
|
242
|
+
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.
|
|
243
|
+
|
|
244
|
+
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:
|
|
245
|
+
|
|
246
|
+
```sh
|
|
247
|
+
/run show <run-id> # revisar el plan en detalle
|
|
248
|
+
/run resume <run-id> # ejecutar despues
|
|
249
|
+
```
|
|
250
|
+
|
|
251
|
+
### `/run`
|
|
252
|
+
|
|
253
|
+
`/run` sirve para revisar, ejecutar, reintentar, reasignar o cancelar una ejecucion.
|
|
254
|
+
|
|
255
|
+
Comandos principales:
|
|
256
|
+
|
|
257
|
+
```sh
|
|
258
|
+
/run
|
|
259
|
+
/run list
|
|
260
|
+
/run show <run-id>
|
|
261
|
+
/run messages <run-id>
|
|
262
|
+
/run tasks <run-id>
|
|
263
|
+
/run task <task-id>
|
|
264
|
+
/run equipo <run-id> <equipo>
|
|
265
|
+
/run resume <run-id>
|
|
266
|
+
/run cancel <run-id>
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
Comandos de recuperacion:
|
|
270
|
+
|
|
271
|
+
```sh
|
|
272
|
+
/run retry <run-id> [task-id]
|
|
273
|
+
/run cancel-task <task-id>
|
|
274
|
+
/run reassign <task-id> <provider>/<agent>
|
|
275
|
+
```
|
|
276
|
+
|
|
277
|
+
Que hace cada comando:
|
|
278
|
+
|
|
279
|
+
- `/run list` muestra las ejecuciones guardadas.
|
|
280
|
+
- `/run show <run-id>` muestra resumen, estado, tareas y ultimos mensajes.
|
|
281
|
+
- `/run tasks <run-id>` muestra todas las tareas de la ejecucion.
|
|
282
|
+
- `/run task <task-id>` muestra una tarea concreta con sus mensajes y resultados.
|
|
283
|
+
- `/run equipo <run-id> frontend` muestra solo el area `frontend`.
|
|
284
|
+
- `/run messages <run-id>` muestra la bitacora completa.
|
|
285
|
+
- `/run resume <run-id>` ejecuta tareas listas.
|
|
286
|
+
- `/run cancel <run-id>` detiene la ejecucion.
|
|
287
|
+
- `/run retry <run-id>` reintenta tareas fallidas o bloqueadas.
|
|
288
|
+
- `/run retry <run-id> <task-id>` reintenta una tarea concreta.
|
|
289
|
+
- `/run cancel-task <task-id>` bloquea una tarea para que no continue.
|
|
290
|
+
- `/run reassign <task-id> openai/backend-lead` cambia el agente responsable.
|
|
291
|
+
|
|
292
|
+
Estados de una ejecucion:
|
|
293
|
+
|
|
294
|
+
- `planned`: fue creada pero aun no se ejecuto.
|
|
295
|
+
- `in_progress`: esta en ejecucion.
|
|
296
|
+
- `completed`: termino sin tareas abiertas.
|
|
297
|
+
- `failed`: alguna tarea fallo o quedo bloqueada.
|
|
298
|
+
- `cancelled`: fue cancelada por el usuario.
|
|
299
|
+
|
|
300
|
+
Estados de una tarea:
|
|
301
|
+
|
|
302
|
+
- `pending`: aun no esta lista.
|
|
303
|
+
- `ready`: puede ejecutarse.
|
|
304
|
+
- `in_progress`: esta ejecutandose.
|
|
305
|
+
- `completed`: termino con resultado.
|
|
306
|
+
- `failed`: fallo al ejecutar.
|
|
307
|
+
- `blocked`: falta configuracion, credenciales, modelo, endpoint o agente valido.
|
|
308
|
+
|
|
309
|
+
### Ejemplo completo
|
|
310
|
+
|
|
311
|
+
```sh
|
|
312
|
+
# 1. Configurar dos proveedores y sus perfiles
|
|
313
|
+
/provider claude profile main
|
|
314
|
+
/login
|
|
315
|
+
/model
|
|
316
|
+
|
|
317
|
+
/provider openai profile work
|
|
318
|
+
/login
|
|
319
|
+
/model
|
|
320
|
+
|
|
321
|
+
# 2. Crear el team con frontend en Claude y backend en OpenAI
|
|
322
|
+
/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
|
|
323
|
+
/team show core-dev
|
|
324
|
+
|
|
325
|
+
# 3. Pedir el objetivo. /orchestrate planifica, muestra el plan
|
|
326
|
+
# en pantalla y pregunta si ejecutar ya:
|
|
327
|
+
# [Enter] = ejecuta y veras progreso + reporte final
|
|
328
|
+
# [Esc] = solo planifica, queda en estado 'planned'
|
|
329
|
+
/orchestrate core-dev crear login con UI y API
|
|
330
|
+
|
|
331
|
+
# 4. (Opcional) revisar la bitacora completa de mensajes
|
|
332
|
+
/run list
|
|
333
|
+
/run messages <run-id>
|
|
334
|
+
```
|
|
335
|
+
|
|
336
|
+
Notas importantes:
|
|
337
|
+
|
|
338
|
+
- 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>`.
|
|
339
|
+
- 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>`.
|
|
340
|
+
|
|
341
|
+
## Seleccion automatica y fallback
|
|
342
|
+
|
|
343
|
+
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.
|
|
344
|
+
|
|
345
|
+
### `/policy`
|
|
346
|
+
|
|
347
|
+
`/policy` muestra politicas predefinidas. Una politica indica como elegir agentes.
|
|
348
|
+
|
|
349
|
+
```sh
|
|
350
|
+
/policy list
|
|
351
|
+
/policy show score-with-fallback:quality
|
|
352
|
+
```
|
|
353
|
+
|
|
354
|
+
Modos disponibles:
|
|
355
|
+
|
|
356
|
+
- `manual`: usa el agente que ya estaba asignado.
|
|
357
|
+
- `score`: elige el mejor agente por puntaje.
|
|
358
|
+
- `score-with-fallback`: elige el mejor agente y guarda candidatos alternos.
|
|
359
|
+
- `fallback-only`: mantiene la asignacion inicial y solo cambia si algo falla.
|
|
360
|
+
|
|
361
|
+
Objetivos disponibles:
|
|
362
|
+
|
|
363
|
+
- `balanced`: equilibrio general.
|
|
364
|
+
- `cost`: prioriza costo.
|
|
365
|
+
- `latency`: prioriza velocidad.
|
|
366
|
+
- `quality`: prioriza calidad.
|
|
367
|
+
- `capability`: prioriza especialidad declarada.
|
|
368
|
+
- `resilience`: prioriza estabilidad y opciones de recuperacion.
|
|
369
|
+
|
|
370
|
+
Formato:
|
|
371
|
+
|
|
372
|
+
```text
|
|
373
|
+
modo:objetivo
|
|
374
|
+
```
|
|
375
|
+
|
|
376
|
+
Ejemplos:
|
|
377
|
+
|
|
378
|
+
```text
|
|
379
|
+
score-with-fallback:quality
|
|
380
|
+
score:capability
|
|
381
|
+
score-with-fallback:resilience
|
|
382
|
+
manual:balanced
|
|
383
|
+
```
|
|
384
|
+
|
|
385
|
+
### Comandos de Fase 4
|
|
386
|
+
|
|
387
|
+
```sh
|
|
388
|
+
/run optimize <run-id> [policy]
|
|
389
|
+
/run assign <run-id> [policy]
|
|
390
|
+
/run fallback <run-id> [task-id] [policy]
|
|
391
|
+
/run explain <run-id>
|
|
392
|
+
```
|
|
393
|
+
|
|
394
|
+
Que hace cada uno:
|
|
395
|
+
|
|
396
|
+
- `/run optimize <run-id> score-with-fallback:quality` simula la seleccion y muestra candidatos. No cambia tareas.
|
|
397
|
+
- `/run assign <run-id> score:capability` aplica la seleccion y asigna tareas abiertas.
|
|
398
|
+
- `/run fallback <run-id> <task-id> score-with-fallback:resilience` busca otro agente para una tarea fallida o bloqueada.
|
|
399
|
+
- `/run explain <run-id>` muestra las decisiones guardadas como mensajes `policy.*`.
|
|
400
|
+
|
|
401
|
+
Reglas importantes:
|
|
402
|
+
|
|
403
|
+
- cada decision automatica queda guardada en SQLite
|
|
404
|
+
- `/run optimize` es seguro porque solo muestra recomendaciones
|
|
405
|
+
- `/run assign` y `/run fallback` si cambian tareas
|
|
406
|
+
- un agente deshabilitado no debe ser elegido
|
|
407
|
+
- si falta perfil, modelo o credenciales, la tarea puede quedar `blocked`
|
|
408
|
+
- errores de autenticacion no deben reintentarse agresivamente
|
|
409
|
+
|
|
410
|
+
## Ejemplo completo de flujo de trabajo
|
|
411
|
+
|
|
412
|
+
Este ejemplo muestra un flujo real de principio a fin. Puedes cambiar `claude`, `openai`, `minimax` u `ollama` por los proveedores que tengas configurados.
|
|
413
|
+
|
|
414
|
+
### 1. Preparar el primer proveedor
|
|
415
|
+
|
|
416
|
+
Activa el proveedor, inicia sesion y elige modelo.
|
|
417
|
+
|
|
418
|
+
```sh
|
|
419
|
+
/provider claude profile main
|
|
420
|
+
/login
|
|
421
|
+
/model
|
|
422
|
+
```
|
|
423
|
+
|
|
424
|
+
Verifica que quedo activo:
|
|
425
|
+
|
|
426
|
+
```sh
|
|
427
|
+
/status
|
|
428
|
+
```
|
|
429
|
+
|
|
430
|
+
Debes revisar que aparezcan proveedor, perfil activo, modelo guardado y credenciales configuradas.
|
|
431
|
+
|
|
432
|
+
### 2. Preparar otro proveedor
|
|
433
|
+
|
|
434
|
+
Repite el proceso para otro proveedor. En este ejemplo OpenAI sera backend.
|
|
435
|
+
|
|
436
|
+
```sh
|
|
437
|
+
/provider openai profile work
|
|
438
|
+
/login
|
|
439
|
+
/model
|
|
440
|
+
/status
|
|
441
|
+
```
|
|
442
|
+
|
|
443
|
+
Si usas Ollama local, normalmente seria:
|
|
444
|
+
|
|
445
|
+
```sh
|
|
446
|
+
/provider ollama profile local
|
|
447
|
+
/model
|
|
448
|
+
/status
|
|
449
|
+
```
|
|
450
|
+
|
|
451
|
+
### 3. Crear el equipo con el wizard
|
|
452
|
+
|
|
453
|
+
Abre el wizard:
|
|
454
|
+
|
|
455
|
+
```sh
|
|
456
|
+
/workspace setup
|
|
457
|
+
```
|
|
458
|
+
|
|
459
|
+
Desde ahi puedes elegir:
|
|
460
|
+
|
|
461
|
+
- `Preparar proveedor/perfil`: seleccionas proveedor, escribes perfil y el sistema lanza `/provider`. Si faltan credenciales, se abre login/configuracion; despues te lleva a `/model`.
|
|
462
|
+
- `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.
|
|
463
|
+
|
|
464
|
+
Si ya sabes los perfiles y areas, puedes saltarte el wizard y crear el equipo base en un solo comando:
|
|
465
|
+
|
|
466
|
+
```sh
|
|
467
|
+
/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
|
|
468
|
+
/team show core-dev
|
|
469
|
+
```
|
|
470
|
+
|
|
471
|
+
En este ejemplo:
|
|
472
|
+
|
|
473
|
+
- `core-dev` es el equipo.
|
|
474
|
+
- `claude/frontend-lead` coordina el equipo completo.
|
|
475
|
+
- `frontend` queda asignado a Claude.
|
|
476
|
+
- `backend` queda asignado a OpenAI.
|
|
477
|
+
|
|
478
|
+
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.
|
|
479
|
+
|
|
480
|
+
### 4. Crear una ejecucion y revisar el plan en pantalla
|
|
481
|
+
|
|
482
|
+
```sh
|
|
483
|
+
/orchestrate core-dev crear login con UI y API
|
|
484
|
+
```
|
|
485
|
+
|
|
486
|
+
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:
|
|
487
|
+
|
|
488
|
+
```text
|
|
489
|
+
Plan listo para core-dev
|
|
490
|
+
Ejecucion: 1b4fb901-...
|
|
491
|
+
Objetivo: crear login con UI y API
|
|
492
|
+
Orquestador global: openai/backend-lead
|
|
493
|
+
|
|
494
|
+
Tareas por equipo
|
|
495
|
+
- backend -> ready | assigned=openai/backend-lead
|
|
496
|
+
- docs -> blocked | assigned=sin asignar
|
|
497
|
+
- frontend -> ready | assigned=claude/frontend-lead
|
|
498
|
+
- planning -> blocked | assigned=sin asignar
|
|
499
|
+
|
|
500
|
+
Listas: 2 | Bloqueadas: 2
|
|
501
|
+
|
|
502
|
+
Advertencias
|
|
503
|
+
- docs: warning -> No hay agente asignable para este equipo.
|
|
504
|
+
- planning: warning -> No hay agente asignable para este equipo.
|
|
505
|
+
|
|
506
|
+
[Enter] Ejecutar ahora (las bloqueadas se omiten) | [Esc] Solo planificar
|
|
507
|
+
```
|
|
508
|
+
|
|
509
|
+
### 5. Decidir: ejecutar ya, o revisar y ejecutar despues
|
|
510
|
+
|
|
511
|
+
- **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.
|
|
512
|
+
- **Pulsa `Esc`** si prefieres revisar antes. La ejecucion queda en `planned`. Despues puedes inspeccionarla con:
|
|
513
|
+
|
|
514
|
+
```sh
|
|
515
|
+
/run show <run-id>
|
|
516
|
+
/run tasks <run-id>
|
|
517
|
+
/run equipo <run-id> frontend
|
|
518
|
+
/run equipo <run-id> backend
|
|
519
|
+
```
|
|
520
|
+
|
|
521
|
+
Si una tarea aparece `blocked`, normalmente falta agente, workspace, perfil, modelo o credencial. Asigna lo que falte y vuelve.
|
|
522
|
+
|
|
523
|
+
### 6. Ejecutar manualmente cuando hayas pulsado Esc
|
|
524
|
+
|
|
525
|
+
```sh
|
|
526
|
+
/run resume <run-id>
|
|
527
|
+
```
|
|
528
|
+
|
|
529
|
+
Luego revisa resultados:
|
|
530
|
+
|
|
531
|
+
```sh
|
|
532
|
+
/run show <run-id>
|
|
533
|
+
/run messages <run-id>
|
|
534
|
+
```
|
|
535
|
+
|
|
536
|
+
Si quieres ver una tarea concreta:
|
|
537
|
+
|
|
538
|
+
```sh
|
|
539
|
+
/run task <task-id>
|
|
540
|
+
```
|
|
541
|
+
|
|
542
|
+
### 7. Usar seleccion automatica antes de reasignar
|
|
543
|
+
|
|
544
|
+
Si quieres ver que agente recomienda el sistema sin cambiar nada:
|
|
545
|
+
|
|
546
|
+
```sh
|
|
547
|
+
/policy list
|
|
548
|
+
/policy show score-with-fallback:quality
|
|
549
|
+
/run optimize <run-id> score-with-fallback:quality
|
|
550
|
+
```
|
|
551
|
+
|
|
552
|
+
Si la recomendacion te parece correcta, puedes aplicarla:
|
|
553
|
+
|
|
554
|
+
```sh
|
|
555
|
+
/run assign <run-id> score:capability
|
|
556
|
+
```
|
|
557
|
+
|
|
558
|
+
Para ver por que se tomaron decisiones:
|
|
559
|
+
|
|
560
|
+
```sh
|
|
561
|
+
/run explain <run-id>
|
|
562
|
+
```
|
|
563
|
+
|
|
564
|
+
### 8. Recuperar errores o bloqueos
|
|
565
|
+
|
|
566
|
+
Si una tarea fallo o quedo bloqueada, puedes reintentar:
|
|
567
|
+
|
|
568
|
+
```sh
|
|
569
|
+
/run retry <run-id>
|
|
570
|
+
```
|
|
571
|
+
|
|
572
|
+
O reintentar solo una tarea:
|
|
573
|
+
|
|
574
|
+
```sh
|
|
575
|
+
/run retry <run-id> <task-id>
|
|
576
|
+
```
|
|
577
|
+
|
|
578
|
+
Si quieres cambiarla a otro agente manualmente:
|
|
579
|
+
|
|
580
|
+
```sh
|
|
581
|
+
/run reassign <task-id> claude/frontend-lead
|
|
582
|
+
/run resume <run-id>
|
|
583
|
+
```
|
|
584
|
+
|
|
585
|
+
Si quieres que el sistema busque otro agente compatible:
|
|
586
|
+
|
|
587
|
+
```sh
|
|
588
|
+
/run fallback <run-id> <task-id> score-with-fallback:resilience
|
|
589
|
+
/run resume <run-id>
|
|
590
|
+
```
|
|
591
|
+
|
|
592
|
+
### 9. Cerrar o cancelar
|
|
593
|
+
|
|
594
|
+
Si todo termino bien:
|
|
595
|
+
|
|
596
|
+
```sh
|
|
597
|
+
/run show <run-id>
|
|
598
|
+
```
|
|
599
|
+
|
|
600
|
+
Si necesitas detener la ejecucion:
|
|
601
|
+
|
|
602
|
+
```sh
|
|
603
|
+
/run cancel <run-id>
|
|
604
|
+
```
|
|
605
|
+
|
|
606
|
+
### Resumen corto
|
|
607
|
+
|
|
608
|
+
```sh
|
|
609
|
+
/provider claude profile main
|
|
610
|
+
/login
|
|
611
|
+
/model
|
|
612
|
+
|
|
613
|
+
/provider openai profile work
|
|
614
|
+
/login
|
|
615
|
+
/model
|
|
616
|
+
|
|
617
|
+
/workspace setup core-dev orchestrator=backend claude/main:frontend openai/work:backend
|
|
618
|
+
/team show core-dev
|
|
619
|
+
|
|
620
|
+
/orchestrate core-dev crear login con UI y API
|
|
621
|
+
# Aqui ves el plan en pantalla.
|
|
622
|
+
# [Enter] ejecuta ya y muestra el reporte final.
|
|
623
|
+
# [Esc] te deja la ejecucion en 'planned'; ejecuta despues con /run resume <run-id>.
|
|
624
|
+
|
|
625
|
+
/run messages <run-id> # bitacora completa cuando quieras revisarla
|
|
626
|
+
```
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
## Limitaciones actuales
|
|
2
|
+
|
|
3
|
+
- La calidad de la ejecucion depende de que cada agente tenga perfil, modelo y credenciales validas.
|
|
4
|
+
- La seleccion automatica ya existe, pero las politicas personalizadas editables todavia no estan persistidas con `/policy create`.
|
|
5
|
+
- El fallback es auditable y controlado, no un sistema de retries infinitos.
|
|
6
|
+
- Si varios proveedores producen respuestas incompatibles, el usuario debe revisar el consolidado antes de cerrar la ejecucion.
|
|
7
|
+
|
|
8
|
+
## Cuando algo no avanza
|
|
9
|
+
|
|
10
|
+
Sintomas comunes despues de `/orchestrate` o `/run resume`, y como salir de cada uno.
|
|
11
|
+
|
|
12
|
+
### "El plan se quedo en `planned` y no pasa nada"
|
|
13
|
+
|
|
14
|
+
Pulsaste `Esc` (o cerraste la vista) en lugar de `Enter`. La ejecucion existe pero no se ejecuto. Reanuda cuando quieras:
|
|
15
|
+
|
|
16
|
+
```sh
|
|
17
|
+
/run resume <run-id>
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
### "Aparecen equipos `blocked` que yo no pedi"
|
|
21
|
+
|
|
22
|
+
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:
|
|
23
|
+
|
|
24
|
+
- **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.
|
|
25
|
+
- **Asignar agente y reintentar**:
|
|
26
|
+
```sh
|
|
27
|
+
/team equipo <team> docs <provider>/<agent>
|
|
28
|
+
/team equipo <team> planning <provider>/<agent>
|
|
29
|
+
/run retry <run-id>
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
### "Mi proveedor devolvio `usage_limit_reached` o `rate_limit`"
|
|
33
|
+
|
|
34
|
+
Pasa cuando un proveedor alcanza el limite de tokens/segundo o de plan. La tarea afectada queda `failed`. Opciones:
|
|
35
|
+
|
|
36
|
+
- Cambiar de perfil del mismo proveedor con `/profile use <proveedor> <otro-perfil>` y reintentar.
|
|
37
|
+
- Reasignar la tarea a otro agente:
|
|
38
|
+
```sh
|
|
39
|
+
/run reassign <task-id> <provider>/<agent>
|
|
40
|
+
/run resume <run-id>
|
|
41
|
+
```
|
|
42
|
+
- Pedir al sistema que busque un agente alterno:
|
|
43
|
+
```sh
|
|
44
|
+
/run fallback <run-id> <task-id> score-with-fallback:resilience
|
|
45
|
+
/run resume <run-id>
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
### "Faltan credenciales o el modelo no esta configurado"
|
|
49
|
+
|
|
50
|
+
Verifica el estado del perfil:
|
|
51
|
+
|
|
52
|
+
```sh
|
|
53
|
+
/status
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
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.
|
|
57
|
+
|
|
58
|
+
### "Quiero detener una ejecucion en marcha"
|
|
59
|
+
|
|
60
|
+
```sh
|
|
61
|
+
/run cancel <run-id>
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### "Quiero ver que dijo cada orquestador local antes del reporte final"
|
|
65
|
+
|
|
66
|
+
```sh
|
|
67
|
+
/run messages <run-id>
|
|
68
|
+
/run equipo <run-id> <equipo>
|
|
69
|
+
/run task <task-id>
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
`/run messages` te lista en orden cronologico todos los `global-plan`, `squad-plan`, `task.completed`, `run-report` y eventos de policy de la ejecucion.
|