@trycore/spec-build-harness 0.14.0 → 0.14.2

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.2",
   "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,52 @@ 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)
+  ya existen en el hub, en el **carril del agente** (`/projects/{id}/agent/epic-proposals`), y la
+  **v0.14.2** alineó al cliente con ese contrato: hasta entonces pegaba contra la ruta de consola
+  y la propuesta moría con `405`/`422` (#70). Contra un hub que no lo exponga, 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.2

package/commands/build/epic.md

@@ -49,6 +49,9 @@ Reúne del repo y de `docs/` lo necesario y **propón** al usuario, vía **AskUs
 título, objetivo, capa (`foundational` | `business` | `technical`), alcance de archivos y
 dependencias con épicas existentes. Las historias van con AC en Given/When/Then.
 
+El grafo del hub solo distingue **dos** capas (`FOUNDATIONAL` y `BUSINESS`): una épica
+`technical` viaja como `business` y eso es correcto, no un error que debas corregir.
+
 No inventes la clasificación de capa ni las dependencias: derívalas del PRD / Story Map y
 confírmalas. Sin aprobación explícita del usuario, **no propongas nada**.
 
@@ -61,10 +64,21 @@ Escribe el borrador en un fichero temporal (nunca por argv):
   "layer": "business",
   "files_scope": ["src/…/**"],
   "depends_on": ["EP-012"],
-  "stories": [{"title": "…", "acceptance_criteria": "Dado … Cuando … Entonces …"}]
+  "stories": [
+    {
+      "title": "…",
+      "description": "Como … quiero … para …",
+      "acceptance_criteria": "Dado … Cuando … Entonces …. Dado … Cuando … Entonces …"
+    }
+  ]
 }
 ```
 
+Escribe los criterios **completos** en `acceptance_criteria`: `slice-ops.sh` los parte en un
+escenario por entrada y los manda como `acceptance[]`, que es lo que la consola del hub enseña
+en el detalle de la historia (issue #70). Varios escenarios en un mismo campo se separan con
+`. Dado …`; si prefieres darlos ya partidos, usa `"acceptance": ["Dado …", "Dado …"]` y manda.
+
 ## 2. Proponer
 
 ```bash

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/docs/runtime/protocolo-cliente-runtime.md

