[navori](https://ulisescm.github.io/navori-harness/es/docs/master) · Español

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

## Comandos 

[navori init](https://ulisescm.github.io/navori-harness/es/docs/init)[navori add](https://ulisescm.github.io/navori-harness/es/docs/add)[navori remove](https://ulisescm.github.io/navori-harness/es/docs/remove)[navori adopt](https://ulisescm.github.io/navori-harness/es/docs/adopt)[navori configure](https://ulisescm.github.io/navori-harness/es/docs/configure)[navori preset](https://ulisescm.github.io/navori-harness/es/docs/preset)[navori render](https://ulisescm.github.io/navori-harness/es/docs/render)[navori sync](https://ulisescm.github.io/navori-harness/es/docs/sync)[navori update](https://ulisescm.github.io/navori-harness/es/docs/update)[navori refresh](https://ulisescm.github.io/navori-harness/es/docs/refresh)[navori scan](https://ulisescm.github.io/navori-harness/es/docs/scan)[navori doctor](https://ulisescm.github.io/navori-harness/es/docs/doctor)[navori status](https://ulisescm.github.io/navori-harness/es/docs/status)[navori bench](https://ulisescm.github.io/navori-harness/es/docs/bench)[navori codex](https://ulisescm.github.io/navori-harness/es/docs/codex)[navori audit](https://ulisescm.github.io/navori-harness/es/docs/audit)[navori backup](https://ulisescm.github.io/navori-harness/es/docs/backup)[navori migrations](https://ulisescm.github.io/navori-harness/es/docs/migrations)[navori registry](https://ulisescm.github.io/navori-harness/es/docs/registry)[navori workspace](https://ulisescm.github.io/navori-harness/es/docs/workspace)[navori ticket](https://ulisescm.github.io/navori-harness/es/docs/ticket)[navori dominio](https://ulisescm.github.io/navori-harness/es/docs/dominio)[navori tools](https://ulisescm.github.io/navori-harness/es/docs/tools)[navori receipt](https://ulisescm.github.io/navori-harness/es/docs/receipt)[navori plan](https://ulisescm.github.io/navori-harness/es/docs/plan)[navori spec](https://ulisescm.github.io/navori-harness/es/docs/spec)[navori handoff](https://ulisescm.github.io/navori-harness/es/docs/handoff)[navori master](https://ulisescm.github.io/navori-harness/es/docs/master)[navori gate](https://ulisescm.github.io/navori-harness/es/docs/gate) Sin manual aún. Esta página es la referencia. 

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.


