n.siegfried
6201fcfb4a
The deliberate mobile pass the original proposal never had. Driven page by page at 390px with mobile emulation (the media queries under test actually fire) by NEW tests/mobile_check.py, 24/24: - no page scrolls sideways - all seven (the creator joined at T9.5 when BL-001 died) - no visible control is clipped past the viewport (the probe learned frame_check's two lessons: an off-canvas drawer is PARKED, not clipped, and a row inside an overflow-x container is scrollable) - tap targets: the shared coarse-pointer block in wp-chrome.css puts every button, input, select, nav link and appbar control at a 44px minimum on phone widths and coarse pointers; checkboxes, radios and help-tip badges get the 24px WCAG floor with spacing doing the rest. Field View - the gloved-hands surface - measures 44px on EVERY control. Inline text links are exempt per WCAG 2.5.8's own exception. Even the deliberately unobtrusive dev toggle grew to the floor: subtle by opacity, not by size. - CR-007 attachments offline at 390px and T8.5 requests at 390px were already pinned by files_check and mreq_check; this pass cites rather than repeats. After-screenshots for all seven pages at 390px are committed in docs/reference/baseline/after-wave9, beside the wave 0 set, captured by the same baseline_shots.py fixture. Verification (each probe run alone): NEW tests/mobile_check.py 24/24. Regressions: form_structure_check 50/51 (BL-022's standing question), files_check 36/36. Items: C2 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Baseline — August 14, 2026
Task: T0.2 · Branch: feat/wp-suite-r2-implementation · commit before wave 1
The before images every later PR compares against, and the record of which rendering defects were confirmed present at the start.
Screenshots
14 images, <page>-<width>.png, at 390px and 1440px. The plan says 12 (6 pages × 2); there are
7 pages, so there are 14 — see file-map.md D1.
| Page | 390px | 1440px |
|---|---|---|
| login | login-390.png |
login-1440.png |
| launcher | launcher-390.png |
launcher-1440.png |
| SOP wizard | sop-390.png |
sop-1440.png |
| creator | creator-390.png |
creator-1440.png |
| admin | admin-390.png |
admin-1440.png |
| field view | field-390.png |
field-1440.png |
| directory/users | users-390.png |
users-1440.png |
Regenerate, or capture the "after" half of a comparison:
python tests/baseline_shots.py # -> here
python tests/baseline_shots.py --out /tmp/after --label after
390px is captured with Chrome's mobile flag set, not as a narrow desktop window. Every page
declares width=device-width, so this is the layout a field tablet actually gets. The script
asserts the width it asked for is the width the page saw.
Two pages are not byte-stable — do not diff them blindly
Found at T1.5. Capturing twice with no code change at all produces different bytes for
admin and users at both widths. login, launcher, sop, creator and field are
stable. The console pages render live timestamps, so a byte comparison of them reports a
change on every run.
A task whose done-when is "no layout change at 1440px" therefore cannot use a byte diff on those two. Run the capture twice before drawing any conclusion, or compare a page that is stable. Four of the "changes" in this document's own history were this, not code.
F1–F6: all six reproduce
Measured in a browser by tests/f_items.py, not read from source. Re-run any time:
python tests/f_items.py # all six
python tests/f_items.py F2 F5 # a subset, after one task
Each probe reports REPRODUCES, FIXED or INCONCLUSIVE — never a silent pass. The same
script is the regression check for waves 1–3: an item is done when its probe flips to FIXED.
| Item | Verdict | Measured | Evidence |
|---|---|---|---|
| F1 | REPRODUCES | Picked "Job A" in the launcher picker: hero became Job A, app bar stayed Select a project, wp_active_project=projA, no reload. |
launcher-1440.png |
| F2 | REPRODUCES | Field view at 390px: Sign out occupies x 382–432 against a 390px viewport — cut in half. Bar is 424px of content in 374px, ~3 rows tall. |
field-390.png, launcher-390.png |
| F3 | REPRODUCES | SOP header with the real long name: injected chrome paints over the logo by 106×32px at 1024px and 41×32px at 1440px; .header-left collapses to clientWidth 0. |
f-evidence/F3-sop-header-*-longname.png |
| F4 | REPRODUCES | Standalone creator: comments drawer overlaps the header by 380×91px once open. | creator-1440.png |
| F5 | REPRODUCES | 5 of 5 enabled wizard inputs compute to rgb(244,244,244) fill with rgb(224,224,224) border — the #f4f4f4/#e0e0e0 the review named. |
sop-1440.png |
| F6 | REPRODUCES | Creator is 11 cards in a single 5,017px scroll, 0 sectioning controls, 3 jump links. Review said ~4,700px; it has grown. | creator-1440.png |
Notes that change how a fix gets verified
- F1 is only visible if
localStorageis not primed first. Setting bothwp_active_projectandwp_active_project_objbefore load makes the two sources agree and hides the defect. The probe clears storage and drives the real picker. - F3 is only visible with a genuinely long project name, and it has to be long in the
database — any page reached with
?project=re-pulls the project from the server and overwrites a name faked inlocalStorage. The probe seedsMicron EUV Cleanroom Enable 2667008as a real project. - F3 cannot be measured by comparing
.header-leftto the chrome. Under the long name.header-left(flex:1; min-width:0) collapses to zero width, so that comparison reports a tidy zero gap while the chrome is painting across the logo. The probe measures against.logo, which isflex-shrink:0and therefore the one box in the bar whose position means something. A fix that leaves.header-leftcollapsed has not fixed F3. - F5 must ignore genuinely disabled inputs, or the fix looks done while real fields stay grey. The probe counts only enabled, visible, non-hidden fields.
Horizontal overflow, measured at capture time
documentElement.scrollWidth against clientWidth. Recorded because four pages overflow at
390px and one also overflows at desk width, which no F item covers.
| Page | 390px viewport | 1440px viewport |
|---|---|---|
| launcher | 425px content | — |
| SOP wizard | 429px content | — |
| creator | 485px content | 1551px content |
| field view | 432px content | — |
| login, admin, users | fits | fits |
The 1440px creator overflow is logged as BL-001. The 390px ones are F2 and its
neighbourhood, resolved properly by B1 in wave 2.