@trycore/spec-build-harness 0.5.0 → 0.7.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.5.0",
+  "version": "0.7.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

@@ -8,9 +8,10 @@ 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 | 11 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/` |
+| Agentes | 12 agentes de build | `.claude/agents/build/` |
+| 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,44 @@ 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
+  (Agent Manager). Cambios: (1) **handoff fino en disco** — nuevos campos por-slice `wiring_checklist[]`,
+  `progress_log[]`, `sub_slices[]` (refresh de contexto = estado por defecto); (2) **gate
+  `wiring_verified`** + nuevo agente **`wiring-adversarial-verifier`** (opus, contexto virgen): la
+  verificación es adversarial e independiente del generador, prerequisito duro de `dod` (el DoD
+  declarativo pasa a ser piso); (3) **cimiento pre-construido** — tag `layer: foundational|business` y
+  criterio de DoR que rechaza épicas de negocio que arrastran cimiento no construido (anula la cláusula
+  "no bloquean" para el cimiento); (4) **gate de tamaño** en el DoR (>3 HU ó ≥3 capas → descomposición
+  en sub-slices) + orquestación por fases con subagentes solo-lectura por área; (5) **runner fuera-de-chat
+  `integration-check`** que endurece `journey_smoke` (sin gate nuevo; el `integration` con deps reales
+  sigue en el outer loop); (6) **fidelidad estricta** — para UI, `fidelity` exige verificación visual
+  real vía MCP (INCONCLUSO ya no pasa). Convenciones anti-deriva (producto completo, no MVP) upstreadas
+  al bloque del arnés en `CLAUDE.md`. Se quitó la referencia colgante a `invest-validator` (agente
+  inexistente). Total: **12 agentes**.
+
 - **2026-06-03 · v0.5.0** — Seguro de fuente de diseño + verificación de fidelidad. Nuevo gate de
   proyecto `design_source` (espejo de scaffold, confirmado por humano; el arnés no genera el prototipo)
   con hook `design-source-guard.sh`; criterio DoR "fuente de diseño identificada" para slices con UI;

package/INSTALL.md

@@ -13,6 +13,8 @@ Es el **compañero** de [`@trycore/spec-product-flow`](https://www.npmjs.com/pac
 | Marketplace | `trycore-build` |
 | Versión | `0.5.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).
