@trycore/spec-build-harness 0.6.0 → 0.7.1

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.6.0",
+  "version": "0.7.1",
   "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

@@ -9,8 +9,9 @@ evoluciona con el modelo y el proyecto. No es "instalar y olvidar".
 | Contexto | sección Construcción de CLAUDE.md, `openspec/project.md` | raíz / `openspec/` |
 | Estado | `build-state.json` (+schema, README) | `.claude/state/` |
 | Agentes | 12 agentes de build | `.claude/agents/build/` |
-| Hooks | settings.json + 9 scripts | `.claude/settings.json`, `.claude/hooks/build/` |
-| Skill | `building-a-slice` (+10 refs) · `building-a-micro-change` (carril ligero de mantenimiento) | `.claude/skills/` |
+| Hooks | settings.json + 10 scripts | `.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) | `.claude/skills/` |
+| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:slice` · `/build:release` · `/build:work` | `.claude/commands/` |
 | Config | allowlist de stack | `.claude/config/stack-allowlist.json` |
 
 ## Fases de activación (`harness_phase`)
@@ -28,7 +29,8 @@ evoluciona con el modelo y el proyecto. No es "instalar y olvidar".
    hook o un agente? Si sí, retirarlo.
 3. **Allowlist vs PRD**: re-sincronizar `stack-allowlist.json` con la sección de requisitos técnicos del PRD del consumidor (ruta declarada en `stack-allowlist.json#source`) si el stack cambió.
 4. **Coherencia de convenciones**: que `build-state.schema.json`, los agentes y la skill sigan
-   alineados (mismos nombres de gate/fase).
+   alineados (mismos nombres de gate/fase). Las plantillas `*.workflow.js` de `skills/*/workflows/`
+   entran al **mismo barrido agnóstico** que `agents/` y `skills/` (`check-agnostic.sh` incluye `*.js`).
 
 ## DRI (Directly Responsible Individual)
 Un **Agent Manager** (rol híbrido PM + DevEx) centraliza qué funciona y evita la fragmentación de
@@ -44,6 +46,27 @@ Editar `stack-allowlist.json` SOLO si la sección de requisitos técnicos del PR
 ## Bitácora de cambios de metodología
 Cambios a la política de construcción (unidad de trabajo, gates, DoR/DoD). Aprueba el DRI; van por PR.
 
+- **2026-06-24 · v0.7.0** — **Workflows dinámicos en el flujo build-a-slice** (origen:
+  evaluación adversarial del arnés con workflows dinámicos; 18 mejoras aprobadas contra una rúbrica de
+  hardness). **Aprobado por el DRI (Agent Manager); fusionado en PR #7.** No cambia la unidad de trabajo, los gates,
+  el DoR ni el DoD — introduce **mecanismos de ejecución** opcionales y endurece componentes existentes.
+  Cambios que tocan la metodología: (1) **§1-bis.2** — la exploración solo-lectura puede conducirse con un
+  **workflow fan-out** opcional, gated por el size-gate (`sub_slices[]`); read-only, no escribe estado.
+  (2) **§1-bis.3** — **plantilla de conducción** opcional del verificador adversarial del gate
+  `wiring_verified`; no es gate nuevo y no escribe estado (`build-orchestrator` sigue siendo single-writer).
+  (3) **§4** — el nudge "≥2 épicas archivadas desde el último `releases[]`" también lo emite un **hook Stop
+  determinista** (`release-gate-nudge.sh`) por aritmética de conjuntos sobre `epicas[]`. (4) **§0** — nuevo
+  router de entrada `/build:work` (classify-and-act) que codifica el ruteo micro-change/slice/release (ruteo,
+  no política nueva). Hardening sin cambio de política: corrección de la **deriva de nombres de gate** de los 5
+  reviewers pesados (`releases[].gates.{security,smell,ux,coherence,stack_arch}`; `stack`→`stack_arch`) y del
+  gate de inner loop `coherence_link`; **contrato de degradación segura** de reviewers (fallo de herramienta →
+  bloqueante, nunca PASS); refuerzo del `wiring-adversarial-verifier` (evidencia ejecutada, no por inspección);
+  **escritura atómica** del estado en `load-build-state.sh`; cierre del **bypass de specs no-semver** en
+  `stack-guard.sh`; `check-agnostic.sh` ahora barre `*.js`/`*.mjs`. Artefactos nuevos: **3 comandos**
+  (`/build:slice`, `/build:release`, `/build:work`), **1 hook** (`release-gate-nudge.sh`, total **10**),
+  **3 plantillas `*.workflow.js`** (read-only) + 1 reference. Empaquetado en el **release 0.7.0** (bump
+  simultáneo de `VERSION`, `package.json` y `plugin.json`, por la regla de version-sync).
+
 - **2026-06-19 · v0.6.0** — **Calidad de cierre contra horizonte largo** (origen: feedback del equipo
   exodocs tras varios releases, revisado por un experto de Anthropic; raíz: agotamiento de contexto +
   cierre prematuro en épicas multicapa). Toca gates/DoR/DoD y el schema de estado → aprobado por el DRI

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.5.0` |
+| Versión | `0.7.0` |
 
 > **¿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,7 +30,7 @@ npm install -g @trycore/spec-build-harness
 Esto expone el binario `trycore-build`. Comprueba la versión:
 
 ```bash
