One /status, assembled once, rendered per front end
@NotRetarded put Discord's and Telegram's /status side by side: Discord was missing Docksentry itself, missing health, missing uptime, and showed :latest where a version would mean something.
The diagnosis worth shipping came from the discussion that followed: the assumption that a reply is generated once and then simply sent per connection. That has been true for notifications since the announce() seam — and it was false for command replies, where each front end kept its own assembly. Two assemblies is drift, by construction, and no amount of catching up fixes it permanently.
So the detail view is now one collector and one renderer, and the only thing a front end may choose is its bold marker. Verified live against a running container: both outputs are byte-identical once markdown is stripped.
What the detail shows — the questions you actually have when a container misbehaves at 2 am:
- state, health and uptime
- the exit code when it is not running (the field #62 was diagnosed from)
- live CPU and memory
- what the health probe said when unhealthy — the v2.15.0 lesson: the probe's words, not the container's
- image, version label, image ID
- ports, volumes, restart policy
- and Docksentry's own knowledge: pinned, auto-update, protected, trust-running, ask-major, group, note, pending update
Docksentry sees itself again
Discord's /status listed everything except the container answering the question. The self-filter exists for the update path, where it protects PID 1 — the status listing had borrowed it wholesale. Readers now ask for the whole truth; the update path keeps its guard.
And the overview grew up
Both front ends' overview lines lead with a health icon, name the version when the image carries one — ollama/ollama:latest (v0.32.14) instead of just the tag — and show uptime. Built by the same line builder, so they cannot disagree.
