@trycore/spec-build-harness 0.8.4 → 0.10.0

package/skills/prototyping-screens/references/extraction.md

@@ -0,0 +1,57 @@
+# Extracción viva del UX/UI implementado (modo feature)
+
+Protocolo para capturar el **contexto rico real** de la app implementada antes de generar
+pantallas nuevas. La lección de fondo: la fidelidad no sale de "mirar un screenshot", sale de
+**CSS computado real + capturas multi-viewport + estructura**. Todo esto exige la app corriendo
+y un MCP de inspección de UI habilitado (p.ej. chrome-devtools para web); sin ellos, la skill
+ya hizo STOP antes de llegar aquí.
+
+## 1. Elegir pantallas representativas (2-3)
+
+Criterio: cubrir los patrones que la pantalla nueva va a necesitar —
+- la pantalla de **navegación/layout principal** (caparazón: menús, cabecera, panel central);
+- una pantalla del **mismo tipo** que la que se va a generar (listado si va a haber listado,
+  formulario si va a haber formulario, detalle si detalle);
+- si existe, una pantalla ya validada como fiel (`gates.fidelity: true` en `history[]`).
+
+## 2. Capturar por cada pantalla
+
+1. **Screenshots en 3 viewports** — desktop, tablet y mobile (redimensionar la página antes de
+   cada captura). Guardan la referencia de composición y densidad.
+2. **CSS computado de elementos clave** — vía el MCP (evaluar `getComputedStyle` sobre):
+   - tipografía real: `font-family`, `font-size`, `font-weight`, `line-height` de titular
+     principal, titular secundario, cuerpo y etiquetas;
+   - color real: `color`, `background-color`, `border-color` de superficie, texto, acción
+     primaria, acción secundaria y estados de énfasis;
+   - espaciado real: `padding`/`margin`/`gap` de los contenedores estructurales y de los
+     componentes repetidos (tarjetas, filas, campos);
+   - `border-radius` y `box-shadow` de los componentes elevados.
+3. **Árbol estructural** — snapshot del árbol accesible/DOM de la pantalla: número y disposición
+   de paneles, orden de secciones, jerarquía. Es la referencia de **composición** (estructura >
+   píxeles).
+
+## 3. Destilar y reconciliar tokens
+
+1. Consolida lo capturado en un conjunto de tokens (paleta, tipografía, spacing scale, radios,
+   sombras). Los valores repetidos entre pantallas son los tokens; los valores únicos son ruido.
+2. **Si `docs/05-prototipo/tokens.css` ya existe → reconciliar**:
+   - **La app real gana** sobre lo declarado: si el token declarado dice un valor y el CSS
+     computado dice otro de forma consistente, actualiza el token al valor real.
+   - Cada divergencia se **reporta al humano como drift** (tabla token → declarado → real →
+     pantallas donde se observó). El drift es señal de que prototipo viejo y app se separaron:
+     el humano decide si además hay que corregir la app (fuera del alcance de esta skill).
+3. Si no existe `tokens.css`, créalo desde lo extraído y genera/actualiza `DESIGN.md`
+   (`assets/DESIGN.md.template`) con **Procedencia: extracción viva** y la fecha.
+
+## 4. Empaquetar el contexto para la generación
+
+Antes de generar, deja explícito el paquete de referencia que usará la pantalla nueva:
+- `tokens.css` reconciliado;
+- screenshots de referencia (composición/densidad) de las pantallas capturadas;
+- el árbol estructural del layout principal (dónde vive el contenido en el caparazón);
+- las reglas de componentes observadas (densidad de tablas, anatomía de formularios, etc.),
+  anotadas en `DESIGN.md` si no estaban.
+
+La generación no "interpreta" este paquete: **copia valores exactos**. Toda desviación deliberada
+se anota como desviación intencional en `notas` del manifest para que `ux-fidelity-reviewer` no
+la penalice después.

package/skills/prototyping-screens/references/self-check.md

