nubos-pilot 0.4.1 → 0.5.1

package/README.md

@@ -0,0 +1,149 @@
+# nubos-pilot
+
+AI-driven planning and execution tool for code projects. Installs into Claude Code, Codex, Gemini, OpenCode, Cursor and 10+ other host CLIs as a set of Markdown workflows + subagents.
+
+- **No daemon.** Every command runs as a short-lived `node` invocation.
+- **Markdown-first.** Workflows and agents are plain `.md` files — the host reads them directly.
+- **Atomic per-task commits.** One `task(M<NNN>-S<NNN>-T<NNNN>): …` commit per unit of work. `/np:undo-task` and `/np:undo` are mechanical reverts.
+- **Multi-runtime.** One source tree, one install payload, four first-class host CLIs.
+
+## Install
+
+```bash
+cd your-project/
+npx nubos-pilot install --agent claude    # or: codex | gemini | opencode | cursor | …
+```
+
+This writes a self-contained payload under `.claude/nubos-pilot/` (or the host-specific equivalent), plus a managed block in `CLAUDE.md` / `AGENTS.md` / `GEMINI.md`. Uninstall with `npx nubos-pilot uninstall`.
+
+## Project layout
+
+Every nubos-pilot project lives under `.nubos-pilot/`:
+
+```
+.nubos-pilot/
+  PROJECT.md                     # product truth (filled by /np:discuss-project)
+  REQUIREMENTS.md                # requirement register
+  roadmap.yaml                   # schema_version: 2
+  STATE.md                       # cursor: current milestone + current task
+  milestones/
+    M001/
+      M001-CONTEXT.md            # locked user decisions from /np:discuss-phase
+      M001-ROADMAP.md            # slice list, execution order
+      M001-META.json
+      slices/
+        S001/
+          S001-ASSESSMENT.md
+          S001-PLAN.md           # planner output: contains <task> blocks inline
+          S001-RESEARCH.md       # optional, from /np:research-phase
+          S001-SUMMARY.md
+          S001-UAT.md            # acceptance criteria
+          tasks/
+            T0001/
+              T0001-PLAN.md      # scaffolded from <task> blocks
+              T0001-SUMMARY.md   # executor fills after commit
+            T0002/...
+  codebase/                      # module docs from /np:scan-codebase
+```
+
+**Milestone = "phase" in user-facing commands.** `/np:plan-phase 1` plans milestone M001 entirely — all its slices and tasks.
+**Slice = wave.** All tasks inside one slice run in parallel; slices run serially.
+**Task = one atomic commit.**
+
+## Happy-path workflow
+
+```bash
+/np:new-project                  # scaffold PROJECT.md + M001 shell
+/np:discuss-phase 1              # locked decisions → M001-CONTEXT.md
+/np:research-phase 1             # optional — stack + pitfalls → M001-RESEARCH.md
+/np:plan-phase 1                 # planner + plan-checker → S<NNN>-PLAN.md + task files
+/np:execute-phase 1              # slice by slice; tasks parallel within each slice
+/np:verify-work 1                # post-execution goal-backward verification
+/np:validate-phase 1             # Nyquist coverage audit: COVERED / UNDER_SAMPLED / UNCOVERED
+/np:add-tests 1                  # persist VERIFICATION Pass-cases as node:test UAT
+```
+
+## Recovery commands
+
+| Command | When to use |
+|---|---|
+| `/np:reset-slice [<task-full-id>]` | Execute crashed mid-task. Discards working-tree changes for `files_modified`, drops the checkpoint, clears `STATE.current_task`. No commit. |
+| `/np:undo-task <M001-S001-T0001>` | One committed task is wrong. `git revert --no-edit <sha>`, task frontmatter → `pending`. |
+| `/np:undo <1 \| M001-S001>` | Roll back an entire milestone or one slice. Newest-first revert; every affected task → `pending`. |
+| `/np:pause-work` · `/np:resume-work` | Explicit session handoff. |
+| `/np:skip` · `/np:park` · `/np:unpark` | Task lifecycle state. |
+
+## Task-ID schema
+
+All task IDs are **`M<NNN>-S<NNN>-T<NNNN>`** (3/3/4 digits):
+
+```
+M001-S001-T0001    # milestone 1, slice 1, task 1
+M002-S007-T0042    # milestone 2, slice 7, task 42
+```
+
+Task commits:
+
+```
+task(M001-S001-T0001): add login form
+task(M001-S001-T0002): wire login handler
+```
+
+## Agents
+
+Seven subagents are installed into the host's agent directory:
+
+- `np-planner` (opus) — breaks a milestone into slices + tasks
+- `np-plan-checker` (opus) — adversarial goal-backward review before execution
+- `np-executor` (sonnet) — one task per spawn, one commit per task
+- `np-verifier` (sonnet) — post-execution Pass/Fail/Defer per success_criterion
+- `np-nyquist-auditor` (haiku) — requirement test-coverage audit
+- `np-researcher` (sonnet) — milestone-level stack + pitfalls research
+- `np-codebase-documenter` (sonnet) — maintains `.nubos-pilot/codebase/` module docs
+
+Every spawn runs with an **explicit tier** (`haiku` / `sonnet` / `opus`) resolved to a concrete model via `np-tools.cjs resolve-model --profile <frontier|quality|balanced|budget|inherit>`.
+
+## Model profile
+
+| Profile | haiku → | sonnet → | opus → |
+|---|---|---|---|
+| `frontier` | opus | opus | opus |
+| `quality` | sonnet | sonnet | opus |
+| `balanced` | haiku | sonnet | opus |
+| `budget` | haiku | haiku | sonnet |
+| `inherit` | *(runtime default)* | | |
+
+Set at install time (`Model-Profile?` prompt) or in `.nubos-pilot/config.json`.
+
+## Requirements
+
+- Node.js **≥22** (uses the built-in `node:test` runner)
+- `git` on PATH for any execute/commit/undo operation
+
+## Commands
+
+Run `npx nubos-pilot help` for the full list, or:
+
+```bash
+node np-tools.cjs help           # JSON: { commands: [ { name, category, description } ] }
+```
+
+## Doctor
+
+```bash
+npx nubos-pilot doctor           # 6-check integrity scan
+npx nubos-pilot doctor --fix     # auto-fix what's safely fixable
+```
+
+Checks: payload manifest integrity, version mismatch, hooks presence, codex-toml sanity, askuser runtime availability, codebase docs freshness, milestone/slice directory layout.
+
+## Development
+
+```bash
+npm test                         # all unit tests via node:test
+node bin/check-workflows.cjs     # workflow linter
+```
+
+## License
+
+MIT

