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