@trycore/spec-build-harness 0.7.1 → 0.8.1

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.1",
+  "version": "0.8.1",
   "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/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

@@ -76,8 +76,61 @@ Gate de release que corre **una sola vez por versión** sobre el conjunto de sli
 | `/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
 
 ```
@@ -88,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/                 ← 5 comandos /build:* (onboard, reflect, slice, release, work)
-├── skills/                    ← 13 skills (building-a-slice, building-a-micro-change, releasing-a-version, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
-├── hooks/build/               ← 10 hooks bash (gate-check, reflect-nudge, release-gate-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)
@@ -126,7 +179,9 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **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** — **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 (actual)** — **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.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 (actual)** — **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`.
 
 ## Licencia
 

package/VERSION

@@ -1 +1 @@
-0.7.1
+0.8.1

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', 'release-gate-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/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 5 `/build:*`: `onboard`, `reflect`, `slice`, `release`, `work`) — 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 7 `/build:*`: `onboard`, `reflect`, `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 5 `/build:*` (`onboard`, `reflect`, `slice`, `release`, `work`).
+El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y `.claude/commands/build/` → los 7 `/build:*` (`onboard`, `reflect`, `slice`, `release`, `work`, `resume`, `front`).
 
 ### `/opsx:*` — pipeline OpenSpec
 
@@ -99,6 +99,18 @@ El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y
 |---|---|
 | `/build:reflect` | Tras archivar un slice, detecta **convenciones aprendidas** / errores recurrentes (a partir del change, el diff y la sesión) y **propone** viñetas para el bloque `trycore-build-learnings` de `CLAUDE.md`; las aplica **solo tras tu aprobación** y estampa el slice como reflexionado (`reflected: true`). Lo **sugiere** el hook `reflect-nudge.sh` al cerrar sesión, pero puedes invocarlo cuando quieras. No toca el bloque de dominio ni sus `{{placeholders}}` (eso es de `/build:onboard`). |
 
+### `/build:resume` — rehidratación sin pérdida de contexto
+
+| Slash command | Propósito |
+|---|---|
+| `/build:resume` | Reconstruye el contexto de construcción **desde disco**, no desde la conversación: corre `reconcile-build-state.py`, lee `active_slice` (`gates`, `wiring_checklist`, `progress_log`, `session_continuity`, `parallel_front`) y determina la siguiente acción por prioridad (`resume_hint` → item `failing` de wiring → `sub_slices` pendiente → fase del pipeline). Es el punto de entrada tras un handoff automático del hook `context-monitor.sh` o tras cualquier reinicio de contexto. |
+
+### `/build:front` — front paralelo inter-épica
+
+| Slash command | Propósito |
+|---|---|
+| `/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`. |
+
 ---
 
 ## 3. Caveat de canales (CLI vs. plugin)
@@ -108,7 +120,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 5 `/build:*` (`onboard`, `reflect`, `slice`, `release`, `work`) | Por nombre del plugin: `/trycore-spec-build-harness:*` (por diseño de Claude Code) |
+| Namespace de comandos | Por subcarpeta: `/opsx:*` y los 7 `/build:*` (`onboard`, `reflect`, `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 |