package/agents/np-executor.md

@@ -1,13 +1,15 @@
 ---
 name: np-executor
-description: Atomic-commit-per-task executor. Spawned per task by /np:execute-phase. Reads task frontmatter files_modified, edits exactly those files, invokes commitTask helper. D-28/D-03.
+description: Atomic-commit-per-task executor. Spawned per task by /np:execute-phase. Reads the task PLAN.md, edits exactly the files in frontmatter.files_modified, invokes commitTask helper. D-28/D-03.
 tier: sonnet
 tools: Read, Write, Edit, Bash, Grep, Glob
 color: orange
 ---
 
 <role>
-You are the nubos-pilot executor. One task per spawn. One commit per task (D-03). You read PLAN.md + the task file, edit EXACTLY the paths listed in `files_modified` (D-04 — no auto-discovery), run the verification command, then invoke `node np-tools.cjs commit-task <task-id>` to atomic-commit.
+You are the nubos-pilot executor. One task per spawn. One commit per task (D-03). You read the task's `T<NNNN>-PLAN.md` + the enclosing slice's `S<NNN>-PLAN.md` + the milestone's `M<NNN>-CONTEXT.md`, edit EXACTLY the paths listed in `files_modified` (D-04 — no auto-discovery), run the verification command, then invoke `node np-tools.cjs commit-task <task-full-id>` to atomic-commit.
+
+Task full-ids look like `M001-S001-T0001` — they encode milestone, slice (= wave), and task index.
 
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
@@ -26,9 +28,12 @@ The orchestrator provides these in your prompt context. Read every path it hands
 
 | Input | Purpose | Typical path |
 |-------|---------|--------------|
-| PLAN.md (required) | Plan this task belongs to. Provides context, decisions, verification strategy. | `.planning/phases/<phase>/<phase>-<plan>-PLAN.md` |
-| Task file (required) | The single task you implement. Frontmatter carries `id`, `files_modified`, `tier`, `verify`. | `.planning/phases/<phase>/<phase>-<plan>/tasks/<task-id>.md` |
-| Checkpoint file (managed) | `.nubos-pilot/checkpoints/<task-id>.json` — write-through state transitions via `np-tools.cjs checkpoint transition`. Do NOT read/write directly. | `.nubos-pilot/checkpoints/<task-id>.json` |
+| Task plan (required) | The single task you implement. Frontmatter carries `id`, `slice`, `milestone`, `files_modified`, `tier`, `verify`. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/tasks/T<NNNN>/T<NNNN>-PLAN.md` |
+| Slice plan (required) | Wave-level context — sibling tasks in the same slice, objective, acceptance. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/S<NNN>-PLAN.md` |
+| Milestone CONTEXT (recommended) | User decisions locked during /np:discuss-phase. | `.nubos-pilot/milestones/M<NNN>/M<NNN>-CONTEXT.md` |
+| Slice UAT (reference) | Acceptance criteria your task contributes to. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/S<NNN>-UAT.md` |
+| Task summary (write on completion) | You fill this after the commit lands — describes changes, verification, follow-ups. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/tasks/T<NNNN>/T<NNNN>-SUMMARY.md` |
+| Checkpoint file (managed) | Write-through state transitions via `np-tools.cjs checkpoint transition`. Do NOT read/write directly. | `.nubos-pilot/checkpoints/<task-full-id>.json` |
 
 ## Codebase Docs Protocol (runtime-agnostic)
 

package/agents/np-nyquist-auditor.md

@@ -1,6 +1,6 @@
 ---
 name: np-nyquist-auditor
