@trycore/spec-build-harness 0.8.3 → 0.8.5

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.3",
+  "version": "0.8.5",
   "description": "Arnés de construcción de dos loops (slice por épica + release gate) para Claude Code, con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "author": {
     "name": "Trycore",

package/GOVERNANCE.md

@@ -10,8 +10,8 @@ evoluciona con el modelo y el proyecto. No es "instalar y olvidar".
 | Estado | `build-state.json` (+schema, README) | `.claude/state/` |
 | Agentes | 14 agentes de build | `.claude/agents/build/` |
 | Hooks | settings.json + 13 scripts | `.claude/settings.json`, `.claude/hooks/build/` |
-| Skill | `building-a-slice` (+11 refs · `workflows/`) · `releasing-a-version` (`workflows/`) · `building-a-micro-change` (carril ligero de mantenimiento) · `managing-parallel-front` (front paralelo inter-épica) | `.claude/skills/` |
-| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:slice` · `/build:release` · `/build:work` · `/build:resume` · `/build:front` | `.claude/commands/` |
+| Skill | `building-a-slice` (+11 refs · `workflows/`) · `releasing-a-version` (`workflows/`) · `building-a-micro-change` (carril ligero de mantenimiento) · `managing-parallel-front` (front paralelo inter-épica) · `prototyping-screens` (prototipo HTML de referencia) | `.claude/skills/` |
+| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:prototype` · `/build:slice` · `/build:release` · `/build:work` · `/build:resume` · `/build:front` | `.claude/commands/` |
 | Config | allowlist de stack | `.claude/config/stack-allowlist.json` |
 
 ## Fases de activación (`harness_phase`)
@@ -46,6 +46,21 @@ Editar `stack-allowlist.json` SOLO si la sección de requisitos técnicos del PR
 ## Bitácora de cambios de metodología
 Cambios a la política de construcción (unidad de trabajo, gates, DoR/DoD). Aprueba el DRI; van por PR.
 
+- **2026-08-05 · v0.8.5** — **El arnés puede generar el prototipo (fuente de diseño)** (origen:
+  investigación de comunidad sobre fidelidad visual + dolor recurrente de pantallas que difieren del
+  prototipo; spec `docs/superpowers/specs/2026-08-05-prototype-generator-design.md`). **Aprobación del
+  DRI (Agent Manager) requerida en el PR.** Cambia una regla de política: "el arnés NO genera el
+  prototipo" → "**puede generarlo** vía `/build:prototype` (skill `prototyping-screens`); la
+  confirmación (`design_source.confirmed`) y la aprobación de cada pantalla (`borrador`→`aprobada`
+  en `manifest.json`) siguen siendo **exclusivamente humanas**". No cambia unidad de trabajo, gates,
+  DoR ni DoD: el gate `design_source` conserva su semántica (espejo de `scaffold`) y `fidelity`
+  sigue igual. Toca §9.2 (4º carve-out de escritura: subárbol `docs/05-prototipo/`, análogo a
+  `docs/adr/`) y §10 regla 9 (nota de producción de la fuente). Modo feature con **precondición
+  dura** (app corriendo + MCP de inspección de UI; sin degradación estática), coherente con la
+  postura estricta de `fidelity`. Artefactos nuevos: **1 comando** (`/build:prototype`, total 9
+  `/build:*`) y **1 skill** (`prototyping-screens`, total 16); sin hooks ni agentes nuevos; schema
+  sin cambio estructural (solo texto de `description`). Release **0.8.5** (version-sync ×3).
+
 - **2026-06-24 · v0.7.0** — **Workflows dinámicos en el flujo build-a-slice** (origen:
   evaluación adversarial del arnés con workflows dinámicos; 18 mejoras aprobadas contra una rúbrica de
   hardness). **Aprobado por el DRI (Agent Manager); fusionado en PR #7.** No cambia la unidad de trabajo, los gates,

package/INSTALL.md

@@ -87,8 +87,8 @@ Qué hace `init`:
 1. **Verifica requisitos duros** (a menos que uses `--skip-doctor`).
 2. **Siembra los assets** en rutas nativas de Claude Code:
    - `.claude/agents/build/` — 14 agentes.