+
 Hay **dos canales** de instalación: el **CLI npm** (canónico, recomendado para operar en un
 proyecto) y el **plugin nativo** de Claude Code (conveniencia a nivel usuario). Lee el
 [caveat de canales](#5-alternativa-plugin-nativo-con-caveat-de-canales) antes de elegir.
@@ -84,7 +86,7 @@ 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/` — 11 agentes.
+   - `.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.

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 -->` |
 
@@ -63,6 +63,48 @@ por slice. Y el inner loop **no** dispara reviewers pesados. Cada gate vive en e
 
 ---
 
+## 1-bis. Disciplina de horizonte largo (cómo NO dejar cableado a medias)
+
+Una épica multicapa (SPA → gateway → core → cola → worker → IA → persistencia) es **demasiado para una
+sola pasada**: a medida que crece el contexto, la atención se degrada ("context rot") y el modelo
+**recorta, difiere o se declara terminado**. Cuatro disciplinas, todas obligatorias, lo previenen:
+
+1. **Refresh de contexto = estado por defecto (no un fallback).** Cada iteración nace **headless /
+   contexto virgen** y reconstruye el estado desde **disco** (git history + `build-state.json` + logs),
+   **no** desde la conversación viva. El handoff fino vive en el estado: **`wiring_checklist[]`** (un item
+   por escenario AC y por **punto de integración entre capas**) nace `failing` y pasa a `passing`
+   **solo tras prueba real ejecutada**; **`progress_log[]`** deja un hito por sesión. **Mientras quede un
+   item `failing`, el cableado NO está hecho** — una sesión fresca no puede "creer que ya está".
+2. **Unidades pequeñas, de a una (descomposición).** El cimiento se construye antes que el negocio
+   (épicas `layer: foundational` archivadas antes de las `layer: business`, ver §3.1). Una épica que
+   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. 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**
+   (cargar la página, correr la suite, leer la consola). Estas convenciones viven también en el bloque
+   `trycore-build-harness` del `CLAUDE.md` del consumidor (duraderas, sobreviven a la reinstalación).
+
+---
+
 ## 2. La regla del "esqueleto que camina"
 
 > **Paso 1 fundamental — el scaffold (precondición, NO generada por el arnés).** Antes del primer
@@ -97,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.
 
 ---
 
@@ -112,9 +156,9 @@ reference). Un gate no se salta.
 | 1 | `dor` | Validar Definition of Ready de la épica y sus HU | `dor-dod-gatekeeper` | `dor` | `dor.md` |
 | 2 | `change` | `opsx:new` + bloque `## Trazabilidad`; validar enlace (barato) | `opsx:new`, `change-epic-coherence` | `coherence_link` | `link-change-epic.md` |
 | 3 | `red`→`green`→`refactor` | TDD por cada escenario AC (G/W/T) de cada HU | `superpowers:test-driven-development` | `tdd` | — |
-| 4 | `smoke` | Recorrer el journey-hasta-aquí end-to-end | skill `verify`/`run` (+ MCP chrome-devtools) | `journey_smoke` | `mcp-map.md` |
+| 4 | `smoke` | Recorrer el journey-hasta-aquí end-to-end con el **runner determinista fuera-de-chat** en sesión virgen; **UI:** fidelidad por **verificación visual real** (MCP) | runner `integration-check`, skill `verify`/`run` + MCP chrome-devtools, `ux-fidelity-reviewer` | `journey_smoke`, `fidelity` | `mcp-map.md` |
 | 5 | `api`/`data` | Contratos de endpoints + invariantes de datos (si aplican) | `api-contract-tester`, `data-consistency-checker` | `api`, `data` | `newman-tests.md`, `data-consistency.md` |
-| 6 | `dod` | Definition of Done reducido (lee los gates del estado) | `dor-dod-gatekeeper` | `dod` | `dod.md` |
+| 6 | `dod` | **Primero** verificación adversarial independiente del cableado (contexto virgen) → `wiring_verified`; **luego** Definition of Done reducido | `wiring-adversarial-verifier`, `dor-dod-gatekeeper` | `wiring_verified`, `dod` | `dod.md` |
 | 7 | `pr` | Abrir PR + **archivar el change en el mismo PR** | `opsx:archive`, `opsx:sync` | — | `gitflow.md` |
 | 8 | (decisión) | ¿Correr el Release Gate ahora? (default computado, decide el humano) | usuario | — | §4 |
 
@@ -132,12 +176,20 @@ Una épica **no entra a construcción** hasta cumplir todo (lo valida `dor-dod-g
   rama de error/edge, debe tener su escenario.
 - Cada HU pasa los 6 criterios **INVEST**.
 - Dependencias resueltas (las épicas/HU de las que depende están en `history[]` o no bloquean).
+- **Cimiento construido (épicas `layer: business`)**: todo el cimiento que arrastra (autenticación,
+  acceso a datos, arquitectura base, design-system/componentes base) ya existe como épica(s)
+  `layer: foundational` **archivada(s)**. Si arrastra cimiento no construido → STOP: se extrae a una
+  épica fundacional previa. La cláusula "no bloquean" de dependencias **no aplica al cimiento**.
+- **Tamaño acotado (gate de descomposición)**: si la épica supera el umbral —por defecto **> 3 HU** ó
+  **≥ 3 capas tocadas**, configurable— se descompone en `sub_slices[]` construidos de a uno
+  (`journey_smoke` verde entre cada uno). Umbral proporcional, no cuota rígida.
 - Cabe en el stack del PRD (no requiere tecnología fuera de `stack-allowlist.json`).
 - Datos de prueba disponibles o identificables (fixtures sintéticos del dominio).
 
 Si todo ✓ → se abre `active_slice` con `phase: dor`, `gates.dor: true` y el resto en `false`
-(`ux`/`api` en `null` si la épica no toca UI/endpoints). Si algo ✗ → no se abre el slice; se reporta
-qué falta y se vuelve a discovery.
+—incluido **`wiring_verified: false`**— (`fidelity`/`api` en `null` si la épica no toca UI/endpoints;
+`fidelity` arranca en `false` si toca UI). Si algo ✗ → no se abre el slice; se reporta qué falta y se
+vuelve a discovery.
 
 ### 3.2 Definition of Done reducido (gate `dod`)
 
@@ -150,6 +202,12 @@ las revisiones pesadas **no** se piden aquí (van al Release Gate):
   la trazabilidad triple completa va al Release Gate).
 - `data` — invariantes de datos validadas (si el slice toca datos).
 - `api` — Newman 100% verde (o `null` si el slice no tiene endpoints).
+- `fidelity` (slices con UI) — **ESTRICTO**: solo `true` con verificación visual real vía MCP
+  chrome-devtools (screenshot app vs prototipo); INCONCLUSO ya **no** pasa (queda `false`). `null` si
+  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).
 - 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`,
@@ -161,8 +219,10 @@ vía el hook `stack-guard.sh` en tiempo real, no vía subagente.
 
 ### 3.3 Gates por slice y su naturaleza N/A
 
-- `ux` y `api` admiten `null` cuando el slice no tiene UI o endpoints. `null` ≠ abierto: **no
-  bloquea** el DoD.
+- `fidelity` y `api` admiten `null` cuando el slice no tiene UI o endpoints. `null` ≠ abierto: **no
+  bloquea** el DoD. Pero `fidelity` **no** puede quedar `null` si el slice toca UI (debe llegar a
+  `true` por verificación visual real). `wiring_verified` aplica **siempre** (sin `null`) y es
+  prerequisito de `dod`.
 - En `harness_phase: authoring` (sin `package.json`) se puede hacer la Fase 0 (crear/confirmar el
   scaffold) + `dor` + `change`, pero los gates de código (`tdd`, `journey_smoke`, `api`, `data`) **no
   se cierran** hasta tener el scaffold confirmado (gate de proyecto `scaffold.confirmed`, ver §2).
@@ -182,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)
@@ -264,8 +330,9 @@ agente lo lee antes de actuar. Estructura: `version`, `harness_phase`, `active_s
 3. **Gates monótonos hacia adelante.** Un gate solo pasa de `false`→`true` cuando su agente lo
    aprueba. Si una revisión posterior falla, **se vuelve a `false` y `phase` retrocede** (el retroceso
    está permitido y es la forma de manejar fallos tardíos).
-4. **`null` para N/A.** `ux`/`api` son `null` cuando el slice no tiene UI/endpoints; no cuentan como
-   abiertos para el DoD.
+4. **`null` para N/A.** `fidelity`/`api` son `null` cuando el slice no tiene UI/endpoints; no cuentan
+   como abiertos para el DoD. `fidelity` **no** puede ser `null` si toca UI; `wiring_verified` aplica
+   siempre y es prerequisito de `dod`.
 5. **Archivar.** Al completar `opsx:archive`, mover `active_slice` a `history[]` con
    `phase: "archived"` y dejar `active_slice: null`.
 6. **Validar tras escribir** contra el schema (con `jsonschema`/`python3`).
@@ -277,9 +344,10 @@ agente lo lee antes de actuar. Estructura: `version`, `harness_phase`, `active_s
 | `active_slice` (alta) · `gates.dor` · `gates.dod` | `dor-dod-gatekeeper` | slice |
 | `gates.coherence_link` | `change-epic-coherence` | slice |
 | `gates.tdd` | flujo `superpowers:test-driven-development` (vía `build-orchestrator`) | slice |
-| `gates.journey_smoke` · `phase` (transiciones) · `history[]` | `build-orchestrator` | slice |
+| `gates.journey_smoke` · `gates.fidelity` · `phase` · `history[]` · `wiring_checklist[]` · `progress_log[]` · `sub_slices[]` | `build-orchestrator` (fidelity desde `ux-fidelity-reviewer`) | slice |
 | `gates.api` | `api-contract-tester` | slice |
 | `gates.data` | `data-consistency-checker` | slice |
+| `gates.wiring_verified` | `wiring-adversarial-verifier` (independiente, contexto virgen) | slice (antes de `dod`) |
 | `releases[]` (security, smell, ux, coherence, stack_arch, integration, status) | `releasing-a-version` (delega en los reviewers) | release |
 | `harness_phase` | `load-build-state.sh` (SessionStart) | — |
 
@@ -379,6 +447,13 @@ El arnés **no escribe** en `docs/`; cuando una HU no cumple DoR, devuelve el tr
    commits/push directos.
 7. **`integration` con dependencias reales es obligatorio** para cerrar una release; sin él no hay
    release.
-8. El core es **agnóstico**: lo específico del dominio se inyecta vía `/build:onboard` y
-   `stack-allowlist.json`; el ejemplo de referencia vive en `docs/examples/reference/`.
-9. Si una skill, agente o reference contradice este documento, **gana la metodología**.
+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).
+9. **Fidelidad estricta**: para slices con UI, `fidelity` solo cierra con **verificación visual real**
+   (MCP chrome-devtools); INCONCLUSO no pasa.
+10. El core es **agnóstico**: lo específico del dominio se inyecta vía `/build:onboard` y
+    `stack-allowlist.json`; el ejemplo de referencia vive en `docs/examples/reference/`.
+11. Si una skill, agente o reference contradice este documento, **gana la metodología**.

