@trycore/spec-build-harness 0.8.5 → 0.11.0

package/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "trycore-spec-build-harness",
   "displayName": "Trycore — Spec & Build Harness",
-  "version": "0.8.5",
+  "version": "0.11.0",
   "description": "Arnés de construcción de dos loops (slice por épica + release gate) para Claude Code, con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "author": {
     "name": "Trycore",

package/GOVERNANCE.md

@@ -7,12 +7,14 @@ evoluciona con el modelo y el proyecto. No es "instalar y olvidar".
 | Capa | Artefactos | Ubicación |
 |---|---|---|
 | Contexto | sección Construcción de CLAUDE.md, `openspec/project.md` | raíz / `openspec/` |
-| Estado | `build-state.json` (+schema, README) | `.claude/state/` |
+| Estado (modo `legacy`, default) | `build-state.json` (+schema, README) | `.claude/state/` |
+| Cliente runtime (modo `dual`/`runtime`, opt-in — beta) | `runtime.credentials` (0600), `context.lock`, `runtime-projection.json`, `outbox/`; `slice-ops.sh`/`release-ops.sh` (13 subcomandos) | `.claude/state/`, `.claude/hooks/build/` |
 | Agentes | 14 agentes de build | `.claude/agents/build/` |
-| Hooks | settings.json + 13 scripts | `.claude/settings.json`, `.claude/hooks/build/` |
+| Hooks | settings.json + 19 scripts (15 registrados + 4 invocados: `reconcile-build-state.py`, `context-sync.sh`, `heartbeat.sh` como daemon, `statusline-bridge.sh` como comando `statusLine`) | `.claude/settings.json`, `.claude/hooks/build/` |
 | Skill | `building-a-slice` (+11 refs · `workflows/`) · `releasing-a-version` (`workflows/`) · `building-a-micro-change` (carril ligero de mantenimiento) · `managing-parallel-front` (front paralelo inter-épica) · `prototyping-screens` (prototipo HTML de referencia) | `.claude/skills/` |
-| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:prototype` · `/build:slice` · `/build:release` · `/build:work` · `/build:resume` · `/build:front` | `.claude/commands/` |
-| Config | allowlist de stack | `.claude/config/stack-allowlist.json` |
+| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:prototype` · `/build:slice` · `/build:release` · `/build:work` · `/build:resume` · `/build:front` · `/build:claim` · `/build:status` · `/build:escalate` | `.claude/commands/` |
+| Config | allowlist de stack, `build-config.json` (umbrales de contexto + `runtime.mode`) | `.claude/config/` |
+| CLI (`trycore-build`) | `init`/`update`/`status`/`doctor`/`uninstall`/`migrate` | `src/` → `dist/` (este repo, no el consumidor) |
 
 ## Fases de activación (`harness_phase`)
 - **authoring** (actual): aún no hay `package.json`. Activos: `gitflow-guard`, `load-build-state`,
@@ -114,6 +116,27 @@ Cambios a la política de construcción (unidad de trabajo, gates, DoR/DoD). Apr
   el nº de escenarios G/W/T con `complejidad` en vez de exigir 3–5 fijos. La regla "épica = unidad"
   se mantiene intacta para producto. Origen: auditoría del arnés vs. crítica de sobre-configuración.
 
+## Modo runtime (Agent Orchestrator Runtime) — beta, opt-in
+
+Desde EP-OR-08 (sub-slices A-E, código completo en `main`), el arnés puede correr como cliente de
+un **Agent Orchestrator Runtime** remoto (repo hermano `trycore-ia-hub`) en vez de (o además de)
+`build-state.json`. Gobernanza específica de esta capa:
+
+- **El agente propone/reporta; un ADMIN publica/importa.** Ningún acto de agente sube contexto
+  (`POST …/context/agent-proposals`, nunca `…/context/proposals`), importa el grafo de épicas
+  (`scripts/lib/graph-bundle.py` prepara, no sube) ni cierra una release o un front paralelo — esas
+  son superficies humanas en la consola del hub. Detalle → `docs/runtime/protocolo-cliente-runtime.md`.
+- **`legacy` es el default y el único camino con soporte completo.** `dual`/`runtime` se activan
+  explícitamente (`trycore-build init --runtime-url --runtime-token`); nadie los activa por decisión
+  del modelo. En `dual`, `hooks/build/dual-compare.sh` mide discrepancias fichero↔servidor — es el
+  instrumento de medición del piloto, no un gate.
+- **El corte (retirar `legacy`, reescribir METODOLOGIA/CLAUDE.md/`state/README.md` como si el
+  runtime fuera canónico) requiere DRI + un piloto real sin discrepancias durante 1 sprint**
+  (`docs/runtime/plan-migracion-harness-v0.9.md` §2.3) — no es una decisión de PR aislado. La
+  versión `0.9.0` ya publica el cliente en beta/opt-in (ver CHANGELOG); el corte es una release
+  posterior y distinta.
+- **Cómo migrar un proyecto al modo dual** → `docs/runtime/guia-modo-dual-y-migracion.md`.
+
 ## Extensiones futuras (no implementadas)
 - **Construcción en paralelo** de slices con `superpowers:using-git-worktrees` + orquestación
   multi-worktree (hoy el modelo es **secuencial** por decisión de proyecto). El `build-state.json`

package/INSTALL.md

@@ -11,7 +11,7 @@ Es el **compañero** de [`@trycore/spec-product-flow`](https://www.npmjs.com/pac
 | CLI (bin) | `trycore-build` |
 | Plugin | `trycore-spec-build-harness` |
 | Marketplace | `trycore-build` |
-| Versión | `0.7.0` |
+| Versión | ver `VERSION` en la raíz del paquete (`trycore-build --version`) |
 
 > **¿Solo quieres empezar ya?** El [Quickstart](docs/getting-started.md) te lleva de 0 a tu primer slice en pocos comandos. Esta guía es la **referencia detallada** (flags, CI, plugin, troubleshooting).
 
@@ -30,11 +30,11 @@ npm install -g @trycore/spec-build-harness
 Esto expone el binario `trycore-build`. Comprueba la versión:
 
 ```bash
-trycore-build --version    # → 0.7.0
+trycore-build --version
 trycore-build --help
 ```
 
-Comandos disponibles: `init` · `update` · `status` · `uninstall` · `doctor`.
+Comandos disponibles: `init` · `update` · `status` · `uninstall` · `doctor` · `migrate` (beta — ver §9).
 
 > Requiere Node `>=18.0.0` (`engines` del paquete).
 
@@ -87,9 +87,9 @@ Qué hace `init`:
 1. **Verifica requisitos duros** (a menos que uses `--skip-doctor`).
 2. **Siembra los assets** en rutas nativas de Claude Code:
    - `.claude/agents/build/` — 14 agentes.
-   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (9 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:prototype`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`).
+   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (12 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:prototype`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`, `/build:claim`, `/build:status`, `/build:escalate`).
    - `.claude/skills/` — 16 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `prototyping-screens`, `openspec-*`).
