@trycore/spec-build-harness 0.8.5 → 0.11.0

package/skills/building-a-slice/references/runtime-protocol.md

@@ -0,0 +1,75 @@
+# Protocolo de estado sobre el runtime (modos `dual` y `runtime`)
+
+El estado del pipeline vive en el **Agent Orchestrator Runtime**: fases, gates, wiring,
+checkpoints, releases y hechos de proyecto son suyos. El arnés **observa el working tree**
+(hooks) y **transiciona el dominio** por la API. Ningún agente arma peticiones a mano: todo
+acto pasa por `slice-ops.sh` (inner loop) y `release-ops.sh` (outer loop), instalados en
+`.claude/hooks/build/`.
+
+> **Antes de nada, pregunta el modo:**
+> ```bash
+> bash .claude/hooks/build/slice-ops.sh mode      # legacy | dual | runtime
+> ```
+> - `legacy` → **no** uses este documento: el fichero es primario, sigue `state-protocol.md`.
+> - `dual` → el **fichero sigue siendo primario** (escríbelo como en `state-protocol.md`) y
+>   **además** invoca los subcomandos: espejan cada transición al runtime. El claim NO
+>   aplica en `dual` (devuelve rc 3): el slice lo decide el fichero.
+> - `runtime` → el fichero es fósil: **no lo leas ni lo escribas**. Todo pasa por los
+>   subcomandos, y el estado se consulta con `slice-ops.sh status`.
+
+## Códigos de salida (ramifica sobre ellos, no sobre el texto)
+
+| rc | Significado | Qué hace la skill |
+|---|---|---|
+| 0 | aceptado | continúa |
+| 2 | uso incorrecto | corrige la invocación (bug de la skill, no del runtime) |
+| 3 | modo `legacy` (o claim en `dual`) | sigue el protocolo del fichero |
+| 4 | sin slice activo | reclama primero (`claim`) o abre el slice por DoR |
+| 5 | offline: encolado | **sigue trabajando**; el daemon entrega al reconectar |
+| 6 | rechazado por el servidor | **NO reintentes**: muestra la razón y corrige la causa |
+| 7 | sin trabajo (204) o carrera perdida | comunica y termina limpio |
+
+## El ciclo del slice
+
+| Acto | Comando | Notas |
+|---|---|---|
+| Reclamar | `slice-ops.sh claim [--epic EP-XXX]` | Sincroniza el contexto **antes** (regla: no se abre trabajo con contexto viejo) y reporta los sha256 locales de los archivos gobernados. Si la respuesta trae `checkpoint`, **continúa desde él; jamás reinicies**. |
+| Saber el paso | `slice-ops.sh next-step` | Lo deriva el **cliente** desde la proyección: `resume_hint` → wiring `failing` → sub-slice pendiente → primer gate abierto. |
+| Sembrar el cableado | `slice-ops.sh wiring seed --file items.json` | Un item por escenario AC y por punto de integración entre capas. Nacen `failing`. |
+| Cablear un item | `slice-ops.sh wiring update <item_id> passing --kind K --ref HU-XXX --evidence-file f` | `passing` **solo tras prueba real ejecutada**. Sin evidencia el comando avisa: no lo ignores. |
+| Cerrar un gate | `slice-ops.sh gate <nombre> <pass\|fail\|na> --evidence-file f` | Gates canónicos: `dor coherence_link tdd journey_smoke fidelity api data wiring_verified dod`. Un `na` es legítimo cuando el gate no aplica. |
+| Dejar bitácora | `slice-ops.sh progress «hito»` | Sustituye a `progress_log[]`: el event stream **es** la bitácora. |
+| Guardar continuidad | `slice-ops.sh checkpoint --note «dónde me quedé»` | Rama + commit reales. Es lo que permite que otro agente continúe tras una caída. |
+| Entregar | `slice-ops.sh submit --pr-url U --openspec-change C` | Tras abrir el PR. |
+| Archivar | `slice-ops.sh archive --epic EP-XXX --openspec-change C --pr-url U` | Lo dispara `opsx:archive` en el mismo PR. Va por cola (idempotente, protegido de la cota). |
+| Hechos de proyecto | `slice-ops.sh fact scaffold-confirmed --by «persona»` · `fact design-source …` · `fact project-kind …` · `fact foundation …` | **Reportan lo que un humano confirmó**; el agente nunca confirma por su cuenta. |
+| Bloqueo | `slice-ops.sh escalate «razón» --gate G` | Deja el rastro; la decisión (recortar/diferir/desbloquear) es del equipo. |
+| Ver el estado | `slice-ops.sh status` | Modo, slice, gates, wiring, contexto, lease y cola pendiente. |
+
+## Reglas duras
+
+1. **Un gate no se salta y `dod` exige `wiring_verified`.** La compuerta real es el servidor:
+   un `422` es la compuerta funcionando, no un error a reintentar.
+2. **Nunca marques `passing`/`pass` por inspección.** La evidencia es de ejecución real.
+3. **Contexto antes que trabajo.** Si el `manifest_hash` no coincide, el claim sincroniza
+   solo; si el servidor responde `409 drift`, el cliente re-sincroniza y reintenta **una** vez.
+4. **Un solo slice activo.** Reclamar con lease vigente devuelve el mismo slice (idempotente).
+5. **Lease perdido** (`⚠ lease` en la statusline, `heartbeat-status.json`): haz `checkpoint`,
+   detén el trabajo y vuelve a reclamar. No sigas cerrando gates con el lease caído.
+6. **Offline no bloquea.** rc 5 = encolado: sigue construyendo; el daemon despacha al
+   reconectar y el `client_event_id` evita duplicados.
+7. **El agente no gobierna.** No cierra releases, no publica contexto, no importa el grafo,
+   no abre/drena/cierra fronts: prepara, propone, reporta — y el humano decide en la consola.
+
+## Qué queda del fichero (legado)
+
+En `runtime` el fichero `.claude/state/build-state.json` **no se lee ni se escribe** (queda fósil hasta que el sub-slice E lo retire); solo en modo `legacy` sigue siendo el protocolo primario — ver `state-protocol.md`. Lo que antes se leía de él ahora:
+
+| Antes (fichero) | Ahora |
+|---|---|
+| `active_slice.gates` | `slice-ops.sh status` / caché de proyección |
+| `active_slice.wiring_checklist[]` | eventos `wiring_*` + `wiring_failing` de la proyección |
+| `active_slice.progress_log[]` | eventos `progress_noted` (event stream) |
+| `session_continuity.resume_hint` | `resume_hint` de `/agent/context` (lo rinde `next-step`) |
+| `scaffold`, `design_source`, `project_kind`, `foundation` | hechos de proyecto (`fact …`) |
+| `history[]`, `releases[]`, `parallel_front` | proyecciones del runtime (consola del hub) |