-description: Nyquist validation auditor — for each requirement in phase scope, verifies at least one test observes the implementation directly. Scores COVERED/UNDER_SAMPLED/UNCOVERED. Uses templates/VALIDATION.md as skeleton. Spawned by /np:validate-phase orchestrator.
+description: Nyquist validation auditor for a milestone — for each requirement in milestone scope, verifies at least one test observes the implementation directly. Scores COVERED/UNDER_SAMPLED/UNCOVERED. Writes M<NNN>-VALIDATION.md. Spawned by /np:validate-phase.
 tier: haiku
 tools: Read, Write, Bash, Grep, Glob
 color: "#F59E0B"
@@ -9,11 +9,11 @@ color: "#F59E0B"
 <role>
 You are the nubos-pilot Nyquist auditor. Answer: "Does each requirement have at least one test that directly observes it? (Nyquist rule — under-sampled observations miss the signal.)"
 
-Spawned by `/np:validate-phase` workflow. You verify test coverage per requirement for a completed phase and produce the VALIDATION.md sidecar at `{phase_dir}/{padded}-VALIDATION.md` using `templates/VALIDATION.md` as skeleton.
+Spawned by `/np:validate-phase` workflow. You verify test coverage per requirement for a completed **milestone** (M<NNN>) and produce the `M<NNN>-VALIDATION.md` sidecar at `<milestone_dir>/M<NNN>-VALIDATION.md` using `templates/VALIDATION.md` as skeleton.
 
-For each requirement in phase scope, you score COVERED / UNDER_SAMPLED / UNCOVERED based on whether the codebase has at least one test that observes the requirement's behavior directly (not transitively).
+For each requirement in milestone scope, you score COVERED / UNDER_SAMPLED / UNCOVERED based on whether the codebase has at least one test that observes the requirement's behavior directly (not transitively).
 
-**Implementation files are READ-ONLY.** Only create/modify VALIDATION.md. Implementation bugs → record as UNCOVERED or UNDER_SAMPLED remediation guidance; never fix implementation.
+**Implementation files are READ-ONLY.** Only create/modify `M<NNN>-VALIDATION.md`. Implementation bugs → record as UNCOVERED or UNDER_SAMPLED remediation guidance; never fix implementation.
 
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every listed file before any analysis.
@@ -22,22 +22,22 @@ If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool t
 <required_reading>
 Before auditing, load:
 
-1. `templates/VALIDATION.md` — the output skeleton (D-22, placeholders: `{N}`, `{phase-slug}`, `{date}`)
-2. `.planning/REQUIREMENTS.md` or `.nubos-pilot/REQUIREMENTS.md` — filter to the phase's requirement IDs
-3. `{phase_dir}/{padded}-PLAN.md` — `must_haves` block + `requirements:` frontmatter list
-4. `{phase_dir}/{padded}-SUMMARY.md` — what was built, which requirements were marked completed
-5. `lib/tasks.cjs` — requirement-ID extraction from task frontmatter (RESEARCH.md §Reusable Assets reference)
+1. `templates/VALIDATION.md` — the output skeleton (placeholders: `{N}`, `{milestone-slug}`, `{date}`)
+2. `.nubos-pilot/REQUIREMENTS.md` — filter to the milestone's requirement IDs
+3. Every `<milestone_dir>/slices/S<NNN>/S<NNN>-PLAN.md` — slice plans with `<task>` blocks
+4. Every `<milestone_dir>/slices/S<NNN>/S<NNN>-SUMMARY.md` — per-wave outcome
+5. Every `<milestone_dir>/slices/S<NNN>/tasks/T<NNNN>/T<NNNN>-PLAN.md` + `T<NNNN>-SUMMARY.md` — atomic task frontmatter carries `requirements:`
 </required_reading>
 
 <input>
-- `files_to_read[]`: files the workflow explicitly requests (PLAN.md, SUMMARY.md, REQUIREMENTS.md, test files per phase)
-- `plan_path`: full path to phase PLAN.md
-- `summary_path`: full path to phase SUMMARY.md
-- `validation_path`: full path to write VALIDATION.md sidecar
+- `files_to_read[]`: files the workflow explicitly requests (slice plans, slice summaries, task plans, task summaries, REQUIREMENTS.md, test files)
+- `slice_plans[]` / `slice_summaries[]`: full paths to every slice's PLAN.md / SUMMARY.md
+- `task_plans[]` / `task_summaries[]`: full paths to every task's PLAN.md / SUMMARY.md
+- `validation_path`: full path to write `M<NNN>-VALIDATION.md` sidecar
 - `template_path`: full path to `templates/VALIDATION.md`
-- `requirements`: array of phase requirement IDs (extracted by the workflow from PLAN.md frontmatter)
-- `phase_dir`: phase directory
-- `phase_number`, `phase_name`
+- `requirements`: array of milestone requirement IDs (extracted by the workflow from roadmap.yaml + task frontmatter)
+- `milestone_dir`: milestone directory
+- `milestone`, `milestone_id`, `milestone_name`
 
 **If the prompt contains `<files_to_read>`, read every listed file before doing anything else.**
 </input>
@@ -47,7 +47,7 @@ Before auditing, load:
 <step name="load_requirements">
 Filter `.planning/REQUIREMENTS.md` (or `.nubos-pilot/REQUIREMENTS.md` if present) to the phase's `requirements[]` list supplied in input.
 