package/README.md

@@ -11,6 +11,8 @@ Ambos paquetes coexisten en el mismo `.claude/` sin colisión: namespaces disjun
 
 ## Cómo se usa (rápido)
 
+> **Guía paso a paso:** [`docs/getting-started.md`](docs/getting-started.md) — Quickstart de 0 a tu primer slice.
+
 ```bash
 # 0) Requisito: OpenSpec (lo usan los comandos /opsx:* y las skills openspec-*)
 npm install -g @fission-ai/openspec
@@ -35,7 +37,7 @@ trycore-build init
 /plugin install trycore-spec-build-harness@trycore-build
 ```
 
-> **Caveat de canales (importante).** El canal **npm CLI es el canónico**: instala los comandos en `.claude/commands/{opsx,build}/`, que namespacean por subcarpeta → `/opsx:*` y `/build:onboard`, y referencia los agentes por su nombre. El canal **plugin** namespacea los componentes bajo el **nombre del plugin** (→ `/trycore-spec-build-harness:*`) por diseño de Claude Code; se ofrece como conveniencia a nivel usuario, pero las cross-references internas (skills que invocan `/opsx:*`, agentes por nombre) están escritas para el canal CLI. **Para operar dentro de un proyecto, usa el CLI.** Los hooks son una única cadena autorresolutiva idéntica en ambos canales (`"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/<script>.sh"`); si se instalan los dos, Claude Code deduplica y el hook dispara una sola vez.
+> **Caveat de canales.** Para operar dentro de un proyecto, **usa el canal CLI** (canónico): comandos namespaceados por subcarpeta (`/opsx:*`, `/build:*`) y agentes por nombre. El plugin los namespacea bajo su propio nombre (`/trycore-spec-build-harness:*`) y las cross-references internas asumen el canal CLI. Los hooks son idénticos en ambos canales (se deduplican si coexisten). Detalle → [`INSTALL.md`](INSTALL.md).
 
 ### Comandos del CLI `trycore-build`
 
