n.siegfried
4d3258113a
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>
119 lines
6.5 KiB
Markdown
119 lines
6.5 KiB
Markdown
# 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
|
||
|
||
```markdown
|
||
### 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`.
|
||
|
||
### BL-003 — User-menu links are 16px tap targets
|
||
|
||
- **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.
|