n.siegfried
5f3141e2a3
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>
98 lines
5.2 KiB
Markdown
98 lines
5.2 KiB
Markdown
# 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:
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
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 `localStorage` is *not* primed first. Setting both
|
||
`wp_active_project` and `wp_active_project_obj` before 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 in `localStorage`. The probe seeds
|
||
`Micron EUV Cleanroom Enable 2667008` as a real project.
|
||
- **F3** cannot be measured by comparing `.header-left` to 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 is `flex-shrink:0` and therefore the one box in the bar whose position means
|
||
something. A fix that leaves `.header-left` collapsed 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.
|