Five reports from the running GUI: a lost control, a colour, a dialog and a name

[donislawdev]

Five things reported from the running GUI. Two of them turned out to be one
change, one turned out to be a functional loss rather than a cosmetic fault,
and one turned out to be two different claims sharing a name.

Gates 12/12. Rust 432 to 435, C# 373 to 386, harness 146 PASS / 0 FAIL. Every
slice was verified on a live window by UIA rectangle and by pixel, and every
guard added here had its revert probe seen red.

The step row could add a step it could not remove

Reported as a clipped dropdown. Measured on the default 1040 window: the row
wanted 439 logical px where the column had 331, so the unit list ended mid
word and the remove button was laid out 108 px beyond the column, underneath
the opaque result panel. That button is the only control that takes a step
off, and it was never painted. At these column proportions the row first fits
in a window about 1400 logical px wide, which is neither the default nor
anything the window's own minimum allows.

A grid alone does not fix it: after the kind picker and the remove button
there are about 160 px left for an editor that needs 277. The kind picker now
heads the step and the editor sits under it, spanning the card, with a wrap
panel underneath as the floor for a longer label in another language.
Measured after, with the longest unit label selected: nothing crosses the
column boundary at the default size or at the window's minimum width.

The primary action lost its colour, and was not the stop control

Two faults on one button, and one template fixes both.

It carried its accent as a local Background, and the stock template repaints
a NAMED PART of itself on hover. A template part is not the control, so the
local value never competed with it, and the one findable control on the
screen dropped to grey the moment the pointer arrived. It now has its own
template, which paints state as a veil over whatever fill the usage sets.
That is what lets one template serve both an accent Start and a red Stop
without a palette entry that exists only to be a shade of another one.
Measured by pixel on a live window: at rest #4CC2FF, which is the accent
token itself, and on hover #63C9FE, so luminance rises by 9.8 instead of
falling.

Stop used to sit at the bottom of the in-flight block, under the speed and
jump rows, so the control that ENDS what the panel is doing was the last
thing on it. It is now the same button, told apart by the label AND by the
fill turning to the failure red, never by colour alone. Content, tooltip and
enabled state moved into the style, because a local value outranks a trigger
and the running state would otherwise never have shown. The guard is on that
trap rather than on the appearance.

The app answered in a language it does not speak

The confirm box in front of clearing the history was a native MessageBox, and
being a light-grey window on a dark app was the smaller of its two faults.
WINDOWS labels those buttons, in the system language, so an English interface
answered in Polish and no translation key of ours was involved at all.

One window, two shapes. A question offers a named affirmative beside a
cancel, and anything other than the affirmative is a no. A notice has one way
out. Focus starts on the answer that changes nothing. The destructive answer
wears the same failure red as the session Stop control.

Sized by measurement rather than by eye: sizing to content stopped 60 px
short of fitting, and removing the extended title bar changed nothing, which
ruled the frame out, while adding 300 px to the message grew the window by
only 200, which showed a minimum height carried by the window type itself.

The three dialogs in App.xaml.cs stay native, and the comment there says why:
each reports that the strings, the startup path or the dispatcher has failed,
which is to say the very things a themed window needs in order to draw. A
guard keeps that boundary, with a canary on the count.

Two different claims stopped sharing one name

The block under a result was headed "what this date tests", and so is the line
a preset author writes about their own scenario. Both appeared in one output,
saying different things.

The age-of-majority preset showed it plainly. On one birth date it computes
the day before an eighteenth birthday, which happened to be a Sunday, so
under a heading claiming to say what the date tests it answered "weekend -
not a business day", two lines under an explains line that said the date
tests an age boundary. Both were true. Only one was what the tester came for.

The computed block is now "what this date lands on", which is what it holds.
The preset keeps "what this date tests", because that is what it is. The
block itself is unchanged and still earns its place: for 3 July under the
federal calendar the metadata reads "business day no" and "holiday no", and
only this block explains that pair by naming an observed holiday.

The calendar is now named beside those marks in both surfaces, because
"weekend - not a business day" reads like a fact and is a judgement. It is
stated whether or not any calendar mark fired, since their ABSENCE is the
same file's judgement. The GUI needed the calendar to travel with the result
rather than be read off the picker, so the calc payload gained
metadata.calendar. That closes a gap of its own: the text output has named
the calendar beside its verdict all along and the machine output named it
nowhere. Additive, so no schema version. The site's transcripts were updated
with it, since a transcript that does not match the tool is a lie in a quiet
font.

Not in this branch

The app's window background resolves to the toolkit's own colour rather than
the palette token the views name, and only the calculator view paints the
token, because its own root sets it. So the two modules of one app have
different backgrounds and nobody decided that. Measured by pixel, left alone
here: it is a change to the whole app's appearance rather than one of the
five reports.

🤖 Generated with Claude Code