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.

View File

@@ -339,15 +339,16 @@ body.embed-full { overflow: hidden; }
color: var(--text);
}
/* INTERIM (F5/A3). T3.4 removes the duplicate token underneath this; the fix here
is only to stop editable fields looking disabled.
These were filled with var(--bg) — this sheet's PAGE BACKGROUND, #f4f4f4 — on a
#e0e0e0 border, so an empty required field was indistinguishable from a locked
one and users did not type in them. The wizard redeclares its own tokens and so
never saw --cds-field: #ffffff, which theme-light.css has been supplying to this
page all along. Consume that instead of the local override, and take the same
--border-strong the creator's inputs use, so a field looks like a field in both
places. No new value is introduced here. */
/* An editable field is white on --border-strong, which is what an editable field
is on every other page in the suite. It used to be filled with var(--bg) — this
sheet's PAGE BACKGROUND, #f4f4f4 — so an empty required field was indistinguishable
from a locked one and people did not type in them (F5/A3).
The cause was the wizard declaring its own token set and therefore never seeing
--cds-field, which theme-light.css had been supplying to this page all along.
T1.5 reached past the local tokens with a fallback; T3.2 removed the local tokens
entirely, so the fallback is now dead code and the canonical token is simply
consumed. No field-specific colour is declared on this page. */
.field input,
.field select,
.field textarea {
@@ -357,33 +358,46 @@ body.embed-full { overflow: hidden; }
font-size: 14px;
font-family: inherit;
color: var(--text);
background: var(--cds-field, var(--bg-card));
background: var(--cds-field);
transition: border-color 0.2s;
}
/* Now that editable fields are white, genuinely locked ones need to say so there
was no disabled rule at all, so they would have gone white too and the signal
would have inverted rather than been fixed. --cds-field-02 is the theme's own
secondary field surface, and matches .locked-field in the creator.
The border is deliberately left alone: the same --border-strong on both states
is what makes a field read as a field, and the fill is what carries locked vs
/* Editable fields being white means genuinely locked ones have to say so, or the
signal inverts rather than being fixed. --cds-field-02 is the theme's own
secondary field surface and matches .locked-field in the creator.
The border is deliberately the same on both states: identical --border-strong is
what makes a field read as a field, and the fill is what carries locked versus
editable. Verified as #ffffff vs #f4f4f4 against an identical border. */
.field input:disabled,
.field select:disabled,
.field textarea:disabled,
.field input[readonly],
.field textarea[readonly] {
background: var(--cds-field-02, var(--bg));
background: var(--cds-field-02);
color: var(--text-light);
cursor: not-allowed;
}
/* One focus ring for every control on this page (BL-002).
All three focus rules here removed the outline. Two replaced it with a 3px
var(--primary-light) glow — #edf5ff against a #ffffff field, which is a 1.05:1
edge: a faint halo on the card, invisible on the field itself. The third,
.seq-step input.seq-label, removed the outline with no replacement at all.
CLAUDE.md allows outline:none only with a replacement of at least equal
visibility, so two were marginal and one was a straight violation.
This is Carbon's ring and the one console.css:69 and wp-chrome.css:206 already
draw — 2px of --cds-focus inset over the control's own edge — so it is the app's
existing idiom rather than a fourth. border-color stays as a second cue and as
the fallback if outline is ever suppressed. */
.field input:focus,
.field select:focus,
.field textarea:focus {
outline: none;
.field textarea:focus,
.user-pick:focus,
.seq-step input.seq-label:focus {
outline: 2px solid var(--cds-focus);
outline-offset: -2px;
border-color: var(--primary);
box-shadow: 0 0 0 3px var(--primary-light);
}
/* Helper text under a field, by either of the two names the markup uses: <small>
@@ -404,12 +418,16 @@ body.embed-full { overflow: hidden; }
}
.field-hint strong { color: var(--text-light); }
/* The sign-off name pickers sit outside .field, so they got no form styling at all. */
/* The sign-off name pickers sit outside .field, so they got no form styling at all.
They carried the F5/A3 defect too, and were missed because the review counted
inputs inside .field: --bg fill on a --border hairline is the grey-on-grey that
made empty required fields read as locked. These are enabled selects and now look
like every other enabled control in the suite — --cds-field on --border-strong.
Focus is the shared ring above. */
.user-pick {
padding: 0.75rem; border: 1px solid var(--border); border-radius: 0;
font-size: 14px; font-family: inherit; color: var(--text); background: var(--bg);
padding: 0.75rem; border: 1px solid var(--border-strong); border-radius: 0;
font-size: 14px; font-family: inherit; color: var(--text); background: var(--cds-field);
}
.user-pick:focus { outline: none; border-color: var(--primary); box-shadow: 0 0 0 3px var(--primary-light); }
/* ROLES */
.required-roles {
@@ -563,7 +581,9 @@ body.embed-full { overflow: hidden; }
.seq-step input.seq-label {
border: 1px solid transparent; background: transparent; font-size: 14px; padding: 5px 8px; color: var(--text); flex: 1; border-radius: 4px;
}
.seq-step input.seq-label:focus { background: var(--bg); border-color: var(--primary); outline: none; }
/* Fill only — the ring itself is the shared rule above, which this used to opt out
of entirely with a bare `outline: none`. */
.seq-step input.seq-label:focus { background: var(--bg); }
.seq-del {
background: var(--danger); color: var(--cds-text-on-color); border: none; border-radius: 4px;
width: 28px; height: 28px; cursor: pointer; font-weight: 600; flex-shrink: 0;