@trycore/spec-build-harness 0.7.0 → 0.8.0

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.7.0",
+  "version": "0.8.0",
   "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

@@ -9,9 +9,9 @@ evoluciona con el modelo y el proyecto. No es "instalar y olvidar".
 | Contexto | sección Construcción de CLAUDE.md, `openspec/project.md` | raíz / `openspec/` |
 | Estado | `build-state.json` (+schema, README) | `.claude/state/` |
 | Agentes | 12 agentes de build | `.claude/agents/build/` |
-| Hooks | settings.json + 10 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) | `.claude/skills/` |
-| Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:slice` · `/build:release` · `/build:work` | `.claude/commands/` |
+| 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/` |
 | Config | allowlist de stack | `.claude/config/stack-allowlist.json` |
 
 ## Fases de activación (`harness_phase`)

package/INSTALL.md

@@ -11,7 +11,7 @@ Es el **compañero** de [`@trycore/spec-product-flow`](https://www.npmjs.com/pac
 | CLI (bin) | `trycore-build` |
 | Plugin | `trycore-spec-build-harness` |
 | Marketplace | `trycore-build` |
-| Versión | `0.5.0` |
+| Versión | `0.7.0` |
 
 > **¿Solo quieres empezar ya?** El [Quickstart](docs/getting-started.md) te lleva de 0 a tu primer slice en pocos comandos. Esta guía es la **referencia detallada** (flags, CI, plugin, troubleshooting).
 
@@ -30,7 +30,7 @@ npm install -g @trycore/spec-build-harness
 Esto expone el binario `trycore-build`. Comprueba la versión:
 
 ```bash
-trycore-build --version    # → 0.5.0
+trycore-build --version    # → 0.7.0
 trycore-build --help
 ```
 
@@ -87,9 +87,9 @@ 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/` — 12 agentes.
-   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (`/build:onboard`, `/build:reflect`).
-   - `.claude/skills/` — 12 skills (`building-a-slice`, `releasing-a-version`, `openspec-*`).
-   - `.claude/hooks/build/` — 9 hooks bash.
+   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (5 comandos: `/build:onboard`, `/build:reflect`, `/build:slice`, `/build:release`, `/build:work`).
+   - `.claude/skills/` — 13 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `openspec-*`).
+   - `.claude/hooks/build/` — 10 hooks bash.
 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`).
 4. **Siembra `config/stack-allowlist.json`** (artefacto del consumidor; lo puebla `/build:onboard`).
@@ -205,7 +205,7 @@ Como conveniencia a nivel usuario, el arnés también se instala como **plugin n
 ### ⚠ Caveat de canales (importante)
 
 - El **canal npm CLI es el CANÓNICO**. `trycore-build init` instala los comandos en
-  `.claude/commands/{opsx,build}/`, que namespacean **por subcarpeta** → `/opsx:*` y `/build:onboard`,
+  `.claude/commands/{opsx,build}/`, que namespacean **por subcarpeta** → `/opsx:*` y `/build:*`,
   y los agentes se referencian por su **nombre** (`security-reviewer`, `stack-guardian`, …).
 - El **canal plugin nativo** namespacea **todos** los componentes bajo el **nombre del plugin**
   (→ `/trycore-spec-build-harness:*`), por diseño de Claude Code.
@@ -235,7 +235,7 @@ Ambos paquetes coexisten en el mismo `.claude/` **sin colisión**, porque usan *
 
 | | Discovery — `spec-product-flow` | Construcción — `spec-build-harness` |
 |---|---|---|
-| Comandos | `/trycore:*` | `/opsx:*` + `/build:onboard` + `/build:reflect` |
+| Comandos | `/trycore:*` | `/opsx:*` + `/build:*` (`onboard`, `reflect`, `slice`, `release`, `work`) |
 | Marca de versión | `.trycore-version` | `.build-harness-version` |
 | Bloque en `CLAUDE.md` | `<!-- BEGIN trycore-vertical -->` | `<!-- BEGIN trycore-build-harness -->` |
 

package/METODOLOGIA.md