-   - `.claude/hooks/build/` — 13 hooks (bash + python).
+   - `.claude/hooks/build/` — 19 hooks (bash + python; 6 son del cliente runtime opt-in — §9).
 3. **Siembra el estado**: `state/build-state.schema.json` y `state/README.md` se versionan;
    `state/build-state.json` se siembra **vacío y nunca se sobrescribe** (va al `.gitignore`).
 4. **Siembra `config/stack-allowlist.json`** (artefacto del consumidor; lo puebla `/build:onboard`).
@@ -114,6 +114,9 @@ Al terminar imprime el siguiente paso: abrir Claude Code y ejecutar `/build:onbo
 | `--runtime <semver>` | Semver del runtime (ej. `">=18.18"`) |
 | `--prd-path <path>` | Ruta#ancla del PRD técnico (fuente del allowlist) |
 | `--yes` | No interactivo: usa defaults para el stack (CI-safe) |
+| `--runtime-url <url>` | (Beta — §9.) URL del Agent Orchestrator Runtime; junto con `--runtime-token`, registra el agente. |
+| `--runtime-token <token>` | (Beta — §9.) Token de proyecto emitido por un ADMIN en la consola del hub. |
+| `--runtime-mode <mode>` | (Beta — §9.) `legacy`\|`dual`\|`runtime` (default `dual` si diste URL+token). |
 
 ### Modo `--copy` (Windows / sandbox)
 
@@ -297,6 +300,25 @@ del consumidor y no se borran.
 
 ---
 
+## 9. Modo runtime (beta, opcional)
+
+El arnés puede correr el mismo pipeline contra un **Agent Orchestrator Runtime** remoto en vez de
+(o además de) `build-state.json`. **Es opt-in**: sin las flags de abajo, `init` deja el proyecto en
+modo `legacy` (default, sin cambios). Requiere un runtime corriendo y un **token de proyecto**
+emitido por un ADMIN en la consola del hub.
+
+```bash
+trycore-build init --runtime-url "https://tu-runtime.example.com" --runtime-token "<token>"
+trycore-build doctor    # sección "Runtime": token, conectividad, lock, cola offline
+trycore-build status    # sección "Runtime": conexión, proyección, contexto sincronizado
+trycore-build migrate --project-ref "<nombre-en-el-hub>"   # bundle de estado histórico para un ADMIN
+```
+
+Guía completa (los tres modos, cómo activar/verificar/volver a legacy, cuándo se corta) →
+[`docs/runtime/guia-modo-dual-y-migracion.md`](docs/runtime/guia-modo-dual-y-migracion.md).
+
+---
+
 > **Nota de gobierno:** `METODOLOGIA.md` es la fuente de verdad del arnés. Si una skill contradice
 > la metodología, **gana la metodología** (regla dura del bloque `CLAUDE.md`). El core es 100%
 > agnóstico al proyecto; el ejemplo de referencia vive en `docs/examples/reference/`.

package/METODOLOGIA.md

@@ -105,6 +105,16 @@ sola pasada**: a medida que crece el contexto, la atención se degrada ("context
    actual, solo la hace reproducible. Los workflows quedan **acotados a tres hogares** (fan-out de exploración,
    conducción del verificador adversarial, y el Release Gate del §5) y **prohibidos** en el camino caliente de
    las fases del inner loop.
+   **La verificación adversarial es incremental y acotada.** Cada item de `wiring_checklist[]` cuya
+   evidencia fue reproducida lleva `verified_at_sha` (lo estampa el `build-orchestrator` al aplicar el
+   veredicto); en pasadas posteriores el verificador re-ejecuta **solo** los items cuyo código cambió
+   desde su sha (`git diff <sha>..HEAD -- <rutas del item>`) — el resto conserva veredicto («sin
+   cambios desde <sha>»). Pasada completa solo la primera (y, opcionalmente, una final). Y el bucle
+   tiene **condición de parada**: **máximo 2 pasadas completas por slice** — los hallazgos de la 2ª en
+   código nuevo del cierre se arreglan y se cierran con mutación verificada, sin tercera pasada; la
+   revisión independiente restante se **difiere explícitamente al Release Gate**, declarada en el PR
+   (gates honestos). Excepción única: un hallazgo ALTA en código **preexistente** durante la 2ª pasada
+   habilita una pasada extra **acotada** a ese frente.
 4. **Producto completo, no MVP (anti-deriva).** El alcance acordado se construye **entero**. **Recortar o
    diferir es bloqueante explícito** que exige acuerdo del equipo — **nunca** una decisión del modelo. No
    se "deja para después" ni se deriva en lo complejo. La verificación es **ejecutada, no por inspección**
@@ -232,7 +242,11 @@ las revisiones pesadas **no** se piden aquí (van al Release Gate):
   no toca UI.
 - `wiring_verified` — el `wiring-adversarial-verifier` (subagente **independiente**, contexto virgen)
   intentó refutar el slice y no halló huecos. **Prerequisito duro de `dod`**: el DoD declarativo del
-  gatekeeper es un **piso, no el arreglo** (ver §1-bis).
+  gatekeeper es un **piso, no el arreglo** (ver §1-bis). El bucle adversarial tiene **condición de
+  parada** (§1-bis): máximo **2 pasadas completas** por slice; hallazgos de la 2ª en código nuevo del
+  cierre → mutación verificada sin tercera pasada; lo restante se **difiere declarado en el PR** al
+  Release Gate. Ese diferimiento es **sancionado por la metodología** (no viola «producto completo,
+  no MVP»: no recorta alcance — difiere una *re-revisión* al gate que ya existe para custodiarla).
 - OpenSpec: todas las tasks `[x]`; el archive del change va **en el mismo PR**.
 - Back-reference del change añadida en la épica y en cada HU de `hus[]`.
 - Hooks verdes (automáticos, **no** son gates de agente): `lint-typecheck.sh`, `stack-guard.sh`,
@@ -435,6 +449,36 @@ la capa de arquitectura, `/build:architect` lo **consolida** (añade `allow`/`ra
 los ADRs; **nunca** borra entradas del consumidor ni pisa `source`, que sigue apuntando al PRD).
 `uninstall` preserva `state/` y `config/`.
 
