n.siegfried/Project-SDE-WP-Suite
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
03d24138ed343cadfeebc99a4b587a5b438f0e37
Project-SDE-WP-Suite/docs/waves/wave-8.md
n.siegfried 3d99d4b9d0 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>
2026-08-14 17:42:56 -05:00

6.5 KiB
Raw Blame History

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