n.siegfried
0dbc240900
Nick answered 21 questions at the wave 6 exit and 11 follow-ups. Seven answers are new build work, three amend acceptance criteria on tasks already scheduled, and two close questions without work. None of it had an item ID, so none of it could be built under CLAUDE.md's first rule. New items D1-D10 in docs/waves/decisions-2026-08-18.md. A new prefix rather than widened CR/F/S/A/B/C numbers - those are referenced in documents outside this repo and CLAUDE.md forbids reinterpreting them. Every D entry names the item it amends and quotes the criterion it replaces, so a reader of R2 can see what moved. D1 sample data returns to the creator B7, S7 T7.1 D2 QA distribution list configured in the SOP CR-014 T7.6 D3 side navigation and collapsible sections, not tabs F6 T7.2 D4 Urgent surfaces the audited override, never bypasses CR-003/A1 T7.3 D5 usage data moves to the admin console B7 T7.10 (new) D6 material list uploads at SOP configuration CR-013 T8.6 (new) D7 archived projects readable by project admins B3, C1 T9.8 (new) D8 5MB a file, 2GB a project, PDFs and images, one DB CR-007 T7.7 D9 Ready for QA appears in Field View CR-014 T7.6 D10 email switched on and off from the admin console CR-011/14 T7.6, T8.3 Two decisions were mine to make and are recorded as such. D3: the written F6 criterion (no view over two screen heights) and the answer (one long form with side nav) cannot both hold, so the criterion now reads 'at rest' and sections collapse by default - tabs hide sections a first-time author does not know exist. D8: keeping 5MB files in the same database means every encrypted backup carries them; splitting them out was rejected because a backup without the drawings cannot restore, so a 2GB per-project ceiling was approved instead. Also corrected, not amended: CLAUDE.md and IMPLEMENTATION.md X2 both cited wp-creation-app.js:1962-1972 as the protected logged-override path that T7.3 is forbidden to remove. Those lines are deletePackage() and clearSaved(). The path is confirmEarlyRelease() at :1002. Both documents now name it by function so the reference survives the T7.1 rewrite that is about to move it. Wave 9 gains T9.9, a sweep of the nine backlog entries that name wave 9 as their home. Left unscheduled they surface at T9.7, which has no room to fix anything. The four colour items in it (BL-004/005/008/009) are now approved work. T9.5's help-tip count corrected from 15 to 18 and dated: three were added during waves 5 and 6 by tasks reusing the component as designed, each unreachable for the same reason. Scheduling a broken component late makes every reuse cost more. Closed without work: the free-text location migration. Every location on record is sample data because no real list has been loaded, so there is nothing to migrate. Recorded with the condition that invalidates it - the first real project - so it is a decision rather than a surprise. Items: D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 Task: T7.0 (wave 7 prep) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
229 lines
10 KiB
Markdown
229 lines
10 KiB
Markdown
# Wave 8 — Kitting and material
|
|
|
|
**Items:** `CR-009`, `CR-010`, `CR-011`, `CR-012`, `CR-013`, and from August 18: `D6`, `D10`
|
|
**Depends on:** wave 7 merged
|
|
|
|
**Build order is not task order.** `T8.6` is numbered last because it was added on August 18,
|
|
but it **blocks `T8.5`** - the request cannot select from a list that does not exist yet. Build
|
|
`T8.1`, `T8.2`, `T8.3`, `T8.4`, `T8.6`, then `T8.5`. Task IDs are referenced outside this repo
|
|
and are not renumbered to make the order read left to right.
|
|
**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
|
|
|
|
**Confirmed August 18.** Asked whether the warehouse owner belongs to the project or to each
|
|
work package, the answer was **on the work package**. A project default is fine as a
|
|
convenience, but the field that notifications read is the one on the package, so a package
|
|
retargeted to a different warehouse notifies the right person without touching the project.
|
|
|
|
---
|
|
|
|
### T8.3 — CR-011: Kitting status change notification
|
|
|
|
- **Items:** `CR-011`, `D10`
|
|
- **Depends on:** T8.2, T7.6 (the email gate), 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
|
|
- [ ] the gate built at `T7.6` is reused, not re-implemented; kitting email is off by default and turned on from `admin.html` (`D10`)
|
|
- [ ] the send path is exercised against a capture sink with the captured count asserted; no real mail leaves this branch
|
|
|
|
---
|
|
|
|
### 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`, `D6`
|
|
- **Depends on:** T8.4, T8.6, 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).
|
|
|
|
**Amended August 18 (`D6`).** Two answers change this task. Line items **select from a
|
|
project material list uploaded during SOP configuration** (`T8.6`) rather than being typed
|
|
from nothing - and free text still works when no list has been loaded, which is the state
|
|
every project is in today. And submitting a request **notifies the warehouse owner named on
|
|
the work package** (`CR-010`), which is the routing that replaces the informal funnel through
|
|
one person.
|
|
|
|
`D6` does not open the deferred parts catalog. A project-scoped list the project uploaded is
|
|
not a catalog: no inventory levels, no warehouse integration, no shared master data. If a
|
|
stock count appears in the diff, it has crossed the line `IMPLEMENTATION.md` section 7 draws.
|
|
|
|
**Done when:**
|
|
|
|
- [ ] line items can be added, edited and removed, with quantity and unit
|
|
- [ ] line items select from the `T8.6` list when one exists, and accept free text when it does not
|
|
- [ ] needed-by date, requestor, delivery location and status all persist
|
|
- [ ] requests appear on the dashboard, filterable by location and status
|
|
- [ ] submitting a request notifies the warehouse owner named on the work package
|
|
- [ ] 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
|
|
|
|
---
|
|
|
|
### T8.6 — D6: Upload the material list at SOP configuration
|
|
|
|
- **Items:** `D6`
|
|
- **Depends on:** T8.1
|
|
- **Blocks:** T8.5
|
|
- **Surface:** `server/` + `html/`
|
|
- **Files:** SOP wizard, material list model and routes, `T5.4`'s upload component
|
|
|
|
**Intent:** `CR-013` was written to accept free text because Nate's spreadsheet and the master
|
|
material workbook had not been supplied, and they still have not been. Asked on August 18
|
|
whether to wait for them, the answer was **build the upload path now**, the same call that was
|
|
made for the location list at `CR-005`.
|
|
|
|
**Do:** Reuse `T5.4`. The location upload already does paste-or-file, validates, reports
|
|
rejected rows with the source line number, and stays editable afterwards. Build the material
|
|
list the same way and against the same component, not beside it.
|
|
|
|
Keep the field set small and obvious: description, unit, and an optional code. That is what
|
|
`T8.5` needs to populate a line item.
|
|
|
|
**Do not:** add inventory levels, stock counts, pricing or a warehouse identifier. Do not make
|
|
the list mandatory - a project with no list must still be able to raise a request. Do not
|
|
hardcode sample part numbers; seed with an obviously-fake sample as `CR-005` does.
|
|
|
|
**Done when:**
|
|
|
|
- [ ] a material list uploads or pastes during SOP configuration and persists per project
|
|
- [ ] rejected rows are reported with the source line and a reason
|
|
- [ ] the list is editable after upload, and entries can be deactivated rather than deleted
|
|
- [ ] `T8.5` line items select from it
|
|
- [ ] a project with no list can still raise a request with free text
|
|
- [ ] the upload component is the `T5.4` one; grep confirms there is not a second implementation
|
|
- [ ] no inventory, pricing or stock field exists in the diff
|
|
- [ ] the flow works at 390px
|
|
|
|
---
|
|
|
|
## Wave 8 exit criteria
|
|
|
|
- [ ] Kitting is fully built and toggled off for Micron EUV
|
|
- [ ] notifications carry working deep links and a delivery location, and are off by default
|
|
- [ ] the material request is the lightweight scope, nothing more
|
|
- [ ] a material list uploads at SOP configuration and feeds the request (`D6`)
|
|
- [ ] no guessed part numbers or floor names anywhere in the code
|
|
- [ ] no real email left this branch; the capture sink count is recorded
|