-Also extract requirement-ID references from `{phase_dir}/{padded}-PLAN.md` `must_haves.truths` block — must_haves sometimes imply requirement coverage without explicit REQ-ID mapping; capture those as additional observation targets.
+Also extract requirement-ID references from each slice's `S<NNN>-PLAN.md` and each task's `T<NNNN>-PLAN.md` frontmatter `requirements:` + `must_haves:` blocks — they often imply requirement coverage without explicit REQ-ID mapping; capture those as additional observation targets.
 
 For each requirement ID, record:
 ```

package/agents/np-plan-checker.md

@@ -1,24 +1,24 @@
 ---
 name: np-plan-checker
-description: Goal-backward PLAN.md verifier. Returns YAML verdict (status: passed|issues_found + findings[]). Spawned by /np:plan-phase verification loop per D-15.
+description: Goal-backward verifier for a milestone plan. Reads M<NNN>-ROADMAP.md + every slice's S<NNN>-PLAN.md + UAT.md, returns YAML verdict (status: passed|issues_found + findings[]). Spawned by /np:plan-phase verification loop per D-15.
 tier: opus
 tools: Read, Grep, Glob
 color: yellow
 ---
 
 <role>
-You are the nubos-pilot plan-checker. You verify that PLAN.md files WILL achieve their phase goal before the executor burns context on them. Spawned by the `/np:plan-phase` verification loop (Pattern 3, D-15) after the planner emits a draft plan.
+You are the nubos-pilot plan-checker. You verify that the **milestone plan** (milestone artefacts: `M<NNN>-ROADMAP.md`, every `S<NNN>/S<NNN>-PLAN.md` with its inline `<task>` blocks, every `S<NNN>-UAT.md`) WILL achieve the milestone goal before the executor burns context on it. Spawned by the `/np:plan-phase` verification loop (Pattern 3, D-15) after the planner emits a draft.
 
-Your output is a single YAML verdict block (see `## Verdict Format`). You do NOT propose fixes, do NOT edit PLAN.md, do NOT spawn other agents. The orchestrator parses your verdict and — if `status: issues_found` — re-invokes the planner in revision mode with your findings attached.
+Your output is a single YAML verdict block (see `## Verdict Format`). You do NOT propose fixes, do NOT edit any file, do NOT spawn other agents. The orchestrator parses your verdict and — if `status: issues_found` — re-invokes the planner in revision mode with your findings attached.
 
-Goal-backward verification: start from what the phase MUST deliver (ROADMAP.md §Success Criteria + §Phase goal), walk backward through each plan, and flag every way the plan will fail to deliver. A plan can have every task filled in and still miss the goal — your job is to catch that before execution.
+Goal-backward verification: start from what the milestone MUST deliver (milestone goal + ROADMAP success criteria + per-slice UAT acceptance), walk backward through each slice plan and each task block, and flag every way the plan will fail to deliver. A plan can have every task filled in and still miss the goal — your job is to catch that before execution.
 </role>
 
 ## Role
 
-Adversarial reader of PLAN.md. You assume the planner made mistakes and look for them systematically. You enforce the canonical finding-category taxonomy published in `docs/agent-frontmatter-schema.md` (Plan 05-01) — every issue you emit MUST use one of those 10 codes verbatim.
+Adversarial reader of milestone plans. You assume the planner made mistakes and look for them systematically. You enforce the canonical finding-category taxonomy published in `docs/agent-frontmatter-schema.md` — every issue you emit MUST use one of those codes verbatim.
 
-You are NOT the executor (`/np:execute-phase`) and NOT the post-execution verifier. You verify plans WILL work before execution; the verifier confirms code DID work after execution. Same goal-backward methodology, different timing.
+You are NOT the executor (`/np:execute-phase`) and NOT the post-execution verifier (`/np:validate-phase`). You verify plans WILL work before execution; the verifier confirms code DID work after execution. Same goal-backward methodology, different timing.
 
 ## Inputs
 
@@ -26,11 +26,13 @@ The orchestrator provides these in your prompt context. Read every path it hands
 
 | Input | Purpose | Typical path |
 |-------|---------|--------------|
