navori
navori

handoff

Valida el handoff del implementer antes de que el orquestador despache al siguiente rol.

Uso 

navori handoff <check|log-review> <feature> [--for scribe] [--dir <path>] [--cwd <checkout>] [--json]

Flags

--for scribe Además de existencia/parseo/feature, exige que --cwd coincida con el worktree y la rama del handoff, y valida cada markdownRequests[].path. Sin esta flag valida solo lo que el orquestador necesita (existe, parsea, es del feature pedido).
--dir <path> Directorio de progreso; por defecto .claude/progress.
--cwd <checkout> Checkout a validar; por defecto el directorio actual.
--json Emite el contrato machine-readable.

Ejemplos

Antes de despachar al scribe o al reviewer

navori handoff check checkout --json

Preflight del scribe antes de escribir o commitear

navori handoff check checkout --for scribe --cwd <checkout> --json

Notas

  • El JSON trae `status` (ok/findings/error), `failures` y `warnings` con un `check` nombrado por regla (exists/parse/feature/worktree/branch/path para las fallas; head/legacy-md para los avisos), y el `worktree`/`branch` que el handoff registró.
  • Exit codes como `receipt`: 0 ok, 2 findings (una comprobación falló), 1 error (git o I/O, nunca una falla de validación).
  • `log-review <feature>` valida review_<feature>.json y agrega a findings.jsonl los hallazgos con score >= 50, sin duplicar los ya registrados. Acepta --dir, --cwd y --json; sale con 1 si el sidecar no es válido.
  • Sin `head` en el handoff el resultado sigue siendo `ok`, solo con un aviso — nunca bloquea.
  • Con `harness.scribeOwnsMarkdown: false` valida `impl_<feature>.md` en su lugar (existe, no está vacío, tiene una línea `Status:`), ligado al feature solo por el nombre del archivo.