@trycore/spec-build-harness 0.14.0 → 0.14.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.14.0",
+  "version": "0.14.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/INSTALL.md

@@ -19,6 +19,26 @@ Hay **dos canales** de instalación: el **CLI npm** (canónico, recomendado para
 proyecto) y el **plugin nativo** de Claude Code (conveniencia a nivel usuario). Lee el
 [caveat de canales](#5-alternativa-plugin-nativo-con-caveat-de-canales) antes de elegir.
 
+## ¿Qué camino me toca?
+
+Cuatro situaciones, cuatro caminos. Todos empiezan por §1 (CLI global) y §2 (requisitos).
+
+| Tu situación | Cómo saberlo | Qué haces |
+|---|---|---|
+| **Proyecto nuevo**, sin el arnés | no existe `.claude/.build-harness-version` | §3 `init` → §4 `/build:onboard`. Listo. |
+| **Proyecto existente** con el arnés, quieres ponerlo al día | existe la marca, con una versión vieja | §7 `update`. **No** re-corras `/build:onboard`: tu dominio ya está parametrizado. |
+| **Proyecto existente en `legacy`**, quieres conectarlo al IA Hub | existe la marca y `runtime.mode` es `legacy` | §7 `update` **primero**, luego §9 → [guía runtime §4](docs/runtime/guia-modo-dual-y-migracion.md) |
+| **Proyecto nuevo** que ya nace contra el IA Hub | — | §3 `init` **con las flags de runtime** (§9) → §4 `/build:onboard` |
+
+Dos cosas que ahorran disgustos:
+
+- **`init` y `update` son el mismo comando.** `init` detecta si ya hay instalación (por
+  `.claude/.build-harness-version`) y se comporta como `update`. Re-correrlo es seguro: **nunca**
+  pisa `build-state.json` ni `stack-allowlist.json`, que son del consumidor.
+- **Conectar un proyecto al hub exige el arnés al día primero.** Los hooks del cliente runtime no
+  existen antes de la 0.9.0: si escribes el modo sobre una instalación vieja, queda escrito y nada
+  lo ejecuta.
+
 ---
 
 ## 1. Instalar el CLI global (npm)
@@ -87,7 +107,7 @@ 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/` (12 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:prototype`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`, `/build:claim`, `/build:status`, `/build:escalate`).
+   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (13 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:prototype`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`, `/build:claim`, `/build:status`, `/build:escalate`, `/build:epic`). Los cuatro últimos son la **superficie de agente del modo runtime** (§9): en `legacy`, `claim`, `escalate` y `epic` devuelven `rc 3` remitiendo al flujo del fichero, y `status` informa de que la fuente de verdad es `build-state.json`.
    - `.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/` — 19 hooks (bash + python; 6 son del cliente runtime opt-in — §9).
 3. **Siembra el estado**: `state/build-state.schema.json` y `state/README.md` se versionan;
@@ -166,9 +186,9 @@ Tras `init`, abre Claude Code en el proyecto y ejecuta:
 ```
 
 `/build:onboard` lee el PRD técnico (y `openspec/project.md` si existe) y, vía `AskUserQuestion`
-(proponiendo un valor "(Recomendado)" por punto), confirma y resuelve **6 puntos de extensión**
+(proponiendo un valor "(Recomendado)" por punto), confirma y resuelve **7 puntos de extensión**
 que leen los agentes de calidad (`security-reviewer`, `stack-guardian`, `data-consistency-checker`,
-`ux-krug-reviewer`, `simple-design-reviewer`):
+`ux-krug-reviewer`, `simple-design-reviewer`, `ux-fidelity-reviewer`):
 
 | Placeholder | Qué pregunta |
 |---|---|