@@ -0,0 +1,40 @@
+# Auto-verificación visual del prototipo (ambos modos)
+
+El prototipo no se da por bueno porque "se escribió bien": se **renderiza de verdad y se observa
+la salida real** antes de presentarlo al humano. Misma filosofía que el gate `fidelity`
+(verificación visual real, no best-effort), aplicada en dirección inversa: aquí lo verificado es
+el prototipo recién generado.
+
+## Protocolo por pantalla generada
+
+1. **Renderizar**: abrir el HTML vía `file://` con el MCP de inspección de UI (nueva página).
+   Si el archivo no renderiza limpio (recursos rotos, consola con errores), corregir antes de
+   comparar nada.
+2. **Capturar**: screenshot en **3 viewports** (desktop, tablet, mobile) + snapshot del árbol
+   accesible/DOM.
+3. **Comparar** según el modo:
+   - **Feature** — contra el paquete de extracción (`extraction.md`): ¿la tipografía computada
+     coincide token a token? ¿la paleta usada es la reconciliada, sin colores fuera? ¿la densidad
+     (spacing computado) y el patrón de layout replican los de las pantallas capturadas? ¿la
+     pantalla "parece una más" de la app?
+   - **Greenfield** — contra `DESIGN.md`/`tokens.css`: **cero valores visuales fuera de tokens**
+     (inspeccionar computed styles de los elementos clave); y **consistencia del lote**: mismas
+     resoluciones de componente (el mismo tipo de elemento se ve igual) entre las pantallas
+     generadas en esta tanda.
+4. **Corregir y re-renderizar** cada divergencia encontrada. **Máximo 3 iteraciones** por
+   pantalla; si a la tercera no converge, **parar y reportar al humano** el delta restante
+   (qué difiere, dónde, valor esperado vs observado) — nunca presentar como buena una pantalla
+   que no pasó su self-check.
+5. **Registrar**: anotar en `manifest.json` los `viewports_verificados` de la pantalla. El
+   `estado` sigue siendo `borrador`: el self-check **no aprueba** — aprobar es del humano.
+
+## Reglas
+
+- **Sin pixel-diff**: la comparación es estructural/semántica (composición, tokens computados,
+  densidad, jerarquía), igual que `ux-fidelity-reviewer`. El pixel-diff es frágil y no discrimina
+  desviaciones que importan de ruido de render.
+- **Estructura > píxeles**: una columna de más o un panel ausente pesa más que 2px de padding.
+- Las **variantes de estado** (`<slug>--<estado>.html`) pasan el mismo protocolo (suelen ser más
+  baratas: heredan la composición de la base).
+- El self-check corre **por lote** en greenfield (tras generar cada tanda) y **por pantalla** en
+  feature (pocas pantallas, más exigencia de encaje con la app).

package/skills/releasing-a-version/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: releasing-a-version
-description: Use when closing a release of the product — runs the heavy review gates ONCE over the accumulated diff of a release line (security, design/smell, UX/Krug, three-way coherence, architecture, and full end-to-end integration with real deps), instead of per epic. This is the outer loop; the per-epic inner loop lives in building-a-slice. Trigger after archiving an epic when the user accepts the Release Gate, or when a Story Map release line is complete. Records results in build-state.json releases[].
+description: Use when closing a release of the product — runs the heavy review gates ONCE over the accumulated diff of a release line (security, design/smell, UX/Krug, three-way coherence, architecture, and full end-to-end integration with real deps), instead of per epic. This is the outer loop; the per-epic inner loop lives in building-a-slice. Trigger after archiving an epic when the user accepts the Release Gate, or when a Story Map release line is complete. Reports the six measured verdicts through the agent surface (release-ops.sh verdict); closing the release stays a human act in the hub console.
 ---
 
 # Release Gate (outer loop) — Build
@@ -20,8 +20,13 @@ de épicas de la release son las que vas a auditar en bloque.
 - O explícitamente: "corre el Release Gate de R1".
 
 ## Principio de operación
-- **Una sola fuente de verdad**: `.claude/state/build-state.json` → array `releases[]`. Lee antes,
-  escribe una entrada por release.
+- **Una sola fuente de verdad, según el modo** (`bash .claude/hooks/build/slice-ops.sh mode`): en
+  `dual`/`runtime` la release vive en el runtime y cada gate se reporta con
+  `bash .claude/hooks/build/release-ops.sh verdict <line> <gate> <pass|fail|na>`; en `legacy`, en el
+  array `releases[]` del fichero local (protocolo en `building-a-slice/references/state-protocol.md`).
+- **Reportar es de agentes; cerrar es de humanos** (spec §2). El agente mide y reporta los seis
+  veredictos; **la release la cierra una persona en la consola del hub** — el token de agente no
+  puede hacerlo. `release-ops.sh close-hint <line>` imprime el recordatorio.
 - **Sobre el diff acumulado**: el alcance es el rango de commits de todas las épicas de la release
   (desde el merge anterior a la primera épica de la release hasta `main`).
 - **Delega en subagentes** (devuelven síntesis, protegen el contexto).
@@ -32,9 +37,9 @@ Esta skill es el **hogar primario** de los workflows del arnés: el Release Gate
 (`O(releases)`), fuera del camino caliente del inner loop, y **no** duplica el inner loop (ni TDD ni gates por
 slice). Los `*.workflow.js` bajo `workflows/` son **plantillas de referencia** (no scripts a correr verbatim;
 si contradicen `METODOLOGIA.md`, gana la metodología). Reglas duras:
