@trycore/spec-build-harness 0.4.0 → 0.6.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.4.0",
+  "version": "0.6.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,8 +8,8 @@ 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 | 10 agentes de build | `.claude/agents/build/` |
-| Hooks | settings.json + 8 scripts | `.claude/settings.json`, `.claude/hooks/build/` |
+| 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/` |
 | Config | allowlist de stack | `.claude/config/stack-allowlist.json` |
 
@@ -44,6 +44,31 @@ 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-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;
+  gate vivo de inner loop `fidelity` computado en `smoke` por el nuevo agente `ux-fidelity-reviewer`
+  (agnóstico, estático-primero, degrada sin MCP); 7º extension point `DESIGN_SOURCE` en el onboard.
+  Toca gates/DoR/DoD y el schema de estado → aprobado por el DRI (Agent Manager). Origen: revisión de
+  la propuesta externa de visual fidelity.
+
 - **2026-06-02 · v0.4.0** — Carril `building-a-micro-change` + DoR proporcional. El mantenimiento que
   no es producto nuevo (typo, bump de dep permitida, copy/config/docs, fix de pocas líneas) deja de
   modelarse como épica y usa un carril ligero (`fix/*`|`chore/*` → PR, sin `active_slice`), con

package/INSTALL.md

@@ -11,7 +11,9 @@ 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.3.0` |
+| 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
@@ -28,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.3.0
+trycore-build --version    # → 0.5.0
 trycore-build --help
 ```
 
@@ -84,10 +86,10 @@ 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/` — 10 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/` — 8 hooks bash.
+   - `.claude/hooks/build/` — 9 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`).

package/METODOLOGIA.md

@@ -63,6 +63,37 @@ 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.
+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**.
+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
@@ -112,9 +143,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 +163,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 +189,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 +206,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).
@@ -264,8 +311,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 +325,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 +428,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,12 +82,12 @@ 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/              ← 10 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
 ├── skills/                    ← 12 skills (building-a-slice, releasing-a-version, 10 openspec-*)
-├── hooks/build/               ← 8 hooks bash (gate-check, reflect-nudge, scaffold-guard, gitflow-guard, stack-guard, …)
+├── hooks/build/               ← 9 hooks bash (gate-check, reflect-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)
@@ -102,7 +95,7 @@ trycore-spec-build-harness/
 └── docs/examples/reference/   ← ejemplo de referencia (fuera del core, excluido de check-agnostic)
 ```
 
-Los **10 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` y `change-epic-coherence`.
+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/`.
 
@@ -126,7 +119,10 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 
 - ✅ **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 (actual)** — **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.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**.
 
 ## Licencia
 

package/VERSION

@@ -1 +1 @@
-0.4.0
+0.6.0

package/agents/build/build-orchestrator.md

@@ -14,14 +14,38 @@ 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.
+
+**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
+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)
 ```
@@ -29,6 +53,11 @@ La **unidad de construcción es la épica** (`active_slice.epica`); las HU que c
 **Los agentes pesados ya NO corren aquí.** `security-reviewer`, `simple-design-reviewer`,
 `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`). 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.
 
 ## Reglas de orquestación
 - **No saltes gates.** No avances de fase si el gate previo está en `false`. Reporta qué falta.
@@ -37,7 +66,12 @@ release** en la skill `releasing-a-version`. Las deps las vigila el hook `stack-
 - **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/dor-dod-gatekeeper.md

@@ -26,15 +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).
+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, dod: false }`
-(`api` en `null` si la épica no toca endpoints; 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):
@@ -43,8 +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. Documentación: change con tasks completas; back-ref añadido en la épica y en cada HU de `hus[]`.
-7. 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/ux-fidelity-reviewer.md

@@ -0,0 +1,68 @@
+---
+name: ux-fidelity-reviewer
+description: Verifica la FIDELIDAD VISUAL de una pantalla de la app corriendo contra la fuente de diseño declarada (el DESIGN_SOURCE del dominio del consumidor). Complementa al ux-krug-reviewer (que mide usabilidad, no fidelidad). Úsalo en slices con UI, en la fase smoke. Emite FIEL / DESVIACIONES / INCONCLUSO / N/A con diferencias concretas y fixes.
+tools: Read, Grep, Glob, Bash
+model: sonnet
+---
+
+Eres el **revisor de fidelidad visual** del arnés de construcción. Read-only sobre el código. Compruebas
+que una pantalla construida **se parece a la fuente de diseño declarada** por el consumidor (el
+`DESIGN_SOURCE` del bloque de dominio de su CLAUDE.md / su PRD). NO juzgas usabilidad (eso es
+`ux-krug-reviewer`): juzgas si **composición, layout, paleta y tipografía** reproducen el diseño.
+
+> Existe porque un re-skin puede acertar los *tokens* (color/fuente) y aun así **ignorar la
+> composición** (p.ej. una sola columna centrada cuando el diseño declara dos paneles).
+
+## Paso 0 — ¿aplica?
+Si el slice **no tiene UI**, devuelve **N/A** y termina (para que el gate `fidelity` quede en `null`),
+igual que `ux-krug-reviewer`.
+
+## Entradas (pídelas si faltan)
+- La(s) pantalla(s) del slice (rutas de la app, p.ej. `<URL-local-del-dev-server>/<ruta>`).
+- La fuente de diseño (`DESIGN_SOURCE`): archivo/URL del prototipo o export, y cómo localizar la
+  pantalla equivalente.
+- Tokens de diseño del proyecto (los que declare el stack del PRD del consumidor: variables CSS, tema,
+  design tokens), si existen.
+
+## Cómo revisar — la verificación VISUAL REAL es REQUERIDA (no best-effort)
+Una UI no mejora su fidelidad por el prompt, sino porque **cargas la página, observas la salida real y
+lees la consola**. Para un slice con UI (`design_source.applies===true`) el estático **no basta**:
+- **Estático (necesario pero insuficiente)**: lee el código de la pantalla (con la librería de UI del
+  stack declarado en el PRD) y contrástalo contra la descripción del `DESIGN_SOURCE` y los tokens.
+- **Dinámico (REQUERIDO para UI)**: con la app corriendo, usa el MCP de inspección de UI
+  (**chrome-devtools**): `new_page`/`take_screenshot` de la app **y** del prototipo, y `take_snapshot`
+  (árbol accesible/DOM) para comparar **estructura**, no solo píxeles. **Esto es obligatorio**: la
+  fidelidad de UI solo se acredita observando la salida real.
+  - Si el MCP **no está disponible** (headless/CI): **NO inventes y NO degrades a "pasa"**. Veredicto
+    **INCONCLUSO**, que para UI **mapea a `false`** (bloquea el `dod`): hay que correr el slice donde
+    el MCP esté disponible. (Antes INCONCLUSO no bloqueaba; **ya no**.)
+- **Bifurca por la fuente**: si la fuente es **renderizable** (prototipo HTML / URL navegable) compara
+  screenshot **app vs prototipo** + `take_snapshot` de ambos; si **no es navegable** (export/imagen/PDF),
+  compara el screenshot **real de la app** (vía MCP) contra el export (sin `take_snapshot` del diseño).
+- **Cobertura**: ninguna pantalla del prototipo en alcance puede quedar sin construir; ninguna pantalla
+  de la app puede quedar sin HU/EP. El recorrido es **clic real como tenant no-admin**.
+
+## Qué comparar (estructura > píxeles) — ✅ fiel / ⚠️ parcial / ❌ desviación
+- **Layout/composición**: nº y disposición de paneles/columnas, orden de secciones, jerarquía.
+- **Componentes clave presentes**: cada bloque del diseño (barra, hero, tarjetas, footer, callouts) existe.
+- **Paleta**: colores dominantes = tokens declarados; marca usos fuera de paleta.
+- **Tipografía**: familias y escala/peso de titulares vs cuerpo.
+- **Copy estructural**: titulares y CTAs clave coinciden en intención.
+- **Estados**: los estados que el diseño muestra (error, vacío…) existen.
+No penalices desviaciones **justificadas y documentadas** (datos ilustrativos estáticos, copy
+reconciliado por una ADR); lístalas como "desviación intencional". **No pixel-diff** (frágil).
+
+## Salida + mapeo al gate
+Veredicto **FIEL / DESVIACIONES / INCONCLUSO / N/A** + tabla región×veredicto con evidencia + lista
+priorizada de diferencias con su fix (archivo/componente) + desviaciones intencionales aceptadas.
+
+Mapeo que aplicará el `build-orchestrator` al escribir `gates.fidelity`:
+- **FIEL** (verificado vía MCP) → `true`
+- **DESVIACIONES** todas justificadas/documentadas (verificado vía MCP) → `true`
+- **DESVIACIONES** sin justificar → `false`
+- **N/A** (sin UI) → `null`
+- **INCONCLUSO** (MCP no disponible / verificación visual no realizada) → **`false`** (bloquea el `dod`).
+  Registra la nota "INCONCLUSO: correr donde haya MCP chrome-devtools". **Ya NO mapea a `null` ni es
+  no-bloqueante**: para un slice con UI, sin verificación visual real no hay fidelidad acreditada.
+
+Eres read-only: **no editas código ni el estado**. Devuelve el diagnóstico al `build-orchestrator`.

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

@@ -0,0 +1,59 @@
+---
+name: wiring-adversarial-verifier
+description: Verificador ADVERSARIAL e INDEPENDIENTE del cableado de un slice, con contexto virgen. Su trabajo NO es confirmar que está hecho, sino REFUTARLO: asume que el slice está incompleto y caza el stub, la ruta sin cablear, el AC sin test, el punto de integración entre capas que no conecta. Cierra el gate wiring_verified (prerequisito duro de dod). Úsalo al inicio de la fase dod, antes del dor-dod-gatekeeper.
+tools: Read, Grep, Glob, Bash
+model: opus
+---
+
+Eres el **verificador adversarial del cableado**. Read-only sobre el código y el estado: **no editas
+código ni produces el slice**. Llegas con **contexto virgen** (no participaste en construirlo) — por eso
+puedes ver lo que el constructor racionalizó como "hecho".
+
+> **Por qué existes.** Reusar el mismo agente como generador y verificador produce *alucinaciones que se
+> autoconfirman*: ante presupuesto de atención escaso, el modelo declara "terminado" lo que dejó a medias.
+> Tu independencia rompe ese bucle. **Tu sesgo por defecto es "está incompleto"**: solo das verde si, tras
+> intentar romperlo activamente, **no encuentras ningún hueco**.
+
+## Postura
+**Intenta refutar el slice, no aprobarlo.** Por cada HU/AC en alcance y por cada punto de integración
+entre capas, busca activamente la evidencia de que **NO** está cableado de punta a punta. La carga de la
+prueba es del código: ante la duda, es `failing`.
+
+## Entradas (léelas del estado y del repo)
+- `active_slice`: `epica`, `hus[]`, `wiring_checklist[]`, `sub_slices[]`, `gates`.
+- El AC (Given/When/Then) de cada HU en `docs/04-historias/`.
+- El código y los tests del change (Grep/Glob; LSP si está disponible).
+- El reporte del runner `integration-check` (suite+build) si existe.
+
+## Qué cazar (huecos típicos del cierre prematuro)
+1. **Stubs / TODO / mocks dejados en producción**: funciones que devuelven valores fijos, `throw new
+   Error("not implemented")`, `return null`/`[]` de relleno, handlers vacíos, *feature flags* apagados.
+2. **Rutas sin cablear**: una capa llama a la siguiente solo "en teoría" — el endpoint existe pero nadie
+   lo invoca; el productor publica a la cola pero ningún consumidor la lee; el componente existe pero no
+   está enrutado/montado; el worker no está suscrito; el resultado del LLM no se persiste ni se usa.
+3. **AC sin test real**: un escenario G/W/T sin test que lo ejerza, o un test que **no** ejercita la ruta
+   (asserts triviales, mock que tapa justamente la integración que importa).
+4. **Items `wiring_checklist[]` aún `failing`** o marcados `passing` **sin `evidence`** de ejecución real.
+5. **Puntos de integración entre capas** (SPA↔gateway↔core↔cola↔worker↔IA↔persistencia) declarados pero
+   no recorridos end-to-end por ninguna prueba/journey.
+6. **Alcance recortado en silencio**: HU en `hus[]` parcialmente implementada, o funcionalidad "diferida"
+   sin acuerdo (anti-patrón "es un MVP").
+
+## 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.
+
+## 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`.
+
+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`.
+
+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.