@@ -228,8 +228,8 @@ modo, valida en local lo que es barato validar y encola lo que no pudo entregar.
 | `slice-ops.sh propose-asset` | `POST …/context/agent-proposals` (§6) |
 | `slice-ops.sh status` | `GET /agent/context` (refresco) + ficheros locales; reporta además `outbox/rejected/` (conteo + tipo y razón del rechazo más reciente, issue #52) |
 | `slice-ops.sh escalate` | evento `slice_escalated {cause}` (gate y fase dentro del texto de la causa; exige slice activo en runtime) |
-| `slice-ops.sh propose-epic --file B` | `POST /projects/{id}/epic-proposals` (carril directo). Propone una épica **sin `EP-XXX`**: la identidad la asigna el hub al aprobar (hub#113). `0` enviada · `5` encolada · `6` rechazada · `3` legacy/dual. Un `epic_code` en el borrador se **ignora**, no se rechaza |
-| `slice-ops.sh epic-status [--id P]` | `GET /projects/{id}/epic-proposals/{P}`. Resuelve el ciclo: `QUEUED` → `PROPOSED` → `APPROVED` (con `epic_code`) / `REJECTED`. Informativo: `rc 0` siempre en runtime |
+| `slice-ops.sh propose-epic --file B` | `POST /projects/{id}/agent/epic-proposals` (carril directo). Propone una épica **sin `EP-XXX`**: la identidad la asigna el hub al aprobar. `0` enviada · `5` encolada · `6` rechazada · `3` legacy/dual. Un `epic_code` en el borrador se **ignora**, no se rechaza. El identificador llega en `id` de `EpicProposalOut` |
+| `slice-ops.sh epic-status [--id P]` | `GET /projects/{id}/agent/epic-proposals/{P}`. Resuelve el ciclo: `QUEUED` → `PROPOSED` → `APPROVED` (código en `assigned_code`) / `REJECTED` (motivo en `reject_reason`). Informativo: `rc 0` siempre en runtime |
 | `slice-ops.sh epic-writeback [--id P] [--file F]` | — (local). Escribe en `docs/03-backlog/epicas.md` las épicas ya `APPROVED`, con el código del hub. Mecánico e idempotente: el fichero es proyección del grafo. `--file F` permite otro fichero del backlog (partido en varios), pero **F queda acotado al subárbol `docs/03-backlog/` del proyecto** —`realpath` sobre ambos lados, así que ni symlinks ni `..` escapan— porque los contactos de escritura del arnés en `docs/` son cuatro y acotados (METODOLOGIA §9.2) y este comando promete tocar solo el backlog. Fuera de ahí, `2` con la ruta permitida en el mensaje y **cero escritura**, exista el fichero o no. `0` escribió · `7` nada pendiente · `4` sin fichero · `2` `--file` fuera del carve-out |
 | `release-ops.sh verdict <line> <gate> <estado>` | `POST /releases/{line}/verdicts`; **sin fallback offline** (rc 5 y reintento al reconectar: el agregado `release` no entra por `POST /events`, issue #44) |
 | `release-ops.sh close-hint <line>` | **ninguna**: el cierre es humano, con PDP |
@@ -244,14 +244,27 @@ modo, valida en local lo que es barato validar y encola lo que no pudo entregar.
   "layer": "foundational|business|technical",
   "files_scope": ["…"],
   "depends_on": ["EP-012"],
-  "stories": [{"title": "…", "acceptance_criteria": "…"}]
+  "stories": [{"title": "…", "description": "…", "acceptance_criteria": "Dado … Cuando … Entonces …"}]
 }
 ```
 
 `title` y `objective` son obligatorios; `layer` por defecto `business` (rc 2 si no es una de las
 tres). Un `epic_code`/`code`/`id` en el borrador **se ignora con aviso**, no se rechaza la
-propuesta — la identidad la asigna el hub al aprobar (hub#113). El normalizador estampa
-`origin: "harness-draft"` antes de encolar.
+propuesta — la identidad la asigna el hub al aprobar.
+
+**El borrador NO es el payload** (issue #70). El normalizador traduce al contrato del agente
+(`EpicProposalIn`) antes de encolar, y esa traducción es la única superficie que conoce los dos
+vocabularios:
+
+| Borrador (lo que escribe el agente) | Contrato del hub |
+|---|---|
+| `layer: "foundational"` | `layer: "FOUNDATIONAL"` |
+| `layer: "business"` \| `"technical"` | `layer: "BUSINESS"` — el hub no tiene capa técnica; `technical` se **mapea**, no se rechaza |
+| `stories[].acceptance_criteria` (prosa) | `stories[].acceptance[]` — un escenario Dado/Cuando/Entonces por entrada (se parte por líneas y por el `. Dado ` que une dos escenarios). Una `acceptance[]` ya explícita en el borrador manda |
+| `stories[].description` | `stories[].description` (tal cual) |
+
+El hub descarta los campos que no reconoce (`extra="ignore"`): mandar `acceptance_criteria`
+**no da error**, simplemente llega una historia sin un solo criterio a la consola.
 
 **Códigos de salida** (contrato con la prosa): `0` ok · `2` uso · `3` modo legacy (o claim en dual)
 · `4` sin slice activo · `5` offline (encolado si el tipo tiene camino por la cola; si no, reintento manual al reconectar) · `6` rechazado por el servidor (no reintentar) ·

package/hooks/build/lib/runtime-ops.sh

@@ -112,8 +112,11 @@ ops_path_proposals() { echo "/projects/$1/context/agent-proposals"; }
 # (`EP-XXX`) al aprobar y un humano aprueba: por eso hay una ruta de creación y otra de
 # consulta, y ninguna de publicación. Mismo patrón que las propuestas de asset
 # (`ops_path_proposals`), que es su precedente en este cliente.
-ops_path_epic_proposals() { echo "/projects/$1/epic-proposals"; }
-ops_path_epic_proposal() { echo "/projects/$1/epic-proposals/$2"; }
+# [#70] El carril del AGENTE lleva `/agent/`: `/projects/{id}/epic-proposals` (sin él) es la
+# vista de CONSOLA — GET con JWT de usuario — y responde `405 Allow: GET` a un POST con token
+# de proyecto. Las dos superficies no se comparten por diseño (hub CON-1).
+ops_path_epic_proposals() { echo "/projects/$1/agent/epic-proposals"; }
+ops_path_epic_proposal() { echo "/projects/$1/agent/epic-proposals/$2"; }
 
 ops_mode() { runtime_mode; }
 

package/hooks/build/slice-ops.sh

@@ -485,8 +485,29 @@ _epic_draft_normalize() {
   # el motivo del rc 2 (validación) o el aviso de `epic_code` ignorado; silenciarlo aquí
   # los perdería a los dos.
   python3 - "$f" <<'PY'
-import json,sys
-CAPAS={"foundational","business","technical"}
+import json,re,sys
+# [#70] El vocabulario del BORRADOR (lo que escribe el agente) y el del CONTRATO del hub
+# (`EpicProposalIn`) no son el mismo: el borrador habla en minúsculas y conoce `technical`;
+# el hub solo acepta el literal FOUNDATIONAL|BUSINESS. La traducción vive aquí, en el borde,
+# porque rechazar `technical` sería castigar al agente por una distinción que el grafo no
+# hace: para el hub una épica técnica es de negocio.
+CAPAS={"foundational":"FOUNDATIONAL","business":"BUSINESS","technical":"BUSINESS"}
+
+def escenarios(txt):
+    """Criterios en prosa -> `acceptance[]` del contrato: un escenario Dado/Cuando/Entonces
+    por entrada. Se parte por líneas y, dentro de cada una, por el `. Dado ` que separa dos
+    escenarios seguidos en un mismo párrafo."""
+    out=[]
+    for linea in str(txt).splitlines():
+        linea=linea.strip().lstrip("-*•").strip()
+        if not linea:
+            continue
+        for trozo in re.split(r"\.\s+(?=Dado\s)", linea):
+            trozo=trozo.strip()
+            if trozo:
+                out.append(trozo[:2000])
+    return out[:20]
+
 try:
     d=json.load(open(sys.argv[1]))
 except Exception:
@@ -499,29 +520,77 @@ if not title:
     print("⛔ el borrador no trae `title` (título de la épica)", file=sys.stderr); raise SystemExit(2)
 if not objective:
     print("⛔ el borrador no trae `objective` (objetivo de la épica)", file=sys.stderr); raise SystemExit(2)
-layer=d.get("layer") or "business"
+layer=str(d.get("layer") or "business").strip().lower()
 if layer not in CAPAS:
     print("⛔ `layer` debe ser uno de: %s" % ", ".join(sorted(CAPAS)), file=sys.stderr); raise SystemExit(2)
 ignorados=[k for k in ("epic_code","code","id") if d.get(k)]
 stories=[]
 for s in d.get("stories") or []:
     if isinstance(s,str):
-        stories.append({"title":s})
+        stories.append({"title":s[:300]})
     elif isinstance(s,dict) and (s.get("title") or "").strip():
-        st={"title":s["title"].strip()}
-        if s.get("acceptance_criteria"):
-            st["acceptance_criteria"]=str(s["acceptance_criteria"])[:2000]
+        st={"title":s["title"].strip()[:300]}
+        if s.get("description"):
+            st["description"]=str(s["description"])[:2000]
+        # La `acceptance` explícita del borrador manda; si no, se derivan de los criterios en
+        # prosa. `acceptance_criteria` NO viaja: el hub descarta el campo en el borde
+        # (`extra="ignore"`) y la consola enseñaba las historias sin un solo criterio.
+        acc=s.get("acceptance")
+        if isinstance(acc,list):
+            acc=[str(x).strip()[:2000] for x in acc if str(x).strip()][:20]
+        elif s.get("acceptance_criteria"):
+            acc=escenarios(s["acceptance_criteria"])
+        else:
+            acc=[]
+        if acc:
+            st["acceptance"]=acc
         stories.append(st)
-out={"title":title[:300],"objective":objective[:2000],"layer":layer,
+out={"title":title[:300],"objective":objective[:2000],"layer":CAPAS[layer],
      "files_scope":[str(x) for x in (d.get("files_scope") or []) if isinstance(x,(str,int))],
      "depends_on":[str(x) for x in (d.get("depends_on") or []) if isinstance(x,(str,int))],
-     "stories":stories,"origin":"harness-draft"}
+     "stories":stories}
 if ignorados:
     print("IGNORADOS %s" % ",".join(ignorados), file=sys.stderr)
 print(json.dumps(out,ensure_ascii=False))
 PY
 }
 
+# [#70] `EpicProposalOut` del contrato nombra `id` al identificador de la propuesta (el
+# borrador de hub#113 lo llamaba `proposal_id`). Sin esto la terminal decía «sin identificador
+# en la respuesta» y el ledger guardaba "" — `epic-status` se quedaba sin a quién preguntar.
+# Se acepta el nombre viejo como respaldo: un hub anterior al contrato sigue funcionando.
+_epic_proposal_id() {
+  command -v python3 >/dev/null 2>&1 || { echo ""; return; }
+  printf '%s' "$1" | python3 -c '
+import json,sys
+try:
+    d=json.load(sys.stdin)
+    r=(d.get("response") if isinstance(d.get("response"),dict) else d) or {}
+    print(r.get("id") or r.get("proposal_id") or "")
+except Exception:
+    print("")
+' 2>/dev/null
+}
+
+# _epic_from_response <respuesta> — la épica aprobada como objeto para el ledger. El contrato
+# la devuelve en la RAÍZ de `EpicProposalOut`; el borrador viejo la anidaba en `epic`.
+_epic_from_response() {
+  command -v python3 >/dev/null 2>&1 || { echo "{}"; return; }
+  printf '%s' "$1" | python3 -c '
+import json,sys
+try:
+    d=json.load(sys.stdin)
+except Exception:
+    print("{}"); raise SystemExit(0)
+if not isinstance(d,dict):
+    print("{}"); raise SystemExit(0)
+e=d.get("epic")
+if not isinstance(e,dict):
+    e={k:d[k] for k in ("title","objective","layer","stories","files_scope","depends_on") if k in d}
+print(json.dumps(e,ensure_ascii=False))
+' 2>/dev/null || echo "{}"
+}
+
 cmd_propose_epic() {
   local file="" mode pid norm errf rc cid pfile ack proposal_id reason
   while [ $# -gt 0 ]; do
@@ -590,7 +659,7 @@ cmd_propose_epic() {
   runtime_dispatch_outbox >/dev/null 2>&1
   ack="$(ops_epic_ack_read "$cid")"
   if [ -n "$ack" ]; then
-    proposal_id="$(printf '%s' "$ack" | python3 -c 'import json,sys; print((json.load(sys.stdin).get("response") or {}).get("proposal_id") or "")' 2>/dev/null)"
+    proposal_id="$(_epic_proposal_id "$ack")"
     ops_epic_ledger_upsert "{\"client_event_id\":\"$cid\",\"status\":\"PROPOSED\",\"proposal_id\":$(ops_json_str "$proposal_id")}"
     echo "propuesta enviada: ${proposal_id:-sin identificador en la respuesta}"
     echo "Queda en PROPOSED: NO es reclamable hasta que un humano la apruebe en la consola del hub."
@@ -662,7 +731,7 @@ cmd_epic_status() {
     if [ "$st" = "QUEUED" ] && [ -n "$cid" ]; then
       ack="$(ops_epic_ack_read "$cid")"
       if [ -n "$ack" ]; then
-        pidv="$(printf '%s' "$ack" | python3 -c 'import json,sys; print((json.load(sys.stdin).get("response") or {}).get("proposal_id") or "")' 2>/dev/null)"
+        pidv="$(_epic_proposal_id "$ack")"
         st=PROPOSED
         ops_epic_ledger_upsert "{\"client_event_id\":\"$cid\",\"status\":\"PROPOSED\",\"proposal_id\":$(ops_json_str "$pidv")}"
       else
@@ -686,13 +755,18 @@ cmd_epic_status() {
           case "$st" in
             APPROVED)
               local code epic
-              code="$(_claim_field "$resp" epic_code)"
-              epic="$(printf '%s' "$resp" | python3 -c 'import json,sys; print(json.dumps(json.load(sys.stdin).get("epic") or {},ensure_ascii=False))' 2>/dev/null)"
+              # [#70] El código lo asigna el hub en `assigned_code` (EP-OR-15); `epic_code` era
+              # el nombre del borrador y se conserva como respaldo.
+              code="$(_claim_field "$resp" assigned_code)"
+              [ -n "$code" ] || code="$(_claim_field "$resp" epic_code)"
+              epic="$(_epic_from_response "$resp")"
               [ -n "$epic" ] || epic="{}"
               ops_epic_ledger_upsert "{\"client_event_id\":\"$cid\",\"status\":\"APPROVED\",\"epic_code\":$(ops_json_str "$code"),\"epic\":$epic}"
               echo "$pidv  APPROVED     $code — escríbela con \`slice-ops.sh epic-writeback\`" ;;
             REJECTED)
-              local why; why="$(_claim_field "$resp" reason)"
+              # [#70] El motivo del rechazo humano viaja en `reject_reason` (EP-OR-15).
+              local why; why="$(_claim_field "$resp" reject_reason)"
+              [ -n "$why" ] || why="$(_claim_field "$resp" reason)"
               ops_epic_ledger_upsert "{\"client_event_id\":\"$cid\",\"status\":\"REJECTED\",\"reason\":$(ops_json_str "$why")}"
               echo "$pidv  REJECTED     ${why:-sin motivo registrado}" ;;
             *)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trycore/spec-build-harness",
-  "version": "0.14.0",
+  "version": "0.14.2",
   "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": {

package/scripts/tests/test-skill-ops.sh

@@ -31,9 +31,11 @@ source "$ROOT/hooks/build/lib/runtime-ops.sh" 2>/dev/null || { echo "FAIL no exi
 [ "$(ops_path_front_integration f-1 ak-1)" = "/fronts/f-1/members/ak-1/integration" ] && echo "OK ops_path_front_integration" || { echo "FAIL ops_path_front_integration"; fail=1; }
 
 # [#62] Tabla de rutas de la propuesta de épica: un solo sitio donde se escriben rutas.
-[ "$(ops_path_epic_proposals p-1)" = "/projects/p-1/epic-proposals" ] \
+# [#70] El carril del AGENTE lleva `/agent/`: `/projects/{id}/epic-proposals` es la vista de
+# consola (GET, JWT de usuario) y devuelve 405 a un POST — el drift que rompió el piloto.
+[ "$(ops_path_epic_proposals p-1)" = "/projects/p-1/agent/epic-proposals" ] \
   && echo "OK ops_path_epic_proposals" || { echo "FAIL ops_path_epic_proposals"; fail=1; }
-[ "$(ops_path_epic_proposal p-1 prop-7)" = "/projects/p-1/epic-proposals/prop-7" ] \
+[ "$(ops_path_epic_proposal p-1 prop-7)" = "/projects/p-1/agent/epic-proposals/prop-7" ] \
   && echo "OK ops_path_epic_proposal" || { echo "FAIL ops_path_epic_proposal"; fail=1; }
 
 # [#62] Ledger: upsert por client_event_id, sin duplicar, conservando lo no mencionado.
@@ -1618,9 +1620,13 @@ runtime_credentials_merge "{\"runtime_url\":\"http://127.0.0.1:$PORT_GA\"}"
 # ══════════════ slice-ops.sh: propose-epic / epic-status / epic-writeback [#62] ══════════════
 # Stub PROPIO (puerto, routes-ep.json y calls-ep.jsonl): routes-cl.json/STUB_CL ya no existen
 # en este punto del fichero y mutarlos rompería aserciones aguas arriba.
+# [#70] Las rutas y los cuerpos de este bloque son los del CONTRATO DEL AGENTE del hub
+# (`contrato-agente-openapi.json`, EP-OR-14/EP-OR-15), no los del borrador de hub#113:
+# carril `/agent/…`, `layer` en MAYÚSCULAS (FOUNDATIONAL|BUSINESS), historias con
+# `description`+`acceptance[]`, y respuesta `{id, status, assigned_code, reject_reason}`.
 PORT_EP="$(freeport)"
 cat > "$TMP/routes-ep.json" <<JSON
-{"POST /projects/p-1/epic-proposals": {"status": 201, "body": {"proposal_id": "prop-77", "status": "PROPOSED"}}}
+{"POST /projects/p-1/agent/epic-proposals": {"status": 201, "body": {"id": "prop-77", "project_id": "p-1", "title": "Notificaciones en tiempo real", "objective": "que el usuario vea los avisos sin recargar", "layer": "BUSINESS", "stories": [], "files_scope": [], "depends_on": [], "status": "PROPOSED", "assigned_code": null, "reject_reason": null}}}
 JSON
 : > "$TMP/calls-ep.jsonl"
 python3 "$ROOT/scripts/tests/lib/http-stub.py" "$PORT_EP" "$TMP/routes-ep.json" "$TMP/calls-ep.jsonl" &
@@ -1634,7 +1640,8 @@ cat > "$TMP/draft.json" <<'JSON'
 {"title":"Notificaciones en tiempo real","objective":"que el usuario vea los avisos sin recargar",
  "layer":"business","files_scope":["src/notifications/**"],"depends_on":["EP-012"],
  "epic_code":"EP-999",
- "stories":[{"title":"ver el aviso","acceptance_criteria":"Dado … Cuando … Entonces …"}]}
+ "stories":[{"title":"ver el aviso","description":"Como usuario quiero ver el aviso sin recargar",
+             "acceptance_criteria":"Dado un aviso nuevo Cuando llega Entonces se ve. Dado un aviso leído Cuando entro Entonces no se repite"}]}
 JSON
 
 # legacy y dual: rc 3 sin efectos (ni cola, ni red).
@@ -1659,22 +1666,59 @@ out="$(bash "$SO" propose-epic --file "$TMP/draft.json" 2>&1)"; rc=$?
   && echo "OK propose-epic envia y devuelve el identificador" \
   || { echo "FAIL propose-epic online (rc $rc): $out"; fail=1; }
 
-# El EP-XXX del borrador se IGNORA (la identidad la asigna el hub, hub#113) — ignorar, no rechazar.
+# [#70] El cuerpo enviado valida contra `EpicProposalIn` del contrato del agente: `layer` en
+# MAYÚSCULAS, historias con `description`+`acceptance[]` y NUNCA `acceptance_criteria` (el
+# hub lo descarta en el borde con extra="ignore": la consola mostraba las HU sin criterios).
 body="$(python3 - "$TMP/calls-ep.jsonl" <<'PY'
 import json,sys
 for l in open(sys.argv[1]):
     d=json.loads(l)
-    if d["path"]=="/projects/p-1/epic-proposals":
-        b=json.loads(d["body"])
-        print("SI" if "epic_code" not in b and b.get("title","").startswith("Notificaciones") else "NO")
+    if d["path"]=="/projects/p-1/agent/epic-proposals":
+        b=json.loads(d["body"]); errores=[]
+        if b.get("layer")!="BUSINESS": errores.append("layer=%r" % b.get("layer"))
+        if "epic_code" in b: errores.append("viajo el epic_code del borrador")
+        if not b.get("title","").startswith("Notificaciones"): errores.append("title=%r" % b.get("title"))
+        s=(b.get("stories") or [{}])[0]
+        if "acceptance_criteria" in s: errores.append("la historia lleva acceptance_criteria")
+        if set(s)-{"title","description","acceptance","code","acceptance_ref"}:
+            errores.append("campos fuera del contrato: %s" % sorted(set(s)-{"title","description","acceptance","code","acceptance_ref"}))
+        if s.get("description")!="Como usuario quiero ver el aviso sin recargar":
+            errores.append("description=%r" % s.get("description"))
+        acc=s.get("acceptance")
+        if not isinstance(acc,list) or len(acc)!=2: errores.append("acceptance=%r" % acc)
+        elif not acc[0].startswith("Dado un aviso nuevo") or not acc[1].startswith("Dado un aviso leído"):
+            errores.append("escenarios mal partidos: %r" % acc)
+        print("SI" if not errores else "NO: "+" | ".join(errores))
         break
 PY
 )"
-[ "$body" = SI ] && echo "OK propose-epic ignora el EP-XXX del borrador" \
-  || { echo "FAIL el EP-XXX viajo al hub ($body)"; fail=1; }
+[ "$body" = SI ] && echo "OK el cuerpo de propose-epic valida contra el contrato del agente" \
+  || { echo "FAIL cuerpo de propose-epic ($body)"; fail=1; }
 echo "$out" | grep -qi 'ignorado' && echo "OK propose-epic avisa de que ignoro el codigo" \
   || { echo "FAIL sin aviso del codigo ignorado"; fail=1; }
 
+# [#70] `technical` no existe en el enum del hub (FOUNDATIONAL|BUSINESS): el 422 que devolvía
+# se evita mapeándolo a BUSINESS en el borde, no rechazando el borrador del agente.
+cat > "$TMP/draft-tech.json" <<'JSON'
+{"title":"Observabilidad","objective":"ver qué pasa en produccion","layer":"technical",
+ "stories":[{"title":"ver las trazas"}]}
+JSON
+: > "$TMP/calls-ep.jsonl"
+bash "$SO" propose-epic --file "$TMP/draft-tech.json" >/dev/null 2>&1
+tech="$(python3 - "$TMP/calls-ep.jsonl" <<'PY'
+import json,sys
+for l in open(sys.argv[1]):
+    d=json.loads(l)
+    if d["path"]=="/projects/p-1/agent/epic-proposals":
+        b=json.loads(d["body"])
+        s=(b.get("stories") or [{}])[0]
+        print("SI" if b.get("layer")=="BUSINESS" and "acceptance" not in s else "NO: layer=%r story=%r" % (b.get("layer"), s))
+        break
+PY
+)"
+[ "$tech" = SI ] && echo "OK layer technical viaja como BUSINESS y una historia sin AC no inventa acceptance" \
+  || { echo "FAIL mapeo de layer technical ($tech)"; fail=1; }
+
 # El ledger recuerda la propuesta con su borrador.
 ops_epic_ledger_read | python3 -c "
 import json,sys
@@ -1710,14 +1754,18 @@ out="$(bash "$SO" propose-epic --file "$TMP/malo.json" 2>&1)"
   || { echo "FAIL validacion local del borrador: $out"; fail=1; }
 
 # --- [#62] epic-status ---
+# [#70] La respuesta es `EpicProposalOut` del contrato: el código aprobado viaja en
+# `assigned_code` y la épica en la RAÍZ (no anidada en `epic`).
 python3 - "$TMP/routes-ep.json" <<'PY'
 import json,sys
 p=sys.argv[1]; d=json.load(open(p))
-d["GET /projects/p-1/epic-proposals/prop-77"]={"status":200,"body":{
-  "proposal_id":"prop-77","status":"APPROVED","epic_code":"EP-045",
-  "epic":{"title":"Notificaciones en tiempo real","objective":"que el usuario vea los avisos sin recargar",
-          "layer":"business","depends_on":["EP-012"],
-          "stories":[{"code":"HU-310","title":"ver el aviso"}]}}}
+d["GET /projects/p-1/agent/epic-proposals/prop-77"]={"status":200,"body":{
+  "id":"prop-77","project_id":"p-1","status":"APPROVED","assigned_code":"EP-045",
+  "title":"Notificaciones en tiempo real","objective":"que el usuario vea los avisos sin recargar",
+  "layer":"BUSINESS","depends_on":["EP-012"],"files_scope":["src/notifications/**"],
+  "stories":[{"code":"HU-310","title":"ver el aviso","description":"Como usuario…",
+              "acceptance":["Dado un aviso nuevo Cuando llega Entonces se ve"],"acceptance_ref":None},],
+  "reject_reason":None}}
 json.dump(d,open(p,"w"))
 PY
 TRYCORE_RUNTIME_MODE=legacy bash "$SO" epic-status >/dev/null 2>&1
@@ -1733,20 +1781,38 @@ out="$(bash "$SO" epic-status 2>&1)"; rc=$?
   || { echo "FAIL epic-status (rc $rc): $out"; fail=1; }
 ops_epic_ledger_read | python3 -c "
 import json,sys
-p=json.load(sys.stdin)['proposals'][0]
-print('SI' if p['status']=='APPROVED' and p['epic_code']=='EP-045' and p['epic']['stories'][0]['code']=='HU-310' else 'NO')" \
+ps=json.load(sys.stdin)['proposals']
+p=[q for q in ps if q.get('proposal_id')=='prop-77'][0]
+print('SI' if p['status']=='APPROVED' and p['epic_code']=='EP-045' and p['epic']['stories'][0]['code']=='HU-310' and p['epic']['title'].startswith('Notificaciones') else 'NO')" \
   | grep -q SI && echo "OK epic-status guarda el codigo y el contenido aprobado" \
   || { echo "FAIL el ledger no recogio la aprobacion"; fail=1; }
 
+# [#70] El rechazo humano viaja en `reject_reason` (EP-OR-15): sin leerlo, la terminal decía
+# "sin motivo registrado" y el usuario no sabía qué corregir.
+python3 - "$TMP/routes-ep.json" <<'PY'
+import json,sys
+p=sys.argv[1]; d=json.load(open(p))
+d["GET /projects/p-1/agent/epic-proposals/prop-88"]={"status":200,"body":{
+  "id":"prop-88","project_id":"p-1","status":"REJECTED","assigned_code":None,
+  "title":"Otra","objective":"otra cosa","layer":"BUSINESS","depends_on":[],"files_scope":[],
+  "stories":[],"reject_reason":"se solapa con EP-012"}}
+json.dump(d,open(p,"w"))
+PY
+ops_epic_ledger_upsert '{"client_event_id":"cid-r","proposal_id":"prop-88","status":"PROPOSED"}'
+out="$(bash "$SO" epic-status --id prop-88 2>&1)"; rc=$?
+[ $rc -eq 0 ] && echo "$out" | grep -q 'se solapa con EP-012' \
+  && echo "OK epic-status muestra el motivo del rechazo humano" \
+  || { echo "FAIL motivo del rechazo (rc $rc): $out"; fail=1; }
+
 # Un hub sin soporte (404) se dice con esas palabras y NO rompe nada.
 python3 - "$TMP/routes-ep.json" <<'PY'
 import json,sys
 p=sys.argv[1]; d=json.load(open(p))
-d.pop("GET /projects/p-1/epic-proposals/prop-77",None)
+d.pop("GET /projects/p-1/agent/epic-proposals/prop-77",None)
 json.dump(d,open(p,"w"))
 PY
 ops_epic_ledger_upsert '{"client_event_id":"cid-x","proposal_id":"prop-77","status":"PROPOSED"}'
-out="$(bash "$SO" epic-status 2>&1)"; rc=$?
+out="$(bash "$SO" epic-status --id prop-77 2>&1)"; rc=$?
 [ $rc -eq 0 ] && echo "$out" | grep -qi 'sin soporte' \
   && echo "OK epic-status nombra la falta de soporte del hub" \
   || { echo "FAIL epic-status con 404 (rc $rc): $out"; fail=1; }