+## 7-bis. Modo runtime (opcional, piloto — EP-OR-08)
+
+Las reglas de §7 (leer antes de actuar, una transición = una escritura, gates monótonos, `null`
+para N/A, archivar, dos loops) **no cambian**. Lo que puede cambiar es **el medio**: en vez de
+leer/escribir `build-state.json` directamente, el pipeline puede correr contra el **Agent
+Orchestrator Runtime** (servidor remoto, repo hermano `trycore-ia-hub`), que valida las
+transiciones server-side y es la fuente de verdad para la flota (varios agentes, un proyecto).
+
+- **Lo decide `config/build-config.json#runtime.mode`** (`legacy` default | `dual` | `runtime`),
+  nunca una elección del modelo. `legacy`: sin cambios, todo este documento aplica literal.
+  `dual`: el fichero sigue siendo **primario**, y cada transición se **espeja** al servidor
+  (comparador `dual-compare.sh` en el hook `Stop` detecta discrepancias y escala — no bloquea).
+  `runtime`: el servidor es primario; el fichero desaparece del camino de escritura.
+- **Las skills no arman peticiones a mano.** Todo acto de dominio pasa por `slice-ops.sh`
+  (inner loop) / `release-ops.sh` (outer loop) — el equivalente runtime del "patrón
+  lee-modifica-escribe con `python3`" de la regla 2. Protocolo completo:
+  `skills/building-a-slice/references/runtime-protocol.md` y
+  `docs/runtime/protocolo-cliente-runtime.md`.
+- **Gobierno sin cambios**: recortar/diferir alcance sigue siendo bloqueante explícito humano
+  (regla 8 de §10); el import del grafo de épicas y del histórico de estado los sube un **ADMIN**
+  en la consola del hub — el arnés **prepara y valida** bundles (`scripts/lib/graph-bundle.py`,
+  `trycore-build migrate`) pero nunca los publica.
+- **Es beta, opt-in, y NO es el default.** Se activa explícitamente con
+  `trycore-build init --runtime-url <url> --runtime-token <token> [--runtime-mode dual|runtime]`.
+  El corte a `runtime` como único camino (y el retiro de la maquinaria legacy) está condicionado a
+  que un piloto real corra en `dual` **un sprint sin discrepancias** — ver
+  `docs/runtime/plan-migracion-harness-v0.9.md` §2. Hasta entonces, `legacy` es el camino con
+  soporte completo y **este documento sigue siendo la fuente de verdad primaria**.
+- **Cómo migrar un proyecto** (paso a paso, con `trycore-build`) → `docs/runtime/guia-modo-dual-y-migracion.md`.
+
 ---
 
 ## 8. GitHub Flow estricto
@@ -547,7 +591,8 @@ salida es file-based y la propuesta se materializa en git, mañana irá por API
    (outer). Ningún gate vive en ambos.
 4. La trazabilidad change↔épica va en el **cuerpo markdown** de `proposal.md` (`## Trazabilidad`),
    **nunca** en frontmatter YAML.
-5. `build-state.json`: leer antes de actuar; **una transición = una escritura**; gates **monótonos**
+5. `build-state.json` (modo `legacy`, default) o su equivalente runtime (modo `dual`/`runtime`, opt-in
+   — §7-bis): leer antes de actuar; **una transición = una escritura**; gates **monótonos**
    (retroceso solo ante fallo); solo `dor-dod-gatekeeper` abre un slice cuando no hay activo.
 6. **GitHub Flow estricto**: `main` desplegable, integración solo por PR; `gitflow-guard.sh` bloquea
    commits/push directos.
@@ -555,9 +600,14 @@ salida es file-based y la propuesta se materializa en git, mañana irá por API
    release.
 8. **Disciplina de horizonte largo (§1-bis)**: refresh de contexto por defecto (estado en disco +
    `wiring_checklist[]`); cimiento antes que negocio y descomposición por tamaño/topología; gate
-   `wiring_verified` por verificador **adversarial independiente** antes de `dod`; **producto completo,
-   no MVP** (recortar/diferir es bloqueante explícito, nunca decisión del modelo; verificación
-   ejecutada, no por inspección).
+   `wiring_verified` por verificador **adversarial independiente** antes de `dod` — **incremental**
+   (pasadas 2+ solo re-ejecutan items cambiados desde su `verified_at_sha`) y con **condición de
+   parada**: máximo **2 pasadas completas** por slice, hallazgos de la 2ª en código nuevo → mutación
+   verificada sin tercera pasada, lo restante diferido **declarado en el PR** al Release Gate
+   (excepción: hallazgo ALTA en código preexistente → una pasada extra acotada); **producto completo,
+   no MVP** (recortar/diferir alcance es bloqueante explícito, nunca decisión del modelo; verificación
+   ejecutada, no por inspección — el diferimiento por condición de parada NO recorta alcance: difiere
+   una re-revisión al gate que la custodia).
 9. **Fidelidad estricta**: para slices con UI, `fidelity` solo cierra con **verificación visual real**
    (MCP chrome-devtools); INCONCLUSO no pasa. La fuente de diseño puede **producirse** con
    `/build:prototype` (en modo feature exige extracción viva de la app corriendo);

package/README.md

@@ -142,12 +142,12 @@ trycore-spec-build-harness/
 ├── agents/build/              ← 14 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← 9 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front)
+│   └── build/                 ← 12 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front, claim, status, escalate)
 ├── skills/                    ← 16 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, setup-architecture, prototyping-screens, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
-├── hooks/build/               ← 13 hooks (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, statusline-bridge, context-monitor, reconcile-build-state, …)
-├── state/                     ← máquina de estado: build-state.json + schema + README
-├── config/                    ← build-config.template.json (umbrales de contexto) + stack-allowlist.template.json (artefacto del consumidor)
-├── src/ + dist/               ← CLI trycore-build (init/update/status/uninstall/doctor)
+├── hooks/build/               ← 19 hooks (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, statusline-bridge, context-monitor, reconcile-build-state, …) + 6 opt-in del cliente runtime (session-start, event-emitter, context-sync, heartbeat, dual-compare, session-stop — ver docs/hooks.md)
+├── state/                     ← máquina de estado legacy: build-state.json + schema + README
+├── config/                    ← build-config.template.json (umbrales de contexto + runtime.mode) + stack-allowlist.template.json (artefacto del consumidor)
+├── src/ + dist/               ← CLI trycore-build (init/update/status/uninstall/doctor/migrate)
 ├── scripts/                   ← installer + guardias (check-version-sync/agnostic/state-clean)
 └── docs/examples/reference/   ← ejemplo de referencia (fuera del core, excluido de check-agnostic)
 ```
@@ -156,6 +156,14 @@ Los **14 agentes** en `agents/build/` son: `build-orchestrator`, `dor-dod-gateke
 
 **Estado.** `state/build-state.json` se siembra **vacío** y nunca se sobreescribe (va al `.gitignore`); el schema y el README sí se versionan. `config/stack-allowlist.json` es artefacto del consumidor: lo siembra el CLI y lo puebla `/build:onboard`. `uninstall` preserva `state/` y `config/`.
 
