v2.11.0 — a status page that leads with the answer
A second way to draw the status page
The old one was the dense page in the product, and I finally measured it instead of squinting at it. Twenty-five containers produced 236 forms, 380 fields and 289 buttons — about nine forms and eleven buttons per row — and 426 of the page's explanations sat in title tooltips, which a phone cannot show at all.
Then I looked at a screenshot, which settled the rest. Every row carried six identical emoji buttons at the same size and the same weight, so you could not tell the routine one from the one that stops your database. And in a tool whose entire job is telling you when a container needs updating, the row never said whether it needed updating. That fact lived in a counter at the top of the page.
So there is a list layout now, and it leads with the answer: state, name, image, and then either "update available" with the button that applies it, or nothing at all. An up-to-date container is quiet.
Everything else — check, pin, auto-update, restart, logs, stop — moved into a detail panel behind one control per row, with its explanations written on the page rather than hidden in a tooltip. Colour means something again: Stop is the only red thing on the screen. It lays out as two-line cards on a phone, and refreshes itself in place instead of reloading.
Underneath, the page is data rather than markup: the server sends one JSON document, built from the same view the table renders from so the two cannot disagree about what is pinned or pending, and the browser draws it. 27 kB instead of 173 kB at 25 containers. No framework and no build step — this image still has no npm anywhere near it.
Settings › General › Status page. The default is unchanged — table, the layout you already have. An upgrade should not rearrange a page you know how to use. STATUS_VIEW=list seeds it on a fresh install; the setting wins after that.
One note on what this deliberately is not. It started as a whole rebuilt interface behind a hidden switch, for a handful of testers. That was over-scoped, and the same measurements said so: Settings, at four tabs and 45 fields, was the tidiest page there was. One page had the problem, so one page got the fix.
Also
The status JSON now says what the caller is allowed to do, so a read-only API token gets a read-only page — the actions it would be refused are simply not offered. Groundwork more than a feature: the day roles arrive, the server sends a shorter list and the interface needs no change. To be clear about the boundary, hiding a button is not a permission, and every endpoint still enforces its own access.
And the status page no longer changes width when you arrive on it. It has been 1400px wide since #46, because the old seven-column table scrolled sideways on a big monitor. The list has no such problem, and inheriting the exception made the header, the navigation and the content jump between two widths as you moved around. The table keeps its extra width; the list matches every other page.
Nothing to do on upgrade — you keep the status page you have.