@@ -71,16 +73,7 @@ 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. |
-| `/opsx:explore` | Explora el dominio / specs antes de abrir un change. |
-| `/opsx:new` | Crea un nuevo OpenSpec change. |
-| `/opsx:continue` | Retoma un change en curso. |
-| `/opsx:apply` | Aplica los cambios propuestos del change. |
-| `/opsx:verify` | Verifica el change contra sus specs. |
-| `/opsx:archive` | Archiva un change completado. |
-| `/opsx:bulk-archive` | Archiva varios changes en lote. |
-| `/opsx:ff` | Fast-forward de un change. |
-| `/opsx:onboard` | Onboarding de OpenSpec en el repo. |
-| `/opsx:sync` | Sincroniza specs ↔ estado del proyecto. |
+| `/opsx:*` (10) | Ciclo OpenSpec: `explore` · `new` · `continue` · `apply` · `verify` · `archive` · `bulk-archive` · `ff` · `onboard` · `sync`. Detalle → [`docs/commands.md`](docs/commands.md). |
 
 ## Arquitectura
 
@@ -89,7 +82,7 @@ trycore-spec-build-harness/
 ├── METODOLOGIA.md             ← fuente de verdad metodológica (gana ante cualquier skill)
 ├── GOVERNANCE.md              ← gobernanza del paquete + cadencia de auditoría
 ├── .claude-plugin/            ← manifiesto del plugin nativo (canal de conveniencia)
