Files
Project-SDE-WP-Suite/docs/waves/backlog.md
n.siegfried 9ab7b48de2 T3.2 - C3/S5: one source of truth for colour; page sheets alias only
theme-light.css is now the only file in html/ that contains a colour literal.
The five page stylesheets and all four inline <style> blocks declare names and
nothing else.

  theme-light.css                 191 declarations, 175 with a literal value
  console.css                      28 declarations,   0
  work-package-suite-styles.css    16 declarations,   0
  wp-chrome.css                    14 declarations,   0
  wp-creation-styles.css           24 declarations,   0
  wp-sidenav.css                    0 declarations,   0

#0f62fe is declared in one sheet, down from five. The eleven occurrences left
inside theme-light.css are Carbon's own v10-to-v11 alias layer, which the
inventory records as deliberate and not the S5 defect.

Names were kept, because 111 var() references live in .js files across 23 token
names and a rename there fails silently - no build error, no console warning,
just an unstyled element.

The rule the refactor was built on: consolidation is not unification. Where two
sheets declared the same value, they collapse. Where they declared DIFFERENT
values for one role - the two shadows, the eight status borders doing four jobs,
the three mono stacks - each value got its own canonical name and the pair is
recorded for T3.5. Picking a winner between two near-identical greys is a
rendered change, which this task forbids. The console's zebra stripe is the one
that would have bitten: #fafafa is six points from #f4f4f4, and merging them
erases the striping on the nine-column user table.