+## Modo runtime (beta, opcional)
+
+El arnés puede correr el mismo pipeline contra un **Agent Orchestrator Runtime** remoto en vez de
+(o además de) `build-state.json` — útil para flotas de varios agentes sobre un mismo proyecto.
+**Es opt-in**: `legacy` (el fichero local) sigue siendo el default y el único camino con soporte
+completo. Activarlo: `trycore-build init --runtime-url <url> --runtime-token <token>` (el token lo
+emite un ADMIN en la consola del hub). Guía paso a paso → [`docs/runtime/guia-modo-dual-y-migracion.md`](docs/runtime/guia-modo-dual-y-migracion.md).
+
 ## Requisitos
 
 `init` y `doctor` **fallan** si falta cualquiera de estos:
@@ -174,6 +182,31 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 
 ## Roadmap
 
+- ✅ **v0.10.0 (actual) — convergencia del inner loop** — ataque a los seis multiplicadores de
+  latencia de la verificación adversarial (iniciativa #31, issues #25–#30) **sin bajar el rigor**:
+  **re-verificación incremental** con `verified_at_sha` por item de `wiring_checklist[]` (las
+  pasadas 2+ re-ejecutan O(items tocados), no O(items totales)); **condición de parada** del bucle
+  adversarial (máx. 2 pasadas completas por slice; lo diferido se declara en el PR y lo custodia el
+  Release Gate; excepción única: hallazgo ALTA en código preexistente → pasada extra acotada);
+  **carril micro blindado** (`building-a-micro-change` exento de mutación obligatoria/evidencia
+  anclada/regresión con worktree — 1 test de regresión + suite del módulo en verde);
+  **presupuesto de mutación** (obligatoria solo para tests que sostienen items del checklist);
+  **evidencia en dos clases** (determinista → HEAD; viva → último commit del módulo medido,
+  `anchored_at.sha`/`head_at_run`); y **baseline de regresión cacheado por sha**
+  (`assets/baseline-verdict.sh`: capture/compare contra `origin/<destino>` con guard contra refs
+  locales). Nuevos references `evidence-budget.md` y `regression-baseline.md`; superficies
+  sincronizadas en METODOLOGIA §1-bis/§3.2/§10.
+- ✅ **v0.9.0 — beta/opt-in, EP-OR-08** — **cliente del Agent Orchestrator Runtime**,
+  opt-in, sin cambiar el default: el mismo pipeline de dos loops puede correr contra un servidor
+  remoto en vez de (o además de) `build-state.json`. 6 hooks nuevos (`session-start`,
+  `event-emitter`, `context-sync`, `heartbeat`, `dual-compare`, `session-stop`), `slice-ops.sh`/
+  `release-ops.sh` (13 subcomandos que conducen las skills), 3 comandos nuevos (`/build:claim`,
+  `/build:status`, `/build:escalate`), CLI extendido (`init --runtime-url/--runtime-token`,
+  `doctor`/`status` con sección Runtime, `migrate`). **Esta versión NO es "el corte"**: el paso a
+  `runtime` como único camino y el retiro del legacy esperan a un piloto real sin discrepancias
+  (release posterior) — ver
+  [`docs/runtime/guia-modo-dual-y-migracion.md`](docs/runtime/guia-modo-dual-y-migracion.md).
+  Total: **19 hooks**, **12 comandos `/build:*`**.
 - ✅ **v0.1.0** — arnés de dos loops (`building-a-slice` + `releasing-a-version`), 10 agentes, comandos `/opsx:*` + `/build:onboard`, 12 skills, 6 hooks, máquina de estado `build-state.json`, allowlist de stack, CLI `trycore-build` (init/update/status/uninstall/doctor) y plugin nativo. Compañero de `@trycore/spec-product-flow`.
 - ✅ **v0.2.0** — scaffold como "Paso 1 fundamental": gate de proyecto `scaffold.confirmed` (confirmación **explícita**, no auto), Fase 0 en `building-a-slice`, criterio duro de DoR y hook `scaffold-guard.sh`. El arnés **exige** el scaffold pero **no lo genera**.
 - ✅ **v0.3.0** — **ciclo autocorrectivo** (hook `reflect-nudge.sh` + comando `/build:reflect`: propone convenciones aprendidas al bloque `trycore-build-learnings` de `CLAUDE.md` tras tu aprobación; campos `reflected`/`reflected_at`) y **LSP opt-in** (`docs/customization/lsp-extensions.md` + sugerencia en `doctor` para stacks tipados). Total: **8 hooks**; comandos `/opsx:*` + `/build:onboard` + `/build:reflect`.
@@ -183,7 +216,7 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **v0.7.0** — **orquestación con workflows dinámicos + hardening** (de una evaluación adversarial del propio arnés): **3 plantillas `*.workflow.js`** opt-in y read-only (`explore-fanout`, `wiring-verify`, `release-gate`) que entran **solo donde aportan valor** y nunca en el camino caliente del inner loop; **3 comandos nuevos** `/build:slice` (entrada del inner loop), `/build:release` (outer loop) y `/build:work` (router *classify-and-act*); hook **`release-gate-nudge.sh`** (Stop, determinista: solo sugiere el Release Gate). Rename de los gates de los 5 reviewers pesados → `releases[].gates.{security,smell,ux,coherence,stack_arch}` (`stack`→`stack_arch`; separación `coherence` (release) / `coherence_link` (inner)). Hardening: degradación segura en 8 agentes, escritura atómica del estado, cierre del bypass de specs no-semver, `wiring` exige evidencia ejecutada y `check-agnostic` barre `*.js`. Total: **12 agentes**, **10 hooks**, **5 comandos `/build:*`**.
 - ✅ **v0.8.0** — **motor de contexto + estado anclado a disco + front paralelo inter-épica**: hooks **`statusline-bridge.sh`** (canal CLI) + **`context-monitor.sh`** (umbrales `context.warning_pct`/`context.critical_pct` configurables, 35%/25% por defecto) con **auto-handoff** a `session_continuity` en critical/`PreCompact` y comando **`/build:resume`** para rehidratar desde disco; config **`context.auto_checkpoint`** (opt-in). Reconciliador **`reconcile-build-state.py`** (`SessionStart`): deriva de git + evidencia de tests, degrada `wiring_checklist` sin evidencia, anota *branch drift*, ratchet de gates, fail-open. **Front paralelo** (`parallel_front` en el estado): comando **`/build:front`** + skill **`managing-parallel-front`** + `scripts/lib/front-plan.py` (disjunción por `files_scope`, foundational-first). Schema nuevo: `slice.layer`, `slice.files_scope`, `slice.branch_drift`, `slice.session_continuity`. **Caveat:** `statusLine` es solo canal CLI; en plugin-only el motor de contexto degrada fail-open. Total: **12 agentes**, **13 hooks**, **7 comandos `/build:*`**, **14 skills**.
 - ✅ **v0.8.1** — **hotfix del motor de contexto**: `context-monitor.sh` re-inyectaba `additionalContext` en cada evento `Stop`, lo que re-lanzaba el turno en bucle hasta el tope `CLAUDE_CODE_STOP_HOOK_BLOCK_CAP` (9→override). Ahora en `Stop` re-lanza como mucho una vez por sesión (solo la transición a crítico que graba el handoff) y `warning` nunca inyecta en `Stop`. Cubierto por `test-context-monitor.sh`.
-- ✅ **v0.8.5 (actual)** — **generador de prototipos HTML de referencia**: comando **`/build:prototype`** + skill **`prototyping-screens`** que producen la fuente de diseño (`DESIGN_SOURCE`) en `docs/05-prototipo/` (`DESIGN.md` + `tokens.css` + `manifest.json` pantalla↔épica/HU + un HTML autocontenido por pantalla). Dos modos: **greenfield** (inventario desde PRD/mapa/historias → dirección estética con 2-3 variantes a elección humana → generación por lotes) y **feature** (pantallas de una épica nueva con **extracción viva obligatoria** del UI implementado: CSS computado + screenshots en 3 viewports vía MCP; sin degradación estática). Auto-verificación visual (render real, máx. 3 iteraciones, sin pixel-diff) y **aprobación humana** de cada pantalla (`borrador`→`aprobada`); `ux-fidelity-reviewer` resuelve pantallas vía `manifest.json` (solo `aprobada`). La regla "el arnés no genera el prototipo" evoluciona a "puede generarlo; `design_source.confirmed` sigue siendo humano". 4º carve-out de escritura en `docs/` (§9.2). Total: **14 agentes**, **13 hooks**, **9 comandos `/build:*`**, **16 skills**.
+- ✅ **v0.8.5** — **generador de prototipos HTML de referencia**: comando **`/build:prototype`** + skill **`prototyping-screens`** que producen la fuente de diseño (`DESIGN_SOURCE`) en `docs/05-prototipo/` (`DESIGN.md` + `tokens.css` + `manifest.json` pantalla↔épica/HU + un HTML autocontenido por pantalla). Dos modos: **greenfield** (inventario desde PRD/mapa/historias → dirección estética con 2-3 variantes a elección humana → generación por lotes) y **feature** (pantallas de una épica nueva con **extracción viva obligatoria** del UI implementado: CSS computado + screenshots en 3 viewports vía MCP; sin degradación estática). Auto-verificación visual (render real, máx. 3 iteraciones, sin pixel-diff) y **aprobación humana** de cada pantalla (`borrador`→`aprobada`); `ux-fidelity-reviewer` resuelve pantallas vía `manifest.json` (solo `aprobada`). La regla "el arnés no genera el prototipo" evoluciona a "puede generarlo; `design_source.confirmed` sigue siendo humano". 4º carve-out de escritura en `docs/` (§9.2). Total: **14 agentes**, **13 hooks**, **9 comandos `/build:*`**, **16 skills**.
 - ✅ **v0.8.4** — **épica caparazón obligatoria en greenfield**: nuevo campo `project_kind` con detección automática conservadora en `trycore-build init` (brownfield seguro = manifiesto + código + **historial git con commits de código**; ambigüedad → una sola pregunta en `/build:onboard`; **en brownfield el mecanismo es N/A total, sin preguntar**) y gate de proyecto **`foundation`**: contrato del caparazón (navegación/menús · layout/panel central · homepage · login/authN · redirecciones/guards) como checklist podable con **evidencia de ejecución por ítem** (patrón `wiring_checklist`, contrato en `skills/building-a-slice/references/foundation-contract.md`). `/build:onboard` **Fase 2c** poda el contrato y redacta el **borrador híbrido** de la épica (solo se escribe en `epicas.md` con aprobación humana explícita — carve-out §9.2). **DoR 7-bis proactivo**: en greenfield ninguna épica `business` abre slice hasta que la caparazón esté **archivada con checklist evidenciada** (`foundation.completed_at`); las fundacionales y el carril micro-change nunca se bloquean. Línea `Caparazón` en `status`/`doctor`. Retrocompatible: campos opcionales del schema.
 - ✅ **v0.8.3** — **gates de validación paralelizados (sharding lossless)**: el carril `coherence` del Release Gate se shardea **por HU** (≥ 3 HUs, `args.hus[]`) — de un solo agente opus O(HUs) a un shard por HU en paralelo con consolidación **fail-closed** y cobertura completa; nueva plantilla **`dor-fanout.workflow.js`** para los chequeos per-HU del DoR (frontmatter/G-W-T/INVEST en paralelo; el nivel épica sigue en `dor-dod-gatekeeper`, único emisor del veredicto). `security`/`smell`/`ux`/`stack_arch` quedan monolíticos a propósito (riesgo cross-cutting); `integration` sigue secuencial (regla dura §5).
 - ✅ **v0.8.2** — **capa de arquitectura (ADD)** entre discovery y construcción: comando **`/build:architect`** + skill **`setup-architecture`** que aplica el método **Attribute-Driven Design** (Len Bass) leyendo `docs/` (solo lectura) y produciendo `docs/adr/` (drivers/ASRs → tácticas → estilos → vistas → ATAM-lite → stack), con **mínimo HITL** (autónomo, una revisión final; propone, no publica). Dos agentes nuevos (`asr-extractor`, `architecture-evaluator`), plantillas ADD embebidas en la skill (`skills/setup-architecture/assets/`) y **`asset-types.json`** (forward-compat runtime v0.9: `arch.drivers`/`arch.adr`/`arch.backlog`). Cierre del lazo: los ADRs se vuelven criterios — el **DoR** exige cobertura para el cimiento fundacional (opt-in, retrocompatible) y el gate **`stack_arch`** audita conformidad contra `docs/adr/`. Total: **14 agentes**, **13 hooks**, **8 comandos `/build:*`**, **15 skills**.

package/VERSION

@@ -1 +1 @@
-0.8.5
+0.11.0

package/agents/build/build-orchestrator.md

@@ -1,6 +1,6 @@
 ---
 name: build-orchestrator
-description: Orquesta el pipeline secuencial de construcción de un slice (épica EP-XXX) del arnés de construcción. Lee y escribe .claude/state/build-state.json, transiciona las fases y delega en los gates, en los skills opsx:* (motor de changes) y en superpowers:test-driven-development (motor TDD). Úsalo cuando el usuario quiera construir, continuar o avanzar una épica EP-XXX (las HU que cubre son su alcance interno).
+description: Orquesta el pipeline secuencial de construcción de un slice (épica EP-XXX) del arnés de construcción. Consulta el estado y reporta cada transición por slice-ops.sh (o, en modo legacy, por el fichero local), transiciona las fases y delega en los gates, en los skills opsx:* (motor de changes) y en superpowers:test-driven-development (motor TDD). Úsalo cuando el usuario quiera construir, continuar o avanzar una épica EP-XXX (las HU que cubre son su alcance interno).
 tools: Read, Grep, Glob, Bash, Edit, Write
 model: sonnet
 ---
@@ -9,13 +9,19 @@ Eres el **orquestador de construcción** del arnés de construcción. NO escribe
 diriges el pipeline secuencial, mantienes el estado y delegas en agentes y skills.
 
 ## Fuente de verdad
-`.claude/state/build-state.json` (valida contra `.claude/state/build-state.schema.json`).
-Protocolo en `.claude/state/README.md`. **Sólo un slice activo a la vez** (modelo secuencial).
-La **unidad de construcción es la épica** (`active_slice.epica`); las HU que cubre el change van en
-`active_slice.hus[]`. Un slice = una épica = un change = una rama = un PR.
+Depende del modo (`bash .claude/hooks/build/slice-ops.sh mode`):
+- `dual`/`runtime` → el **Agent Orchestrator Runtime**. Consulta con `slice-ops.sh status` y
+  transiciona con `slice-ops.sh gate|wiring|progress|checkpoint|submit|archive`. Protocolo en
+  `.claude/skills/building-a-slice/references/runtime-protocol.md`.
+- `legacy` → el fichero local, con el protocolo de
+  `.claude/skills/building-a-slice/references/state-protocol.md`.
+
+**Sólo un slice activo a la vez** (modelo secuencial). La **unidad de construcción es la épica**;
+las HU que cubre el change son su alcance interno. Un slice = una épica = un change = una rama = un PR.
+Eres el único que reporta gates y transiciona fases; los reviewers solo emiten su veredicto.
 
 ## Coexistencia con el front paralelo (outer-loop)
-Si `parallel_front` existe en el estado principal, el paralelismo lo gobierna la skill
+Si hay un front paralelo abierto, el paralelismo lo gobierna la skill
 `managing-parallel-front`; cada worktree corre su propio inner loop con `active_slice` singular.
 **Regla de drenado:** si se necesita abrir una épica `layer=foundational`, primero pon
 `parallel_front.status="draining"` (termina las en curso, no admite nuevas) y espera a cerrarlo.
@@ -54,7 +60,9 @@ auditará después que cada `passing` tenga evidencia real y que no falte ningú
               justificadas→true; DESVIACIONES→false; INCONCLUSO/sin MCP→FALSE, bloquea; sin UI→null).
 5. api/data → api-contract-tester (si hay endpoints) · data-consistency-checker (si toca datos)
 6. dod      → PRIMERO delega en wiring-adversarial-verifier (subagente INDEPENDIENTE, contexto virgen:
-              intenta refutar el slice; cierra gates.wiring_verified) → SOLO si true, dor-dod-gatekeeper (DoD reducido)
+              intenta refutar el slice; cierra gates.wiring_verified) → SOLO si true, dor-dod-gatekeeper (DoD reducido).
+              Máximo 2 pasadas completas por slice (condición de parada, ver abajo); pasadas 2+ incrementales
+              (solo items cuyo código cambió desde su verified_at_sha)
 7. pr       → abre PR y archiva el change EN EL MISMO PR (opsx:archive + opsx:sync); back-ref en épica y HU
 8. release? → tras archivar, devuelve a la skill building-a-slice para preguntar el Release Gate (default computado)
 ```
@@ -71,6 +79,24 @@ verificación se conduce con la plantilla read-only `skills/building-a-slice/wor
 (envuelve al verificador); **tú** —`build-orchestrator`— sigues siendo quien escribe `gates.wiring_verified`
 a partir del veredicto que la plantilla devuelve (la plantilla no toca el estado).
 