-├── agents/build/              ← 11 agentes revisores (segunda opinión, contexto limpio)
+├── agents/build/              ← 12 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
 │   └── build/                 ← /build:onboard, /build:reflect
@@ -102,7 +95,7 @@ trycore-spec-build-harness/
 └── docs/examples/reference/   ← ejemplo de referencia (fuera del core, excluido de check-agnostic)
 ```
 
-Los **11 agentes** en `agents/build/` son: `build-orchestrator`, `dor-dod-gatekeeper`, `security-reviewer`, `simple-design-reviewer`, `ux-krug-reviewer`, `coherence-three-way` (opus), `stack-guardian`, `api-contract-tester`, `data-consistency-checker`, `change-epic-coherence` y `ux-fidelity-reviewer`.
+Los **12 agentes** en `agents/build/` son: `build-orchestrator`, `dor-dod-gatekeeper`, `security-reviewer`, `simple-design-reviewer`, `ux-krug-reviewer`, `coherence-three-way` (opus), `stack-guardian`, `api-contract-tester`, `data-consistency-checker`, `change-epic-coherence`, `ux-fidelity-reviewer` y `wiring-adversarial-verifier` (opus).
 
 **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/`.
 
@@ -128,7 +121,8 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **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`.
 - ✅ **v0.4.0** — carril `building-a-micro-change` (mantenimiento ligero sin slice) + DoR proporcional a la complejidad.
-- ✅ **v0.5.0 (actual)** — 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.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**.
 
 ## Licencia
 

package/VERSION

@@ -1 +1 @@
-0.5.0
+0.7.0

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

@@ -14,17 +14,41 @@ Protocolo en `.claude/state/README.md`. **Sólo un slice activo a la vez** (mode
 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.
 
+## Trabajo por fases encadenadas (NO one-shot)
+Una épica multicapa es demasiado para una pasada. Trabaja por **fases encadenadas** —**mapear →
+generar → revisar → fix-loop → optimizar**— nunca todo de golpe. Reparte la **exploración** "ancho
+antes que profundo": lanza **subagentes SOLO-LECTURA por área** (frontend/backend/datos) que devuelven
+**síntesis condensada** (~1–2K tokens) para que la sesión gaste su presupuesto en **cablear**, no en
+descubrir. El **cableado lo hace la sesión** (o la sesión de integración), **no** subagentes que
+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. 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
+punto de integración entre capas** que el slice toca, todos en `status: failing`. Pásalos a `passing`
+**solo tras prueba real ejecutada** (registrando `evidence`). Deja un hito en `progress_log[]` por sesión.
+Una sesión fresca retoma desde el estado en disco, no desde la conversación. El `wiring-adversarial-verifier`
+auditará después que cada `passing` tenga evidencia real y que no falte ningún item.
+
 ## Pipeline — inner loop (orden estricto, rápido, SIN subagentes pesados)
 ```
-1. dor      → delega en dor-dod-gatekeeper (abre el slice si pasa)
+1. dor      → delega en dor-dod-gatekeeper (abre el slice si pasa; inicializa wiring_verified:false)
 2. change   → opsx:new + bloque ## Trazabilidad → delega en change-epic-coherence (gate coherence_link, barato)