package/skills/building-a-slice/references/state-protocol.md

@@ -1,4 +1,11 @@
-# Protocolo del archivo de estado (`build-state.json`)
+# Protocolo del archivo de estado (`build-state.json`) — **modo `legacy`**
+
+> **Vigencia:** este documento describe el protocolo del **modo `legacy`** (v0.8.5 exacto),
+> donde el fichero es la fuente de verdad. En `dual` el fichero sigue siendo primario **y
+> además** cada transición se espeja al runtime; en `runtime` el fichero es fósil y **no se
+> lee ni se escribe**. Para esos dos modos, el protocolo es
+> [`runtime-protocol.md`](runtime-protocol.md). Comprueba el modo con
+> `bash .claude/hooks/build/slice-ops.sh mode`.
 
 El estado es **cómo se comunican los agentes** en el modelo secuencial: cada uno lee antes de
 actuar y escribe su resultado, dejando el testigo al siguiente. Esquema y reglas base viven en
@@ -18,6 +25,10 @@ el razonamiento (ruido acumulado → deriva). Para retomar sin "creer que ya est
 - **`wiring_checklist[]`** — un item por escenario AC de cada HU y por **punto de integración entre capas**.
   Nace `failing`; pasa a `passing` **SOLO tras prueba real ejecutada** (con `evidence`), nunca por inspección.
   **Mientras quede un item `failing`, el slice NO está cableado** — no cierres `wiring_verified` ni `dod`.
