navori 0.11.3 → 0.12.0

package/README.md

@@ -18,6 +18,9 @@ También renderiza un harness Codex completo: `AGENTS.md`, skills en
 
 // Solo guía universal, con el menor número de archivos
 { "engines": ["agents-md"] }
+
+// Solo Pi (opt-in; ver docs/pi.md)
+{ "engines": ["pi"] }
 ```
 
 `codex` ya incluye y administra `AGENTS.md`; no necesitas combinarlo con
@@ -41,7 +44,7 @@ npx navori init
 cd ~/tu-repo
 navori init --recommended
 
-# + proveedores externos (tgrep, semgrep, jscpd, acli) + pre-commit hook +
+# + proveedores externos (tgrep, acli) + pre-commit hook +
 # scan-monorepo + project block estricto — requiere instalar los binarios de esos proveedores.
 # También avisa si falta algún binario y cómo instalarlo, sin instalarlo nunca.
 navori init --full
@@ -115,7 +118,8 @@ de caché de ambos directorios.
 | `remove <plugin>` | Desactiva un plugin y limpia sus bloques managed, sub-bloques y scripts |
 | `configure <section>` | Ajusta una sección del config sin re-correr el wizard |
 | `adopt <path>` | Toma un archivo de `.claude/` que escribiste a mano bajo gestión de navori: lo envuelve en un bloque managed sin reescribir su contenido (preview por default) |
-| `update` | Re-detecta el repo, refresca config y corre sync en un paso |
+| `refresh` | Re-detecta el repo, refresca config y corre sync en un paso |
+| `update` | Actualiza el propio navori desde npm y luego corre `refresh` con el binario nuevo (ver [Actualizar navori](#actualizar-navori)) |
 | `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. 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 |
@@ -124,17 +128,17 @@ de caché de ambos directorios.
 | `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, 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` |
