navori 0.11.1 → 0.11.3

package/README.md

@@ -77,9 +77,34 @@ No instala ni actualiza automáticamente y tampoco ejecuta `render`: después de
 actualizar navori, corre `navori render --apply` para aplicar los cambios a tu
 harness.
 
-Si un cierre abrupto deja bloqueado el aviso, detén primero todos los procesos
-`navori`. Después elimina únicamente `~/.navori/update-notice/lock`; conserva los
-archivos de caché y reserva de ese directorio.
+#### Avisos de actualización de herramientas de plugin
+
+Plugins como `engram` pueden declarar `latestRelease` en su manifest para recibir
+avisos cuando existe una versión más nueva. El aviso aparece al final del contexto de
+arranque, en un espacio reservado de 300 caracteres, una vez cada 24 h por versión.
+
+La consulta se ejecuta:
+- **Fuente**: `api.github.com/repos/<owner>/<repo>/releases/latest` o
+  `registry.npmjs.org/<package>/latest` (sin token, solo un User-Agent `navori/<version>`)
+- **Frecuencia**: máximo una solicitud por herramienta por día, reservada bajo un lock
+- **Red**: la carga de red ocurre en un worker detached en segundo plano; la sesión
+  nunca espera
+- **Caché**: `~/.navori/tool-versions/` (similar a `~/.navori/update-notice/`)
+- **CI**: sin red — ni refrescos ni avisos
+
+Desactívalo junto con el aviso de navori: `NAVORI_NO_UPDATE_NOTIFIER=1`.
+
+**Limitaciones:**
+- Codex en sandboxes sin red no obtiene refrescos ni avisos.
+- pi no tiene hooks de sesión: ahí los avisos solo aparecen en `navori doctor`.
+- Si el aviso no cabe en su reserva, se muestra un puntero a `navori doctor` y el aviso
+  se reintenta en la siguiente sesión (no se marca como entregado).
+- `doctor` muestra todos los avisos como filas informativas, sin aplicar `--strict`.
+
+Si un cierre abrupto deja bloqueado el aviso, solo intervendrás si el lock persiste
+más de un minuto. En ese caso, detén todos los procesos `navori` y elimina
+`~/.navori/tool-versions/lock` o `~/.navori/update-notice/lock`; conserva los archivos
+de caché de ambos directorios.
 
 ## Comandos
 
@@ -93,21 +118,23 @@ archivos de caché y reserva de ese directorio.
 | `update` | Re-detecta el repo, refresca config y corre sync en un paso |
 | `render` | Genera los archivos nativos de cada engine configurado (preview por default; `--apply` escribe). `--all` renderea todos los repos del registro global; `--prune` limpia los que ya no existen |
 | `registry <sub>` | Registro global de tus repos con navori, para `render --all` (`ls`, `scan <dir>`, `add`, `remove`, `prune`) |
-| `sync` | Refresca todos los engines configurados con conflict resolution + backups |
+| `sync` | Refresca todos los engines configurados con conflict resolution + backups. Los bloques en conflicto se resuelven con `--interactive` (diff, keep-mine / accept-new) o en bloque con `--accept-new` / `--keep-mine`. Los archivos completos sin marcador se resuelven archivo por archivo en modo interactivo (diff, keep / accept); `--accept-new-files` acepta en bloque los resolvibles |
 | `preset init <id>` | Scaffoldea un preset local en `.navori/presets/<id>/` |
 | `scan` | Detecta workspaces nuevos en monorepos (`pnpm-workspace.yaml` / `package.json#workspaces`) |
-| `doctor` | Audita el config + drift de cada managed block (CLAUDE.md **y AGENTS.md**), orden canónico, markers malformados, desincronización de monorepo y tools externas faltantes (`--strict` para CI) |
+| `doctor` | Audita el config + drift de cada managed block (CLAUDE.md **y AGENTS.md**), orden canónico, markers malformados, desincronización de monorepo y tools externas faltantes (`--strict` para CI). Informativo, sin afectar `--strict`: versiones instaladas con problema conocido (`externalTool.versionAdvisory`) y avisos de versiones nuevas de herramientas (`navori tools notice`) |
 | `status` | Snapshot rápido: config, plugins activos, conteo de drift y próximos pasos |
