Project-SDE-WP-Suite/docs/waves/backlog.md

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

### 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.

Found during implementation

BL-001 — The creator overflows horizontally at 1440px

• Found during: T0.2
• Where: html/wp-creation-index.html / html/wp-creation-styles.css
• What: the creator lays out 1,551px of content inside a 1,440px viewport, so the page scrolls sideways at desk width. Measured by tests/baseline_shots.py, which compares documentElement.scrollWidth against clientWidth at each capture. F2 covers narrow widths; no item covers this one. The other three overflowing pages (launcher 425px, SOP wizard 429px, field view 432px, all at a 390px viewport) are F2 and are already scheduled.
• Why not now: wave 1 is scoped to F1–F5, and T7.1 dissolves this page's iframe and rebuilds its layout regardless — fixing it in wave 1 would be thrown away.
• Suggested wave or follow-up: verify it is gone at T7.1; if it survives the rebuild, it needs its own item in the next revision.
• Update, T1.2: the 1440px half of this is resolved as a side effect, not by intent. The unbreakable #wp-usermenu run that T1.2 fixed was the cause of four of the five overflows recorded in wave 0 — launcher, SOP wizard and field view at 390px, and the creator at 1440px. Capture now reports overflow on 1 of 14 shots instead of 5. What remains is the creator at 390px (485px of content), which is its own layout rather than the shared chrome. Left open so T7.1 still checks it.

BL-002 — outline: none appears three times in the wizard sheet, not once

• Found during: T0.1
• Where: html/work-package-suite-styles.css:325, :347, :501
• What: A3/F5 cite the focus-ring removal at 322-328 only. The same outline:none + pale 3px glow is repeated at :347 (.user-pick:focus), and :501 (.seq-step input.seq-label:focus) removes the outline with no replacement at all, which is a straight CLAUDE.md violation.
• Why not now: it is in scope for T3.4, not a separate item — recorded so the task fixes all three rather than the one the review cited.
• Suggested wave or follow-up: fold into T3.4.

BL-003 — User-menu links are 16px tap targets

• Found during: T1.2
• Where: html/auth-guard.js:186-191 (buildUserMenu's link())
• What: every link in the app bar's user menu — including Sign out — renders 16px tall, from font:400 13px/1.2. T1.2 made them all reachable at 390px, but reachable is not the same as comfortably tappable on the gloved-hands surface. Well under the usual 24–44px guidance.
• Why not now: T1.2 is explicitly triage and T2.2 replaces this markup with the drawer, which has its own tap targets. Enlarging them here would change the 1440px layout the task must leave byte-identical, and would be thrown away in wave 2.
• Suggested wave or follow-up: T2.2 should ship the drawer with adequate targets; C1's audit at T9.5 confirms it app-wide.