+| `gate <fast\|full>` | Corre `qualityGate.fast` o `qualityGate.full` con la salida completa en un log (`.navori/state/gate/`) y solo un veredicto compacto en stdout. Flag: `--cwd <path>` |
+| `receipt <sub>` | Recibo de los bytes revisados antes de publicar: `sign` (`--feature <id>`, `--gate-ran scoped\|full`, `--spec <dir> --milestone <Mn>` o `--phase <name\|index>`), `check`, `gate --spec <dir> --milestone <Mn>` o `--phase <name\|index>` (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]`) |
+| `handoff <check\|log-review>` | `check` valida el handoff del implementer (`impl_<feature>.json`) antes de despachar al siguiente agente; `log-review <feature>` valida `review_<feature>.json` y agrega a `findings.jsonl` los hallazgos con score >= 50 (`navori handoff check <feature> [--for scribe] [--produced-by reviewer [--since <iso>]] [--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`, `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`, `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 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/` |
@@ -185,8 +189,6 @@ La resolución es **local → bundled**: si tienes un preset local con el mismo
 | `tgrep` | Descubrimiento textual de código vía CLI indexado | `tgrep` binary |
 | `acli` | Leer tickets de Jira desde la terminal | `acli` |
 | `gh` | GitHub Issues, PRs y workflow runs | `gh` |
-| `jscpd` | Detección de duplicación en el diff | `jscpd` (opt-in) |
-| `semgrep` | Security gate local | `semgrep` (opt-in) |
 
 > `codegraph` y `tgrep` se retiraron brevemente el 2026-09-15 y se reintrodujeron el
 > 2026-09-16 (#838) con una integración que los hace trabajar entre sí — acta en
@@ -319,7 +321,7 @@ un aviso que **nombra** los repos con bloques editados a mano (conflict, que el
 render no pisa) y un roll-up `ok · changed · conflict · failed`.
 
 El registro (`~/.navori/registry.json`) se puebla solo: cada `navori init` /
-`navori update` te da de alta. Para arrancar con lo que ya tenías instalado,
+`navori refresh` te da de alta. Para arrancar con lo que ya tenías instalado,
 escanéalo una vez:
 
 ```bash
@@ -331,52 +333,6 @@ navori registry prune                       # quitar los que ya no existen
 Es ortogonal a los workspaces: el registro es "qué repos existen"; el workspace
 es el perfil de policy (branchBase/prTarget) que cada repo hereda.
 
-## Harness global por máquina (opt-in)
-
-Todo lo de arriba es por repo. Cuando abres una sesión **fuera** de un repo con navori (un scratch,
-un repo ajeno, tu `~`), no hay harness: ni doctrina de orquestación, ni skills, ni agentes. La capa
-global cubre ese hueco. No la confundas con `render --all` de la sección anterior: aquélla empuja tu
-harness a los repos que **ya** tienen navori; ésta cubre las sesiones que no están en ninguno.
-
-Es **opt-in de huella cero**: si nunca corres `navori global init`, no existe `~/.navori/global.json`
-y navori no escribió un solo byte en tu máquina.
-
-```bash
-navori global init                        # wizard: bloques del baseline + permisos personales.
-                                          # Preview: sin --apply no escribe un solo byte
-navori global init --apply                # escribe lo que el preview mostró
-navori global init --recommended --apply  # headless (CI): sin preguntas, selección recomendada
-navori global doctor                      # audita: drift del hook, gate, plugin, permisos y versión
-navori global render --apply              # re-renderiza tras un bump del CLI (preview sin --apply)
-navori global uninstall                   # la retira por completo
-```
-
-El `init` pregunta dos cosas: **qué bloques** componen el baseline (los que declaran `globalSafe`)
-y **qué permisos personales** quieres en `~/.claude/settings.json` — ése es el único camino de UI
-para `permissions`. Re-inicializar **preserva** lo que ya habías elegido: no te resetea a los
-defaults. Sin TTY (CI, pipe) cae solo al camino de `--recommended`, y `--lang es|en` fija el idioma
-del baseline y de los prompts.
-
-Qué escribe el `init --apply`, y nada más:
-
-- `~/.navori/global.json` — el manifest: idioma, bloques del baseline y tus permisos globales.
-- `~/.claude/skills/navori/` — el plugin `navori@skills-dir` con los 8 agentes, las 11 skills y el
-  hook del baseline. Claude Code lo carga sin marketplace ni paso de instalación; las skills globales
-  se invocan `/navori:<nombre>` (tras un render, `/reload-plugins` o sesión nueva).
-- `~/.claude/settings.json` — **solo** la clave `permissions`, y solo si declaraste permisos globales
-  en el manifest. Con la config por default ni siquiera lo crea.
-
-Respeta `CLAUDE_CONFIG_DIR`: si lo tienes seteado, el plugin va ahí en vez de a `~/.claude`.
-
-**El baseline se hace a un lado solo.** El hook corre en `SessionStart` y busca un `navori.config.json`
-hacia arriba desde el directorio de la sesión: si lo encuentra, no emite nada — manda el harness del
-repo, que es más específico. Por eso el baseline viaja dentro de un hook y no como bloque estático en
-`~/.claude/CLAUDE.md`: ese archivo se carga siempre y no podría cederle el paso a nadie.
-
-`navori global uninstall` retira **solo lo que navori escribió**: el plugin, el manifest y los permisos
-que quedaron registrados como suyos. Un permiso que ya tenías en tu `settings.json` nunca se vuelve de
-navori, así que el uninstall no se lo lleva.
-
 ## Managed blocks con versionado
 
 Cada bloque que `navori` inyecta en tu `CLAUDE.md` lleva metadata:
@@ -408,9 +364,9 @@ Cambiar una sola cosa sin re-init:
 
 ```bash
 navori configure plugins              # multiselect de plugins activos
-navori configure quality-gate         # nuevo comando de quality gate
+navori configure quality-gate         # comandos del quality gate
 navori configure language en          # switch a inglés (fallback a es)
-navori configure engines              # multiselect: claude / codex / agents-md / cursor / copilot
+navori configure engines              # multiselect: claude / codex / agents-md / cursor / copilot / pi
 navori configure branch-base main     # punto de fork / rama protegida
 navori configure pr-target develop    # rama destino del PR (gh pr create --base)
 navori configure workspace bonum      # asociar a un workspace
@@ -424,6 +380,24 @@ retiradas caen en la misma con valores distintos no se infiere nada — se pregu
 `--scout=<modelo> --scout-effort=<nivel>`. `--dry-run` no escribe, y `--all` barre el registry
 completo (preview salvo `--apply`).
 
+### Claves de config para el gate y los hooks nativos
+
+- `qualityGate.scoped` (string): carril acotado del reviewer — los checks baratos de `full` más los tests relacionados con el diff. Si falta, usa `fast`. Se interpola como `navori.scopedGate`.
+- `qualityGate.nativeHooks` (boolean): declara que el pre-commit nativo del proyecto ya corre `fast`; el hook `quality-gate-pre-commit` omite solo su paso de gate.
+- `plugins.<id>.nativeHook` (boolean): el hook git nativo corre el check de ese plugin, así que su hook no se registra (los scripts se siguen instalando).
+
+### Tope de `progress/current.md`
+
+`progress/current.md` se carga en cada sesión, así que tiene un tope. El hook pre-commit bloquea los commits de agente que lo dejan sobre el tope duro o lo hacen crecer estando ya sobre él (los commits humanos no se bloquean). `navori doctor` lo mide en bytes con los mismos topes y avisa; el hook de inicio de sesión advierte, sin bloquear, al pasar el tope suave.
+
+## Migrando a 0.12
+
+- Se retiró el comando `global` y el colector launchd (`audit --collect` sigue). `doctor --json` ya no emite `globalScope`.
+- Se retiraron los plugins `jscpd` y `semgrep`: `navori add jscpd|semgrep` responde que están retirados.
+- El piso de Pi sube a 1.1.0: Pi 0.87.x pierde `navori_subagent`. Node mínimo: >= 22.12.
+- `navori update` ahora actualiza el CLI (consulta npm, confirma, instala y luego corre `navori refresh`). El comportamiento anterior es ahora `navori refresh`, sin alias: los scripts que usaban `navori update` para re-sincronizar el harness deben cambiar a `navori refresh`.
+- Migra con `navori render --apply` (poda los assets retirados que navori gestionaba) y luego `navori doctor` (reporta los restos).
+
 ## Extender el harness en tu repo
 
 navori instala un baseline; lo que lo vuelve valioso en **tu** repo es el conocimiento que sólo
@@ -477,3 +451,15 @@ Contrato del `SKILL.md`: [`docs/recipes/skill-authoring.md`](https://github.com/
 ## Licencia
 
 MIT.
+
+## Actualizar navori
+
+`navori update` consulta npm por la última versión de navori y muestra el comando de
+instalación según cómo lo tengas: npm global, devDependency, dependency o `npx`. Pide
+confirmación (salvo `--yes`), instala y corre `navori refresh` con el binario nuevo.
+
+- `--cli-only`: se detiene tras actualizar el CLI, sin `refresh`.
+- Sin red o ya en la última versión: corre `refresh` directo.
+- Si la instalación falla: imprime el comando manual y sale con código 1.
+- Sin TTY y sin `--yes`: imprime el comando y sale con código 1.
+- Solo soporta npm.

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

@@ -29,7 +29,7 @@ For a **master-plan** task, write the requested `<etapa>/plans/plan<n>.md` and p
 
 Use URLs de documentación oficial for expiring facts and include the fecha de consulta. If a source is unavailable, label the claim `[SIN VERIFICAR]` and list the sources consulted or unavailable.
 
-Via `Agent` you may dispatch `scout`/`scribe`; plan-gate and Agent hooks fire inside you with `agent_id`, expected.
+<!-- navori:if-not onPi -->Via `Agent` you may dispatch `scout`/`scribe`; plan-gate and Agent hooks fire inside you with `agent_id`, expected.<!-- /navori:if-not -->
 
 ## Protocol
 

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: 2448
+maxWords: 2473
 ---
 
 # Implementer Agent
@@ -27,7 +27,7 @@ You execute **a single** task from start to verification. You don't orchestrate,
      - [ ] Define interface in <path>
      - [ ] Implement logic in <path>
      - [ ] Cover with a test
-     - [ ] Run `{{qualityGate.fast}}`
+     - [ ] Run `{{gateRun.fast}}`
      ```
 
    - `Expected files: <list>`
@@ -38,10 +38,12 @@ You execute **a single** task from start to verification. You don't orchestrate,
 4. **Quality gate** (mandatory before returning):
 
    ```bash
-   {{qualityGate.fast}}
+   {{gateRun.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 (<!-- 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.
+   If `navori gate <kind>` prints no first line `navori gate <kind>: exit <N> — log <path>`, it did not run: run the literal `{{qualityGate.fast}}`. Open the log only on a red.
+
+   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. 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 -->
@@ -60,7 +62,7 @@ When the encargo opens with `workplan: <feature>`, read `.navori/state/handoffs/
 - **Zero new errors** introduced by your code in the quality gate tools (vs. baseline) — classify per `verify-before-done`'s Failure attribution, never by diff location alone; see the evidence table below. Returning with any tool red (because of your change) is automatic grounds for `CHANGES_REQUESTED`.
 - **Never mutate or discard the shared working tree**: no stashing, no checkout/reset that discards local changes, no working-tree clean — these hit the `ask` permission rule and can stall a background agent indefinitely. Same reasoning for scratch files: leave them, don't clean them with a recursive delete.
 - **JSDoc** mandatory on public exports and functions >15 lines or with dense conditional logic.
-- **SDD traceability** (only if the feature has `{{sdd.specsDir}}/<feature>/tasks.md`, see the SDD block in `CLAUDE.md`): each `R<n>` in your batch is covered by ≥1 test, and each test references its requirements with a `// Covers: R<n>` comment above the case. Without full traceability the `reviewer` rejects.
+- **SDD traceability** (only if the feature has `{{sdd.specsDir}}/<feature>/tasks.md`, see `spec-bootstrap`): each `R<n>` in your batch is covered by ≥1 test, and each test references its requirements with a `// Covers: R<n>` comment above the case. Without full traceability the `reviewer` rejects.
 - **Guard/policy coverage** (only if your task introduces or modifies a guard, policy or permission check): your report carries the enumeration, not just the diff — every entry point that mutates the same resource (routes, bulk/admin variants, jobs, scripts) with its `file:line` evidence, each marked covered or excluded with the reason. Locate them with `locate-code`; an entry point you didn't list is one the `reviewer` has to rediscover.
 - If a tool fails weirdly (e.g. tsc breaks with no apparent diff), **don't improvise a workaround**: note `Status: BLOCKED` + the reason in `.navori/state/handoffs/impl_<feature>.md` and stop.
 - **While iterating, run only the tests of the area you touch** (filter by the runner's path). The full gate in step 4 runs at the end, not on each iteration — saves time and context. Never run the full `{{qualityGate.full}}` suite yourself: that's the `reviewer`'s Pass 2 job, and it commonly outlives Bash's timeout. If this repo has a diff-scoped fast check (`scoped-gate`), it's hygiene for iterating, never a substitute for step 4.
@@ -163,6 +165,8 @@ Write `.navori/state/handoffs/impl_<feature>.json` — the only artifact you pro
 
 `doubts` is optional: declare one `{ "file": "<path>", "reason": "<why you are unsure>" }` entry per spot where you are unsure the change is right, so the reviewer answers it.
 
+Types follow the handoff schema: `rootCause` is a string, present only for a bugfix (omit the key otherwise, never `null`); `blockers` is an array of strings (`[]` when none).
+
 `markdownRequests` carries every piece of prose your task needs — your own non-obvious decisions, a CONTRIBUTING/README update, a spec task checkbox, a skill or agent tweak. State the `intent` and the `evidence`; never the finished sentence — drafting the prose from that intent is the `scribe`'s job, not yours. Empty array when the task touches no Markdown at all.
 
 ## Communication with the orchestrator

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

@@ -4,7 +4,7 @@ description: Do NOT invoke as a subagent, never and under no condition. Orchestr
 tools: Read, Glob, Grep, Bash, Agent
 model: {{models.orchestrator}}
 effort: {{effort.orchestrator}}
-maxWords: 3050
+maxWords: 3365
 ---
 
 # Orchestrator Playbook (embodied by the main agent)
@@ -20,7 +20,7 @@ One route removes the decision entirely. It is more expensive per change and tha
 ## Startup protocol
 
 1. `CLAUDE.md` (stack, conventions, quality gate) is already in your context when your host injects it; read it from disk ONLY if your host did not inject it (e.g. an engine without automatic injection).
-2. The catalog of subagents and skills is in `CLAUDE.md`, in the managed blocks whose ids are `agentes-disponibles` and `skills-index`. Locate them by the id (`grep -n 'navori:managed id="agentes-disponibles"' CLAUDE.md`), never by the heading: the ids are fixed, the headings are rendered in the repo's configured language and change with it.
+2. The catalog of subagents is the managed block whose id is `agentes-disponibles`, delivered at session start. Locate it by the id, never by the heading: the ids are fixed, the headings are rendered in the repo's configured language and change with it. Skills: the host's native listing.
 3. Read `progress/current.md` (repo root) if it exists — the previous session's state.
 4. Identify the task's scope against the "Project rules" below (legacy paths, critical areas, repo conventions).
 5. **Did text from a ticket (Jira/Linear/GitHub/Slack) arrive?** If it matches your `auditor` agent's ticket-encargo triggers (bug in a critical feature, structural migration, feature that crosses >3 layers), invoke that agent first — it produces `.navori/state/handoffs/audit_ticket_<ID>.md` that guides all later decomposition. For trivial tickets (typo, copy, color), skip the audit. The single architectural design gate — when it fires, who proposes, who challenges, who decides — lives in "## Role: orchestrator" and the `solution-design` skill, not here.
@@ -67,7 +67,7 @@ When the `done -> file` come back, **gather and analyze deeply YOURSELF**: read
 
 Fan-out is a lever, not a toll — so when you do delegate, hand the smallest encargo that covers the work:
 
-- **Don't delegate merely to wrap a lookup.** If what's missing is a Code discovery routing call you can make yourself (project instructions), run it directly — a subagent invocation isn't a proxy for a query you can issue this turn. When delegation is warranted for a real reason, carry over the pending question, the evidence you already gathered, the relevant paths and their freshness in the encargo; never assume the subagent shares this context — it starts isolated.
+- **Don't delegate merely to wrap a lookup.** If what's missing is a Code discovery routing call you can make yourself (project instructions), run it directly — a subagent invocation isn't a proxy for a query you can issue this turn. When delegation is warranted for a real reason, carry over the pending question, the evidence you already gathered, the relevant paths and their freshness in the encargo; never assume the subagent shares this context — it starts isolated, with no skills listing: name any skill it should apply with its path `.claude/skills/<id>/SKILL.md`.
 - **Peel off the mechanical first.** Copies, renames, scaffolding, JSON/string edits → send them to a low-tier agent in their own encargo; never bundle them into the `implementer`'s, where they inflate its context and its run without raising quality.
 - **One encargo = one unit.** A pre-existing bug the `implementer` hits outside its scope → it reports and stops there (a trivial one-liner is the exception); **you** decide whether to open a separate unit. Scope doesn't self-expand mid-run.
 - **Tier by sub-task, not by round.** A single fix round can mix tiers. Map: **low** → mechanical work (copies, renames, scaffolding, string/JSON edits, a one-line fix); **mid** → a scoped bugfix with a clear cause or a bounded feature; **high** → judgment work (design, security regex, ambiguous root-cause, removal semantics, critical areas).
@@ -155,10 +155,12 @@ And never take a merged PR as proof on its own: **squash merge leaves no ancestr
 ## Quality gate
 
 ```bash
-{{qualityGate.fast}}    # fast gate — pre-step to the reviewer
-{{qualityGate.full}}    # full gate — before closing the session / creating the PR
+{{gateRun.fast}}    # fast gate — pre-step to the reviewer
+{{gateRun.full}}    # full gate — before closing the session / creating the PR
 ```
 
+When the command is `navori gate <kind>`, its first stdout line is `navori gate <kind>: exit <N> — log <path>`; if it is missing, the gate did not run: run the literal `{{qualityGate.fast}}` or `{{qualityGate.full}}` command instead.
+
 If the repo has no test suite, the `implementer` still can't claim "done" without fresh evidence (a correct diff plus whatever checks exist) — but browser/visual validation stays **on-request only, never automatic**. The `verify-before-done` skill enforces the "fresh evidence rule" over any "done" claim.
 
 ## What you do NOT do

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

@@ -17,14 +17,14 @@ You own the **end of the cycle**: well-structured commits in the configured styl
 ## When to trigger
 
 - Working tree with changes ready to commit (post-implementer + review APPROVED).
-- Branch finished, ready for PR: commits on the branch, harness approved, and fresh `{{qualityGate.full}}` evidence over the shipping diff (see Gate below).
+- Branch finished, ready for PR: commits on the branch, harness approved, and fresh full-gate evidence over the diff that ships (see Gate below).
 - Explicit user request: "create the PR", "commit this", "send the PR", "/pr".
 
 ## When NOT to trigger
 
 - Working tree with uncommitted changes when the user only asked to "open the PR" → first commit or ask for permission.
 - You are on `{{prTarget}}`, on the branch this one was forked from, or another protected branch → abort + ask for a branch.
-- Harness active and THIS feature's review — `.navori/state/handoffs/review_<feature>.md`, the single file the pre-flight below identifies by name — contains `CHANGES_REQUESTED` → no PR is created. Never scan the directory for it: a `CHANGES_REQUESTED` belonging to someone else's closed cycle must not abort your PR, exactly as another feature's `APPROVED` never unblocks it.
+- Harness active and THIS feature's review (`.navori/state/handoffs/review_<feature>.md`, identified by name in the pre-flight) contains `CHANGES_REQUESTED` → no PR is created.
 - Quality gate red this turn.
 
 > **Two branches, one that decides:** `{{prTarget}}` is the target for `gh pr create --base` and every diff below. The fork point is a separate setting; in most repos both name the same branch. Where they differ, the target branch wins — the fork-point diff is never the PR's.
@@ -43,51 +43,32 @@ if [ "$behind" -ne 0 ]; then
   exit 1
 fi
 git log origin/{{prTarget}}..HEAD --oneline           # must have ≥1 commit (or changes to commit)
-git diff origin/{{prTarget}} --stat                   # REAL scope so far (two-dot: see below)
+git diff origin/{{prTarget}} --stat                   # real scope so far
 gh auth status                                        # gh authenticated
 ```
 
-A nonzero `behind` count is a hard stop: do not construct a shipping diff,
-consume a receipt, commit, push, or create a PR. The reviewer would otherwise
-have signed target-only files as phantom deletions from this stale worktree.
+A nonzero `behind` count is a hard stop: do not consume a receipt, commit, push, or create a PR. The reviewer would otherwise have signed target-only files as phantom deletions from this stale worktree.
 
-The later `receipt.txt` check is also a hard stop: it must report JSON
-`"status":"ok"` before this branch can publish.
+**Which review counts.** Identify THIS feature's review by name: `.navori/state/handoffs/review_<feature>.md`, with `<feature>` the id from your brief. A broad glob (`review_*.md`) over all reviews is not valid: another feature's `APPROVED` never unblocks this PR and another cycle's `CHANGES_REQUESTED` never aborts it. Open that file: its verdict must be `APPROVED` and its scope/feature section must name the feature you are about to commit. Absent, ambiguous (more than one candidate), or mismatched → not approved: abort, tell the user the review is missing, and never assume a generic `APPROVED`.
 
-### The shipping diff — the one set every count in this pre-flight comes from
-
-Coverage of the review and the receipt's fingerprints are two questions about the SAME set of files. Write it once, read it everywhere:
-
-```bash
-shipping=$({ git -c core.quotepath=false diff --name-only "origin/{{prTarget}}"; \
-             git -c core.quotepath=false ls-files --others --exclude-standard; } \
-           | sort -u | grep -vE '^(\.navori/state/handoffs/|progress/)')
-printf '%s\n' "$shipping"                             # read it: this is what ships
-```
-
-- **`$shipping` does not survive the call.** Each Bash call starts a fresh shell — no variable or function crosses over — so re-run the assignment in the same call as whatever reads it. That is a copy of four lines, not a second definition of the set.
-- **Two dots, plus the untracked files — NEVER `...HEAD`.** Three-dot lists only what is already *committed*, and your trigger is by construction an **uncommitted** tree: there is no clean-working-tree check in this pre-flight because the commit is yours to make, further down. Run against an uncommitted tree, a three-dot listing comes back EMPTY — the coverage check then finds nothing missing and the waiver's count reads zero, so both are granted on every diff. It fails silently, in the unsafe direction. Two-dot plus `ls-files --others` is the exact set the `reviewer` captured and signed.
-- **`progress/` is dropped**, the same grep the receipt applies, so the two sets line up 1:1 and a git-persisted session-state update never looks like an unreviewed file. Deletions DO stay in the set (the receipt records them as `deleted  <path>`), so a removed file can't ship unreviewed.
-- **`quotepath=false` on both listings**, exactly as the reviewer signed them: git C-quotes a non-ASCII path by default, and a quoted path never matches the receipt's line — the file would read as uncovered, or slip by unverified.
-
-If the harness is active, identify THIS feature's review: `.navori/state/handoffs/review_<feature>.md`, with `<feature>` the id you received in your brief. A broad glob (`review_*.md`) over all reviews is not valid — it's not enough that some review with `APPROVED` exists in the directory, it has to be this feature's.
-
-Open that specific file and confirm its verdict is `APPROVED` and that its scope/feature section names the same feature you're about to commit. The verdict only counts if the review **covers the whole shipping diff**: the reviewer's content receipt (below) is the authoritative list of the files it actually reviewed, so every file in the shipping diff above must appear there. A touched file the review never saw → the `APPROVED` doesn't cover the full change → it does NOT count as approved. Abort, don't create the PR, and send it back to the reviewer to cover the missing files. It's not enough to mention the difference and carry on. The coverage check is mechanical — see the receipt block.
-
-<!-- This file-coverage rule lives here only; the commit+PR flow has no second home to this agent (single owner of the PR flow). -->
-
-
-An absent file, ambiguous (more than one candidate), or with a verdict/scope that doesn't match the current feature → does NOT count as approved: abort, tell the user the review is missing, and never assume a generic `APPROVED`.
-
-**Content receipt: the diff must still match what was approved.** Before committing, run the receipt command with the feature id from `review_<feature>.md`. It owns coverage and drift detection; do not reproduce its algorithm in shell.
+**Content receipt: the diff must still match what was approved.** The `receipt.txt` check is also a hard stop. Run it with the feature id from `review_<feature>.md`. It owns the shipping set (working tree against `origin/{{prTarget}}`, untracked files included), the coverage check and the drift check: do not reproduce any of them in shell.
 
 ```bash
 navori receipt check --feature <feature> --target {{prTarget}} --dir .navori/state/handoffs --json
 ```
 
-Continue only when the JSON has `"status":"ok"`. A missing `navori`, absent receipt, non-zero command, malformed JSON, `ERROR`, `UNCOVERED`, or `DRIFT` blocks the commit and PR.
+Continue only on `"status":"ok"`, and read the rest of the JSON by this table:
+
+| JSON from `navori receipt check` | Action |
+|---|---|
+| `"status":"error"` (`error` names the cause: branch behind the target, no receipt, receipt of another feature, fetch failure), a non-zero exit with no JSON, or `navori` missing | Hard stop. Report the `error`; no commit, push or PR. |
+| `"status":"findings"` with `uncovered[]` not empty | The review never saw those files, so its `APPROVED` does not cover this change. Abort and send it back to the `reviewer` for a full re-review of them; do not carry on. |
+| `"status":"findings"` with `drift[]` not empty (`kind`: `changed`, `missing`, `reappeared`) | `drift[].blob` is the approved blob: `git diff <blob-sha> <file>` shows the change (`git cat-file -p <blob-sha>` prints the approved content). An explained post-review edit goes to the `reviewer` for a **delta re-sign**; unexplained drift goes to a full re-review. |
+| `"status":"ok"`, `"fresh":true`, `"gateKind":"full"` | Gate evidence is trusted: do not re-run the gate (see Gate below). |
+| `"status":"ok"` with `"fresh":false` (`stale[]` lists `format`, `gate` or `inputs`), or `"gateKind":null` | No trustworthy gate evidence: you run the gate yourself (see Gate below). |
+| `"gateKind":"scoped"` | Commit-only mode below, whatever `fresh` says. |
 
-For every live-file `DRIFT`, the JSON provides the approved blob and the exact inspection command is `git diff <blob-sha> <file>` (`git cat-file -p <blob-sha>` prints its approved content). Route explained drift caused by a post-review edit to the reviewer for a **delta re-sign**; route unexplained drift or any uncovered file to a full re-review. If the real PR base differs from `{{prTarget}}`, pass that actual base as `--target` to both receipt commands.
+If the real PR base differs from `{{prTarget}}`, pass that actual base as `--target`.
 
 <!-- The orchestrator block states the rule (every change goes through implementer -> reviewer); this is where the PR side of it is enforced. -->
 
@@ -96,18 +77,18 @@ For every live-file `DRIFT`, the JSON provides the approved blob and the exact i
 **The one exception: delegation was genuinely impossible, and it was DECLARED.** The operator forbade subagents for the session, or the `Agent` tool was unavailable. The orchestrator must have said so explicitly, naming the reason. Then, and only then:
 
 - you do NOT abort for the missing review;
-- you MUST run `{{qualityGate.full}}` green yourself in pre-flight (see Gate below) — there is no review evidence to trust;
+- you MUST run the full gate green yourself in pre-flight (see Gate below) — there is no review evidence to trust;
 - the **PR body must state it**, in one line: what was done inline and why delegation was not possible. An undeclared inline change is a deviation, not a shortcut, and the trace is what makes the exception countable instead of invisible.
 
 **No count, no judgement about the diff's content.** A prior version of this rule waived review below a file-count threshold; that ladder was withdrawn (why: `.claude/agents/orchestrator.md`) and has not returned. Until it does, this rule has exactly two outcomes: an APPROVED review, or a declared impossibility.
 
 ### Gate: `{{qualityGate.full}}` green before the PR
 
-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:
+The PR gate is the FULL one, 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` 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.
+- **Reviewed:** the reviewer ran the full gate green in Pass 2 (see `review_<feature>.md`). Skip re-running **only** when the receipt table says `"fresh":true`. The `quality-gate-pre-commit` hook re-runs `fast` on `git commit` and blocks if it fails. Any duplication or security scan beyond the quality gate is the repo's own tooling and only runs if the repo wired it in — don't assume a net that may not be there.
+- **`"fresh":false`:** no trustworthy evidence — YOU run `{{gateRun.full}}` in pre-flight before `gh pr create`. Follow `.claude/skills/verify-before-done/SKILL.md`'s subagent row if it outlives the timeout. When the command is `navori gate <kind>`, its first stdout line is `navori gate <kind>: exit <N> — log <path>`; if that line is missing, the gate did not run: run the literal full gate.
+- **Declared inline (no reviewer):** no review evidence either — run it yourself.
 
 Never open the PR with the gate red.
 
@@ -225,7 +206,7 @@ This is a separate contract from the PR body in the flow above: that one is the
 ## Test plan
 - [ ] <concrete manual check 1>
 - [ ] <concrete manual check 2>
-- [ ] `{{qualityGate.full}}` green
+- [ ] Full quality gate green
 
 ## References
 - Closes #<N> (an issue of THIS repo; omit the line if there is none)

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: 2966
+maxWords: 3046
 ---
 
 # Reviewer Agent
@@ -15,13 +15,11 @@ You are a strict reviewer. Your only function is to **approve or reject**. You d
 
 ### Setup (common to both passes)
 
-1. Ground yourself in `CLAUDE.md` — already in your context when your host injects it; read it from disk ONLY if your host did not inject it. Then read `.navori/state/handoffs/impl_<feature>.md` (when `impl_<feature>` carries `doubts`, read them too: each is a `{file, reason}`), `.navori/state/handoffs/audit_ticket_<ID>.md` and `.navori/state/handoffs/solution_<scope>.md` (whichever exist). When there IS a solution artifact, the diff is judged against the approach it records — an implementation that quietly took a different path is a `SPEC_MISS`, even if the code is good. You do NOT re-open the design itself: whether that approach was the right one was settled in its own phase; your question is whether the code did what was agreed.
+1. Ground yourself in `CLAUDE.md` — already in your context when your host injects it; read it from disk ONLY if your host did not inject it. Then read `.navori/state/handoffs/impl_<feature>.md` (when `impl_<feature>` carries `doubts`, read them too: each is a `{file, reason}`), `.navori/state/handoffs/audit_ticket_<ID>.md` and `.navori/state/handoffs/solution_<scope>.md` (whichever exist). When there IS a solution artifact, the diff is judged against the approach it records — an implementation that quietly took a different path is a `SPEC_MISS`, even if the code is good. You do NOT re-open the design itself: whether that approach was the right one was settled in its own phase; your question is whether the code did what was agreed. Read it by `Chosen solution`, `Boundaries & contracts`, `NOT in scope` and any revision after challenge section — the whole file when those headings are absent.
 2. Identify modified files. Diff against `{{prTarget}}` (the PR's target
    branch), **not** against the fork point: it's the EXACT diff GitHub will show and
-   the one publisher reviews. In most repos the branch you forked from and
-   the branch the PR targets are the same, and the distinction costs you nothing;
-   where they differ, the fork-point diff is NOT the PR's — so the target always
-   wins, and you never have to work out which of the two a given name refers to.
+   the one publisher reviews. Where the fork branch and the PR target differ, the
+   fork-point diff is NOT the PR's: the target always wins.
 
    ```bash
    git status --short
@@ -48,10 +46,9 @@ You are a strict reviewer. Your only function is to **approve or reject**. You d
    receipt. A target-only file would otherwise look like a deletion in this
    worktree and the receipt would sign that phantom deletion.
 
-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.
+3. **Re-review** (a previous `review_<feature>.md` exists): From round 2 on read the prior `review_<feature>.md` (are its issues resolved?) and the delta in `impl_<feature>.md`; re-open `solution_<scope>.md` only on a prior `SPEC_MISS` or design finding, or when the delta touches files outside the prior diff. Don't re-review unchanged code — the Pass 2 table sets the gate, so a `CHANGES_REQUESTED` round stays scoped; the Coverage table stays required on the signing round. If the previous verdict was already `APPROVED` and the diff only moved because of a later edit, that's the **delta re-sign** mode below.
 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.
+5. **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 the full gate (Pass 2) over those bytes. The receipt is then the publisher's reusable verdict.
 
 ### Pass 1 — Spec compliance
 
@@ -77,7 +74,7 @@ Does the diff do EXACTLY what was asked? You don't review style yet.
 
 Does the code match the repo's conventions? Here you do review style/naming/types.
 
-Apply `.claude/skills/review-diff/SKILL.md` — the full checklist by dimensions (types, hardcode, naming, dead code, quality gate, etc.), with severities. When the diff touches auth, permissions, object access, secrets or anything in `{{project.criticalAreas}}`, also apply `.claude/skills/security-invariants/SKILL.md`: it carries the business invariants a static scanner cannot infer from the code. Its CRITICAL/HIGH map to the ≥80 issues below; MEDIUM to the informational observations. On top of that checklist, always validate against `CLAUDE.md` and the orchestrator's "Project rules" — plus any additional rule the orchestrator wrote in the user-section of its prompt.
+Apply `.claude/skills/review-diff/SKILL.md` in full in round 1 (later rounds: the Pre-pass plus sections tied to prior findings) — the checklist by dimension, with severities. When the diff touches auth, permissions, object access, secrets or anything in `{{project.criticalAreas}}`, also apply `.claude/skills/security-invariants/SKILL.md`: it carries the business invariants a static scanner cannot infer from the code. Its CRITICAL/HIGH map to the ≥80 issues below; MEDIUM to the informational observations. On top of that checklist, always validate against `CLAUDE.md` and the orchestrator's "Project rules" — plus any additional rule the orchestrator wrote in the user-section of its prompt.
 
 **Quality gate** (mandatory green, run this turn):
 
@@ -85,21 +82,28 @@ 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:
+If the result contains `"gateKind":"scoped"`, run `{{navori.scopedGate}}` plus the milestone's `A<n>` commands instead. If `"gateKind":"full"`, the gate fails, or there is no spec line, apply the table below.
+
+| Round outcome | Gate evidence |
+|---|---|
+| Ends in `CHANGES_REQUESTED` (any issue ≥80) | `{{navori.scopedGate}}` plus the assigned `A<n>` commands. Do NOT run the full gate. |
+| About to sign `APPROVED` (including delta re-sign) | The full gate, over the bytes you sign: |
 ```bash
-{{qualityGate.full}}
+{{gateRun.full}}
 ```
+The full gate runs once, on the round that signs; a rejected round never spends it.
+
+If `navori gate <kind>` prints no first line `navori gate <kind>: exit <N> — log <path>`, it did not run (an old navori prints help and exits 0): run the literal `{{qualityGate.fast}}` or `{{qualityGate.full}}` instead. Read only the verdict.
 
 <!-- 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.
+Read the verdict 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.
+Start `{{gateRun.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. The full gate runs only on the round about to sign `APPROVED`; a round ending in `CHANGES_REQUESTED` uses the scoped gate and the assigned `A<n>` commands, and runs no full gate.
 <!-- /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.
+Read the verdict 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 `{{gateRun.full}}` in the foreground with the Bash tool's max `timeout`; if the full gate 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. The full gate runs only on the round about to sign `APPROVED`; a round ending in `CHANGES_REQUESTED` uses the scoped gate and the assigned `A<n>` commands, and runs no full gate.
 <!-- /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.
 
 **Partial verdict:**
 
@@ -108,7 +112,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. 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.
+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`; `--gate-ran full` means the full gate ran over the signed bytes, since signing needs it; 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
@@ -122,7 +126,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.
+3. **Re-run the full gate** (Pass 2), over the live bytes, since this round is about to re-sign. 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. 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.
@@ -172,7 +176,7 @@ An unanswered doubt, or one concluded `issue`, follows the normal severity and s
 ### Quality gate (run this turn)
 | Check | Status | Evidence |
 |---|---|---|
-| `{{qualityGate.full}}` | [x] / [ ] | <output or exit code from this turn> |
+| Gate (Pass 2 table: scoped on `CHANGES_REQUESTED`, full on `APPROVED`) | [x] / [ ] | <output or exit code from this turn> |
 | Failure attribution | [x] / [ ] | <state per failure (per `verify-before-done`) + the run over `origin/{{prTarget}}` that demonstrates it, this turn> |
 
 ### Conventions (CLAUDE.md + orchestrator's Project rules)
@@ -233,10 +237,10 @@ CHANGES_REQUESTED -> .navori/state/handoffs/review_<feature>.md
 - ❌ Never skip Pass 1 (spec compliance). If the code is pretty but doesn't do what was asked, it's `CHANGES_REQUESTED`.
 - ❌ Never include as a blocker (in "Issues ≥80") a finding with confidence <80.
 - ✅ Apply `.claude/skills/verify-before-done/SKILL.md` before marking APPROVED: each `[x]` must be backed by evidence run this turn (not from the implementer's cached report).
-- ❌ Never approve with `{{qualityGate.full}}` red.
+- ❌ Never approve with the full gate red.
 - ❌ Never approve a failure legitimately classified *introduced (demonstrated)* per `verify-before-done`'s Failure attribution, and never classify one *pre-existing* by diff location alone.
 - ❌ Never approve new code with explicit or implicit `any` without a valid `// any justified: <reason>`.
-- ❌ Don't block or escalate a screen change to a human for lack of browser validation — the default gate is the diff + tests; require a visual check only when the user explicitly asked for one.
+
 - ✅ On APPROVED, write the content receipt (`.navori/state/handoffs/receipt.txt`) so the commit is bound to the reviewed bytes.
 - ❌ In SDD features (with `tasks.md`), never approve if some `R<n>` in the batch has no traceable test covering it.
 - ❌ You never edit the code. You only point out what fails and where.

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

@@ -58,7 +58,7 @@ navori_audit_record_metadata() {
   fi
   command -v navori >/dev/null 2>&1 || return 0
   case "${nv_engine:-}" in
-    claude | codex) navori_audit_host=$nv_engine ;;
+    claude | codex | pi) navori_audit_host=$nv_engine ;;
     *) case "$navori_audit_script" in *".codex/hooks/"* | *".codex/scripts/"*) navori_audit_host=codex ;; *) navori_audit_host=claude ;; esac ;;
   esac
   # The writer assigns eventId/wireVersion before first persistence. Replay