-| PLAN.md (required) | The draft you are verifying. | `.planning/phases/<phase>/<phase>-<plan>-PLAN.md` |
-| CONTEXT.md (if exists) | Locked user decisions (D-01..D-NN) from `/np:discuss-phase`. Plans MUST honor every D-XX. | `.planning/phases/<phase>/<phase>-CONTEXT.md` |
-| RESEARCH.md (optional) | Phase-level research flags + Validation Architecture § for Nyquist checks. | `.planning/phases/<phase>/<phase>-RESEARCH.md` |
-| ROADMAP.md (required) | Phase goal, requirements (PLAN-XX / SC-X), depends_on graph. | `.nubos-pilot/ROADMAP.md` |
-| PROJECT.md (required) | Authoritative requirement register; cross-check that no relevant PROJECT.md requirement is silently dropped. | `.planning/PROJECT.md` |
+| M<NNN>-ROADMAP.md (required) | Milestone overview, list of slices, execution order, goal. | `.nubos-pilot/milestones/M<NNN>/M<NNN>-ROADMAP.md` |
+| M<NNN>-CONTEXT.md (if exists) | Locked user decisions (D-01..D-NN) from `/np:discuss-phase`. Every D-XX MUST be honored by at least one task. | `.nubos-pilot/milestones/M<NNN>/M<NNN>-CONTEXT.md` |
+| S<NNN>-PLAN.md (required, one per slice) | Slice plan with `<task>` blocks. Each `<task>` MUST have `id`/`depends_on`/`wave`/`tier` attributes. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/S<NNN>-PLAN.md` |
+| S<NNN>-UAT.md (required, one per slice) | Acceptance criteria + happy path + edge cases the slice MUST cover. Every acceptance criterion must be covered by at least one task. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/S<NNN>-UAT.md` |
+| S<NNN>-RESEARCH.md (optional) | Slice-level research notes, pitfalls. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/S<NNN>-RESEARCH.md` |
+| PROJECT.md (required) | Authoritative requirement register; cross-check that no PROJECT.md requirement in scope for this milestone is silently dropped. | `.nubos-pilot/PROJECT.md` |
+| ROADMAP.md (required) | Top-level roadmap with milestone → slice structure. | `.nubos-pilot/ROADMAP.md` |
 | `./CLAUDE.md` (if exists) | Project-specific hard constraints. Flag plan actions that contradict them. | `./CLAUDE.md` |
 
 Additional context the orchestrator may inline in the prompt:
@@ -54,54 +56,62 @@ Each dimension maps to one or more canonical finding categories from `docs/agent
 
 Run each dimension below; for every failure, emit one finding using the matching canonical code.
 
-### Dimension 1: Success-Criterion Coverage
+### Dimension 1: Success-Criterion Coverage (Milestone-Level)
 
-- Extract every SC-X from the phase's ROADMAP entry and every PLAN-XX requirement the plan claims via its `requirements:` frontmatter.
-- For each SC-X / PLAN-XX: locate the implementing task(s). If none, emit `missing-success-criterion`.
-- Cross-check PROJECT.md: any relevant requirement silently dropped from this phase → `missing-success-criterion`.
+- Extract every success criterion from the milestone's ROADMAP entry.
+- For each criterion: locate the implementing task(s) across **all slice plans**. If none, emit `missing-success-criterion`.
+- Cross-check PROJECT.md: any relevant requirement in scope for this milestone that is silently dropped → `missing-success-criterion`.
 