-| `audit` | Reporta cómo corrió el harness de verdad: atribución de tokens y huecos de adherencia en tus sesiones |
-| `receipt <sign\|check>` | Firma o verifica los bytes revisados antes de publicar un cambio (`navori receipt <sign\|check> --feature <id> [--target <ref>] [--dir <path>] [--json]`) |
+| `audit` | Reporta cómo corrió el harness de verdad: atribución de tokens, huecos de adherencia y outcomes de revisión y receipt; disponibilidad de herramientas por ventanas; eficiencia y ciclo de vida por tarea aceptada. `--snapshot` guarda una foto nombrada del rango y `--compare` la contrasta con otra por cohorte, con causas y evidencia |
+| `receipt <sub>` | Recibo de los bytes revisados antes de publicar: `sign` (`--feature <id>`, `--gate-ran scoped\|full`, `--spec <dir> --milestone <Mn>`), `check`, `gate --spec <dir> --milestone <Mn>` (decide si el milestone necesita el gate acotado o el completo) y `review begin` / `review seal --nonce <n>` (sidecar de revisión con identidad de contenido). Flags comunes: `--target <ref>`, `--dir <path>`, `--json` |
+| `spec <classify\|check> <feature>` | `classify` decide si una spec sale en 1 PR o en una PR por entrega (umbrales de `sdd.deliveries`); `check` valida su `tasks.md`: milestones, criterios, cobertura y entregas verticales. Flags: `--cwd`, `--json` |
+| `tools notice [--ack <pluginId@x.y.z,…>]` | Emite los avisos de versiones de herramientas externas pendientes para el hook de arranque; `--ack` los marca como entregados |
 | `handoff <check>` | Valida el handoff del implementer (`impl_<feature>.json`) antes de despachar al siguiente agente (`navori handoff check <feature> [--for scribe] [--dir <path>] [--cwd <checkout>] [--json]`) |
 | `plan <sub>` | Planificación por niveles (`harness.planTiers`): `classify [--files\|--diff]` mide complejidad y nivel de una tarea, `render`/`update` mantienen el workplan Markdown en sync con su JSON, `check` valida su esquema y reglas, `gate` es el hook `PreToolUse(Agent)` que niega el despacho sin workplan válido |
-| `master <sub>` | Flujo guiado del plan maestro por etapas (`init`, `mode`, `template`, `check`, `advance`, `status`, `part`, `close`) |
+| `master <sub>` | Flujo guiado del plan maestro por etapas (`init`, `ux`, `mode`, `template`, `check`, `advance`, `status`, `part`, `close`) y entregas de sus partes: `delivery-slice`, `delivery-check`, `delivery-baseline`, `delivery-queue`, `delivery-criterion`, `delivery-review`, `delivery-present`, `delivery-decision`, `delivery-publication`, `delivery-revoke`. Las que autorizan o aprueban llevan `--approved-by` |
 | `bench` | Corre `render` en dry-run N veces y reporta latencias (detecta regresiones locales) |
-| `workspace <sub>` | Gestiona workspaces cross-repo (`init`, `ls`, `show`, `rm`) |
+| `workspace <sub>` | Gestiona workspaces cross-repo (`init`, `ls`, `show`, `link`, `add-repo`, `set-default`, `render`, `rename`, `delete`) |
 | `ticket <sub>` | Gestiona tickets-as-files en un workspace (`new`, `list`, `show`, `archive`, `delete`) |
 | `dominio <sub>` | Base de conocimiento durable del workspace (`init`, `list`, `show`, `reindex`, `doctor`, `inject`) |
-| `global <sub>` | Harness base por máquina en `~/.claude` (`init`, `render`, `doctor`, `uninstall`) — opt-in explícito y aditivo |
+| `global <sub>` | Harness base por máquina en `~/.claude` (`init`, `render`, `doctor`, `uninstall`) — opt-in explícito y aditivo. `global collect install` / `uninstall` gestionan el receptor OTel que alimenta `audit --collect` (launchd, solo macOS) |
 | `codex <sub>` | Comandos específicos de Codex; hoy `trust` aprueba los hooks del proyecto en `~/.codex/config.toml` |
 | `backup <sub>` | Lista y restaura backups de `~/.navori/backups/` |
 | `migrations <sub>` | Lista y restaura migraciones de `~/.navori/migrations/` |
@@ -177,7 +204,10 @@ Con `harness.planTiers: true` en `navori.config.json`, `navori plan classify` mi
 complejidad de una tarea (señales como dinero/credenciales/PII, dependencia nueva, migración de
 esquema, o tocar una ruta de `project.criticalPaths`) y la ubica en un nivel 0–3. El hook
 `PreToolUse(Agent)` (`navori plan gate`) niega el despacho de un subagente sin el workplan que su
-nivel exige, y escala la exigencia tras dos rechazos seguidos. `navori plan classify --diff`
+nivel exige, y escala la exigencia tras dos rechazos seguidos. Si `navori` falta o su build no tiene el
+subcomando `plan`, el hook no tiene veredicto y, en modos que muestran el prompt, pide
+confirmación en vez de dejarte sin salida (en `bypassPermissions`, `dontAsk` o `plan` sigue
+bloqueando). `navori plan classify --diff`
 corre el mismo clasificador contra `git diff --name-only <base>...HEAD` para avisar cuando el
 trabajo se salió del nivel que el workplan declaró.
 