-trycore-build --version    # → 0.5.0
+trycore-build --version    # → 0.7.0
 trycore-build --help
 ```
 
@@ -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/` — 12 agentes.
-   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (`/build:onboard`, `/build:reflect`).
-   - `.claude/skills/` — 12 skills (`building-a-slice`, `releasing-a-version`, `openspec-*`).
-   - `.claude/hooks/build/` — 9 hooks bash.
+   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (5 comandos: `/build:onboard`, `/build:reflect`, `/build:slice`, `/build:release`, `/build:work`).
+   - `.claude/skills/` — 13 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `openspec-*`).
+   - `.claude/hooks/build/` — 10 hooks bash.
 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`).
@@ -205,7 +205,7 @@ Como conveniencia a nivel usuario, el arnés también se instala como **plugin n
 ### ⚠ Caveat de canales (importante)
 
 - El **canal npm CLI es el CANÓNICO**. `trycore-build init` instala los comandos en
-  `.claude/commands/{opsx,build}/`, que namespacean **por subcarpeta** → `/opsx:*` y `/build:onboard`,
+  `.claude/commands/{opsx,build}/`, que namespacean **por subcarpeta** → `/opsx:*` y `/build:*`,
   y los agentes se referencian por su **nombre** (`security-reviewer`, `stack-guardian`, …).
 - El **canal plugin nativo** namespacea **todos** los componentes bajo el **nombre del plugin**
   (→ `/trycore-spec-build-harness:*`), por diseño de Claude Code.
@@ -235,7 +235,7 @@ Ambos paquetes coexisten en el mismo `.claude/` **sin colisión**, porque usan *
 
 | | Discovery — `spec-product-flow` | Construcción — `spec-build-harness` |
 |---|---|---|
-| Comandos | `/trycore:*` | `/opsx:*` + `/build:onboard` + `/build:reflect` |
+| Comandos | `/trycore:*` | `/opsx:*` + `/build:*` (`onboard`, `reflect`, `slice`, `release`, `work`) |
 | Marca de versión | `.trycore-version` | `.build-harness-version` |
 | Bloque en `CLAUDE.md` | `<!-- BEGIN trycore-vertical -->` | `<!-- BEGIN trycore-build-harness -->` |
 

package/METODOLOGIA.md

@@ -28,7 +28,7 @@ Ambos paquetes **coexisten en el mismo `.claude/` sin colisión**, con namespace
 
 | Eje | Discovery (`spec-product-flow`) | Construcción (`spec-build-harness`) |
 |---|---|---|
-| Comandos | `trycore/` (`/trycore:*`) | `opsx/` + `build/` (`/opsx:*`, `/build:onboard`, `/build:reflect`) |
+| Comandos | `trycore/` (`/trycore:*`) | `opsx/` + `build/` (`/opsx:*`, `/build:work`, `/build:slice`, `/build:release`, `/build:onboard`, `/build:reflect`) |
 | Sentinela de versión | `.trycore-version` | `.build-harness-version` |
 | Bloque en `CLAUDE.md` | `<!-- BEGIN trycore-vertical -->` | `<!-- BEGIN trycore-build-harness -->` |
 
@@ -80,12 +80,23 @@ sola pasada**: a medida que crece el contexto, la atención se degrada ("context
    supera el **gate de tamaño** (>3 HU ó ≥3 capas) se trocea en `sub_slices[]` construidos de a uno. El
    orquestador trabaja por **fases encadenadas** (mapear → generar → revisar → fix-loop → optimizar) y
    reparte la **exploración** "ancho antes que profundo" con subagentes **solo-lectura** por área
-   (devuelven síntesis condensada); el **cableado** lo hace la sesión, no subagentes en paralelo.
+   (devuelven síntesis condensada); el **cableado** lo hace la sesión, no subagentes en paralelo. Ese
+   reparto de exploración solo-lectura **puede** conducirse, de forma OPCIONAL, con un **workflow fan-out**
+   (`parallel()`) **SOLO** para épicas que superaron el gate de tamaño (con `sub_slices[]`); en épicas
+   atómicas se hace secuencial en sesión. El workflow es **solo-lectura**: no escribe código de producto ni
+   `build-state.json` (plantilla en `skills/building-a-slice/workflows/explore-fanout.workflow.js`).
 3. **Verificación adversarial independiente (no DoD declarativo).** Reusar el mismo agente como generador
    y verificador produce **auto-confirmación**. Por eso el gate **`wiring_verified`** lo cierra un
    subagente **independiente, de contexto virgen** (`wiring-adversarial-verifier`) cuyo trabajo es
    **asumir que el slice está incompleto y refutarlo** (stubs, rutas sin cablear, AC sin test, items
    `failing`) **antes** de permitir `dod`. El DoD declarativo del gatekeeper es un **piso, no el arreglo**.
+   Esta verificación adversarial **puede** conducirse, de forma OPCIONAL, con una **plantilla de conducción**
+   (`skills/building-a-slice/workflows/wiring-verify.workflow.js`) que envuelve al verificador ya existente: (a)
+   **NO** es un gate nuevo ni cambia política; (b) **NO** escribe estado — el verificador sigue read-only y
+   `build-orchestrator` sigue siendo el **único** escritor de `gates.wiring_verified`; (c) equivale a la prosa
+   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.
 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**
@@ -128,7 +139,9 @@ se listan en `active_slice.hus[]`. Construir por HU individual es sobre-ingenier
 > PR, sin abrir `active_slice`). No es una excepción a la regla, sino mantenimiento fuera de su
 > alcance. **Límites duros:** si el cambio añade una dependencia nueva, crea un endpoint/API nuevo, o
 > toca lógica de dominio o el modelo/invariantes de datos, **deja de ser micro-change** y se escala a
-> épica. Ante la duda, es una épica.
+> épica. Ante la duda, es una épica. El comando `/build:work` codifica este *decision gate* (y el default
+> del Release Gate del §4) como **ruteo** —no política nueva—: enruta a `building-a-micro-change`,
+> `building-a-slice` o `releasing-a-version` según el cambio; ante ambigüedad, escala a épica.
 
 ---
 
@@ -229,6 +242,12 @@ Tras archivar la épica, `building-a-slice` **pregunta al humano** si correr el
 El humano siempre puede sobreescribir el default. Si acepta, se invoca `releasing-a-version` sobre la
 release correspondiente.
 
+> El *nudge* "≥ 2 épicas archivadas desde el último entry de `releases[]`" también lo emite un **hook
+> `Stop` determinista** (`release-gate-nudge.sh`), computado por **aritmética de conjuntos** sobre
+> `epicas[]` (archivadas − cubiertas), independiente de timestamps; **solo sugiere** (no ejecuta nada, no
+> llama al modelo, no escribe estado). El criterio "cierra una línea de release" requiere
+> `docs/02-user-story-map/` y por eso **no** lo cubre el hook: lo computa la skill `building-a-slice`.
+
 ---
 
 ## 5. Los gates del Release Gate (outer loop)

package/README.md

@@ -73,6 +73,9 @@ Gate de release que corre **una sola vez por versión** sobre el conjunto de sli
 |---|---|
 | `/build:onboard` | Onboarding capa 2: lee el PRD, pregunta por PII/IA/determinismo/secretos, resuelve `{{placeholders}}` y escribe la auto-memory. |
 | `/build:reflect` | Reflexión post-slice: tras archivar, propone convenciones aprendidas / errores recurrentes al bloque `trycore-build-learnings` de `CLAUDE.md` (tras tu aprobación) y marca el slice como reflexionado. |
+| `/build:slice` | Entrada del **inner loop**: abre o continúa un slice (épica `EP-XXX`) y conduce el pipeline DoR → change → TDD → smoke → api/data → DoD → PR+archive. Adaptador delgado que delega en la skill `building-a-slice`. |
+| `/build:release` | Entrada del **outer loop**: corre el Release Gate **una sola vez** sobre el diff acumulado (los 5 reviewers pesados en paralelo + integración secuencial). Delega en la skill `releasing-a-version`. |
+| `/build:work` | Router *classify-and-act*: clasifica el trabajo entrante y enruta al carril correcto (`building-a-micro-change` · `building-a-slice` · `releasing-a-version`). Es ruteo, no política: no ejecuta el pipeline ni toca el estado. |
 | `/opsx:*` (10) | Ciclo OpenSpec: `explore` · `new` · `continue` · `apply` · `verify` · `archive` · `bulk-archive` · `ff` · `onboard` · `sync`. Detalle → [`docs/commands.md`](docs/commands.md). |
 
 ## Arquitectura
@@ -85,9 +88,9 @@ trycore-spec-build-harness/
 ├── agents/build/              ← 12 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← /build:onboard, /build:reflect
-├── skills/                    ← 12 skills (building-a-slice, releasing-a-version, 10 openspec-*)
-├── hooks/build/               ← 9 hooks bash (gate-check, reflect-nudge, scaffold-guard, gitflow-guard, stack-guard, …)
+│   └── build/                 ← 5 comandos /build:* (onboard, reflect, slice, release, work)
+├── skills/                    ← 13 skills (building-a-slice, building-a-micro-change, releasing-a-version, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
+├── hooks/build/               ← 10 hooks bash (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, …)
 ├── state/                     ← máquina de estado: build-state.json + schema + README
 ├── config/                    ← stack-allowlist.template.json (artefacto del consumidor)
 ├── src/ + dist/               ← CLI trycore-build (init/update/status/uninstall/doctor)
@@ -122,7 +125,8 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **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`.
 - ✅ **v0.4.0** — carril `building-a-micro-change` (mantenimiento ligero sin slice) + DoR proporcional a la complejidad.
 - ✅ **v0.5.0** — seguro de fuente de diseño (`design_source` + `design-source-guard.sh`) + agente `ux-fidelity-reviewer` (gate `fidelity`, inner loop). Total: **11 agentes**, **9 hooks**.
