@trycore/spec-build-harness 0.8.2 → 0.8.3

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.8.2",
+  "version": "0.8.3",
   "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",
@@ -22,7 +22,10 @@
     "trycore"
   ],
   "skills": "./skills/",
-  "commands": ["./commands/opsx/", "./commands/build/"],
+  "commands": [
+    "./commands/opsx/",
+    "./commands/build/"
+  ],
   "agents": "./agents/build/",
   "hooks": "./hooks/build-harness.json"
 }

package/README.md

@@ -183,7 +183,8 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **v0.7.0** — **orquestación con workflows dinámicos + hardening** (de una evaluación adversarial del propio arnés): **3 plantillas `*.workflow.js`** opt-in y read-only (`explore-fanout`, `wiring-verify`, `release-gate`) que entran **solo donde aportan valor** y nunca en el camino caliente del inner loop; **3 comandos nuevos** `/build:slice` (entrada del inner loop), `/build:release` (outer loop) y `/build:work` (router *classify-and-act*); hook **`release-gate-nudge.sh`** (Stop, determinista: solo sugiere el Release Gate). Rename de los gates de los 5 reviewers pesados → `releases[].gates.{security,smell,ux,coherence,stack_arch}` (`stack`→`stack_arch`; separación `coherence` (release) / `coherence_link` (inner)). Hardening: degradación segura en 8 agentes, escritura atómica del estado, cierre del bypass de specs no-semver, `wiring` exige evidencia ejecutada y `check-agnostic` barre `*.js`. Total: **12 agentes**, **10 hooks**, **5 comandos `/build:*`**.
 - ✅ **v0.8.0** — **motor de contexto + estado anclado a disco + front paralelo inter-épica**: hooks **`statusline-bridge.sh`** (canal CLI) + **`context-monitor.sh`** (umbrales `context.warning_pct`/`context.critical_pct` configurables, 35%/25% por defecto) con **auto-handoff** a `session_continuity` en critical/`PreCompact` y comando **`/build:resume`** para rehidratar desde disco; config **`context.auto_checkpoint`** (opt-in). Reconciliador **`reconcile-build-state.py`** (`SessionStart`): deriva de git + evidencia de tests, degrada `wiring_checklist` sin evidencia, anota *branch drift*, ratchet de gates, fail-open. **Front paralelo** (`parallel_front` en el estado): comando **`/build:front`** + skill **`managing-parallel-front`** + `scripts/lib/front-plan.py` (disjunción por `files_scope`, foundational-first). Schema nuevo: `slice.layer`, `slice.files_scope`, `slice.branch_drift`, `slice.session_continuity`. **Caveat:** `statusLine` es solo canal CLI; en plugin-only el motor de contexto degrada fail-open. Total: **12 agentes**, **13 hooks**, **7 comandos `/build:*`**, **14 skills**.
 - ✅ **v0.8.1** — **hotfix del motor de contexto**: `context-monitor.sh` re-inyectaba `additionalContext` en cada evento `Stop`, lo que re-lanzaba el turno en bucle hasta el tope `CLAUDE_CODE_STOP_HOOK_BLOCK_CAP` (9→override). Ahora en `Stop` re-lanza como mucho una vez por sesión (solo la transición a crítico que graba el handoff) y `warning` nunca inyecta en `Stop`. Cubierto por `test-context-monitor.sh`.
