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>
This commit is contained in:
217
docs/waves/wave-9.md
Normal file
217
docs/waves/wave-9.md
Normal file
@@ -0,0 +1,217 @@
|
||||
# Wave 9 — Verification and cleanup
|
||||
|
||||
**Items:** `CR-008`, `CR-017` (guard), `S6`, `S7`, `S8`, `C1` audit, `C2` audit, part of `C4`
|
||||
**Depends on:** wave 8 merged
|
||||
**Why last:** `CR-008` reviews the PDF export against the final structure rather than
|
||||
reviewing it twice. The audits confirm the standing requirements actually held across eight
|
||||
waves rather than being asserted per PR.
|
||||
|
||||
---
|
||||
|
||||
### T9.1 — CR-008: PDF export review
|
||||
|
||||
- **Items:** `CR-008`
|
||||
- **Depends on:** T8.5
|
||||
- **Blocks:** nothing
|
||||
- **Surface:** `server/` + `html/`
|
||||
- **Files:** PDF export
|
||||
|
||||
**Problem:** The export was never walked through in the meeting. It needs a pass to confirm
|
||||
it prints what the field actually needs and nothing it does not, now that the work package
|
||||
structure has changed substantially.
|
||||
|
||||
**Do:** Review the export section by section against the final structure. Sections toggled
|
||||
off under `CR-006` must be omitted. The export must include: P6 Activity ID and Description,
|
||||
Priority, Building / Floor / Sector, scope of work, materials, constraints with status,
|
||||
QA/QC, and an attachment index. Removed fields — ACU Cost Code, Acumatica Task — must not
|
||||
appear.
|
||||
|
||||
Open question to raise in the PR, not to decide alone: should attachments merge into a single
|
||||
PDF package, or be listed as separate files? The field preference expressed in the meeting
|
||||
was to hand someone exactly the sheet they need and nothing more, which argues for a merged
|
||||
package with only the attached sheets. Propose, do not assume.
|
||||
|
||||
**Done when:**
|
||||
|
||||
- [ ] every listed field appears in the export
|
||||
- [ ] toggled-off sections are absent
|
||||
- [ ] ACU Cost Code and Acumatica Task appear nowhere
|
||||
- [ ] the export is legible printed in black and white
|
||||
- [ ] the export is legible opened on a tablet
|
||||
- [ ] the attachment index lists every attachment with its description
|
||||
- [ ] the merge-versus-list question is raised in the PR with a recommendation
|
||||
|
||||
---
|
||||
|
||||
### T9.2 — CR-017: Actual Hours guard
|
||||
|
||||
- **Items:** `CR-017`
|
||||
- **Depends on:** T9.1
|
||||
- **Blocks:** nothing
|
||||
- **Surface:** verification only
|
||||
- **Files:** Closeout section
|
||||
|
||||
**This is a guard, not a build.** Removing Actual Hours was floated in the meeting and
|
||||
rejected — Marlena said she likes tracking actual hours spent so it can be measured. It is
|
||||
listed here so a later simplification pass does not quietly drop it.
|
||||
|
||||
**Do:** Confirm Actual Hours still exists in Closeout, is optional rather than required, and
|
||||
survived eight waves of change.
|
||||
|
||||
**Done when:**
|
||||
|
||||
- [ ] Actual Hours exists in Closeout and persists
|
||||
- [ ] it is optional, and a work package can be closed without it
|
||||
- [ ] it rolls up per `T6.4`
|
||||
- [ ] a follow-up item is logged for comparing actual against estimated hours to produce a productivity factor
|
||||
|
||||
---
|
||||
|
||||
### T9.3 — S6: One icon system
|
||||
|
||||
- **Items:** `S6`
|
||||
- **Depends on:** T9.1
|
||||
- **Blocks:** nothing
|
||||
- **Surface:** `html/`
|
||||
- **Files:** every page
|
||||
|
||||
**Problem:** The icon set mixes emoji and dingbats, and at least one glyph is used for two
|
||||
different meanings on the same page.
|
||||
|
||||
**Do:** Pick one icon system and convert everything to it. Build a mapping of meaning to icon
|
||||
and record it in `docs/reference/tokens.md`. Resolve every duplicate meaning.
|
||||
|
||||
**Do not:** leave emoji in the UI. They render differently per platform, which is part of why
|
||||
the same glyph reads as two things.
|
||||
|
||||
**Done when:**
|
||||
|
||||
- [ ] one icon system across all 6 pages
|
||||
- [ ] no glyph carries two meanings anywhere
|
||||
- [ ] every icon has a text label or an accessible name
|
||||
- [ ] the meaning-to-icon mapping is documented
|
||||
- [ ] icons render identically on Windows, macOS and a tablet
|
||||
|
||||
---
|
||||
|
||||
### T9.4 — S7: Sample-data cleanup
|
||||
|
||||
- **Items:** `S7`
|
||||
- **Depends on:** T9.1
|
||||
- **Blocks:** nothing
|
||||
- **Surface:** `html/` + `server/`
|
||||
- **Files:** every sample-data affordance
|
||||
|
||||
**Problem:** Four sample-data affordances under three names. One sits a single click from
|
||||
live project data with no confirm and no undo.
|
||||
|
||||
**Do:** Reduce to one affordance with one name. Move it away from live project actions. Add a
|
||||
confirmation stating exactly what will happen, and make it reversible or clearly scoped to a
|
||||
sample project only.
|
||||
|
||||
**Done when:**
|
||||
|
||||
- [ ] exactly one sample-data affordance exists, under one name
|
||||
- [ ] it is not adjacent to any live project action
|
||||
- [ ] it confirms before acting, naming what it will do
|
||||
- [ ] it cannot touch live project data; verify by attempting it against a real project
|
||||
- [ ] the other three affordances are removed; grep confirms
|
||||
|
||||
---
|
||||
|
||||
### T9.5 — C1 + S8: Accessibility audit
|
||||
|
||||
- **Items:** `C1`, `S8`
|
||||
- **Depends on:** T9.3
|
||||
- **Blocks:** nothing
|
||||
- **Surface:** `html/`
|
||||
- **Files:** all pages, `.help-tip` elements
|
||||
|
||||
**`S8` is finished here** because tooltips are the one accessibility item with no natural
|
||||
host component earlier in the plan. 15 `.help-tip` badges are `<span>` elements with no
|
||||
`tabindex`, so the `:focus` half of their CSS rule is dead code and there is no touch path at
|
||||
all — on tablets, which is exactly what Field View targets.
|
||||
|
||||
**Do:** Make every `.help-tip` reachable by keyboard and by touch. Then audit the whole app
|
||||
against the `CLAUDE.md` rules and record results in `docs/reference/accessibility-audit.md`.
|
||||
|
||||
Compare against the wave 0 baseline counts:
|
||||
|
||||
| Metric | Baseline | Target |
|
||||
|---|---|---|
|
||||
| `<div>` / `<span>` with `onclick` | 12 / 2 | 0 |
|
||||
| `.help-tip` unreachable by keyboard | 15 | 0 |
|
||||
| `aria-live` regions | 0 | at least 1 per toast system and banner |
|
||||
| Text below 4.5:1 | present | 0 |
|
||||
| `outline: none` without replacement | present | 0 |
|
||||
| Native dialogs (`alert`/`confirm`/`prompt`) | 79 | 0, or documented exceptions |
|
||||
|
||||
**Done when:**
|
||||
|
||||
- [ ] every `.help-tip` works by keyboard and by touch
|
||||
- [ ] every metric above meets target, or the gap is documented with a reason and a follow-up item
|
||||
- [ ] a full keyboard-only pass completes the primary flow: sign in, create project, SOP wizard, create work package, issue it
|
||||
- [ ] the audit document exists with per-page results
|
||||
|
||||
---
|
||||
|
||||
### T9.6 — C2: Mobile pass
|
||||
|
||||
- **Items:** `C2`
|
||||
- **Depends on:** T9.5
|
||||
- **Blocks:** nothing
|
||||
- **Surface:** `html/`
|
||||
- **Files:** all pages
|
||||
|
||||
**Problem:** Nothing in the original proposal touched mobile, and it is where the worst
|
||||
rendering was found. Field View at 390px is the gloved-hands surface.
|
||||
|
||||
**Do:** A deliberate pass at 390px across all 6 pages and the full primary flow. Capture
|
||||
after screenshots and compare against the wave 0 baseline.
|
||||
|
||||
**Done when:**
|
||||
|
||||
- [ ] the full primary flow completes at 390px without horizontal scrolling
|
||||
- [ ] tap targets are at least 44px throughout
|
||||
- [ ] no control is clipped, overlapped or unreachable on any page
|
||||
- [ ] `CR-007` attachments open at 390px, offline
|
||||
- [ ] `T8.5` material requests can be raised at 390px
|
||||
- [ ] after screenshots for all 6 pages at 390px are committed alongside the baseline
|
||||
|
||||
---
|
||||
|
||||
### T9.7 — Final reconciliation
|
||||
|
||||
- **Items:** all
|
||||
- **Depends on:** T9.6
|
||||
- **Blocks:** nothing
|
||||
- **Surface:** documentation
|
||||
- **Files:** creates `docs/reference/completion.md`
|
||||
|
||||
**Do:** Walk all 55 items from `IMPLEMENTATION.md` section 6 and record, for each: built /
|
||||
deferred / not applicable, the PR that delivered it, and any deviation from its written
|
||||
acceptance criteria.
|
||||
|
||||
Explicitly confirm the four out-of-scope items in section 7 were not built: no parts catalog
|
||||
or inventory, no asset database integration, no CxAlloy integration, no P6 activity import.
|
||||
|
||||
Then list what the plan learned that the next revision should carry: items whose acceptance
|
||||
criteria turned out wrong, inputs still outstanding, and follow-ups logged along the way.
|
||||
|
||||
**Done when:**
|
||||
|
||||
- [ ] all 55 items are accounted for with a PR reference or a stated reason
|
||||
- [ ] every deviation from written acceptance criteria is documented
|
||||
- [ ] the four out-of-scope items are confirmed unbuilt
|
||||
- [ ] outstanding inputs from `IMPLEMENTATION.md` section 8 are restated with current status
|
||||
- [ ] follow-ups are collected in one place for the next revision
|
||||
|
||||
---
|
||||
|
||||
## Wave 9 exit criteria
|
||||
|
||||
- [ ] the export matches the final structure
|
||||
- [ ] one icon system, one sample-data affordance
|
||||
- [ ] accessibility metrics hit target or are documented
|
||||
- [ ] the primary flow works at 390px
|
||||
- [ ] every item is reconciled
|
||||
Reference in New Issue
Block a user