oficina-opencode 2.1.0 → 2.1.1
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 +1 -1
- package/commands/oficina.md +22 -9
- package/docs/QUE-ES.md +1 -1
- package/package.json +1 -1
- package/skills/oficina/SKILL.md +191 -69
- package/skills/oficina/reference/mesh.md +11 -2
package/README.md
CHANGED
package/commands/oficina.md
CHANGED
|
@@ -1,34 +1,47 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: Abrir la Oficina de Agents para trabajar un objetivo de punta a punta con
|
|
2
|
+
description: Abrir la Oficina de Agents para trabajar un objetivo de punta a punta con dispatch, auto-revisión, gates de calidad y evidencia por requisito
|
|
3
3
|
subtask: false
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
Cargá la skill `oficina` y seguí su protocolo exactamente. Si sus instrucciones no están ya en contexto,
|
|
7
|
-
|
|
8
|
-
**Vos sos el Director.** Leé el agente `oficina-director` en `~/.config/opencode/agents/oficina-director.md` y adoptá su rol: planificás, delegás, decidís, escalás. **No escribas código de producción vos** — eso lo hacen los especialistas que delegás.
|
|
6
|
+
Cargá la skill `oficina` y seguí su protocolo exactamente. Si sus instrucciones no están ya en contexto, cargala primero.
|
|
9
7
|
|
|
10
8
|
**Objetivo de la corrida:** $ARGUMENTS
|
|
11
9
|
|
|
12
10
|
Si el objetivo está vacío, tomá el pedido más reciente del usuario en esta conversación como objetivo.
|
|
13
11
|
|
|
12
|
+
## Paso 0 — ¿Plugin o fallback?
|
|
13
|
+
|
|
14
|
+
**[plugin]** Si tenés las tools `oficina_*` disponibles, usá el **motor duro**. Es lo que hace que los invariantes dejen de ser sugerencias: el guard de scope rechaza escrituras fuera del scope, el gate corre comandos de verdad, y una card no se cierra sin evidencia.
|
|
15
|
+
|
|
16
|
+
Comprobá si existe `oficina_plan`. Si existe:
|
|
17
|
+
|
|
18
|
+
1. `oficina_plan` con el objetivo descompuesto en cards (ver abajo).
|
|
19
|
+
2. `oficina_dispatch` → **arma el equipo**: resuelve los roles en el catálogo de agency-agents, materializa los agentes y los arranca en paralelo.
|
|
20
|
+
3. `oficina_mesa` (view) → mirá quién trabaja en qué.
|
|
21
|
+
4. Corré el ciclo con las tools: `oficina_assign` → trabajo → `oficina_submit` → `oficina_review` → `oficina_evidence` → `oficina_gate`.
|
|
22
|
+
5. `oficina_cost` para el costo; `oficina_stop` si la corrida se descontrola.
|
|
23
|
+
|
|
24
|
+
**Si NO hay plugin**, seguí el flujo de artefactos en markdown de `reference/protocol.md`. Mismo protocolo, sin enforcement.
|
|
25
|
+
|
|
14
26
|
## Arrancá así — sin preguntar permiso
|
|
15
27
|
|
|
16
28
|
1. Leé `reference/protocol.md` y `reference/roles.md` de la skill `oficina`.
|
|
17
29
|
2. **Resolvé PROJECT_ROOT** siguiendo el Paso 0 del protocolo (buscá markers de proyecto; no asumas que el cwd es el proyecto). `OFFICE_DIR = PROJECT_ROOT/.oficina/`. Usá paths ABSOLUTOS en todo lo que escribas y en todos los prompts de delegación.
|
|
18
|
-
3.
|
|
19
|
-
4.
|
|
30
|
+
3. Descomponé el objetivo en cards con acceptance criteria **verificables** y gate explícito. Si el objetivo es vago, hacé las inferencias razonables y anotá cuáles son — no frenes por ambigüedad menor. Ordená las cards por **causa**: si el fix de B rompe el gate de A, B va primero.
|
|
31
|
+
4. Cada card necesita: `scope` (qué archivos puede tocar), `acceptance` (criterios verificables) y `gate` (el comando que lo demuestra).
|
|
20
32
|
5. Delegá por la **tabla de enrutado** de `reference/roles.md`. El Crítico nunca es el owner. El Verificador nunca es el Implementador. Cada subagente es stateless: el prompt lleva TODO el contexto, y los paths absolutos del PROJECT_ROOT.
|
|
21
|
-
6. Corré el ciclo: TRABAJO → AUTO-REVIEW → GATES → DONE, o REWORK/REPLAN/ESCALADA.
|
|
22
|
-
7. Checkpoint al usuario cada 3 cards — **
|
|
33
|
+
6. Corré el ciclo: TRABAJO → AUTO-REVIEW → GATES + EVIDENCIA → DONE, o REWORK/REPLAN/ESCALADA.
|
|
34
|
+
7. Checkpoint al usuario cada 3 cards — **informá y seguí**, no pidás permiso.
|
|
23
35
|
8. Escalá solo con el formato de 2-3 opciones concretas + recomendación.
|
|
24
36
|
|
|
25
37
|
## Presupuesto
|
|
26
38
|
|
|
27
|
-
20 cards, 40 invocaciones de subagente por corrida.
|
|
39
|
+
20 cards, 40 invocaciones de subagente, 20 spawns por corrida. **[plugin]** El costo real (tokens y USD) se ve con `oficina_cost`; si se dispara, `oficina_stop` frena la corrida.
|
|
28
40
|
|
|
29
41
|
## Lo que esta oficina garantiza
|
|
30
42
|
|
|
31
43
|
- Ninguna card se marca DONE sin `gates.md` en PASS
|
|
44
|
+
- **[plugin]** Ninguna card se marca DONE sin evidencia para cada criterio de aceptación obligatorio
|
|
32
45
|
- Ningún trabajo se auto-aprueba
|
|
33
46
|
- Nada se pierde: todo está en `.oficina/artifacts/`
|
|
34
47
|
- El objetivo se trabaja hasta cumplirlo o hasta un bloqueo real
|
package/docs/QUE-ES.md
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "oficina-opencode",
|
|
3
|
-
"version": "2.1.
|
|
3
|
+
"version": "2.1.1",
|
|
4
4
|
"description": "Oficina de Agents — malla de coordinadores + peer mesh para OpenCode. Orquestación durable de subagentes con bus de mensajes en disco, roster de roles, leases, gates de calidad y escalamiento por invariantes.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|
package/skills/oficina/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: oficina
|
|
3
|
-
description: Oficina de Agents que trabaja un objetivo de principio a fin sin instrucciones repetidas. Con el plugin instalado, la oficina es una máquina de estados con hooks de enforcement: el Director descompone,
|
|
3
|
+
description: Oficina de Agents que trabaja un objetivo de principio a fin sin instrucciones repetidas. Con el plugin instalado, la oficina es una máquina de estados con hooks de enforcement: el Director descompone, el dispatch crea los subagentes buscándolos en el catálogo real de agency-agents, coordina por un bus de mensajes en disco, permite pedir ayuda y delegar entre pares, y un hook de auto-continuación sigue trabajando cuando el modelo dice "terminé". Una card no se cierra sin gates en verde Y sin evidencia para cada criterio de aceptación. Sin el plugin, el mismo protocolo funciona con el flujo de artefactos en markdown. Úsala cuando el usuario da un objetivo, feature, bug o refactor y quiere que un equipo de agentes lo ejecute completo, se auto-verifique y entregue evidencia, en vez de que el assistant lo haga todo lineal.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# OFICINA — Oficina de Agents
|
|
@@ -12,10 +12,13 @@ Un objetivo entra por la puerta. La oficina lo ejecuta, se auto-verifica, y entr
|
|
|
12
12
|
| | **Con plugin** (motor duro) | **Sin plugin** (fallback) |
|
|
13
13
|
|---|---|---|
|
|
14
14
|
| Estado | Máquina de estados en TypeScript | `state.json` markdown + JSON |
|
|
15
|
-
|
|
|
16
|
-
|
|
|
15
|
+
| Equipo | `oficina_dispatch` crea los subagentes | El modelo los crea a mano |
|
|
16
|
+
| Gates | 7 comandos reales, exit codes interpretados por código | El modelo corre los comandos y pega la salida |
|
|
17
|
+
| Enforcement | 3 capas: guard, `permission.ask`, tripwire | Disciplina del prompt |
|
|
18
|
+
| Cierre | Gates **+ evidencia** de cada requisito | Solo gates |
|
|
17
19
|
| Loop | Hook `session.idle` → la oficina sigue sola | El modelo decide si sigue |
|
|
18
20
|
| Invariantes | `assertInvariants` en código | Regla dura en el prompt |
|
|
21
|
+
| Costo | Ledger de tokens y USD en tiempo real | No se mide |
|
|
19
22
|
| Comunicación | Bus de mensajes con TTL/ack/idempotencia | Artefactos en disco, unidireccional |
|
|
20
23
|
|
|
21
24
|
**Preferí el plugin.** Si las tools `oficina_*` están disponibles, usá el motor duro: los invariantes dejan de ser sugerencias.
|
|
@@ -29,13 +32,15 @@ El protocolo de este documento sirve para los dos. Las secciones marcadas **[plu
|
|
|
29
32
|
| Falla | Cómo la resuelve OFICINA |
|
|
30
33
|
|---|---|
|
|
31
34
|
| El usuario tiene que dar todas las instrucciones | El **Comandante** descompone solo. El usuario da un objetivo y basta. |
|
|
32
|
-
| El agent "no cumple" lo que dice | Cada card tiene **acceptance criteria** explícitos y un **gate** que se ejecuta, no se opina. |
|
|
33
|
-
| Los subagentes se desaprovechan |
|
|
35
|
+
| El agent "no cumple" lo que se dice | Cada card tiene **acceptance criteria** explícitos y un **gate** que se ejecuta, no se opina. |
|
|
36
|
+
| Los subagentes se desaprovechan | **Dispatch** que resuelve el rol desde el catálogo real de agency-agents y panel con complementos. |
|
|
34
37
|
| Hay que repetir el contexto | **Ledger de contexto** en disco (`.oficina/context.md`) + handoff por artefactos. |
|
|
35
|
-
| Los agents no se coordinan ni se ayudan | **Bus de mensajes
|
|
38
|
+
| Los agents no se coordinan ni se ayudan | **Bus de mensajes** + **mesa** compartida: cada uno sabe quién trabaja en qué. |
|
|
36
39
|
| Son monotonos | **Revisor distinto del autor** + rotación de owner y de dimensión. |
|
|
37
40
|
| Nadie los orquesta | **3 coordinadores** con dominios particionados y arbitraje explícito. |
|
|
38
41
|
| La IA dice "terminé" sin terminar | **[plugin]** Hook de auto-continuación: el estado decide, no la confianza. |
|
|
42
|
+
| Compila pero no cumple | **Grafo de evidencia**: cada criterio de aceptación necesita respaldo o la card no se cierra. |
|
|
43
|
+
| Se gasta una fortuna sin avisar | **Ledger de costo** con presupuestos y **freno de emergencia**. |
|
|
39
44
|
|
|
40
45
|
---
|
|
41
46
|
|
|
@@ -52,6 +57,115 @@ Detalle completo en `reference/mesh.md`.
|
|
|
52
57
|
|
|
53
58
|
---
|
|
54
59
|
|
|
60
|
+
## El flujo completo: de un objetivo a un equipo
|
|
61
|
+
|
|
62
|
+
Este es el flujo. Seguílo en orden.
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
EL USUARIO DA UN OBJETIVO
|
|
66
|
+
|
|
|
67
|
+
v
|
|
68
|
+
+--------------------------------+
|
|
69
|
+
| 1. PLAN (Comandante) | → cards con scope, acceptance, gate, deps
|
|
70
|
+
| oficina_plan |
|
|
71
|
+
+--------------------------------+
|
|
72
|
+
|
|
|
73
|
+
v
|
|
74
|
+
+--------------------------------+
|
|
75
|
+
| 2. DISPATCH (Integrador) | → RESUELVE LOS ROLES y ARRANCA LOS AGENTES
|
|
76
|
+
| oficina_dispatch | busca en agency-agents, materializa
|
|
77
|
+
| | .opencode/agents/, spawna en paralelo
|
|
78
|
+
+--------------------------------+
|
|
79
|
+
|
|
|
80
|
+
v
|
|
81
|
+
+--------------------------------+
|
|
82
|
+
| 3. MESA (todos) | → quién trabaja en qué, quién está libre,
|
|
83
|
+
| oficina_mesa (view) | qué ayuda espera respuesta
|
|
84
|
+
+--------------------------------+
|
|
85
|
+
|
|
|
86
|
+
v
|
|
87
|
+
+--------------------------------+
|
|
88
|
+
| 4. TRABAJO (Owner) | → oficina_assign + handoff.md + evidence.md
|
|
89
|
+
+--------------------------------+
|
|
90
|
+
|
|
|
91
|
+
v
|
|
92
|
+
+--------------------------------+
|
|
93
|
+
| 5. AUTO-REVIEW (Crítico) | → revisor ≠ owner
|
|
94
|
+
| oficina_review |
|
|
95
|
+
+--------------------------------+
|
|
96
|
+
| APROBADO
|
|
97
|
+
v
|
|
98
|
+
+--------------------------------+
|
|
99
|
+
| 6. GATES + EVIDENCIA | → oficina_gate corre los 7 gates
|
|
100
|
+
| oficina_gate | + verifica el grafo de requisitos
|
|
101
|
+
+--------------------------------+
|
|
102
|
+
| PASA
|
|
103
|
+
v
|
|
104
|
+
+--------------------------------+
|
|
105
|
+
| 7. DONE | → la card queda done, el agente se libera
|
|
106
|
+
+--------------------------------+
|
|
107
|
+
|
|
|
108
|
+
v
|
|
109
|
+
el agente queda LIBRE y ofrece ayuda
|
|
110
|
+
→ puede reclamar la siguiente card
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
**[plugin] El paso 2 es el que hace que esto sea una oficina y no un chatbot.** `oficina_dispatch` es lo único que arma el equipo: resuelve el rol de cada card, materializa el agente con su briefing de 10 secciones, y lo arranca con `session.prompt`.
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Las 16 tools
|
|
118
|
+
|
|
119
|
+
| Tool | Qué hace |
|
|
120
|
+
|---|---|
|
|
121
|
+
| `oficina_plan` | Guarda el plan de cards. El modelo propone; el motor valida y rutea owner/reviewer |
|
|
122
|
+
| **`oficina_dispatch`** | **Arma el equipo**: resuelve los roles, materializa los agentes y los arranca en paralelo |
|
|
123
|
+
| **`oficina_mesa`** | **La mesa**: quién trabaja en qué, quién está libre, qué ayuda espera respuesta, qué cards no tienen owner |
|
|
124
|
+
| `oficina_board` | Estado: cards, owners, agentes libres, agentes sin heartbeat, presupuesto |
|
|
125
|
+
| `oficina_assign` | Toma trabajo — la próxima card, o claim proactivo de una puntual |
|
|
126
|
+
| `oficina_submit` | Entrega handoff + evidencia real → pasa a `REVIEW` |
|
|
127
|
+
| `oficina_review` | Registra el veredicto. El motor **rechaza** que el owner se auto-revise |
|
|
128
|
+
| `oficina_gate` | Corre los 7 gates. Exit codes reales, no opinión |
|
|
129
|
+
| **`oficina_evidence`** | **El grafo de requisitos**: qué evidencia falta para poder cerrar |
|
|
130
|
+
| **`oficina_cost`** | **Tokens y USD** por card, agente y fase, con los presupuestos |
|
|
131
|
+
| **`oficina_stop`** | **Freno de emergencia**: detiene o reanuda la corrida |
|
|
132
|
+
| `oficina_bus` | Bus: `send` · `receive` · `ack` · `help` |
|
|
133
|
+
| `oficina_spawn` | Pide desplegar un agente. El Integrador aprueba o rechaza |
|
|
134
|
+
| `oficina_escalate` | Escala al usuario con 2-3 opciones concretas y recomendación |
|
|
135
|
+
| `oficina_ficha` | Resuelve un rol a ficha y **despliega** el agente con su briefing |
|
|
136
|
+
| `oficina_brief` | Muestra el briefing y el **panel de roles** sin desplegar: decisión del Comandante |
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## El dispatch: cómo se arma el equipo
|
|
141
|
+
|
|
142
|
+
**[plugin]** `oficina_dispatch` hace, por cada card sin owner:
|
|
143
|
+
|
|
144
|
+
1. **Busca el rol** en el catálogo de agency-agents con el matcher.
|
|
145
|
+
2. **Calcula el panel**: primario + complementos (los que cubren lo que el primario NO cubre).
|
|
146
|
+
3. **Materializa el agente** en `.opencode/agents/oficina-<slug>.md` con su briefing de 10 secciones y su prompt de especialidad. Queda versionado con el repo.
|
|
147
|
+
4. **Lo arranca** en paralelo con `session.prompt` (parte `subtask`).
|
|
148
|
+
|
|
149
|
+
El resultado es que **los subagentes heredan el scope de su card** y trabajan con el contexto completo desde el primer token.
|
|
150
|
+
|
|
151
|
+
**Si algo no matchea bien**, no fuerces: `oficina_brief` muestra las alternativas sin desplegar, y `oficina_ficha` despliega un rol puntual.
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
## La mesa: cómo se coordinan
|
|
156
|
+
|
|
157
|
+
**[plugin]** `oficina_mesa` es la vista compartida. Sin ella, el peer mesh es un bus al que nadie mira.
|
|
158
|
+
|
|
159
|
+
- **view** — quién trabaja en qué, quién está libre, qué cards no tienen owner, qué ayuda espera respuesta, qué preguntas están abiertas.
|
|
160
|
+
- **read** — tus mensajes.
|
|
161
|
+
- **respond** — contestar un pedido de ayuda.
|
|
162
|
+
- **offer** — ofrecer ayuda.
|
|
163
|
+
- **claim** — reclamar una card libre.
|
|
164
|
+
|
|
165
|
+
**Consultá la mesa antes de**: reclamar trabajo, pedir ayuda (para saber a quién), y cuando te asignen una card.
|
|
166
|
+
|
|
167
|
+
---
|
|
168
|
+
|
|
55
169
|
## Los 3 coordinadores
|
|
56
170
|
|
|
57
171
|
Un solo coordinador es cuello de botella y punto único de falla. Tres, con dominios particionados:
|
|
@@ -69,56 +183,6 @@ Un solo coordinador es cuello de botella y punto único de falla. Tres, con domi
|
|
|
69
183
|
|
|
70
184
|
---
|
|
71
185
|
|
|
72
|
-
## El ciclo de la oficina
|
|
73
|
-
|
|
74
|
-
```
|
|
75
|
-
OBJETIVO
|
|
76
|
-
|
|
|
77
|
-
v
|
|
78
|
-
+---------------------------+
|
|
79
|
-
| 1. PLAN (Comandante) | Descompone -> cards con owner, acceptance, gate, scope
|
|
80
|
-
+---------------------------+
|
|
81
|
-
|
|
|
82
|
-
v
|
|
83
|
-
+---------------------------+
|
|
84
|
-
| 2. STANDUP | Elige la card mas prioritaria con deps satisfechas
|
|
85
|
-
+---------------------------+
|
|
86
|
-
|
|
|
87
|
-
v
|
|
88
|
-
+---------------------------+
|
|
89
|
-
| 3. TRABAJO (Owner) | Ejecuta + escribe handoff.md + evidence.md
|
|
90
|
-
+---------------------------+
|
|
91
|
-
|
|
|
92
|
-
v
|
|
93
|
-
+---------------------------+
|
|
94
|
-
| 4. AUTO-REVIEW | Critico != owner. APROBADO o RECHAZADO con razon
|
|
95
|
-
+---------------------------+
|
|
96
|
-
| RECHAZADO ----------------+
|
|
97
|
-
| APROBADO |
|
|
98
|
-
v |
|
|
99
|
-
+---------------------------+ |
|
|
100
|
-
| 5. GATES | |
|
|
101
|
-
| Verificador (tecnico) | |
|
|
102
|
-
| Guardian (seguridad) | |
|
|
103
|
-
+---------------------------+ |
|
|
104
|
-
| |
|
|
105
|
-
| FALLA ---------------------+
|
|
106
|
-
| PASA
|
|
107
|
-
v
|
|
108
|
-
+-----------+ +---------------+
|
|
109
|
-
| 6. DONE | | 7. REWORK |
|
|
110
|
-
+-----------+ | 1er: reintenta|
|
|
111
|
-
| 2do: replan |
|
|
112
|
-
| 3ro: ESCALA |
|
|
113
|
-
+---------------+
|
|
114
|
-
```
|
|
115
|
-
|
|
116
|
-
**[plugin]** Con el plugin, el paso 3 es un `oficina_assign` y el paso 5 un `oficina_gate` que corre los comandos de verdad.
|
|
117
|
-
|
|
118
|
-
Cada 3 cards completadas → **checkpoint** al usuario. Al final → **informe de entrega**.
|
|
119
|
-
|
|
120
|
-
---
|
|
121
|
-
|
|
122
186
|
## Los roles
|
|
123
187
|
|
|
124
188
|
| Rol | Agente | Puede aprobar? |
|
|
@@ -141,7 +205,11 @@ Cada 3 cards completadas → **checkpoint** al usuario. Al final → **informe d
|
|
|
141
205
|
|
|
142
206
|
**[plugin]** `oficina_brief` muestra el panel sin desplegar; `oficina_ficha` además despliega el agente con su briefing.
|
|
143
207
|
|
|
144
|
-
**1. Catálogo primero.** El repo de agency-agents tiene **
|
|
208
|
+
**1. Catálogo primero.** El repo de agency-agents tiene **258 agentes resolubles en 18 divisiones** (la cifra vive en `docs/catalog-facts.json`, con su commit de origen, y el CI verifica que no se desactualice). La especialidad real de cada uno está en el **cuerpo** (Core Mission, Technical Deliverables, Advanced Capabilities) y en la `description` y el `vibe` del frontmatter, no solo en el nombre.
|
|
209
|
+
|
|
210
|
+
El matcher pondera por señal: **identidad** (slug + nombre + `description` + `vibe`) 35%, **misión literal** 28%, **misión conceptual** 18%, **división** 10%, **cuerpo** 5%. Además usa **sinónimos por capability** (`"e2e"` es `"end-to-end"`, pero `"e2e"` NO es `"playwright"`), **lematización** (`"testing"` ~ `"test"`) y **focus de misión** (qué fracción de las misiones del agente es del dominio: distingue a un especialista de un generalista que menciona la tool de pasada).
|
|
211
|
+
|
|
212
|
+
**Medido, no supuesto:** el matcher completo acierta el primer rol en el **71%** de 21 tareas de referencia, contra el **48%** de la versión anterior. El benchmark es `npm run bench:selection`.
|
|
145
213
|
|
|
146
214
|
**2. Factory si la cobertura es < 60%.** El rol fabricado emite la **misma estructura de 10 secciones** que el catálogo, con las capabilities, el scope, el objetivo de la corrida y los modos de fallo del rol. Un rol fabricado con contexto es usable; uno genérico no.
|
|
147
215
|
|
|
@@ -151,7 +219,7 @@ Cada 3 cards completadas → **checkpoint** al usuario. Al final → **informe d
|
|
|
151
219
|
- **complementos** — los que cubren lo que el primario NO cubre. Son sus pares en el bus.
|
|
152
220
|
- **sin cubrir** — lo que nadie cubre. Señal de que la card debería partirse en dos.
|
|
153
221
|
|
|
154
|
-
**Nunca fuerces un mal match.** Si nadie cubre una capacidad, se fabrica el rol o se pide ayuda. Un rol medio-
|
|
222
|
+
**Nunca fuerces un mal match.** Si nadie cubre una capacidad, se fabrica el rol o se pide ayuda. Un rol medio-tonto en el equipo arruina más de lo que aporta.
|
|
155
223
|
|
|
156
224
|
**Sin plugin**: la tabla de `reference/roles.md`.
|
|
157
225
|
|
|
@@ -178,6 +246,19 @@ Detalle completo en `reference/mesh.md`.
|
|
|
178
246
|
|
|
179
247
|
---
|
|
180
248
|
|
|
249
|
+
## El scope: una restricción, no una instrucción
|
|
250
|
+
|
|
251
|
+
**[plugin]** Cuando un agente intenta escribir fuera del scope de su card, la operación **se rechaza**. No es una sugerencia.
|
|
252
|
+
|
|
253
|
+
- La ruta se **resuelve** (absoluta → normalizada → symlinks resueltos) y recién ahí se decide.
|
|
254
|
+
- `..`, paths absolutos y symlinks que apuntan afuera están cerrados.
|
|
255
|
+
- Los archivos sensibles (`.env`, `.npmrc`, `.git/**`, claves) **nunca** son escribibles.
|
|
256
|
+
- Los **subagentes heredan el scope**: delegar no es un escalón para salirse.
|
|
257
|
+
|
|
258
|
+
Si el archivo es necesario: pedí por el bus que se amplíe el scope. No lo toques por tu cuenta.
|
|
259
|
+
|
|
260
|
+
---
|
|
261
|
+
|
|
181
262
|
## Pedir ayuda y delegar
|
|
182
263
|
|
|
183
264
|
**[plugin]** `oficina_bus` con `action: "help"`.
|
|
@@ -212,24 +293,65 @@ El modo 3 es lo que convierte la oficina de "N tareas en paralelo" a "N agentes
|
|
|
212
293
|
|
|
213
294
|
---
|
|
214
295
|
|
|
215
|
-
##
|
|
296
|
+
## Verificar el resultado, no solo el proceso
|
|
216
297
|
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
|
|
221
|
-
|
|
222
|
-
|
|
298
|
+
**[plugin]** Siete gates. Los seis técnicos dicen que **el código está sano**; el séptimo dice que **el objetivo está cumplido**:
|
|
299
|
+
|
|
300
|
+
| # | Fase | Qué comprueba |
|
|
301
|
+
|---|---|---|
|
|
302
|
+
| 1 | Build | Compila |
|
|
303
|
+
| 2 | Type check | Tipos |
|
|
304
|
+
| 3 | Lint | Estilo |
|
|
305
|
+
| 4 | Tests | Comportamiento |
|
|
306
|
+
| 5 | Secretos | No hay credenciales en el árbol |
|
|
307
|
+
| 6 | Diff | Qué cambió |
|
|
308
|
+
| 7 | **Requisitos** | **Cada criterio de aceptación tiene evidencia** |
|
|
309
|
+
|
|
310
|
+
**Reglas de honestidad** — no negociables:
|
|
311
|
+
|
|
312
|
+
- Nunca `PASS` en una fase que no se corrió → `NOT RUN` y eso hace fallar el gate
|
|
313
|
+
- Nunca output inventado
|
|
314
|
+
- `N/A` siempre con motivo explícito
|
|
315
|
+
- Una fase aplicable en `FAIL` = gate `FAIL`. No se promedia
|
|
316
|
+
- El escaneo de secretos corre **en código**, no shelling out a `grep` (que no existe en Windows), y **redacta** el valor: un log de gate que imprime la credencial completa la acaba de filtrar
|
|
317
|
+
|
|
318
|
+
### El grafo de evidencia
|
|
319
|
+
|
|
320
|
+
**[plugin]** `oficina_evidence` muestra, por card, qué criterio de aceptación tiene evidencia y cuál no.
|
|
321
|
+
|
|
322
|
+
Cada criterio de aceptación es un **requisito**. Cada evidencia —un artefacto, un test, un gate, una inspección, una auditoría— se vincula a un requisito con un **nivel**:
|
|
323
|
+
|
|
324
|
+
| Nivel | Qué es |
|
|
325
|
+
|---|---|
|
|
326
|
+
| 1 | Estático (un gate) |
|
|
327
|
+
| 2 | Comportamiento (un artefacto, un test) |
|
|
328
|
+
| 3 | Validación de requisitos (inspección) |
|
|
329
|
+
| 4 | Auditoría independiente (revisor ≠ owner) |
|
|
330
|
+
|
|
331
|
+
**Una card NO se cierra sin evidencia suficiente de cada requisito obligatorio.** Los gates en verde no alcanzan: un proyecto puede compilar, pasar todos sus tests y tener la autenticación mal porque ningún test contemplaba ese escenario.
|
|
332
|
+
|
|
333
|
+
Cuando entregues, registrá la evidencia: `oficina_evidence` con `action: "add"`, diciendo QUÉ evidencia respalda QUÉ criterio.
|
|
223
334
|
|
|
224
335
|
---
|
|
225
336
|
|
|
226
|
-
##
|
|
337
|
+
## El costo y el freno
|
|
227
338
|
|
|
228
|
-
|
|
339
|
+
**[plugin]** `oficina_cost` muestra tokens y USD por card, agente y fase, con los presupuestos y cuánto falta para cada límite. El costo real lo reporta el motor; no se estima.
|
|
229
340
|
|
|
230
|
-
Si
|
|
341
|
+
Si la corrida se está descontrolando: `oficina_stop` con `action: "halt"`. La oficina deja de avanzar — no reanuda, no despacha, no gasta. Se reanuda con `action: "resume"`.
|
|
342
|
+
|
|
343
|
+
---
|
|
231
344
|
|
|
232
|
-
|
|
345
|
+
## Reglas de ejecución
|
|
346
|
+
|
|
347
|
+
1. **Nunca marques DONE sin los gates en verde.** Una card sin `gates.md` en PASS no está DONE, está mintiendo.
|
|
348
|
+
2. **Nunca marques DONE sin evidencia** de cada requisito obligatorio.
|
|
349
|
+
3. **Nunca revises tu propio trabajo.**
|
|
350
|
+
4. **Un subagente, una card, un artefacto.** Los subagentes son stateless: la delegación lleva todo el contexto.
|
|
351
|
+
5. **Los artefactos son la memoria.** Si no está en `.oficina/`, no existe.
|
|
352
|
+
6. **No toques fuera del scope.** Si hace falta, pedí la ampliación por el bus.
|
|
353
|
+
7. **Escalá cuando el caso lo pida**, no antes. 3 rechazos de la misma card = escalación con opciones concretas.
|
|
354
|
+
8. **Presupuesto**: 20 cards, 40 invocaciones, 20 spawns por corrida. Si se agota, informe parcial honesto y preguntá.
|
|
233
355
|
|
|
234
356
|
---
|
|
235
357
|
|
|
@@ -45,13 +45,22 @@ escalate_to: coordinator-flow
|
|
|
45
45
|
|
|
46
46
|
### Resolución: catálogo primero, factory después
|
|
47
47
|
|
|
48
|
-
El catálogo de agency-agents tiene **
|
|
48
|
+
El catálogo de agency-agents tiene **258 agentes resolubles en 18 divisiones** (la cifra vive en `docs/catalog-facts.json`, con su commit de origen, y el CI verifica que no se desactualice). La especialidad real de cada uno está en el **cuerpo** y en la `description` y el `vibe` del frontmatter:
|
|
49
49
|
|
|
50
50
|
- **Core Mission** → los subtítulos son la especialidad declarada
|
|
51
51
|
- **Technical Deliverables** → lo que sabe producir
|
|
52
52
|
- **Advanced Capabilities** → lo que maneja mejor
|
|
53
|
+
- **description + vibe** → líneas curadas a mano: la señal más limpia
|
|
53
54
|
|
|
54
|
-
El matcher pondera: nombre
|
|
55
|
+
El matcher pondera por señal: **identidad** (slug + nombre + `description` + `vibe`) 35% · **misión literal** 28% · **misión conceptual** 18% · **división** 10% · **cuerpo** 5%.
|
|
56
|
+
|
|
57
|
+
Además aplica tres correcciones que la bolsa de tokens no hace:
|
|
58
|
+
|
|
59
|
+
- **Sinónimos por capability** — `"e2e"` es `"end-to-end"`, pero `"e2e"` **no** es `"playwright"`. La taxonomía agrupa por concepto; los sinónimos no.
|
|
60
|
+
- **Lematización** — `"testing"` ~ `"test"`, `"validation"` ~ `"validate"`. El Commander pide capabilities en sus palabras y los agentes usan las suyas.
|
|
61
|
+
- **Focus de misión** — qué fracción de las misiones declaradas del agente es del dominio. Es lo que distingue a un especialista de un generalista que menciona la tool de pasada.
|
|
62
|
+
|
|
63
|
+
**Medido**: el matcher completo acierta el primer rol en el **71%** de 21 tareas de referencia, contra el **48%** de la versión anterior (`npm run bench:selection`). Se probó además una ponderación por IDF y **no se quedó**: bajaba el hit@1 a 67%.
|
|
55
64
|
|
|
56
65
|
```
|
|
57
66
|
1. CATALOG MATCH (preferido)
|