-- ✅ **v0.6.0 (actual)** — **calidad de cierre contra horizonte largo** (feedback exodocs): handoff fino en disco (`wiring_checklist[]` + `progress_log[]` + `sub_slices[]`), gate `wiring_verified` por nuevo agente **`wiring-adversarial-verifier`** (verificación adversarial independiente, contexto virgen), cimiento pre-construido + tag `layer` y gate de tamaño en el DoR, runner fuera-de-chat `integration-check`, y **fidelidad estricta por verificación visual real** (MCP requerido para UI). Convenciones anti-deriva (producto completo, no MVP) upstreadas al bloque del arnés. Total: **12 agentes**, **9 hooks**.
+- ✅ **v0.6.0** — **calidad de cierre contra horizonte largo** (feedback exodocs): handoff fino en disco (`wiring_checklist[]` + `progress_log[]` + `sub_slices[]`), gate `wiring_verified` por nuevo agente **`wiring-adversarial-verifier`** (verificación adversarial independiente, contexto virgen), cimiento pre-construido + tag `layer` y gate de tamaño en el DoR, runner fuera-de-chat `integration-check`, y **fidelidad estricta por verificación visual real** (MCP requerido para UI). Convenciones anti-deriva (producto completo, no MVP) upstreadas al bloque del arnés. Total: **12 agentes**, **9 hooks**.
+- ✅ **v0.7.0 (actual)** — **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:*`**.
 
 ## Licencia
 

package/VERSION

@@ -1 +1 @@
-0.6.0
+0.7.1

package/agents/build/api-contract-tester.md

@@ -29,4 +29,12 @@ Eres el **tester de contratos de API** del arnés de construcción. Si el slice
 - Resumen de ejecución (totales, fallos con request + aserción).
 - Veredicto: 100% verde → propón `gates.api: true`; fallos → `false` con el detalle; sin endpoints → `null`.
 
+## Degradación segura
+Si **no puedes completar tu verificación** (la app no levanta, `newman`/`npx` ausente, la colección no se puede
+crear, readiness no llega), **NO devuelvas PASS ni inventes**: devuelve veredicto **BLOQUEANTE / INCONCLUSO** con
+el motivo y qué falta para correr. *La ausencia de evidencia no es evidencia de ausencia de problemas.* Distingue
+—como `ux-fidelity-reviewer` (INCONCLUSO ≠ N/A)— el **N/A legítimo** (slice **sin endpoints** → `gates.api: null`)
+de **"no pude verificar"** (fallo de herramienta → `false`). Reserva el `null` SOLO para el N/A genuino (sin
+endpoints), nunca para un fallo de herramienta.
+
 No edites código de producto: si faltan casos, propón los requests a añadir. Devuelve al `build-orchestrator`.

package/agents/build/build-orchestrator.md

@@ -24,7 +24,10 @@ escriben en paralelo.
 
 **Descomposición (gate de tamaño).** Si la épica supera el umbral (>3 HU ó ≥3 capas; configurable),
 el DoR la trocea en `sub_slices[]`: constrúyelos **de a uno**, con `journey_smoke` verde entre cada
-uno, marcando `sub_slices[].status: done` al cerrar cada uno.
+uno, marcando `sub_slices[].status: done` al cerrar cada uno. Para épicas troceadas, la exploración
+solo-lectura por área **puede** conducirse con la plantilla (opcional) `skills/building-a-slice/workflows/
+explore-fanout.workflow.js` (gated por la guarda del propio workflow: `sub_slices[]` no vacío). **No** la uses
+en épicas atómicas: inflaría el inner loop barato. Es read-only; el cableado sigue siendo de la sesión.
 
 **Refresh de contexto por defecto.** Mantén el handoff fino en disco. **Siémbralo al entrar a `change`/`tdd`**:
 deriva de las HU de `hus[]` un item de `wiring_checklist[]` por **cada escenario AC** y uno por **cada
@@ -57,7 +60,10 @@ El `ux-fidelity-reviewer` **sí** corre aquí (en `smoke`): es barato (la app ya
 por-slice; no es la revisión pesada de UX/Krug (esa sigue en `releasing-a-version`). El
 `wiring-adversarial-verifier` **también** corre aquí (al inicio de `dod`): es un verificador
 **enfocado y corto** (solo refuta cableado/AC/stubs, no re-revisa diseño/seguridad), e **independiente**
-del que generó el código — por eso evita la auto-confirmación del cierre prematuro.
+del que generó el código — por eso evita la auto-confirmación del cierre prematuro. Opcionalmente esa
+verificación se conduce con la plantilla read-only `skills/building-a-slice/workflows/wiring-verify.workflow.js`
+(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).
 
 ## Reglas de orquestación
 - **No saltes gates.** No avances de fase si el gate previo está en `false`. Reporta qué falta.

package/agents/build/change-epic-coherence.md

@@ -35,7 +35,16 @@ que aparezca un OpenSpec change "huérfano" desconectado de la discovery de Tryc
 
 ## Salida
 - Veredicto: **COHERENTE** / **INCOHERENTE**, con lista ✓/✗ y citas textuales (archivo:línea).
-- Si COHERENTE: indica que se puede marcar `gates.coherence: true` para la fase `change`.
+- Si COHERENTE: indica que se puede marcar `gates.coherence_link: true` (gate del **inner loop**, fase
+  `change`). NO es el `coherence` pesado del outer loop (ese lo cierra `coherence-three-way` en
+  `releasing-a-version` sobre la implementación real): son gates distintos del schema — `coherence_link`
+  (inner, barato, enlace change↔épica) vs `coherence` (release, trazabilidad triple completa).
 - Si INCOHERENTE: por cada ✗, propone el fix concreto (texto exacto a añadir/corregir).
 
-No edites archivos: devuelve el diagnóstico al `build-orchestrator`.
+## Degradación segura
+Si **no puedes completar tu verificación** (`openspec validate` no corre, no puedes leer el `proposal.md`/las
+HU/la épica), **NO devuelvas COHERENTE ni inventes**: devuelve **INCOHERENTE / INCONCLUSO** con el motivo y qué
+falta para correr. *La ausencia de evidencia no es evidencia de ausencia de problemas.* Un fallo de herramienta
+**no es N/A**: nunca devuelvas `null` por no poder verificar — devuelve bloqueante/`false`.
+
+No edites archivos: devuelve el diagnóstico al `build-orchestrator` (gate de inner loop `coherence_link`).

package/agents/build/coherence-three-way.md

@@ -1,6 +1,6 @@
 ---
 name: coherence-three-way
-description: Verifica la coherencia triple AC de las HU de la épica (Given/When/Then) ↔ OpenSpec change(specs/tasks) ↔ código/tests implementados. Detecta AC sin test, tasks sin AC, y código que no traza a ninguna HU. Úsalo en la fase verify, antes del DoD.
+description: Verifica la coherencia triple AC de las HU de la épica (Given/When/Then) ↔ OpenSpec change(specs/tasks) ↔ código/tests implementados. Detecta AC sin test, tasks sin AC, y código que no traza a ninguna HU. Úsalo en el Release Gate (releasing-a-version), sobre el diff acumulado de la release.
 tools: Read, Grep, Glob, Bash
 model: opus
 ---
@@ -29,7 +29,15 @@ construcción: nada implementado sin razón, nada especificado sin implementar.
 ## Salida
 - Matriz de trazabilidad AC ↔ escenario ↔ task ↔ test/código (tabla compacta).
 - Huérfanos top-down (AC de alguna HU sin test) y bottom-up (código sin HU), con `archivo:línea`.
-- Veredicto: **COHERENTE** → propone `gates.coherence: true`; o **INCOHERENTE** con fixes.
+- Veredicto: **COHERENTE** → propone `releases[].gates.coherence: true`; o **INCOHERENTE** con fixes.
 
-Complementa a `change-epic-coherence` (que valida el enlace) verificando la **implementación real**.
-No edites: devuelve el diagnóstico al `build-orchestrator`.
+## Degradación segura
+Si **no puedes completar tu verificación** (no puedes leer las HU/specs/código, `openspec`/LSP ausente, `diff`
+vacío inesperado), **NO devuelvas COHERENTE ni inventes**: devuelve **INCOHERENTE / INCONCLUSO** con el motivo y
+qué falta para correr. *La ausencia de evidencia no es evidencia de ausencia de problemas.* Un fallo de
+herramienta **no es N/A**: nunca devuelvas `null` por no poder verificar — devuelve bloqueante/`false`.
+
+Complementa a `change-epic-coherence` (que valida el enlace, gate de inner loop `coherence_link`) verificando la
+**implementación real** (gate de release `coherence`). No edites: devuelve el diagnóstico a la skill
+`releasing-a-version` (Release Gate, **outer loop**), que escribe `releases[].gates`. Cadencia: **una vez por
+RELEASE**, no por slice.

package/agents/build/data-consistency-checker.md

@@ -45,4 +45,11 @@ bloque de dominio del CLAUDE.md del consumidor / del PRD del consumidor. Este ag
 - Invariantes ✓/✗ con evidencia (`archivo:línea` o salida de test).
 - Veredicto: todas ✓ → propón `gates.data: true`; alguna ✗ → `false` con el fix/test faltante.
 
+## Degradación segura
+Si **no puedes completar tu verificación** (los tests no corren, runner `vitest`/`jest` ausente, no puedes leer
+la capa de decisión), **NO devuelvas PASS ni inventes**: devuelve veredicto **BLOQUEANTE / INCONCLUSO** con el
+motivo y qué falta para correr. *La ausencia de evidencia no es evidencia de ausencia de problemas.* Un fallo de
+herramienta **no es N/A**: nunca devuelvas `null` por no poder verificar — devuelve bloqueante/`false` (el caso
+N/A de `data` lo decide el `build-orchestrator` por aplicabilidad del slice, no tú por un fallo de herramienta).
+
 No edites: devuelve el diagnóstico al `build-orchestrator`.

package/agents/build/security-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: security-reviewer
-description: Revisión de seguridad del slice con foco en el dominio declarado por el consumidor (PII/datos regulados, claves de servicios externos, validación de entrada). Envuelve la lógica de /security-review y la especializa para este proyecto. Úsalo en la fase review. Requiere código.
+description: Revisión de seguridad del slice con foco en el dominio declarado por el consumidor (PII/datos regulados, claves de servicios externos, validación de entrada). Envuelve la lógica de /security-review y la especializa para este proyecto. Úsalo en el Release Gate (releasing-a-version), sobre el diff acumulado de la release. Requiere código.
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
@@ -41,6 +41,14 @@ consumidor o de su PRD (la sección de requisitos técnicos del PRD, en la ruta
 
 ## Salida
 - Hallazgos por severidad **CRÍTICO / ALTO / MEDIO / BAJO** con `archivo:línea` y remediación.
-- Veredicto: sin CRÍTICO/ALTO abiertos → propón `gates.security: true`; si los hay → `false`.
+- Veredicto: sin CRÍTICO/ALTO abiertos → propón `releases[].gates.security: true`; si los hay → `false`.
 
-No edites: devuelve el diagnóstico al `build-orchestrator`.
+## Degradación segura
+Si **no puedes completar tu verificación** (herramienta/comando indisponible, app no levantable, `diff`
+vacío inesperado, runner/`npm audit` ausente), **NO devuelvas PASS ni inventes**: devuelve veredicto
+**BLOQUEANTE / INCONCLUSO** con el motivo y qué falta para correr. *La ausencia de evidencia no es evidencia
+de ausencia de problemas.* Un fallo de herramienta **no es N/A**: nunca devuelvas `null` por no poder
+verificar — devuelve bloqueante/`false`.
+
+No edites: devuelve el diagnóstico a la skill `releasing-a-version` (Release Gate, **outer loop**), que
+escribe `releases[].gates`. Cadencia: **una vez por RELEASE**, no por slice.

package/agents/build/simple-design-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: simple-design-reviewer
-description: Revisa el código del slice contra las 4 reglas de diseño simple de Kent Beck y un catálogo de code smells. Úsalo en la fase review, sobre código ya en verde (tests pasando). Requiere que exista código.
+description: Revisa el código del slice contra las 4 reglas de diseño simple de Kent Beck y un catálogo de code smells. Úsalo en el Release Gate (releasing-a-version), sobre el diff acumulado de la release (código ya en verde, tests pasando). Requiere que exista código.
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
@@ -28,6 +28,7 @@ Cuando 2 y 3 chocan, gana eliminar duplicación; cuando 4 choca con 2/3, gana re
 
 ## Salida
 - Hallazgos clasificados **BLOQUEANTE / RECOMENDADO / NIT**, con `archivo:línea` y el refactor sugerido.
-- Veredicto: sin BLOQUEANTES → propón `gates.smell: true`; si hay BLOQUEANTES → mantener en `false`.
+- Veredicto: sin BLOQUEANTES → propón `releases[].gates.smell: true`; si hay BLOQUEANTES → mantener en `false`.
 
-No edites código: devuelve el diagnóstico al `build-orchestrator`.
+No edites código: devuelve el diagnóstico a la skill `releasing-a-version` (Release Gate, **outer loop**),
+que escribe `releases[].gates`. Cadencia: **una vez por RELEASE**, no por slice.

package/agents/build/stack-guardian.md

@@ -1,6 +1,6 @@
 ---
 name: stack-guardian
-description: Garantiza que el diseño y las dependencias del slice respetan el stack y la arquitectura declarados en la sección de requisitos técnicos del PRD del consumidor (ruta declarada en stack-allowlist.json#source), operacionalizados en .claude/config/stack-allowlist.json. Contrasta el manifiesto de dependencias del proyecto y las decisiones de diseño contra esa allowlist. Úsalo en la fase stack y al revisar design.md.
+description: Garantiza que el diseño y las dependencias del slice respetan el stack y la arquitectura declarados en la sección de requisitos técnicos del PRD del consumidor (ruta declarada en stack-allowlist.json#source), operacionalizados en .claude/config/stack-allowlist.json. Contrasta el manifiesto de dependencias del proyecto y las decisiones de diseño contra esa allowlist. Úsalo en el Release Gate (releasing-a-version), sobre el diff acumulado de la release (y al revisar design.md).
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
@@ -35,7 +35,15 @@ Eres el **guardián del stack** del arnés de construcción. Read-only. Defiende
 - Veredicto **STACK-OK** / **DESVIACIÓN**, lista ✓/✗ con `archivo:línea` o nombre de dep.
 - Por cada desviación: el fix (usar la dep/patrón declarado en el PRD del consumidor) o, si es
   intencional, instruir a actualizar `stack-allowlist.json` + nota en `GOVERNANCE.md`.
-- Si OK: propón `gates.stack: true`.
+- Si OK: propón `releases[].gates.stack_arch: true` (el gate de arquitectura del Release Gate; antes se
+  llamaba `gates.stack` por-slice — hoy vive en `releases[]` como `stack_arch`).
 
-No edites: devuelve el diagnóstico al `build-orchestrator`. Nota: el hook `stack-guard.sh`
-bloquea en tiempo real las deps fuera de lista; tú razonas también sobre arquitectura/uso.
+## Degradación segura
+Si **no puedes completar tu verificación** (no hay manifiesto de dependencias legible, `stack-allowlist.json`
+ausente, repo no inspeccionable), **NO devuelvas STACK-OK ni inventes**: devuelve **DESVIACIÓN / INCONCLUSO** con
+el motivo y qué falta para correr. *La ausencia de evidencia no es evidencia de ausencia de problemas.* Un fallo
+de herramienta **no es N/A**: nunca devuelvas `null` por no poder verificar — devuelve bloqueante/`false`.
+
+No edites: devuelve el diagnóstico a la skill `releasing-a-version` (Release Gate, **outer loop**), que escribe
+`releases[].gates`. Cadencia: **una vez por RELEASE**, no por slice. Nota: el hook `stack-guard.sh` bloquea en
+tiempo real las deps fuera de lista; tú razonas también sobre arquitectura/uso.

package/agents/build/ux-krug-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: ux-krug-reviewer
-description: Revisa la UI del slice contra los principios de usabilidad de Steve Krug ("Don't Make Me Think"). Aplica solo a slices con interfaz. Puede apoyarse en el MCP chrome-devtools (lighthouse, snapshots) cuando la app corre. Úsalo en la fase review de épicas con UI.
+description: Revisa la UI del slice contra los principios de usabilidad de Steve Krug ("Don't Make Me Think"). Aplica solo a slices con interfaz. Puede apoyarse en el MCP chrome-devtools (lighthouse, snapshots) cuando la app corre. Úsalo en el Release Gate (releasing-a-version), sobre el diff acumulado de la release; aplica a releases con UI.
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
@@ -28,6 +28,15 @@ slice no tiene UI, devuelve "N/A" para que el gate `ux` quede en `null`. Referen
 
 ## Salida
 - Hallazgos **BLOQUEANTE / RECOMENDADO / NIT** con la pantalla/componente y el fix.
-- Veredicto: sin BLOQUEANTES → `gates.ux: true`; sin UI → `gates.ux: null`.
+- Veredicto: sin BLOQUEANTES → `releases[].gates.ux: true`; sin UI → `releases[].gates.ux: null`.
 
-No edites: devuelve el diagnóstico al `build-orchestrator`.
+## Degradación segura
+Si **no puedes completar tu verificación** (la app no levanta, el MCP chrome-devtools no está disponible, no
+puedes leer los componentes), **NO devuelvas PASS ni inventes**: devuelve veredicto **BLOQUEANTE / INCONCLUSO**
+con el motivo y qué falta para correr. *La ausencia de evidencia no es evidencia de ausencia de problemas.*
+Distingue —como `ux-fidelity-reviewer` (INCONCLUSO ≠ N/A)— el **N/A legítimo** (release **sin UI** → `null`) de
+**"no pude verificar"** (fallo de herramienta → bloqueante/`false`). Reserva el `null` SOLO para el N/A genuino
+(sin UI), nunca para un fallo de herramienta.
+
+No edites: devuelve el diagnóstico a la skill `releasing-a-version` (Release Gate, **outer loop**), que escribe
+`releases[].gates`. Cadencia: **una vez por RELEASE**, no por slice.

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

@@ -41,19 +41,26 @@ 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.
-- Donde el `wiring_checklist[]` diga `passing`, **verifica la `evidence`** (corre/lee el test o el
-  comando citado). Si no reproduce, es `failing`.
-- Corre la suite si hace falta (`Bash`) para confirmar que lo verde es verde 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.
+- Corre la suite (`Bash`) para confirmar que lo verde es verde de verdad.
 
 ## 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`.