@@ -190,12 +220,41 @@ El agente `architect` ya no tiene un flag `harness.architect` — renderiza siem
 que todavía trae `harness.architect` falla con un aviso de clave retirada en vez de ignorarla en
 silencio; `navori configure migrate` la quita.
 
+## Entregas de specs (`sdd.deliveries`)
+
+Una spec grande no tiene por qué salir en una sola PR. `navori spec classify <feature>` la mide
+contra los umbrales de `sdd.deliveries` en `navori.config.json` (`splitMinTasks`, `splitMinLoc`,
+`maxPrsPerSpec`; defaults 12 tareas, 1500 LOC estimadas y 4 PRs) y dice si sale en una PR o en una
+PR por entrega. `navori spec check` valida el `tasks.md` contra su gramática:
+
+- **`E<n>`**: entrega; una PR cada una.
+- **`M<n>`**: milestone; cada uno se verifica y se commitea por separado.
+- **`T<n>`**: tarea; declara los `R<n>` que cubre.
+
+El gate completo corre una vez por PR, no una vez por milestone; el gate por milestone lo decide
+`navori receipt gate`.
+
+## Harness de workspaces (`monorepo.workspaceHarness`)
+
+`monorepo.workspaceHarness` decide cuánto harness recibe cada workspace de un monorepo. Es un solo
+valor para todo el repo:
+
+- `minimal` (default): su archivo de contexto más las skills que la raíz no tiene ya. Una skill
+  idéntica a la de la raíz no se duplica.
+- `full`: todo, como antes de recortar.
+- `root`: solo su archivo de contexto (`CLAUDE.md`, y `AGENTS.md` bajo Codex). La raíz escribe las
+  skills de librería y de preset que declaran los workspaces.
+
+`navori doctor` trata `minimal` y `root` como harness recortado, y avisa si el valor es `full`.
+
 ## Harness defensivo (read-only por default)
 
 El harness que genera `navori` trae permisos seguros desde el arranque, para que tengas menos prompts en lo cotidiano sin bajar la guardia en lo peligroso:
 
 - **Las lecturas no piden confirmación**: `git status/diff/log/show`, `ls`, `cat`, `grep`, `Read`/`Glob`/`Grep`, etc. corren sin interrumpirte.
 - **Lo destructivo pide confirmación** (`ask`): `rm -rf`, `git push --force`, `git reset --hard`, `git clean -f`, `chmod -R`, …
+- **Descartar trabajo sin commitear se bloquea** (`guard-destructive`, `exit 2`, sin aprobación posible): `git reset --hard`, `git checkout -f`, `git checkout -- .` (o `git checkout .`), `git restore <rutas>` sin `--staged`, y `git clean -f` (sin `-n`). El bloqueo depende del estado: si el árbol está limpio, no hay nada que perder y el comando pasa. Si el directorio destino no se puede inspeccionar (variable, sustitución o ruta inexistente), también bloquea. El mensaje indica la ruta para hacerlo de forma segura.
+- **El `publisher` no reescribe historia**: tras un commit fallido no ejecuta `git reset` ni reescribe commits. Reporta con `git status` y `git log -1 --stat`, y la recuperación queda para el orquestador o el usuario.
 - **Lo catastrófico se rechaza** (`deny`): `rm -rf /`, `sudo rm`, `mkfs`, …
 - Un hook `guard-destructive` actúa como backstop adicional.
 

package/dist/assets/core/core-assets/agents/implementer.md

@@ -5,7 +5,7 @@ tools: Read, Write, Edit, Glob, Grep, Bash
 model: {{models.implementer}}
 effort: {{effort.implementer}}
 maxTurns: 160
-maxWords: 2433
+maxWords: 2448
 ---
 
 # Implementer Agent