-- **Read-only sobre el estado.** La plantilla devuelve veredictos; **esta skill** es la única que escribe
-  `releases[]` (una entrada por release, validando contra `build-state.schema.json`, `updated_by:
-  releasing-a-version`). Parciales **no** promueven a `passed`.
+- **Read-only sobre el estado.** La plantilla devuelve veredictos; **esta skill** es la única que los
+  reporta (un `release-ops.sh verdict` por gate; en modo legacy, una entrada en `releases[]` del
+  fichero). El agregado lo hace el runtime: **parciales no promueven a `passed`**.
 - **`integration` fuera del paralelo.** Los 5 reviewers pesados van en `parallel()`; el gate `integration`
   (journey completo con **deps reales**) es **secuencial** vía `verify`/`run` y **no** delega en un reviewer.
 
@@ -54,14 +59,19 @@ Ver `workflows/README.md`. Hoy: `workflows/release-gate.workflow.js`.
 Checklist de cierre: `references/release-dod.md`.
 
 ## Cómo proceder
-1. Lee `build-state.json`; identifica la release y sus épicas (cruza con `docs/02-user-story-map/`).
-2. Crea/actualiza la entrada en `releases[]` con `status: pending`.
+1. Identifica la release y sus épicas: `bash .claude/hooks/build/slice-ops.sh status` + el Story Map
+   (`docs/02-user-story-map/`).
+2. No hay entrada que crear: la línea de release existe en el runtime; los veredictos la van poblando.
 3. Dispara los subagentes **en paralelo** sobre el diff acumulado (devuelven síntesis).
 4. Corre el gate de **integración** con la skill `verify`/`run`: el journey completo, deps reales.
-5. Cuando todos los gates pasan (o `null` cuando N/A) → `status: passed`, escribe los `gates` y
-   `updated_by: releasing-a-version`. Si algo falla → `status: failed` y lista los hallazgos
-   bloqueantes; el usuario los corrige como un slice normal (fix en `building-a-slice`) y se
-   re-corre el Release Gate.
+5. Reporta **cada** gate en cuanto lo tengas medido, con su evidencia:
+   `release-ops.sh verdict R1-mvp security pass --evidence-file informe.txt` (usa `na` cuando el gate
+   no aplique — p. ej. `ux` en una release sin UI). Un `rc 6` es el servidor rechazando: muestra su
+   razón, no reintentes. Sin red, el veredicto se encola (`rc 5`) y se entrega al reconectar.
+6. Cuando los seis estén reportados, **avisa al humano para el cierre**
+   (`release-ops.sh close-hint R1-mvp`): el agente no cierra releases. Si algún gate quedó `fail`,
+   lista los hallazgos bloqueantes; el usuario los corrige como un slice normal (fix en
+   `building-a-slice`) y se re-corre el Release Gate.
 
 > **Opcional — conducir con workflow (releases grandes).** El fan-out del paso 3 puede conducirse con la
 > plantilla `workflows/release-gate.workflow.js` (referencia, no obligatoria): SOLO paraleliza los 5 reviewers
@@ -69,12 +79,11 @@ Checklist de cierre: `references/release-dod.md`.
 > **fuera** del `parallel()`. Pasa por `args` lo que computes **read-only**: `diffRange`, `hasUI` y **`hus[]`**
 > (los IDs de todas las HU de las épicas de la release) — con ≥ 3 HUs el carril `coherence` se shardea por HU
 > (lossless, fail-closed) en vez de recorrerlas en un solo agente; con menos, corre monolítico como siempre.
-> El resultado se escribe igual en `releases[]` respetando **una escritura por
-> entrada** y **validando contra el schema**; esta skill sigue siendo la única escritora. Parciales NO
-> promueven a `passed`.
+> El resultado se reporta igual, gate a gate, con `release-ops.sh verdict`; esta skill sigue siendo la
+> única que reporta veredictos de release. Parciales NO promueven a `passed` (lo agrega el runtime).
 
 ## Reglas duras
 - **No dupliques el inner loop.** Aquí no se hace TDD ni se cierran gates por slice.
-- **Integración con deps reales es obligatoria** para `status: passed` — es el gate que faltaba y
+- **Integración con deps reales es obligatoria** para que la release pueda cerrarse — es el gate que faltaba y
   por el que el producto "no funcionaba al terminar". No se acepta con todo stubbeado.
 - Si una regla aquí contradice la metodología Trycore (`METODOLOGIA.md`), **gana la metodología**.

package/skills/releasing-a-version/references/release-dod.md

@@ -1,8 +1,8 @@
 # Release Gate — checklist de salida (outer loop)
 
 Una **release** (línea de release del Story Map) no se da por cerrada hasta cumplir TODO esto. Se
