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>
239 lines
14 KiB
Markdown
239 lines
14 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.
|
||
|
||
## 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
|
||
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.
|
||
|
||
### 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.
|