n.siegfried
3d99d4b9d0
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>
54 lines
2.2 KiB
Markdown
54 lines
2.2 KiB
Markdown
# Backlog
|
|
|
|
Anything noticed during implementation that is real but not in the plan goes here instead of
|
|
into the current PR. `CLAUDE.md` requires this: every change traces to an item ID, so
|
|
unplanned work gets logged rather than built.
|
|
|
|
Add an entry, do not fix it inline. This file is reviewed at `T9.7` and feeds the next spec
|
|
revision.
|
|
|
|
## Format
|
|
|
|
```markdown
|
|
### BL-001 — Short title
|
|
|
|
- **Found during:** T3.2
|
|
- **Where:** path/to/file.js:120
|
|
- **What:** one or two sentences on the problem
|
|
- **Why not now:** out of scope for the current wave / needs a product decision / larger than the task
|
|
- **Suggested wave or follow-up:** wave 9 / next revision / needs Nick
|
|
```
|
|
|
|
## Known follow-ups already identified in the spec
|
|
|
|
These are logged from the source documents, not discovered in code. They are real but
|
|
deliberately deferred.
|
|
|
|
### BL-000a — Validated P6 activity lookup
|
|
|
|
- **From:** `CR-001`
|
|
- **What:** `CR-001` accepts free text for the P6 Activity ID. A validated lookup against an imported P6 activity list was identified as the eventual want.
|
|
- **Why not now:** the Micron schedule is actively being reworked, so importing an activity list now would import churn.
|
|
- **Suggested:** next revision, once the schedule stabilizes.
|
|
|
|
### BL-000b — Field-level toggles in General Information
|
|
|
|
- **From:** `CR-006`
|
|
- **What:** `CR-006` toggles whole sections. General Information may need per-field toggles, since projects differ in which identifiers they use.
|
|
- **Why not now:** section-level toggles cover every removal request currently on the list.
|
|
- **Suggested:** next revision, if a second project needs a different field set.
|
|
|
|
### BL-000c — Estimated versus actual hours productivity factor
|
|
|
|
- **From:** `CR-017`
|
|
- **What:** Actual Hours is retained and rolls up. Comparing it against estimated hours would produce a productivity factor, which was the stated reason for wanting the field.
|
|
- **Why not now:** estimated hours capture is not in scope this round.
|
|
- **Suggested:** next revision.
|
|
|
|
### BL-000d — Attachment merge versus list on export
|
|
|
|
- **From:** `CR-008` / `T9.1`
|
|
- **What:** whether the PDF export merges attachments into one package or lists them separately.
|
|
- **Why not now:** product decision, raised in the `T9.1` PR.
|
|
- **Suggested:** needs Nick.
|