-corre **una vez** sobre el diff acumulado de todas sus épicas. Resultado en `build-state.json` →
-`releases[]`.
+corre **una vez** sobre el diff acumulado de todas sus épicas. Resultado en el runtime (veredictos por `release-ops.sh verdict`; en modo legacy, en `build-state.json` →
+`releases[]`). El **cierre** de la release lo hace una persona en la consola del hub, nunca el agente.
 
 - [ ] **`security`** — `security-reviewer` sin hallazgos CRÍTICO/ALTO sobre el diff completo de la release; claves de servicios externos solo server-side; datos sensibles / PII regulados (según el PRD del consumidor) no persistidos crudos; salida de cualquier servicio externo/IA tratada como input no confiable y validada contra esquema antes de alimentar la capa de decisión.
 - [ ] **`smell`** — `simple-design-reviewer` sin bloqueantes sobre el diff acumulado; 4 reglas de Beck respetadas.
@@ -12,9 +12,11 @@ corre **una vez** sobre el diff acumulado de todas sus épicas. Resultado en `bu
 - [ ] **`integration`** — el **journey completo** de la release se recorre end-to-end con **dependencias reales** del proyecto (servicios externos/IA y capa de decisión reales, según el PRD del consumidor), no stubs. Verificado con la skill `verify`/`run` (+ MCP `chrome-devtools`). Se corre **fuera** del fan-out
   paralelo de reviewers (es **secuencial**, con deps reales); ver `../workflows/release-gate.workflow.js`.
 
-**Todo ✓ (o `null` cuando N/A)** → `releases[].status: "passed"`, escribe `gates` y `updated_by:
-releasing-a-version`. **Algo ✗** → `status: "failed"`, lista hallazgos bloqueantes; se corrigen como
-un slice normal en `building-a-slice` y se re-corre el Release Gate.
+**Todo ✓ (o `na` cuando N/A)** → los seis veredictos quedan reportados con `release-ops.sh verdict`
+(en modo legacy, `releases[].status: "passed"` en el fichero); el **cierre** lo hace una persona en la
+consola del hub, nunca el agente. **Algo ✗** → se reporta `fail` con la evidencia y se lista el
+hallazgo bloqueante; se corrige como un slice normal en `building-a-slice` y se re-corre el Release
+Gate.
 
 > El gate `integration` es el que faltaba en la era anterior: todos los gates por-slice estaban en
 > verde y aun así el producto no caminaba de punta a punta. Sin `integration` con deps reales no hay

package/skills/releasing-a-version/workflows/README.md

@@ -7,7 +7,8 @@
 1. **Hogar primario de los workflows.** El Release Gate corre **una vez por release** (`O(releases)`), fuera
    del camino caliente del inner loop. **No duplica** el inner loop (ni TDD ni gates por slice).
 2. **Read-only sobre el estado.** La plantilla devuelve veredictos; la skill `releasing-a-version` es la
-   **única** que escribe `releases[]` (una entrada por release, validando contra `build-state.schema.json`,
+   **única** que reporta los veredictos de release (uno por gate vía `release-ops.sh verdict`; en modo
+   legacy, una entrada en `releases[]` validada contra el schema local,
    `updated_by: releasing-a-version`). Parciales **no** promueven a `passed`.
 3. **`integration` fuera del paralelo.** Los 5 reviewers pesados van en `parallel()`; el gate `integration`
    (journey completo con **deps reales**) es **secuencial**, lo corre la skill `verify`/`run`, y **no** delega

package/skills/releasing-a-version/workflows/release-gate.workflow.js

@@ -8,9 +8,10 @@
 // caliente del inner loop. NO duplica el inner loop (ni TDD ni gates por slice).
 //
 // READ-ONLY sobre el estado: esta plantilla devuelve un diagnóstico; la skill
-// releasing-a-version es la ÚNICA que escribe releases[] (una entrada por release, validando
-// contra build-state.schema.json antes de persistir, updated_by:releasing-a-version).
-// Parciales NO promueven a passed. Si METODOLOGIA.md (§5) contradice algo aquí, gana la metodología.
+// releasing-a-version es la ÚNICA que reporta los veredictos (release-ops.sh verdict por gate;
+// en modo legacy, una entrada en releases[] del fichero). El agregado y el cierre son del
+// runtime/humano. Parciales NO promueven a passed. Si METODOLOGIA.md (§5) contradice algo aquí,
+// gana la metodología.
 //
 // RUNTIME: corre en el runtime de Workflow de Claude Code, que provee los globals
 // agent()/parallel()/pipeline()/phase()/log()/args y envuelve el cuerpo en un contexto async
@@ -149,11 +150,11 @@ const reviewersGreen = reviews.filter(Boolean).every((r) => r.na || r.value ===
 const status = (reviewersGreen && gates.integration === true) ? 'passed' : 'failed'
 
 return {
-  status,            // releasing-a-version lo persiste en releases[] (única escritora).
+  status,            // reportado por releasing-a-version vía release-ops.sh verdict (agregado y cierre son del runtime/humano).
   gates,             // {security, smell, ux, coherence, stack_arch, integration}
   blocking: [
     ...reviews.filter((r) => r && r.value === false).map((r) => ({ gate: r.gate, error: r.error || null, findings: r.findings || [] })),
     ...(gates.integration === true ? [] : [{ gate: 'integration', findings: (integration && integration.findings) || [] }]),
   ],
-  note: 'Read-only. releasing-a-version valida contra build-state.schema.json y escribe UNA entrada en releases[] (updated_by:releasing-a-version). Parciales NO promueven a passed.',
+  note: 'Read-only. releasing-a-version reporta un veredicto por gate (release-ops.sh verdict). El runtime agrega y un humano cierra la release en la consola. Parciales NO promueven a passed.',
 }

package/skills/setup-architecture/SKILL.md

@@ -27,14 +27,16 @@ Negocio → ASRs → Tácticas → Estilos → Vistas → Evaluación (ATAM) →
   subárbol **`docs/adr/`** (propiedad de construcción; carve-out declarado en `METODOLOGIA.md`).
 - **Propone, no publica.** Genera los `.md` con estado `proposed` / `living-document`. La promoción a
   `accepted` la hace un humano en la revisión única (fase 5). Forward-compat v0.9: los tipos viven en
-  `asset-types.json`; cuando exista el runtime, la propuesta irá por API (`POST /context/proposals`).
+  `asset-types.json`; con el runtime disponible, la instancia se **propone** por la superficie de
+  agente: `bash .claude/hooks/build/slice-ops.sh propose-asset --type-key <k> --path <p> --content-file <f>`
+  (la publica un ADMIN; un agente jamás publica contexto).
 - **Autónoma y de propuesta máxima.** La IA rellena todo el catálogo y todos los ADRs de una pasada;
   **no** pregunta campo por campo. Solo se detiene ante **trade-offs de negocio** genuinos (ver fase 5).
 - **Delega la exploración pesada en subagentes** (`asr-extractor`, `architecture-evaluator`): devuelven
   síntesis condensada y protegen el presupuesto de atención de la sesión principal.
 - **Divulgación progresiva:** carga el `references/<tema>.md` solo cuando la fase lo necesita.
 - **El estado es el archivo.** `docs/adr/_backlog-arquitectonico.md` es el estado auto-descriptivo de la
-  capa (no toca `build-state.json`). Re-correr = **incremental**: añade iteraciones, no regenera.
+  capa (no transiciona el estado del slice). Re-correr = **incremental**: añade iteraciones, no regenera.
 
 ## Fases (carga la referencia indicada en cada paso)
 

package/state/README.md

@@ -5,6 +5,15 @@ el que los agentes se sincronizan en modo **secuencial**. La unidad de construcc
 (`EP-XXX`)**; las HU que cubre el change se listan en `hus[]` (trazabilidad al alcance interno).
 Cada gate del pipeline transiciona el estado; el siguiente agente lo lee antes de actuar.
 
+> **Todo lo anterior describe el modo `legacy` (default).** Si el proyecto corre en modo `dual` o
+> `runtime` (`config/build-config.json#runtime.mode`, opt-in — EP-OR-08, beta), este mismo
+> protocolo lo conducen `hooks/build/slice-ops.sh`/`release-ops.sh` contra el Agent Orchestrator
+> Runtime en vez de (o además de) este fichero: mismas reglas, mismo "quién escribe qué", otro
+> medio. Ver `skills/building-a-slice/references/runtime-protocol.md`,
+> `docs/runtime/protocolo-cliente-runtime.md` y, para migrar un proyecto,
+> `docs/runtime/guia-modo-dual-y-migracion.md`. `legacy` sigue siendo el camino con soporte
+> completo hasta que un piloto real confirme el corte (`docs/runtime/plan-migracion-harness-v0.9.md` §2).
+
 - **Esquema**: `build-state.schema.json` (versionado, draft 2020-12). Valida con:
   ```bash
   # Recomendado (funciona sin plugins de formato):
@@ -56,8 +65,9 @@ slice (fases `red…data`) mientras `confirmed` no sea `true`. El arnés **no ge
 ### `design_source` (gate de proyecto, slices con UI)
 
 Espejo de `scaffold` para la UI: `applies` (¿el proyecto tiene UI?), `confirmed` (humano confirmó que
-existe una fuente de diseño declarada), `source` (puntero al prototipo/export). El arnés NO genera el
-prototipo. Lo respalda `design-source-guard.sh`.
+existe una fuente de diseño declarada), `source` (puntero al prototipo/export). El prototipo puede
+**generarse** con `/build:prototype` (skill `prototyping-screens`, salida en `docs/05-prototipo/`);
+`confirmed` sigue siendo exclusivamente humano. Lo respalda `design-source-guard.sh`.
 
 ### `foundation` (gate de proyecto, solo greenfield) + `project_kind`
 
@@ -90,7 +100,12 @@ INCONCLUSO ya **no** pasa (queda `false` → el `dod` no cierra hasta correrlo d
 Campos por-slice que hacen el **refresh de contexto el estado por defecto** (una sesión fresca retoma
 desde disco, no desde la conversación):
 - **`wiring_checklist[]`** — un item por escenario AC y por punto de integración entre capas; nace
-  `failing`, pasa a `passing` **solo tras prueba real ejecutada** (con `evidence`).
+  `failing`, pasa a `passing` **solo tras prueba real ejecutada** (con `evidence`). Cada item puede
+  llevar además **`verified_at_sha`** (opcional): el sha del commit en que su evidencia fue
+  reproducida por última vez. Lo estampa el `build-orchestrator` al aplicar un veredicto del
+  `wiring-adversarial-verifier`, y habilita la **re-verificación incremental**: en pasadas
+  posteriores solo se re-ejecuta la evidencia de los items cuyo código cambió desde su sha
+  (`git diff <sha>..HEAD -- <rutas del item>`); el resto conserva veredicto.
 - **`progress_log[]`** — bitácora append-only (`{at, by, note}`) que sobrevive al reset.
 - **`sub_slices[]`** — descomposición de una épica que superó el gate de tamaño (>3 HU ó ≥3 capas).
 - **gate `wiring_verified`** — lo cierra el `wiring-adversarial-verifier` (subagente **independiente**,
@@ -114,6 +129,7 @@ El razonamiento vive en el modelo; el hook solo es un recordatorio determinista.
 | `gates.coherence_link` | `change-epic-coherence` | slice |
 | `gates.tdd` | flujo `superpowers:test-driven-development` (vía `build-orchestrator`) | slice |
 | `gates.journey_smoke` · `gates.fidelity` · `phase` (transiciones) · `history[]` (archivado) · `wiring_checklist[]` · `progress_log[]` · `sub_slices[]` | `build-orchestrator` (fidelity desde `ux-fidelity-reviewer`) | slice |
+| `wiring_checklist[].verified_at_sha` | `build-orchestrator` (al aplicar un veredicto del `wiring-adversarial-verifier`: estampa el sha en los items cuya evidencia fue reproducida en esa pasada) | por pasada de verificación |
 | `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`) |
@@ -124,3 +140,4 @@ El razonamiento vive en el modelo; el hook solo es un recordatorio determinista.
 | `foundation` (`required`, `checklist[]`, `epic`) | `/build:onboard` Fase 2c | una vez (greenfield) |
 | `foundation.checklist[].evidence` | `build-orchestrator` (durante la construcción de la caparazón) | al construir la caparazón |
 | `foundation.completed_at` | `dor-dod-gatekeeper` (al cerrar el DoD de la épica caparazón) | al archivar la caparazón |
+| `design_source` (`source`, `confirmed`, `confirmed_by/at`, `notes`) | `building-a-slice` Fase 0-bis · `/build:onboard` Fase 3c · `prototyping-screens` (greenfield, solo tras aprobación humana de ≥1 pantalla; `confirmed` humano siempre) | una vez (proyecto) |

package/state/build-state.schema.json

@@ -64,7 +64,7 @@
     "design_source": {
       "type": "object",
       "additionalProperties": false,
-      "description": "Gate de PROYECTO para slices con UI: existe una fuente de diseño declarada (prototipo/export). Espejo de scaffold: confirmed pasa a true SOLO por confirmación humana, nunca por auto-detección. El arnés NO genera el prototipo. applies=false apaga todo el mecanismo (proyecto sin UI).",
+      "description": "Gate de PROYECTO para slices con UI: existe una fuente de diseño declarada (prototipo/export). Espejo de scaffold: confirmed pasa a true SOLO por confirmación humana, nunca por auto-detección. El prototipo puede generarse con /build:prototype (skill prototyping-screens); confirmed sigue siendo exclusivamente humano. applies=false apaga todo el mecanismo (proyecto sin UI).",
       "required": ["applies", "confirmed"],
       "properties": {
         "applies": { "type": "boolean", "description": "¿el proyecto tiene UI / hay diseño que respetar? false → mecanismo N/A." },
@@ -162,7 +162,8 @@
               "kind": { "type": "string", "enum": ["hu_ac", "integration_point"], "description": "hu_ac = escenario Given/When/Then de una HU; integration_point = cableado entre dos capas." },
               "ref": { "type": "string", "description": "A qué apunta: el AC (HU-XXX#escenario) o el par de capas (capaA→capaB)." },
               "status": { "type": "string", "enum": ["failing", "passing"], "description": "failing al nacer; passing SOLO tras prueba real ejecutada." },
-              "evidence": { "type": "string", "description": "Evidencia de ejecución que justificó passing (test, comando, salida). Vacío mientras failing." }
+              "evidence": { "type": "string", "description": "Evidencia de ejecución que justificó passing (test, comando, salida). Vacío mientras failing." },
+              "verified_at_sha": { "type": "string", "description": "OPCIONAL. Sha del commit en que la evidence de este item fue reproducida por última vez. Lo estampa el build-orchestrator al aplicar un veredicto del wiring-adversarial-verifier. Habilita la re-verificación incremental: en pasadas posteriores el verificador solo re-ejecuta la evidencia de items cuyo código cambió desde este sha (git diff <sha>..HEAD -- <rutas del item>); los demás conservan veredicto. Ausente = el item nunca fue verificado por el verificador (se re-ejecuta siempre)." }
             }
           }
         },

package/templates/CLAUDE.md.template

@@ -40,6 +40,22 @@ Outer loop (por release):       Release Gate (seguridad · diseño · UX · cohe
 8. **Cimiento antes que negocio y unidades pequeñas.** Las épicas de cimiento (auth, datos, arquitectura base, design-system) se construyen antes que las de negocio; una épica grande (>3 HU ó ≥3 capas) se descompone en sub-slices construidos de a uno. En proyectos **nuevos** (`project_kind: greenfield`), la **épica caparazón** (app shell: navegación, layout, homepage, login, redirecciones — gate de proyecto `foundation`) se construye y archiva **con evidencia** antes que cualquier épica de negocio; en brownfield el mecanismo es N/A.
 9. Si una regla del arnés contradice la metodología Trycore (`METODOLOGIA.md`), **gana la metodología**.
 
+### Ámbito de las reglas de evidencia
+
+- Las reglas pesadas — **mutación obligatoria, evidencia anclada a sha, regresión con
+  worktree/baseline** — aplican al **inner loop de slices** (fase tdd→dod de `building-a-slice`),
+  **no** al carril `building-a-micro-change`: un micro-cambio exige 1 test de regresión si cambia
+  comportamiento + la suite del módulo tocado en verde, y cierra en **< 30 min** (mutación opcional;
+  los límites duros de escalada a slice quedan intactos).
+- **Presupuesto de mutación**: obligatoria solo para los tests que sostienen un item de
+  `wiring_checklist[]` (AC de HU, puntos de integración); opcional para tests auxiliares.
+  Alternativa al ciclo manual: mutación automatizada acotada a los ficheros cambiados, con el
+  reporte como evidencia.
+- **Dos clases de evidencia**: la **determinista** (runners sin LLM) se re-ancla a HEAD; la **viva**
+  (corridas contra el LLM real del proyecto) se ancla al último commit que tocó el módulo medido
+  (`anchored_at.sha`; `head_at_run` informativo) y solo se regenera cuando cambió el código que mide.
+  Detalle operativo: `.claude/skills/building-a-slice/references/evidence-budget.md`.
+
 ### Bloque de dominio (lo resuelve `/build:onboard`)
 
 Estos puntos de extensión los leen los agentes `security-reviewer`, `stack-guardian`,
@@ -51,7 +67,7 @@ Estos puntos de extensión los leen los agentes `security-reviewer`, `stack-guar
 - **Categorías de datos sensibles / PII reguladas**: {{SENSITIVE_DATA_CATEGORIES}}
 - **Secretos server-side**: {{SERVER_SIDE_SECRETS}}
 - **Decisiones de alto impacto que exigen explicabilidad UX**: {{HIGH_STAKES_DECISIONS}}
