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>
154 lines
5.9 KiB
Markdown
154 lines
5.9 KiB
Markdown
# Wave 6 — Work package general information
|
|
|
|
**Items:** `CR-001`, `CR-003`, `CR-004`, `CR-018`, `A7`
|
|
**Depends on:** wave 5 merged
|
|
**Why here:** these are the field's most-requested changes and they need the location lists
|
|
(`T5.4`), the server aggregates (`T4.1`) and the token system (`T3.2`) to already exist.
|
|
|
|
---
|
|
|
|
### T6.1 — CR-001: P6 Activity ID and Description
|
|
|
|
- **Items:** `CR-001`
|
|
- **Depends on:** T5.5
|
|
- **Blocks:** nothing
|
|
- **Surface:** `server/` + `html/`
|
|
- **Files:** work package model, General Information section, list/dashboard, PDF export
|
|
|
|
**Intent:** Every work package traces back to the P6 schedule activity that drives it, so a
|
|
date on the work package is anchored to a schedule activity rather than floating on its own.
|
|
The meeting placed this at the top of the work package, next to the due date.
|
|
|
|
**Do:** Add `P6 Activity ID` and `P6 Activity Description` to General Information. Free text
|
|
is acceptable — a validated lookup against an imported activity list is explicitly deferred,
|
|
partly because the Micron schedule is actively being reworked.
|
|
|
|
Display the Activity ID next to the Due Date so the schedule driver is visible without
|
|
scrolling. Add it to the list/dashboard as a sortable column and to the PDF export.
|
|
|
|
**Done when:**
|
|
|
|
- [ ] both fields exist, persist, and survive a reload
|
|
- [ ] Activity ID renders next to Due Date on the detail view
|
|
- [ ] the list/dashboard column sorts correctly, including with empty values
|
|
- [ ] both fields appear on the PDF export
|
|
- [ ] the fields respect the `CR-006` section toggles
|
|
|
|
---
|
|
|
|
### T6.2 — CR-003: Priority
|
|
|
|
- **Items:** `CR-003`
|
|
- **Depends on:** T3.5
|
|
- **Blocks:** nothing
|
|
- **Surface:** `server/` + `html/`
|
|
- **Files:** work package model, General Information, list/dashboard, PDF export
|
|
|
|
**Intent:** Due date alone does not convey urgency. Exactly three levels, agreed live in the
|
|
meeting: Normal, High, Urgent. Normal is the baseline default.
|
|
|
|
**Do:** A required dropdown with those three values, defaulting to Normal. Filterable and
|
|
sortable on the dashboard. Color-coded using canonical tokens only (`X7`). Printed on the
|
|
PDF export.
|
|
|
|
Priority is independent of status: it can change after issue without a status change.
|
|
|
|
**Do not:** add a fourth level. Do not introduce a new color outside the token system.
|
|
|
|
**Done when:**
|
|
|
|
- [ ] exactly three values exist; Normal is the default on a new work package
|
|
- [ ] the dashboard filters and sorts by priority
|
|
- [ ] priority colors come from canonical tokens; no raw hex added
|
|
- [ ] color is not the only signal — the label is always present
|
|
- [ ] priority prints on the PDF export
|
|
- [ ] changing priority does not alter status
|
|
|
|
---
|
|
|
|
### T6.3 — CR-004: Building / Floor / Sector dropdowns
|
|
|
|
- **Items:** `CR-004`
|
|
- **Depends on:** T5.4, T4.1
|
|
- **Blocks:** T6.4, T8.4
|
|
- **Surface:** `server/` + `html/`
|
|
- **Files:** Location section, work package model, dashboard filters
|
|
|
|
**Intent:** Users pick location from a controlled list rather than typing it. Floors within
|
|
B100 behave like separate buildings and are the unit of both execution and cost tracking.
|
|
|
|
**Do:** Three dependent dropdowns in the Location section, sourced from the project
|
|
configuration built in `T5.4`. Selecting a Building filters Floors; selecting a Floor filters
|
|
Sectors. Store codes, not display strings. Add dashboard filters for all three.
|
|
|
|
**Do not:** free-text these fields, and do not read the option lists from `localStorage`
|
|
(`X5`).
|
|
|
|
**Done when:**
|
|
|
|
- [ ] all three render as dropdowns populated from project configuration
|
|
- [ ] dependent filtering works, and clearing a parent clears its children
|
|
- [ ] values persist as codes; confirm by inspecting stored data
|
|
- [ ] the dashboard filters by each of the three
|
|
- [ ] a work package referencing a deactivated value still renders correctly
|
|
- [ ] all option data comes from the server
|
|
|
|
---
|
|
|
|
### T6.4 — CR-018: Rollup by floor and area
|
|
|
|
- **Items:** `CR-018`
|
|
- **Depends on:** T6.3, T4.1
|
|
- **Blocks:** nothing
|
|
- **Surface:** `server/` + `html/`
|
|
- **Files:** aggregate endpoints, dashboard
|
|
|
|
**Intent:** This is why the Acumatica cost code was removed rather than relabeled. The
|
|
tracking dimension the team wants is floor and area, not an accounting code. For Phase 2 the
|
|
intent is to stop treating B100 as one building and monitor by floor, since each floor
|
|
carries its own instrumentation and material load.
|
|
|
|
**Do:** Extend the `T4.1` aggregates to group and total by Building, Floor and Sector. Surface
|
|
grouped totals on the dashboard. Where hours are captured (Closeout `Actual Hours`, retained
|
|
per `CR-017`), roll them up along the same dimensions.
|
|
|
|
**Done when:**
|
|
|
|
- [ ] the dashboard groups and totals by Building, Floor and Sector
|
|
- [ ] totals reconcile against an unfiltered count; verify with a known data set
|
|
- [ ] Actual Hours rolls up along the same dimensions
|
|
- [ ] grouping is computed server-side
|
|
- [ ] work packages with no location assigned appear in an explicit "unassigned" group rather than vanishing
|
|
|
|
---
|
|
|
|
### T6.5 — A7: Card status lines, footer clarity, language and time
|
|
|
|
- **Items:** `A7`
|
|
- **Depends on:** T3.5
|
|
- **Blocks:** nothing
|
|
- **Surface:** `html/`
|
|
- **Files:** card components, footer, `admin.js:484-517`
|
|
|
|
**Do:** Clarify status lines on cards and tidy the footer as proposed.
|
|
|
|
**Do not:** remove localization. `admin.js:484-517` handles language and time and it is a
|
|
shipped feature. The review specifically endorsed keeping it. If the proposal reads as
|
|
removing it, that reading is wrong.
|
|
|
|
**Done when:**
|
|
|
|
- [ ] card status lines read clearly and use the canonical status colors
|
|
- [ ] the footer is unambiguous about what it is showing
|
|
- [ ] localization still functions; verify by switching language and time format
|
|
- [ ] `admin.js:484-517` behavior is unchanged
|
|
|
|
---
|
|
|
|
## Wave 6 exit criteria
|
|
|
|
- [ ] P6 activity, priority and structured location all persist and export
|
|
- [ ] the dashboard filters by priority and by all three location levels
|
|
- [ ] rollups are server-computed and reconcile
|
|
- [ ] localization intact
|