-- ✅ **v0.8.2 (actual)** — **capa de arquitectura (ADD)** entre discovery y construcción: comando **`/build:architect`** + skill **`setup-architecture`** que aplica el método **Attribute-Driven Design** (Len Bass) leyendo `docs/` (solo lectura) y produciendo `docs/adr/` (drivers/ASRs → tácticas → estilos → vistas → ATAM-lite → stack), con **mínimo HITL** (autónomo, una revisión final; propone, no publica). Dos agentes nuevos (`asr-extractor`, `architecture-evaluator`), plantillas ADD embebidas en la skill (`skills/setup-architecture/assets/`) y **`asset-types.json`** (forward-compat runtime v0.9: `arch.drivers`/`arch.adr`/`arch.backlog`). Cierre del lazo: los ADRs se vuelven criterios — el **DoR** exige cobertura para el cimiento fundacional (opt-in, retrocompatible) y el gate **`stack_arch`** audita conformidad contra `docs/adr/`. Total: **14 agentes**, **13 hooks**, **8 comandos `/build:*`**, **15 skills**.
+- ✅ **v0.8.3 (actual)** — **gates de validación paralelizados (sharding lossless)**: el carril `coherence` del Release Gate se shardea **por HU** (≥ 3 HUs, `args.hus[]`) — de un solo agente opus O(HUs) a un shard por HU en paralelo con consolidación **fail-closed** y cobertura completa; nueva plantilla **`dor-fanout.workflow.js`** para los chequeos per-HU del DoR (frontmatter/G-W-T/INVEST en paralelo; el nivel épica sigue en `dor-dod-gatekeeper`, único emisor del veredicto). `security`/`smell`/`ux`/`stack_arch` quedan monolíticos a propósito (riesgo cross-cutting); `integration` sigue secuencial (regla dura §5).
+- ✅ **v0.8.2** — **capa de arquitectura (ADD)** entre discovery y construcción: comando **`/build:architect`** + skill **`setup-architecture`** que aplica el método **Attribute-Driven Design** (Len Bass) leyendo `docs/` (solo lectura) y produciendo `docs/adr/` (drivers/ASRs → tácticas → estilos → vistas → ATAM-lite → stack), con **mínimo HITL** (autónomo, una revisión final; propone, no publica). Dos agentes nuevos (`asr-extractor`, `architecture-evaluator`), plantillas ADD embebidas en la skill (`skills/setup-architecture/assets/`) y **`asset-types.json`** (forward-compat runtime v0.9: `arch.drivers`/`arch.adr`/`arch.backlog`). Cierre del lazo: los ADRs se vuelven criterios — el **DoR** exige cobertura para el cimiento fundacional (opt-in, retrocompatible) y el gate **`stack_arch`** audita conformidad contra `docs/adr/`. Total: **14 agentes**, **13 hooks**, **8 comandos `/build:*`**, **15 skills**.
 
 ## Licencia
 

package/VERSION

@@ -1 +1 @@
-0.8.2
+0.8.3

package/agents/build/dor-dod-gatekeeper.md

@@ -19,6 +19,14 @@ las fases de código.)
 La unidad es la **épica**. Identifica `EP-XXX` en `docs/03-backlog/epicas.md` y el conjunto de HU
 que la componen (las que tienen `epica: EP-XXX` en `docs/04-historias/`). Pasa SOLO si **todas** se
 cumplen; lista cada una con ✓/✗:
+
+> **Conducción opcional — fan-out per-HU (épicas con ≥ 3 HUs).** Los criterios 3-5 (frontmatter, AC
+> G/W/T, INVEST) son por-HU e independientes: puedes conducirlos con la plantilla
+> `building-a-slice/workflows/dor-fanout.workflow.js` (read-only; `args: {epica, hus[]}`) para validarlos
+> **en paralelo** en vez de HU por HU. La plantilla devuelve el diagnóstico per-HU con consolidación
+> fail-closed (HU fallida o shard ausente = false); tú **combinas** ese diagnóstico con los criterios de
+> nivel épica (1-2 y 6-10, que valides tú en sesión) y sigues siendo el **único** que emite el veredicto
+> DoR y abre `active_slice`. Con < 3 HUs la plantilla se auto-salta: valida secuencial como siempre.
 1. La épica existe en `docs/03-backlog/epicas.md` con su trazabilidad a objetivos del PRD.
 2. Tiene **al menos una HU** asociada y todas se enumeran en `hus[]`.
 3. **Cada HU** de la épica: frontmatter YAML completo (`id, titulo, epica, prioridad, complejidad,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trycore/spec-build-harness",
-  "version": "0.8.2",
+  "version": "0.8.3",
   "description": "Arnés agéntico de construcción de Trycore para Claude Code: pipeline de dos loops (slice por épica + release gate) con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "type": "module",
   "bin": {

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

@@ -7,7 +7,9 @@
 ## Reglas duras (todas las plantillas las cumplen)
 1. **Solo para épicas grandes.** Los workflows del inner loop son **OPT-IN** y solo para épicas troceadas por
    el gate de tamaño (`sub_slices[]` no vacío). **Nunca** en el camino caliente ≤ ~20 min de una épica
-   atómica: inflaría el inner loop barato.
+   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
    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
@@ -23,3 +25,7 @@
   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.
+- **`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`
+  en sesión, que combina ambos y es el único que emite el veredicto DoR. Guard: ≥ 3 HUs.

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

@@ -0,0 +1,98 @@
+// =============================================================================
+// PLANTILLA — referencia, NO un script a correr verbatim.
+// dor-fanout.workflow.js — Fan-out de los chequeos PER-HU del DoR (inner loop).
+//
+// QUÉ PARALELIZA (y qué NO): SOLO los criterios del DoR que son por-HU e independientes
+// entre sí — frontmatter completo + estado:lista, AC en Given/When/Then proporcional a
+// `complejidad`, e INVEST. Los criterios de NIVEL ÉPICA (trazabilidad de la épica,
+// dependencias en history[], cimiento construido, gate de tamaño, stack/allowlist,
+// fuente de diseño, cobertura de ADR) NO van aquí: los valida dor-dod-gatekeeper en
+// sesión — necesitan estado y son baratos. Este workflow ataca lo LENTO: O(HUs) → O(1).
+//
+// READ-ONLY sobre el estado: NO escribe gates.dor ni abre active_slice. El ÚNICO que
+// abre el slice sigue siendo dor-dod-gatekeeper, que COMBINA este diagnóstico per-HU
+// con sus criterios de épica y emite el veredicto DoR completo.
+//
+// CUÁNDO: SOLO con ≥ 3 HUs (bajo eso el fan-out no paga su overhead y el inner loop
+// debe seguir barato). Consolidación FAIL-CLOSED con cobertura COMPLETA: una HU
+// fallida o un shard ausente = DoR per-HU false, nunca muestreo silencioso.
+//
+// PLANTILLA AGNÓSTICA: sin vocabulario de dominio/cliente (scripts/check-agnostic.sh
+// escanea *.js). Si METODOLOGIA.md (§3.1) 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 (por eso usa `await` y `return` a nivel superior). NO es un módulo node standalone.
+// =============================================================================
+
+export const meta = {
+  name: 'dor-fanout',
+  description: 'Fan-out per-HU de los chequeos del DoR (frontmatter, AC G/W/T proporcional, INVEST) con consolidación fail-closed. Read-only; dor-dod-gatekeeper combina el diagnóstico y emite el veredicto.',
+  phases: [{ title: 'HUs', detail: 'un validador solo-lectura por HU, en paralelo' }],
+}
+
+const HU_CHECK_SCHEMA = {
+  type: 'object', additionalProperties: false,
+  required: ['hu', 'pass', 'faltantes'],
+  properties: {
+    hu: { type: 'string' },
+    pass: { type: 'boolean', description: 'true SOLO si los 3 bloques (frontmatter, AC, INVEST) están completos y verificados' },
+    faltantes: { type: 'array', items: { type: 'string' }, description: 'cada criterio incumplido, con detalle accionable' },
+  },
+}
+
+// Insumos por `args` (dor-dod-gatekeeper los pasa READ-ONLY; el workflow no decide alcance):
+//   args.epica  : string   — ID de la épica (solo para el reporte).
+//   args.hus    : string[] — IDs de las HU en alcance (hus[] del slice candidato).
+//   args.husDir : string   — directorio de las HU (default 'docs/04-historias').
+const epica = (args && args.epica) || '<EP-XXX>'
+const hus = (args && Array.isArray(args.hus)) ? args.hus.filter(Boolean) : []
+const husDir = (args && args.husDir) || 'docs/04-historias'
+
+// Guard de tamaño: bajo 3 HUs el fan-out no paga su overhead → el gatekeeper valida
+// secuencial en sesión (comportamiento previo). Espeja el guard de explore-fanout.
+if (hus.length < 3) {
+  log(`Épica ${epica} con ${hus.length} HU(s): fan-out no amortiza — validación secuencial en sesión.`)
+  return { skipped: true, reason: 'pocas-hus', hus_count: hus.length }
+}
+
+phase('HUs')
+log(`DoR per-HU: fan-out de ${hus.length} HUs de ${epica} (cobertura completa, sin muestreo)`)
+const checks = await parallel(hus.map((hu) => async () => {
+  try {
+    const v = await agent(
+      `Eres un validador SOLO-LECTURA del DoR para UNA SOLA historia de usuario: ${hu} (épica ${epica}).
+Lee ${husDir}/${hu}.md y verifica EXACTAMENTE estos 3 bloques (nada de nivel épica):
+1. FRONTMATTER completo: id, titulo, epica, prioridad, complejidad, estado — y estado: lista.
+2. AC en Given/When/Then PROPORCIONAL a complejidad: trivial/baja → 1-2 (happy + error/edge crítico si
+   existe); media → 3 (happy + error + edge); alta → 3-5 (cobertura completa). Regla dura: toda rama de
+   error/edge que exista DEBE tener su escenario; NO exijas cuota fija a una HU trivial.
+3. INVEST: evalúa tú mismo los 6 criterios (Independent, Negotiable, Valuable, Estimable, Small, Testable).
+pass:true SOLO si los 3 bloques cumplen. Cada incumplimiento va en faltantes[] con detalle accionable
+(qué campo/escenario/criterio y por qué). Si el archivo no existe o es ilegible → pass:false con el motivo.
+NO edites nada; NO valides otras HU ni criterios de épica.`,
+      { label: `dor:${hu}`, phase: 'HUs', agentType: 'Explore', schema: HU_CHECK_SCHEMA },
+    )
+    if (!v) return { hu, pass: false, faltantes: [`${hu}: sin veredicto`] }
+    return { hu, pass: v.pass === true, faltantes: v.faltantes || [] }
+  } catch (e) {
+    return { hu, pass: false, faltantes: [`${hu}: el validador falló — revalidar en sesión`] }
+  }
+}))
+
+// Consolidación FAIL-CLOSED + cobertura completa: shard ausente = hueco, nunca verde.
+const done = checks.filter(Boolean)
+const missing = hus.length - done.length
+const bad = done.filter((c) => !c.pass)
+const all_pass = bad.length === 0 && missing === 0
+
+return {
+  epica,
+  all_pass,                       // pass per-HU; NO es el DoR completo (falta el nivel épica)
+  hus: done,                      // diagnóstico por HU para el reporte ✓/✗ del gatekeeper
+  faltantes: [
+    ...bad.flatMap((c) => c.faltantes),
+    ...(missing > 0 ? [`${missing} HU(s) sin resultado — cobertura incompleta, revalidar en sesión`] : []),
+  ],
+  note: 'Read-only. dor-dod-gatekeeper combina esto con los criterios de NIVEL ÉPICA (dependencias, cimiento, tamaño, stack, diseño, ADR) y es el único que emite el veredicto DoR y abre active_slice.',
+}

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

@@ -66,7 +66,10 @@ Checklist de cierre: `references/release-dod.md`.
 > **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
 > pesados; el gate `integration` (paso 4) sigue siendo **secuencial**, vía `verify`/`run` con **deps reales**,
-> **fuera** del `parallel()`. El resultado se escribe igual en `releases[]` respetando **una escritura por
+> **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`.
 

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

@@ -16,4 +16,9 @@
 
 ## Plantillas
 - **`release-gate.workflow.js`** — `parallel(5 reviewers)` → `integration` secuencial → síntesis a
-  `releases[].gates.{security, smell, ux, coherence, stack_arch, integration}`.
+  `releases[].gates.{security, smell, ux, coherence, stack_arch, integration}`. El carril **`coherence`**
+  se shardea **por HU** cuando la release tiene ≥ 3 HUs (`args.hus[]`, computadas read-only por la skill):
+  la trazabilidad triple de cada HU es independiente → el sharding es *lossless* y el carril más lento pasa
+  de O(HUs) a O(1) + consolidación **fail-closed** con cobertura completa (shard fallido/ausente = gate
+  false, nunca muestreo). `security`/`smell`/`ux`/`stack_arch` quedan **monolíticos a propósito**:
+  shardearlos por archivos puede perder hallazgos cross-cutting.

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

@@ -19,9 +19,9 @@
 
 export const meta = {
   name: 'release-gate',
-  description: 'Reviewers pesados en paralelo + integración secuencial + síntesis para el Release Gate (outer loop). Read-only; devuelve veredictos, no escribe estado.',
+  description: 'Reviewers pesados en paralelo (coherence shardeado por HU cuando la release es grande) + integración secuencial + síntesis para el Release Gate (outer loop). Read-only; devuelve veredictos, no escribe estado.',
   phases: [
-    { title: 'Reviewers', detail: '5 reviewers pesados en paralelo sobre el diff acumulado' },
+    { title: 'Reviewers', detail: '5 reviewers en paralelo; el carril coherence fan-out por HU (≥3 HUs) con consolidación fail-closed' },
     { title: 'Integration', detail: 'journey completo con deps reales (SECUENCIAL, fuera del parallel)' },
   ],
 }
@@ -35,24 +35,79 @@ const RELEASE_REVIEW_SCHEMA = {
   },
 }
 