@@ -41,7 +41,7 @@ You execute **a single** task from start to verification. You don't orchestrate,
    {{qualityGate.fast}}
    ```
 
-   If it fails: fix it and re-run. Don't return with red. You are the single owner of this gate run: never share it with another process, never poll `pgrep`/`ps` for it, and a timeout is never a success signal. If the gate can outlive the Bash timeout, follow `.claude/skills/verify-before-done/SKILL.md`'s subagent row: run its chained steps one by one in the foreground, never background them (no shell `&`, no `run_in_background`, no `Monitor`) — you won't be re-woken to read the result. If no chained step fits under any foreground timeout, stop and report `BLOCKED` instead of improvising a background wait. When you can't explain WHY it failed, apply `.claude/skills/debug-failure/SKILL.md` before touching anything — the size of the output is not the trigger, the missing root cause is, and a failure whose error stream you truncated away reads the same as one you understand. If your second fix attempt fails the same way, that same skill's hypothesis re-check governs instead of throwing a third patch.
+   If it fails: fix it and re-run. Don't return with red. You are the single owner of this gate run: never share it with another process, never poll `pgrep`/`ps` for it, and a timeout is never a success signal. If the gate can outlive the Bash timeout, follow `.claude/skills/verify-before-done/SKILL.md`'s subagent row: run its chained steps one by one in the foreground, never background them (<!-- navori:if-not onCodex -->no shell `&`, no `run_in_background`, no `Monitor`<!-- /navori:if-not --><!-- navori:if onCodex -->no shell `&`, no background execution<!-- /navori:if -->) — you won't be re-woken to read the result. If no chained step fits under any foreground timeout, stop and report `BLOCKED` instead of improvising a background wait. When you can't explain WHY it failed, apply `.claude/skills/debug-failure/SKILL.md` before touching anything — the size of the output is not the trigger, the missing root cause is, and a failure whose error stream you truncated away reads the same as one you understand. If your second fix attempt fails the same way, that same skill's hypothesis re-check governs instead of throwing a third patch.
 5. **UI**: for screen changes, the default evidence is the repo's tests plus a correct diff — **do NOT spin up a browser or dev server automatically**. Visual/browser validation is **optional and strictly on-request**: run it only when the user explicitly asks to check the UI in this prompt, and then drive the repo's browser-automation tool if one is set up (e.g. `playwright-cli`, whose installer ships its own skill).
 6. **No commits** without the `reviewer`'s approval. When you finish, <!-- navori:if-not scribeOwnsMarkdown -->write the report<!-- /navori:if-not --><!-- navori:if scribeOwnsMarkdown -->write your JSON evidence<!-- /navori:if --> and return the reference.
 <!-- navori:if planTiers -->

package/dist/assets/core/core-assets/agents/publisher.md

@@ -4,7 +4,10 @@ description: Drafts commits in the configured style and opens the PR with the re
 tools: Read, Glob, Grep, Bash
 model: {{models.publisher}}
 effort: {{effort.publisher}}
-maxWords: 3800
+# Spec 0044 T12 (R18, R19, R23, R26): added commit-only mode, spec delivery PR steps
+# (with Spec-Delivery, git merge-base check, Refs/Closes), and prTarget warning;
+# +~200 words measured. 4200 = 3987 actual + 5.3% margin.
+maxWords: 4200
 ---
 
 # Publisher Agent
@@ -103,7 +106,7 @@ For every live-file `DRIFT`, the JSON provides the approved blob and the exact i
 The PR gate is the FULL one, `{{qualityGate.full}}`, not `{{qualityGate.fast}}`. Which steps sit where is a per-project decision; don't assume the fast gate covers all full steps. Three paths:
 
 - **Reviewed:** the reviewer ran `{{qualityGate.full}}` green in Pass 2 (see `review_<feature>.md`). Skip re-running **only** when `navori receipt check` reports `"fresh":true`. The `quality-gate-pre-commit` hook re-runs `fast` on `git commit` and blocks if it fails. Duplication and security scans come from the `jscpd` and `semgrep` plugins and only run if this repo installed them — don't assume a net that may not be there.
-- **`"fresh":false`:** no trustworthy evidence — YOU run `{{qualityGate.full}}` green in pre-flight before `gh pr create`. Follow `.claude/skills/verify-before-done/SKILL.md`'s subagent row if it outlives the timeout.
+- **`"fresh":false` on `full` receipts:** no trustworthy evidence — YOU run `{{qualityGate.full}}` green in pre-flight before `gh pr create`. Follow `.claude/skills/verify-before-done/SKILL.md`'s subagent row if it outlives the timeout.
 - **Declared inline (no reviewer):** no review evidence either — run `{{qualityGate.full}}` yourself.
 
 Never open the PR with the gate red.
@@ -119,9 +122,13 @@ Never open the PR with the gate red.
 4. If you touch potentially sensitive files (`.env*`, credentials, odd lockfiles), **flag the user before staging**.
 5. `git add <files>` (prefer explicit over `git add -A`).
 6. `git commit -m "..."` with a HEREDOC for the body if applicable.
-7. Validate with `git status` that the commit landed. Foreign modified files are reported as an observation and never discarded, restored or reverted.
+7. Validate with `git status` that the commit landed. If it failed, stop with `git status` + `git log -1 --stat`; recovery is the orchestrator's or the user's call. Foreign modified files are reported as an observation and never discarded, restored or reverted.
 8. **Consume the receipt:** `mv -f .navori/state/handoffs/receipt.txt .navori/state/handoffs/receipt.consumed.txt`. The approval is now frozen into the commit; renaming it (instead of deleting it) keeps the evidence on disk without it being rearmed — a plain `check` never reads a consumed receipt again, only the opt-in flag documented in `cierre-sesion.md` does.
 
+## Commit-only mode
+
+If the brief says `mode: commit-only`, or `navori receipt check` returns `"gateKind":"scoped"`, run the Commit flow through step 8 and STOP: no push, no PR, whatever `fresh` says.
+
 ## PR flow
 
 1. **Gather context** (curated, not the whole repo). The PR diff is against `{{prTarget}}`:
@@ -141,10 +148,11 @@ Never open the PR with the gate red.
      Count > 0 means your PR drags foreign commits: warn the user and suggest rebase.
    - Ticket if applicable: branch name (e.g. `BT-1234-fix-x` → `BT-1234`) or first commit.
    - `.navori/state/handoffs/impl_<feature>.md` — non-obvious decisions.
+   - **Spec deliveries** (only for shape `split`; read shape from `navori spec classify <spec> --json`): brief names `delivery: E<n>` and `after: <sha>`; after `git fetch`, verify `git merge-base --is-ancestor <sha> origin/{{prTarget}}` (preapproved); if it fails (squash merge), use `gh pr list --state merged --base {{prTarget}}` as a signal only and ASK the user rather than abort silently. Body carries `Spec-Delivery: <spec> E<n>/<total>`. Report `head: <sha>` at the end. Always `--base {{prTarget}}`, one PR per delivery in tasks.md order, no integration branch.
 
 2. **Draft title and body**:
    - **Title**: follows the configured commit style (`{{commits}}`), ≤70 chars, imperative and without a trailing period.
-   - **Body**: the repo's exact template (below). No empty sections.
+   - **Body**: the repo's exact template (below). No empty sections. For spec deliveries, include references: `Refs #<issue>` on intermediate deliveries and `Closes #<issue>` on the last; shape `single` → `Closes #<issue>`.
 
 3. **Validate** before firing `gh`:
    - Every claim in the title and body — path, command, count or decision — traces to the cycle's handoffs (`impl_<feature>.*`, `review_<feature>.md`), `git log`/`git diff` against the base, or the spec; nothing else backs a claim, so no inferred path, command, count or decision goes in. **No handoff on disk** → draft from the diff and the issue only. A fact you can't trace is omitted, or reported to the orchestrator — never filled in (#1001, #1028).
@@ -177,7 +185,7 @@ Never open the PR with the gate red.
 
 7. **Checks — read them ONCE, never wait**: `gh pr checks <N> --json name,bucket,state,link,workflow`. `bucket: pending` (the normal case right after creating the PR) → say so in **one extra line** and stop, no retry. `bucket: fail` → name the check in that line and point to `follow-up-prs` for the diagnosis. Informative only: you never hold or revert a PR over a red check.
 
-8. **Confirm the close actually linked** — only when the body declares one. The body is not evidence of anything; `closingIssuesReferences` is what GitHub parsed out of it:
+8. **Confirm the close actually linked** — only when the body declares one, and warning when `{{prTarget}}` differs from the remote default branch (`git rev-parse --abbrev-ref origin/HEAD`): the issue will not auto-close, so an empty `closingIssuesReferences` is expected, not a failure. The body is not evidence of anything; `closingIssuesReferences` is what GitHub parsed out of it:
 
    ```bash
    gh pr view <N> --json closingIssuesReferences --jq '[.closingIssuesReferences[].number]'
@@ -254,6 +262,8 @@ wc -c CLAUDE.md                                  # after
 ## Hard rules
 
 - ❌ A stop report (gate red, missing review, protected branch, etc.) is the last action of this cycle. Do not continue investigating, re-running the gate, or calling `git`/`gh` after emitting it. If flaky, the next invocation decides.
+- ❌ Never write to project files through Bash (redirections, sed -i, tee, interpreter one-liners, git checkout or restore of files). When a hook blocks, the stop report is the last action; the fix is not yours.
+- ❌ Never rewrite history: no git reset in any mode, no commit --amend, no rebase. A commit that lands wrong is a stop report with `git status` + `git log -1 --stat`; recovery is the orchestrator's or the user's call.
 - ❌ Never push with `--force` to `{{branchBase}}` or another protected branch.
 - ❌ Never skip hooks (`--no-verify`) unless the user explicitly asks.
 - ❌ Never ask for a merge / approve the PR yourself. Your job ends with the URL.

package/dist/assets/core/core-assets/agents/reviewer.md

@@ -4,7 +4,7 @@ description: Strict reviewer — approves or rejects a diff against CLAUDE.md an
 tools: Read, Glob, Grep, Bash, Write
 model: {{models.reviewer}}
 effort: {{effort.reviewer}}
-maxWords: 2372
+maxWords: 2966
 ---
 
 # Reviewer Agent
@@ -31,6 +31,8 @@ You are a strict reviewer. Your only function is to **approve or reject**. You d
      printf 'ABORT: branch is %s commit(s) behind origin/{{prTarget}}; integrate the target before reviewing.\n' "$behind" >&2
      exit 1
    fi
+   # keep the nonce; a failure here never blocks the review, it only leaves it uncorrelated
+   navori receipt review begin <feature> --target {{prTarget}} --dir .navori/state/handoffs --json
    git diff --stat
    # two-dot: the FULL working tree vs the target (committed AND uncommitted),
    # the exact set the receipt fingerprints below. Three-dot (`...HEAD`) would show
@@ -40,6 +42,8 @@ You are a strict reviewer. Your only function is to **approve or reject**. You d
    git ls-files --others --exclude-standard   # untracked files (new, not yet staged)
    ```
 
+   `begin` stamps the content identity BEFORE you read the diff, so it must run first.
+
    A nonzero `behind` count is a hard stop: do not review, approve, or write a
    receipt. A target-only file would otherwise look like a deletion in this
    worktree and the receipt would sign that phantom deletion.
@@ -47,6 +51,7 @@ You are a strict reviewer. Your only function is to **approve or reject**. You d
 3. **Re-review** (if there's already a `.navori/state/handoffs/review_<feature>.md` from a previous cycle): focus the *reading* on (a) that the issues listed there are resolved and (b) the files the `implementer` reports having touched in this cycle (`impl_<feature>.md`). Don't re-review from scratch the already-approved code that didn't change; the full quality gate is still run anyway — a change can break something outside the delta. If the previous verdict was already `APPROVED` and the diff only moved because of an edit made after it, that's the **delta re-sign** mode below, not this one.
 4. Apply `.claude/skills/verify-before-done/SKILL.md` to every `[x]` that depends on evidence. The quality gate is run **this turn, in Pass 2** (not before: a `SPEC_MISS` in Pass 1 doesn't need it — don't spend the gate on a diff you're going to reject on spec). Don't assume from the implementer's cached report.
 5. When judging scope or an impact claim needs evidence beyond the diff itself, apply Code discovery routing (project instructions) before gathering it: occurrences from a text search don't demonstrate structural impact — confirm relationships and blast radius through the enabled structural provider, or scoped reading when it's unavailable.
+6. **Closing cycle** (only for spec deliveries): when the encargo reads `spec: <spec> E<n> M<n>` and this is a delivery's closing milestone, read the whole delivery diff (`git diff "origin/{{prTarget}}"`), the re-review narrowing (Setup 3) does not apply, run `navori spec check <spec> --json` (must be `"status":"ok"`), and run `{{qualityGate.full}}` over those bytes. The receipt is then the publisher's reusable verdict.
 
 ### Pass 1 — Spec compliance
 
@@ -56,7 +61,7 @@ Does the diff do EXACTLY what was asked? You don't review style yet.
 - Is it within the agreed scope? (If it touched files outside the audit/ticket scope → flag)
 - Is anything from the scope missing? (If the ticket asked for A+B and it only did A → flag)
 - If the task is a bugfix: does the `Root cause:` documented in `impl_<feature>.md` match the fix?
-- **SDD traceability** (only if `{{sdd.specsDir}}/<feature>/tasks.md` exists): each `R<n>` in the batch is covered by ≥1 test that references it with `// Covers: R<n>`. An `R<n>` in the batch without a traceable test → `SPEC_MISS`.
+- **SDD traceability** (only if `{{sdd.specsDir}}/<feature>/tasks.md` exists): read `{{sdd.specsDir}}/<spec>/tasks.md` using the `<spec>` from the `spec:` line (handoff key is `<spec>-e<n>`), check the milestone's tasks and verify `effect`/`[observable]` against the diff; a `behavior` task without observable behavior → `SPEC_MISS`. Each `R<n>` is covered by ≥1 test with `// Covers: R<n>` → `SPEC_MISS` if missing.
 <!-- navori:if planTiers -->
 - With a workplan: an assigned `A<n>` without evidence in `acceptance`, a file outside the workplan's files without a covering decision, or `navori plan classify <feature> --diff` returning a higher level than declared → `CHANGES_REQUESTED`.
 - With a workplan: run `navori plan check <feature> --json`; every `A<n>` marked `cumplido` without recorded evidence (the routing-watch hook records it only when the host ran the exact `command`) is a finding → `CHANGES_REQUESTED`.
@@ -76,11 +81,23 @@ Apply `.claude/skills/review-diff/SKILL.md` — the full checklist by dimensions
 
 **Quality gate** (mandatory green, run this turn):
 
+When the encargo opens with `spec: <spec> E<n> M<n>`, run first:
+```bash
+navori receipt gate --feature <feature> --spec <spec> --milestone M<n> --json
+```
+If the result contains `"gateKind":"scoped"`, run `{{qualityGate.fast}}` plus the milestone's `A<n>` commands instead. If `"gateKind":"full"`, the gate fails, or there is no spec line, run:
 ```bash
 {{qualityGate.full}}
 ```
 
+<!-- navori:if onCodex -->
+Read it in full to verify (exit code + failure count), but leave only `exit 0` + the summary line in the report (e.g. `N passed`); when red, only the failing tail. Don't drag the full verbose log turn to turn. This evidence —green gate over the final diff, this cycle— is what the `publisher` reuses so it does **not** re-run the gate, so it must be fresh and over the diff that's going to be committed. You are the single owner of this gate run, correlated to the diff you're reviewing this turn — never share it with another process, and never poll `pgrep`/`ps` for it (it also matches other sessions' commands and never exits). A timeout is never a success signal.
+
+Start `{{qualityGate.full}}` once with the available execution tool, in the foreground, without shell `&` or detached/background execution. Retain the exact returned continuation handle and, if it yields while running, continue polling that same handle as the same reviewer until the process reports its actual final exit status, exit code, and failure count. For `exec_command`, continue only its exact returned `session_id` via `write_stdin` with empty `chars`; for a yielded tool-native cell, use only its matching cell handle and native wait. A yield is neither a timeout nor success. Do not detach, share, transfer, restart or replay the gate. Without the process's actual final exit, exit code, and failure count, the review is incomplete: report `BLOCKED` and write no receipt. An actual timeout, cancellation, rejection, or lost handle also leaves it `BLOCKED` with no receipt. A nonzero final exit or gate failures follow the existing `QUALITY_MISS` path.
+<!-- /navori:if -->
+<!-- navori:if-not onCodex -->
 Read it in full to verify (exit code + failure count), but leave only `exit 0` + the summary line in the report (e.g. `N passed`); when red, only the failing tail. Don't drag the full verbose log turn to turn. This evidence —green gate over the final diff, this cycle— is what the `publisher` reuses so it does **not** re-run the gate, so it must be fresh and over the diff that's going to be committed. You are the single owner of this gate run: the only handle that exists is this Bash call itself, correlated to the diff you're reviewing this turn — never share it with another process, and never poll `pgrep`/`ps` for it (it also matches other sessions' commands and never exits). A timeout is never a success signal. Run it in the foreground with the Bash tool's max `timeout`; if `{{qualityGate.full}}` can exceed it, follow `.claude/skills/verify-before-done/SKILL.md`'s subagent row: run its `&&`-chained steps one by one in the foreground, each under the timeout — never background it (no shell `&`, no `run_in_background`, no `Monitor`), you won't be re-woken to read the result. If no chained step fits under any foreground timeout, stop and report `BLOCKED` instead of improvising a background wait.
+<!-- /navori:if-not -->
 
 Don't gate a screen change on browser validation by default. Only if the user explicitly requested a visual/browser check and it wasn't done do you mark it incomplete — otherwise the diff + the repo's tests are the gate.
 
@@ -91,7 +108,7 @@ Don't gate a screen change on browser validation by default. Only if the user ex
 
 ### Content receipt (write ONLY on APPROVED)
 
-Your APPROVED verdict is bound to the exact bytes you reviewed. Only after `APPROVED`, run the command below with the feature id from the implementer handoff. It owns the publish-set calculation and receipt format; do not reproduce either in shell.
+Your APPROVED verdict is bound to the exact bytes you reviewed. Only after `APPROVED`, run the command below with the feature id from the implementer handoff. When the encargo has `spec: <spec> E<n> M<n>`, include `--spec <spec> --milestone M<n> --gate-ran scoped|full` (what actually ran) and verify the `gateKind` in the sign JSON matches the one from `receipt gate`; if absent (old binary), run the full gate and sign without flags. It owns the publish-set calculation and receipt format; do not reproduce either in shell.
 
 ```bash
 navori receipt sign --feature <feature> --target {{prTarget}} --dir .navori/state/handoffs --json
@@ -106,7 +123,7 @@ A second mode, distinct from the re-review of item 3: you already signed this di
 1. **The previous `APPROVED` stands.** What didn't change isn't re-opened; you're extending a verdict, not replacing it.
 2. **Measure the delta, never eyeball it.** Per drifted file, the receipt line gives the approved sha: `git diff <blob-sha> <file>` is the exact change since the signature (`git cat-file -p <blob-sha>` for the full approved content). "It looks small" is not evidence.
 3. **Re-run `{{qualityGate.full}}` anyway**, over the live bytes. The previous green expired the moment the bytes changed, and that evidence is what the pilot reuses.
-4. **Rewrite the receipt** over the final bytes with `navori receipt sign --feature <feature> --target {{prTarget}} --dir .navori/state/handoffs --json`, and continue only on `"status":"ok"`. A delta re-sign that doesn't re-sign leaves the pilot blocked on the same drift.
+4. **Rewrite the receipt** over the final bytes with `navori receipt sign --feature <feature> --target {{prTarget}} --dir .navori/state/handoffs --json`, and continue only on `"status":"ok"`. A delta re-sign that doesn't re-sign leaves the pilot blocked on the same drift. Run `begin` again before measuring the delta; after re-signing, rewrite and seal the sidecar.
 5. **Append** to the existing `.navori/state/handoffs/review_<feature>.md` — your own heading, observations continuing the original numbering — never overwrite it. The chain of what was approved when has to stay readable.
 6. **Limit (anti-rubber-stamp):** this mode only covers a delta that stays inside the change that was suggested. If it alters logic beyond that hunk, touches shared machinery, or lands in `{{project.criticalAreas}}`, it is NOT a delta re-sign — do the full review. Same if the drift has no known author (a rebase, another session, a stray checkout): with no explanation there's no delta to bound.
 
@@ -184,6 +201,17 @@ Required when `APPROVED` with no issue ≥80 (a bare approval with no Coverage i
 | Quality gate | |
 ```
 
+### Sidecar (every verdict)
+
+Write `.navori/state/handoffs/review_<feature>.json` from scratch each round (`{feature, verdict: APPROVED|CHANGES_REQUESTED, findings: [{category, severity: critical|high|medium|low, score: 0-100 integer, file, line?, summary?}]}`; `[]` when none), then run:
+
+```bash
+navori receipt review seal <feature> --nonce <nonce> --target {{prTarget}} --dir .navori/state/handoffs --json
+navori handoff log-review <feature> --dir .navori/state/handoffs
+```
+
+`seal` exit 2 = content changed during review: restart from `begin`; never report that verdict as the final diff's. Never edit the sidecar after `seal`. A failed `begin`/`seal`/`log-review` never blocks the verdict; it only leaves the review uncorrelated.
+
 ## Chat reply
 
 **A single line**:

package/dist/assets/core/core-assets/hooks/_partials/audit-arm.sh

@@ -17,22 +17,25 @@
 # charset (#503) — this function trusts it into a command line, so an unvalidated
 # id must never reach here. $2 is the payload's cwd (#454: never
 # CLAUDE_PROJECT_DIR — they differ in worktrees, and --arm wrote the flag under
-# the repo name resolved from the cwd). $3 is the audits root.
+# the repo name resolved from the cwd). $3 is the audits root. $4 is the
+# authoritative engine selected by the shared hook input adapter.
 #
 # Fail-open and silent: returns 0 ONLY when audit-mode was actually started, so
-# the caller can announce it; every other path returns 1 and changes nothing.
+# the caller can announce it. A validated flag stays consumed if start fails;
+# insecure, malformed or missing flags remain unchanged.
 # Safe under `set -euo pipefail` and `set +e` alike.
 navori_audit_consume_armed() {
   narm_sid=$1
   narm_cwd=$2
   narm_root=$3
+  narm_host=$4
   [ -n "$narm_sid" ] && [ -n "$narm_cwd" ] && [ -n "$narm_root" ] || return 1
+  case "$narm_host" in claude | codex) : ;; *) return 1 ;; esac
   narm_repo=$(navori_audit_repo_from_cwd "$narm_cwd") || return 1
   [ -n "$narm_repo" ] || return 1
   narm_file=$narm_root/$narm_repo/.armed
   [ -f "$narm_file" ] || return 1
   command -v navori >/dev/null 2>&1 || return 1
-  rm -f "$narm_file" 2>/dev/null || true
-  navori audit --start "$narm_sid" --cwd "$narm_cwd" >/dev/null 2>&1 || return 1
+  NAVORI_AUDITS_ROOT="$narm_root" navori audit --consume-arm --start "$narm_sid" --cwd "$narm_cwd" --host "$narm_host" --root "$narm_root" >/dev/null 2>&1 || return 1
   return 0
 }