+**Estampa `verified_at_sha` al aplicar un veredicto.** Cuando apliques el veredicto del
+`wiring-adversarial-verifier` al estado, escribe en cada item de `wiring_checklist[]` cuya evidencia
+fue **reproducida en esa pasada** el campo `verified_at_sha` con el sha del commit verificado
+(`git rev-parse HEAD` al momento de la pasada). Los items que el verificador listó como «sin cambios
+desde <sha>» conservan su `verified_at_sha` anterior; los items que pasaron a `failing` lo pierden
+(quítalo o déjalo intacto solo si la evidencia sigue reproducida). Ese sello es lo que habilita la
+re-verificación incremental de las pasadas siguientes.
+
+**Condición de parada del bucle adversarial (máximo 2 pasadas completas por slice).** No conduzcas
+una tercera pasada: los hallazgos de la 2ª que estén en **código nuevo del cierre** se arreglan y se
+cierran con **mutación verificada** (re-ejecutar la evidencia del item afectado tras el fix), sin
+pasada adicional; la revisión independiente restante se **difiere explícitamente al Release Gate**
+(`releasing-a-version`) y se declara en el PR del slice (los gates `wiring_verified`/`dod` se cierran
+honestos, con el diferimiento anotado). **Única excepción**: un hallazgo ALTA en código
+**preexistente** durante la 2ª pasada habilita una pasada extra **acotada a ese frente** (no una
+tercera pasada completa). El diferimiento por condición de parada NO es «recortar alcance en
+silencio»: queda declarado en el PR y lo custodia el gate que ya existe para eso.
+
 ## Reglas de orquestación
 - **No saltes gates.** No avances de fase si el gate previo está en `false`. Reporta qué falta.
 - **Delega, no reimplementes.** Changes = `opsx:*`. TDD = `superpowers:test-driven-development`.