+  Cada item puede llevar **`verified_at_sha`** (opcional): 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** (pasadas 2+ solo
+  re-ejecutan items cuyo código cambió desde su sha).
 - **`progress_log[]`** — bitácora append-only (`{at, by, note}`) de qué se hizo / qué falta. Deja una nota
   por hito para que la siguiente sesión retome el cableado.
 - **`sub_slices[]`** — si la épica superó el gate de tamaño (>3 HU ó ≥3 capas), se trocea aquí; cada

package/skills/building-a-slice/workflows/README.md

@@ -10,11 +10,12 @@
    atómica: inflaría el inner loop barato. *Excepción de guard:* `dor-fanout` corre **antes** de abrir el
    slice (aún no existe `sub_slices[]`), así que su guard es por **nº de HUs** (≥ 3; bajo eso se auto-salta
    y la validación queda secuencial en sesión).
-2. **Read-only sobre el estado.** Ninguna plantilla escribe `build-state.json`. El único escritor de los
+2. **Read-only sobre el estado.** Ninguna plantilla transiciona el estado (ni por `slice-ops.sh` ni,
+   en modo legacy, escribiendo el fichero). El único escritor de los
    gates del slice sigue siendo `build-orchestrator` (y los agentes dueños de cada gate). Las plantillas
    **devuelven un diagnóstico**; la sesión/orquestador aplica el mapeo respetando el protocolo: **una
    transición = una escritura**, gates **monótonos** (`false`→`true` solo por su agente; retroceso solo ante
-   fallo) y **validar contra `build-state.schema.json` tras escribir**.
+   fallo) y en modo legacy **validar contra `build-state.schema.json` tras escribir**.
 3. **Subagentes de exploración = solo-lectura.** No editan código ni estado; su única salida es síntesis
    condensada. El **cableado lo hace la sesión**, no subagentes en paralelo.
 4. **Agnóstico.** Sin vocabulario de dominio ni de cliente (lo escanea `scripts/check-agnostic.sh`, que
@@ -24,7 +25,10 @@
 - **`explore-fanout.workflow.js`** — exploración "ancho antes que profundo" por área (fan-out → síntesis),
   gated por `sub_slices[]`. Contrato detallado en `../references/exploration-fanout.md`.
 - **`wiring-verify.workflow.js`** — conducción adversarial del gate `wiring_verified` (envuelve, read-only, al
-  agente `wiring-adversarial-verifier`); devuelve el veredicto, no escribe el gate.
+  agente `wiring-adversarial-verifier`); devuelve el veredicto, no escribe el gate. Soporta pasadas
+  **incrementales** (`args.passNumber` > 1: solo re-ejecuta items cambiados desde su `verified_at_sha`;
+  `args.finalFullPass` fuerza una completa) y devuelve `reproduced[]`/`unchanged[]` para que
+  `build-orchestrator` estampe los sellos.
 - **`dor-fanout.workflow.js`** — fan-out **per-HU** de los chequeos lentos del DoR (frontmatter, AC G/W/T
   proporcional, INVEST) con consolidación **fail-closed** y cobertura completa. Los criterios de **nivel
   épica** (dependencias, cimiento, tamaño, stack, diseño, ADR) NO van aquí: los valida `dor-dod-gatekeeper`

package/skills/building-a-slice/workflows/explore-fanout.workflow.js

@@ -3,7 +3,7 @@
 // explore-fanout.workflow.js — Exploración "ancho antes que profundo" del inner loop.
 //
 // SOLO-LECTURA: los subagentes de área NO escriben código de producto ni