-3. tdd      → conduce superpowers:test-driven-development (red→green→refactor)
-4. smoke    → recorre el journey-hasta-aquí end-to-end con la skill verify/run (+ chrome-devtools) → gate journey_smoke.
-              Slices con UI: con la app levantada, delega en ux-fidelity-reviewer (compara la(s) pantalla(s)
-              contra el DESIGN_SOURCE) y ESCRIBE gates.fidelity desde su veredicto (FIEL/DESVIACIONES
-              justificadas→true; DESVIACIONES→false; INCONCLUSO (MCP no disponible)→deja con nota; sin UI→null).
+3. tdd      → conduce superpowers:test-driven-development (red→green→refactor); marca items wiring_checklist passing al verde real
+4. smoke    → recorre el journey-hasta-aquí end-to-end con el RUNNER fuera-de-chat integration-check
+              (suite+build+reporte) en sesión/contexto virgen → gate journey_smoke.
+              Slices con UI: con la app levantada, delega en ux-fidelity-reviewer (verificación VISUAL REAL
+              vía MCP chrome-devtools) y ESCRIBE gates.fidelity desde su veredicto (FIEL/DESVIACIONES
+              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      → dor-dod-gatekeeper (cierre por slice, DoD reducido)
+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)
 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)
 ```
@@ -33,7 +57,13 @@ La **unidad de construcción es la épica** (`active_slice.epica`); las HU que c
 `ux-krug-reviewer`, `coherence-three-way` y `stack-guardian` (arquitectura) corren **una vez por
 release** en la skill `releasing-a-version`. Las deps las vigila el hook `stack-guard.sh`.
 El `ux-fidelity-reviewer` **sí** corre aquí (en `smoke`): es barato (la app ya está levantada) y vivo
-por-slice; no es la revisión pesada de UX/Krug (esa sigue en `releasing-a-version`).
+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. 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.
@@ -42,7 +72,12 @@ por-slice; no es la revisión pesada de UX/Krug (esa sigue en `releasing-a-versi
 - **Una escritura por transición**: actualiza `phase`, el gate tocado, `updated_at` (ISO UTC),
   `updated_by: build-orchestrator`. No toques otros campos.
 - **Gate `api`** puede quedar en `null` si la épica no tiene endpoints (no bloquea DoD). `data` solo
-  si el slice toca datos.
+  si el slice toca datos. **`fidelity`** no puede quedar `null` si el slice toca UI (debe ser `true`
+  por verificación visual real; INCONCLUSO → `false`).
+- **`dod` exige `wiring_verified: true`.** No cierres `dod` sin que el `wiring-adversarial-verifier`
+  haya dado verde. El DoD del gatekeeper es declarativo (piso); el verificador independiente es el arreglo.
+- **Producto completo, no MVP.** Construye el alcance acordado entero. **Recortar o diferir es
+  bloqueante explícito** que requiere acuerdo del equipo — nunca lo decides tú. No derives en lo complejo.
 - Si `harness_phase` = `authoring` (no hay `package.json`), los gates de código (tdd, journey_smoke,
   api, data) no pueden cerrarse: dilo y detente tras preparar lo que sí aplica.
 - **Tras `archived`**, calcula el default del Release Gate y pásalo a la skill: (a) ¿esta épica

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/dor-dod-gatekeeper.md

@@ -26,18 +26,25 @@ cumplen; lista cada una con ✓/✗:
 4. **Cada HU**: AC en formato **Given/When/Then**, **proporcional a `complejidad`** (`trivial`/baja →
    1–2; `media` → 3; `alta` → 3–5), cubriendo los modos de fallo que existen (happy + error/edge
    reales). No exijas 3–5 a una HU trivial; sí exige el escenario de toda rama de error/edge que exista.
-5. **Cada HU** pasa los 6 criterios **INVEST** (si dudas, invoca al agente `invest-validator`).
+5. **Cada HU** pasa los 6 criterios **INVEST** (Independent, Negotiable, Valuable, Estimable, Small, Testable); evalúalos tú mismo.
 6. Dependencias declaradas (otras épicas/HU) están en `history[]` del estado o marcadas done.