+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).
+
+**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
+CABLEADO COMPLETO): sin ejecución no hay evidencia. Registra el motivo. Jamás conviertas "no pude verificar"
+en verde.
 
 Mapeo que aplicará el `build-orchestrator` a `gates.wiring_verified`:
-- **CABLEADO COMPLETO** (ningún hueco tras intentar refutar) → `true` → habilita la fase `dod`.
-- **HUECOS** (≥1) → `false` → el `build-orchestrator` retrocede `phase`, marca los items afectados
-  `failing` y **NO** se cierra `dod`.
+- **CABLEADO COMPLETO** (ningún hueco tras intentar refutar, toda evidencia reproducida) → `true` → habilita la fase `dod`.
+- **HUECOS** (≥1, incluido "no pude ejecutar") → `false` → el `build-orchestrator` retrocede `phase`, marca los
+  items afectados `failing` y **NO** se cierra `dod`.
 
 No editas el estado tú mismo: devuelves el diagnóstico al `build-orchestrator`. Si una regla aquí
 contradice `METODOLOGIA.md` (§1-bis), gana la metodología.

package/commands/build/onboard.md

@@ -91,6 +91,17 @@ No inventes la clasificación: derívala del PRD/Story Map y confírmala con el
 
 Lee `CLAUDE.md`. Encuentra el bloque entre `<!-- BEGIN trycore-build-harness` y `<!-- END trycore-build-harness -->`.
 