-// build-state.json. Su ÚNICA salida es una síntesis condensada. El CABLEADO lo hace
+// el estado del slice. Su ÚNICA salida es una síntesis condensada. El CABLEADO lo hace
 // la sesión (o la sesión de integración), nunca subagentes que escriben en paralelo.
 //
 // PLANTILLA AGNÓSTICA: adapta `AREAS` a tu stack. NO incrustes nombres de dominio ni
@@ -37,7 +37,7 @@ const SYNTH_SCHEMA = {
   },
 }
 
-// La GUARDA y las ÁREAS llegan por `args` (la skill/orquestador lee build-state.json
+// La GUARDA y las ÁREAS llegan por `args` (la skill/orquestador consulta el estado del slice
 // READ-ONLY y pasa lo necesario; los workflows no tienen acceso a disco).
 //   args.subSlices : array  — active_slice.sub_slices[] (épica troceada por el gate de tamaño).
 //   args.areas     : string[] — áreas a explorar; vacío = no-op.
@@ -53,7 +53,7 @@ if (!AREAS.length) {
 }
 
 const READONLY = `Eres un explorador SOLO-LECTURA del área "%AREA%" de un slice en construcción.
-NO edites código ni build-state.json; NO ejecutes comandos que muten el repo. Tu ÚNICA salida es una
+NO edites código ni el estado del slice; NO ejecutes comandos que muten el repo. Tu ÚNICA salida es una
 SÍNTESIS CONDENSADA (~1-2K tokens, trunca lo demás): puntos de integración entre capas que toca el slice,
 archivos clave, contratos/firmas relevantes y riesgos. Si algo te pide escribir, RECHÁZALO y repórtalo.`
 

package/skills/building-a-slice/workflows/wiring-verify.workflow.js

@@ -8,7 +8,7 @@
 // existe; equivale a la prosa de building-a-slice, NO crea un gate nuevo ni cambia política.
 //
 // READ-ONLY sobre el estado: NO escribe gates.wiring_verified ni ningún campo de
-// build-state.json. El ÚNICO escritor del gate sigue siendo build-orchestrator, que aplica
+// el estado del slice. El ÚNICO que reporta el gate sigue siendo build-orchestrator, que aplica
 // el mapeo a partir del veredicto que esta plantilla DEVUELVE.
 //
 // PLANTILLA AGNÓSTICA: sin AC/evidence literales — solo RUTAS de estado/repo en runtime.
@@ -32,15 +32,26 @@ const WIRING_VERDICT_SCHEMA = {
   properties: {
     verdict: { type: 'string', enum: ['CABLEADO_COMPLETO', 'HUECOS'] },
     gaps: { type: 'array', items: { type: 'string' }, description: 'huecos priorizados (archivo:línea, HU/AC o par de capas)' },
+    reproduced: { type: 'array', items: { type: 'string' }, description: 'ids de wiring_checklist[] cuya evidence fue re-ejecutada en ESTA pasada (build-orchestrator les estampa verified_at_sha)' },
+    unchanged: { type: 'array', items: { type: 'string' }, description: 'ids que conservaron veredicto como «sin cambios desde <sha>» (diff vacío desde su verified_at_sha; no se re-ejecutó su evidence)' },
   },
 }
 
 // Insumos por `args` (la sesión/orquestador los pasa READ-ONLY; el workflow no toca disco):
 //   args.checklistPresent  : boolean  — ¿active_slice.wiring_checklist[] existe y NO está vacío?
 //   args.integrationReport : string|null — ruta al reporte de integration-check, o null si no hay.
+//   args.passNumber        : number   — nº de pasada adversarial sobre este slice (1 = primera).
+//   args.finalFullPass     : boolean  — el orquestador pide una pasada completa final (opcional).
 const checklistPresent = !!(args && args.checklistPresent)
 const integrationReport = (args && args.integrationReport) || null
 const integrationPresent = !!integrationReport