@@ -178,6 +198,7 @@ que leen los agentes de calidad (`security-reviewer`, `stack-guardian`, `data-co
 | `{{SENSITIVE_DATA_CATEGORIES}}` | Categorías de datos sensibles / PII reguladas |
 | `{{SERVER_SIDE_SECRETS}}` | Secretos server-side que jamás van al cliente |
 | `{{HIGH_STAKES_DECISIONS}}` | Decisiones de alto impacto que exigen explicabilidad en la UI |
+| `{{DESIGN_SOURCE}}` | Fuente de diseño / referencia visual (prototipo, export), o `N/A` si el proyecto no tiene UI |
 
 Qué resuelve:
 
@@ -308,12 +329,44 @@ modo `legacy` (default, sin cambios). Requiere un runtime corriendo y un **token
 emitido por un ADMIN en la consola del hub.
 
 ```bash
+# Proyecto nuevo contra el hub, o proyecto existente YA actualizado (ver la tabla del principio)
 trycore-build init --runtime-url "https://tu-runtime.example.com" --runtime-token "<token>"
+
 trycore-build doctor    # sección "Runtime": token, conectividad, lock, cola offline
 trycore-build status    # sección "Runtime": conexión, proyección, contexto sincronizado
 trycore-build migrate --project-ref "<nombre-en-el-hub>"   # bundle de estado histórico para un ADMIN
 ```
 
+Sin `--runtime-mode`, el default con URL+token es **`dual`** (nunca `runtime`): el fichero local
+sigue mandando y cada transición se espeja al servidor para poder compararlas. El corte directo a
+`runtime` no está soportado por diseño.
+
+### Qué gana el proyecto al conectarse
+
+| | Qué hace | Necesita el hub |
+|---|---|---|
+| **Contexto vivo** | El daemon refresca `/agent/context` cada `runtime.context_refresh_s` segundos (default 45, `0` desactiva) — una terminal abierta se entera de lo que pasa sin reiniciar | **No**, funciona hoy |
+| **Épicas propuestas** | `/build:epic` propone la épica, el hub asigna el `EP-XXX` al aprobarla y `/build:epic --check` la proyecta a `epicas.md` | Sí (`trycore-ia-hub#113`/`#114`) |
+| **Versión de grafo** | `claim` y la propuesta mandan la versión conocida; un `409` provoca refresco y reintento en vez de fallo | Sí (`trycore-ia-hub#115`) |
+| **Reparto de trabajo** | `/build:claim` pide la siguiente tarea por lease; `/build:status` informa; `/build:escalate` registra un bloqueo | Sí |
+
+Contra un hub que no implementa una de esas mitades, el cliente **degrada limpiamente**: un `404`
+se aparta diciendo «esta instancia está sin soporte», sin reintentos en bucle, y un hub que no
+versiona el grafo ve el mismo cuerpo de `claim` de siempre.
+
+### Configuración
+
+`.claude/config/build-config.json`, bloque `runtime`:
+
+| Clave | Default | Para qué |
+|---|---|---|
+| `mode` | `legacy` | `legacy` \| `dual` \| `runtime`. Un valor inválido cae a `legacy`, nunca a la red. |
+| `stale_seconds` | `900` | A partir de cuántos segundos la proyección se considera stale |
+| `context_refresh_s` | `45` | Cadencia del refresco de contexto del daemon; `0` lo desactiva |
+
+Overrides por entorno, útiles para una sesión puntual sin editar el fichero:
+`TRYCORE_RUNTIME_MODE`, `TRYCORE_CONTEXT_REFRESH_S`.
+
 Guía completa (los tres modos, cómo activar/verificar/volver a legacy, cuándo se corta) →
 [`docs/runtime/guia-modo-dual-y-migracion.md`](docs/runtime/guia-modo-dual-y-migracion.md).
 

package/README.md

@@ -143,7 +143,7 @@ trycore-spec-build-harness/
 ├── agents/build/              ← 14 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← 12 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front, claim, status, escalate)
+│   └── build/                 ← 13 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front, claim, status, escalate, epic)
 ├── 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/               ← 19 hooks (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, statusline-bridge, context-monitor, reconcile-build-state, …) + 6 opt-in del cliente runtime (session-start, event-emitter, context-sync, heartbeat, dual-compare, session-stop — ver docs/hooks.md)
 ├── state/                     ← máquina de estado legacy: build-state.json + schema + README
@@ -183,7 +183,50 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 
 ## Roadmap
 