+**Guardarraíl de markers (antes de escribir):** verifica que exista **exactamente un** par
+`BEGIN`/`END trycore-build-harness`:
+
+```bash
+b=$(grep -c 'BEGIN trycore-build-harness' CLAUDE.md 2>/dev/null || echo 0)
+e=$(grep -c 'END trycore-build-harness' CLAUDE.md 2>/dev/null || echo 0)
+[ "$b" = 1 ] && [ "$e" = 1 ] || echo "MARKERS_BAD ($b BEGIN / $e END)"
+```
+
+Si imprime `MARKERS_BAD` (0 ó >1 pares) → **STOP**: pide correr `trycore-build update` y **no** edites el bloque.
+
 Reemplaza dentro del bloque los placeholders `{{PRD_TECH_PATH}}`, `{{EXTERNAL_SERVICE_LAYER}}`,
 `{{DETERMINISTIC_LAYER}}`, `{{SENSITIVE_DATA_CATEGORIES}}`, `{{SERVER_SIDE_SECRETS}}`,
 `{{HIGH_STAKES_DECISIONS}}`, `{{DESIGN_SOURCE}}` por los valores confirmados.
@@ -117,6 +128,10 @@ Espejo de la confirmación de scaffold, para `design_source` en `build-state.jso
   `confirmed_at`). El arnés **no genera** el prototipo.
 - Si **no hay UI**: setea `design_source.applies=false` (el mecanismo de fidelidad queda N/A).
 
+Escribe **solo** los campos del schema (`applies`, `source`, `confirmed`, `confirmed_by`, `confirmed_at`,
+`notes`; el objeto es `additionalProperties:false`) y **valida contra `build-state.schema.json` tras escribir**
+(aborta si no valida). Guardarraíl: **una transición = una escritura**; no toques otros campos del estado.
+
 ---
 
 ## Fase 4: Guardar en auto-memory
@@ -154,7 +169,9 @@ CLAUDE.md actualizado. Auto-memory escrita. Los agentes de calidad ya leen tu do
 
 | Acción | Para qué |
 |---|---|
-| skill `building-a-slice` | Abrir un slice (épica EP-XXX) e iniciar el inner loop |
+| `/build:work <descripción>` | Router: enruta a micro-change / slice / release según el cambio |
+| `/build:slice [EP-XXX]` | Abrir un slice (épica EP-XXX) e iniciar el inner loop |
+| `/build:release [release]` | Correr el Release Gate (outer loop) sobre el diff acumulado |
 | `/opsx:new` | Crear un OpenSpec change |
 | `trycore-build doctor` | Verificar openspec/python3/hooks |
 ```