+const passNumber = (args && args.passNumber) || 1
+const finalFullPass = !!(args && args.finalFullPass)
+// Selección incremental: pasada completa solo la primera (o una final explícita); las pasadas 2+
+// re-ejecutan SOLO los items cuyo código cambió desde su verified_at_sha, acotadas al diff de los
+// arreglos + sus rutas gemelas. Condición de parada (fase dod): máximo 2 pasadas completas por
+// slice — la 3ª solo existe como pasada ACOTADA por hallazgo ALTA en código preexistente.
+const incremental = passNumber > 1 && !finalFullPass
 
 // (ii) wiring_checklist[] ausente/vacío (slice trivial) → INSUFICIENTE, nunca verde por defecto.
 if (!checklistPresent) {
@@ -58,8 +69,17 @@ try {
 Tu sesgo por defecto es "está incompleto": solo das CABLEADO_COMPLETO si, tras intentar romperlo activamente, NO
 encuentras ningún hueco. Lee READ-ONLY: active_slice.wiring_checklist[] del estado, el diff del slice y las HU en
 alcance${integrationPresent ? `, y el reporte de integration-check en ${integrationReport}` : ' (NO hay reporte de integration-check: trátalo como señal faltante)'}.
-Por cada AC y cada punto de integración, REPRODUCE la evidencia ejecutándola; si no puedes ejecutarla, ese item
-es failing. Ante CUALQUIER duda no resuelta o señal faltante → HUECOS. No edites estado ni código.`,
+${incremental
+  ? `PASADA INCREMENTAL (nº ${passNumber}): re-ejecuta la evidencia SOLO de los items cuyo código cambió desde su
+verified_at_sha (git diff <sha>..HEAD -- <rutas del item>) o que no traen verified_at_sha; los demás conservan
+veredicto y los listas en "unchanged" como «sin cambios desde <sha>». Acota el foco al diff de los arreglos +
+sus rutas gemelas (el patrón de defectos inducidos: blindar una ruta y dejar la gemela). Si un diff no se puede
+calcular, ese item SE RE-EJECUTA (nunca «sin cambios» por fallo). Si re-ejecutas un item «sin cambios» y su
+evidencia es irreproducible → HUECOS igual que siempre.`
+  : `PASADA COMPLETA (nº ${passNumber}): por cada AC y cada punto de integración, REPRODUCE la evidencia ejecutándola.`}
+Si no puedes ejecutar una evidencia, ese item es failing. Reporta en "reproduced" los ids re-ejecutados en esta
+pasada (build-orchestrator les estampará verified_at_sha). Ante CUALQUIER duda no resuelta o señal faltante →
+HUECOS. No edites estado ni código.`,
     { label: 'wiring-verify', agentType: 'wiring-adversarial-verifier', phase: 'Refute', schema: WIRING_VERDICT_SCHEMA },
   )
 } catch (e) {
@@ -83,6 +103,8 @@ const greenlit = result.verdict === 'CABLEADO_COMPLETO' && integrationPresent
 return {
   verdict: greenlit ? 'CABLEADO_COMPLETO' : (result.verdict === 'CABLEADO_COMPLETO' ? 'HUECOS' : 'HUECOS'),
   gaps: result.gaps && result.gaps.length ? result.gaps : (integrationPresent ? [] : ['falta reporte de integration-check: señal faltante']),
+  reproduced: result.reproduced || [],
+  unchanged: result.unchanged || [],
   maps_to_wiring_verified: greenlit,
-  note: 'Read-only. build-orchestrator es quien escribe gates.wiring_verified a partir de este veredicto.',
+  note: 'Read-only. build-orchestrator es quien escribe gates.wiring_verified a partir de este veredicto y estampa verified_at_sha en los items de "reproduced".',
 }

package/skills/managing-parallel-front/SKILL.md

@@ -1,36 +1,52 @@
 ---
 name: managing-parallel-front
-description: Use when building multiple NON-foundational, file-disjoint epics in parallel via git worktrees. Coordinates the parallel_front in build-state.json (selection, worktrees, deterministic merge order with re-smoke). Never parallelizes foundational epics or overlapping file scopes.
+description: Use when building multiple NON-foundational, file-disjoint epics in parallel via git worktrees. Prepares the disjoint selection and merge order locally (front-plan.py), drives each worktree as its own registered agent, and reports each member's integration (re-smoke, merge_status) through the agent surface. Planning, opening, draining and closing the front are human acts in the hub console. Never parallelizes foundational epics or overlapping file scopes.
 ---
 
 # Gestionar el front paralelo inter-épica (outer-loop)
 
-**Invariante:** el paralelismo es outer-loop. Cada worktree es un checkout aislado con su
-**propio** `build-state.json` y su `active_slice` singular (el inner loop no cambia).
+**Invariante:** el paralelismo es outer-loop. Cada worktree es un checkout aislado con **su
+propio agente registrado** (mismo token de proyecto, `agent_key` distinto) y un slice activo
+singular: el inner loop no cambia.
+
+**Reparto agente ↔ humano (spec §2).** El agente **prepara y reporta**; la persona **decide**:
+
+| Acto | Quién |
+|---|---|
+| Proponer el conjunto disjunto y el `merge_order` (`front-plan.py`, local) | agente |
+| **Planificar, abrir, drenar y cerrar** el front | **humano**, en la consola del hub |
+| Construir cada worktree (inner loop) | agente (uno por worktree) |
+| Reportar re-smoke y `merge_status` de su miembro | agente, vía `release-ops.sh front-integration` |
 
 ## Precondiciones (compuertas)
-- `scaffold.confirmed == true`.
-- **G1 Fundacionales primero:** ninguna épica `layer=foundational` abierta. Si aparece una,
-  poner `parallel_front.status="draining"` (terminar en curso, no admitir nuevas) antes de abrirla.
+- Scaffold confirmado (`bash .claude/hooks/build/slice-ops.sh status`).
+- **G1 Fundacionales primero:** ninguna épica `layer=foundational` abierta. Si aparece una, el
+  front debe **drenarse** (terminar en curso, no admitir nuevas) antes de abrirla — el drenaje
+  lo hace una persona en la consola.
 
 ## Procedimiento
 1. **Reunir candidatas** no fundacionales listas (DoR pasado), cada una con `layer` y `files_scope`.
-2. **Seleccionar el conjunto disjunto** (G2):
+2. **Seleccionar el conjunto disjunto** (G2), en local:
    `echo "$CANDS" | python3 .claude/scripts/lib/front-plan.py`
-   → `selected` van al front; `serialized` esperan (construir secuencial después);
-   `excluded_foundational` nunca en paralelo.
-3. **Abrir un worktree por épica seleccionada:**
+   → `selected` propuestas al front; `serialized` esperan (construir secuencial después);
+   `excluded_foundational` nunca en paralelo. **Presenta el plan al humano**: es él quien abre el
+   front en la consola con ese `merge_order`.
+3. **Abrir un worktree por épica aprobada:**
    `git worktree add ".wt/<epica>" -b feature/<slug>` (rama por `1 épica = 1 rama = 1 PR`).
-   Registrar el miembro en `parallel_front.members[]` (`merge_status:"pending"`).
+   En cada worktree corre `trycore-build init` con el **mismo token de proyecto**: se registra
+   como agente propio y obtiene su `agent_key`.
 4. **Construir cada worktree** con la skill `building-a-slice` (inner loop normal, en su cwd).
-   Cada uno mantiene su `journey_smoke` verde localmente.
-5. **Coordinar merge (G3)** en `merge_order` (determinista: por orden de épica):
+   Cada uno reclama su slice y mantiene su `journey_smoke` verde localmente.
+5. **Coordinar merge (G3)** en el `merge_order` aprobado:
    - Merge del PR; tras cada merge, **re-smoke del journey completo** en el árbol principal.
-   - Conflicto → `merge_status:"conflict"`, serializar la perdedora (rebase + re-correr sus gates).
-   - Éxito → `merge_status:"merged"`; `git worktree remove`.
-6. **Cerrar el front** cuando todos `merged`: `parallel_front=null`.
+   - Reporta el resultado desde el worktree:
+     `bash .claude/hooks/build/release-ops.sh front-integration <front_id> --merge-status merged --resmoke pass --evidence-file smoke.txt`
+   - Conflicto → `--merge-status conflict`; serializa la perdedora (rebase + re-correr sus gates).
+6. **Cerrar el front** cuando todos los miembros estén `merged`: lo hace una persona en la consola
+   (el agente solo reporta que su miembro terminó).
 
 ## Reglas duras
 - Nunca escritores paralelos sobre el mismo árbol (por eso worktrees).
 - Nunca paralelizar dentro de una épica (preserva la "regla del esqueleto que camina").
 - Un solape de `files_scope` no detectado que cause conflicto de merge → el re-smoke (G3) lo caza.
+- El agente **no** abre, drena ni cierra el front: esas superficies exigen decisión humana.

package/skills/openspec-archive-change/SKILL.md

@@ -82,6 +82,21 @@ Archive a completed change in the experimental workflow.
    mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
    ```
 
+5-bis. **Report the archived slice (build harness)**
+
+   When the change belongs to an epic slice driven by the build harness, report the domain
+   transition — the runtime owns the slice history, not the local file:
+
+   ```bash
+   [ -x .claude/hooks/build/slice-ops.sh ] && \
+     bash .claude/hooks/build/slice-ops.sh archive \
+       --epic "<EP-XXX>" --openspec-change "<change-name>" --pr-url "<PR URL>"
+   ```
+
+   It is queued and idempotent (protected from the outbox cap), so it survives an offline
+   archive; `rc 3` simply means legacy mode (the file protocol applies). Never block the
+   archive on this step.
+
 6. **Display summary**
 
    Show archive completion summary including:

package/skills/prototyping-screens/SKILL.md

@@ -16,7 +16,8 @@ Genera el **prototipo HTML de referencia** del consumidor: la fuente de verdad v
 - Es **outer-loop**: se corre antes de abrir slices (como `/build:architect`), nunca dentro del
   inner loop de una épica.
 - Escribe **solo** en `docs/05-prototipo/` (carve-out §9.2 de METODOLOGIA) y, con aprobación
-  humana, en `design_source` de `build-state.json` (protocolo de `state/README.md`).
+  humana, reporta el hecho `design_source` (`slice-ops.sh fact design-source …`; protocolo en
+  `building-a-slice/references/runtime-protocol.md`).
 
 ## Artefactos que produce (repo del consumidor)
 
@@ -83,10 +84,13 @@ greenfield → contra tokens + consistencia del lote), corrección y re-render c
 
 1. Abre las pantallas en el navegador del usuario y pide aprobación explícita (por pantalla o por
    lote). Aprobada → `manifest.json` pasa esa entrada a `"aprobada"`.
-2. **Greenfield** con ≥1 pantalla aprobada: ofrece registrar la fuente en `build-state.json` —
-   `design_source.source: "docs/05-prototipo/"`, `confirmed: true`, `confirmed_by`, `confirmed_at`,
-   `notes` — siguiendo el protocolo de escritura de `state/README.md`. Solo con el **sí** explícito
-   del humano.
+2. **Greenfield** con ≥1 pantalla aprobada: ofrece registrar la fuente. Solo con el **sí** explícito
+   del humano:
+
+   ```bash
+   bash .claude/hooks/build/slice-ops.sh fact design-source \
+     --applies true --source "docs/05-prototipo/" --confirmed true --by "<quién aprobó>"
+   ```
 3. **Feature**: `design_source` ya está confirmado; solo se amplía el manifest.
 
 ## Qué NO hace esta skill

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,20 @@ 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 **no** tiene camino por la cola offline (`rc 5`,
+   issue #44): reintenta el mismo comando cuando vuelva la red, antes de pedir el cierre.
+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 +80,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):
@@ -91,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**,
@@ -115,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`) |

package/state/build-state.schema.json

@@ -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`,