@trycore/spec-build-harness 0.12.0 → 0.14.0

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

@@ -11,15 +11,27 @@ la épica; lo de abajo aplica a la épica y a **cada HU** que cubre (`hus[]`). L
 - [ ] **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 los hechos de proyecto del runtime (`slice-ops.sh status`; en modo legacy, `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`.
+  y la caparazón está **requerida**, ninguna épica `layer: business` entra a construcción mientras
+  la caparazón no esté **construida y archivada con su checklist evidenciada**. Las épicas
+  `layer: foundational` (la caparazón 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.
+  **Dónde se leen esos hechos depende del modo**, y no son los mismos:
+  - **`legacy`/`dual`** — `build-state.json`: `foundation.required`, `foundation.epic` (el
+    `EP-XXX` concreto) y `foundation.completed_at`. Si `foundation.epic` es `null` → **STOP**: la
+    épica caparazón no existe aún; se define en `/build:onboard` Fase 2c o en discovery.
+  - **`runtime`** — la proyección solo trae `foundation_done` (booleano), vía
+    `slice-ops.sh status` (línea `hechos:`). **Nadie fija `foundation.epic` en este modo**: la
+    Fase 2c propone la épica al hub sin código y la identidad la asigna el hub al aprobar
+    (issue #62). Así que aquí **no preguntes por `foundation.epic`** — no existe. Con
+    `foundation_done: false`, el estado real de la caparazón lo dice `slice-ops.sh epic-status`
+    (o `/build:epic --check`): si hay una propuesta `PROPOSED`, el STOP es **esperar la
+    aprobación**, no re-onboardear (repetir la Fase 2c propondría la misma épica dos veces); si
+    no hay ninguna propuesta, entonces sí → Fase 2c o discovery.
+
+  Brownfield o caparazón no requerida (`foundation.required: false` en `legacy`/`dual`;
+  `foundation_done: true` en `runtime`) → **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

@@ -40,5 +40,9 @@ N/A y el arnés no pregunta ni exige nada (`foundation.required: false`).
 - 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:*`).
+  En modo `runtime`, esa aprobación humana en `/build:onboard` **propone al hub**
+  (`slice-ops.sh propose-epic`), no escribe: el fichero se escribe después, cuando el hub
+  también aprueba y asigna el `EP-XXX`, vía `/build:epic --check` (issue #62). En `legacy`/`dual`
+  la aprobación humana escribe directo, como arriba.
 - La evidencia es de **ejecución**, nunca de inspección.
 - Si contradice `METODOLOGIA.md`, gana la metodología.

package/state/README.md

@@ -141,3 +141,15 @@ El razonamiento vive en el modelo; el hook solo es un recordatorio determinista.
 | `foundation.checklist[].evidence` | `build-orchestrator` (durante la construcción de la caparazón) | al construir la caparazón |
 | `foundation.completed_at` | `dor-dod-gatekeeper` (al cerrar el DoD de la épica caparazón) | al archivar la caparazón |
 | `design_source` (`source`, `confirmed`, `confirmed_by/at`, `notes`) | `building-a-slice` Fase 0-bis · `/build:onboard` Fase 3c · `prototyping-screens` (greenfield, solo tras aprobación humana de ≥1 pantalla; `confirmed` humano siempre) | una vez (proyecto) |
+
+### Ficheros de estado aparte (no viven en `build-state.json`)
+
+La tabla de arriba describe **campos** de `build-state.json`. Estos son **ficheros propios** de
+`.claude/state/`: estado derivado del hub que solo existe en modo `runtime`, no forma parte de la
+máquina del pipeline y por eso no entra en el schema del estado. `trycore-build init` los siembra
+en `.gitignore`.
+
+| Fichero | Lo escribe | Cadencia |
+|---|---|---|
+| `epic-proposals.json` — ledger de propuestas de épica (`client_event_id`, `proposal_id`, `status`, `epic_code`, `draft`, `written_back_at`) | `slice-ops.sh propose-epic` / `epic-status` / `epic-writeback` | por propuesta de épica |
+| `graph-status.json` — marcador de desfase de grafo (`local`, `server`, `seen_at`): lo deja un `409 stale_graph` del hub y **su existencia es la señal** (el fichero se borra en cuanto la acción vuelve a pasar). Es lo que hace **visible** el desfase en `slice-ops.sh status` y `trycore-build status`; sin él el 409 se resolvería solo y nadie sabría que ocurrió. `local: null` = la petición salió sin versión estampada — nunca `0`, que sería una versión real | `runtime_graph_note_stale` / `runtime_graph_clear_stale` (`hooks/build/lib/runtime-client.sh`), desde `slice-ops.sh claim` y desde el despacho del carril directo | por rechazo `409 stale_graph` |