package/commands/build/reflect.md

@@ -37,16 +37,24 @@ Lee `.claude/state/build-state.json` y filtra las entradas de `history[]` con `r
 
 ```bash
 python3 - <<'PY'
-import json
-d = json.load(open(".claude/state/build-state.json"))
-pend = [h for h in (d.get("history") or []) if h.get("reflected") is not True]
+import json, os, sys
+p = ".claude/state/build-state.json"
+if not os.path.exists(p):
+    print("NO_STATE"); sys.exit(0)             # estado ausente → nada que reflexionar, salir
+try:
+    d = json.load(open(p))
+except Exception as e:
+    print("CORRUPT_STATE", e); sys.exit(0)      # JSON inválido → reportar y STOP, NO escribir
+pend = [h for h in (d.get("history") or []) if isinstance(h, dict) and h.get("reflected") is not True]
 for h in pend:
     print(h.get("epica"), "·", h.get("openspec_change"), "·", h.get("branch"), "·", ",".join(h.get("hus") or []))
 print("TOTAL", len(pend))
 PY
 ```
 
-**Si `TOTAL 0`:** informa "No hay slices pendientes de reflexión ✅" y termina. No inventes trabajo.
+**Si `NO_STATE`:** no hay estado → nada que reflexionar; termina. **Si `CORRUPT_STATE`:** el estado está
+corrupto → repórtalo y **detente sin escribir** (no estampes ni edites). **Si `TOTAL 0`:** informa "No hay
+slices pendientes de reflexión ✅" y termina. No inventes trabajo.
 
 Si hay varios, procésalos **de uno en uno** (el más reciente primero), o pregunta al usuario cuál.
 
@@ -116,15 +124,31 @@ Marca el/los slice(s) procesado(s) en `history[]` para que el nudge calle. Usa l
 ```bash
 NOW="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
 python3 - "$NOW" "<openspec_change>" <<'PY'
