@trycore/spec-build-harness 0.8.2 → 0.8.4

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.4",
   "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/METODOLOGIA.md

@@ -124,6 +124,18 @@ sola pasada**: a medida que crece el contexto, la atención se degrada ("context
 > construye **encima** del scaffold: el scaffold es el shell vacío que arranca; el walking skeleton
 > es el primer journey real más delgado. Sin scaffold confirmado no se abre ningún slice.
 
+> **Paso 1-bis — la épica caparazón (solo greenfield).** En un proyecto **nuevo**
+> (`project_kind: "greenfield"`), entre el scaffold y las épicas de negocio existe un tercer
+> concepto: el **caparazón** — navegación/menús, layout/panel central, homepage, login/authN y
+> redirecciones/guards (contrato podable en
+> `skills/building-a-slice/references/foundation-contract.md`). Se modela como **épica
+> `layer: foundational` obligatoria y primera**: el DoR bloquea **proactivamente** toda épica
+> `business` hasta archivarla con su checklist **evidenciada** (gate de proyecto `foundation`).
+> El arnés **propone** su borrador y solo lo escribe con aprobación humana (§9.2); si se
+> rechaza, se crea en discovery. En **brownfield** el mecanismo es N/A y el arnés no pregunta.
+> Scaffold = shell vacío que arranca; caparazón = shell con contenido fundacional; walking
+> skeleton = primer journey de negocio más delgado, construido **sobre** ambos.
+
 El arnés prohíbe construir capas horizontales aisladas que "se juntan al final" (el anti-patrón que
 hace que todos los gates por-slice estén en verde y el producto aun así no funcione de punta a
 punta). En su lugar:
@@ -188,6 +200,11 @@ Una épica **no entra a construcción** hasta cumplir todo (lo valida `dor-dod-g
   acceso a datos, arquitectura base, design-system/componentes base) ya existe como épica(s)
   `layer: foundational` **archivada(s)**. Si arrastra cimiento no construido → STOP: se extrae a una
   épica fundacional previa. La cláusula "no bloquean" de dependencias **no aplica al cimiento**.
+- **Caparazón construido (solo greenfield — PROACTIVO)**: con `project_kind: "greenfield"` y
+  `foundation.required: true`, ninguna épica `business` abre hasta que la épica caparazón esté
+  archivada con su checklist evidenciada (`foundation.completed_at`); las fundacionales sí abren.
+  No depende de detectar arrastre (eso es "Cimiento construido"): en greenfield bloquea siempre.
+  Brownfield → N/A.
 - **Tamaño acotado (gate de descomposición)**: si la épica supera el umbral —por defecto **> 3 HU** ó
   **≥ 3 capas tocadas**, configurable— se descompone en `sub_slices[]` construidos de a uno
   (`journey_smoke` verde entre cada uno). Umbral proporcional, no cuota rígida.
@@ -476,10 +493,13 @@ La construcción **consume** los artefactos de discovery y los trata como entrad
 
 El arnés **no escribe** en los artefactos de discovery (`docs/01-prd/` … `docs/04-historias/`); cuando
 una HU no cumple DoR, devuelve el trabajo a discovery (`/trycore:*`). Los contactos de escritura del
-arnés en `docs/` son dos y están acotados: la **back-reference** del change en la épica y las HU al
-archivar (§6.4), y el subárbol **`docs/adr/`** —propiedad de construcción— que produce la capa de
-arquitectura (§9.3). `docs/adr/` **no** es un artefacto de discovery: es la salida de construcción que
-traza *hacia* discovery (HU/PRD) sin modificarla.
+arnés en `docs/` son **tres** y están acotados: la **back-reference** del change en la épica y las HU
+al archivar (§6.4), el subárbol **`docs/adr/`** —propiedad de construcción— que produce la capa de
+arquitectura (§9.3), y la **épica caparazón** en `docs/03-backlog/epicas.md` — únicamente esa épica,
+únicamente con **aprobación humana explícita** del borrador propuesto en `/build:onboard` Fase 2c
+(frontmatter `origin: harness-draft`); si el humano rechaza, la épica se crea en discovery como
+siempre. `docs/adr/` **no** es un artefacto de discovery: es la salida de construcción que traza
+*hacia* discovery (HU/PRD) sin modificarla.
 
 ### 9.3 Capa de arquitectura (ADD) — entre discovery y construcción
 
@@ -544,3 +564,8 @@ salida es file-based y la propuesta se materializa en git, mañana irá por API
     disjuntas en `files_scope` se paralelizan; una épica `layer: foundational` nunca entra al front y
     lo pone en `draining` hasta que se vacía; el merge exige re-smoke del journey completo tras cada
     integración.
+13. **Caparazón primero en greenfield (§2 Paso 1-bis)**: en un proyecto nuevo, la épica caparazón
+    (`foundation.epic`) se construye y archiva **antes** que cualquier épica `business`; su DoD
+    exige evidencia de ejecución por cada ítem `applies: true` del contrato. En brownfield el
+    mecanismo es N/A y no se pregunta. El arnés propone el borrador de la épica; solo lo escribe
+    con aprobación humana explícita (§9.2).

package/README.md

@@ -183,7 +183,9 @@ 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.4 (actual)** — **épica caparazón obligatoria en greenfield**: nuevo campo `project_kind` con detección automática conservadora en `trycore-build init` (brownfield seguro = manifiesto + código + **historial git con commits de código**; ambigüedad → una sola pregunta en `/build:onboard`; **en brownfield el mecanismo es N/A total, sin preguntar**) y gate de proyecto **`foundation`**: contrato del caparazón (navegación/menús · layout/panel central · homepage · login/authN · redirecciones/guards) como checklist podable con **evidencia de ejecución por ítem** (patrón `wiring_checklist`, contrato en `skills/building-a-slice/references/foundation-contract.md`). `/build:onboard` **Fase 2c** poda el contrato y redacta el **borrador híbrido** de la épica (solo se escribe en `epicas.md` con aprobación humana explícita — carve-out §9.2). **DoR 7-bis proactivo**: en greenfield ninguna épica `business` abre slice hasta que la caparazón esté **archivada con checklist evidenciada** (`foundation.completed_at`); las fundacionales y el carril micro-change nunca se bloquean. Línea `Caparazón` en `status`/`doctor`. Retrocompatible: campos opcionales del schema.
+- ✅ **v0.8.3** — **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.4

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,
@@ -33,6 +41,15 @@ cumplen; lista cada una con ✓/✗:
    como épica(s) `layer: foundational` **archivada(s)** en `history[]`. Si arrastra cimiento no construido,
    **NO abras el slice**: instruye extraerlo a una épica fundacional previa y construirla primero. Aquí la
    cláusula "explícitamente no bloquean" del criterio 6 **NO aplica**: el cimiento bloquea siempre.
+7-bis. **Caparazón construido (solo greenfield — PROACTIVO)**: lee `project_kind` y `foundation`
+   en `build-state.json`. Si `project_kind === "greenfield"` y `foundation.required === true` y
+   la épica evaluada es `layer: business`: exige `foundation.completed_at` estampado (la épica
+   caparazón, `foundation.epic`, archivada y con su checklist evidenciada). Si no está estampado,
+   **NO abras el slice**: instruye construir primero la épica caparazón (`foundation.epic`; si es
+   `null`, correr `/build:onboard` Fase 2c o crearla en discovery). Las épicas `layer: foundational`
+   no se bloquean por este criterio. Brownfield o `foundation.required !== true` → **N/A** (no
+   bloquea, no preguntes). A diferencia del criterio 7, aquí NO evalúas arrastre: en greenfield
+   el bloqueo es incondicional hasta que el cimiento exista archivado.
 8. **Tamaño acotado**: si la épica supera el umbral del gate de descomposición —heurística por defecto
    **> 3 HU** ó **≥ 3 capas tocadas** (configurable por proyecto)— **no la abras como slice único**:
    instruye descomponerla en `sub_slices[]` construidos de a uno (`journey_smoke` verde entre cada uno).
@@ -72,6 +89,15 @@ Pasa SOLO si **todos** estos gates del **inner loop** están en `true` (o `null`
 6-bis. **Sub-slices completos**: si `active_slice.sub_slices[]` no está vacío, **todos** deben estar en
    `status: done` (cada uno con su `journey_smoke` verde). Una épica descompuesta no cierra `dod` con
    sub-slices pendientes (sería cierre prematuro de alcance).
+6-ter. **Checklist del caparazón evidenciada (solo la épica caparazón)**: si la épica que cierra
+   es `foundation.epic`, **todos** los ítems de `foundation.checklist[]` con `applies: true`
+   deben tener `evidence` no vacía de **ejecución real** (test corrido, comando, screenshot MCP
+   — nunca inspección). Si falta evidencia, `dod` NO cierra: enumera los ítems pendientes. Al
+   cerrar `dod` y archivarse la épica, propone estampar `foundation.completed_at` (ISO-8601 UTC)
+   — con eso las épicas `layer: business` quedan desbloqueadas del criterio 7-bis. Para
+   cualquier otra épica este punto es N/A. La `evidence` de cada ítem la escribe el
+   `build-orchestrator` durante la construcción (misma disciplina que `wiring_checklist[]`: prueba
+   real ejecutada); tú solo la verificas y, al cerrar, estampas `foundation.completed_at`.
 7. **`wiring_verified`** — `true`. Prerequisito **duro** de `dod`: lo cierra el `wiring-adversarial-verifier`
    (subagente **independiente**, contexto virgen) tras intentar refutar el slice (stubs, rutas sin cablear,
    AC sin test, items de `wiring_checklist[]` aún `failing`) y no hallar huecos. **Tu DoD declarativo es un

package/commands/build/onboard.md

@@ -46,6 +46,7 @@ Voy a leer tu PRD/openspec para proponer valores y confirmar contigo:
 6. Decisiones de alto impacto que exigen explicabilidad en UX
 7. Fuente de diseño / referencia visual (prototipo/export) y pantallas — o "N/A" si no hay UI
 8. Capa de cada épica del backlog: **fundacional** (cimiento) vs **negocio**
+9. (Solo proyecto nuevo) Contrato del caparazón: checklist de la épica fundacional de app shell
 ```
 
 ---
@@ -72,6 +73,15 @@ Voy a leer tu PRD/openspec para proponer valores y confirmar contigo:
 
 ## Fase 2b: Clasificar la capa de las épicas (cimiento vs negocio)
 
+**Primero, resuelve `project_kind`** (lee `.claude/state/build-state.json`):
+- `"brownfield"` → el mecanismo del caparazón es **N/A**: no preguntes ni exijas nada de la
+  Fase 2c; clasifica capas como siempre y sigue.
+- `null` / ausente (detección ambigua del CLI) → pregunta **una sola vez** vía AskUserQuestion:
+  *"¿Este proyecto es una app nueva (greenfield: el caparazón — menús, layout, homepage, login,
+  redirecciones — aún no existe) o ya construida (brownfield)?"*. Escribe `project_kind` y
+  `project_kind_source: "human"` en el estado (valida contra el schema tras escribir).
+- `"greenfield"` → tras clasificar capas (abajo), continúa a la **Fase 2c**.
+
 El factor que más reduce el consumo de contexto por slice es que el **cimiento** ya esté construido y
 abstraído antes de que el loop tome historias de negocio. Para habilitar el gate de DoR "Cimiento
 construido":
@@ -87,6 +97,38 @@ No inventes la clasificación: derívala del PRD/Story Map y confírmala con el
 
 ---
 
+## Fase 2c: (Solo greenfield) Contrato del caparazón y su épica
+
+Contrato completo en `.claude/skills/building-a-slice/references/foundation-contract.md`.
+Si `project_kind !== "greenfield"`, salta esta fase (N/A total).
+
+1. **Podar la checklist** vía AskUserQuestion (multiSelect) partiendo de los 5 ítems canónicos
+   (`navegacion-menus`, `layout-panel-central`, `homepage`, `login-authn`,
+   `redirecciones-guards`) según el tipo de app (una API sin UI poda los de UI y conserva
+   `login-authn`). Ítem podado = `applies: false` (se conserva como decisión, no se borra).
+   El usuario puede añadir ítems propios (id kebab-case). Si el humano poda **todos** los ítems
+   (ningún `applies: true`), no hay caparazón exigible: escribe `foundation.required: false` y el
+   mecanismo queda N/A (el DoR no bloqueará por caparazón).
+2. **Identificar la épica caparazón** en `docs/03-backlog/epicas.md`: una épica
+   `layer: foundational` cuyo alcance cubra los ítems `applies: true`.
+   - **Existe** → propónla al usuario y fija `foundation.epic`.
+   - **No existe** → **borrador híbrido**: redacta la épica caparazón (título, objetivo, una HU
+     por ítem `applies: true` con AC en Given/When/Then) y preséntala vía AskUserQuestion.
+     - **Aprueba** → escríbela en `docs/03-backlog/epicas.md` con frontmatter
+       `layer: foundational` y `origin: harness-draft`, y fija `foundation.epic`.
+       **Este es el ÚNICO caso en que el arnés escribe una épica** (carve-out de METODOLOGIA
+       §9.2: solo la épica caparazón, solo con aprobación explícita).
+     - **Rechaza** → **STOP** de la fase: deja `foundation.epic: null`, instruye crearla en
+       discovery (`/trycore:*`) con la checklist como alcance. El gate del DoR bloqueará las
+       épicas de negocio igual hasta que exista y se archive.
+3. **Persistir en el estado**: escribe `foundation.required: true`, `foundation.checklist[]`
+   (todos los ítems con su `applies`, `evidence: ""`), `foundation.epic` (o `null`). Escribe
+   **solo** los campos del schema (`foundation` es `additionalProperties: false`) y **valida
+   contra `build-state.schema.json` tras escribir** (aborta si no valida). Una transición = una
+   escritura.
+
+---
+
 ## Fase 3: Resolver el bloque de CLAUDE.md
 
 Lee `CLAUDE.md`. Encuentra el bloque entre `<!-- BEGIN trycore-build-harness` y `<!-- END trycore-build-harness -->`.
@@ -162,6 +204,7 @@ PII/datos:          <...>
 Secretos:           <...>
 Decisiones clave:   <...>
 Fuente diseño:      <...>
+Caparazón:          <N/A (brownfield) | EP-XXX con N ítems aplicables | pendiente en discovery>
 
 CLAUDE.md actualizado. Auto-memory escrita. Los agentes de calidad ya leen tu dominio.
 

package/commands/build/slice.md

@@ -59,6 +59,11 @@ Antes de escribir código de slice, verifica los gates de proyecto:
 - `scaffold.confirmed` debe ser `true`. Si es `false` → **STOP**: delega en la **Fase 0** de `building-a-slice`
   (pregunta explícita; el arnés **no genera** el scaffold). No abras el slice.
 - Si el proyecto tiene UI, `design_source.confirmed` debe ser `true` (Fase 0-bis). Si no → **STOP** igual.
+- **Caparazón (solo greenfield)**: si `project_kind === "greenfield"` y `foundation.required === true`
+  y la épica objetivo es `layer: business` mientras `foundation.completed_at` no esté estampado (la
+  caparazón `foundation.epic` archivada con evidencia) → **STOP**: solo la épica caparazón
+  (`foundation.epic`) u otra fundacional puede abrir. Lo valida en detalle el `dor-dod-gatekeeper`
+  (criterio 7-bis). Brownfield → N/A, no preguntes.
 
 El hook `scaffold-guard.sh` respalda esto en tiempo real.
 

package/commands/build/work.md

@@ -28,6 +28,15 @@ Si `NOT_INSTALLED` → ejecuta `trycore-build init` y vuelve.
 
 Aplica las reglas en orden:
 
+0. **¿Greenfield sin caparazón construido?** — si `build-state.json` tiene
+   `project_kind: "greenfield"`, `foundation.required: true` y `foundation.completed_at` sin
+   estampar → **enruta directo a construir la épica caparazón**
+   (`foundation.epic`) por el carril **`building-a-slice`**. Si `foundation.epic` es `null`,
+   enruta a `/build:onboard` (Fase 2c) o a discovery para definirla. Ninguna épica de negocio
+   pasa por delante. Brownfield o `foundation.required` ausente/false → esta regla es N/A.
+   Esta regla gatea **aperturas de slice** (épicas): el carril de **mantenimiento**
+   (`building-a-micro-change`, regla 1) no se bloquea — un typo/copy/config fix sigue su carril
+   normal aun sin caparazón construida.
 1. **¿Mantenimiento sin capacidad nueva?** — typo, ajuste de copy/config/docs, bump de dependencia **ya
    permitida**, o fix de **pocas líneas** sin nueva capacidad **Y** sin ninguno de los límites duros del
    paso 3 → carril **`building-a-micro-change`** (`fix/*`|`chore/*` → PR, **sin** abrir `active_slice`).

package/dist/commands/doctor.js

@@ -66,6 +66,14 @@ export async function doctor(opts) {
             const st = JSON.parse(fs.readFileSync(t.stateFile, 'utf8'));
             const confirmed = st?.scaffold?.confirmed === true;
             console.log(`Scaffold (Paso 1): ${confirmed ? '✓ confirmado' : '✗ pendiente — confírmalo en building-a-slice (Fase 0) antes de fases de código'}`);
+            const pk = st?.project_kind ?? null;
+            const fnd = st?.foundation ?? null;
+            if (pk === 'greenfield' && fnd?.required === true && !fnd?.completed_at) {
+                console.log(`Caparazón (1-bis):  ✗ pendiente — ${fnd?.epic ? `construye ${fnd.epic} antes de épicas de negocio` : 'define la épica caparazón en /build:onboard (Fase 2c)'}`);
+            }
+            else if (pk === 'greenfield' && fnd?.completed_at) {
+                console.log(`Caparazón (1-bis):  ✓ construido (${fnd.epic})`);
+            }
             const hist = Array.isArray(st?.history) ? st.history : [];
             const pend = hist.filter((h) => h?.reflected !== true).length;
             if (pend > 0) {

package/dist/commands/init.js

@@ -9,7 +9,7 @@ import path from 'node:path';
 import { ASSETS, readPackageVersion, targetPaths } from '../lib/paths.js';
 import { linkChildren, countChildren, chmodExec } from '../lib/install-engine.js';
 import { upsertMarkedBlock } from '../lib/markers.js';
-import { seedState, seedConfig, seedBuildConfig } from '../lib/state-seed.js';
+import { seedState, seedConfig, seedBuildConfig, stampProjectKind } from '../lib/state-seed.js';
 import { mergeHarnessSettings } from '../lib/settings-merge.js';
 import { captureStack, renderAllowlist } from '../lib/stack-prompt.js';
 import { checkDeps } from './doctor.js';
@@ -57,6 +57,7 @@ export async function init(opts) {
     }
     // 2) Estado (schema/README versionados; build-state.json vacío solo si falta) [C1]
     const { stateSeeded } = seedState(targetDir);
+    const projectKind = stampProjectKind(targetDir);
     // 3) stack-allowlist.json del consumidor (artefacto del consumidor)
     let allowlist = null;
     if (!fs.existsSync(t.configFile) && mode === 'init') {
@@ -87,6 +88,7 @@ export async function init(opts) {
     console.log(`  Estado:    ${stateSeeded ? 'build-state.json sembrado (vacío)' : 'build-state.json preservado'}`);
     console.log(`  Config:    ${configSeeded ? 'stack-allowlist.json sembrado' : 'stack-allowlist.json preservado'}`);
     console.log(`  Config:    ${buildConfigSeeded ? 'build-config.json sembrado' : 'build-config.json preservado'}`);
+    console.log(`  Proyecto:  ${projectKind === 'brownfield' ? 'brownfield (épica caparazón N/A)' : projectKind === 'greenfield' ? 'greenfield (épica caparazón requerida — se define en /build:onboard)' : 'indeterminado (se confirma en /build:onboard)'}`);
     console.log('');
     console.log('Siguiente paso — abre Claude Code y ejecuta:');
     console.log('  /build:onboard   # parametriza el dominio (PII, capa IA, capa determinista) y escribe memoria');

package/dist/commands/status.js

@@ -40,6 +40,25 @@ export async function status(opts) {
             console.log('Estado del arnés:');
             console.log(`  Fase:       ${st.harness_phase ?? '?'}`);
             console.log(`  Scaffold:   ${st.scaffold?.confirmed === true ? '✓ confirmado (Paso 1)' : '✗ pendiente (Paso 1)'}`);
+            const pk = st.project_kind ?? null;
+            const fnd = st.foundation ?? null;
+            let capLine;
+            if (pk === 'brownfield') {
+                capLine = 'N/A (brownfield)';
+            }
+            else if (pk === 'greenfield' && fnd?.required !== true) {
+                capLine = '✗ contrato sin definir — /build:onboard (Fase 2c)';
+            }
+            else if (fnd?.required === true && fnd?.completed_at) {
+                capLine = `✓ construido${fnd.epic ? ` (${fnd.epic})` : ''}`;
+            }
+            else if (fnd?.required === true) {
+                capLine = `✗ pendiente${fnd?.epic ? ` (${fnd.epic})` : ' — define la épica en /build:onboard'}`;
+            }
+            else {
+                capLine = 'N/A';
+            }
+            console.log(`  Caparazón:  ${capLine}`);
             const slice = st.active_slice;
             if (slice) {
                 const openGates = Object.entries(slice.gates ?? {})

package/dist/lib/state-seed.js

@@ -4,6 +4,7 @@
 // y NUNCA se sobreescribe (es propiedad del equipo).
 import fs from 'node:fs';
 import path from 'node:path';
+import { spawnSync } from 'node:child_process';
 import { ASSETS, targetPaths } from './paths.js';
 import { ensureDir } from './install-engine.js';
 /** Estado inicial vacío (fallback si falta el template del paquete). */
@@ -12,6 +13,9 @@ const EMPTY_STATE = {
     harness_phase: 'authoring',
     scaffold: { confirmed: false, confirmed_by: null, confirmed_at: null, notes: '' },
     design_source: { applies: false, confirmed: false, confirmed_by: null, confirmed_at: null, source: '', notes: '' },
+    project_kind: null,
+    project_kind_source: null,
+    foundation: { required: false, epic: null, completed_at: null, checklist: [] },
     active_slice: null,
     history: [],
     releases: [],
@@ -56,7 +60,6 @@ export function seedConfig(targetDir, allowlist) {
     else {
         return { configSeeded: false };
     }
-    void path;
     return { configSeeded: true };
 }
 /**
@@ -73,3 +76,94 @@ export function seedBuildConfig(targetDir) {
     fs.copyFileSync(ASSETS.buildConfigTemplate, t.buildConfigFile);
     return { buildConfigSeeded: true };
 }
+const MANIFESTS = [
+    'package.json', 'pom.xml', 'build.gradle', 'build.gradle.kts', 'go.mod',
+    'Cargo.toml', 'composer.json', 'pyproject.toml', 'requirements.txt', 'Gemfile',
+];
+const CODE_EXTS = ['.ts', '.tsx', '.js', '.jsx', '.java', '.kt', '.go', '.rs', '.php', '.py', '.cs', '.rb', '.swift', '.vue', '.svelte'];
+const CODE_DIRS = ['src', 'app', 'lib', 'apps', 'packages'];
+function dirHasCode(dir, depth = 0) {
+    if (depth > 3 || !fs.existsSync(dir))
+        return false;
+    let entries;
+    try {
+        entries = fs.readdirSync(dir, { withFileTypes: true });
+    }
+    catch {
+        return false;
+    }
+    for (const e of entries) {
+        if (e.isFile() && CODE_EXTS.some((x) => e.name.endsWith(x)))
+            return true;
+        if (e.isDirectory() && e.name !== 'node_modules' && !e.name.startsWith('.')) {
+            if (dirHasCode(path.join(dir, e.name), depth + 1))
+                return true;
+        }
+    }
+    return false;
+}
+/** ¿El repo git del consumidor tiene commits que tocan código? Señal del spec para
+ * brownfield SEGURO. Acotado: mira los últimos 30 commits. Sin repo git → false. */
+function hasGitCodeHistory(dir) {
+    const inRepo = spawnSync('git', ['-C', dir, 'rev-parse', '--git-dir'], { stdio: 'ignore' }).status === 0;
+    if (!inRepo)
+        return false;
+    const r = spawnSync('git', ['-C', dir, 'log', '-n', '30', '--name-only', '--pretty=format:'], { encoding: 'utf8' });
+    if (r.status !== 0 || !r.stdout)
+        return false;
+    return r.stdout.split('\n').some((f) => CODE_EXTS.some((x) => f.trim().endsWith(x)));
+}
+/**
+ * Detección greenfield/brownfield a partir de tres señales: manifiesto de paquete,
+ * presencia de código (raíz o directorios convencionales) e historial git que toca
+ * código. Brownfield CIERTO requiere las tres señales; greenfield CIERTO requiere la
+ * ausencia total de manifiesto y código. Señales mixtas (p.ej. scaffold recién creado
+ * sin historial git) devuelven null — ambiguo, lo resuelve `/build:onboard`.
+ */
+export function detectProjectKind(targetDir) {
+    let rootEntries = [];
+    try {
+        rootEntries = fs.readdirSync(targetDir);
+    }
+    catch {
+        return null;
+    }
+    const hasManifest = MANIFESTS.some((m) => fs.existsSync(path.join(targetDir, m))) ||
+        rootEntries.some((n) => n.endsWith('.csproj') || n.endsWith('.sln'));
+    const rootCode = rootEntries.some((n) => CODE_EXTS.some((x) => n.endsWith(x)));
+    const hasCode = rootCode || CODE_DIRS.some((d) => dirHasCode(path.join(targetDir, d)));
+    if (hasManifest && hasCode && hasGitCodeHistory(targetDir))
+        return 'brownfield';
+    if (!hasManifest && !hasCode)
+        return 'greenfield';
+    return null; // señales mixtas (p.ej. scaffold recién creado sin historial) → ambiguo, lo resuelve onboard
+}
+/**
+ * Estampa project_kind en build-state.json SOLO si está ausente o null (migración
+ * aditiva; nunca pisa una decisión previa auto o humana) y solo con detección no-null.
+ */
+export function stampProjectKind(targetDir) {
+    const t = targetPaths(targetDir);
+    if (!fs.existsSync(t.stateFile))
+        return null;
+    const detected = detectProjectKind(targetDir);
+    let parsed;
+    try {
+        parsed = JSON.parse(fs.readFileSync(t.stateFile, 'utf8'));
+    }
+    catch {
+        return detected;
+    }
+    // JSON.parse puede devolver con éxito algo que no es un objeto plano (null, string,
+    // número, boolean, array) si el archivo está corrupto — degradar igual que un parse fallido.
+    if (typeof parsed !== 'object' || parsed === null || Array.isArray(parsed)) {
+        return detected;
+    }
+    const st = parsed;
+    if (detected !== null && (st.project_kind === undefined || st.project_kind === null)) {
+        st.project_kind = detected;
+        st.project_kind_source = 'auto';
+        fs.writeFileSync(t.stateFile, JSON.stringify(st, null, 2) + '\n', 'utf8');
+    }
+    return st.project_kind ?? detected;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trycore/spec-build-harness",
-  "version": "0.8.2",
+  "version": "0.8.4",
   "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/scripts/tests/test-install.sh

@@ -86,4 +86,92 @@ check "hooks/build/reconcile-build-state.py"
 check "hooks/build/lib/state-io.sh"
 check "scripts/lib/front-plan.py"
 
+# project_kind: el TMP de init es un directorio vacío → greenfield detectado (auto)
+if python3 -c "
+import json,sys
+d=json.load(open('$TMP/.claude/state/build-state.json'))
+assert d.get('project_kind')=='greenfield', d.get('project_kind')
+assert d.get('project_kind_source')=='auto', d.get('project_kind_source')
+" 2>/dev/null; then
+  echo "OK install: project_kind=greenfield detectado (auto)"
+else
+  echo "FAIL install: project_kind no detectado como greenfield/auto"
+  fail=1
+fi
+
+# 5) Brownfield seguro: manifiesto + código + historial git que toca código.
+TMP_BF="$(mktemp -d)"
+echo '{}' > "$TMP_BF/package.json"
+mkdir -p "$TMP_BF/src"
+echo 'export const x = 1;' > "$TMP_BF/src/index.ts"
+(
+  cd "$TMP_BF" &&
+  git init -q &&
+  git add -A &&
+  git -c user.email=t@t -c user.name=t commit -qm x
+) >/dev/null 2>&1
+
+node "$ROOT/dist/cli.js" init "$TMP_BF" \
+  --copy \
+  --skip-doctor \
+  --yes \
+  --stack "" \
+  --pkg-manager npm \
+  --runtime ">=18.18" \
+  --prd-path "docs/01-prd/x.md#req" \
+  >"$TMP_BF/.init.log" 2>&1
+rc=$?
+if [ $rc -ne 0 ]; then
+  echo "FAIL install: \`trycore-build init\` (brownfield) salió con código $rc"
+  cat "$TMP_BF/.init.log"
+  fail=1
+fi
+
+if python3 -c "
+import json,sys
+d=json.load(open('$TMP_BF/.claude/state/build-state.json'))
+assert d.get('project_kind')=='brownfield', d.get('project_kind')
+assert d.get('project_kind_source')=='auto', d.get('project_kind_source')
+" 2>/dev/null; then
+  echo "OK install: project_kind=brownfield con historial git"
+else
+  echo "FAIL install: project_kind no detectado como brownfield con historial git"
+  fail=1
+fi
+rm -rf "$TMP_BF"
+
+# 6) Ambiguo: manifiesto + código pero SIN repo git (sin historial) → project_kind null.
+TMP_AMB="$(mktemp -d)"
+echo '{}' > "$TMP_AMB/package.json"
+mkdir -p "$TMP_AMB/src"
+echo 'export const x = 1;' > "$TMP_AMB/src/index.ts"
+
+node "$ROOT/dist/cli.js" init "$TMP_AMB" \
+  --copy \
+  --skip-doctor \
+  --yes \
+  --stack "" \
+  --pkg-manager npm \
+  --runtime ">=18.18" \
+  --prd-path "docs/01-prd/x.md#req" \
+  >"$TMP_AMB/.init.log" 2>&1
+rc=$?
+if [ $rc -ne 0 ]; then
+  echo "FAIL install: \`trycore-build init\` (ambiguo) salió con código $rc"
+  cat "$TMP_AMB/.init.log"
+  fail=1
+fi
+
+if python3 -c "
+import json,sys
+d=json.load(open('$TMP_AMB/.claude/state/build-state.json'))
+assert d.get('project_kind') is None, d.get('project_kind')
+" 2>/dev/null; then
+  echo "OK install: project_kind=null (ambiguo sin historial git)"
+else
+  echo "FAIL install: project_kind no quedó null en caso ambiguo"
+  fail=1
+fi
+rm -rf "$TMP_AMB"
+
 exit $fail

package/scripts/tests/test-schema.sh

@@ -43,8 +43,29 @@ cat > "$TMP/bad-layer.json" <<'JSON'
    "layer":"WRONG","gates":{"dor":true,"tdd":false,"dod":false},"updated_at":"2026-07-03T00:00:00Z","updated_by":"t"},
  "history":[],"releases":[]}
 JSON
+cat > "$TMP/valid-foundation.json" <<'JSON'
+{"version":"1.0","harness_phase":"authoring","scaffold":{"confirmed":false},
+ "project_kind":"greenfield","project_kind_source":"auto",
+ "foundation":{"required":true,"epic":"EP-001","completed_at":null,
+   "checklist":[{"item":"navegacion-menus","applies":true,"evidence":""},
+                {"item":"login-authn","applies":true,"evidence":"smoke login OK"}]},
+ "active_slice":null,"history":[],"releases":[]}
+JSON
+cat > "$TMP/bad-project-kind.json" <<'JSON'
+{"version":"1.0","harness_phase":"authoring","scaffold":{"confirmed":false},
+ "project_kind":"unknown","active_slice":null,"history":[],"releases":[]}
+JSON
+cat > "$TMP/bad-foundation-item.json" <<'JSON'
+{"version":"1.0","harness_phase":"authoring","scaffold":{"confirmed":false},
+ "foundation":{"required":true,"epic":null,"completed_at":null,
+   "checklist":[{"applies":true}]},
+ "active_slice":null,"history":[],"releases":[]}
+JSON
 check "estado válido con campos nuevos" pass "$TMP/valid.json"
 check "layer inválido rechazado" fail "$TMP/bad-layer.json"
+check "foundation + project_kind válidos" pass "$TMP/valid-foundation.json"
+check "project_kind inválido rechazado" fail "$TMP/bad-project-kind.json"
+check "checklist item sin 'item' rechazado" fail "$TMP/bad-foundation-item.json"
 
 CFG="$ROOT/config/build-config.template.json"
 if [ -f "$CFG" ] && python3 -c "import json,sys; d=json.load(open('$CFG'))['context']; assert d['warning_pct']==35 and d['critical_pct']==25 and d['auto_checkpoint'] is False" 2>/dev/null; then

package/skills/building-a-slice/references/dor.md

@@ -10,6 +10,16 @@ la épica; lo de abajo aplica a la épica y a **cada HU** que cubre (`hus[]`). L
 - [ ] **INVEST** por HU: pasa los 6 criterios (Independent, Negotiable, Valuable, Estimable, Small, Testable).
 - [ ] **Dependencias resueltas**: las épicas/HU de las que depende están archivadas (`history[]`) o explícitamente no bloquean. **Excepción dura — cimiento:** si la dependencia es **infraestructura fundacional** (autenticación, acceso a datos, arquitectura base, design-system/componentes base), la cláusula "explícitamente no bloquean" **NO aplica**: debe estar **construida y archivada** antes (ver criterio "Cimiento construido").
 - [ ] **Cimiento construido (épicas de negocio)**: si esta épica es `layer: business`, todo el cimiento que arrastra (auth, acceso a datos, arquitectura base, design-system/componentes base) ya existe como épica(s) `layer: foundational` **archivada(s)** en `history[]`. Si arrastra cimiento no construido → **STOP**: extráelo a una épica fundacional previa y constrúyela primero. Las épicas fundacionales se priorizan **antes** que las de negocio.
+- [ ] **Caparazón construido (solo greenfield — gate PROACTIVO)**: si `project_kind === "greenfield"`
+  y `foundation.required === true` en `build-state.json`, ninguna épica `layer: business` entra a
+  construcción mientras la épica caparazón (`foundation.epic`) no esté **archivada con su checklist
+  evidenciada** (`foundation.completed_at` estampado). Las épicas `layer: foundational` (la
+  caparazón `foundation.epic` u otras fundacionales) sí pueden abrir. A diferencia de "Cimiento
+  construido" (reactivo: bloquea si *detecta* arrastre), este criterio bloquea **siempre** en
+  greenfield hasta que el cimiento exista archivado — no depende de detectar nada. Si
+  `foundation.epic` es `null` (no existe la épica caparazón aún) → **STOP**: se define en
+  `/build:onboard` Fase 2c o en discovery. Brownfield / `foundation.required: false` → **N/A** (no
+  bloquea). Contrato: `references/foundation-contract.md`.
 - [ ] **Tamaño acotado (gate de descomposición)**: si la épica supera el umbral —heurística por defecto **> 3 HU** ó **≥ 3 capas tocadas** (configurable por proyecto)— **no entra como slice único**: se descompone en `sub_slices[]` verificables construidos de a uno, con `journey_smoke` verde entre cada uno. El umbral es proporcional (no cuota rígida): una épica de 1 capa y pocas HU entra directa.
 - [ ] **Cabe en el stack** del PRD §7 (no requiere tecnología fuera de `stack-allowlist.json`).
 - [ ] **Cobertura arquitectónica (ADR)** *(opt-in, retrocompatible)*: si el proyecto adoptó la capa de

package/skills/building-a-slice/references/foundation-contract.md

@@ -0,0 +1,44 @@
+# Contrato del caparazón (épica fundacional de app shell) — solo greenfield
+
+El **caparazón** es el shell con contenido donde aterrizan las features: navegación, layout,
+homepage, login y redirecciones. No es el *scaffold* (shell vacío que arranca — gate
+`scaffold.confirmed`) ni el *walking skeleton* (primer journey de negocio más delgado): es la
+infraestructura de UI/entrada fundacional que, si no existe primero, cada épica de negocio
+improvisa a pedazos y acumula deuda estructural.
+
+**Aplica si y solo si `project_kind === "greenfield"`.** En brownfield el mecanismo entero es
+N/A y el arnés no pregunta ni exige nada (`foundation.required: false`).
+
+## Checklist base (ids canónicos)
+
+| id | Qué cubre | Poda típica |
+|---|---|---|
+| `navegacion-menus` | Menús / estructura de navegación principal | API sin UI |
+| `layout-panel-central` | Layout base + panel/área central de contenido | API sin UI |
+| `homepage` | Página de inicio real (no placeholder del scaffold) | API sin UI |
+| `login-authn` | Login + autenticación cableada end-to-end | app pública sin cuentas |
+| `redirecciones-guards` | Redirecciones y guards de ruta (authed/anon, 404, deep-links) | API sin UI |
+
+- La **poda** se decide una vez, en `/build:onboard` Fase 2c, con el humano (ítem podado =
+  `applies: false`; queda en la checklist como decisión trazable, no se borra).
+- El proyecto puede **añadir** ítems propios (id kebab-case) si su caparazón exige más.
+
+## Ciclo de vida
+
+1. **Onboard (Fase 2c)** — se poda la checklist, se persiste en `foundation.checklist[]` y se
+   identifica (o redacta en borrador híbrido) la épica caparazón → `foundation.epic`.
+2. **DoR (gate proactivo)** — mientras la épica caparazón no esté **archivada**, ninguna épica
+   `layer: business` abre slice (solo fundacionales). Ver `dor.md`.
+3. **DoD de la épica caparazón** — cada ítem `applies: true` exige `evidence` de ejecución real
+   (test, comando, screenshot MCP), patrón `wiring_checklist`. Sin evidencia completa no se
+   archiva.
+4. **Cierre** — al archivar con la checklist evidenciada se estampa `foundation.completed_at` y
+   las épicas de negocio quedan desbloqueadas.
+
+## Reglas duras
+
+- El arnés **propone** el borrador de la épica caparazón; **solo** lo escribe en
+  `docs/03-backlog/epicas.md` con aprobación humana explícita (carve-out acotado, ver
+  METODOLOGIA §9.2). Si el humano rechaza, STOP: la épica se crea en discovery (`/trycore:*`).
+- La evidencia es de **ejecución**, nunca de inspección.
+- Si contradice `METODOLOGIA.md`, gana la metodología.

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

package/state/README.md

@@ -59,6 +59,24 @@ Espejo de `scaffold` para la UI: `applies` (¿el proyecto tiene UI?), `confirmed
 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`.
 
+### `foundation` (gate de proyecto, solo greenfield) + `project_kind`
+
+`project_kind` (`greenfield` | `brownfield` | `null`) lo detecta `trycore-build init` con
+heurística conservadora (`project_kind_source: "auto"`); ante ambigüedad queda `null` y
+`/build:onboard` pregunta una vez (`"human"`). En **brownfield el mecanismo entero es N/A**: no
+se pregunta ni se exige nada.
+
+`foundation` es el contrato de la **épica caparazón** (app shell: navegación, layout, homepage,
+login, redirecciones — ids canónicos en
+`skills/building-a-slice/references/foundation-contract.md`): `{ required, epic, completed_at,
+checklist[] }`. En greenfield, el DoR (criterio 7-bis, **proactivo**) bloquea abrir épicas
+`layer: business` hasta que la épica caparazón (`foundation.epic`) esté **archivada con su
+checklist evidenciada** (`foundation.completed_at` estampado); otras épicas fundacionales abren
+libremente pero no satisfacen este gate. El DoD de la épica caparazón exige `evidence` de
+ejecución por cada ítem `applies: true` y al archivar se estampa `completed_at`. El arnés
+**propone** el borrador de la épica y solo lo escribe con aprobación humana explícita (carve-out
+METODOLOGIA §9.2).
+
 ### gate `fidelity` (por-slice, inner loop) — ESTRICTO para UI
 
 `true` = FIEL (o desviaciones justificadas, **vía verificación visual real**); `false` = desviaciones
@@ -102,3 +120,7 @@ El razonamiento vive en el modelo; el hook solo es un recordatorio determinista.
 | `releases[]` (`security`, `smell`, `ux`, `coherence`, `stack_arch`, `integration`, `status`) | `releasing-a-version` (delega en `security-reviewer`, `simple-design-reviewer`, `ux-krug-reviewer`, `coherence-three-way`, `stack-guardian`) | release |
 | `history[].reflected` · `history[].reflected_at` | `/build:reflect` | post-slice (tras archivar) |
 | `harness_phase` | `load-build-state.sh` (SessionStart) | — |
+| `project_kind` · `project_kind_source` | `trycore-build init` (auto) · `/build:onboard` (human, solo ambiguo) | una vez |
+| `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 |

package/state/build-state.schema.json

@@ -35,7 +35,18 @@
     "parallel_front": {
       "description": "Coordinación outer-loop de worktrees inter-épica (C). null = modo secuencial normal.",
       "oneOf": [ { "type": "null" }, { "$ref": "#/$defs/parallel_front" } ]
-    }
+    },
+    "project_kind": {
+      "type": ["string", "null"],
+      "enum": ["greenfield", "brownfield", null],
+      "description": "Tipo de proyecto. brownfield = ya construido (el requisito de épica caparazón NO aplica y no se pregunta); greenfield = app nueva (activa el gate foundation); null = indeterminado (lo resuelve /build:onboard con el humano). Detección automática en trycore-build init."
+    },
+    "project_kind_source": {
+      "type": ["string", "null"],
+      "enum": ["auto", "human", null],
+      "description": "Quién fijó project_kind: auto (heurística del CLI, solo con certeza) | human (confirmado en onboard ante ambigüedad)."
+    },
+    "foundation": { "$ref": "#/$defs/foundation" }
   },
   "$defs": {
     "scaffold": {
@@ -64,6 +75,34 @@
         "notes": { "type": "string", "description": "Evidencia libre (p.ej. 'prototipo en docs/… revisado y vigente')." }
       }
     },
+    "foundation": {
+      "type": "object",
+      "additionalProperties": false,
+      "description": "Gate de PROYECTO (solo greenfield): la épica caparazón — navegación/menús, layout/panel central, homepage, login/authN, redirecciones/guards — debe construirse y archivarse ANTES que cualquier épica business. El contrato es la checklist (podada por el humano en /build:onboard según el tipo de app); cada ítem applies=true exige evidence en el DoD (patrón wiring_checklist, nada de palabra de honor). El arnés propone el borrador de la épica pero solo lo escribe con aprobación humana explícita.",
+      "required": ["required"],
+      "properties": {
+        "required": { "type": "boolean", "description": "true solo en greenfield con contrato confirmado en onboard. false = N/A (brownfield o proyecto sin caparazón exigible)." },
+        "epic": {
+          "oneOf": [ { "type": "null" }, { "type": "string", "pattern": "^EP-[0-9]{3}$" } ],
+          "description": "La épica caparazón del backlog. null mientras no exista (el gate del DoR bloquea business igual)."
+        },
+        "completed_at": { "type": ["string", "null"], "format": "date-time", "description": "Cuándo se archivó la épica caparazón con toda la checklist evidenciada. null = pendiente." },
+        "checklist": {
+          "type": "array",
+          "description": "Contrato del caparazón. Ids canónicos: navegacion-menus, layout-panel-central, homepage, login-authn, redirecciones-guards (podables; extensible por proyecto).",
+          "items": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": ["item", "applies"],
+            "properties": {
+              "item": { "type": "string", "description": "Id kebab-case del ítem del contrato." },
+              "applies": { "type": "boolean", "description": "false = podado en onboard (p.ej. homepage en una API sin UI)." },
+              "evidence": { "type": "string", "description": "Evidencia de ejecución que demuestra el ítem construido (test/comando/screenshot). Vacío mientras pendiente." }
+            }
+          }
+        }
+      }
+    },
     "slice": {
       "type": "object",
       "additionalProperties": false,

package/state/build-state.template.json

@@ -15,6 +15,14 @@
     "source": "",
     "notes": ""
   },
+  "project_kind": null,
+  "project_kind_source": null,
+  "foundation": {
+    "required": false,
+    "epic": null,
+    "completed_at": null,
+    "checklist": []
+  },
   "active_slice": null,
   "history": [],
   "releases": []

package/templates/CLAUDE.md.template

@@ -37,7 +37,7 @@ Outer loop (por release):       Release Gate (seguridad · diseño · UX · cohe
 5. **Producto completo, no MVP.** El alcance acordado se construye **entero**. **Recortar o diferir es bloqueante explícito** que requiere acuerdo del equipo — **nunca** una decisión del modelo. No se "deja para después" ni se deriva en lo complejo. La verificación es **ejecutada, no por inspección** (correr la suite, cargar la página, leer la consola).
 6. **Cierre verificado, no declarado.** `dod` exige el gate `wiring_verified`: un subagente **adversarial independiente** (`wiring-adversarial-verifier`, contexto virgen) intenta refutar el slice (stubs, rutas sin cablear, AC sin test) antes de cerrar. El estado del cableado vive en disco (`wiring_checklist[]` + `progress_log[]`) para que una sesión fresca retome sin "creer que ya está".
 7. **Fidelidad por verificación visual real.** Para slices con UI, el gate `fidelity` solo cierra observando la salida real vía MCP de devtools de navegador (screenshot app vs prototipo); sin verificación visual queda `false` (no "INCONCLUSO pasa").
-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.
+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**.
 
 ### Bloque de dominio (lo resuelve `/build:onboard`)