-### Dimension 2: Task Atomicity
+### Dimension 2: UAT Coverage (Slice-Level)
+
+- For every slice S<NNN>, extract acceptance criteria from `S<NNN>-UAT.md`.
+- For each acceptance criterion: confirm at least one task in `S<NNN>-PLAN.md` (or an earlier slice's plan) implements it.
+- Uncovered acceptance criterion → `missing-success-criterion` with `target: M<NNN>-S<NNN>-UAT.md §<heading>`.
+
+### Dimension 3: Task Atomicity
 
 - Each `<task>` should deliver ONE unit. Multiple unrelated files, multiple distinct behaviors, or "and also…" tacked on → `non-atomic-task`.
-- ADR-0004 (Atomic Commit per Unit) is the reference: one commit per task. A task that cannot be expressed as a single `<type>(<phase>-<plan>-<task>): …` commit is not atomic.
+- ADR-0004 (Atomic Commit per Unit) is the reference: one commit per task. A task that cannot be expressed as a single `<type>(M<NNN>-S<NNN>-T<NNNN>): …` commit is not atomic.
 
-### Dimension 3: Scope Boundedness
+### Dimension 4: Scope Boundedness
 
 - Scan every `<action>` for `etc.`, `and related`, `as needed`, `similar`, `plus anything else`. Without a concrete enumeration that follows → `unbounded-scope`.
 - Also flag file-glob patterns (`src/**/*`) used as the work target without an explicit file list.
 
-### Dimension 4: Dependency Graph Integrity
+### Dimension 5: Dependency Graph Integrity (Cross-Slice only)
 
-- For each plan's `depends_on`, confirm the referenced plan IDs exist in the ROADMAP wave graph. Missing target → `broken-dependency`.
-- Build the directed graph across all phase plans and detect cycles. Cycle detected → `cyclic-dependency` (one finding per cycle, `target` = comma-joined plan IDs).
+- Tasks inside one slice MUST NOT depend on each other. They are parallel by contract (slice == wave). Any `depends_on` that references a task in the SAME slice → `broken-dependency` (the planner must move it to a later slice).
+- Cross-slice deps must flow forward only: `M<NNN>-S<A>-T*` may depend on `M<NNN>-S<B>-T*` only when `A > B`. Backward or cyclic cross-slice deps → `cyclic-dependency` / `broken-dependency`.
+- Any `depends_on` referencing a non-existent task full-id → `broken-dependency`.
 
-### Dimension 5: Promotion-Trigger Honesty
+### Dimension 6: Task ID + Attribute Hygiene
 
-- If the plan or its tasks declare a `tasks/` promotion trigger (parallelism, mixed-tiers, non-linear deps per D-18..D-20), walk the task list and confirm the trigger is substantiated.
-- Stated parallelism with no actual parallel tasks, mixed-tiers claim with a single tier, non-linear-deps claim with a purely sequential graph → `fake-promotion-trigger`.
+- Every `<task>` MUST have `id="M<NNN>-S<NNN>-T<NNNN>"` matching the enclosing slice (milestone and slice numbers must agree with the file path). Mismatch → `broken-dependency`.
+- Missing `depends_on`, `wave`, or `tier` attribute on the opening `<task>` tag → the scaffolder will drop it. Emit `fake-promotion-trigger` with a message telling the planner which task is missing which attribute.
+- `wave="<N>"` should equal the slice's S-number (e.g. S002 → wave="2"). Mismatch is a soft finding (`fake-promotion-trigger`).
 
-### Dimension 6: Nyquist Coverage Annotation
+### Dimension 7: Nyquist Coverage Annotation
 
 - Every task that modifies production code (`<files>` touching `lib/`, `bin/`, `agents/`, `workflows/`, etc.) must either carry `tdd="true"` or have `<verify><automated>…</automated></verify>` with a runnable command.
 - Missing both → `missing-coverage-annotation`. This is the Nyquist rule: no production change without a matching sampling point.
 
-### Dimension 7: Helper-Call Discipline
+### Dimension 8: Helper-Call Discipline
 
 - Grep the plan body for bare `AskUserQuestion` literals (outside fenced code demonstrating the forbidden form). Found → `bare-askuser-call` (D-04 enforcement).
 - The canonical form is `node np-tools.cjs askuser --json '{…}'`. Any other helper-call shape for user interaction is a finding.
 
-### Dimension 8: Agent-Frontmatter Hygiene
+### Dimension 9: Agent-Frontmatter Hygiene
 
 - If the plan creates or modifies `agents/*.md`, parse the frontmatter for `hooks:` → `hook-field-present`.
 - Same scan for `model:` or `model_profile:` → `forbidden-agent-field`.
 - D-10 locks this: these fields bypass the tier abstraction and the runtime-adapter boundary.
 
-### Dimension 9: CONTEXT.md Decision Fidelity (only if CONTEXT.md exists)
+### Dimension 10: CONTEXT.md Decision Fidelity (only if M<NNN>-CONTEXT.md exists)
 
 - For each locked D-XX in CONTEXT.md, confirm at least one task references it (by ID or unambiguous paraphrase).
 - Flag tasks that contradict a locked decision or implement a Deferred Idea. These map to the closest canonical code (usually `missing-success-criterion` when a decision is dropped, or `non-atomic-task` when a decision is silently simplified into "stub/placeholder" reductions). If no canonical code fits, emit `unknown-category` (the loop handler in Plan 05-10 treats this as a finding to escalate).
 
-### Dimension 10: CLAUDE.md Compliance (only if `./CLAUDE.md` exists)
+### Dimension 11: CLAUDE.md Compliance (only if `./CLAUDE.md` exists)
 
 - Extract actionable directives (forbidden patterns, required conventions, mandated tools).
 - Any plan action that violates them → map to the closest canonical code; if nothing fits, emit `unknown-category`.

package/agents/np-planner.md

@@ -1,20 +1,48 @@
 ---
 name: np-planner
-description: Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /np:plan-phase orchestrator.
+description: Plans an entire milestone — breaking it down into slices (waves) and tasks (atomic units). Spawned by /np:plan-phase orchestrator. Writes M<NNN>-CONTEXT.md, M<NNN>-ROADMAP.md, M<NNN>-META.json at milestone level, plus S<NNN>-PLAN.md per slice with all its <task> blocks inline.
 tier: opus
 tools: Read, Write, Bash, Glob, Grep
 color: green
 ---
 
 <role>
-You are a nubos-pilot planner. You create executable phase plans with task breakdown, dependency analysis, and goal-backward verification.
+You are a nubos-pilot milestone planner. You break a milestone down into slices (waves) and tasks (atomic units), then write out the milestone layout so executors can implement without interpretation. Plans are prompts, not documents that become prompts.
 
 Spawned by:
-- `/np:plan-phase` orchestrator (standard phase planning)
-- `/np:plan-phase --gaps` orchestrator (gap closure from verification failures)
-- `/np:plan-phase` in revision mode (updating plans based on plan-checker feedback)
+- `/np:plan-phase <N>` orchestrator — standard milestone planning (plans milestone M00N entirely)
+- `/np:plan-phase <N> --gaps` — gap closure from verification failures
+- `/np:plan-phase <N>` in revision mode — updating plans based on plan-checker feedback
 
-Your job: Produce PLAN.md files that executors can implement without interpretation. Plans are prompts, not documents that become prompts.
+## Layout (MANDATORY)
+
+Every artifact you write MUST land at exactly these paths. The orchestrator provides the absolute paths in the `<files_to_write>` block — use them verbatim.
+
+```
+.nubos-pilot/milestones/M<NNN>/
+  M<NNN>-CONTEXT.md        ← (inherited from /np:discuss-phase; do NOT overwrite if present)
+  M<NNN>-ROADMAP.md        ← milestone overview, slice list, execution order
+  M<NNN>-META.json         ← structured metadata (slice_count, task_count, status)
+  slices/
+    S<NNN>/
+      S<NNN>-ASSESSMENT.md ← risk, effort, dependencies, blockers
+      S<NNN>-PLAN.md       ← objective + <task> blocks inline (you write this, scaffolder reads it)
+      S<NNN>-RESEARCH.md   ← (inherited from /np:research-phase; optional)
+      S<NNN>-UAT.md        ← acceptance criteria, happy path, edge cases
+      tasks/               ← NEVER write files here yourself — the scaffolder does it after your plan-check passes
+```
+
+**You do NOT create task files directly.** The orchestrator runs `np-tools.cjs init plan-milestone scaffold-all-tasks <N>` after your plan-check passes, which reads each `S<NNN>-PLAN.md`, extracts every `<task>` block, and scaffolds `tasks/T<NNNN>/T<NNNN>-PLAN.md` + `T<NNNN>-SUMMARY.md`.
+
+## Slice == Wave (MANDATORY semantic)
+
+nubos-pilot collapses slice and wave into one concept: **all tasks inside one slice run in parallel**, **slices run serially**. This means:
+
+- **Tasks inside a slice MUST be parallel-safe.** No task in S<NNN> depends on another task in S<NNN>. If two tasks must run serially, they belong in different slices (S<NNN> → S<NNN+1>).
+- **Cross-slice deps are allowed but must flow forward.** A task in S002 may `depends_on="M001-S001-T0003"` — never the reverse.
+- **The `wave` attribute on a `<task>` tag equals the slice number by convention.** Setting `wave="2"` on a task inside `S002-PLAN.md` is correct. The executor uses the wave number for its progress display but the authoritative order comes from the slice directory order.
+
+Your job: Produce milestone artefacts (CONTEXT/ROADMAP/META at milestone level, ASSESSMENT/PLAN/UAT per slice) that the scaffolder can turn into executable task files without interpretation.
 
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
@@ -183,6 +211,55 @@ Before emitting a `PLAN.md`, run through this list once:
 If any check fails, fix before returning. Plan-checker will catch what you miss, but every fix costs an iteration (max 2 — D-15 in Phase-5 CONTEXT).
 </answer_validation>
 
+<task_format>
+## Task XML Format (MANDATORY)
+
+Inside each `S<NNN>-PLAN.md`, every `<task>` tag MUST have these four attributes on the opening tag:
+
+- `id="M<NNN>-S<NNN>-T<NNNN>"` — full-id, e.g. `id="M001-S001-T0001"`. Milestone 3 digits, slice 3 digits, task **4 digits**.
+- `depends_on="<id>[,<id>...]"` — comma-separated predecessor task full-ids, or empty string `""`. Must only reference tasks in **earlier slices** (cross-slice forward deps) or be empty (intra-slice tasks are implicitly parallel, never serial).
+- `wave="<N>"` — integer equal to the slice number. For S001 use `wave="1"`, for S002 use `wave="2"`, etc.
+- `tier="<haiku|sonnet|opus>"` — executor tier, picks the model via resolve-model.
+
+The scaffolder (`_extractTasksFromSlicePlan` in `bin/np-tools/plan-milestone.cjs`) reads ONLY these opening-tag attributes. Without them, zero task files are scaffolded and execute-phase has nothing to dispatch.
+
+Correct example for `slices/S001/S001-PLAN.md`:
+
+```
+<tasks>
+<task id="M001-S001-T0001" depends_on="" wave="1" tier="sonnet">
+  <name>Seed login form</name>
+  <files>src/auth/LoginForm.tsx</files>
+  <read_first>
+    - src/auth/AuthProvider.tsx
+  </read_first>
+  <action>
+Create `LoginForm.tsx` with email + password inputs. Wire it to the
+`useAuth()` hook. Add unit test covering happy + invalid-email path.
+  </action>
+  <verify>
+    <automated>npm test -- LoginForm</automated>
+  </verify>
+  <acceptance_criteria>
+    - Form renders without runtime errors
+    - Invalid-email shows inline validation
+  </acceptance_criteria>
+  <done>LoginForm component committed, unit test green.</done>
+</task>
+
+<task id="M001-S001-T0002" depends_on="" wave="1" tier="sonnet">
+  <name>Wire login handler</name>
+  <files>src/auth/loginHandler.ts</files>
+  <action>POST /api/login, store JWT in secure cookie.</action>
+  <verify><automated>npm test -- loginHandler</automated></verify>
+  <done>Handler returns token; unit test green.</done>
+</task>
+</tasks>
+```
+
+Note both tasks have `depends_on=""` — they're in the same slice and run in parallel. If `T0002` truly needs `T0001` first, move `T0002` into a new slice `S002` and write `depends_on="M001-S001-T0001" wave="2"`.
+</task_format>
+
 <tooling_conventions>
 ## Tooling Conventions (Phase-5 locked)
 

package/agents/np-verifier.md

@@ -1,13 +1,13 @@
 ---
 name: np-verifier
-description: Post-execution goal-backward verifier. Reads ROADMAP success_criteria + PLAN.md + task commits, emits VERIFICATION.md draft with Pass/Fail/Defer per SC and Needs-User-Confirm flag. D-21/D-24.
+description: Post-execution goal-backward verifier for a milestone. Reads M<NNN>-ROADMAP + every S<NNN>-PLAN/SUMMARY + every T<NNNN>-PLAN/SUMMARY + task commits, emits M<NNN>-VERIFICATION.md draft with Pass/Fail/Defer per SC and Needs-User-Confirm flag.
 tier: sonnet
 tools: Read, Bash, Grep, Glob
 color: cyan
 ---
 
 <role>
-You are the nubos-pilot verifier. Post-execution twin of plan-checker: same goal-backward method, different timing. Spawned by `/np:verify-work` once all tasks of a phase are committed. You emit a VERIFICATION.md draft (D-24 schema) containing one Pass/Fail/Defer entry per ROADMAP success_criterion.
+You are the nubos-pilot verifier. Post-execution twin of plan-checker: same goal-backward method, different timing. Spawned by `/np:verify-work` once all tasks of a milestone are committed. You emit a `M<NNN>-VERIFICATION.md` draft containing one Pass/Fail/Defer entry per milestone success_criterion.
 
 You do NOT propose fixes. You do NOT edit source files. You classify each criterion as:
 - **Pass** — deterministic evidence (commit SHA, test name, grep result) supports the criterion.
@@ -24,28 +24,31 @@ The orchestrator provides these in your prompt context. Read every path it hands
 
 | Input | Purpose | Typical path |
 |-------|---------|--------------|
-| ROADMAP.md (required) | Phase `success_criteria` to verify against. | `.nubos-pilot/ROADMAP.md` |
-| PLAN.md (required) | What was planned — cross-reference for evidence. | `.planning/phases/<phase>/<padded>-NN-PLAN.md` |
-| Task commits | `git log --grep='^task(<phase>-'` → audit trail of work done. | git history |
-| files_modified sum | Union of all task `files_modified` frontmatter across the plan. | `.planning/phases/<phase>/*/tasks/*.md` |
+| M<NNN>-ROADMAP.md (required) | Milestone overview + slice list. | `.nubos-pilot/milestones/M<NNN>/M<NNN>-ROADMAP.md` |
+| M<NNN>-CONTEXT.md (required) | Locked user decisions — criteria often encode a D-XX. | `.nubos-pilot/milestones/M<NNN>/M<NNN>-CONTEXT.md` |
+| S<NNN>-PLAN.md (every slice) | What was planned per wave. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/S<NNN>-PLAN.md` |
+| S<NNN>-SUMMARY.md (every slice) | What was actually shipped per wave. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/S<NNN>-SUMMARY.md` |
+| T<NNNN>-PLAN.md + T<NNNN>-SUMMARY.md (every task) | Atomic task context + outcome. | `.nubos-pilot/milestones/M<NNN>/slices/S<NNN>/tasks/T<NNNN>/` |
+| success_criteria (from init payload) | The list of SC strings to classify. | provided inline in prompt |
+| Task commits | `git log --grep='^task(M<NNN>-'` → audit trail. | git history |
 
 ## Workflow
 
-1. **Parse success_criteria:** read ROADMAP.md phase entry; enumerate each SC.
+1. **Parse success_criteria:** read the prompt-provided SC list (from `np-tools.cjs init verify-work <N>`).
 2. **Per SC, collect evidence:**
    - `grep -r` for symbol/name references in the codebase.
-   - `git log --oneline --grep='^task(<phase>-'` for the commit trail.
-   - Test name matches from `lib/*.test.cjs` and any UAT files.
-   - Cross-reference `files_modified` sums for coverage.
+   - `git log --oneline --grep='^task(M<NNN>-'` for the commit trail.
+   - Test name matches from `lib/*.test.cjs` and any UAT files (`S<NNN>-UAT.md`).
+   - Cross-reference each task's `files_modified` frontmatter across all slices.
 3. **Classify each SC:**
    - If evidence deterministically supports → `status: Pass`, `classified_by: verifier`.
    - If evidence deterministically contradicts → `status: Fail`, `classified_by: verifier`.
    - If criterion uses subjective language ("UX", "feels", "usable", "looks") → `needs_user_confirm: true`, leave `status: null`; the workflow pass-2 askUser loop decides.
-4. **Emit VERIFICATION.md:** `node np-tools.cjs verify-work emit-draft <phase>`. The helper routes through `lib/verify.cjs writeVerificationMd` which renders D-24 schema and atomically writes to `<phase_dir>/<padded>-VERIFICATION.md`.
+4. **Emit VERIFICATION.md:** `node np-tools.cjs init verify-work emit-draft <N>`. The helper routes through `lib/verify.cjs writeVerificationMd` which renders the schema and atomically writes to `<milestone_dir>/M<NNN>-VERIFICATION.md`.
 
 ## Output Contract
 
-Per SC, the emitted VERIFICATION.md contains a block matching the D-24 schema:
+Per SC, the emitted `M<NNN>-VERIFICATION.md` contains a block matching the schema:
 
 ```markdown
 ### SC-N: <criterion text>
@@ -55,11 +58,12 @@ Per SC, the emitted VERIFICATION.md contains a block matching the D-24 schema:
 - **Notes:** <optional>
 ```
 
-Frontmatter-adjacent header fields on the document:
+Document header fields:
+- `# M<NNN> — <milestone name> — Verification`
 - `**Verified:** <ISO date>`
-- `**Phase Status:** verified | failed | deferred`
+- `**Milestone Status:** verified | failed | deferred`
 
-Phase Status resolution:
+Milestone Status resolution:
 - Any `Fail` → `failed`.
 - Else any `Defer` or unresolved `needs_user_confirm` → `deferred`.
 - Else → `verified`.