Files

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

2026-08-14 18:40:28 -05:00

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

6.5 KiB Raw Blame History Unescape Escape