T3.4 - A3/F5 full, BL-002: the wizard's fields look editable and focus is visible

T1.5 stopped editable fields looking disabled by reaching past the wizard's own
token block with a fallback: background: var(--cds-field, var(--bg-card)). T3.2
deleted the local tokens, so the fallback is now dead code and the canonical
token is simply consumed. The interim comment is gone; grep for INTERIM in the
sheet returns nothing, and the sheet declares no field-specific colour.

Measured in the browser rather than asserted - every enabled text control in the
suite, side by side:

  sop .field input        #ffffff on #8d8d8d 1px
  sop .user-pick          #ffffff on #8d8d8d 1px
  creator .field input    #ffffff on #8d8d8d 1px
  console .toolbar input  #ffffff on #8d8d8d 1px
  launcher .proj-row      #ffffff on #8d8d8d 1px

.user-pick was not identical before this commit, and that is the one thing here
beyond the written task. The sign-off name pickers were --bg on a --border
hairline - #f4f4f4 on #e0e0e0, which is precisely the grey-on-grey that F5/A3 is
about. They were missed because the review counted inputs inside .field and these
two sit outside it, which is why they needed their own rule in the first place.
Fixing the token duplication without fixing them would have left the defect on
the page while reporting it closed.

Disabled fields stay distinguishable: f_items F5 reads them at #f4f4f4 on the
same #8d8d8d border, so fill carries locked-vs-editable and the border does not
move.

BL-002 folded in, as that entry asks. All three outline:none sites in this sheet
are gone:

  .field input/select/textarea:focus  had a 3px --primary-light glow
  .user-pick:focus                    had the same glow
  .seq-step input.seq-label:focus     had NO replacement at all

#edf5ff against a #ffffff field is a 1.05:1 edge - a faint halo on the card and
nothing at all on the field. Replaced with the ring console.css:69 and
wp-chrome.css:206 already draw, so this is the app's existing idiom rather than a
fourth one: 2px of --cds-focus, inset by -2px over the control's own edge.

Verified with CDP focus emulation ON. Without it the headless page is not the
focused document, :focus never matches, and every reading comes back as the
unfocused style - which looks like a pass and is not one. It cost a wrong answer
before I noticed, so it is worth saying. .user-pick and .seq-label also live on
later wizard steps, which are display:none and cannot take focus, so the probe
reveals the steps before measuring:

  .field input / select / textarea    2px solid #0f62fe  offset -2px
  .user-pick                          2px solid #0f62fe  offset -2px
  .seq-label                          2px solid #0f62fe  offset -2px

f_items 5 FIXED / F6 REPRODUCES. browser_check 71/71.

Two findings outside this task's files, logged rather than fixed: BL-013, the
creator's inputs have NO outline on focus and rely on the same 1.05:1 glow, which
is BL-002's defect in the sheet next door and belongs to T7.2; and BL-014, four
controls on the launcher and field view fall back to the UA default ring, which
is visible but is a fourth idiom - T9.5 with C1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-15 19:00:59 -05:00
parent 2485ca7b61
commit 03d24138ed
2 changed files with 74 additions and 25 deletions

View File

@@ -236,3 +236,32 @@ deliberately deferred.
covers what the diff was being asked to prove, and covers it better.
- **Suggested wave or follow-up:** wave 9, alongside `C2`. Either freeze the clock in the
fixture or exclude the live regions from capture — otherwise every later wave re-learns this.
### BL-013 — The creator's inputs have no visible focus ring at all
- **Found during:** T3.4
- **Where:** `html/wp-creation-styles.css:168` (`outline: none` on every input, textarea and
select) and `:171` (`:focus` replaces it with `box-shadow: 0 0 0 3px var(--accent-dim)`)
- **What:** the same defect `BL-002` recorded in the wizard sheet, in the sheet next door.
Measured in the browser with focus emulation on: a focused creator input reports
`outline-style: none`, and its only focus cue is a 3px `#edf5ff` glow against a `#ffffff`
field — a 1.05:1 edge. `.wp-nav-search:focus` (`:765`) is the same. That is `CLAUDE.md`'s
"outline: none without a replacement of at least equal visibility", on the page with the
most form controls in the app.
- **Why not now:** `T3.4`'s files are the SOP wizard stylesheet, and `BL-002` scoped the
three sites it folded in to that sheet. The creator is rebuilt at `T7.1`/`T7.2`.
- **Suggested wave or follow-up:** `T7.2`, or `T9.5` with the `C1` audit if it survives the
rebuild. The fix is the ring `T3.4` established: `outline: 2px solid var(--cds-focus);
outline-offset: -2px`, which `console.css`, `wp-chrome.css` and now the wizard all use.
### BL-014 — Four controls fall back to the browser's default focus ring
- **Found during:** T3.4
- **Where:** `html/index.html` `.proj-row select`, `.proj-form-grid input`, `.link-like`;
`html/field.html` `.fld-search`
- **What:** these have no focus rule, so they get the UA default (`1px auto #111`). Visible,
so not a `C1` violation — but it is a fourth focus idiom beside the app's 2px `--cds-focus`
inset ring, and it does not follow the accent if the accent ever changes.
- **Why not now:** adding rings to the launcher and field view is outside `T3.4`, whose files
are the wizard stylesheet, and both surfaces are touched by later waves anyway.
- **Suggested wave or follow-up:** `T9.5`, with the `C1` audit.