-- **Fuente de diseño / referencia visual**: {{DESIGN_SOURCE}}
+- **Fuente de diseño / referencia visual**: {{DESIGN_SOURCE}} (si no existe fuente aún, `/build:prototype` puede generarla en `docs/05-prototipo/`; la confirmación sigue siendo humana)
 
 (Si aparecen como `{{...}}`, ejecuta `/build:onboard` para parametrizarlos.)
 

package/templates/settings-hooks.template.json

@@ -1,5 +1,5 @@
 {
-  "_comment": "ESPEJO DOCUMENTAL del bloque que `trycore-build init` mergea en el settings.json del consumidor (canal CLI). La fuente de verdad es src/lib/settings-merge.ts. Misma cadena de comando que hooks/build-harness.json (canal plugin) → si se instalan ambos canales, Claude Code deduplica y el hook dispara UNA vez. Permisos MÍNIMOS y enumerados (sin mcp__* ni rutas absolutas).",
+  "_comment": "ESPEJO DOCUMENTAL del bloque que `trycore-build init` mergea en el settings.json del consumidor (canal CLI). La fuente de verdad es src/lib/settings-merge.ts. Misma cadena de comando que hooks/build-harness.json (canal plugin) → si se instalan ambos canales, Claude Code deduplica y el hook dispara UNA vez. Permisos MÍNIMOS y enumerados (sin mcp__* ni rutas absolutas). Sincronizado con v0.9 (EP-OR-08-B): session-start.sh, event-emitter.sh y session-stop.sh nuevos; context-sync.sh y heartbeat.sh NO se registran (los invocan otros hooks).",
   "permissions": {
     "allow": [
       "Bash(openspec validate *)",
@@ -9,17 +9,21 @@
   },
   "hooks": {
     "SessionStart": [
-      { "matcher": "startup|clear|compact", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/load-build-state.sh\"" } ] }
+      { "matcher": "startup|clear|compact", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/session-start.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/load-build-state.sh\"" } ] }
     ],
     "PreToolUse": [
       { "matcher": "Bash", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/gitflow-guard.sh\"" } ] },
       { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/stack-guard.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/scaffold-guard.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/design-source-guard.sh\"" } ] }
     ],
     "PostToolUse": [
-      { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/lint-typecheck.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/coherence-flag.sh\"" } ] }
+      { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/lint-typecheck.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/coherence-flag.sh\"" } ] },
+      { "matcher": "Bash|Edit|Write|MultiEdit|Task", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/context-monitor.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/event-emitter.sh\"" } ] }
+    ],
+    "PreCompact": [
+      { "matcher": ".*", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/context-monitor.sh\"" } ] }
     ],
     "Stop": [
-      { "matcher": ".*", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/build-gate-check.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/reflect-nudge.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/release-gate-nudge.sh\"" } ] }
+      { "matcher": ".*", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/build-gate-check.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/reflect-nudge.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/release-gate-nudge.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/dual-compare.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/context-monitor.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/session-stop.sh\"" } ] }
     ]
   }
 }