@@ -282,6 +282,43 @@ paralelo** y devuelven síntesis (protegen el contexto). Resultado en `releases[
 
 ---
 
+## 5-bis. Front paralelo inter-épica (outer-loop, opcional)
+
+El inner loop (§3) construye **una épica a la vez, secuencial**. Cuando hay **≥ 2 épicas
+`layer: business` listas** (DoR pasado) y **disjuntas en archivos**, el arnés permite construirlas
+**en paralelo** sin romper la regla de un slice activo por árbol: el comando `/build:front`
+(skill `managing-parallel-front`) abre un **`git worktree` por épica** —cada worktree con su propio
+`active_slice` singular y su propio `build-state.json`; el inner loop **no cambia** dentro de cada
+worktree— y coordina la selección, la construcción y el merge desde el estado raíz
+(`parallel_front`). Es un concepto de **outer-loop**: no es una fase nueva del pipeline por-épica, es
+orquestación **entre** épicas.
+
+**Compuertas del front:**
+
+1. **Foundational-first (G1).** Ninguna épica `layer: foundational` entra jamás al front: el
+   cimiento se construye secuencial, antes que el negocio (§1-bis.2, §3.1). Solo épicas
+   `layer: business` son candidatas a paralelizarse.
+2. **Disjunción por `files_scope` (G2).** `scripts/lib/front-plan.py` calcula, a partir de los globs
+   declarados en `files_scope` de cada épica candidata, qué subconjunto es mutuamente disjunto
+   (`selected`, va al front) y cuál se solapa (`serialized`, espera y se construye después,
+   secuencial). Sin `files_scope` declarado, una épica no es candidata al front.
+3. **Merge en orden + re-smoke (G3).** El merge de los worktrees sigue un `merge_order`
+   determinista; tras **cada** merge se re-corre el `journey_smoke` completo sobre el árbol
+   principal (no basta con el smoke local del worktree). Un solape no capturado por la disjunción
+   declarada que produzca conflicto de merge lo caza este re-smoke: la épica perdedora se
+   **serializa** (rebase + re-correr sus gates), nunca se fuerza el merge ni se aborta el front
+   entero.
+
+**Regla de drenado (drain).** Si mientras el front está activo (`parallel_front.status: "open"`)
+aparece o se vuelve elegible una épica `layer: foundational`, el front **deja de admitir épicas
+nuevas** y pasa a `parallel_front.status: "draining"`: los worktrees en curso terminan y mergean
+normalmente, pero no se abren worktrees adicionales. Solo cuando todos los miembros llegan a
+`merge_status: "merged"` (`parallel_front` se limpia a `null`) puede abrirse la épica fundacional
+pendiente. El drenado existe porque **fundacional siempre precede a negocio** (§1-bis.2): el front
+nunca puede ser la razón por la que el cimiento se retrasa.
+
+---
+
 ## 6. Contrato de trazabilidad change ↔ épica
 
 Cada OpenSpec change corresponde a **exactamente una épica** (la unidad de construcción) y declara
@@ -349,6 +386,9 @@ agente lo lee antes de actuar. Estructura: `version`, `harness_phase`, `active_s
 | `gates.data` | `data-consistency-checker` | slice |
 | `gates.wiring_verified` | `wiring-adversarial-verifier` (independiente, contexto virgen) | slice (antes de `dod`) |
 | `releases[]` (security, smell, ux, coherence, stack_arch, integration, status) | `releasing-a-version` (delega en los reviewers) | release |
+| `parallel_front` (status, members[], merge_order) | skill `managing-parallel-front` (vía `/build:front`) | front (outer-loop, opcional) |
+| `active_slice.session_continuity` | `context-monitor.sh` (auto-handoff) / `/build:resume` | por sesión (critical/PreCompact) |
+| `active_slice.branch_drift`, degradación de `wiring_checklist` sin evidencia | `reconcile-build-state.py` (SessionStart / `/build:resume`) | por sesión |
 | `harness_phase` | `load-build-state.sh` (SessionStart) | — |
 
 **Régimen de fases (`harness_phase`):** arranca en `authoring`; `load-build-state.sh` lo cambia a
@@ -457,3 +497,7 @@ El arnés **no escribe** en `docs/`; cuando una HU no cumple DoR, devuelve el tr
 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**.
+12. **Front paralelo es outer-loop y drena ante fundacional (§5-bis)**: solo épicas `layer: business`
+    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.

package/README.md

@@ -73,8 +73,64 @@ Gate de release que corre **una sola vez por versión** sobre el conjunto de sli
 |---|---|
 | `/build:onboard` | Onboarding capa 2: lee el PRD, pregunta por PII/IA/determinismo/secretos, resuelve `{{placeholders}}` y escribe la auto-memory. |
 | `/build:reflect` | Reflexión post-slice: tras archivar, propone convenciones aprendidas / errores recurrentes al bloque `trycore-build-learnings` de `CLAUDE.md` (tras tu aprobación) y marca el slice como reflexionado. |
+| `/build:slice` | Entrada del **inner loop**: abre o continúa un slice (épica `EP-XXX`) y conduce el pipeline DoR → change → TDD → smoke → api/data → DoD → PR+archive. Adaptador delgado que delega en la skill `building-a-slice`. |
+| `/build:release` | Entrada del **outer loop**: corre el Release Gate **una sola vez** sobre el diff acumulado (los 5 reviewers pesados en paralelo + integración secuencial). Delega en la skill `releasing-a-version`. |
+| `/build:work` | Router *classify-and-act*: clasifica el trabajo entrante y enruta al carril correcto (`building-a-micro-change` · `building-a-slice` · `releasing-a-version`). Es ruteo, no política: no ejecuta el pipeline ni toca el estado. |
+| `/build:resume` | Rehidrata el slice activo **desde disco** (no desde la conversación) tras un reinicio de contexto: reconcilia el estado, lee `session_continuity`/`wiring_checklist`/`parallel_front` y determina la siguiente acción por prioridad. |
+| `/build:front` | Abre y coordina un **front paralelo** de épicas no fundacionales y disjuntas en archivos (`parallel_front`), cada una en su worktree/rama/PR. Delega en la skill `managing-parallel-front`. |
 | `/opsx:*` (10) | Ciclo OpenSpec: `explore` · `new` · `continue` · `apply` · `verify` · `archive` · `bulk-archive` · `ff` · `onboard` · `sync`. Detalle → [`docs/commands.md`](docs/commands.md). |
 
