nw-deliver

NW-DELIVER: Complete DELIVER Wave Orchestrator

Wave: DELIVER (wave 6 of 6)|Agent: Main Instance (orchestrator)|Command: /nw-deliver "{feature-description}"

Overview

Orchestrates complete DELIVER wave: feature description → production-ready code with mandatory quality gates. You (main Claude instance) coordinate by delegating to specialized agents via Task tool. Final wave (DISCOVER > DISCUSS > SPIKE > DESIGN > DEVOPS > DISTILL > DELIVER).

Sub-agents cannot use Skill tool or /nw-* commands. You MUST:

• Read the relevant command file and embed instructions in the Task prompt
• Remind the crafter to load its skills as needed for the task (skill files are at ~/.claude/skills/nw-{skill-name}/SKILL.md)

Output Tiers (per D2)

Provenance: feature lean-wave-documentation — D2 (schema-typed sections), D10 (one-line expansion descriptions). Tier-1 [REF] sections (always emitted) + Tier-2 EXPANSION CATALOG items (lazy, on-demand) are the two output bands. Implementation details live in code; the wave-delta sections are pointers + structured summaries. Full contract: nWave/skills/nw-density-resolution-contract/SKILL.md.

Tier-1 [REF] — always emitted

Under ## Wave: DELIVER / [REF] <Section> headings:

• Implementation summary — one-paragraph description of what shipped (no design rationale)
• Files modified — categorized list (production, tests, docs) with one-line per file
• Scenarios green count — <N> of <M> from the .feature file with timestamp
• DoD check — itemized pass/fail against the DISCUSS Definition of Done items
• Demo evidence — captured stdout/exit-code per Elevator Pitch demo command (Phase 3.5 gate)
• Quality gates — per-phase outcomes (refactor, review, mutation, integrity)
• Pre-requisites — DISTILL scenarios + DESIGN component manifest the implementation depended on

Tier-2 EXPANSION CATALOG — lazy, on-demand (per D10)

Rendered under ## Wave: DELIVER / [WHY|HOW] <Section> only when requested via --expand <id> (DDD-2), the wave-end menu (expansion_prompt = "ask"), mode = "full" auto-expansion, or an ad-hoc user request mid-session.

| Expansion ID | Tier label | One-line description | |---|---|---| | refactoring-journal | [HOW] | L1-L6 refactoring log with rationale per micro-transformation | | retrospective-notes | [WHY] | 5 Whys analysis on issues encountered, lessons learned, what to repeat/avoid | | performance-measurements | [WHY] | Benchmarks, profiling output, latency/memory deltas vs baseline | | alternative-implementations-rejected | [WHY] | Implementation approaches tried and rejected with one-paragraph reason each | | mutation-testing-report | [HOW] | Mutmut/Pitest output: kill rate, surviving mutants, mitigation actions | | architecture-decision-deviations | [WHY] | Where DELIVER deviated from DESIGN and the back-propagation logged in upstream-issues.md | | coverage-deltas | [HOW] | Per-module coverage delta with rationale for any drops | | expansion-catalog-rationale | [WHY] | Why this set of expansions, why these defaults, why D10 enforces one-line descriptions |

Density resolution (per D12)

Call resolve_density(global_config) from scripts/shared/density_config.py after reading ~/.nwave/global-config.json (missing/malformed = empty dict). Returns mode ("lean" | "full") + expansion_prompt ("ask" | "always-skip" | "always-expand" | "smart") per the D12 cascade (resolver-internal, DDD-5 — do NOT replicate locally). Branch on density.mode for what to emit; branch on density.expansion_prompt at wave end for menu behaviour. Full cascade detail, branch semantics, ad-hoc override workflow: nWave/skills/nw-density-resolution-contract/SKILL.md.

Telemetry (per D4 + DDD-6)

