190144c539062067c7ad905a4c544e4e8b272602
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 12c0e5ca74 |
Wave 3 exit - record what the wave actually changed on screen
wave-3.md asks for "no unintended visual change on any page versus wave 2".
Measured with tests/token_check.py,
|
|||
| ce6fb840f0 |
T3.5 - A5: one button system, and green goes back to being a status
251 buttons across the 7 pages, counted in the browser with every wizard step,
creator section and tool panel forced visible. Two thirds of them are
display:none at load, so a static grep sees about eighty and misses the rest.
FOUR ROLES, defined once in theme-light.css as --wp-btn-*, and no fifth:
primary the one action the screen exists for. Filled accent.
secondary every other real action. White, --border-strong, accent on hover.
tertiary navigating or undoing. No fill, no border, accent text.
danger destructive. Outlined red; filled red only where the control is too
small for an outline to read - the 28px x on a sequence row.
Every button class is mapped to a role in docs/reference/tokens.md section 12.
No value is new: these are the fills the sheets already rendered, given one
definition so that "primary" means one thing.
GREEN IS A STATUS COLOUR AND NO LONGER FILLS A BUTTON. A5 names two green action
buttons; there are four. .use-btn and the launcher's completed-SOP card button
never render green in the default fixture, so the review could not have seen
them - the SOP has to be finished and a suggested value has to be offered first.
.nav-btn.primary "SOP complete" wizard
.btn.btn-generate "Save & view" creator
.use-btn creator
.card.complete .card-button launcher
The green did not go anywhere. .cstatus button.on-cleared, .toggle-btn.enabled,
.wp-nav-dot.ok, .rb-ready, .badge-R and the launcher card's own left border and
status line all still carry it, and every one of those is a state rather than an
action. The launcher card in particular still says "complete" twice after this
change; it just no longer says it on the button.
SENTENCE CASE, applied to buttons and field labels only, which is the scope A5
sets. First word capitalised, the rest lowercased, acronyms and external proper
nouns left alone (SOP, QC, WP, UPN, PM/APM/CM/QM, PDF, JSON, CSV, BIM, MIMO,
Excel, Acumatica).
~30 button labels across launcher, wizard, creator, admin and two scripts
46 field labels
text-transform:uppercase removed from 4 rules - .btn and .add-btn (creator
buttons), label and .cmt-namebar label (creator field labels)
Labels carrying markup - a .req asterisk, a .help-tip chip - had only their text
nodes transformed, so the markup survives and "first word" means the first word
of the label rather than of each fragment. The creator's mono face, 10px size and
tracking are its idiom and are untouched; only the forced uppercase goes.
help.js was updated too. It names "Load Sample" and "SOP Complete" in prose, so
renaming the buttons without it would have left the help centre describing
controls that no longer exist. That coupling is the only place in the app where
button text is referenced by name.
Verified by re-running the inventory: 0 green action buttons, 0 uppercase button
labels, 251 buttons still present - nothing was lost in the rename.
console.css card headers are unchanged, confirmed by diff: the only six lines
this task touches in that file are token substitutions on button/button.primary/
button.danger, none of them within twenty lines of .card h2.
f_items 5 FIXED / F6 REPRODUCES. browser_check 71/71.
Left alone and logged: .step-tab is still uppercase (BL-015) - it is a stepper
tab, neither a button nor a field label, and A4/S9 rebuild the stepper. Table
headers, section eyebrows and headings keep their case throughout. BL-008 and
BL-009 were re-targeted from T3.5 to wave 9: both are colour merges on a field
fill and a status pill, and this task is scoped to buttons.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|||
| 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> |
|||
| 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> |