-- ✅ **v0.10.0 (actual) — convergencia del inner loop** — ataque a los seis multiplicadores de
+- ✅ **v0.14.0 (actual) — contexto vivo, épicas propuestas y versión de grafo** (#61, #62, #63) —
+  tres capacidades del cliente del runtime que componen entre sí. **(1)** El daemon de heartbeat
+  refresca `GET /agent/context` con **cadencia propia** (`runtime.context_refresh_s`, default 45 s,
+  `0` la desactiva): antes la caché se hidrataba al arrancar la sesión y en cada `claim` —y el
+  `claim` ocurre una vez por slice—, así que una terminal abierta podía trabajar horas contra una
+  foto vieja; un refresco fallido **conserva** la caché anterior y la marca stale, porque quedarse
+  sin proyección dejaría al agente huérfano. **(2)** En modo `runtime` la épica se **propone** al
+  hub en vez de escribirse en el backlog: comando nuevo **`/build:epic`**, subcomandos
+  `propose-epic`/`epic-status`/`epic-writeback` y un **carril directo** en la cola offline que
+  sobrevive a quedarse sin red; el hub asigna el `EP-XXX` al aprobar y `docs/03-backlog/epicas.md`
+  pasa a ser **proyección del grafo**, nunca una fuente paralela —el agente pierde la potestad de
+  inventar identidades, que es lo que hacía colisionar las historias de dos épicas creadas el mismo
+  día—. **(3)** `claim` y la propuesta mandan la **versión de grafo** conocida, estampada *al
+  despachar* y no al encolar; un `409` por grafo rancio provoca refresco y un reintento en vez de
+  un fallo. `legacy` sigue siendo el default y no cambia. Las mitades de servidor de (2) y (3)
+  (`trycore-ia-hub#113`/`#114`/`#115`) están pendientes: contra un hub sin ellas el cliente degrada
+  a «instancia sin soporte». Total: **14 agentes**, **19 hooks**, **13 comandos `/build:*`**,
+  **16 skills**.
+- ✅ **v0.13.0 — el grafo llega al hub con aristas** — las dependencias entre épicas viven como
+  prosa en `epicas.md` (`**Depende de**: EP-001`) y su lectura estaba delegada al modelo, con un
+  ejemplo en `/build:onboard` que mostraba `"depends_on": []`: las 41 épicas del piloto entraron
+  sin una sola arista y nadie lo detectó, porque un grafo vacío no falla, solo empobrece (#56).
+  `graph-bundle.py` gana un **extractor determinista** (`--from-docs` / `--print-deps`) que relee
+  el campo, con avisos de cobertura y traza de la fuente en `depends_on_source`. Además,
+  `unmapped[].original` viaja siempre como dict (#55): el hub valida el bundle entero con pydantic,
+  así que un escalar lo rechazaba **completo** antes de persistir nada.
+- ✅ **v0.12.0 — la fase del slice llega al hub** (#52) — el hub modela la fase con eventos
+  `phase_advanced` de orden estricto y exige `phase == pr` para archivar, pero el cliente no emitía
+  ninguna: los slices quedaban «en construcción» con su PR ya mergeado. Subcomando
+  `slice-ops.sh phase <to>`, que emite la cadena que falte (idempotente, sin saltos), y **catch-up
+  automático** al archivar. Además, `outbox/rejected/` deja de ser invisible: la razón del rechazo
+  se persiste en el propio fichero y la muestran `slice-ops.sh status` y `trycore-build status`/`doctor`.
+- ✅ **v0.11.1 — auto-cierre de releases en verde** — el cierre manual de una release con 6/6 gates
+  PASS era control-teatro: el hub la cierra solo (`closed_by: AUTO_6_OF_6_PASS`) y los casos
+  degradados siguen siendo decisión humana. Arreglado también que `release-ops.sh verdict` devolvía
+  **422 en todo reporte** (faltaba el campo `verdict` en mayúsculas junto a `status`).
+- ✅ **v0.11.0 — drift cliente↔hub del primer piloto real** (#36–#44) — la primera migración contra
+  el hub en producción reveló un desajuste sistemático entre lo que el cliente emite y lo que el
+  hub valida: `claim` devolvía 422 en todo intento, la cola offline **nunca drenaba**, `fact`
+  emitía tipos fuera del catálogo, `claim --epic` se ignoraba en silencio y repartía otra épica, y
+  el import rechazaba 36 de 41 entradas del bundle histórico. Cada fix verificado contra el código
+  real del hub, con regresión anti-drift nueva que valida todo tipo encolable contra una réplica
+  literal de su catálogo.
+- ✅ **v0.10.0 — convergencia del inner loop** — ataque a los seis multiplicadores de
   latencia de la verificación adversarial (iniciativa #31, issues #25–#30) **sin bajar el rigor**:
   **re-verificación incremental** con `verified_at_sha` por item de `wiring_checklist[]` (las
   pasadas 2+ re-ejecutan O(items tocados), no O(items totales)); **condición de parada** del bucle

package/VERSION

@@ -1 +1 @@
-0.14.0
+0.14.1

package/docs/commands.md

@@ -136,7 +136,7 @@ protocolo del fichero (`/build:slice`) — no rompen el flujo normal si el proye
 
 | Slash command | Propósito |
 |---|---|
-| `/build:claim [EP-XXX]` | Pide la siguiente tarea al runtime (`POST /tasks/next`): sincroniza contexto, reporta hashes locales (detección de drift) y reclama por lease. Si trae `CHECKPOINT`, continúa desde ahí — **nunca reinicia** un slice de otro agente. |
+| `/build:claim` | Pide la siguiente tarea al runtime (`POST /tasks/next`): sincroniza contexto, reporta hashes locales (detección de drift) y reclama por lease. Si trae `CHECKPOINT`, continúa desde ahí — **nunca reinicia** un slice de otro agente. **No acepta épica dirigida**: el hub reparte por orden de cola y `claim --epic` falla explícito con `rc 2` (issue #39 — el servidor ignoraba el `epic_code` y entregaba otra épica como si fuera la pedida, dejando un lease huérfano). |
 | `/build:status` | Informe de solo lectura: modo, slice activo, gates, wiring failing, versión de contexto, lease y cola de eventos pendientes. Nunca transiciona nada. |
 | `/build:escalate <razón>` | Registra un bloqueo en el runtime (`escalation_raised`) y devuelve la decisión a un humano — recortar, diferir o desbloquear **nunca** lo decide el modelo (mismo principio que la regla 8 de METODOLOGIA §10). |
 | `/build:epic` | Propone una épica **incremental de construcción** al hub y, tras la aprobación humana, la escribe en `docs/03-backlog/epicas.md` con el `EP-XXX` que asignó el hub (`/build:epic --check`). El agente **no elige** el código: elegirlo mirando el fichero es lo que hace colisionar a dos terminales. La descomposición inicial del backlog sigue siendo de discovery. |

package/docs/getting-started.md

@@ -24,6 +24,14 @@ trycore-build doctor     # verifica requisitos y hooks
 
 Eso es el ciclo completo. Lo de abajo explica cada paso.
 
+> **¿Conectado a un IA Hub?** El pipeline es **el mismo**; cambia dónde vive el estado y quién
+> valida las transiciones. Añades cuatro comandos a la caja de herramientas — `/build:claim` (pide
+> trabajo), `/build:status` (informe), `/build:epic` (propone una épica) y `/build:escalate`
+> (registra un bloqueo) — y el arranque lleva las flags de runtime. En `legacy` no estorban:
+> `claim`, `epic` y `escalate` devuelven `rc 3` y te remiten al flujo del fichero, y `status`
+> informa de que la fuente de verdad es `build-state.json`.
+> Instalación y activación → [`docs/runtime/guia-modo-dual-y-migracion.md`](runtime/guia-modo-dual-y-migracion.md).
+
 ---
 
 ## Requisitos duros
@@ -48,7 +56,9 @@ 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**, **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.
+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:*`** + **13 comandos `/build:*`** (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front` + `claim`, `status`, `escalate`, `epic`, que son la superficie del modo runtime), **19 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.
+
+> **¿Ya tenías el arnés instalado?** Entonces esto es un `update`, no un `init` — el CLI lo detecta solo por `.claude/.build-harness-version`. Corre `npm i -g @trycore/spec-build-harness@latest` y luego `trycore-build update`; **no** repitas `/build:onboard`, tu dominio ya está parametrizado. La tabla «¿Qué camino me toca?» de [`INSTALL.md`](../INSTALL.md) cubre los cuatro casos.
 
 ```bash
 trycore-build init

package/docs/runtime/guia-modo-dual-y-migracion.md

@@ -55,16 +55,47 @@ Si `--runtime-mode` no se especifica pero sí `--runtime-url`/`--runtime-token`,
 `dual` (nunca `runtime` — el corte directo a `runtime` sin pasar por `dual` no está soportado por
 diseño: es exactamente el "big bang" que el plan de migración evita).
 
-## 4. Activar `dual` en un proyecto ya instalado (`update`)
+## 4. Activar `dual` en un proyecto ya instalado
 
-`trycore-build update` no acepta las flags de runtime directamente hoy — vuelve a correr `init` con
-las mismas flags sobre el proyecto existente; es idempotente (no pisa `build-state.json` ni
-`stack-allowlist.json`, solo añade las credenciales y el modo):
+Este es el camino normal: el proyecto ya lleva el arnés en `legacy` (tiene
+`.claude/.build-harness-version` y su `build-state.json` con historial) y quieres que además
+espeje al hub.
+
+**`trycore-build update` no acepta las flags de runtime.** Vuelve a correr `init` con ellas sobre
+el proyecto existente: `init` detecta la instalación previa y es **idempotente** — no pisa
+`build-state.json` ni `stack-allowlist.json`, solo añade las credenciales y el modo.
 
 ```bash
-trycore-build init --runtime-url "..." --runtime-token "..." --runtime-mode dual
+# 0. Parte de un arnés al día (si vienes de una versión vieja, primero esto)
+npm i -g @trycore/spec-build-harness@latest
+cd /ruta/al/proyecto
+trycore-build update
+
+# 1. Añade las credenciales y activa el espejo
+trycore-build init --runtime-url "https://tu-runtime.example.com" \
+                   --runtime-token "<token-del-ADMIN>" \
+                   --runtime-mode dual
+
+# 2. Comprueba
+trycore-build doctor
+trycore-build status
 ```
 
+El paso 0 importa: las credenciales y el modo se escriben igual, pero los **hooks del cliente
+runtime** (`session-start`, `event-emitter`, `context-sync`, `heartbeat`, `dual-compare`,
+`session-stop`) solo existen desde la 0.9.0. Si el proyecto arrastra una versión anterior, el modo
+queda escrito y **nada lo ejecuta**: sin ese `update` previo el espejo no espeja nada.
+
+> **Salto grande de versión.** `update` refresca assets y schema, nunca tu estado. Si vienes de
+> varias minor por detrás, corre `trycore-build status` después y mira el informe en vez de darlo
+> por bueno: te dirá si la versión instalada quedó sincronizada y si el estado sigue validando.
+
+### ¿Y el historial que ya tienes?
+
+Activar `dual` **no** sube tus slices archivados: el espejo solo cubre lo que ocurra de aquí en
+adelante. Para que el hub conozca el pasado, ver §7 (`trycore-build migrate`). Es opcional — el
+piloto funciona igual sin ello, solo que las proyecciones del servidor empiezan vacías.
+
 ## 5. Verificar que quedó bien
 
 ```bash
@@ -73,19 +104,68 @@ trycore-build status    # resumen + sección "Runtime": conexión, proyección,
 ```
 
 Dentro de una sesión de Claude, `/build:status` da el mismo informe (más `next-step` derivado) y
-`/build:claim [EP-XXX]` reclama la siguiente tarea directamente contra el runtime.
+`/build:claim` reclama la siguiente tarea directamente contra el runtime. **`claim` no acepta épica
+dirigida**: el hub reparte por orden de cola y `claim --epic EP-XXX` falla explícito con `rc 2`
+(issue #39 — el servidor ignoraba el `epic_code` en el cuerpo y entregaba la primera épica de su
+cola como si fuera la pedida, dejando un lease huérfano que solo la consola admin libera). Si
+necesitas dirigir una épica concreta, termina el slice en `dual`, pide al ADMIN apagar el espejo y
+reclama lo que la cola sirva.
 
 ## 6. Qué cambia en el día a día
 
 **Nada que tengas que operar tú a mano.** Las skills (`building-a-slice`, `releasing-a-version`,
 `managing-parallel-front`) conducen exactamente el mismo pipeline; por debajo, en vez de
-leer/escribir `build-state.json` directamente, llaman a `slice-ops.sh`/`release-ops.sh` (13
-subcomandos: `claim`, `gate`, `wiring`, `progress`, `checkpoint`, `submit`, `archive`, `fact`,
-`propose-asset`, `status`, `escalate`, y del lado release `verdict`/`front-integration`) — nunca
+leer/escribir `build-state.json` directamente, llaman a `slice-ops.sh`/`release-ops.sh` — nunca
 arman peticiones a mano. En `dual`, cada transición también se **espeja** al servidor con la
 identidad del fichero (que sigue mandando). Si el espejo falla (red caída, servidor rechaza), el
 trabajo local **nunca se bloquea** — se avisa y queda como discrepancia para el comparador.
 
+`slice-ops.sh` tiene **17 subcomandos** (los conducen las skills; los listamos para que puedas
+leer un log o depurar, no para que los teclees):
+
+| Subcomando | Para qué |
+|---|---|
+| `mode` | imprime `legacy`\|`dual`\|`runtime` |
+| `claim` | reclama trabajo (el hub reparte por orden de cola; sin épica dirigida) |
+| `next-step` | deriva la siguiente acción desde la caché de proyección |
+| `phase` | reporta la fase del pipeline (emite la cadena que falte; idempotente) |
+| `gate` | reporta un veredicto del slice |
+| `submit` · `archive` | entrega y archiva el slice |
+| `wiring` | siembra y actualiza el checklist de cableado |
+| `progress` · `checkpoint` | bitácora y continuidad tras una caída |
+| `fact` | reporta un hecho de proyecto confirmado |
+| `propose-asset` | propone un documento al plano de contexto (lo publica un ADMIN) |
+| `propose-epic` · `epic-status` · `epic-writeback` | proponen una épica, consultan su estado y proyectan la aprobada a `epicas.md` |
+| `status` · `escalate` | informe local del agente y registro de un bloqueo |
+
+Del lado release, `release-ops.sh` añade `verdict` y `front-integration`.
+
+**Códigos de salida** (sobre estos ramifica la prosa de las skills): `0` ok · `2` uso · `3` legacy ·
+`4` sin slice · `5` offline · `6` rechazado · `7` sin trabajo.
+
+### Lo que aportó la 0.14.0
+
+- **El contexto ya no se queda congelado** (#61). El daemon de heartbeat refresca `GET /agent/context`
+  cada `runtime.context_refresh_s` segundos (default **45**; `0` lo desactiva; override
+  `TRYCORE_CONTEXT_REFRESH_S`), **solo en modo `runtime`**. Antes, la caché se hidrataba al arrancar
+  la sesión y en cada `claim` — y el `claim` ocurre una vez por slice, así que una terminal abierta
+  podía trabajar horas contra una foto vieja. Si el refresco falla, la caché anterior **se conserva**
+  y se marca stale (lo dice `/build:status`): quedarse sin proyección dejaría al agente huérfano.
+- **Las épicas se proponen, no se escriben** (#62). En `runtime`, el agente ya no elige el `EP-XXX`:
+  lo propone al hub con **`/build:epic`**, un humano lo aprueba en la consola, el hub asigna la
+  identidad y `/build:epic --check` proyecta la épica aprobada a `docs/03-backlog/epicas.md`. El
+  fichero pasa a ser una **proyección del grafo**, nunca una fuente paralela. La propuesta viaja por
+  un carril de la cola offline, así que sobrevive a quedarte sin red.
+- **Una terminal desactualizada ya no puede hacer daño** (#63). `claim` y la propuesta de épica
+  mandan la versión de grafo que conocen; si está rancia, el hub responde `409` y el cliente
+  refresca y reintenta una vez en vez de fallar. `/build:status` avisa si tu versión va por detrás.
+
+> **Dependencia externa:** las mitades de servidor de #62 y #63 (`trycore-ia-hub#113`, `#114`, `#115`)
+> **todavía no existen**. Contra un hub que no las implementa, `/build:epic` recibe un `404` y aparta
+> la propuesta diciendo «esta instancia está sin soporte», sin reintentos en bucle; y un hub que no
+> versiona el grafo ve exactamente el mismo cuerpo de `claim` de siempre. El refresco de contexto
+> (#61) **sí funciona hoy**: no necesita nada nuevo del servidor.
+
 **El comparador dual** (`hooks/build/dual-compare.sh`, hook `Stop`) corre después de cada turno:
 compara la proyección del servidor contra el fichero local (épica, fase, gates ya resueltos) y, si
 divergen, lo escala vía `/build:escalate` — nunca bloquea el cierre de sesión. Es el instrumento

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trycore/spec-build-harness",
-  "version": "0.14.0",
+  "version": "0.14.1",
   "description": "Arnés agéntico de construcción de Trycore para Claude Code: pipeline de dos loops (slice por épica + release gate) con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "type": "module",
   "bin": {