nw-crafter-discipline-atdd-pure

# Crafter Discipline — ATDD-pure Protocol

## Scope

This skill defines the **discipline contract** for the slim crafter in the ATDD-pure 7-phase workflow (ADR-027, plan v3 §3-§4). It is loaded when `.nwave/config.yaml` sets `workflow.mode: atdd_pure` and the crafter is dispatched into Phase A, Phase B, or Phase E.

The crafter does NOT author ATs. ATs are the exclusive territory of `nw-acceptance-designer` (DISTILL wave). Back-pressure on AT gaps flows through the Phase C reviewer + Phase D router — never crafter-side AT edits.

Reference: plan v3 `docs/proposals/atdd-pure-workflow-restructure-v3-2026-05-19.md` §3, §4, §7; ADR-027 `docs/architecture/adrs/adr-027-atdd-pure-7-phase-extension.md`.

---

## Phase A — GREEN-the-ATs (crafter instance #1)

**Goal**: take the AT contract authored by DISTILL and produce the **minimum production code** that turns all ATs from RED to GREEN in a single dispatch.

### Inputs
- `.feature` files + step definitions (DISTILL output, immutable to crafter)
- Optional paired unit tests (PBT + state-delta) per `nw-test-design-mandates`
- `files_to_modify` roadmap entry (architect-grounded per `feedback_architect_must_filesystem_ground_roadmap_2026_05_18`)

### Discipline
1. Read **all** ATs end-to-end before writing one line of production code. Hold the AT contract in working memory (~50KB sustainable per spike-2 honest assessment).
2. Implement the **smallest** code shape that satisfies every AT. Single dispatch — no iterative incremental ping-pong.
3. **NO defensive code**: do not write try/except wrappers, dry_run guards, idempotency checks, `validate_prerequisites()` failure branches, `_read_hooks` isinstance guards, type-branching coercion in formatters — **unless an AT explicitly requires it**.
4. **NO architectural anticipation**: write what tests demand, not what "future me might need". Speculative abstractions, premature extension points, configuration knobs without an AT — all forbidden.
5. **NO AT modification**: ATs are read-only. If an AT seems wrong or incomplete, surface to the Phase C reviewer via the verdict pipeline; do NOT edit.

### Empirical anchor
Spike-2 (codex 20 BDD, M cohort): **160 LOC of defensive code** cut in Phase B because no AT asserted them. Phase A had originally written them out of habit — Phase B coverage report exposed them as dead.

### Exit gate
All ATs pass (full suite, not smoke). Output: production code + diff scope confined to `files_to_modify` entries that have been **filesystem-grounded** (paths exist, named symbols are grep-findable in the cited files).

---

## Phase B — Coverage-driven dead-code elimination (same crafter instance)

**Goal**: prove that every line of production code written in Phase A is **required** by at least one AT. Cut everything else.

### Workflow
1. Run `pytest --cov` after Phase A green. Capture line + branch coverage report.
2. For each uncovered line, choose one:
   - **CUT**: delete the line; re-run tests; must stay green.
   - **JUSTIFY**: add to dead-code-justification list with rationale (e.g. monkeypatched module-level symbol that coverage cannot track, `__main__` guard, platform-conditional import).
3. After all cuts applied, re-run the full suite. Suite stays GREEN — no regression tolerated.
4. Target coverage: **≥90% line + branch** (canonical baseline anchor).

### Mechanical character
Phase B is mechanical: the coverage report is the candidate-cuts list. No judgement calls beyond the justification taxonomy.

### Exit gate
1. All ATs still pass.
2. Coverage ≥90% line + branch (or documented misses in justification list).
3. Zero try/except surviving without a paired AT-justified anchor.
4. Zero defensive branches surviving without paired AT.

---

## Phase E — Batch L1-L6 refactor (crafter instance #2, SEPARATE)

**Goal**: apply all L1-L6 refactor transformations atomically in a single editing session, then run the test suite once.

### Separation principle
Phase E **MUST** run in a **separate crafter instance** from Phase A (Ale 2026-05-19 mandate, plan v3 §3). Phase A crafter holds the "minimal-to-GREEN" context; Phase E crafter holds the "refactor-for-quality" context. Mixing the two contexts dilutes both. Dispatch as `Agent(subagent_type='nw-software-crafter')` with a clean session.

### Batch protocol
1. Read all production files modified in Phase A + the test suite.
2. Plan all L1-L6 transformations as a single coherent edit set:
   - **L1**: rename for clarity
   - **L2**: extract method / inline temp
   - **L3**: introduce parameter object / extract class
   - **L4**: replace conditional with polymorphism / strategy
   - **L5**: introduce interface / port boundary cleanup
   - **L6**: eliminate duplication across modules
3. Apply ALL planned edits in one editing session — no interleaved test runs. The L1-L6 cascade governs planning order only.
4. Single test run at the end.
5. If RED: diagnose breakage and fix the **production** code — do NOT modify tests to make them pass. A test that must change means either (a) the refactor altered observable behavior — revert that transformation — or (b) the test encoded an implementation detail — flag to the operator before touching it. **Do NOT retry incremental** (`feedback_refactor_batch_when_test_suite_slow_2026_05_19`).

### Rationale
Batch-then-verify is the **unconditional default** for refactoring (`feedback_refactor_batch_when_test_suite_slow_2026_05_19`, strengthened 2026-05-20 — the prior "only when suite slow" conditional is removed). The cascade orders planning, not test runs. Incremental L1→test→L2→test wastes wall-clock on identical-result test runs; batch protocol cuts wait-time by ~5-6× per spike-2 anchor (6 L-transformations + 1 test run vs 6 test runs). The legacy incremental variant lives in `nw-progressive-refactoring` as explicit opt-in only.

### Exit gate
1. Full suite GREEN.
2. Diff is internally consistent (no half-applied refactors).
3. No production behavior change (ATs unchanged in count and conten