6fbc5b9735f6763b770c598e404edf46359fe034
14 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 6fbc5b9735 |
Wave 4 exit - record the new probes and move the baseline counts
Wave 4's five exit criteria, and what shows each of them: counts come from the server, identical across users aggregates_check 16/16 work packages addressable by URL, incl. signed-out url_state_check 23/23 drafts autosave, unsaved work guarded, save honest autosave_check 34/34 toasts announce, helper text legible, focus visible a11y_check 22/22 X1 and X5 cleared see below X1 is cleared: a work package has an address, and WPUrl.absolute() is what CR-011 and CR-014 will paste into an email in wave 8. X5 is cleared: /api/wps/metrics returns by_location with its dimensions declared alongside the groups, so CR-004 and CR-018 can group by building/floor/sector in wave 6 by changing the dimensions and the keys, not the response shape. Four metrics moved off their wave 0 baselines and are recorded in the file map so wave 9 measures against the right numbers. The one that matters most is not in the plan's list: `outline: none` went from six to one, and the survivor has its replacement in the rule directly above it. The file map also now says to run the browser probes ONE AT A TIME. Chained, they exhaust the headless browser's ports and abort with "browser would not start", which reads as a code fault and is not one - it cost a confusing red run here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| 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>
|
|||
| 03d24138ed |
T3.4 - A3/F5 full, BL-002: the wizard's fields look editable and focus is visible
T1.5 stopped editable fields looking disabled by reaching past the wizard's own token block with a fallback: background: var(--cds-field, var(--bg-card)). T3.2 deleted the local tokens, so the fallback is now dead code and the canonical token is simply consumed. The interim comment is gone; grep for INTERIM in the sheet returns nothing, and the sheet declares no field-specific colour. Measured in the browser rather than asserted - every enabled text control in the suite, side by side: sop .field input #ffffff on #8d8d8d 1px sop .user-pick #ffffff on #8d8d8d 1px creator .field input #ffffff on #8d8d8d 1px console .toolbar input #ffffff on #8d8d8d 1px launcher .proj-row #ffffff on #8d8d8d 1px .user-pick was not identical before this commit, and that is the one thing here beyond the written task. The sign-off name pickers were --bg on a --border hairline - #f4f4f4 on #e0e0e0, which is precisely the grey-on-grey that F5/A3 is about. They were missed because the review counted inputs inside .field and these two sit outside it, which is why they needed their own rule in the first place. Fixing the token duplication without fixing them would have left the defect on the page while reporting it closed. Disabled fields stay distinguishable: f_items F5 reads them at #f4f4f4 on the same #8d8d8d border, so fill carries locked-vs-editable and the border does not move. BL-002 folded in, as that entry asks. All three outline:none sites in this sheet are gone: .field input/select/textarea:focus had a 3px --primary-light glow .user-pick:focus had the same glow .seq-step input.seq-label:focus had NO replacement at all #edf5ff against a #ffffff field is a 1.05:1 edge - a faint halo on the card and nothing at all on the field. Replaced with the ring console.css:69 and wp-chrome.css:206 already draw, so this is the app's existing idiom rather than a fourth one: 2px of --cds-focus, inset by -2px over the control's own edge. Verified with CDP focus emulation ON. Without it the headless page is not the focused document, :focus never matches, and every reading comes back as the unfocused style - which looks like a pass and is not one. It cost a wrong answer before I noticed, so it is worth saying. .user-pick and .seq-label also live on later wizard steps, which are display:none and cannot take focus, so the probe reveals the steps before measuring: .field input / select / textarea 2px solid #0f62fe offset -2px .user-pick 2px solid #0f62fe offset -2px .seq-label 2px solid #0f62fe offset -2px f_items 5 FIXED / F6 REPRODUCES. browser_check 71/71. Two findings outside this task's files, logged rather than fixed: BL-013, the creator's inputs have NO outline on focus and rely on the same 1.05:1 glow, which is BL-002's defect in the sheet next door and belongs to T7.2; and BL-014, four controls on the launcher and field view fall back to the UA default ring, which is visible but is a fourth idiom - T9.5 with C1. 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> |
|||
| b105135a98 |
T2.3 - B2: a breakpoint plan for the project switcher, not an ellipsis
"Micron EUV Cleanroom Enable 2667008" did not fit. The switcher capped the name
at 240px inside a 280px button, so the real project name was ellipsised to
"Micron EUV Clean..." on the one control whose job is to tell you which job you
are in - which is the failure this item exists to prevent.
The plan, now written into docs/reference/file-map.md so it is not re-litigated:
>= 1024px the full project NAME. Caps raised to 400px / 340px, which is
enough for a real name with no ellipsis.
< 1024px the project NUMBER alone, e.g. 2667008. Dropping the name beats
shortening it: short, stable, unambiguous.
The number is no longer prefixed to the name at wide widths. Real names already
end with their number, so the old format printed it twice - the test project
rendered as "2667008 - Micron EUV Cleanroom Enable 2667008".
The full name stays reachable at every width by three routes, none hover-only,
because the Field View is a touch surface:
- the drawer, which now shows the active project under its head, wrapping onto
as many lines as it needs and never truncated. This is the guaranteed route,
and it subscribes to ProjectData.onActiveChange so it does not go stale when
the launcher switches project without reloading.
- the switcher's title attribute, carrying the full number and name, which
surfaces on keyboard focus as well as hover.
- the switcher popover, which lists every project in full.
Crossing the breakpoint re-labels, so a resized window does not keep whichever
form was chosen at load.
Verified with the real long name at 390, 768, 1024 and 1440: nothing truncated
at any width (scrollWidth vs clientWidth, not by eye), and the drawer carries
the whole name at all four. T1.1 correctness holds - the switcher never reads
"Select a project" while a project is active.
f_items: F1-F5 FIXED, F3 still passing at all four widths with the wider
switcher. browser_check 71/71.
Wave 2 complete: one drawer on six pages, no flat strip, F2 resolved for real,
S4 closed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|||
| 0a080be1f8 |
T2.1 - B1 part 1: the drawer is already one shared component; verified, not rebuilt
No code change. T2.1 asks to lift the drawer out of "three near-copies" into one shared implementation. There are no copies to lift. html/wp-sidenav.js and html/wp-sidenav.css are already a single implementation included by admin, field view and directory. .wp-sidenav, .wp-navscrim and .wp-navbtn are each declared in exactly one file, and no page defines its own drawer. The review's sentence was that the drawer "ships on 3 of 6 pages while a flat strip duplicates it" - the duplication is between the drawer and the flat strip, not among three drawers. The plan read "3 of 6 pages" as "3 copies". It already satisfies every T2.1 done-when, including the one that could have failed: activeProjectId() at wp-sidenav.js:62-68 reads ?project= and falls back to ProjectData.getActiveId(), which is the single source T1.1 established. It also self-mounts into .wp-appbar OR .header and returns early inside an iframe, so it is already built for the pages T2.2 has to put it on. Refactoring a single shared component into a single shared component would be churn with regression risk and nothing gained, so nothing was touched. Recorded as file-map D5 so the next reader does not go looking for the copies either. The real work of this wave is T2.2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| 5f3141e2a3 |
T1.5 - F5 (interim): wizard fields stop looking disabled
INTERIM. T3.4 removes the duplicate token underneath this; the job here is only the appearance, and no token consolidation is started. The wizard filled its inputs with var(--bg) - which in this sheet is the PAGE BACKGROUND, #f4f4f4 - on a #e0e0e0 border. An empty required field was indistinguishable from a locked one, which is why people were not typing in them. The cause is the one the review named: this sheet redeclares its own tokens, so it never saw --cds-field: #ffffff, even though theme-light.css has been supplying that to this page all along. Fields now consume --cds-field, and take the same --border-strong the creator's inputs already use, so a field looks like a field on both pages. No new value is introduced - both tokens already existed. That inverts a signal if left there, so it needed the other half: there was no disabled rule at all on this page, meaning locked fields would have turned white too. Disabled and readonly fields now take --cds-field-02, the theme's own secondary field surface, matching .locked-field in the creator. Enabled #ffffff against disabled #f4f4f4, verified by computed style rather than by eye. The border is deliberately the same on both states. I first wrote `border-color: var(--border)` on the disabled rule and could not demonstrate it taking effect - the rule matches, is more specific than the base rule, and its background applies, but the computed border stayed --border-strong. Rather than ship a declaration whose effect I cannot show, it is gone: a consistent border is what "consistent with inputs elsewhere" asks for, and the fill is what carries the state. Screenshot diff is limited to the wizard, but establishing that took a control run. admin and users appeared to change too, until capturing twice with NO code change showed they differ from themselves - the console pages render live timestamps and are not byte-stable. login, launcher, sop, creator and field are. Recorded in the baseline README so the next task with a "no layout change" done-when does not chase it. The F5 probe now also fails if enabled and disabled fields become identical, which is the way this fix could silently go wrong. f_items: F1-F5 FIXED, F6 untouched as wave 1 requires. browser_check 71/71. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| 4d3258113a |
T1.4 - F4: the comments drawer opens below the header, not under it
Containing block first, as the task asks. The drawer is a body child with no
transformed ancestor, so its containing block was already the viewport - the
positioning context was never wrong. What was wrong was `top: 0` with
`height: 100vh`: the drawer started at the very top of the viewport, and the
creator's .header is sticky with z-index:100 against the drawer's 61. The
header won, so the drawer's own head - its title and its close button - was
roofed over and unreachable. It read as "off-screen" because the part you
needed was covered, not because the box had escaped the viewport.
That is why raising z-index would have been the wrong move: it does not remove
the collision, it just swaps which element is on top, and then the drawer
covers the header instead. The fix is to stop them occupying the same band.
The drawer now starts at var(--rail-top) and is that much shorter. --rail-top
is the header's measured height, set by wp-creation-app.js:1328 and already
used by .wp-nav for exactly this purpose, so "below the header" has one
definition on this page rather than two.
The iframe boundary is NOT implicated. position:fixed inside the embedded
creator resolves against the iframe's own viewport, which is self-consistent,
and the drawer behaves identically framed and unframed. T7.1 can dissolve the
boundary without revisiting this.
The probe was checking one width, one mode, and placement only. It now checks
390 and 1440, standalone and embedded, that the close button is genuinely
hit-testable via elementFromPoint rather than merely present, that the drawer
reopens after closing, and that opening it does not move the page's scroll
position. All pass.
One honest caveat, attributed rather than hidden. At 390px the drawer sits at
the right edge of a 485px layout viewport while the screen is 390px, so 95px of
it is off-screen. That is not the drawer: the creator forces its containing
block to 485px, and while chasing it I found BL-001's root cause -
wp-creation-app.js:1389 injects `body{--nav-w:288px}` with no media query,
which lands after wp-creation-styles.css:815's
`@media (max-width:860px){body{--nav-w:56px}}` and overrides it, so the page
reserves 288px of rail that is not there at any width. Every `right: 0` fixed
element on the page is displaced by it, not only this one.
Left unfixed on purpose - it is the creator's layout, T7.1 rebuilds it, and
CLAUDE.md is explicit about not fixing things noticed in passing. BL-001 now
carries the exact cause and the five rules that consume the token, so T7.1 does
not have to find it again. The probe reports it as an attributed note naming
BL-001, so nobody is sent to the wrong file.
browser_check 71/71. f_items: F1, F2, F3, F4 FIXED.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|||
| 440f3239a4 |
T1.2 - log the two backlog entries the commit message referenced
BL-001 updated: its 1440px half was resolved as a side effect of the F2 fix, not by intent. Left open, scoped to the creator at 390px, so T7.1 still checks it. BL-003 added: user-menu links are 16px tap targets. T1.2 made them reachable; it did not make them comfortable. Deferred to T2.2, which replaces the markup. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| fe8a27e022 |
T0.2 - baseline captured; all six rendering defects confirmed present
Runs the app from a clean database, captures the before images, and records which of F1-F6 actually still reproduce. All six do. Rather than eyeball screenshots, each defect is measured in a browser by tests/f_items.py, which reports REPRODUCES / FIXED / INCONCLUSIVE and never a silent pass. That makes it both the wave 0 record and the wave 1-3 regression check: an item is done when its probe flips to FIXED. F1 hero says "Job A", app bar still says "Select a project", no reload F2 "Sign out" spans x382-432 in a 390px viewport - cut in half, 3 rows F3 chrome paints over the logo by 106x32px; .header-left collapses to 0 F4 comments drawer overlaps the header by 380x91px in the standalone creator F5 5 of 5 ENABLED wizard inputs compute #f4f4f4 on #e0e0e0 F6 11 cards in one 5,017px scroll, 0 tabs (review said ~4,700px; it grew) Three probes needed care to avoid reporting a false pass, and the traps are worth knowing before anyone verifies a fix: F1 disappears if localStorage is primed first, because then both sources of truth agree. The probe clears it and drives the real picker. F3 needs a long project name that is long IN THE DATABASE - any page reached with ?project= re-pulls it and overwrites a locally-faked one. It also cannot be measured by comparing .header-left to the chrome: under the long name .header-left (flex:1, min-width:0) collapses to clientWidth 0, so that comparison reports a tidy zero gap while the chrome paints across the logo. It measures against .logo, which is flex-shrink:0. My first two attempts at this probe both reported FIXED for those reasons; the screenshot did not. F5 must ignore genuinely disabled inputs or a fix looks done while real fields stay grey. 14 screenshots, not the 12 the plan asks for, because there are 7 pages (file-map D1). Capture also measures horizontal overflow, which is how BL-001 was found. Tooling: cdp.py gains viewport() and screenshot() - it could do neither, and T0.2 requires 390px and 1440px images. 390px sets the mobile flag rather than just narrowing the window, since every page declares width=device-width and Chrome otherwise lays out at 980px and no media query under test fires. Both new scripts reuse browser_check.py's seed() and start_server() instead of growing a second fixture. Existing browser_check still passes 71/71. No application code changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| c2e35b9261 |
T0.1 - build the file map and verify the plan's line references
Wave 0 exists because the plan's line numbers came from a review of users/directory-super-user rather than a fresh read. This is the fresh read: 7 pages, 6 stylesheets, 11,867 lines, with each page's stylesheets, scripts and iframe role recorded, and all seven baseline counts captured with the command that produced them. Four discrepancies, one of which matters a great deal: D2 - CLAUDE.md's "logged-override path for predecessors stays (A1). See wp-creation-app.js:1962-1972" cites the wrong function. That range is dashIssue(), which REFUSES to issue and says "open the package to release it early with a logged reason". The reviewer read that sentence and correctly inferred an override exists, but cited the mention rather than the code. The audited path is confirmEarlyRelease() at 967-984 plus seven satellites (state at 392, call sites at 998 and 1149, persisted at 1117, rendered at 1215, rehydrated at 1674, reset at 481/488/1744). A T7.3 that preserved only 1962-1972 would delete the business rule while believing it had protected it. D1 - "6 pages, 4 stylesheets" is 7 and 6; wave-0's own parenthetical lists seven names. Every "all 6 pages" done-when is off by one. D3 - four documents the plan reads from are deliverables not yet written. D4 - the creator overflows horizontally at 1440px, which no F item covers. Logged as BL-001 rather than fixed, since T7.1 rebuilds that layout anyway. BL-002 records that outline:none appears three times in the wizard sheet, not once, so T3.4 fixes all three. Counts confirmed against the review: 79 dialogs (43 in the creator), 12 div and 2 span onclick, 15 help-tip badges, 0 aria-live, 0 pushState. The "4 declarations of #0f62fe" needed a definition - there are 31 occurrences and 14 custom-property declarations; the 4 is the number of stylesheets declaring their own accent token, which is the number wave 9 should drive to 1. No application code changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
|||
| 3d99d4b9d0 |
Import the R2 implementation spec into the repo
The plan was delivered as wp-suite-implementation-spec.zip and lived only in Downloads, so every "read CLAUDE.md first" instruction in it pointed at a file the repo did not have. Bring it in unchanged: CLAUDE.md, IMPLEMENTATION.md, and docs/waves/wave-0 through wave-9 plus backlog.md. UX-REVIEW-2026-08-14.md is committed alongside it. It is the review that produced F1-F6, S1-S13 and the A/B/C assessments, and item IDs throughout the wave files cite it, so it belongs under version control rather than sitting untracked in the working tree. No application code changes here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