Collecting the one-offs in one place made two things countable that were not
before: twelve distinct shadows, and a ninth amber (#8a6d00 on the field view,
four points from #8e6a00 and doing the same job - BL-009).

VERIFICATION - the screenshot done-when could not do the job, so it was replaced.

Captured against wave 2, 11 of 14 shots were pixel-identical and 3 were not.
Capturing wave 2 against ITSELF produced the same 3 differences at the same
bounding box, so those shots cannot distinguish a regression from the clock.
Trap 2 in the brief is half wrong: users.html is stable at both widths; the
unstable third is the creator at 1440px, and admin's captured page height varies
by ~600px between runs (BL-012).

So tests/token_check.py was added. It checks what wave 3 actually claims: that
every custom property resolves to the same literal, and every element computes
the same colours, shadows and type. That is stronger than a screenshot - it
covers the hover, focus and disabled rules a screenshot never exercises, and it
is deterministic.

  wave 2 vs T3.2, all 7 pages:
  178/178 wave-2 token names resolve identically, +213 new
  3,500 elements compute identically, zero added, zero removed
  16 tokens differ in notation only (#fff -> #ffffff), which is the duplicate
  class this task existed to collapse

Two detours worth not repeating: the element walk was first keyed by sibling
index and reported 55 phantom differences on the SOP page, where three
JS-injected overlays append in whichever order their async work finishes
(BL-011); and the comparator now normalises notation before reporting, because
otherwise it fails on its own success.

f_items 5 FIXED / F6 REPRODUCES as expected. browser_check 71/71.

ONE DONE-WHEN NOT MET, recorded rather than skipped: "no page stylesheet
declares a raw color, spacing or type value". The colour half is met in full.
483 raw spacing values, 281 font-sizes and 65 radii remain inside rules, 492 of
them in the creator. That is arithmetic, not effort: the creator's spacing is
every integer from 1px to 14px, so no token exists that padding:9px 11px maps to
without changing one of the numbers - and this task forbids changing a rendered
value. The two requirements are mutually exclusive. Logged as BL-010 for T5.x
and T7.1, where those pages are re-laid-out and the values get chosen again.

New backlog: BL-009 (ninth amber), BL-010 (raw spacing/type in rules),
BL-011 (overlay append race), BL-012 (unstable screenshot targets).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-15 18:50:30 -05:00

239 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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.
## 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.
- **Root cause, found at T1.4 — not fixed, T7.1 owns it.** `wp-creation-styles.css:815` has
`@media (max-width: 860px) { body { --nav-w: 56px; } }`, which is correct. But
`wp-creation-app.js:1389` injects `body{--nav-w:288px;}` into a runtime `<style>` with no
media query. Injected last, same specificity, so it **wins over the media query** and
`--nav-w` stays 288px at every width. Everything keyed off it then reserves 288px of
rail that is not there: `.main` padding-left `calc(288px + 28px)`
(`wp-creation-styles.css:109`), `.ctx-bar` (`:452`), `.release-banner` (`:488`),
`.section-nav-bar` (`:596`) and `.sticky-save { left: var(--nav-w,288px) }` (`:820`).
At a 390px screen that forces the initial containing block to 485px.
The fix is to give the injected rule the same breakpoint, or to stop injecting the
value that the stylesheet already declares — one line, but it belongs with the creator
rebuild rather than in a wave 1 rendering task.
- **Consequence for `F4`:** every `position: fixed; right: 0` element on this page sits at
the right edge of that 485px box, which is 95px off the visible 390px screen. The
comments drawer is placed correctly relative to its containing block; the containing
block is wrong. `T1.4` reports this as an attributed note rather than a drawer defect,
so nobody is sent to the wrong file.
- **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
2444px 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.
### BL-004 — `help.js` ships a 52-colour palette in a different design language
- **Found during:** T3.1
- **Where:** `html/help.js:79` (the injected `<style>`)
- **What:** the help centre injects its own stylesheet with **52 colour literals and zero
`var()`**. It is not a fourth copy of the suite palette — it is a different one: slate
(`#27313f`, `#334155`, `#e2e8f0`), violet (`#7c3aed`, `#f3e8ff`), its own blue
(`rgba(37,99,214,.15)`, see BL-008) and its own greys (`#fafbfc`, `#eef1f6`, `#f4f6f9`,
`#f7f8fa`). It loads on the launcher, SOP wizard, creator and field view.
- **Why not now:** `T3.2`'s contract is "no rendered change", and converting this palette is a
restyle, not a consolidation — it would change the help centre on four pages and break the
empty-screenshot-diff done-when. The token rule in `CLAUDE.md` does reach it, so it is real
work, not a non-issue.
- **Suggested wave or follow-up:** wave 9, alongside `C4`. Documented in
`docs/reference/tokens.md` §1.
### BL-005 — Two modals are styled entirely by inline `style=` attributes
- **Found during:** T3.1
- **Where:** `html/auth-guard.js:67-92` (change-password) and `html/wp-format.js:120-150`
(preferences)
- **What:** 35 raw colour literals between them — `#0f62fe`, `#8d8d8d`, `#e0e0e0`, `#defbe6`,
`#fff1f1`, `#0e6027`, `rgba(20,30,50,.5)` and so on — written into `style=` strings, so no
stylesheet can reach them and no token can either.
- **Why not now:** they are markup built by JS, not a stylesheet, so they are outside `T3.2`'s
four-sheet surface. Both dialogs are rebuilt as accessible components under `C1`.
- **Suggested wave or follow-up:** `T9.5`, with the `C1` audit.
### BL-006 — Seventeen half-pixel font sizes
- **Found during:** T3.1
- **Where:** `html/wp-creation-styles.css` (14) and `html/wp-chrome.css` (3)
- **What:** `9.5px`, `10.5px`, `11.5px`, `12.5px`, `13.5px` sit inside an otherwise integer
type scale of 27 distinct sizes. They round inconsistently between engines and there is no
reason for any of them.
- **Why not now:** retiring them moves text on every creator screen; `T3.2` forbids rendered
change and `T7.1` re-lays-out this page anyway.
- **Suggested wave or follow-up:** `T7.1`. See `docs/reference/tokens.md` §6a.
### BL-007 — `--radius: 0` is contradicted 45 times in the sheet that declares it
- **Found during:** T3.1
- **Where:** `html/wp-creation-styles.css:26` and 45 raw `border-radius` values in the same file
- **What:** the creator declares `--radius: 0` and honours it 23 times, then writes `2px 3px
4px 5px 6px 8px 9px 10px 12px 14px 20px 50%` directly in 45 other places, plus two
asymmetric CTA radii at `:707` and `:716`. Square corners are the Carbon idiom and the
intent everywhere else in the suite; this one sheet drifted.
- **Why not now:** changing 45 radii is the most visible diff available, and `T3.2` must
produce none.
- **Suggested wave or follow-up:** `T7.1`. See `docs/reference/tokens.md` §6c.
### BL-008 — There is a second brand blue: `#2563d6`
- **Found during:** T3.1
- **Where:** `html/wp-creation-styles.css:565`, `html/help.js`, `html/wp-creation-app.js:1257`
- **What:** `.sop-inherited` — the highlight on every field a work package inherited from its
SOP — fills with `rgba(37,99,214,0.07)`, which is **`#2563d6`**, not the suite's `#0f62fe`.
`help.js` carries the same blue at `.15` alpha and the print window uses it solid for
headings. At 7% nobody has noticed, but "one accent colour" is not currently true even after
the four token systems collapse to one.
- **Why not now:** swapping it changes a rendered fill, which `T3.2` forbids. It is the same
conversation as the green action buttons.
- **Suggested wave or follow-up:** `T3.5`, with `A5`. See `docs/reference/tokens.md` §8-E.
### BL-009 — A ninth amber, four points from the eighth
- **Found during:** T3.2
- **Where:** `html/field.html:35` (`.pill.warn`)
- **What:** the field view's warn pill uses `#8a6d00`; every other warning text in the app is
`#8e6a00`. Four points apart, doing the same job, on the surface that is read through a
face shield. Almost certainly a typo rather than a decision — `field.html`'s inline `<style>`
was missed by the `T3.1` inventory, which is why it survived this long.
- **Why not now:** merging it moves a rendered colour, which `T3.2` forbids. `T3.2` named it
`--wp-status-warning-text-alt` so it is visible rather than hidden in a hex.
- **Suggested wave or follow-up:** `T3.5`. See `docs/reference/tokens.md` §8-K.
### BL-010 — 829 raw spacing, type and radius values remain inside rules
- **Found during:** T3.2
- **Where:** all five page stylesheets; 492 of them in `html/wp-creation-styles.css`
- **What:** `T3.2` removed every raw **colour** from the page sheets, but 483 spacing values,
281 font-sizes and 65 radii are still written literally in rules. The token *declarations*
are aliased — `--s1`…`--s6`, `--ctl`, `--radius`, `--mono`, `--sans` all resolve from
`theme-light.css` — but the rules that should consume them do not.
- **Why not now:** not effort — arithmetic. The creator's spacing is every integer from 1px to
14px, which is a histogram rather than a scale, so there is no token `padding: 9px 11px` maps
to without changing one of the two numbers. `T3.2` forbids changing a rendered value, so
tokenising these and honouring that constraint are mutually exclusive. This is the one `T3.2`
done-when not met, and it is recorded as not met rather than quietly skipped.
- **Suggested wave or follow-up:** `T5.x` and `T7.1`, where these pages are re-laid-out and the
values are being chosen again anyway. See `docs/reference/tokens.md` §6b and §11.
### BL-011 — Three JS-injected overlays race to append on the SOP page
- **Found during:** T3.2
- **Where:** `html/work-package-suite.html` — `#wp-sync-badge`, `.wp-navscrim`, `#wp-sidenav`
- **What:** the sync badge, the drawer scrim and the drawer are appended to `<body>` by three
different scripts after async work, so their DOM order varies run to run. Nothing is painted
differently — all three are `position: fixed` with their own `z-index` — but any test that
keys elements by sibling index sees dozens of phantom differences on this page. It cost real
time in `T3.2` before the cause was found, and `tests/token_check.py` now keys by identity
to avoid it.
- **Why not now:** invisible to users, and the fix is ordering in three separate scripts, which
is a change with no observable benefit while `T7.1` is still going to move this code.
- **Suggested wave or follow-up:** wave 9, if it is still true after `T7.1`.
### BL-012 — `admin.html` and the creator at 1440px are not stable enough to screenshot-diff
- **Found during:** T3.2
- **Where:** `tests/baseline_shots.py` output for `admin-390`, `admin-1440`, `creator-1440`
- **What:** the task brief's trap 2 says `admin.html` and `users.html` are not byte-stable.
Measured by capturing wave 2 against itself: **`users` is stable at both widths**, and the
unstable third is the **creator at 1440px** (344,272 px differ, bbox 288,14→1439,4924).
`admin` is worse than "live timestamps" suggests — its captured page *height* varies by about
600px between runs, so the two images cannot even be compared pixel-for-pixel.
- **Why not now:** the screenshots are a review aid, not a gate; `tests/token_check.py` now
covers what the diff was being asked to prove, and covers it better.
- **Suggested wave or follow-up:** wave 9, alongside `C2`. Either freeze the clock in the
fixture or exclude the live regions from capture — otherwise every later wave re-learns this.