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