Every expansion choice emits a DocumentationDensityEvent (dataclass at src/des/domain/telemetry/documentation_density_event.py) via event.to_audit_event() → JsonlAuditLogWriter().log_event(...). Schema fields per D4: feature_id, wave, expansion_id, choice, timestamp. For this wave the schema declares "wave": "DELIVER". Use helper scripts/shared/telemetry.py:write_density_event(...) — do NOT write JSONL directly.

Wave-specific signal: a DELIVER wave recording choice = "expand" for retrospective-notes indicates the team needed deeper learning capture; over time the data drives whether retrospective notes should be promoted to Tier-1. Full emission rules: nWave/skills/nw-density-resolution-contract/SKILL.md.

CRITICAL BOUNDARY RULES

1. NEVER implement steps directly. ALL implementation MUST be delegated to the selected crafter (@nw-software-crafter or @nw-functional-software-crafter per step 1.5) via Task tool with DES markers. You are ORCHESTRATOR — coordinate, not implement.
2. NEVER write phase entries to execution-log.json. Only the crafter subagent that performed TDD work may append entries.
3. Extract step context from roadmap.json ONLY for Task prompt. Grep roadmap for step_id ~50 lines context, extract (name|criteria|files_to_modify) per nWave/templates/roadmap-schema.json, pass in DES template.

DES monitoring is non-negotiable. Circumventing DES — faking step IDs, omitting markers, or writing log entries manually — is a violation that invalidates the delivery. DES detects unmonitored steps and flags them; finalize blocks until every flagged step is re-executed through a properly instrumented Task. There is no workaround: unverified steps cannot pass integrity verification, and the delivery cannot be finalized. Without DES monitoring, nWave cannot verify TDD phase compliance. For non-deliver tasks (docs, research, one-off edits): <!-- DES-ENFORCEMENT : exempt -->.

Rigor Profile Integration

Before dispatching any agent, read the rigor profile from .nwave/des-config.json (key: rigor). If absent, use standard defaults.

How rigor affects deliver phases:

| Setting | Effect | |---------|--------| | agent_model | Pass as model parameter to all Task tool invocations for crafter agents. If "inherit", omit model parameter (Task tool inherits from session). | | reviewer_model | Pass as model parameter to reviewer Task invocations. If "skip", skip Phase 4 entirely. | | review_enabled | If false, skip Phase 4 (Adversarial Review). | | double_review | If true, run Phase 4 twice with separate review scopes. | | tdd_phases | Pass to crafter in DES template. Replace # TDD_PHASES section with the configured phases. The 3-phase canon (ADR-025) is [RED, GREEN, COMMIT]; legacy 5-phase contract is [PREPARE, RED_ACCEPTANCE, RED_UNIT, GREEN, COMMIT]. If lean profile ([RED_UNIT, GREEN] legacy or [RED, GREEN] canon), omit setup/commit instructions accordingly. | | refactor_pass | If false, skip Phase 3 (Complete Refactoring). | | mutation_enabled | If false, skip Phase 5 regardless of mutation strategy in CLAUDE.md. |

Task invocation with rigor model:

Task(
    subagent_type="{agent}",
    model=rigor_agent_model,  # omit this line entirely if "inherit"
    max_turns=45,
    prompt=...,
)

Prior Wave Consultation

Before beginning DELIVER work, read prior wave content. With lean v3.14, all wave decisions live in a single feature-delta.md (sections tagged ## Wave: <NAME> / [REF|WHY|HOW] <Section>); legacy multi-file directories are no longer produced.

1. DISCOVER (skip): Synthesized into DISCUSS sections of feature-delta.md.
2. DISCUSS (read on demand): in docs/feature/{feature-id}/feature-delta.md under ## Wave: DISCUSS / [REF] ... sections. Already encoded as acceptance scenarios — read for elevator pitch extraction (Phase 3.5) and clarification only.
3. DESIGN (structural context, MANDATORY): Read docs/product/architecture/brief.md (cross-feature SSOT — component boundaries, driving ports, C4 diagrams). PLUS read docs/feature/{feature-id}/feature-delta.md filtered to ## Wave: DESIGN / [REF] ... sections — DDD