fix(web): profit and loss were the same brightness, and inputs had no visible border

[eaitbrahim]

Closes #532.

The finding

--good and --bad were photometrically identical in light mode:

good #1f5f4f  relative luminance 0.0904
bad  #96322a  relative luminance 0.0893
                        delta 0.0011  →  1.01:1

Profit and loss were separated by hue alone — render.py:82 carried nothing else. That fails WCAG 1.4.1 Use of Color in an application whose central signal is gain versus loss. Roughly one in twelve men has red-green colour deficiency; greyscale, e-ink and direct sunlight collapse the distinction for everyone else.

--accent was also byte-identical to --good in both themes, so a link and a gain rendered alike.

The rule this change encodes

Move the colour that has room to move away from the background. Toward the background loses contrast; away gains it. When two colours need luminance separation, moving the one with headroom gains separation and contrast instead of trading one for the other.

• Light background, both colours dark → darken bad.
• Dark background, both colours light → lighten good.

A first draft did the opposite in both themes and cost two AAA grades to buy separation. That alternative is now recorded in the source comment as rejected, with the reason.

Result — zero grade drops, four tokens improved

Light

token	before	after
bad	7.22 AAA	13.92 AAA
accent	7.17 AAA	7.70 AAA
good	7.17 AAA	7.17 AAA (unchanged)

Dark

token	before	after
good	8.39 AAA	10.39 AAA
accent on card	7.83 AAA	7.68 AAA
bad	6.24 AA	6.24 AA (unchanged)

good/bad luminance delta: 0.0011 → 0.0681 light, 0.1234 → 0.2382 dark.

fg, muted and warn are untouched on every surface. Every entry that was AAA before is still AAA.

Form inputs

.field input used background: var(--bg) — the page background — so a --line border at 1.27:1 was the only thing marking the control. Fails WCAG 1.4.11 (3:1 for component boundaries).

Raising --line globally was rejected and the rejection is recorded: --line also draws table rules, the footer border and card edges, which 1.4.11 explicitly exempts as decorative. A new --control-line is scoped to interactive boundaries only — 3.72:1 light, 3.54:1 dark. --line is unchanged, and a test pins that it stays unchanged.

Tests

tests/web/test_palette_contrast.py, 8 tests, pure Python, no new dependency — the WCAG formulas are about twenty lines.

Two properties make it a real guard rather than a restatement:

• It regexes the tokens out of render._STYLE rather than holding a copy, so a reverted or fat-fingered value fails for real.
• It pins the grade (AAA/AA), not just the ratio. A ratio floor could not have caught the first draft's mistake: 4.89:1 and 7.17:1 both clear 4.5:1, and only one is AAA.

Confirmed red first: run against the unmodified palette it fails for the right reasons — missing --control-line, accent == good, luminance delta below floor.

Not in this PR

The ▲/▼ glyph and sign that make P&L survive without colour at all. That needs the state field from the API payload and arrives with the client (#533, #536). This PR is the palette and the guard.

Gates

• ruff check keel tests packages — All checks passed
• mypy — no issues in 354 source files
• pytest -q — 4562 passed, 3 skipped

🤖 Generated with Claude Code

https://claude.ai/code/session_01NyeggYtojNXCTHeD3JHxb6

[eaitbrahim]

Review fixes applied

The glyph landed — this is what actually satisfies 1.4.1

New pnl_cell() renders ▲ 120.00 / ▼ -45.00 inside the existing .good/.bad span. Its docstring states the layering well: "a glyph, the signed amount, and a colour class — in that order of how much of the meaning each one carries alone."

It also makes the honest point that money() already printed the sign, so the sign survived colour removal already; the glyph is what stops a skimmed table row from missing it.

With the glyph in, colour is a secondary signal, which is what makes the palette trade below acceptable.

--bad re-picked: #4d1711 → #7b2915

Round 2 fixed the good/bad collision by opening a new one against body text. Recomputed independently:

light --bad	vs --bg	vs --fg	delta from good
original #96322a	7.22 AAA	2.28	0.0011 ← the bug
round 2 #4d1711	13.92 AAA	1.19 ← new collision	0.0681
final #7b2915	9.28 AAA	1.78	0.0319

The delta is smaller than round 2's, and that is forced rather than chosen. Working the constraints: --bad must clear the --fg floor, which puts its luminance at ≥ 0.0537; --good sits at 0.0904 with an AAA ceiling of 0.0938, so almost no headroom to move the other way. The maximum achievable good/bad delta is 0.0367. This pick reaches 0.0319 — 87% of the theoretical best, and 29× the original collision, with no AAA lost anywhere.

New floor, so the collision cannot recur

test_signal_tokens_stay_distinguishable_from_fg pins _MIN_SIGNAL_FG_RATIO = {"light": 1.7, "dark": 1.4} across good/bad/warn in both themes. It rejects round 2's #4d1711 at 1.19:1 and passes the corrected palette.

That closes the failure mode this PR twice walked into: fixing one photometric collision by opening another. The test now knows about both axes.

Comment-stripping

_theme_palette strips /* */ before parsing. The new test builds a stylesheet whose comment is shaped exactly like a real rejected-value note — /* REJECTED: --bad: #000000 ... */ — and asserts the live declaration still wins. Worth having, since this PR's own comments now document rejected hex values in close to that form.

Gates

ruff clean · mypy clean, 354 files · 4564 passed, 3 skipped · test_palette_contrast.py now 11 tests (was 9 — the PR body's "8" was wrong from the start)