+## Gestión de contexto
+
+Las sesiones largas (una épica multicapa, un slice que se alarga) pueden agotar la ventana de
+contexto antes de terminar el cableado. El arnés lo mitiga con un **motor de contexto** que corre
+solo, sin que el humano lo invoque:
+
+- **Aviso por umbrales.** El hook `context-monitor.sh` lee el contexto restante en cada
+  `PostToolUse`/`PreCompact`/`Stop` y lo compara contra dos umbrales **configurables**
+  (`context.warning_pct: 35`, `context.critical_pct: 25` en `build-config.json`): por debajo del
+  umbral de aviso, inyecta un recordatorio de acercarse a un punto de corte natural; por debajo del
+  crítico (o en `PreCompact`), dispara un **auto-handoff** —una sola vez por sesión— que escribe en
+  `active_slice.session_continuity` un `resume_hint` derivado de los items `wiring_checklist` aún
+  `failing`, sin esperar a que el humano lo pida.
+- **`/build:resume`.** Para retomar sin pérdida: reconcilia el estado contra disco y determina la
+  siguiente acción por prioridad (`resume_hint` → primer item `failing` → siguiente `sub_slice` →
+  fase del pipeline). Reconstruye el contexto **desde el estado**, nunca desde la conversación viva.
+- **`config context.auto_checkpoint`** (opt-in, default `false`): si se activa, el handoff marca
+  `auto_continue: true` para que la siguiente sesión retome automáticamente el `resume_hint` sin
+  preguntar. Apagado por defecto porque el checkpoint automático es una decisión que el equipo debe
+  optar explícitamente a tomar.
+- **Caveat de canal.** El aviso proactivo depende de `statusLine`, un ajuste de `settings.json` que
+  **solo existe en el canal CLI** (`trycore-build init`/`update`). En una instalación **plugin-only**
+  no hay puente de contexto que leer y el motor **degrada fail-open**: no rompe nada, simplemente no
+  avisa; `/build:resume` y el reconciliador de disco (ver abajo) siguen funcionando igual porque no
+  dependen del puente.
+
+El **estado sigue anclado a disco** entre sesiones: `reconcile-build-state.py` corre en cada
+`SessionStart` (y en `/build:resume`) y deriva la verdad desde git y la evidencia de tests —degrada a
+`failing` cualquier item `wiring_checklist` marcado `passing` sin `evidence`, anota *branch drift* si
+la rama real difiere de la del slice, y nunca revierte un gate booleano por sí mismo (ratchet)—.
+Fail-open siempre: un estado ilegible o `git` ausente no bloquean la sesión.
+
+## Front paralelo
+
+Cuando hay **≥ 2 épicas de negocio (`layer: business`)** listas (DoR pasado) y **disjuntas en
+archivos**, el comando **`/build:front`** (skill `managing-parallel-front`) las construye en
+paralelo, cada una en su propio `git worktree`/rama/PR — el inner loop no cambia: cada worktree
+mantiene su `active_slice` singular y su propio `build-state.json`. Tres compuertas gobiernan el
+front:
+
+1. **Foundational-first.** Ninguna épica `layer: foundational` entra jamás al front; si una aparece
+   mientras el front está activo, el front pasa a `status: "draining"` (termina lo que ya empezó, no
+   admite épicas nuevas) hasta vaciarse.
+2. **Disjunción por `files_scope`.** `scripts/lib/front-plan.py` calcula, por conjuntos de globs
+   declarados en cada épica, qué candidatas son mutuamente disjuntas (`selected`) y cuáles deben
+   esperar (`serialized`) por solaparse.
+3. **Merge en orden + re-smoke.** El merge de los worktrees sigue un `merge_order` determinista; tras
+   cada merge se re-corre el `journey_smoke` completo en el árbol principal. Un conflicto no
+   detectado por la disjunción declarada lo caza el re-smoke: la épica perdedora se serializa
+   (rebase + re-correr sus gates) en vez de abortar el front.
+
 ## Arquitectura
 
 ```
@@ -85,11 +141,11 @@ trycore-spec-build-harness/
 ├── agents/build/              ← 12 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← /build:onboard, /build:reflect
-├── skills/                    ← 12 skills (building-a-slice, releasing-a-version, 10 openspec-*)
-├── hooks/build/               ← 9 hooks bash (gate-check, reflect-nudge, scaffold-guard, gitflow-guard, stack-guard, …)
+│   └── build/                 ← 7 comandos /build:* (onboard, reflect, slice, release, work, resume, front)
+├── skills/                    ← 14 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, 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/                    ← stack-allowlist.template.json (artefacto del consumidor)
+├── config/                    ← build-config.template.json (umbrales de contexto) + stack-allowlist.template.json (artefacto del consumidor)
 ├── src/ + dist/               ← CLI trycore-build (init/update/status/uninstall/doctor)
 ├── scripts/                   ← installer + guardias (check-version-sync/agnostic/state-clean)
 └── docs/examples/reference/   ← ejemplo de referencia (fuera del core, excluido de check-agnostic)
@@ -122,7 +178,9 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **v0.3.0** — **ciclo autocorrectivo** (hook `reflect-nudge.sh` + comando `/build:reflect`: propone convenciones aprendidas al bloque `trycore-build-learnings` de `CLAUDE.md` tras tu aprobación; campos `reflected`/`reflected_at`) y **LSP opt-in** (`docs/customization/lsp-extensions.md` + sugerencia en `doctor` para stacks tipados). Total: **8 hooks**; comandos `/opsx:*` + `/build:onboard` + `/build:reflect`.
 - ✅ **v0.4.0** — carril `building-a-micro-change` (mantenimiento ligero sin slice) + DoR proporcional a la complejidad.
 - ✅ **v0.5.0** — seguro de fuente de diseño (`design_source` + `design-source-guard.sh`) + agente `ux-fidelity-reviewer` (gate `fidelity`, inner loop). Total: **11 agentes**, **9 hooks**.
-- ✅ **v0.6.0 (actual)** — **calidad de cierre contra horizonte largo** (feedback exodocs): handoff fino en disco (`wiring_checklist[]` + `progress_log[]` + `sub_slices[]`), gate `wiring_verified` por nuevo agente **`wiring-adversarial-verifier`** (verificación adversarial independiente, contexto virgen), cimiento pre-construido + tag `layer` y gate de tamaño en el DoR, runner fuera-de-chat `integration-check`, y **fidelidad estricta por verificación visual real** (MCP requerido para UI). Convenciones anti-deriva (producto completo, no MVP) upstreadas al bloque del arnés. Total: **12 agentes**, **9 hooks**.
+- ✅ **v0.6.0** — **calidad de cierre contra horizonte largo** (feedback exodocs): handoff fino en disco (`wiring_checklist[]` + `progress_log[]` + `sub_slices[]`), gate `wiring_verified` por nuevo agente **`wiring-adversarial-verifier`** (verificación adversarial independiente, contexto virgen), cimiento pre-construido + tag `layer` y gate de tamaño en el DoR, runner fuera-de-chat `integration-check`, y **fidelidad estricta por verificación visual real** (MCP requerido para UI). Convenciones anti-deriva (producto completo, no MVP) upstreadas al bloque del arnés. Total: **12 agentes**, **9 hooks**.
+- ✅ **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 (actual)** — **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**.
 
 ## Licencia
 

package/VERSION

@@ -1 +1 @@
-0.7.0
+0.8.0

package/agents/build/build-orchestrator.md

@@ -14,6 +14,12 @@ Protocolo en `.claude/state/README.md`. **Sólo un slice activo a la vez** (mode
 La **unidad de construcción es la épica** (`active_slice.epica`); las HU que cubre el change van en
 `active_slice.hus[]`. Un slice = una épica = un change = una rama = un PR.
 
+## Coexistencia con el front paralelo (outer-loop)
+Si `parallel_front` existe en el estado principal, el paralelismo lo gobierna la skill
+`managing-parallel-front`; cada worktree corre su propio inner loop con `active_slice` singular.
+**Regla de drenado:** si se necesita abrir una épica `layer=foundational`, primero pon
+`parallel_front.status="draining"` (termina las en curso, no admite nuevas) y espera a cerrarlo.
+
 ## Trabajo por fases encadenadas (NO one-shot)
 Una épica multicapa es demasiado para una pasada. Trabaja por **fases encadenadas** —**mapear →
 generar → revisar → fix-loop → optimizar**— nunca todo de golpe. Reparte la **exploración** "ancho

package/commands/build/front.md

@@ -0,0 +1,15 @@
+---
+name: "BUILD: Front"
+description: Abre y coordina un front paralelo de épicas NO fundacionales y disjuntas en archivos, cada una en su worktree/rama/PR. Delega en la skill managing-parallel-front (selección disjunta vía scripts/lib/front-plan.py, worktrees, merge en orden con re-smoke).
+category: Workflow
+tags: [build-harness, outer-loop, front-paralelo, trycore]
+---
+
+# /build:front — Front paralelo inter-épica
+
+Delega en la skill **managing-parallel-front**. Resumen:
+1. Verifica precondiciones (scaffold confirmado; sin épica foundational abierta).
+2. Reúne candidatas no fundacionales listas (DoR pasado) con `layer` y `files_scope`.
+3. Selecciona el conjunto disjunto (`scripts/lib/front-plan.py`), abre worktrees, construye y mergea en orden con re-smoke.
+
+Úsalo solo cuando haya ≥2 épicas no fundacionales disjuntas listas. Para una sola épica, usa `/build:slice`.

package/commands/build/resume.md

@@ -0,0 +1,29 @@
+---
+name: "BUILD: Resume"
+description: Rehidrata el slice activo desde disco tras un reinicio de contexto (reconcilia estado, muestra continuidad y la siguiente acción).
+category: Workflow
+tags: [build-harness, resume, rehydrate, trycore]
+---
+
+# /build:resume — Retomar sin pérdida
+
+Objetivo: reconstruir el contexto de construcción **desde disco**, no desde la conversación.
+
+## Pasos
+
+1. **Reconciliar**: `python3 .claude/hooks/build/reconcile-build-state.py .claude/state/build-state.json`
+   (degrada wiring sin evidencia; anota branch drift; fail-open).
+
+2. **Leer estado**: `.claude/state/build-state.json`. Extraer `active_slice`, sus `gates`, `wiring_checklist`, `progress_log`, `session_continuity`, y `parallel_front` si existe.
+
+3. **Determinar la siguiente acción por prioridad** (la primera que aplique):
+   1. `session_continuity.resume_hint` presente → ejecutarla.
+   2. Items de `wiring_checklist` en `failing` → cablear el primero (con prueba real; no marcar passing sin evidencia).
+   3. `sub_slices` con `status!=done` → construir el siguiente.
+   4. Según `active_slice.phase` → continuar el pipeline (delegar en la skill `building-a-slice`).
+
+4. **Si hay `parallel_front`**: delegar en la skill `managing-parallel-front` (Task 12+).
+
+5. Registrar un hito en `progress_log[]` (`by: /build:resume`).
+
+**Regla dura:** mientras quede un item `failing`, el slice NO está terminado. Nunca marques `passing` sin evidencia de ejecución real.

package/config/build-config.template.json

@@ -0,0 +1,8 @@
+{
+  "context": {
+    "warning_pct": 35,
+    "critical_pct": 25,
+    "auto_checkpoint": false,
+    "stale_seconds": 60
+  }
+}

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 } from '../lib/state-seed.js';
+import { seedState, seedConfig, seedBuildConfig } 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';
@@ -45,9 +45,16 @@ export async function init(opts) {
     linkChildren(ASSETS.commandsOpsx, t.commandsOpsx, linkMode, (n) => n.endsWith('.md'));
     linkChildren(ASSETS.commandsBuild, t.commandsBuild, linkMode, (n) => n.endsWith('.md'));
     const nSkills = linkChildren(ASSETS.skills, t.skillsDir, linkMode);
-    linkChildren(ASSETS.hooksBuild, t.hooksBuild, linkMode, (n) => n.endsWith('.sh'));
-    if (linkMode === 'copy')
-        chmodExec(t.hooksBuild); // preserva +x [H1]
+    // hooks/build: acepta .sh Y .py en el nivel raíz (reconcile-build-state.py es un hook v0.8).
+    linkChildren(ASSETS.hooksBuild, t.hooksBuild, linkMode, (n) => n.endsWith('.sh') || n.endsWith('.py'));
+    // hooks/build/lib: subcarpeta NO recorrida por el linkChildren de arriba — hay que recursar a mano.
+    linkChildren(ASSETS.hooksBuildLib, t.hooksBuildLib, linkMode, (n) => n.endsWith('.sh'));
+    // scripts/lib: asset nuevo consumido por /build:front (front-plan.py).
+    linkChildren(ASSETS.scriptsLib, t.scriptsLib, linkMode, (n) => n.endsWith('.py'));
+    if (linkMode === 'copy') {
+        chmodExec(t.hooksBuild); // preserva +x [H1] (recorre hooks/build/ incl. lib/)
+        chmodExec(t.scriptsLib);
+    }
     // 2) Estado (schema/README versionados; build-state.json vacío solo si falta) [C1]
     const { stateSeeded } = seedState(targetDir);
     // 3) stack-allowlist.json del consumidor (artefacto del consumidor)
@@ -60,6 +67,7 @@ export async function init(opts) {
         }
     }
     const { configSeeded } = seedConfig(targetDir, allowlist);
+    const { buildConfigSeeded } = seedBuildConfig(targetDir);
     // 4) Hooks + permisos mínimos en settings.json (canal CLI) [H3,H11]
     const { addedHooks, addedPerms } = mergeHarnessSettings(t.settingsFile);
     // 5) CLAUDE.md: bloque marcado con {{placeholders}} SIN resolver (los resuelve /build:onboard)
@@ -75,8 +83,10 @@ export async function init(opts) {
     console.log(`  Comandos:  ${countChildren(t.commandsOpsx)} /opsx:* + ${countChildren(t.commandsBuild)} /build:*`);
     console.log(`  Skills:    ${nSkills} en .claude/skills/`);
     console.log(`  Hooks:     ${countChildren(t.hooksBuild)} en .claude/hooks/build/ (settings.json +${addedHooks} hook(s), +${addedPerms} permiso(s))`);
+    console.log(`  Scripts:   ${countChildren(t.scriptsLib)} en .claude/scripts/lib/`);
     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('');
     console.log('Siguiente paso — abre Claude Code y ejecuta:');
     console.log('  /build:onboard   # parametriza el dominio (PII, capa IA, capa determinista) y escribe memoria');
@@ -133,7 +143,7 @@ function syncGitignoreBlock(targetDir, mode) {
     const lines = [GI_BEGIN + ' ───────────────────────', '.claude/state/build-state.json'];
     if (mode === 'symlink') {
         // Los symlinks absolutos a node_modules global se rompen en otra máquina si se commitean.
-        lines.push('.claude/agents/build/', '.claude/commands/opsx/', '.claude/commands/build/', '.claude/hooks/build/');
+        lines.push('.claude/agents/build/', '.claude/commands/opsx/', '.claude/commands/build/', '.claude/hooks/build/', '.claude/scripts/lib/');
         const skillNames = fs.existsSync(ASSETS.skills)
             ? fs.readdirSync(ASSETS.skills, { withFileTypes: true }).filter((d) => d.isDirectory()).map((d) => d.name)
             : [];

package/dist/commands/status.js

@@ -27,6 +27,7 @@ export async function status(opts) {
     console.log(`  Comandos:   ${countChildren(t.commandsOpsx)} /opsx:* · ${countChildren(t.commandsBuild)} /build:*`);
     console.log(`  Skills:     ${countChildren(t.skillsDir)} en .claude/skills/`);
     console.log(`  Hooks:      ${countChildren(t.hooksBuild)} en .claude/hooks/build/`);
+    console.log(`  Scripts:    ${countChildren(t.scriptsLib)} en .claude/scripts/lib/`);
     console.log('');
     console.log('Requisitos externos:');
     console.log(`  openspec:   ${hasBinary('openspec') ? '✓' : '✗ falta (npm i -g @fission-ai/openspec)'}`);

package/dist/commands/uninstall.js

@@ -14,7 +14,8 @@ export async function uninstall(opts) {
     }
     console.log(`▶ uninstall trycore-build-harness de ${targetDir}`);
     // 1) Assets exclusivos del arnés
-    for (const p of [t.agentsBuild, t.commandsOpsx, t.commandsBuild, t.hooksBuild]) {
+    // scriptsLib (NO t.scriptsDir completo — .claude/scripts/ podría llevar contenido del consumidor).
+    for (const p of [t.agentsBuild, t.commandsOpsx, t.commandsBuild, t.hooksBuild, t.scriptsLib]) {
         if (fs.existsSync(p))
             fs.rmSync(p, { recursive: true, force: true });
     }

package/dist/lib/paths.js

@@ -32,12 +32,15 @@ export const ASSETS = {
     commandsBuild: path.join(PACKAGE_ROOT, 'commands', 'build'),
     skills: path.join(PACKAGE_ROOT, 'skills'),
     hooksBuild: path.join(PACKAGE_ROOT, 'hooks', 'build'),
+    hooksBuildLib: path.join(PACKAGE_ROOT, 'hooks', 'build', 'lib'),
+    scriptsLib: path.join(PACKAGE_ROOT, 'scripts', 'lib'),
     // Declaración de hooks para el canal PLUGIN (no la instala el CLI; la consume el plugin nativo).
     pluginHooks: path.join(PACKAGE_ROOT, 'hooks', 'build-harness.json'),
     stateSchema: path.join(PACKAGE_ROOT, 'state', 'build-state.schema.json'),
     stateReadme: path.join(PACKAGE_ROOT, 'state', 'README.md'),
     stateTemplate: path.join(PACKAGE_ROOT, 'state', 'build-state.template.json'),
     configTemplate: path.join(PACKAGE_ROOT, 'config', 'stack-allowlist.template.json'),
+    buildConfigTemplate: path.join(PACKAGE_ROOT, 'config', 'build-config.template.json'),
     templateClaudeMd: path.join(PACKAGE_ROOT, 'templates', 'CLAUDE.md.template'),
     settingsHooksTemplate: path.join(PACKAGE_ROOT, 'templates', 'settings-hooks.template.json'),
 };
@@ -51,8 +54,12 @@ export function targetPaths(targetDir) {
         commandsBuild: path.join(claudeDir, 'commands', 'build'),
         skillsDir: path.join(claudeDir, 'skills'),
         hooksBuild: path.join(claudeDir, 'hooks', 'build'),
+        hooksBuildLib: path.join(claudeDir, 'hooks', 'build', 'lib'),
+        scriptsDir: path.join(claudeDir, 'scripts'),
+        scriptsLib: path.join(claudeDir, 'scripts', 'lib'),
         configDir: path.join(claudeDir, 'config'),
         configFile: path.join(claudeDir, 'config', 'stack-allowlist.json'),
+        buildConfigFile: path.join(claudeDir, 'config', 'build-config.json'),
         stateDir: path.join(claudeDir, 'state'),
         stateSchema: path.join(claudeDir, 'state', 'build-state.schema.json'),
         stateReadme: path.join(claudeDir, 'state', 'README.md'),

package/dist/lib/settings-merge.js

@@ -14,13 +14,23 @@ const CHAIN = '${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/';
 function cmd(script) {
     return `"${CHAIN}${script}"`;
 }
-/** Las 5 agrupaciones de hooks del arnés (= las de hooks/build-harness.json). */
+// statusLine: SOLO canal CLI — los plugins no pueden inyectar statusLine.
+// Misma cadena autorresolutiva que los hooks, así funciona tanto si el
+// arnés se instaló por CLI como si conviven ambos canales (CLAUDE_PLUGIN_ROOT
+// resuelve si el plugin está presente; si no, cae a $CLAUDE_PROJECT_DIR/.claude).
+// En instalaciones plugin-only NO hay statusLine → context-monitor.sh no
+// tiene puente (claude-ctx-*.json) que leer → degrada fail-open (sin aviso),
+// lo cual es aceptable.
+const STATUSLINE_CMD = cmd('statusline-bridge.sh');
+/** Las agrupaciones de hooks del arnés (= las de hooks/build-harness.json). */
 const HOOK_SPECS = [
     { event: 'SessionStart', matcher: 'startup|clear|compact', scripts: ['load-build-state.sh'] },
     { event: 'PreToolUse', matcher: 'Bash', scripts: ['gitflow-guard.sh'] },
     { event: 'PreToolUse', matcher: 'Write|Edit|MultiEdit', scripts: ['stack-guard.sh', 'scaffold-guard.sh', 'design-source-guard.sh'] },
     { event: 'PostToolUse', matcher: 'Write|Edit|MultiEdit', scripts: ['lint-typecheck.sh', 'coherence-flag.sh'] },
-    { event: 'Stop', matcher: '.*', scripts: ['build-gate-check.sh', 'reflect-nudge.sh'] },
+    { event: 'PostToolUse', matcher: 'Bash|Edit|Write|MultiEdit|Task', scripts: ['context-monitor.sh'] },
+    { event: 'PreCompact', matcher: '.*', scripts: ['context-monitor.sh'] },
+    { event: 'Stop', matcher: '.*', scripts: ['build-gate-check.sh', 'reflect-nudge.sh', 'release-gate-nudge.sh', 'context-monitor.sh'] },
 ];
 /** Permisos MÍNIMOS y enumerados [H11]. Nunca permisos amplios (mcp__*, additionalDirectories…). */
 const MIN_PERMISSIONS = [
@@ -49,6 +59,10 @@ function readSettings(file) {
 function writeSettings(file, s) {
     fs.writeFileSync(file, JSON.stringify(s, null, 2) + '\n', 'utf8');
 }
+/** True si el statusLine actual (si existe) ya es el nuestro (por script). */
+function isOwnStatusLine(statusLine) {
+    return typeof statusLine?.command === 'string' && statusLine.command.includes('statusline-bridge.sh');
+}
 function existingCommands(settings, event) {
     const out = new Set();
     for (const group of settings.hooks?.[event] ?? []) {
@@ -83,6 +97,14 @@ export function mergeHarnessSettings(settingsFile) {
             addedPerms++;
         }
     }
+    // statusLine: solo canal CLI (el plugin no inyecta statusLine). Escribe el
+    // puente de contexto. Idempotente: si ya apunta a statusline-bridge.sh no
+    // lo reescribe (evita diffs innecesarios); si el consumidor no tiene
+    // statusLine o tiene otra cosa, este paquete reclama el slot (es único,
+    // no se puede "mergear" como los hooks).
+    if (!isOwnStatusLine(settings.statusLine)) {
+        settings.statusLine = { type: 'command', command: STATUSLINE_CMD };
+    }
     writeSettings(settingsFile, settings);
     return { addedHooks, addedPerms };
 }
@@ -119,6 +141,11 @@ export function removeHarnessSettings(settingsFile) {
             changed = true;
         }
     }
+    // statusLine: quitar SOLO si es el nuestro (simetría con la instalación).
+    if (isOwnStatusLine(settings.statusLine)) {
+        delete settings.statusLine;
+        changed = true;
+    }
     if (changed)
         writeSettings(settingsFile, settings);
     return changed;

package/dist/lib/state-seed.js

@@ -59,3 +59,17 @@ export function seedConfig(targetDir, allowlist) {
     void path;
     return { configSeeded: true };
 }
+/**
+ * Siembra el build-config.json del consumidor (umbrales del context engine).
+ * Solo si NO existe. Idempotente: nunca pisa la config ya ajustada por el equipo.
+ */
+export function seedBuildConfig(targetDir) {
+    const t = targetPaths(targetDir);
+    ensureDir(t.configDir);
+    if (fs.existsSync(t.buildConfigFile))
+        return { buildConfigSeeded: false };
+    if (!fs.existsSync(ASSETS.buildConfigTemplate))
+        return { buildConfigSeeded: false };
+    fs.copyFileSync(ASSETS.buildConfigTemplate, t.buildConfigFile);
+    return { buildConfigSeeded: true };
+}

package/docs/agents.md

@@ -12,7 +12,14 @@ veredicto al `build-orchestrator`**, que es quien propone la escritura del estad
 > **inner loop** (skill `building-a-slice`, por épica `EP-XXX`). Los 5 revisores pesados de
 > release (`security-reviewer`, `simple-design-reviewer`, `ux-krug-reviewer`,
 > `coherence-three-way`, `stack-guardian`) corren **una vez por release** en el **outer loop**
-> (skill `releasing-a-version`).
+> (skill `releasing-a-version`) y escriben sus veredictos en `releases[].gates`
+> (`security`, `smell`, `ux`, `coherence`, `stack_arch` — este último renombrado desde el antiguo
+> `stack` por-slice).
+>
+> **Conducción opcional vía plantillas de workflow.** Tres plantillas read-only (opt-in, no editan
+> estado) sirven de andamiaje para orquestar estos agentes sin sustituir su juicio:
+> `explore-fanout.workflow.js` y `wiring-verify.workflow.js` en `building-a-slice` (inner loop), y
+> `release-gate.workflow.js` en `releasing-a-version` (outer loop).
 
 ## Tabla resumen
 
@@ -23,8 +30,8 @@ veredicto al `build-orchestrator`**, que es quien propone la escritura del estad
 | 3 | `security-reviewer` | sonnet | Revisores de release | Gate `security` — seguridad enfocada al dominio |
 | 4 | `simple-design-reviewer` | sonnet | Revisores de release | Gate `smell` — 4 reglas de Beck + code smells |
 | 5 | `ux-krug-reviewer` | sonnet | Revisores de release | Gate `ux` — usabilidad (Steve Krug) |
-| 6 | `coherence-three-way` | **opus** | Revisores de release | Gate `coherence` — coherencia triple AC↔change↔código |
-| 7 | `stack-guardian` | sonnet | Revisores de release | Gate `stack` — stack y arquitectura vs. allowlist |
+| 6 | `coherence-three-way` | **opus** | Revisores de release | Gate `coherence` (en `releases[].gates`) — coherencia triple AC↔change↔código |
+| 7 | `stack-guardian` | sonnet | Revisores de release | Gate `stack_arch` (en `releases[].gates`) — stack y arquitectura vs. allowlist |
 | 8 | `api-contract-tester` | sonnet | Contrato / datos | Gate `api` — pruebas de contrato (Newman/Postman) |
 | 9 | `data-consistency-checker` | sonnet | Contrato / datos | Gate `data` — invariantes y consistencia de datos |
 | 10 | `change-epic-coherence` | sonnet | Trazabilidad | Gate `coherence_link` — enlace change↔épica↔HU |
@@ -53,7 +60,7 @@ frontmatter completo y `estado: lista`; AC en Given/When/Then con happy/error/ed
 dependencias declaradas; alcance dentro de la allowlist) y abre el `active_slice` si pasa. A
 la salida valida la **Definition of Done reducida por slice** (gate `dod`): `tdd`,
 `journey_smoke`, `coherence_link`, `data`, `api`, documentación con back-refs y hooks verdes.
-**No valida aquí** `security`, `smell`, `ux`, `coherence` ni `stack`: esos son del Release Gate.
+**No valida aquí** `security`, `smell`, `ux`, `coherence` ni `stack_arch`: esos son del Release Gate (viven en `releases[].gates`).
 
 ## Revisores de release
 
@@ -69,39 +76,39 @@ los **especializa al dominio declarado por el consumidor**: secretos de servicio
 solo server-side, datos sensibles/PII regulados no persistidos crudos, validación de archivos
 y entrada, salida de servicios externos/IA tratada como input no confiable, logs sin PII y
 decisiones auditables sin sobre-exposición. Veredicto por severidad
-(CRÍTICO/ALTO/MEDIO/BAJO); sin CRÍTICO/ALTO → `gates.security: true`.
+(CRÍTICO/ALTO/MEDIO/BAJO); sin CRÍTICO/ALTO → `releases[].gates.security: true`.
 
 ### `simple-design-reviewer` · modelo `sonnet`
 **Revisor de diseño simple y code smells** (gate `smell`), sobre código ya en verde. Aplica
 las 4 reglas de Kent Beck (pasa los tests → revela la intención → sin duplicación → mínimos
 elementos) y caza un catálogo de smells (funciones largas, clases "Dios", números mágicos,
 duplicación de validación, props drilling, código muerto, `any`, acoplamiento a servicios
-externos). Hallazgos BLOQUEANTE/RECOMENDADO/NIT; sin bloqueantes → `gates.smell: true`.
+externos). Hallazgos BLOQUEANTE/RECOMENDADO/NIT; sin bloqueantes → `releases[].gates.smell: true`.
 
 ### `ux-krug-reviewer` · modelo `sonnet` · lee el dominio
-**Revisor de usabilidad** según Steve Krug (gate `ux`); aplica solo a slices con UI (sin UI →
-`gates.ux: null`). Verifica "don't make me think", jerarquía visual, convenciones,
+**Revisor de usabilidad** según Steve Krug (gate `releases[].gates.ux`); aplica solo a releases con UI (sin UI →
+`releases[].gates.ux: null`). Verifica "don't make me think", jerarquía visual, convenciones,
 escaneabilidad, affordances, tolerancia al error (claridad de las decisiones de alto impacto y
 su justificación según el dominio) y accesibilidad básica. Revisión estática y, si la app
 corre, dinámica vía MCP `chrome-devtools` (`take_snapshot`, `lighthouse_audit`). Sin
-bloqueantes → `gates.ux: true`.
+bloqueantes → `releases[].gates.ux: true`.
 
 ### `coherence-three-way` · modelo `opus` · lee el dominio
-**Auditor de coherencia triple** (gate `coherence`). Usa el modelo más capaz porque razona a
+**Auditor de coherencia triple** (gate `releases[].gates.coherence`). Usa el modelo más capaz porque razona a
 la vez sobre tres documentos: los **AC (G/W/T)** de las HU de la épica ↔ el **OpenSpec change**
 (`specs/` + `tasks.md`) ↔ el **código y tests** implementados. Hace comprobaciones top-down
 (cada requisito tiene implementación) y bottom-up (nada huérfano: ni tests sin propósito ni
 código fuera del alcance de `hus[]`). Produce una matriz de trazabilidad; COHERENTE →
-`gates.coherence: true`. Complementa a `change-epic-coherence` verificando la implementación real.
+`releases[].gates.coherence: true`. Complementa a `change-epic-coherence` verificando la implementación real.
 
 ### `stack-guardian` · modelo `sonnet` · lee el dominio
-**Guardián del stack** (gate `stack`, arquitectura). Defiende la sección de requisitos
+**Guardián del stack** (gate `releases[].gates.stack_arch`, arquitectura; antes `gates.stack` por-slice). Defiende la sección de requisitos
 técnicos del PRD del consumidor (ruta en `stack-allowlist.json#source`), operacionalizada en
 `.claude/config/stack-allowlist.json`. Verifica que las **dependencias** matcheen la
 allowlist y que la **arquitectura** respete el stack declarado (frontend/runtime del
 consumidor; servicio externo/IA usado solo en su frontera server-side; capa de decisión del
 dominio determinista sin servicio no determinista cuando el PRD lo exige; persistencia sin PII
-regulada cruda) y señala anti-patrones. STACK-OK → `gates.stack: true`. El hook
+regulada cruda) y señala anti-patrones. STACK-OK → `releases[].gates.stack_arch: true`. El hook
 `stack-guard.sh` bloquea deps fuera de lista en tiempo real; este agente razona sobre
 arquitectura y uso.