package/agents/build/dor-dod-gatekeeper.md

@@ -11,7 +11,8 @@ proponer la escritura del estado (no editas código de producto).
 ## Definition of Ready (gate `dor`) — antes de construir
 
 **Precondición — Paso 1 fundamental (scaffold):** antes de validar nada más, exige
-`scaffold.confirmed=true` en `build-state.json`. Si es `false`, **NO valides el DoR**: instruye
+el scaffold confirmado (`bash .claude/hooks/build/slice-ops.sh status`). Si no lo está, **NO valides
+el DoR**: instruye
 confirmar primero que existe un scaffold runnable del proyecto (ver `building-a-slice` Fase 0). El
 arnés **no genera** el scaffold; lo exige. (El hook `scaffold-guard.sh` respalda este bloqueo en
 las fases de código.)
@@ -41,10 +42,10 @@ cumplen; lista cada una con ✓/✗:
    como épica(s) `layer: foundational` **archivada(s)** en `history[]`. Si arrastra cimiento no construido,
    **NO abras el slice**: instruye extraerlo a una épica fundacional previa y construirla primero. Aquí la
    cláusula "explícitamente no bloquean" del criterio 6 **NO aplica**: el cimiento bloquea siempre.
-7-bis. **Caparazón construido (solo greenfield — PROACTIVO)**: lee `project_kind` y `foundation`
-   en `build-state.json`. Si `project_kind === "greenfield"` y `foundation.required === true` y
-   la épica evaluada es `layer: business`: exige `foundation.completed_at` estampado (la épica
-   caparazón, `foundation.epic`, archivada y con su checklist evidenciada). Si no está estampado,
+7-bis. **Caparazón construido (solo greenfield — PROACTIVO)**: lee los hechos de proyecto con
+   `slice-ops.sh status`. Si el proyecto es `greenfield` con caparazón **requerida** y la épica
+   evaluada es `layer: business`: exige la caparazón **completada** (su épica archivada y con la
+   checklist evidenciada). Si no lo está,
    **NO abras el slice**: instruye construir primero la épica caparazón (`foundation.epic`; si es
    `null`, correr `/build:onboard` Fase 2c o crearla en discovery). Las épicas `layer: foundational`
    no se bloquean por este criterio. Brownfield o `foundation.required !== true` → **N/A** (no
@@ -105,6 +106,13 @@ Pasa SOLO si **todos** estos gates del **inner loop** están en `true` (o `null`
    (subagente **independiente**, contexto virgen) tras intentar refutar el slice (stubs, rutas sin cablear,
    AC sin test, items de `wiring_checklist[]` aún `failing`) y no hallar huecos. **Tu DoD declarativo es un
    piso, no el arreglo**: no marques `dod` sin `wiring_verified: true`.
+   **Condición de parada (máximo 2 pasadas completas por slice)**: NO exijas una 3ª pasada adversarial.
+   Los hallazgos de la 2ª en código nuevo del cierre se cierran con **mutación verificada** (evidencia
+   del item re-ejecutada tras el fix), y la revisión independiente restante se **difiere explícitamente
+   al Release Gate**, declarada en el PR — con eso `wiring_verified`/`dod` cierran **honestos**. Verifica
+   que el diferimiento esté declarado en el PR; si no lo está, `dod` NO cierra. Excepción: un hallazgo
+   ALTA en código **preexistente** durante la 2ª pasada sí habilita (solo) una pasada extra **acotada**
+   a ese frente antes de cerrar.
 8. Documentación: change con tasks completas; back-ref añadido en la épica y en cada HU de `hus[]`.
 9. Hooks verdes (automáticos): `lint-typecheck.sh`, `stack-guard.sh`, `gitflow-guard.sh`.
 

package/agents/build/wiring-adversarial-verifier.md

@@ -41,16 +41,63 @@ prueba es del código: ante la duda, es `failing`.
 
 ## Método
 - Traza **cada** AC y **cada** integration_point hasta el código y un test que lo ejerza de verdad.
-- **Evidencia EJECUTADA, no por inspección.** Por cada item de `wiring_checklist[]` marcado `passing`,
-  **REPRODUCE su `evidence`** ejecutándola (el test/comando citado). Si **no puedes ejecutarla** (entorno sin
-  runner, build roto, dependencia ausente), ese item es `failing` — **NUNCA** `passing` por inspección.
+- **Evidencia EJECUTADA, no por inspección.** Por cada item de `wiring_checklist[]` **seleccionado
+  para re-verificación** (ver protocolo incremental) y marcado `passing`, **REPRODUCE su `evidence`**
+  ejecutándola (el test/comando citado). Si **no puedes ejecutarla** (entorno sin runner, build roto,
+  dependencia ausente), ese item es `failing` — **NUNCA** `passing` por inspección.
 - Corre la suite (`Bash`) para confirmar que lo verde es verde de verdad.
 
+## Protocolo incremental (re-verificación por `verified_at_sha`)
+
+Cada pasada re-ejecutar TODO es el multiplicador de coste más grande del bucle (coste ∝ items
+acumulados, y los items solo crecen). Por eso la selección de qué reproducir es **incremental**:
+
+1. **Primera pasada del slice** (ningún item trae `verified_at_sha`): pasada **completa** — reproduce
+   la evidencia de todos los items `passing`, como siempre.
+2. **Pasadas 2+**: por cada item con `verified_at_sha`, calcula si su código cambió desde ese sha —
+   `git diff <verified_at_sha>..HEAD -- <rutas del item>` (las rutas que su `evidence` y tu trazado
+   del item citan: código bajo prueba + test que lo ejerce).
+   - **Diff no vacío** (o item sin `verified_at_sha`, o sha inexistente en el repo) → re-ejecuta su
+     evidencia.
+   - **Diff vacío** → el item **conserva su veredicto** y lo listas como «sin cambios desde <sha>»
+     (no re-ejecutas su evidencia).
+   Acota además el foco de la pasada al **diff de los arreglos + sus rutas gemelas** (el patrón
+   documentado de defectos inducidos es «blindar una ruta y dejar la gemela»: si el fix tocó un
+   handler/rama/capa, revisa también su simétrico — el otro endpoint del par, la rama de error del
+   happy arreglado, el consumidor del productor tocado).
+3. **Pasada completa** solo la primera y, opcionalmente, una final si el orquestador la pide.
+4. **La incrementalidad no diluye el sesgo adversarial**: si por cualquier motivo re-ejecutas la
+   evidencia de un item «sin cambios» y resulta **irreproducible**, el veredicto es **HUECOS**
+   igual que siempre (conservar veredicto es un ahorro de ejecución, no una amnistía). Y la
+   degradación segura sigue intacta: «no pude calcular el diff» o «no pude ejecutar» jamás se
+   convierte en «sin cambios».
+
+Tú NO escribes `verified_at_sha` (eres read-only sobre el estado): reporta en tu salida **qué items
+reprodujiste** en esta pasada y cuáles quedaron «sin cambios desde <sha>»; el `build-orchestrator`
+estampa el sello al aplicar tu veredicto.
+
+## Anclaje de la evidencia: dos clases
+
+Al validar si una `evidence` sigue vigente, distingue la clase de evidencia:
+
+- **Evidencia determinista** (runners sin LLM: suite de tests, build, comando reproducible) — se
+  valida contra **HEAD**, como siempre: si el código cambió, se re-ejecuta contra el estado actual.
+- **Evidencia viva** (corridas contra un LLM real: evaluaciones, journeys conducidos por modelo,
+  mediciones de calidad de salida) — se valida contra **el último commit que tocó el módulo bajo
+  medición** (`git log -1 --format=%H -- <rutas del módulo>`), **no** contra HEAD: un commit de
+  docs/estado/otro módulo **no** la invalida. El artefacto de la corrida declara `anchored_at.sha`
+  (ese último commit del módulo) y `head_at_run` (el HEAD al momento de correr); la evidencia sigue
+  anclada mientras `anchored_at.sha` no cambie. Si el módulo bajo medición SÍ cambió desde
+  `anchored_at.sha`, la corrida está desanclada → re-ejecutar o `failing`.
+
 ## Salida + mapeo al gate
 Veredicto **CABLEADO COMPLETO** o **HUECOS** + lista priorizada de huecos con `archivo:línea`, la HU/AC o
 el par de capas afectado, y el fix mínimo. Devuelve también qué items de `wiring_checklist[]` deberían
-estar `failing`. **CABLEADO COMPLETO solo si CADA AC y CADA integration_point quedó trazado a un test
-ejercido y reproducido**; cualquier duda no resuelta → **HUECOS** (la carga de la prueba es del código).
+estar `failing`, qué items **reprodujiste en esta pasada** (para que el orquestador estampe
+`verified_at_sha`) y cuáles conservaron veredicto como **«sin cambios desde <sha>»**. **CABLEADO
+COMPLETO solo si CADA AC y CADA integration_point quedó trazado a un test ejercido y reproducido —
+en esta pasada o en una anterior sin cambios desde su `verified_at_sha`**; cualquier duda no resuelta
+→ **HUECOS** (la carga de la prueba es del código).
 
 **Degradación segura (no éxito silencioso).** Si **no pudiste ejecutar** la verificación de uno o más items
 (sin runner, build roto, dependencia ausente, sin reporte de `integration-check`) → veredicto **HUECOS** (no

package/commands/build/architect.md

@@ -44,7 +44,7 @@ Invoca la skill **`setup-architecture`**. La skill:
 - **No** edites artefactos de discovery (`docs/01-prd/`…`docs/04-historias/`): la única salida en `docs/`
   es `docs/adr/`.
 - **No** publiques: los ADRs se **proponen** (`proposed`/`living-document`); el humano promueve a `accepted`.
-- **No** abras un slice ni toques `build-state.json`: esta fase es **pre-build**.
+- **No** abras un slice ni transiciones el estado del slice: esta fase es **pre-build**.
 
 ---
 

package/commands/build/claim.md

@@ -0,0 +1,46 @@
+---
+name: "BUILD: Claim"
+description: Reclama trabajo al Agent Orchestrator Runtime (POST /tasks/next) sincronizando el contexto antes, reportando los hashes locales de los archivos gobernados y continuando desde el checkpoint si lo hay. Adaptador delgado sobre slice-ops.sh claim; en modo legacy o dual el slice lo decide el fichero local.
+category: Workflow
+tags: [build-harness, runtime, claim, trycore]
+---
+
+# /build:claim — Pedir la siguiente tarea al runtime
+
+**Entrada (opcional):** `EP-XXX` para pedir una épica concreta. Sin argumento, el runtime elige.
+
+## 1. Reclamar
+
+```bash
+bash .claude/hooks/build/slice-ops.sh claim ${1:+--epic "$1"}
+echo "rc=$?"
+```
+
+El comando ya hace, por ti y en este orden: sincroniza el contexto (no se abre trabajo con
+contexto viejo), reporta los `sha256` locales efectivos de los archivos gobernados (el servidor
+detecta drift), reclama por **POST**, refresca la caché de proyección y rinde el slice.
+
+## 2. Ramificar por el código de salida
+
+| rc | Qué significa | Qué haces |
+|---|---|---|
+| 0 | slice reclamado | si la salida trae **CHECKPOINT**, haz checkout de esa rama y **continúa desde ahí, jamás reinicies**; luego `/build:slice` |
+| 3 | modo `legacy`, o `dual` (el fichero decide) | abre/retoma el slice con el protocolo del fichero (`/build:slice`) |
+| 5 | runtime inalcanzable | **sigue trabajando** con lo local; reintenta al reconectar |
+| 6 | rechazo del servidor (409/401/422) | muestra su razón tal cual; **no reintentes** — token, contexto o proyecto a resolver con el ADMIN |
+| 7 | sin trabajo disponible, o carrera perdida | dilo y termina limpio; ofrece `/build:status` |
+
+## 3. Seguir
+
+```bash
+bash .claude/hooks/build/slice-ops.sh next-step
+```
+
+Ejecuta esa acción, o entra al pipeline con `/build:slice`.
+
+## Guardrails
+
+- **No** armes peticiones al runtime a mano: todo pasa por `slice-ops.sh`.
+- **Un solo slice activo**: reclamar con lease vigente devuelve el mismo slice (idempotente).
+- **Nunca reinicies** un slice que trae checkpoint: es trabajo de otro agente que cayó.
+- Si algo contradice `METODOLOGIA.md`, **gana la metodología**.

package/commands/build/escalate.md

@@ -0,0 +1,36 @@
+---
+name: "BUILD: Escalate"
+description: Registra un bloqueo del slice en el runtime (evento slice_escalated) y devuelve la decisión al humano — recortar, diferir o desbloquear nunca lo decide el modelo. Adaptador delgado sobre slice-ops.sh escalate.
+category: Workflow
+tags: [build-harness, runtime, escalada, gobierno, trycore]
+---
+
+# /build:escalate — Bloqueo que decide una persona
+
+**Entrada:** la razón del bloqueo (una frase concreta y verificable). Opcional: el gate afectado.
+
+## 1. Registrar
+
+```bash
+bash .claude/hooks/build/slice-ops.sh escalate "<razón>" --gate <gate opcional>
+```
+
+Deja el rastro tipado en el runtime (ámbito slice si hay slice reclamado; de proyecto si no).
+Para razones largas, escríbelas en un fichero y usa `--file`.
+
+## 2. Devolver la decisión al humano
+
+Presenta al usuario, en tres líneas: **qué está bloqueado**, **qué evidencia lo demuestra** y
+**las opciones reales** (con su coste). No elijas por él.
+
+> **Regla dura del arnés:** *Producto completo, no MVP.* Recortar o diferir alcance es un
+> **bloqueante explícito** que requiere acuerdo del equipo — jamás una decisión del modelo. Escalar
+> no es rendirse: es negarse a degradar el alcance en silencio.
+
+## Guardrails
+
+- **No** cierres gates «para avanzar» mientras el bloqueo esté vivo.
+- **No** inventes alternativas fuera del alcance acordado.
+- Si el bloqueo es de contexto gobernado (allowlist, política, reglas), la salida es una
+  **propuesta** en el hub que publica un ADMIN, no una edición local del fichero sincronizado.
+- Si algo contradice `METODOLOGIA.md`, **gana la metodología**.