navori
navori

master

Project master plan: manages stages, phases, parts, and closure (spec 0034).

Usage 

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

Flags

<slug> kebab-case slug for the first stage (init); required only when no stage is active.
<template|en-curso> The stage's mode (mode). Can only be set in phase 'context' and only for the first stage — from stage 2 onward the mode is registered as 'en-curso' automatically.
ux <none|md|md-json> Records the stage's UX contract decision. It can only be set in phase 'ux' and is not available for deliveries mode yet.
delivery-slice --part <P<n>> [--refresh --approved-by user] Projects an authorized part into a workplan. --refresh resets pending criteria and requires --approved-by user.
delivery-queue --delivery <E<n>> --parts <P1,P2> --approved-by user [--transition replacement|continuation] Authorizes a bounded queue of parts for a delivery; the parts are validated against parts.json.
delivery-check | delivery-baseline --approved-by user | delivery-revoke --approved-by user Checks without writing whether preparation is ready (exit 1 with blockers), records the explicit baseline approval, or revokes the queue authority.
delivery-criterion --part <P<n>> --criterion <A<n>> [--approved-by user] Consumes host evidence or, for manual criteria only, an explicit attestation (--approved-by user).
delivery-review --part <P<n>> --report <file> --envelope <file> [--approved-by user] Records the operator-attested technical review; the CLI verifies content and receipt, not the reviewer's identity or QA execution.
delivery-present --delivery <E<n>> Records the identity of a demo that is already technically reviewed; it is not client consent.
delivery-decision --delivery <E<n>> --identity <id> --decision <accepted|declined|deferred|discarded> [--reason <text>] [--reference <ref>] --approved-by user Records the client's decision on a reviewed identity; any decision other than accepted requires --reason.
delivery-publication --delivery <E<n>> --identity <id> --kind <release|deploy> --reference <ref> --approved-by user Attests the release or deploy reference of an accepted identity without running the deployment (a merge does not count).
status [--json|--line] Shows the current stage and phase; without options, regenerates STATUS.md. --json and --line are read-only.
check [--stage <NN-slug>|--part <P<n>>|--fit [--json]] Validates the active phase exit, a closed stage, a part spec, or the verifiable single-spec fit criteria.
advance Validates the active phase and advances when its requirements are met.
part <P<n>> [--state <state>] [--reason <text>] [--spec <path>] [--issue <n>] Updates a part; --accept, --command, --result, and --approved-by record acceptance evidence.
template <name> [--part <P<n>>] Prints a template; --part fills the issue template from parts.json.
close [--convert <path>|--abandon] [--reason <text>] Closes, converts, or abandons the active stage; closed stages are read-only.
--cwd <path> Repo to operate on; defaults to the current directory.

Examples

Open the first stage

$ navori master init mvp
Stage 01-mvp · phase context
Signal: commits=3 firstCommit=2026-08-01 filesChanged=12 framework=next suggested=template

Register the mode after reviewing the signal

navori master mode template

Notes

  • init creates <sdd.specsDir>/_master/<NN>-<slug>/ with context/raw/ (its own .gitignore, out of git regardless of gitignoreHarness), context/md/ and plans/, turns on harness.masterPlan and applies the render.
  • With a stage already active, init (with or without a slug) does not create a second one: it completes whatever the active one is missing, reports its stage and phase, and exits 1 if a slug was passed.
  • Fails when sdd.enabled is false, naming the key to turn on.
  • check --stage inspects closed stages; state-changing operations act only on the active stage.
  • The delivery-* subcommands belong to deliveries mode: they validate parts against parts.json and every approval requires --approved-by user. The master-accept-confirm hook asks a human to confirm before an acceptance is recorded; an agent cannot approve itself.