3.1.1: a sort marker you can read, and guards that actually guard

[Fivell]

A review of 3.1.0 turned up that several of the checks shipped alongside it were quiet rather than wrong, and that one visual change lost information. Six fixes, each reproduced before and after.

Unsorted and descending looked the same

ActiveAdmin's sprite carries three glyphs — a double arrow for sortable-but-unsorted, up for ascending, down for descending. The replacement in 3.1.0 drew the same down triangle for unsorted and descending, separated only by 0.6 against 1.0 opacity on an 8×4 shape. On a freshly loaded index every heading pointed down.

Three shapes again, drawn as masks in currentColor like the theme switch icons, so they still follow the heading colour into dark mode.

	3.1.0	3.1.1
unsorted	▾ at 0.6	⇕ at 0.6
ascending	▴	▴
descending	▾	▾

The type guards for the new palette were never tested

Deleting all five $skinStatusTag*Color entries from the colour guard map left rake css green. The single BAD fixture passed because none crashes mix() inside the theme, not because the guard fired — and a rejection reading

argument `$color1` of `mix($color1, $color2, $weight: 50%)` must be a color,
on line 1477 of app/assets/stylesheets/wigu/active_admin_theme.scss

is exactly what the guards exist to replace: it names gem internals, not the variable the host set.

The BAD check now requires the message to name that variable, and there is a fixture per variable rather than one standing in for five. With the guards deleted it fails five times over, naming each.

An example that failed the contract beside it

GOOD["status tags recoloured"] paired $skinStatusTagTextColor: #f5f5f5 with the other four fills left at their defaults:

neutral 4.19:1   notice 4.19:1   warn 4.18:1   error 4.17:1

Under the 4.5:1 the contrast guard two screens away enforces. That guard only ever compiles the defaults, so it could not see its own neighbour. The example is now a palette that passes.

Checks that hid each other

The contrast and README checks sat behind if failures.empty?, and the first aborted before the second ran — so a run could report one problem while holding three, and each fix revealed the next. Reproduced with a lightened fill and an unrelated nav rule: only the nav failure printed.

They are collected and reported together now. For the same reason a single translucent fill no longer returns early and hides the other four, and $skinStatusTagTextColor is no longer reported as a tag named label.

Two lists that drift

TAG_COLOURS was five names typed out by hand — the same drift DECLARED_ROWS was deleted for. It is read from the stylesheet now, so a sixth tag colour cannot be silently exempt from the contrast check.

The !default scanner had no comment awareness. A note like // was: $skinStatusTagOkColor: #8daa92!default; above the live declaration failed the build twice over, both messages blaming the live one.

Smaller

• ActiveAdmin's sprite is cleared from every anchor in a sortable heading, not only the one the theme marks. An application's own link in a header kept the PNG and the 13px indent it needs — which is the opposite of what the 3.1.0 comment claimed.
• $skinTableHeaderTextColorDark derives from $skinTextColorDark, matching its light twin and the sentence the README already carried. It was a literal that happens to equal it today, so the asymmetry would have surfaced only once someone overrode the body colour.

Left for a minor

Two findings change how the theme looks and do not belong in a patch:

• the five tag fills are iso-luminant — all five reduce to the same grey, where the palette they replaced spanned a range;
• those fills sit at 2.87:1 against the striped dark-mode row background, down from 3.47–5.58:1, because they were tuned against the label alone.

Both want new …Dark variants or a retune, which is additive. Neither affects the label contrast this release is built on.