@trycore/spec-build-harness 0.15.0 → 0.16.0

package/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "trycore-spec-build-harness",
   "displayName": "Trycore — Spec & Build Harness",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Arnés de construcción de dos loops (slice por épica + release gate) para Claude Code, con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "author": {
     "name": "Trycore",

package/GOVERNANCE.md

@@ -8,7 +8,7 @@ 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 (modo `legacy`, default) | `build-state.json` (+schema, README) | `.claude/state/` |
-| Cliente runtime (modo `dual`/`runtime`, opt-in — beta) | `runtime.credentials` (0600), `context.lock`, `runtime-projection.json`, `outbox/`; `slice-ops.sh`/`release-ops.sh` (13 subcomandos) | `.claude/state/`, `.claude/hooks/build/` |
+| Cliente runtime (modo `dual`/`runtime`, opt-in — beta) | `runtime.credentials` (0600), `context.lock`, `runtime-projection.json`, `outbox/`; `slice-ops.sh`/`release-ops.sh` (20 + 3 subcomandos) | `.claude/state/`, `.claude/hooks/build/` |
 | Agentes | 14 agentes de build | `.claude/agents/build/` |
 | Hooks | settings.json + 19 scripts (15 registrados + 4 invocados: `reconcile-build-state.py`, `context-sync.sh`, `heartbeat.sh` como daemon, `statusline-bridge.sh` como comando `statusLine`) | `.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) · `prototyping-screens` (prototipo HTML de referencia) | `.claude/skills/` |

package/INSTALL.md

@@ -107,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/` (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/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (14 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`, `/build:graph-sync`). Los cinco últimos son la **superficie de agente del modo runtime** (§9): en `legacy`, `claim`, `escalate`, `epic` y `graph-sync` 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;

package/METODOLOGIA.md

@@ -332,15 +332,26 @@ worktree— y coordina la selección, la construcción y el merge desde el estad
 (`parallel_front`). Es un concepto de **outer-loop**: no es una fase nueva del pipeline por-épica, es
 orquestación **entre** épicas.
 
+**Compuerta cero: un agente por worktree, un token por agente.** En modo `runtime`, cada worktree
+se da de alta como **agente propio** con un token que el ADMIN emitió **para él**
+(`slice-ops.sh register`, que lo pide por stdin). No es un trámite: el hub deriva el `agent_key`
+del `agent_id` grabado en el token, así que dos worktrees con el mismo token son **un solo agente**
+y el segundo `claim` devuelve el slice del primero. Y un worktree **sin** credenciales propias no
+queda huérfano — hereda las del clon principal y **suplanta** a ese agente. Por eso toda escritura
+desde un árbol sin identidad propia aborta con `rc 9` (issue #74).
+
 **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.
+2. **Disjunción por `files_scope` y por el grafo (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: el script la serializa (fail-closed). Tampoco son paralelizables dos épicas unidas por
+   un camino en el DAG de `depends_on`, aunque sus ficheros sean disjuntos — la de abajo
+   construiría sobre lo que la de arriba todavía no ha mergeado.
 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

package/README.md

@@ -121,14 +121,21 @@ Cuando hay **≥ 2 épicas de negocio (`layer: business`)** listas (DoR pasado)
 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:
+front (más una compuerta cero, de identidad, cuando se corre contra el hub):
 
+0. **Un agente por worktree, un token por agente** (modo `runtime`). Cada árbol se da de alta con
+   `slice-ops.sh register` y un token que el ADMIN emitió **para él**: el hub deriva el `agent_key`
+   del token, así que dos worktrees con el mismo token son un solo agente. Un árbol sin dar de alta
+   hereda las credenciales del clon principal y lo suplantaría — por eso toda escritura desde él
+   aborta con `rc 9`.
 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.
+2. **Disjunción por `files_scope` y por el grafo.** `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. Sin `files_scope` declarado una
+   épica **no es candidata** (se serializa), y dos épicas unidas por un camino en el DAG de
+   `depends_on` tampoco van juntas aunque sus ficheros sean disjuntos.
 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
@@ -144,7 +151,7 @@ trycore-spec-build-harness/
 ├── agents/build/              ← 14 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← 13 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front, claim, status, escalate, epic)
+│   └── build/                 ← 14 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, resume, front, claim, status, escalate, epic, graph-sync)
 ├── 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
@@ -184,7 +191,36 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 
 ## Roadmap
 
-- ✅ **v0.14.0 (actual) — contexto vivo, épicas propuestas y versión de grafo** (#61, #62, #63) —
+- ✅ **v0.16.0 (actual) — identidad por árbol de trabajo** (#74) — construir dos épicas en paralelo
+  en la misma máquina, una por `git worktree`, ya es una operación segura. El reparto nunca fue el
+  problema del hub —ya entrega dos épicas a dos agentes sin objeción—: el bloqueo estaba en el
+  cliente. El estado del arnés está en `.gitignore` y no viaja a un worktree, así que el árbol nuevo
+  **heredaba en silencio** las credenciales del clon principal y lo suplantaba: reclamaba con su
+  `agent_key`, reportaba los sha del árbol equivocado (cegando la detección de drift justo en el
+  escenario paralelo) y compartía su heartbeat. Ahora toda **escritura** desde un árbol sin dar de
+  alta aborta con **`rc 9`** antes de abrir un socket (las lecturas siguen, y `status` avisa con
+  `identidad: ⚠ HEREDADA`), y el alta es explícita: **`slice-ops.sh register`**, con el token por
+  **stdin** —nunca por argumento—, siembra local antes de tocar la red, verificación de que el
+  `agent_key` **difiera** del principal y rollback total ante cualquier fallo. Dato que corrige la
+  documentación anterior: `POST /agents/register` **no crea identidad** —el `agent_key` es el
+  `agent_id` grabado en el token por el ADMIN—, así que es **un token por agente**, no uno por
+  proyecto. Además, `front-plan.py` cierra tres fallos silenciosos: `layer` normalizado (el bundle
+  del grafo emite `FOUNDATIONAL` y la exclusión foundational-first podía no disparar),
+  **fail-closed** sin `files_scope` declarado, y serialización de los pares con camino en el DAG de
+  `depends_on`.
+- ✅ **v0.15.0 — el arnés propone el re-sync de su grafo** (EP-OR-17) — el grafo del hub se sembraba
+  una vez, con el import de admin de `/build:onboard`, y ahí se quedaba: las épicas que discovery
+  escribía después no tenían por dónde entrar y **todos** los eventos de un slice cuya épica falta
+  rebotan. Comando **`/build:graph-sync`** (+ `--check`) y subcomandos `graph-sync`/
+  `graph-sync-status`: el arnés construye el bundle desde los docs, el hub calcula el delta y un
+  **humano aprueba** en la consola — nada se aplica sin esa aprobación; tras ella, las historias
+  nuevas entran solas al reparto del claim. `client_event_id` determinista para que el reintento
+  deduplique en vez de dejar dos propuestas del mismo grafo esperando. En el camino, dos defectos
+  vivos desde antes: el `409` se leía en la raíz y con un nombre que no existe en el backend (el
+  claim no reintentaba ante grafo rancio ni ante drift), y el **espejo del modo `dual` era un 422 el
+  100 % de las veces** (mandaba un cuerpo que el contrato no tiene). Total: **14 comandos
+  `/build:*`**.
+- ✅ **v0.14.0 — 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

package/VERSION

@@ -1 +1 @@
-0.15.0
+0.16.0

package/agents/build/build-orchestrator.md

@@ -23,6 +23,9 @@ Eres el único que reporta gates y transiciona fases; los reviewers solo emiten
 ## Coexistencia con el front paralelo (outer-loop)
 Si hay un front paralelo abierto, el paralelismo lo gobierna la skill
 `managing-parallel-front`; cada worktree corre su propio inner loop con `active_slice` singular.
+En modo `runtime`, cada worktree es además un **agente propio** con su token del ADMIN (alta con
+`slice-ops.sh register`): si un árbol no está dado de alta, sus escrituras salen con `rc 9` porque
+estaría operando con la identidad del clon principal — eso se arregla registrando, no reintentando.
 **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.
 

package/commands/build/front.md

@@ -1,6 +1,6 @@
 ---
 name: "BUILD: Front"
-description: Prepara y coordina un front paralelo de épicas NO fundacionales y disjuntas en archivos, cada una en su worktree/rama/PR con su propio agente registrado. Delega en la skill managing-parallel-front (selección disjunta local vía scripts/lib/front-plan.py, worktrees, merge en orden con re-smoke reportado por cada worktree). Planificar, abrir, drenar y cerrar el front son actos humanos en la consola.
+description: Prepara y coordina un front paralelo de épicas NO fundacionales y disjuntas en archivos, cada una en su worktree/rama/PR con su propio agente registrado (un token por agente, alta con slice-ops.sh register). Delega en la skill managing-parallel-front (selección disjunta local vía scripts/lib/front-plan.py, worktrees, merge en orden con re-smoke reportado por cada worktree). Planificar, abrir, drenar y cerrar el front son actos humanos en la consola.
 category: Workflow
 tags: [build-harness, outer-loop, front-paralelo, trycore]
 ---
@@ -10,11 +10,15 @@ tags: [build-harness, outer-loop, front-paralelo, trycore]
 Delega en la skill **managing-parallel-front**. Resumen:
 1. Verifica precondiciones (scaffold confirmado; sin épica foundational abierta) con
    `bash .claude/hooks/build/slice-ops.sh status`.
-2. Reúne candidatas no fundacionales listas (DoR pasado) con `layer` y `files_scope`.
+2. Reúne candidatas no fundacionales listas (DoR pasado) con `layer`, `files_scope` y
+   `depends_on`. Sin `files_scope` declarado la épica **no es candidata** (se serializa).
 3. Propón el conjunto disjunto y el `merge_order` (`scripts/lib/front-plan.py`, local) y
    **preséntaselo a una persona**: abrir el front es acto de gobierno, en la consola del hub.
-4. Un worktree por épica aprobada, cada uno registrado como **agente propio**
-   (`trycore-build init` con el mismo token de proyecto); construye con `/build:slice`.
+4. Un worktree por épica aprobada, cada uno dado de alta como **agente propio** con **su
+   propio token** emitido por el ADMIN: `trycore-build init` (sin `--runtime-token`) y luego
+   `bash .claude/hooks/build/slice-ops.sh register` (pide el token por stdin). Sin ese alta,
+   toda escritura desde el worktree sale con **rc 9**: estaría suplantando al clon principal.
+   Después, construye con `/build:slice`.
 5. Tras cada merge, re-smoke y reporte desde el worktree:
    `bash .claude/hooks/build/release-ops.sh front-integration <front_id> --merge-status … --resmoke …`.
 

package/docs/commands.md

@@ -121,7 +121,7 @@ El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y
 
 | 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`. |
+| `/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`, que serializa también las candidatas sin `files_scope` declarado y los pares con camino en el DAG de `depends_on`) y mergea en orden con re-smoke. En modo `runtime`, **cada worktree se da de alta como agente propio** con su token del ADMIN (`slice-ops.sh register`): sin ese alta, toda escritura desde el árbol sale con `rc 9` porque estaría firmando con la identidad del clon principal. Úsalo solo con ≥2 épicas no fundacionales disjuntas listas; para una sola épica, usa `/build:slice`. |
 
 ### `/build:prototype` — prototipo HTML de referencia (fuente de diseño)
 
@@ -134,6 +134,14 @@ El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y
 Adaptadores delgados sobre `slice-ops.sh`; en modo `legacy` (default) devuelven `rc 3` y remiten al
 protocolo del fichero (`/build:slice`) — no rompen el flujo normal si el proyecto no está migrado.
 
+> **Un árbol de trabajo, un agente.** Estos comandos operan con la identidad de
+> `.claude/state/runtime.credentials`. Ese fichero está en `.gitignore` y **no viaja** a un
+> `git worktree`, así que un árbol nuevo hereda la del clon principal y lo suplantaría: por eso
+> toda **escritura** desde un árbol sin dar de alta aborta con **`rc 9`**. El alta no es un slash
+> command —pide el token por stdin y necesita un terminal humano—: se corre una vez por worktree
+> con `bash .claude/hooks/build/slice-ops.sh register`. Ver
+> [guía runtime → «Varios agentes en la misma máquina»](runtime/guia-modo-dual-y-migracion.md).
+
 | Slash command | Propósito |
 |---|---|
 | `/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). |

package/docs/getting-started.md

@@ -56,7 +56,7 @@ 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:*`** + **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.
+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:*`** + **14 comandos `/build:*`** (`onboard`, `reflect`, `architect`, `prototype`, `slice`, `release`, `work`, `resume`, `front` + `claim`, `status`, `escalate`, `epic`, `graph-sync`, 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.
 

package/docs/hooks.md

@@ -1,6 +1,6 @@
 # Hooks del arnés de construcción
 
-Este documento describe los **19 hooks** que `@trycore/spec-build-harness` instala en el proyecto del consumidor. Todos viven en `hooks/build/` (un script bash o python por hook, más los helpers compartidos `lib/state-io.sh`, `lib/config.sh`, `lib/runtime-client.sh`, `lib/runtime-ops.sh`, `lib/agent-context.sh`, `lib/projection.sh`) y se cablean a los eventos de Claude Code mediante una **cadena de comando única**, idéntica en ambos canales de instalación.
+Este documento describe los **19 hooks** que `@trycore/spec-build-harness` instala en el proyecto del consumidor. Todos viven en `hooks/build/` (un script bash o python por hook, más los helpers compartidos `lib/state-io.sh`, `lib/config.sh`, `lib/runtime-client.sh`, `lib/runtime-ops.sh`, `lib/agent-context.sh`, `lib/projection.sh`, `lib/harness-meta.sh`) y se cablean a los eventos de Claude Code mediante una **cadena de comando única**, idéntica en ambos canales de instalación.
 
 Los hooks son el sistema nervioso del arnés: vigilan GitFlow, el stack declarado, el scaffold y la fuente de diseño (bloqueantes), inyectan y re-anclan el estado del build al iniciar la sesión, delegan estilo/typecheck a herramientas, vigilan la presión de contexto y escriben handoff automático, y recuerdan validar trazabilidad, gates abiertos, reflexionar al cerrar un slice y correr el Release Gate cuando se acumulan épicas sin auditar. No reemplazan a los agentes ni a las skills; los **complementan** liberando capacidad de razonamiento del modelo y poniendo barandillas mecánicas donde un olvido cuesta caro.
 
@@ -41,7 +41,9 @@ Los hooks son el sistema nervioso del arnés: vigilan GitFlow, el stack declarad
 >
 > `lib/state-io.sh` (`legacy`), `lib/config.sh` (`runtime.mode`, umbrales), `lib/runtime-client.sh`
 > (cliente HTTP + cola offline), `lib/runtime-ops.sh` (helpers de `slice-ops.sh`/`release-ops.sh`),
-> `lib/agent-context.sh` (normaliza `GET /agent/context`) y `lib/projection.sh` (lee esa caché,
+> `lib/agent-context.sh` (normaliza `GET /agent/context`), `lib/harness-meta.sh` (versión del arnés
+> y catálogo de asset types, compartidos por el registro de sesión y el alta de un worktree) y
+> `lib/projection.sh` (lee esa caché,
 > sin red) **no son hooks**: son los helpers compartidos que los scripts de arriba `source`an.
 
 ---

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

@@ -120,12 +120,13 @@ arman peticiones a mano. En `dual`, cada transición también se **espeja** al s
 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 **19 subcomandos** (los conducen las skills; los listamos para que puedas
-leer un log o depurar, no para que los teclees):
+`slice-ops.sh` tiene **20 subcomandos** (los conducen las skills; los listamos para que puedas
+leer un log o depurar, no para que los teclees — `register` es la excepción: ese lo tecleas tú):
 
 | Subcomando | Para qué |
 |---|---|
 | `mode` | imprime `legacy`\|`dual`\|`runtime` |
+| `register` | da de alta **este árbol de trabajo** como agente propio, con su token (lo pide por stdin). Solo hace falta en un `git worktree` — ver «Varios agentes en la misma máquina» |
 | `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) |
@@ -142,7 +143,47 @@ leer un log o depurar, no para que los teclees):
 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 · `8` tipo no espejable.
+`4` sin slice · `5` offline · `6` rechazado · `7` sin trabajo · `8` tipo no espejable ·
+`9` identidad heredada (este árbol no está dado de alta — ver abajo).
+
+### Varios agentes en la misma máquina (0.16.0)
+
+Si abres un `git worktree` por épica para construir en paralelo (`/build:front`), **cada árbol
+necesita su propio token de agente**, emitido por el ADMIN para él. No es burocracia:
+
+- El hub **no crea identidad** al registrar. El `agent_key` es el `agent_id` que va grabado en el
+  token, así que dos árboles con el mismo token son **un solo agente** — y el segundo `claim` te
+  devuelve el slice que ya tiene reclamado el primero.
+- El estado del arnés está en `.gitignore` y **no viaja** al worktree. Sin credenciales propias, el
+  árbol nuevo hereda las del clon principal y **suplanta** a ese agente: reclamaría con su
+  `agent_key`, reportaría los hashes del árbol equivocado y compartiría su heartbeat.
+
+Por eso, en un árbol sin dar de alta, **toda escritura** (`claim`, `phase`, `gate`, `submit`,
+`archive`, `wiring`, `progress`, `checkpoint`, `fact`, `propose-*`, `graph-sync`, `escalate` y
+`release-ops.sh front-integration`) aborta con `rc 9` **antes de tocar la red**. Las lecturas siguen
+funcionando —son el diagnóstico de ese árbol— y `status` lo dice en su primera línea:
+
+```
+identidad:    ⚠ HEREDADA del clon principal (/ruta/al/clon) — solo lectura
+```
+
+El alta es un comando, en el terminal, una vez por worktree:
+
+```bash
+cd .wt/ep-003
+trycore-build init                                   # tiende .claude/ (sin --runtime-token)
+bash .claude/hooks/build/slice-ops.sh register       # pide el token por stdin
+```
+
+`register` **no acepta el token por argumento** (`--token` sale con `rc 2`): en argv quedaría en el
+historial del shell y en `ps`. Por lo mismo lo corres tú y no un hook — las tool calls no tienen
+TTY. Antes de tocar la red siembra el fichero local (si no, el registro habría escrito sobre las
+credenciales del clon principal), y después verifica contra el hub que el `agent_key` obtenido
+**difiere** del suyo; si coincide, lo rechaza y te dice que pidas al ADMIN un token con `agent_id`
+distinto. Ante cualquier fallo revierte: el árbol queda con identidad propia y verificada, o
+exactamente como estaba. El fichero del clon principal no se toca nunca.
+
+Para rotar el token de un árbol ya registrado: `register --force`.
 
 ### Qué espeja el modo `dual` — y qué no (0.15.0)
 

package/docs/runtime/protocolo-cliente-runtime.md

@@ -9,6 +9,11 @@
 - **Token de proyecto:** emitido por un ADMIN en el hub, entregado al desarrollador, configurado una vez con `trycore-build init --runtime-url --runtime-token` (se guarda en `.claude/state/runtime.credentials`, `0600`, sembrado en `.gitignore` por `init`). Todas las llamadas: `Authorization: Bearer <token>`.
 - **Registro:** `POST /agents/register {harness_version, asset_types}` → el servidor responde `{agent_key, project_id, harness_version, poll_interval_s, lease_ttl_s, manifest_hash, catalog{…}}`; el cliente (`runtime_register`) persiste hoy solo `agent_key`, `project_id`, `poll_interval_s`, `lease_ttl_s` y `manifest_hash` — `catalog` (tipos de asset) todavía no se persiste (el cliente ya envía `asset_types` desde `.claude/asset-types.json`, pero no consume el `catalog` de vuelta), `harness_version` no se re-persiste (ya se conoce localmente). Los intervalos los dicta el servidor (el cliente no los hardcodea). `409 incompatible_version` ⇒ mensaje claro con la versión mínima requerida (cuerpo `{error, min_version}`).
 - **Identidad local:** `agent_key`/`project_id` persisten en `.claude/state/runtime.credentials` (`0600`, protegido en `.gitignore` desde el primer `init`); un mismo clon re-registrado reactiva su agente (no crea otro): `runtime_register` hace upsert sobre el fichero existente, nunca lo recrea desde cero.
+- **Un token = un agente.** `POST /agents/register` **no crea identidad**: el `agent_key` es el `agent_id` que el ADMIN grabó en el token al emitirlo. Dos árboles con el mismo token son **el mismo agente** para el hub, y el segundo `claim` devuelve el slice que ya tiene reclamado el primero. Para dos agentes hacen falta **dos tokens**.
+- **Identidad por árbol de trabajo (`git worktree`, issue #74).** El estado del arnés está en `.gitignore` y **no viaja** a un `git worktree add`. `config_root()` cae entonces al clon principal (`--git-common-dir`) para que el árbol nuevo no quede huérfano de contexto — pero ese fallback vale para **leer**, no para **escribir**: sin credenciales propias, el worktree firmaría cada acto con el `agent_key` del clon principal, reportaría los hashes del árbol equivocado y compartiría su heartbeat. Por eso:
+  - Toda operación de **escritura** (`slice-ops.sh claim|phase|gate|submit|archive|wiring|progress|checkpoint|fact|propose-asset|propose-epic|epic-writeback|graph-sync|escalate` y `release-ops.sh front-integration`) aborta con **rc 9** antes de tocar la red si la identidad es heredada.
+  - Las **lecturas** (`mode`, `next-step`, `status`, `epic-status`, `graph-sync-status`) conservan el fallback: son el diagnóstico del árbol que aún no se dio de alta. `status` lo encabeza con `identidad: ⚠ HEREDADA del clon principal … — solo lectura`.
+  - El alta es explícita: **`slice-ops.sh register`** (§10). Con ella, `ops_context_hashes`, el heartbeat, la outbox y los ledgers pasan a ser por-worktree solos — todos cuelgan de `config_root()`.
 
 ## 2. Mapeo hook → endpoint (la telemetría es del harness, no del modelo)
 
@@ -215,6 +220,7 @@ modo, valida en local lo que es barato validar y encola lo que no pudo entregar.
 | Comando | Superficie |
 |---|---|
 | `slice-ops.sh mode` | ninguna (lee `build-config.json`) |
+| `slice-ops.sh register [--runtime-url U] [--force]` | `POST /agents/register` con un token **propio de este árbol**. Da de alta un worktree como agente distinto (§1). El token entra por **stdin** (prompt si hay TTY), nunca por argumento —`--token` sale con rc 2— porque en argv queda en el historial del shell y en `ps`; por lo mismo es un comando de terminal humano y **no** se invoca desde dentro de un claim (los hooks no tienen TTY y un `read` colgaría la llamada). Orden obligado: siembra el fichero local **primero** (si no, el upsert caería sobre las credenciales del clon principal y le pisaría la identidad), registra, y **verifica que el `agent_key` obtenido difiera** del del principal. Cualquier fallo revierte: el árbol queda con identidad propia y verificada, o exactamente como estaba; el fichero del clon principal no se toca nunca. `0` alta (o ya registrado) · `2` uso · `5` sin red · `6` mismo agente que el principal / token rechazado |
 | `slice-ops.sh claim` | `POST /tasks/next` (§3); `--epic` falla explícito, rc 2 (no hay claim dirigido, §3.6) |
 | `slice-ops.sh next-step` | ninguna: lo **deriva el cliente** desde la caché de proyección |
 | `slice-ops.sh phase <to>` | evento(s) `phase_advanced {to}` en cadena (issue #52): el hub lleva la fase con orden ESTRICTO (`dor→change→red→green→refactor→smoke→api→data→dod→pr`, `domain.py` `PHASES`) y solo acepta la fase siguiente exacta. El cliente emite la cadena que falte desde la fase conocida (proyección ∪ `phase_advanced` pendientes en la cola) hasta `<to>`; idempotente (nada si ya está). `archived` no se reporta aquí (lo produce `archive`). Siempre por cola en `runtime` (tipo protegido de la cota: evictar un eslabón haría ilegal todo lo posterior); espejo en `dual` (`phase_advanced` ∈ `TIPOS_DE_ESPEJO`) |
@@ -235,6 +241,10 @@ modo, valida en local lo que es barato validar y encola lo que no pudo entregar.
 | `release-ops.sh close-hint <line>` | **ninguna**: el cierre es humano, con PDP |
 | `release-ops.sh front-integration <front>` | `POST /fronts/{id}/members/{agent_key}/integration`; **sin fallback offline** (rc 5: `front_integration_reported` no existe en el catálogo v2, issue #44) |
 
+**Códigos de salida.** `0` ok · `2` uso · `3` legacy · `4` sin slice · `5` offline · `6` rechazado ·
+`7` sin trabajo · `8` fuera del catálogo de espejo · **`9` identidad heredada** (#74: este árbol
+opera con las credenciales del clon principal; da de alta el worktree con `register`).
+
 **Forma del borrador de `propose-epic --file`:**
 
 ```json

package/hooks/build/lib/config.sh

@@ -16,23 +16,71 @@
 # Por eso, cuando el árbol actual no tiene estado, se cae al clon principal
 # (--git-common-dir), que es donde vive de verdad. Idempotente para un clon
 # normal: si el candidato ya tiene estado, se devuelve tal cual.
+#
+# [#74] Ese fallback vale para LEER, nunca para ESCRIBIR: quien vaya a transicionar algo
+# tiene que preguntar antes por `config_is_inherited_root` (más abajo) y abortar, o estará
+# operando con la identidad del clon principal sin saberlo.
 config_root() {
   local candidate
   candidate="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"
   [ -f "$candidate/.claude/state/runtime.credentials" ] && { echo "$candidate"; return; }
 
-  local common main
-  common="$(git -C "$candidate" rev-parse --git-common-dir 2>/dev/null)" || common=""
-  if [ -n "$common" ]; then
-    case "$common" in /*) ;; *) common="$candidate/$common" ;; esac
-    main="$(cd "$common/.." 2>/dev/null && pwd)" || main=""
-    if [ -n "$main" ] && [ -f "$main/.claude/state/runtime.credentials" ]; then
-      echo "$main"; return
-    fi
+  local main
+  main="$(config_main_clone_root)"
+  if [ -n "$main" ] && [ -f "$main/.claude/state/runtime.credentials" ]; then
+    echo "$main"; return
   fi
   echo "$candidate"
 }
 
+# ── Identidad por árbol de trabajo [#74] ─────────────────────────────────────────────
+# El fallback de config_root es deliberado para LEER (un worktree sin estado propio sigue
+# viendo el contexto del proyecto), pero es veneno para ESCRIBIR: un worktree sin
+# credenciales propias impersona en silencio al agente del clon principal — reclama con su
+# `agent_key`, reporta los hashes de SU árbol (no del propio), comparte su heartbeat y, al
+# registrarse, le pisaría el fichero de credenciales. Estos tres helpers son la señal que
+# permite a las operaciones de escritura fallar rápido en vez de suplantar.
+
+# _config_phys <ruta> — forma FÍSICA de una ruta (resuelve symlinks). En macOS /var es un
+# symlink a /private/var: comparar rutas sin normalizar mide cómo se escribió el path, no a
+# qué apunta. Ante una ruta inaccesible devuelve la entrada tal cual — nunca lanza.
+_config_phys() {
+  (cd "$1" 2>/dev/null && pwd -P) || printf '%s\n' "$1"
+}
+
+# config_candidate_root — la raíz que corresponde a ESTE árbol de trabajo, SIN fallback:
+# `CLAUDE_PROJECT_DIR` o el toplevel del árbol actual. Es el otro extremo de la comparación
+# de identidad (config_root es «de quién es el estado que voy a usar»; esto es «dónde estoy»).
+config_candidate_root() {
+  local candidate
+  candidate="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"
+  _config_phys "$candidate"
+}
+
+# config_main_clone_root — raíz del clon principal según `--git-common-dir` ("" si no hay
+# git). En un clon normal coincide con el propio árbol; en un worktree apunta al clon que lo
+# creó. Es la única forma de leer la identidad del principal sin depender de config_root
+# (que es justo lo que puede estar heredado).
+config_main_clone_root() {
+  local candidate common main
+  candidate="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"
+  common="$(git -C "$candidate" rev-parse --git-common-dir 2>/dev/null)" || common=""
+  [ -n "$common" ] || { echo ""; return; }
+  case "$common" in /*) ;; *) common="$candidate/$common" ;; esac
+  main="$(cd "$common/.." 2>/dev/null && pwd -P)" || main=""
+  echo "$main"
+}
+
+# config_is_inherited_root — rc 0 si el estado que se va a usar NO es el de este árbol, es
+# decir: config_root cayó al clon principal. rc 1 en un clon normal, en un worktree ya
+# registrado y en un proyecto sin arnés (donde no hay identidad que heredar).
+config_is_inherited_root() {
+  local here there
+  here="$(config_candidate_root)"
+  there="$(_config_phys "$(config_root)")"
+  [ -n "$here" ] && [ -n "$there" ] && [ "$here" != "$there" ]
+}
+
 # config_get <clave.punteada> <default>
 config_get() {
   local key="$1" def="$2" file

package/hooks/build/lib/harness-meta.sh

@@ -0,0 +1,72 @@
+#!/usr/bin/env bash
+# harness-meta.sh — metadatos del PAQUETE instalado (versión del arnés y catálogo de asset
+# types). Extraído de session-start.sh [#74] para que `slice-ops.sh register` mande
+# exactamente el mismo `harness_version` que el registro de arranque de sesión: dos lecturas
+# distintas de la misma versión acabarían con un worktree rechazado por
+# `incompatible_version` y el clon principal aceptado, o al revés.
+# Fail-open, igual que config.sh: nunca lanza; sin fichero devuelve un valor neutro.
+
+source "$(dirname "${BASH_SOURCE[0]}")/config.sh"
+
+# harness_pkg_root — raíz del PAQUETE (no del proyecto). Los hooks se instalan como symlinks
+# por fichero (linkChildren), así que hay que resolver la cadena de enlaces a mano:
+# `readlink -f` no es portable al BSD readlink de macOS. Este fichero vive en
+# `<pkg>/hooks/build/lib/`, de ahí los tres niveles.
+harness_pkg_root() {
+  local src="${BASH_SOURCE[0]}" target i=0
+  while [ -L "$src" ] && [ "$i" -lt 10 ]; do
+    target="$(readlink "$src" 2>/dev/null)" || break
+    case "$target" in
+      /*) src="$target" ;;
+      *)  src="$(dirname "$src")/$target" ;;
+    esac
+    i=$((i + 1))
+  done
+  (cd "$(dirname "$src")/../../.." >/dev/null 2>&1 && pwd -P) 2>/dev/null
+}
+
+# harness_version — versión instalada en el consumidor; si no, la del paquete.
+# [#74] El marcador `.claude/.build-harness-version` está en .gitignore en modo symlink: NO
+# viaja a un `git worktree add`. Por eso se mira también el clon principal antes de caer al
+# paquete — un worktree recién dado de alta no tiene por qué mentir sobre su versión.
+harness_version() {
+  local f pkg root
+  for root in "$(config_root)" "$(config_candidate_root)" "$(config_main_clone_root)"; do
+    [ -n "$root" ] || continue
+    f="$root/.claude/.build-harness-version"
+    [ -f "$f" ] && { tr -d ' \n' < "$f"; return; }
+  done
+  pkg="$(harness_pkg_root)"
+  if [ -n "$pkg" ] && [ -f "$pkg/VERSION" ]; then
+    tr -d ' \n' < "$pkg/VERSION"
+    return
+  fi
+  echo "0.0.0"
+}
+
+# harness_asset_types — el array `types` de asset-types.json del paquete (protocolo §6).
+# Cadena de resolución: plugin > copia en .claude/ (la siembra es del sub-slice D) >
+# paquete resuelto por symlink. Sin fichero: "[]" — el registro sigue funcionando.
+harness_asset_types() {
+  local pkg candidates f
+  pkg="$(harness_pkg_root)"
+  candidates="${CLAUDE_PLUGIN_ROOT:-}/asset-types.json
+$(config_root)/.claude/asset-types.json
+${pkg:-}/asset-types.json"
+  while IFS= read -r f; do
+    case "$f" in /asset-types.json|asset-types.json) continue ;; esac
+    [ -f "$f" ] || continue
+    python3 - "$f" <<'PY' 2>/dev/null && return
+import json,sys
+try:
+    d=json.load(open(sys.argv[1]))
+    t=d.get("types")
+    print(json.dumps(t if isinstance(t,list) else [],ensure_ascii=False))
+except Exception:
+    raise SystemExit(1)
+PY
+  done <<EOS
+$candidates
+EOS
+  echo "[]"
+}

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

@@ -46,11 +46,39 @@ except Exception:
 PY
 }
 
+# runtime_credentials_field_at <fichero> <clave> — lee un campo de un fichero de credenciales
+# CONCRETO, sin pasar por config_root(). [#74] Es la única forma de mirar la identidad del clon
+# principal desde un worktree: `runtime_field` resuelve por config_root(), que es justo lo que
+# puede estar heredado — preguntarle «¿cuál es el agent_key del principal?» devolvía el propio.
+runtime_credentials_field_at() {
+  local file="$1" key="$2"
+  [ -f "$file" ] || { echo ""; return; }
+  command -v python3 >/dev/null 2>&1 || { echo ""; return; }
+  python3 - "$file" "$key" <<'PY' 2>/dev/null
+import json,sys
+file,key=sys.argv[1],sys.argv[2]
+try:
+    d=json.load(open(file))
+    v=d.get(key)
+    print(v if v is not None else "")
+except Exception:
+    print("")
+PY
+}
+
 # runtime_credentials_merge <json> — hace upsert de las claves del fragmento sobre el
 # fichero existente (o uno nuevo). Escritura atómica + chmod 0600. Nunca imprime el token.
 runtime_credentials_merge() {
-  local fragment="$1" file dir
-  file="$(runtime_credentials_path)"
+  runtime_credentials_merge_at "$(runtime_credentials_path)" "$1"
+}
+
+# runtime_credentials_merge_at <fichero> <json> — el mismo upsert sobre una RUTA EXPLÍCITA.
+# [#74] `register` tiene que sembrar el fichero del worktree ANTES de que exista, y por tanto
+# antes de que config_root() pueda anclar en local: pasando por runtime_credentials_path()
+# habría hecho merge del token nuevo sobre el fichero del clon principal, pisándole la
+# identidad al agente que está construyendo ahí.
+runtime_credentials_merge_at() {
+  local file="$1" fragment="$2" dir
   dir="$(dirname "$file")"
   mkdir -p "$dir"
   command -v python3 >/dev/null 2>&1 || return 1
@@ -78,6 +106,41 @@ except Exception:
 PY
 }
 
+# runtime_credentials_seed_at <fichero> <runtime_url> — siembra credenciales en una RUTA
+# EXPLÍCITA con el token tomado de `TRYCORE_REGISTER_TOKEN`. [#74] El token viaja por ENTORNO
+# y no por argv a propósito: `runtime_credentials_merge_at` recibe el fragmento como argumento
+# y en una máquina compartida un `ps` lo vería. Es el único camino por el que un secreto entra
+# de nuevo al fichero, así que es el único que necesita esta precaución.
+# Escribe un documento NUEVO, no un upsert: dar de alta un árbol es estrenar identidad, y
+# conservar el `agent_key` anterior haría que una respuesta 200 sin `agent_key` pareciera un alta
+# buena (`register --force` para rotar el token es justo el caso). Lo que el hub devuelva vuelve a
+# entrar por `runtime_register`. Escritura atómica + chmod 0600.
+runtime_credentials_seed_at() {
+  local file="$1" url="$2" dir
+  dir="$(dirname "$file")"
+  mkdir -p "$dir"
+  command -v python3 >/dev/null 2>&1 || return 1
+  python3 - "$file" "$url" <<'PY' 2>/dev/null || return 1
+import json,os,sys,tempfile
+path,url=sys.argv[1],sys.argv[2]
+tok=os.environ.get("TRYCORE_REGISTER_TOKEN","")
+if not tok:
+    raise SystemExit(1)
+d={"runtime_url":url,"project_token":tok}
+dirn=os.path.dirname(path) or "."
+fd,tmp=tempfile.mkstemp(dir=dirn,prefix=".runtime-credentials.",suffix=".tmp")
+try:
+    with os.fdopen(fd,"w") as out:
+        json.dump(d,out,indent=2,ensure_ascii=False); out.flush(); os.fsync(out.fileno())
+    os.chmod(tmp,0o600)
+    os.replace(tmp,path)
+except Exception:
+    try: os.unlink(tmp)
+    except OSError: pass
+    raise
+PY
+}
+
 runtime_url() {
   runtime_field runtime_url
 }

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

@@ -22,6 +22,31 @@ OPS_RC_OFFLINE=5
 OPS_RC_REJECTED=6
 OPS_RC_NO_WORK=7
 OPS_RC_NOT_MIRRORABLE=8
+OPS_RC_NO_IDENTITY=9
+
+# ── Guard de identidad heredada [#74] ────────────────────────────────────────────────
+# Un worktree sin `.claude/state/runtime.credentials` propio hereda el del clon principal por
+# el fallback de `config_root()`: lee bien, pero al ESCRIBIR suplanta — reclama con el
+# `agent_key` ajeno, reporta al hub los hashes del árbol equivocado y comparte su heartbeat.
+# El hub reparte dos épicas a dos agentes sin objeción; el bloqueo del multi-agente en una
+# misma máquina siempre estuvo aquí, en el cliente. Por eso el guard es fail-FAST y no
+# fail-open: la regla general de este cliente («ante la duda, no bloquees el trabajo local»)
+# protege del runtime caído, no de mandar actos firmados con la identidad de otro.
+#
+# ops_guard_own_identity <subcomando> — rc 0 si este árbol tiene identidad propia;
+# OPS_RC_NO_IDENTITY (9) con mensaje accionable si la heredó.
+ops_guard_own_identity() {
+  local sub="${1:-esta operación}" main
+  config_is_inherited_root || return 0
+  main="$(config_main_clone_root)"
+  echo "⛔ este worktree no tiene identidad propia: «${sub}» operaría como el agente del clon" >&2
+  echo "   principal (${main:-?}) — su agent_key, su lease, sus hashes de contexto." >&2
+  echo "   Da de alta este árbol con un token de agente NUEVO emitido por el ADMIN:" >&2
+  echo "     bash .claude/hooks/build/slice-ops.sh register" >&2
+  echo "   (el token se pide por stdin, nunca por argumento). Las lecturas — \`status\`," >&2
+  echo "   \`next-step\`, \`mode\` — siguen funcionando con el contexto heredado." >&2
+  return $OPS_RC_NO_IDENTITY
+}
 
 # Tope de texto libre que el cliente manda al servidor (evidencias, notas): el protocolo §8
 # dice que el servidor rechaza payloads sobredimensionados; se trunca aquí, marcándolo.