@@ -99,7 +99,7 @@ navori_audit_log() {
      + (if (.tool_use_id|id) then {toolUseId:.tool_use_id} else {} end)
      + (if (["Bash","Edit","Read","Write","Agent","Task","NotebookEdit"]|index($tool)) != null then {tool:$tool} else {} end)
      + (if $reason == "" then {}
-        elif (["oversize","no-verify","force-push-base","rm-root","rm-var","no-preserve-root","fork-bomb","block-device","managed-rewrite","binary-missing","plan-denied","subcommand-unavailable"]|index($reason)) != null then {reason:$reason}
+        elif (["oversize","no-verify","force-push-base","rm-root","rm-var","no-preserve-root","fork-bomb","block-device","managed-rewrite","binary-missing","plan-denied","subcommand-unavailable","native-hook"]|index($reason)) != null then {reason:$reason}
         else {reason:"unspecified"} end)
      + (($kind | if . == "" then (if $verdict == "block" then "hard" elif $verdict == "ask" then "ask" else "" end) else . end) as $k
         | if (["hard","ask","advisory"]|index($k)) != null then {kind:$k} else {} end)' 2>/dev/null) || return 0

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

@@ -25,7 +25,7 @@
 # the ORIGINAL signal with its default disposition — so the process still dies
 # from what it was sent instead of continuing as if nothing happened — and never
 # changes what the host does with the tool call. It is deliberately NOT a
-# process-tree kill: the gate's own child (`pnpm lint`, `semgrep`, `jscpd`)
+# process-tree kill: the gate's own child (`pnpm lint`, a scanner)
 # already outlives the hook today, and killing someone else's build from an
 # observer is a decision of its own (#797, residue 3).
 #