-   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (8 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`).
-   - `.claude/skills/` — 15 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `openspec-*`).
+   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (9 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:prototype`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`).
+   - `.claude/skills/` — 16 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `prototyping-screens`, `openspec-*`).
    - `.claude/hooks/build/` — 13 hooks (bash + python).
 3. **Siembra el estado**: `state/build-state.schema.json` y `state/README.md` se versionan;
    `state/build-state.json` se siembra **vacío y nunca se sobrescribe** (va al `.gitignore`).

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,16 @@ 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 **cuatro** 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), 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 —, y el subárbol **`docs/05-prototipo/`** —propiedad de construcción— donde
+`/build:prototype` (skill `prototyping-screens`) produce el prototipo HTML de referencia (la fuente
+de diseño): las pantallas nacen `borrador` y solo pasan a `aprobada` con aprobación humana, análogo
+a `docs/adr/`. Ni `docs/adr/` ni `docs/05-prototipo/` son artefactos de discovery: son salida de
+construcción que traza *hacia* discovery (HU/PRD) sin modificarla.
 
 ### 9.3 Capa de arquitectura (ADD) — entre discovery y construcción
 
@@ -536,7 +559,9 @@ salida es file-based y la propuesta se materializa en git, mañana irá por API
    no MVP** (recortar/diferir es bloqueante explícito, nunca decisión del modelo; verificación
    ejecutada, no por inspección).
 9. **Fidelidad estricta**: para slices con UI, `fidelity` solo cierra con **verificación visual real**
-   (MCP chrome-devtools); INCONCLUSO no pasa.
+   (MCP chrome-devtools); INCONCLUSO no pasa. La fuente de diseño puede **producirse** con
+   `/build:prototype` (en modo feature exige extracción viva de la app corriendo);
+   `design_source.confirmed` sigue siendo confirmación humana, nunca del arnés.
 10. El core es **agnóstico**: lo específico del dominio se inyecta vía `/build:onboard` y
     `stack-allowlist.json`; el ejemplo de referencia vive en `docs/examples/reference/`.
 11. Si una skill, agente o reference contradice este documento, **gana la metodología**.
@@ -544,3 +569,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

@@ -142,8 +142,8 @@ trycore-spec-build-harness/
 ├── agents/build/              ← 14 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← 8 comandos /build:* (onboard, reflect, architect, slice, release, work, resume, front)
-├── skills/                    ← 15 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, setup-architecture, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
+│   └── build/                 ← 9 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front)
+├── skills/                    ← 16 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, setup-architecture, prototyping-screens, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
 ├── hooks/build/               ← 13 hooks (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, statusline-bridge, context-monitor, reconcile-build-state, …)
 ├── state/                     ← máquina de estado: build-state.json + schema + README
 ├── config/                    ← build-config.template.json (umbrales de contexto) + stack-allowlist.template.json (artefacto del consumidor)
@@ -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.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.5 (actual)** — **generador de prototipos HTML de referencia**: comando **`/build:prototype`** + skill **`prototyping-screens`** que producen la fuente de diseño (`DESIGN_SOURCE`) en `docs/05-prototipo/` (`DESIGN.md` + `tokens.css` + `manifest.json` pantalla↔épica/HU + un HTML autocontenido por pantalla). Dos modos: **greenfield** (inventario desde PRD/mapa/historias → dirección estética con 2-3 variantes a elección humana → generación por lotes) y **feature** (pantallas de una épica nueva con **extracción viva obligatoria** del UI implementado: CSS computado + screenshots en 3 viewports vía MCP; sin degradación estática). Auto-verificación visual (render real, máx. 3 iteraciones, sin pixel-diff) y **aprobación humana** de cada pantalla (`borrador`→`aprobada`); `ux-fidelity-reviewer` resuelve pantallas vía `manifest.json` (solo `aprobada`). La regla "el arnés no genera el prototipo" evoluciona a "puede generarlo; `design_source.confirmed` sigue siendo humano". 4º carve-out de escritura en `docs/` (§9.2). Total: **14 agentes**, **13 hooks**, **9 comandos `/build:*`**, **16 skills**.
+- ✅ **v0.8.4** — **é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.3
+0.8.5

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

@@ -41,12 +41,24 @@ 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).
 9. **Fuente de diseño (solo slices con UI)**: si la épica toca UI, `design_source.confirmed===true`
    (fuente visual de verdad declarada para el proyecto) y la épica apunta a la(s) pantalla(s)
-   equivalente(s) del `DESIGN_SOURCE`. Si no toca UI, este criterio es N/A.
+   equivalente(s) del `DESIGN_SOURCE`. Si la fuente es un prototipo generado (convención
+   `docs/05-prototipo/`), la(s) pantalla(s) equivalente(s) deben existir en su `manifest.json` con
+   `estado: "aprobada"` — un `borrador` **no** satisface este criterio (genera/aprueba primero con
+   `/build:prototype`). Si no toca UI, este criterio es N/A.
 10. **Cobertura arquitectónica (ADR)** — *opt-in, retrocompatible*: si el proyecto adoptó la capa de
     arquitectura (existe `docs/adr/_backlog-arquitectonico.md`, generado por `/build:architect`), los
     drivers **arquitecturalmente significativos** que la épica ejerce deben tener un ADR con estado
@@ -80,6 +92,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/agents/build/ux-fidelity-reviewer.md

@@ -20,7 +20,10 @@ igual que `ux-krug-reviewer`.
 ## Entradas (pídelas si faltan)
 - La(s) pantalla(s) del slice (rutas de la app, p.ej. `<URL-local-del-dev-server>/<ruta>`).
 - La fuente de diseño (`DESIGN_SOURCE`): archivo/URL del prototipo o export, y cómo localizar la
-  pantalla equivalente.
+  pantalla equivalente. Si apunta a un directorio de prototipo generado (convención
+  `docs/05-prototipo/`), resuelve la pantalla equivalente vía su `manifest.json` (mapa
+  pantalla↔épica/HU↔archivo) y considera **solo** las entradas `estado: "aprobada"` como fuente
+  de verdad — un `borrador` no acredita fidelidad.
 - Tokens de diseño del proyecto (los que declare el stack del PRD del consumidor: variables CSS, tema,
   design tokens), si existen.
 

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
 ```
 
 ---
@@ -65,13 +66,25 @@ Voy a leer tu PRD/openspec para proponer valores y confirmar contigo:
    - **Decisiones de alto impacto** (`HIGH_STAKES_DECISIONS`): decisiones que exigen explicabilidad/justificación en la UI.
    - **Fuente de diseño** (`DESIGN_SOURCE`): ¿el producto tiene UI? Si sí, ruta/URL de la fuente
      visual de verdad (prototipo, export de diseño o mockups) y cómo localizar cada pantalla; si no,
-     "N/A". (La escritura del estado `design_source` en `build-state.json` se hace en la Fase 3c.)
+     "N/A". Si hay UI pero **no existe** fuente aún, indica que `/build:prototype` puede generarla
+     tras el onboarding (prototipo HTML de referencia en `docs/05-prototipo/`; la confirmación
+     sigue siendo humana). (La escritura del estado `design_source` en `build-state.json` se hace
+     en la Fase 3c.)
 3. Si un punto no aplica al proyecto, registra explícitamente "no aplica" (no lo dejes como `{{...}}`).
 
 ---
 
 ## 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 +100,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 -->`.
@@ -125,7 +170,8 @@ Si el usuario lo desea y existe `package.json` en el proyecto:
 Espejo de la confirmación de scaffold, para `design_source` en `build-state.json`:
 - Si el producto **tiene UI**: setea `design_source.applies=true`, `source` (el puntero confirmado) y
   `confirmed=true` **solo si** el usuario confirma que la fuente de diseño existe (con `confirmed_by`,
-  `confirmed_at`). El arnés **no genera** el prototipo.
+  `confirmed_at`). El prototipo puede generarse con `/build:prototype` (skill `prototyping-screens`);
+  `confirmed` sigue siendo exclusivamente humano.
 - Si **no hay UI**: setea `design_source.applies=false` (el mecanismo de fidelidad queda N/A).
 
 Escribe **solo** los campos del schema (`applies`, `source`, `confirmed`, `confirmed_by`, `confirmed_at`,
@@ -162,6 +208,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/prototype.md

@@ -0,0 +1,22 @@
+---
+name: "BUILD: Prototype"
+description: Genera o amplía el prototipo HTML de referencia (la fuente de diseño / DESIGN_SOURCE) en docs/05-prototipo/. Dos modos — greenfield (prototipo inicial desde los docs de discovery + dirección estética elegida por el humano) y feature (pantallas de una épica nueva extraídas en vivo del UI ya implementado). Delega en la skill prototyping-screens. La confirmación de design_source sigue siendo humana.
+category: Workflow
+tags: [build-harness, outer-loop, prototipo, design-source, trycore]
+---
+
+# /build:prototype — Prototipo HTML de referencia
+
+Delega en la skill **prototyping-screens**. Uso:
+
+- `/build:prototype` — modo **greenfield** (o detección automática): prototipo inicial completo.
+  Inventario de pantallas desde PRD/mapa/historias → confirmación humana → dirección estética
+  (manual de marca o 2-3 variantes a elección humana) → generación por lotes con auto-verificación.
+- `/build:prototype <épica>` — modo **feature**: pantallas nuevas de esa épica, coherentes con el
+  UX/UI ya implementado. **Precondición dura**: app corriendo + MCP de inspección de UI (p.ej.
+  chrome-devtools); sin ellos hace STOP (la extracción viva de CSS computado no se degrada).
+
+Es **outer-loop**: córrelo antes de abrir slices (como `/build:architect`). Produce
+`docs/05-prototipo/` (DESIGN.md, tokens.css, manifest.json, pantallas/) y, en greenfield con
+aprobación humana, registra `design_source` en `build-state.json`. **La skill genera; el humano
+aprueba**: `design_source.confirmed` y el `estado: "aprobada"` del manifest nunca se auto-marcan.

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/docs/commands.md

@@ -3,7 +3,7 @@
 Esta referencia cubre los **dos planos de operación** del arnés de construcción:
 
 1. El **CLI `trycore-build`** (binario Node, paquete `@trycore/spec-build-harness` v0.7.0) — instala, actualiza, diagnostica y desinstala el arnés en el proyecto consumidor. Captura el **stack mecánico**.
-2. Los **slash commands de Claude Code** (`/opsx:*` + los 8 `/build:*`: `onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`) — operan el pipeline de dos loops, resuelven la parametrización **semántica** del dominio y capturan el conocimiento aprendido por slice.
+2. Los **slash commands de Claude Code** (`/opsx:*` + los 9 `/build:*`: `onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`) — operan el pipeline de dos loops, resuelven la parametrización **semántica** del dominio y capturan el conocimiento aprendido por slice.
 
 > **División de responsabilidades del onboarding (dos capas).** Un binario Node **no puede** escribir la auto-memory de Claude. Por eso `trycore-build init` siembra archivos y captura el stack mecánico (lenguaje/deps, package manager, runtime, ruta del PRD), y el slash command `/build:onboard` —ejecutado por Claude— lee el PRD, pregunta por PII / capa de servicios externos-IA / capa determinista / secretos / decisiones de alto impacto, resuelve los `{{placeholders}}` del bloque marcado de `CLAUDE.md` y escribe la auto-memory.
 
@@ -52,7 +52,7 @@ Solo `init` y `update` aceptan flags. `status`, `uninstall` y `doctor` toman ún
 
 ## 2. Slash commands de Claude Code
 
-El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y `.claude/commands/build/` → los 8 `/build:*` (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`).
+El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y `.claude/commands/build/` → los 9 `/build:*` (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`).
 
 ### `/opsx:*` — pipeline OpenSpec
 
@@ -117,6 +117,12 @@ El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y
 |---|---|
 | `/build:front` | Abre y coordina un **front paralelo** de épicas NO fundacionales y disjuntas en archivos, cada una en su propio worktree/rama/PR. Delega en la skill `managing-parallel-front`: verifica precondiciones (scaffold confirmado, sin épica foundational abierta), selecciona el conjunto disjunto (`scripts/lib/front-plan.py`) y mergea en orden con re-smoke. Úsalo solo con ≥2 épicas no fundacionales disjuntas listas; para una sola épica, usa `/build:slice`. |
 
+### `/build:prototype` — prototipo HTML de referencia (fuente de diseño)
+
+| Slash command | Propósito |
+|---|---|
+| `/build:prototype` | Genera o amplía el **prototipo HTML de referencia** (el `DESIGN_SOURCE`) en `docs/05-prototipo/` (`DESIGN.md` + `tokens.css` + `manifest.json` + un HTML autocontenido por pantalla). Adaptador delgado: **delega** en la skill `prototyping-screens`. Dos modos — **greenfield** (`/build:prototype`): inventario de pantallas desde PRD/mapa/historias → confirmación humana → dirección estética (manual de marca o 2-3 variantes a elección humana) → generación por lotes con auto-verificación visual; **feature** (`/build:prototype <épica>`): pantallas nuevas coherentes con el UX/UI **ya implementado**, con **precondición dura** (app corriendo + MCP de inspección de UI: extrae CSS computado real, screenshots en 3 viewports y estructura; sin degradación estática). Es **outer-loop** (antes de abrir slices). **La skill genera; el humano aprueba**: las pantallas nacen `borrador`, solo las `aprobada` son fuente de verdad (las lee `ux-fidelity-reviewer` vía `manifest.json`) y `design_source.confirmed` sigue siendo humano. |
+
 ---
 
 ## 3. Caveat de canales (CLI vs. plugin)
@@ -126,7 +132,7 @@ El arnés se distribuye por **dos canales** que coexisten, pero **namespacean di
 | Aspecto | Canal **CLI** (canónico) | Canal **Plugin** nativo |
 |---|---|---|
 | Instalación | `npm i -g @trycore/spec-build-harness` → `trycore-build init` | `/plugin marketplace add <repo-github>` → `/plugin install trycore-spec-build-harness@trycore-build` |
-| Namespace de comandos | Por subcarpeta: `/opsx:*` y los 8 `/build:*` (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`) | Por nombre del plugin: `/trycore-spec-build-harness:*` (por diseño de Claude Code) |
+| Namespace de comandos | Por subcarpeta: `/opsx:*` y los 9 `/build:*` (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`) | Por nombre del plugin: `/trycore-spec-build-harness:*` (por diseño de Claude Code) |
 | Referencia a agentes | Por su nombre (p. ej. `build-orchestrator`) | Bajo el nombre del plugin |
 | Cross-references internas | ✔ Escritas para este canal (skills invocan `/opsx:*`, agentes por nombre) | Pueden no resolver según están escritas |
 | Recomendación | **Usar este canal para operar un proyecto** | Conveniencia a nivel usuario |

package/docs/getting-started.md

@@ -48,7 +48,7 @@ npm i -g @fission-ai/openspec @trycore/spec-build-harness
 
 ## 2 · `trycore-build init` (terminal)
 
-Desde la raíz de tu proyecto. Es **idempotente** (re-correrlo es seguro) y siembra: **14 agentes**, **15 skills** (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture` + 10 `openspec-*`), **10 comandos `/opsx:*`** + **8 comandos `/build:*`** (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`), **13 hooks**, el estado vacío `.claude/state/build-state.json` (gitignored, nunca se sobreescribe) y el bloque `<!-- BEGIN trycore-build-harness -->` en tu `CLAUDE.md` con `{{placeholders}}` sin resolver.
+Desde la raíz de tu proyecto. Es **idempotente** (re-correrlo es seguro) y siembra: **14 agentes**, **16 skills** (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `prototyping-screens` + 10 `openspec-*`), **10 comandos `/opsx:*`** + **9 comandos `/build:*`** (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front`), **13 hooks**, el estado vacío `.claude/state/build-state.json` (gitignored, nunca se sobreescribe) y el bloque `<!-- BEGIN trycore-build-harness -->` en tu `CLAUDE.md` con `{{placeholders}}` sin resolver.
 
 ```bash
 trycore-build init