-// diffRange y si la release tiene UI llegan por `args` (la skill los computa READ-ONLY).
+// diffRange, si la release tiene UI y la lista de HUs llegan por `args` (la skill los computa READ-ONLY).
+//   args.hus : string[] — IDs de TODAS las HU de las épicas de la release (para shardear coherence).
+//              Ausente o < 3 → coherence corre monolítico (comportamiento previo, sin inflar releases chicas).
 const diffRange = (args && args.diffRange) || '<merge-anterior>..main'
 const hasUI = !!(args && args.hasUI)
+const hus = (args && Array.isArray(args.hus)) ? args.hus.filter(Boolean) : []
+
+// --- Carril coherence: SHARDING por HU (lossless) ----------------------------
+// La trazabilidad triple AC↔change↔código de cada HU es INDEPENDIENTE de las demás: shardearla
+// no pierde hallazgos cruzados (a diferencia de security/smell, que quedan monolíticos a propósito).
+// Consolidación FAIL-CLOSED y cobertura COMPLETA: un shard fallido/ausente = gate false, nunca
+// muestreo silencioso. Con < 3 HUs el fan-out no paga su overhead → monolítico como siempre.
+async function coherenceLane() {
+  if (hus.length < 3) {
+    try {
+      const v = await agent(
+        `Eres el reviewer pesado del Release Gate para el gate "coherence". Verifica READ-ONLY la trazabilidad
+triple AC↔change↔código de TODAS las HU de la release sobre el diff acumulado (${diffRange}). Si NO puedes
+verificar, devuelve pass:false con el motivo — nunca PASS por defecto.`,
+        { label: 'release:coherence', agentType: 'coherence-three-way', phase: 'Reviewers', schema: RELEASE_REVIEW_SCHEMA },
+      )
+      if (!v) return { gate: 'coherence', value: false, error: 'sin veredicto' }
+      return { gate: 'coherence', value: v.pass === true, findings: v.findings || [] }
+    } catch (e) {
+      return { gate: 'coherence', value: false, error: 'el reviewer falló' }
+    }
+  }
+  log(`coherence: fan-out por HU (${hus.length} shards — cobertura completa, sin muestreo)`)
+  const shards = await parallel(hus.map((hu) => async () => {
+    try {
+      const v = await agent(
+        `Eres un shard del reviewer "coherence" del Release Gate. Verifica READ-ONLY la trazabilidad triple
+AC↔change↔código de UNA SOLA HU: ${hu}. Lee sus AC (Given/When/Then), el change OpenSpec que la cubre y el
+código/tests del diff acumulado (${diffRange}) que la implementan. pass:true SOLO si cada AC de ${hu} tiene
+test real y código cableado, sin huérfanos. Si NO puedes verificar → pass:false con el motivo.`,
+        { label: `release:coherence:${hu}`, agentType: 'coherence-three-way', phase: 'Reviewers', schema: RELEASE_REVIEW_SCHEMA },
+      )
+      if (!v) return { hu, pass: false, findings: [`${hu}: sin veredicto`] }
+      return { hu, pass: v.pass === true, findings: (v.findings || []).map((f) => `${hu}: ${f}`) }
+    } catch (e) {
+      return { hu, pass: false, findings: [`${hu}: el shard falló`] }
+    }
+  }))
+  const done = shards.filter(Boolean)
+  const missing = hus.length - done.length            // shard ausente (skip/kill) = hueco de cobertura
+  const bad = done.filter((s) => !s.pass)
+  const value = bad.length === 0 && missing === 0
+  return {
+    gate: 'coherence', value,
+    findings: [
+      ...bad.flatMap((s) => s.findings),
+      ...(missing > 0 ? [`coherence: ${missing} shard(s) sin resultado — cobertura incompleta, gate false`] : []),
+    ],
+  }
+}
 
 // --- PASO A · Reviewers pesados EN PARALELO (exactamente estos 5) ------------
 // Cada uno delega en su subagente sobre el MISMO diff acumulado y devuelve síntesis.
 // Barrera deliberada: la síntesis de release necesita los 5 veredictos juntos.