-import json, sys
+import json, sys, os, tempfile
 now, change = sys.argv[1], sys.argv[2]
 p = ".claude/state/build-state.json"
-d = json.load(open(p))
+try:
+    d = json.load(open(p))
+except Exception as e:
+    print("ABORT: estado ilegible, no estampo:", e); sys.exit(1)
 for h in d.get("history") or []:
-    if h.get("openspec_change") == change:
+    if isinstance(h, dict) and h.get("openspec_change") == change:
         h["reflected"] = True
         h["reflected_at"] = now
-json.dump(d, open(p, "w"), indent=2, ensure_ascii=False)
+# Validación contra el schema ANTES de persistir (si jsonschema está disponible); aborta si no valida.
+try:
+    import jsonschema
+    schema = json.load(open(".claude/state/build-state.schema.json"))
+    jsonschema.Draft202012Validator(schema).validate(d)
+except ImportError:
+    pass  # sin jsonschema: se omite la validación profunda (no se relaja la escritura atómica)
+except Exception as e:
+    print("ABORT: el estado modificado NO valida contra el schema, no escribo:", e); sys.exit(1)
+# Escritura ATÓMICA (una transición = una escritura): tmp + os.replace.
+fd, tmp = tempfile.mkstemp(dir=os.path.dirname(p) or ".", prefix=".build-state.", suffix=".tmp")
+with os.fdopen(fd, "w") as out:
+    json.dump(d, out, indent=2, ensure_ascii=False)
+os.replace(tmp, p)
 print("estampado:", change)
 PY
 ```