-7. El alcance de la épica cabe en el stack declarado del PRD (allowlist) (no exige tecnología fuera de la allowlist).
-8. **Fuente de diseño (solo slices con UI)**: si la épica toca UI, `design_source.confirmed===true`
+7. **Cimiento construido (épicas `layer: business`)**: si la épica es de negocio, todo el cimiento que
+   arrastra (autenticación, acceso a datos, arquitectura base, design-system/componentes base) ya existe
+   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.
+8. **Tamaño acotado**: si la épica supera el umbral del gate de descomposición —heurística por defecto
+   **> 3 HU** ó **≥ 3 capas tocadas** (configurable por proyecto)— **no la abras como slice único**:
+   instruye descomponerla en `sub_slices[]` construidos de a uno (`journey_smoke` verde entre cada uno).
+9. **Fuente de diseño (solo slices con UI)**: si la épica toca UI, `design_source.confirmed===true`
    (fuente visual de verdad declarada para el proyecto) y la épica apunta a la(s) pantalla(s)
    equivalente(s) del `DESIGN_SOURCE`. Si no toca UI, este criterio es N/A.
 
 Si DoR pasa: propón abrir `active_slice` con `epica`, `hus` (lista de las HU cubiertas),
 `openspec_change` (kebab del título de la épica), `branch: feature/ep-xxx-<slug>`, `phase: dor`,
-`gates: { dor: true, tdd: false, journey_smoke: false, coherence_link: false, data: false, fidelity: false, dod: false }`
-(`api` en `null` si la épica no toca endpoints; **`fidelity` en `null` si la épica NO toca UI**; añade
-`data: null`-equivalente omitiéndolo si no toca datos). Si falla: reporta ✗ y NO abras el slice.
+`gates: { dor: true, tdd: false, journey_smoke: false, coherence_link: false, data: false, fidelity: false, wiring_verified: false, dod: false }`
+(`api` en `null` si la épica no toca endpoints; **`fidelity` en `null` si la épica NO toca UI** —si toca UI
+arranca en `false`—; `wiring_verified` **siempre** arranca en `false`). Si falla: reporta ✗ y NO abras el slice.
 
 ## Definition of Done (gate `dod`) — antes de archivar (DoD **reducido**, por slice)
 Pasa SOLO si **todos** estos gates del **inner loop** están en `true` (o `null` cuando N/A):
@@ -46,10 +53,19 @@ Pasa SOLO si **todos** estos gates del **inner loop** están en `true` (o `null`
 3. `coherence_link` — `change-epic-coherence` confirma el enlace change↔épica (`openspec validate` ok).
 4. `data` — `data-consistency-checker` verde (si el slice toca datos).
 5. `api` — `api-contract-tester` verde (o `null` si sin endpoints).
-6. `fidelity` — `true` (FIEL o DESVIACIONES justificadas) o `null` (slice sin UI). INCONCLUSO
-   (MCP no disponible) se registra en `notes`, no bloquea. Es gate **vivo** de inner loop, no la revisión Krug.
-7. Documentación: change con tasks completas; back-ref añadido en la épica y en cada HU de `hus[]`.
-8. Hooks verdes (automáticos): `lint-typecheck.sh`, `stack-guard.sh`, `gitflow-guard.sh`.
+6. `fidelity` — `true` (FIEL o DESVIACIONES justificadas) o `null` (slice sin UI). **ESTRICTO para UI**
+   (`design_source.applies===true`): solo `true` si hubo **verificación visual real** vía MCP
+   chrome-devtools (screenshot app vs prototipo). **INCONCLUSO ya NO pasa**: sin MCP queda `false` y el
+   `dod` no cierra (correr donde haya MCP). Es gate **vivo** de inner loop, no la revisión Krug.
+6-bis. **Sub-slices completos**: si `active_slice.sub_slices[]` no está vacío, **todos** deben estar en
+   `status: done` (cada uno con su `journey_smoke` verde). Una épica descompuesta no cierra `dod` con
+   sub-slices pendientes (sería cierre prematuro de alcance).
+7. **`wiring_verified`** — `true`. Prerequisito **duro** de `dod`: lo cierra el `wiring-adversarial-verifier`
+   (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`.
+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`.
 
 **NO valides aquí** `security`, `smell`, `ux`, `coherence` (triple completa) ni `stack` (arquitectura):
 esos son del **Release Gate** (`releasing-a-version`, `release-dod.md`), cadencia por release.

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.