navori
navori

master

Plan maestro de proyecto: gestiona etapas, fases, partes y cierre (spec 0034).

Uso 

navori master <init|mode|ux|status|check|advance|part|template|close|delivery-*> [opciones] [--cwd <path>]

Flags

<slug> Slug en kebab-case para la primera etapa (init); obligatorio solo cuando no hay ninguna etapa activa.
<template|en-curso> Modo de la etapa (mode). Solo se puede fijar en fase 'context' y solo en la primera etapa — de la etapa 2 en adelante el modo queda registrado como 'en-curso' automáticamente.
ux <none|md|md-json> Registra la decisión del contrato UX de la etapa. Solo se puede fijar en la fase 'ux' y aún no está disponible para el modo entregas.
delivery-slice --part <P<n>> [--refresh --approved-by user] Proyecta una parte autorizada en un workplan. --refresh reinicia los criterios pendientes y exige --approved-by user.
delivery-queue --delivery <E<n>> --parts <P1,P2> --approved-by user [--transition replacement|continuation] Autoriza una cola acotada de partes para una entrega; las partes se validan contra parts.json.
delivery-check | delivery-baseline --approved-by user | delivery-revoke --approved-by user Revisa sin escribir si la preparación está lista (exit 1 con bloqueos), registra la aprobación explícita de la base o revoca la autoridad de la cola.
delivery-criterion --part <P<n>> --criterion <A<n>> [--approved-by user] Consume la evidencia del host o, solo en criterios manuales, una atestación explícita (--approved-by user).
delivery-review --part <P<n>> --report <archivo> --envelope <archivo> [--approved-by user] Registra la revisión técnica atestada por el operador; el CLI verifica contenido y recibo, no la identidad del revisor ni la ejecución del QA.
delivery-present --delivery <E<n>> Registra la identidad de una demo ya revisada técnicamente; no es el consentimiento del cliente.
delivery-decision --delivery <E<n>> --identity <id> --decision <accepted|declined|deferred|discarded> [--reason <texto>] [--reference <ref>] --approved-by user Registra la decisión del cliente sobre una identidad revisada; toda decisión distinta de accepted exige --reason.
delivery-publication --delivery <E<n>> --identity <id> --kind <release|deploy> --reference <ref> --approved-by user Atesta la referencia de release o deploy de una identidad aceptada, sin ejecutar el despliegue (un merge no cuenta).
status [--json|--line] Muestra la etapa y fase actuales; sin opciones regenera STATUS.md. --json y --line son de solo lectura.
check [--stage <NN-slug>|--part <P<n>>|--fit [--json]] Valida la salida de la fase activa, una etapa cerrada, una spec de parte o los criterios verificables para convertir a una sola spec.
advance Valida la fase activa y avanza una fase cuando se cumplen sus requisitos.
part <P<n>> [--state <estado>] [--reason <texto>] [--spec <ruta>] [--issue <n>] Actualiza una parte; --accept, --command, --result y --approved-by registran evidencia de aceptación.
template <nombre> [--part <P<n>>] Imprime una plantilla; --part rellena la plantilla issue desde parts.json.
close [--convert <ruta>|--abandon] [--reason <texto>] Cierra, convierte o abandona la etapa activa; las etapas cerradas son de solo lectura.
--cwd <path> Repo a operar; por defecto el directorio actual.

Ejemplos

Abrir la primera etapa

$ navori master init mvp
Etapa 01-mvp · fase context
Señal: commits=3 primerCommit=2026-08-01 archivosCambiados=12 framework=next sugerido=template

Registrar el modo tras revisar la señal

navori master mode template

Notas

  • init crea <sdd.specsDir>/_master/<NN>-<slug>/ con context/raw/ (con su propio .gitignore, fuera de git sin importar gitignoreHarness), context/md/ y plans/, enciende harness.masterPlan y aplica el render.
  • Con una etapa ya activa, init (con o sin slug) no crea otra: completa lo que le falte a la activa, reporta su etapa y fase, y sale con 1 si se pidió un slug.
  • Falla si sdd.enabled es false, nombrando la clave que hay que activar.
  • check --stage inspecciona etapas cerradas; las operaciones que mutan estado solo actúan sobre la etapa activa.
  • Los subcomandos delivery-* son del modo entregas: validan las partes contra parts.json y toda aprobación exige --approved-by user. El hook master-accept-confirm pide confirmación humana antes de registrar una aceptación; un agente no puede aprobarse a sí mismo.