package/internal/skills/auditar-arnes/SKILL.md

@@ -1,29 +0,0 @@
----
-name: auditar-arnes
-description: Skill INTERNA (no se distribuye al consumidor). Audita el propio paquete del arnés cada 3-6 meses — poda de instrucciones obsoletas, validación de herramientas nativas que vuelvan redundante un hook/agente, re-sincronización de convenciones (schema ↔ agentes ↔ skills), y verificación de agnosticismo. Equivale a la cadencia de GOVERNANCE.md.
----
-
-# Auditar el arnés de construcción (mantenimiento del paquete)
-
-Skill de **mantenedor**, no de consumidor. Vive en `internal/skills/` y se incluye en el
-paquete npm (`files[]`) pero **NO** la instala el CLI ni la expone el plugin — solo se usa
-trabajando sobre el repo del propio paquete.
-
-## Cadencia (cada 3-6 meses)
-
-1. **Poda de instrucciones**: borrar reglas que el modelo nuevo ya maneja nativamente
-   (las instrucciones obsoletas limitan a modelos más capaces). Revisar agentes y references.
-2. **Validación de herramientas**: ¿hay modos nativos (LSP, MCP nuevos) que vuelvan redundante
-   un hook o un agente? Si sí, retirarlo.
-3. **Coherencia de convenciones**: que `state/build-state.schema.json`, los agentes y las skills
-   sigan alineados (mismos nombres de gate/fase).
-4. **Agnosticismo**: correr `bash scripts/check-agnostic.sh` y `bash scripts/check-state-clean.sh`;
-   confirmar que `docs/examples/` sigue siendo el único lugar con vocabulario de dominio.
-5. **Sincronía de versión**: `bash scripts/check-version-sync.sh` (VERSION / package.json / plugin.json).
-
-## Procedimiento
-
-- Trabaja en rama (`chore/auditoria-arnes-YYYY-MM`), PR al cierre (el arnés se gobierna a sí mismo).
-- Registra decisiones de poda/cambio en `GOVERNANCE.md` (bitácora).
-- Si cambias el schema de estado, los nombres de gate/fase o la política de hooks, actualiza
-  en bloque agentes + skills + schema para no fragmentar convenciones.