n.siegfried
0e40e967a0
Produces docs/reference/tokens.md. No stylesheet is touched; T3.1 is inventory. What the inventory found that the plan did not say: - It is six stylesheets plus the launcher's inline <style>, not four (D1 again). 202 custom-property declarations, all listed with file and line. - The wave 0 accent baseline is wrong: 15 declarations across 5 sheets, not 14 across 4. console.css:13 packs five declarations onto one line and the baseline's `^\s*--` regex only ever matches the first, so console's own --accent was never counted. Corrected command is in tokens.md section 10. The wave 9 target of one sheet is unchanged; there is one more to remove. - Three mono stacks, not two. The file map recorded console.css dropping ui-monospace and Segoe UI Mono; wp-chrome.css:159,221 is a third stack that drops Cascadia Mono and Segoe UI Mono. - --shadow-lg does not differ by blur, as the file map says. Both are 0 4px 16px. The difference is the colour: rgba(0,0,0,.16) against rgba(20,30,50,.12). That means they can be unified later with no layout consequence at all. - Twelve var() fallbacks can never fire, because the token they fall back from is declared at :root on a sheet the page loads. Free deletions for T3.2. - --shadow: none is a no-op token with 8 consumers. Left for T3.3, which is hunting exactly this class of silent nothing. - 111 var() references live in .js files across 23 token names. A rename there fails silently - no build error, no console warning, just an unstyled element. Section 9 is the list to grep before deleting any alias. - There is a second brand blue: #2563d6, filling .sop-inherited at 7% alpha on every field a work package inherited from its SOP. Logged as BL-008. The document states one rule up front, because it is the difference between a clean wave 3 and a broken one: consolidation is not unification. Where two sheets declare the same value, T3.2 collapses them. Where they declare different values for the same role - the two banner greens, the three error borders, the two shadows - each value gets its own canonical name and the pair is recorded. Picking a winner between two near-identical greys is a visual change, which T3.2 forbids. Section 8 computes the near-duplicates rather than eyeballing them. The one to watch is the zebra stripe: console's #fafafa sits six points from #f4f4f4, and collapsing them erases the striping on the nine-column user table. New backlog entries: BL-004 (help.js ships 52 colours in a different design language), BL-005 (two modals styled entirely by inline style= attributes), BL-006 (17 half-pixel font sizes), BL-007 (--radius: 0 contradicted 45 times in the sheet that declares it), BL-008 (the second blue). One decision T3.2 needs and this task cannot make: adopting the superset mono stack changes the rendered face on machines that have Segoe UI Mono or ui-monospace but not IBM Plex Mono, which is most of the target environment. That is a real change on admin and users. Either accept it and re-shoot those two baselines - capturing twice, since they are not byte-stable - or keep console.css's narrower stack as a second token until T3.5. Written up in tokens.md section 6d and 8-H; built to neither until it is answered. Verification: f_items 5 FIXED / F6 REPRODUCES as expected, browser_check 71/71. Screenshots not applicable - this task changes no rendered surface. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
183 lines
10 KiB
Markdown
183 lines
10 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.
|