Five tasks, three probes, 156 new checks. Every wave-6 item persists, exports
and filters, and the rollup adds up at every level rather than only at the leaf.
Each task had one decision it had to make rather than inherit, and each is
recorded in wave-6.md because a later reader will otherwise read the behaviour
as an accident:
T6.1 blanks sort LAST in both directions
T6.2 priority sorts by escalation, not alphabetically
T6.3 the stored value is the full path, not the node's own code
T6.4 the unassigned group is shown, or the totals do not reconcile
T6.5 a card has three states, so it needs three status lines
admin.js is byte-identical. A7's note about localization is the loudest "do not"
in the wave file and cards_check proves it two ways.
Screenshots re-captured at 390 and 1440 across all seven pages. One overflow,
the known creator@390 (BL-001), unchanged.
Carried forward unchanged: BL-010 (829 spacing/type literals - wave 6 re-laid-out
none of the pages carrying them), BL-018, BL-019. BL-018 has now cost three
separate probes a hand-seeded SOP; browser_check's fixture should adopt the
production {sop, state} shape when it is fixed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
209 lines
8.8 KiB
Markdown
209 lines
8.8 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
|
|
|
|
- [x] P6 activity, priority and structured location all persist and export
|
|
- [x] the dashboard filters by priority and by all three location levels
|
|
- [x] rollups are server-computed and reconcile — at **every** level, not only the leaf
|
|
- [x] localization intact — `admin.js` is byte-identical, and the feature was driven
|
|
end to end rather than read
|
|
|
|
---
|
|
|
|
## Wave 6 exit — what shipped
|
|
|
|
| Task | Items | What landed |
|
|
|---|---|---|
|
|
| `T6.1` | `CR-001` | P6 activity ID and description, beside the due date; a sortable board column |
|
|
| `T6.2` | `CR-003` | Priority — three levels, Normal default, sortable by escalation, filterable |
|
|
| `T6.3` | `CR-004` | Dependent Building / Floor / Sector dropdowns; codes, not typed strings |
|
|
| `T6.4` | `CR-018` | Server-side rollup at every level, hours included, unassigned explicit |
|
|
| `T6.5` | `A7` | Card status in all three states; a footer that says what it is showing |
|
|
|
|
### The one decision each task had to make, rather than inherit
|
|
|
|
- **`T6.1`** — "sorts correctly, including with empty values" is not a behaviour, it is a
|
|
choice. **Blanks sort last in both directions**, because nobody sorts by a column in
|
|
order to look at the rows with nothing in it.
|
|
- **`T6.2`** — priority sorts by **escalation**, not alphabetically. `High, Normal, Urgent`
|
|
would put the most urgent last, which is the one thing the column exists to prevent.
|
|
- **`T6.3`** — the stored value is the full **path** (`B-ONE/L1`), not the node's own code.
|
|
A floor's own code is not unique across buildings; its path is. That is what lets a
|
|
building filter match everything beneath it with a prefix test.
|
|
- **`T6.4`** — the unassigned group is **shown**. A group set that omits it does not sum to
|
|
the project total, and a rollup that does not reconcile is decoration.
|
|
- **`T6.5`** — a card has **three** states, so it needs three status lines, not one plus
|
|
silence. The silent one was the commonest state on a live project.
|
|
|
|
### What did not change, deliberately
|
|
|
|
`admin.js` — not one byte. `A7`'s note about localization is the loudest "do not" in the
|
|
wave file, and `tests/cards_check.py` proves it two ways: by driving the feature through a
|
|
save and a reload, and by diffing the file.
|
|
|
|
### Probes
|
|
|
|
```bash
|
|
python tests/generalinfo_check.py # CR-001 / CR-003 49 checks
|
|
python tests/rollup_check.py # CR-004 / CR-018 63 checks
|
|
python tests/cards_check.py # A7 44 checks
|
|
```
|
|
|
|
Both `CR-004` and `CR-018` are checked the way `aggregates_check.py` checks its own: by
|
|
**poisoning `localStorage`** and demanding the server's answer. `X5` makes both blocking on
|
|
`B4` for exactly that reason, so agreeing with the browser would have proved nothing.
|
|
|
|
### Carried forward
|
|
|
|
- **BL-010** unchanged again. Wave 6 added rules that consume tokens; it re-laid-out no page
|
|
that carries the 829 literals. `T7.1` still owns it.
|
|
- **BL-018** unchanged and now touched twice: three separate probes have had to seed a SOP
|
|
in the `{sop, state}` shape because `browser_check.py`'s fixture does not use it. That
|
|
fixture should adopt the production shape when BL-018 is fixed.
|
|
- **BL-019** unchanged — the cost-code `<select>` still drops a value that has left the list.
|