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.featurefile 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
- 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.
- NEVER write phase entries to execution-log.json. Only the crafter subagent that performed TDD work may append entries.
- 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.
- DISCOVER (skip): Synthesized into DISCUSS sections of
feature-delta.md. - DISCUSS (read on demand): in
docs/feature/{feature-id}/feature-delta.mdunder## Wave: DISCUSS / [REF] ...sections. Already encoded as acceptance scenarios — read for elevator pitch extraction (Phase 3.5) and clarification only. - DESIGN (structural context, MANDATORY): Read
docs/product/architecture/brief.md(cross-feature SSOT — component boundaries, driving ports, C4 diagrams). PLUS readdocs/feature/{feature-id}/feature-delta.mdfiltered to## Wave: DESIGN / [REF] ...sections — DDD