Files

n.siegfried 0e40e967a0 T3.1 - C3/S5: inventory the token systems, and correct the accent baseline

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>

2026-08-15 18:24:52 -05:00

10 KiB

Raw Blame History

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

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.

10 KiB Raw Blame History Unescape Escape