oficina-opencode 0.0.0-stage → 2.0.0
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/DESIGN.md +145 -0
- package/LICENSE +21 -0
- package/README.md +670 -2
- package/agents/oficina-architect.md +72 -0
- package/agents/oficina-commander.md +108 -0
- package/agents/oficina-critico.md +148 -0
- package/agents/oficina-director.md +160 -0
- package/agents/oficina-guardian.md +128 -0
- package/agents/oficina-integrator.md +98 -0
- package/agents/oficina-verificador.md +88 -0
- package/commands/oficina.md +36 -0
- package/dist/cli.d.ts +12 -0
- package/dist/cli.d.ts.map +1 -0
- package/dist/cli.js +394 -0
- package/dist/cli.js.map +1 -0
- package/dist/core/briefing.d.ts +115 -0
- package/dist/core/briefing.d.ts.map +1 -0
- package/dist/core/briefing.js +410 -0
- package/dist/core/briefing.js.map +1 -0
- package/dist/core/bus.d.ts +132 -0
- package/dist/core/bus.d.ts.map +1 -0
- package/dist/core/bus.js +250 -0
- package/dist/core/bus.js.map +1 -0
- package/dist/core/catalog.d.ts +303 -0
- package/dist/core/catalog.d.ts.map +1 -0
- package/dist/core/catalog.js +816 -0
- package/dist/core/catalog.js.map +1 -0
- package/dist/core/dispatch.d.ts +110 -0
- package/dist/core/dispatch.d.ts.map +1 -0
- package/dist/core/dispatch.js +301 -0
- package/dist/core/dispatch.js.map +1 -0
- package/dist/core/factory.d.ts +74 -0
- package/dist/core/factory.d.ts.map +1 -0
- package/dist/core/factory.js +243 -0
- package/dist/core/factory.js.map +1 -0
- package/dist/core/fsx.d.ts +39 -0
- package/dist/core/fsx.d.ts.map +1 -0
- package/dist/core/fsx.js +113 -0
- package/dist/core/fsx.js.map +1 -0
- package/dist/core/gates.d.ts +97 -0
- package/dist/core/gates.d.ts.map +1 -0
- package/dist/core/gates.js +467 -0
- package/dist/core/gates.js.map +1 -0
- package/dist/core/leases.d.ts +46 -0
- package/dist/core/leases.d.ts.map +1 -0
- package/dist/core/leases.js +94 -0
- package/dist/core/leases.js.map +1 -0
- package/dist/core/log.d.ts +30 -0
- package/dist/core/log.d.ts.map +1 -0
- package/dist/core/log.js +43 -0
- package/dist/core/log.js.map +1 -0
- package/dist/core/mesa.d.ts +82 -0
- package/dist/core/mesa.d.ts.map +1 -0
- package/dist/core/mesa.js +178 -0
- package/dist/core/mesa.js.map +1 -0
- package/dist/core/office.d.ts +208 -0
- package/dist/core/office.d.ts.map +1 -0
- package/dist/core/office.js +618 -0
- package/dist/core/office.js.map +1 -0
- package/dist/core/paths.d.ts +67 -0
- package/dist/core/paths.d.ts.map +1 -0
- package/dist/core/paths.js +136 -0
- package/dist/core/paths.js.map +1 -0
- package/dist/core/retry.d.ts +41 -0
- package/dist/core/retry.d.ts.map +1 -0
- package/dist/core/retry.js +86 -0
- package/dist/core/retry.js.map +1 -0
- package/dist/core/roster.d.ts +47 -0
- package/dist/core/roster.d.ts.map +1 -0
- package/dist/core/roster.js +146 -0
- package/dist/core/roster.js.map +1 -0
- package/dist/core/router.d.ts +67 -0
- package/dist/core/router.d.ts.map +1 -0
- package/dist/core/router.js +186 -0
- package/dist/core/router.js.map +1 -0
- package/dist/core/state.d.ts +89 -0
- package/dist/core/state.d.ts.map +1 -0
- package/dist/core/state.js +303 -0
- package/dist/core/state.js.map +1 -0
- package/dist/core/types.d.ts +333 -0
- package/dist/core/types.d.ts.map +1 -0
- package/dist/core/types.js +27 -0
- package/dist/core/types.js.map +1 -0
- package/dist/hooks/compacting.d.ts +18 -0
- package/dist/hooks/compacting.d.ts.map +1 -0
- package/dist/hooks/compacting.js +72 -0
- package/dist/hooks/compacting.js.map +1 -0
- package/dist/hooks/scopeGuard.d.ts +39 -0
- package/dist/hooks/scopeGuard.d.ts.map +1 -0
- package/dist/hooks/scopeGuard.js +114 -0
- package/dist/hooks/scopeGuard.js.map +1 -0
- package/dist/hooks/sessionIdle.d.ts +35 -0
- package/dist/hooks/sessionIdle.d.ts.map +1 -0
- package/dist/hooks/sessionIdle.js +110 -0
- package/dist/hooks/sessionIdle.js.map +1 -0
- package/dist/hooks/systemTransform.d.ts +18 -0
- package/dist/hooks/systemTransform.d.ts.map +1 -0
- package/dist/hooks/systemTransform.js +63 -0
- package/dist/hooks/systemTransform.js.map +1 -0
- package/dist/index.d.ts +36 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +103 -0
- package/dist/index.js.map +1 -0
- package/dist/tools/index.d.ts +22 -0
- package/dist/tools/index.d.ts.map +1 -0
- package/dist/tools/index.js +854 -0
- package/dist/tools/index.js.map +1 -0
- package/docs/ARCHITECTURE.md +258 -0
- package/docs/QUE-ES.md +337 -0
- package/examples/opencode.json +7 -0
- package/package.json +81 -4
- package/skills/oficina/README.md +120 -0
- package/skills/oficina/SKILL.md +251 -0
- package/skills/oficina/reference/mesh.md +345 -0
- package/skills/oficina/reference/protocol.md +342 -0
- package/skills/oficina/reference/roles.md +171 -0
- package/skills/oficina/reference/templates.md +278 -0
package/package.json
CHANGED
|
@@ -1,6 +1,83 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "oficina-opencode",
|
|
3
|
-
"version": "
|
|
4
|
-
"
|
|
5
|
-
"
|
|
6
|
-
|
|
3
|
+
"version": "2.0.0",
|
|
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
|
+
"license": "MIT",
|
|
6
|
+
"type": "module",
|
|
7
|
+
"engines": {
|
|
8
|
+
"node": ">=20"
|
|
9
|
+
},
|
|
10
|
+
"main": "./dist/index.js",
|
|
11
|
+
"types": "./dist/index.d.ts",
|
|
12
|
+
"exports": {
|
|
13
|
+
".": {
|
|
14
|
+
"types": "./dist/index.d.ts",
|
|
15
|
+
"import": "./dist/index.js"
|
|
16
|
+
},
|
|
17
|
+
"./cli": {
|
|
18
|
+
"types": "./dist/cli.d.ts",
|
|
19
|
+
"import": "./dist/cli.js"
|
|
20
|
+
}
|
|
21
|
+
},
|
|
22
|
+
"bin": {
|
|
23
|
+
"oficina": "./dist/cli.js"
|
|
24
|
+
},
|
|
25
|
+
"files": [
|
|
26
|
+
"dist",
|
|
27
|
+
"skills",
|
|
28
|
+
"agents",
|
|
29
|
+
"commands",
|
|
30
|
+
"docs",
|
|
31
|
+
"examples",
|
|
32
|
+
"DESIGN.md",
|
|
33
|
+
"README.md",
|
|
34
|
+
"LICENSE"
|
|
35
|
+
],
|
|
36
|
+
"keywords": [
|
|
37
|
+
"opencode",
|
|
38
|
+
"opencode-plugin",
|
|
39
|
+
"opencode-agent",
|
|
40
|
+
"agents",
|
|
41
|
+
"orchestration",
|
|
42
|
+
"multi-agent",
|
|
43
|
+
"agent-mesh",
|
|
44
|
+
"peer-to-peer",
|
|
45
|
+
"durable-execution",
|
|
46
|
+
"workflow",
|
|
47
|
+
"state-machine",
|
|
48
|
+
"cli",
|
|
49
|
+
"ai"
|
|
50
|
+
],
|
|
51
|
+
"author": "Marcos <casselsmarcos1@gmail.com>",
|
|
52
|
+
"repository": {
|
|
53
|
+
"type": "git",
|
|
54
|
+
"url": "git+https://github.com/SOCRAMbt/El-ltimoTPP.git"
|
|
55
|
+
},
|
|
56
|
+
"homepage": "https://github.com/SOCRAMbt/El-ltimoTPP#readme",
|
|
57
|
+
"bugs": {
|
|
58
|
+
"url": "https://github.com/SOCRAMbt/El-ltimoTPP/issues"
|
|
59
|
+
},
|
|
60
|
+
"publishConfig": {
|
|
61
|
+
"access": "public"
|
|
62
|
+
},
|
|
63
|
+
"scripts": {
|
|
64
|
+
"build": "tsc -p tsconfig.build.json",
|
|
65
|
+
"dev": "tsc -p tsconfig.build.json --watch",
|
|
66
|
+
"typecheck": "tsc --noEmit",
|
|
67
|
+
"pretest": "npm run build",
|
|
68
|
+
"test": "vitest run",
|
|
69
|
+
"test:watch": "vitest",
|
|
70
|
+
"coverage": "npm run build && vitest run --coverage",
|
|
71
|
+
"prepublishOnly": "npm run typecheck && npm run test && npm run build"
|
|
72
|
+
},
|
|
73
|
+
"dependencies": {
|
|
74
|
+
"@opencode-ai/plugin": "^1.15.11",
|
|
75
|
+
"zod": "4.1.8"
|
|
76
|
+
},
|
|
77
|
+
"devDependencies": {
|
|
78
|
+
"@types/node": "^24.12.2",
|
|
79
|
+
"typescript": "^5.8.2",
|
|
80
|
+
"vitest": "^3.2.4",
|
|
81
|
+
"@vitest/coverage-v8": "^3.2.4"
|
|
82
|
+
}
|
|
83
|
+
}
|
|
@@ -0,0 +1,120 @@
|
|
|
1
|
+
# 🏢 OFICINA — Oficina de Agents
|
|
2
|
+
|
|
3
|
+
Un objetivo entra por la puerta. La oficina lo ejecuta, se auto-verifica, y entrega evidencia.
|
|
4
|
+
|
|
5
|
+
## Qué es
|
|
6
|
+
|
|
7
|
+
Un sistema de orquestación de agentes **nativo de OpenCode**. Combina:
|
|
8
|
+
|
|
9
|
+
- **agency-agents** → los especialistas (`code-explorer`, `code-architect`) y el patrón de subagentes
|
|
10
|
+
- **AgentTeams** → la disciplina de coordinación: cards con owner, scope, acceptance, gate, Kanban, merge gates
|
|
11
|
+
- **Skills nuevas** → `multi-reviewer-patterns` (dimensiones + dedup + severidad), `verification-loop` (6 fases), `deep-agents-orchestration` (subagentes stateless), `secure-code-review` (trust boundaries)
|
|
12
|
+
|
|
13
|
+
## El problema que resuelve
|
|
14
|
+
|
|
15
|
+
| Falla común | Mecanismo de OFICINA |
|
|
16
|
+
|---|---|
|
|
17
|
+
| Tenés que dar todas las instrucciones | El **Director** descompone solo |
|
|
18
|
+
| El agent "no cumple" | Cada card tiene **acceptance criteria** + **gate ejecutable** |
|
|
19
|
+
| Los subagentes se desaprovechan | Tabla de **enrutado determinista** rol→agente |
|
|
20
|
+
| Hay que repetir el contexto | **Ledger de contexto** en disco (`.oficina/context.md`) |
|
|
21
|
+
| No se coordinan entre sí | **Handoff por artefactos** — el disco es el bus de mensajes |
|
|
22
|
+
| Son monotonos | **Revisor distinto del autor** + rotación de owner y de dimensión |
|
|
23
|
+
| Nadie los orquesta | El **Director** corre el loop, detecta estancamiento, escala |
|
|
24
|
+
|
|
25
|
+
## Uso
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
# Desde la raíz de tu proyecto
|
|
29
|
+
/oficina Agregar autenticación JWT con refresh tokens
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
El comando carga la skill `oficina` y arranca el ciclo. No pide permiso: informa y sigue.
|
|
33
|
+
|
|
34
|
+
### Comandos de control (durante la corrida)
|
|
35
|
+
|
|
36
|
+
| Quiero | Digo |
|
|
37
|
+
|---|---|
|
|
38
|
+
| Ver el estado | `/oficina status` |
|
|
39
|
+
| Cambiar de rumbo | `/oficina cambiar a <nuevo objetivo>` |
|
|
40
|
+
| Pausar | `/oficina pausar` |
|
|
41
|
+
| Detener | `/oficina stop` |
|
|
42
|
+
|
|
43
|
+
## Los 7 roles
|
|
44
|
+
|
|
45
|
+
| Rol | Agente | Puede aprobar? |
|
|
46
|
+
|---|---|---|
|
|
47
|
+
| Director | `oficina-director` | No revisa técnico |
|
|
48
|
+
| Explorador | `code-explorer` | No |
|
|
49
|
+
| Arquitecto | `code-architect` | No |
|
|
50
|
+
| Implementador | `general` | No |
|
|
51
|
+
| **Crítico** | `oficina-critico` | Sí (revisión de card) |
|
|
52
|
+
| **Guardián** | `oficina-guardian` | Sí (gate seguridad) |
|
|
53
|
+
| **Verificador** | `oficina-verificador` | Sí (gate técnico) |
|
|
54
|
+
|
|
55
|
+
**Nadie se auto-aprueba.** El Crítico de una card es siempre distinto de su owner.
|
|
56
|
+
|
|
57
|
+
## El ciclo
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
OBJETIVO → PLAN (Director)
|
|
61
|
+
↓
|
|
62
|
+
STANDUP (elegir card)
|
|
63
|
+
↓
|
|
64
|
+
TRABAJO (owner → handoff.md + evidence.md)
|
|
65
|
+
↓
|
|
66
|
+
AUTO-REVIEW (oficina-critico → review.md)
|
|
67
|
+
↓
|
|
68
|
+
GATES (oficina-verificador + oficina-guardian → gates.md)
|
|
69
|
+
↓
|
|
70
|
+
┌────────┴────────┐
|
|
71
|
+
DONE REWORK → REPLAN → ESCALADA
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Garantías
|
|
75
|
+
|
|
76
|
+
1. **Ninguna card DONE sin `gates.md` en PASS** (técnico Y seguridad).
|
|
77
|
+
2. **Ningún trabajo se auto-aprueba.**
|
|
78
|
+
3. **Nada se pierde**: 35+ artefactos por corrida, todo en `.oficina/`.
|
|
79
|
+
4. **La oficina se audita a sí misma**: el Verificador marca en el diff review cualquier archivo tocado fuera de scope.
|
|
80
|
+
5. **Escala con opciones**, nunca con monólogo. 3 rechazos de la misma card = escalación.
|
|
81
|
+
|
|
82
|
+
## Estructura de una corrida
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
<proyecto>/.oficina/
|
|
86
|
+
├── board.md # Kanban legible por humanos
|
|
87
|
+
├── state.json # estado legible por máquinas (retoma tras reinicio)
|
|
88
|
+
├── context.md # ledger de conocimiento acumulado
|
|
89
|
+
└── artifacts/
|
|
90
|
+
└── T-00/
|
|
91
|
+
├── handoff.md # qué hizo el owner
|
|
92
|
+
├── evidence.md # salida real de los comandos
|
|
93
|
+
├── review.md # veredicto del crítico
|
|
94
|
+
├── gates.md # PASS/FAIL técnico y seguridad
|
|
95
|
+
├── decision.md # decisión del director
|
|
96
|
+
└── delegation.md # prompt de delegación (para relanzar)
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
## Requisitos
|
|
100
|
+
|
|
101
|
+
- OpenCode con `experimental.subagent_depth: 3` (ya configurado en `~/.config/opencode/opencode.json`) — sin esto los subagentes no pueden delegar.
|
|
102
|
+
- Correr `/oficina` **desde la raíz del proyecto**.
|
|
103
|
+
|
|
104
|
+
## Costos
|
|
105
|
+
|
|
106
|
+
Presupuesto por corrida: **20 cards, 40 invocaciones de subagente**. Una corrida típica de un bug acotado consume 5 cards / 22 agentes. Si se agota, la oficina entrega informe parcial honesto y pregunta.
|
|
107
|
+
|
|
108
|
+
## Archivos
|
|
109
|
+
|
|
110
|
+
| Ruta | Qué es |
|
|
111
|
+
|---|---|
|
|
112
|
+
| `~/.config/opencode/skills/oficina/SKILL.md` | La skill (protocolo) |
|
|
113
|
+
| `~/.config/opencode/skills/oficina/reference/roles.md` | Fichas de rol + tabla de enrutado |
|
|
114
|
+
| `~/.config/opencode/skills/oficina/reference/protocol.md` | Handoff, gates, escalamiento, checkpoints |
|
|
115
|
+
| `~/.config/opencode/skills/oficina/reference/templates.md` | Templates + prompts de delegación |
|
|
116
|
+
| `~/.config/opencode/agents/oficina-director.md` | El Director |
|
|
117
|
+
| `~/.config/opencode/agents/oficina-critico.md` | El Crítico |
|
|
118
|
+
| `~/.config/opencode/agents/oficina-guardian.md` | El Guardián (gate seguridad) |
|
|
119
|
+
| `~/.config/opencode/agents/oficina-verificador.md` | El Verificador (gate técnico) |
|
|
120
|
+
| `~/.config/opencode/commands/oficina.md` | El comando `/oficina` |
|
|
@@ -0,0 +1,251 @@
|
|
|
1
|
+
---
|
|
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, delega a especialistas con ficha normalizada, 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é". 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
|
+
---
|
|
5
|
+
|
|
6
|
+
# OFICINA — Oficina de Agents
|
|
7
|
+
|
|
8
|
+
Un objetivo entra por la puerta. La oficina lo ejecuta, se auto-verifica, y entrega evidencia.
|
|
9
|
+
|
|
10
|
+
## Dos motores, un solo protocolo
|
|
11
|
+
|
|
12
|
+
| | **Con plugin** (motor duro) | **Sin plugin** (fallback) |
|
|
13
|
+
|---|---|---|
|
|
14
|
+
| Estado | Máquina de estados en TypeScript | `state.json` markdown + JSON |
|
|
15
|
+
| Gates | Comandos reales, exit codes interpretados por código | El modelo corre los comandos y pega la salida |
|
|
16
|
+
| Enforcement | Guard de scope: no se puede editar fuera del scope | Disciplina del prompt |
|
|
17
|
+
| Loop | Hook `session.idle` → la oficina sigue sola | El modelo decide si sigue |
|
|
18
|
+
| Invariantes | `assertInvariants` en código | Regla dura en el prompt |
|
|
19
|
+
| Comunicación | Bus de mensajes con TTL/ack/idempotencia | Artefactos en disco, unidireccional |
|
|
20
|
+
|
|
21
|
+
**Preferí el plugin.** Si las tools `oficina_*` están disponibles, usá el motor duro: los invariantes dejan de ser sugerencias.
|
|
22
|
+
|
|
23
|
+
El protocolo de este documento sirve para los dos. Las secciones marcadas **[plugin]** solo aplican con el plugin instalado.
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## Por qué existe
|
|
28
|
+
|
|
29
|
+
| Falla | Cómo la resuelve OFICINA |
|
|
30
|
+
|---|---|
|
|
31
|
+
| 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 | Tabla de **enrutado determinista** + resolución desde el catálogo real de agency-agents. |
|
|
34
|
+
| 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**: pueden pedir ayuda, delegar y contestar. |
|
|
36
|
+
| Son monotonos | **Revisor distinto del autor** + rotación de owner y de dimensión. |
|
|
37
|
+
| Nadie los orquesta | **3 coordinadores** con dominios particionados y arbitraje explícito. |
|
|
38
|
+
| La IA dice "terminé" sin terminar | **[plugin]** Hook de auto-continuación: el estado decide, no la confianza. |
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## Las 4 capas
|
|
43
|
+
|
|
44
|
+
```
|
|
45
|
+
CAPA 3 — COORDINACIÓN Comandante · Arquitecto · Integrador
|
|
46
|
+
CAPA 2 — BUS bus/<canal>/<seq>-<msgid>.json · inbox/ · leases/
|
|
47
|
+
CAPA 1 — ESPECIALISTAS fichas normalizadas (agency-agents o factory)
|
|
48
|
+
CAPA 0 — ROSTER/FICHAS resolución de roles + matching de capabilities
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
Detalle completo en `reference/mesh.md`.
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
## Los 3 coordinadores
|
|
56
|
+
|
|
57
|
+
Un solo coordinador es cuello de botella y punto único de falla. Tres, con dominios particionados:
|
|
58
|
+
|
|
59
|
+
| | COMANDANTE | ARQUITECTO | INTEGRADOR |
|
|
60
|
+
|---|---|---|---|
|
|
61
|
+
| **Dominio** | Scope, objetivo, prioridades | Decisiones técnicas cross-cutting | DAG, leases, gates, calidad |
|
|
62
|
+
| **Responde** | ¿esto está en el objetivo? | ¿qué patrón usamos? | ¿quién tiene T-07? ¿pasó el gate? |
|
|
63
|
+
| **Detecta** | Scope creep, requisitos no cubiertos | Drift arquitectónico, decisiones inconsistentes | Deadlock, starvation, gates rojos, doble-claim |
|
|
64
|
+
| **NO hace** | Diseñar ni revisar código | Escribir código | Escribir código |
|
|
65
|
+
|
|
66
|
+
**Arbitraje**: scope → Comandante. Patrón/contrato → Arquitecto. Flujo/lease/gate → Integrador. Si cruza dos dominios: el Arquitecto decide lo técnico con visto bueno del Comandante; si el Integrador detecta deadlock, reparte y avisa.
|
|
67
|
+
|
|
68
|
+
**Al usuario solo se escala** si el coordinador no puede decidir (criterio de producto), si el conflicto cruza dominios sin resolución, o si se agotó el presupuesto.
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
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
|
+
## Los roles
|
|
123
|
+
|
|
124
|
+
| Rol | Agente | Puede aprobar? |
|
|
125
|
+
|---|---|---|
|
|
126
|
+
| Comandante | `oficina-commander` | No revisa técnico |
|
|
127
|
+
| Arquitecto | `oficina-architect` | No revisa técnico |
|
|
128
|
+
| Integrador | `oficina-integrator` | No revisa técnico |
|
|
129
|
+
| Explorador | `code-explorer` | No |
|
|
130
|
+
| Arquitecto (rol) | `code-architect` | No |
|
|
131
|
+
| Implementador | `general` | No |
|
|
132
|
+
| **Crítico** | `oficina-critico` | Sí (revisión de card) |
|
|
133
|
+
| **Guardián** | `oficina-guardian` | Sí (gate seguridad) |
|
|
134
|
+
| **Verificador** | `oficina-verificador` | Sí (gate técnico) |
|
|
135
|
+
|
|
136
|
+
**Regla dura:** el que implementa nunca revisa su propio trabajo.
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Resolver roles: catálogo → factory → panel
|
|
141
|
+
|
|
142
|
+
**[plugin]** `oficina_brief` muestra el panel sin desplegar; `oficina_ficha` además despliega el agente con su briefing.
|
|
143
|
+
|
|
144
|
+
**1. Catálogo primero.** El repo de agency-agents tiene **306 agentes en 25 divisiones**. La especialidad real de cada uno está en el **cuerpo** (Core Mission, Technical Deliverables, Advanced Capabilities), no en el `description`. El matcher pondera el nombre del rol (40%), la misión literal (35%) y la misión conceptual (20%).
|
|
145
|
+
|
|
146
|
+
**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
|
+
|
|
148
|
+
**3. Panel, no un solo agente.** Un objetivo casi nunca es de un solo dominio. El panel devuelve:
|
|
149
|
+
|
|
150
|
+
- **primario** — el mejor match. Se lleva la card.
|
|
151
|
+
- **complementos** — los que cubren lo que el primario NO cubre. Son sus pares en el bus.
|
|
152
|
+
- **sin cubrir** — lo que nadie cubre. Señal de que la card debería partirse en dos.
|
|
153
|
+
|
|
154
|
+
**Nunca fuerces un mal match.** Si nadie cubre una capacidad, se fabrica el rol o se pide ayuda. Un rol medio-tono en el equipo arruina más de lo que aporta.
|
|
155
|
+
|
|
156
|
+
**Sin plugin**: la tabla de `reference/roles.md`.
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
## El briefing: qué recibe cada agente
|
|
161
|
+
|
|
162
|
+
**[plugin]** Todo agente desplegado recibe un briefing de **10 secciones en orden fijo** —de lo más estable a lo más cambiante— y **4 artefactos** en `.oficina/fichas/<agentId>/`:
|
|
163
|
+
|
|
164
|
+
| Artefacto | Contenido |
|
|
165
|
+
|---|---|
|
|
166
|
+
| `ficha.md` | Quién sos: rol, especialidad, origen, vibe |
|
|
167
|
+
| `misiones.md` | Tu misión · lo que ya sabés · lo que NO sabés |
|
|
168
|
+
| `protocolo.md` | Cómo trabajás · tu territorio · qué se espera · límites · éxito |
|
|
169
|
+
| `bus.md` | Tu canal: dónde, formato, TTLs, cómo acusar recibo |
|
|
170
|
+
|
|
171
|
+
**El agente no arranca sin `misiones.md`. Nunca.**
|
|
172
|
+
|
|
173
|
+
**Mínimo**: las 10 secciones son requeridas. Si alguna queda vacía, el briefing se marca `INCOMPLETO` y el agente no se despliega. Un briefing a medio llenar produce un agente a medio informado, que es peor que no tener agente.
|
|
174
|
+
|
|
175
|
+
La sección *"lo que ya sabés"* se alimenta del **ledger** (`.oficina/context.md`): decisiones, restricciones, piezas construidas y trampas. Es lo que evita repetir lo ya decidido.
|
|
176
|
+
|
|
177
|
+
Detalle completo en `reference/mesh.md`.
|
|
178
|
+
|
|
179
|
+
---
|
|
180
|
+
|
|
181
|
+
## Pedir ayuda y delegar
|
|
182
|
+
|
|
183
|
+
**[plugin]** `oficina_bus` con `action: "help"`.
|
|
184
|
+
|
|
185
|
+
El que recibe **hace su propio triage** — no acepta por cortesía:
|
|
186
|
+
|
|
187
|
+
1. ¿Entiendo la tarea? → si no, `HELP_DECLINE` + explicar
|
|
188
|
+
2. ¿Está en mi scope? → si no, `HELP_DECLINE` + sugerir a quién
|
|
189
|
+
3. ¿Puedo hacerlo ya sin romper mi card? → si no, `HELP_DECLINE` + "cuando termine"
|
|
190
|
+
4. ¿Tengo el contexto? → si no, `HELP_QUESTION` por el bus
|
|
191
|
+
5. ¿Vale la pena? → si no, `HELP_DECLINE` + alternativa
|
|
192
|
+
6. ¿Tengo presupuesto? → si no, `HELP_DECLINE` + "sin presupuesto"
|
|
193
|
+
|
|
194
|
+
**Anti-deadlock**: máximo 2 saltos en una cadena de ayuda; después escala al Integrador.
|
|
195
|
+
**Anti-monotonía**: si el par A↔B ya se ayudaron 2 veces, el tercer pedido va a un tercero.
|
|
196
|
+
|
|
197
|
+
**[plugin]** Delegar un rol nuevo: `oficina_spawn`. El Integrador aprueba o rechaza. Nunca clones agentes por tu cuenta.
|
|
198
|
+
|
|
199
|
+
**Sin plugin**: `reference/protocol.md`.
|
|
200
|
+
|
|
201
|
+
---
|
|
202
|
+
|
|
203
|
+
## El pool idle
|
|
204
|
+
|
|
205
|
+
Cuando un agente termina su objetivo, entra al pool y puede ayudar de tres modos:
|
|
206
|
+
|
|
207
|
+
1. Atender un `HELP_REQUEST` dirigido
|
|
208
|
+
2. Atender un broadcast (`to: ["*"]`) — el primero que acepta toma el lease
|
|
209
|
+
3. **Claim proactivo** — si hay cards sin owner y tu capability matchea, la reclamás
|
|
210
|
+
|
|
211
|
+
El modo 3 es lo que convierte la oficina de "N tareas en paralelo" a "N agentes que se acomodan solos según la carga".
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## Reglas de ejecución
|
|
216
|
+
|
|
217
|
+
1. **Nunca marques DONE sin los gates en verde.** Una card sin `gates.md` en PASS no está DONE, está mintiendo.
|
|
218
|
+
2. **Nunca revises tu propio trabajo.**
|
|
219
|
+
3. **Un subagente, una card, un artefacto.** Los subagentes son stateless: la delegación lleva todo el contexto.
|
|
220
|
+
4. **Los artefactos son la memoria.** Si no está en `.oficina/`, no existe.
|
|
221
|
+
5. **Escalá cuando el caso lo pida**, no antes. 3 rechazos de la misma card = escalación con opciones concretas.
|
|
222
|
+
6. **Presupuesto**: 20 cards, 40 invocaciones, 20 spawns por corrida. Si se agota, informe parcial honesto y preguntá.
|
|
223
|
+
|
|
224
|
+
---
|
|
225
|
+
|
|
226
|
+
## Umbral de calidad
|
|
227
|
+
|
|
228
|
+
De `verification-loop`: build → type check → lint → tests → security grep → diff review.
|
|
229
|
+
|
|
230
|
+
Si el proyecto no tiene tooling para alguna fase, se marca `N/A` explícito — nunca se saltea en silencio.
|
|
231
|
+
|
|
232
|
+
**[plugin]** El escaneo de secretos corre en código y **redacta** el valor: un log de gate que imprime la credencial completa la acaba de filtrar.
|
|
233
|
+
|
|
234
|
+
---
|
|
235
|
+
|
|
236
|
+
## Cuándo NO usar OFICINA
|
|
237
|
+
|
|
238
|
+
- Tarea de una sola acción.
|
|
239
|
+
- El usuario pidió explícitamente hacerlo vos directo.
|
|
240
|
+
- Exploración sin objetivo claro — primero brainstorming, después OFICINA.
|
|
241
|
+
|
|
242
|
+
En esos casos, hacelo vos. OFICINA es para trabajo multi-paso con objetivo verificable.
|
|
243
|
+
|
|
244
|
+
---
|
|
245
|
+
|
|
246
|
+
## Referencias
|
|
247
|
+
|
|
248
|
+
- `reference/mesh.md` — bus, fichas, roster, leases, spawn policy, idle pool (v2)
|
|
249
|
+
- `reference/roles.md` — fichas de rol, criterios de enrutado, rotación
|
|
250
|
+
- `reference/protocol.md` — handoff, gates, escalamiento, checkpoints, reintentos
|
|
251
|
+
- `reference/templates.md` — templates de board, state.json, handoff, review, gates, informe
|