Import the R2 implementation spec into the repo

The plan was delivered as wp-suite-implementation-spec.zip and lived only in
Downloads, so every "read CLAUDE.md first" instruction in it pointed at a file
the repo did not have. Bring it in unchanged: CLAUDE.md, IMPLEMENTATION.md, and
docs/waves/wave-0 through wave-9 plus backlog.md.

UX-REVIEW-2026-08-14.md is committed alongside it. It is the review that
produced F1-F6, S1-S13 and the A/B/C assessments, and item IDs throughout the
wave files cite it, so it belongs under version control rather than sitting
untracked in the working tree.

No application code changes here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/waves/wave-8.md

@@ -0,0 +1,164 @@
+# Wave 8 — Kitting and material
+
+**Items:** `CR-009`, `CR-010`, `CR-011`, `CR-012`, `CR-013`
+**Depends on:** wave 7 merged
+**Decision, approved Aug 14 2026:** keep and extend Kitting, then ship it **toggled off** for
+the Micron EUV SOP. Kitting is not happening at Micron today — it is complicated by
+journeyman ratio and warehouse cost — but the team expects to get there, and prefab arguably
+already qualifies.
+
+That means this wave builds functionality that will not be visible on the pilot project. That
+is intentional. Do not shortcut it on the grounds that nobody is using it, and do not switch
+it on for Micron.
+
+---
+
+### T8.1 — CR-009: Kitting section retained and structured
+
+- **Items:** `CR-009`
+- **Depends on:** T7.9
+- **Blocks:** T8.2, T8.3, T8.4
+- **Surface:** `server/` + `html/`
+- **Files:** Kitting section, SOP configuration
+
+**Do:** Confirm the Kitting section is intact and structured to receive `T8.2` through
+`T8.4`. Define kitting statuses explicitly. Proposed set, adjust only with a stated reason:
+`Not Started`, `Picking`, `Staged`, `In Transit`, `Delivered`.
+
+Then set the section off for the Micron EUV SOP via the `CR-006` toggles.
+
+**Done when:**
+
+- [ ] kitting statuses are defined as an explicit set, not free text
+- [ ] the section is off for Micron EUV and absent from its form, detail view and export
+- [ ] a different SOP can enable it and it works fully
+- [ ] no kitting data is deleted anywhere
+
+---
+
+### T8.2 — CR-010: Warehouse Owner dropdown
+
+- **Items:** `CR-010`
+- **Depends on:** T8.1
+- **Blocks:** T8.3
+- **Surface:** `server/` + `html/`
+- **Files:** Kitting section, dashboard filters
+
+**Intent:** A named person owns fulfillment of the kit. Today that is Paul Coonrod and
+everything bottlenecks through him informally, so the work package should record it
+explicitly.
+
+**Do:** A Warehouse Owner dropdown populated from project members. That person receives
+kitting notifications by default. Filterable on the dashboard so a warehouse owner can see
+everything assigned to them.
+
+**Done when:**
+
+- [ ] the dropdown lists project members and persists a selection
+- [ ] the selected owner is a default recipient for `T8.3` notifications
+- [ ] the dashboard filters by warehouse owner
+- [ ] removing someone from the project does not break existing work packages referencing them
+
+---
+
+### T8.3 — CR-011: Kitting status change notification
+
+- **Items:** `CR-011`
+- **Depends on:** T8.2, T4.2 (blocking dependency `X1`)
+- **Blocks:** nothing
+- **Surface:** `server/` + `html/`
+- **Files:** notification service, kitting status handling
+
+**Intent:** Extends the existing status-change notification pattern to kitting so the field
+knows when material moves from requested to staged to delivered without chasing it in Teams.
+
+**Do:** A kitting status change emails the work package distribution list. The email states
+the work package, the old and new status, who changed it, the delivery location, and a direct
+link to the work package. Match the existing status-change email pattern so users see one
+convention, not two.
+
+**Do not:** send a link to the app root (`X1`).
+
+**Done when:**
+
+- [ ] every kitting status change sends to the distribution list
+- [ ] the email includes old status, new status, actor, delivery location and a working deep link
+- [ ] the link opens that specific work package, including via login for a signed-out recipient
+- [ ] formatting and tone match the existing status-change email
+- [ ] rapid consecutive changes do not produce a burst of near-identical emails
+- [ ] send failures are logged and surfaced
+
+---
+
+### T8.4 — CR-012: Delivery location on Kitting / Material
+
+- **Items:** `CR-012`
+- **Depends on:** T8.1, T6.3
+- **Blocks:** nothing
+- **Surface:** `server/` + `html/`
+- **Files:** Kitting section, print/pick output
+
+**Intent:** Delivery logistics are the real pain. Staging at the warehouse, getting it on a
+truck, then making sure material reaches the correct floor lay-down, shark cage or conduit
+tree rather than being picked at will by whoever is closest.
+
+**Do:** Capture delivery location using the same Building / Floor / Sector lists as `CR-004`,
+plus a free-text detail field for specifics like lay-down area, shark cage or conduit tree.
+Include the delivery location on the kitting notification email and on any pick or delivery
+printout.
+
+**Done when:**
+
+- [ ] delivery location uses the shared location lists, not a parallel free-text field
+- [ ] the detail field persists and prints
+- [ ] the location appears on the `T8.3` email
+- [ ] it appears on any pick or delivery printout
+
+---
+
+### T8.5 — CR-013: Lightweight material request
+
+- **Items:** `CR-013`
+- **Depends on:** T8.4, T7.2 (sequencing dependency `X6`)
+- **Blocks:** nothing
+- **Surface:** `server/` + `html/`
+- **Files:** Materials section, request model, dashboard
+
+**Decision, approved Aug 14 2026:** build the lightweight version. Defer the parts catalog,
+live inventory and warehouse integration.
+
+**Intent:** Material requests run today through per-floor Teams chats and a spreadsheet, all
+funneling to Paul Coonrod. The comparison drawn in the meeting was a project where requests
+went into a OneNote and became, in the words used at the time, word vomit. The point of this
+item is structure, not features.
+
+**In scope:** line items (description, quantity, unit), needed-by date, requestor, delivery
+location (reuse `T8.4`), and status.
+
+**Out of scope, do not build:** master parts catalog dropdown, live inventory levels,
+warehouse system integration.
+
+**Do:** Build the in-scope set. Requests are visible on the dashboard and filterable by
+delivery location and status.
+
+**Do not:** build this before `T7.2`. A material card added to the pre-tab creator is a 12th
+card on a 4,700px form. And do not invent a parts list — Nate's spreadsheet and the master
+material workbook have not been supplied yet (see `IMPLEMENTATION.md` section 8).
+
+**Done when:**
+
+- [ ] line items can be added, edited and removed, with quantity and unit
+- [ ] needed-by date, requestor, delivery location and status all persist
+- [ ] requests appear on the dashboard, filterable by location and status
+- [ ] no parts catalog, inventory count or warehouse integration exists in the diff
+- [ ] the section respects `CR-006` toggles
+- [ ] the whole flow works at 390px, since requests originate in the field
+
+---
+
+## Wave 8 exit criteria
+
+- [ ] Kitting is fully built and toggled off for Micron EUV
+- [ ] notifications carry working deep links and a delivery location
+- [ ] the material request is the lightweight scope, nothing more
+- [ ] no guessed part numbers or floor names anywhere in the code