+// security/smell/ux/stack_arch quedan MONOLÍTICOS a propósito: shardearlos por archivos
+// puede perder hallazgos cross-cutting (p.ej. un bypass de auth visible solo entre módulos).
 phase('Reviewers')
 const REVIEWERS = [
   { gate: 'security',   agentType: 'security-reviewer' },
   { gate: 'smell',      agentType: 'simple-design-reviewer' },
   { gate: 'ux',         agentType: 'ux-krug-reviewer' },   // null SOLO si la release no tiene UI
-  { gate: 'coherence',  agentType: 'coherence-three-way' },
+  { gate: 'coherence',  agentType: 'coherence-three-way' }, // carril con sharding interno por HU (ver coherenceLane)
   { gate: 'stack_arch', agentType: 'stack-guardian' },
 ]
 const reviews = await parallel(REVIEWERS.map((r) => async () => {
   // N/A legítimo: ux sin UI → null (NO es fallo). El resto SIEMPRE corre.
   if (r.gate === 'ux' && !hasUI) return { gate: r.gate, value: null, na: true }
+  if (r.gate === 'coherence') return coherenceLane()
   try {
     const v = await agent(
       `Eres el reviewer pesado del Release Gate para el gate "${r.gate}". Revisa READ-ONLY el diff acumulado de la