Finding
Hermes-facing dashboards and public pages lose trust when visual polish depends on ad-hoc screenshot iteration instead of a repeatable frontend review loop.
Current
A real Hermes installation may have useful public dashboards, achievement pages, status views, or internal operator screens, but visual quality often improves only when someone notices a rough layout during manual use. The weak point is the lack of an explicit UI polish habit: screenshots, CSS/SVG changes, accessibility checks, and mobile layout review are not treated as part of operational maturity. That can leave otherwise strong automation looking unfinished, inconsistent, or hard to read.
Suggested
- Add screenshot-based UI review for public Hermes pages. Exact change: add a “Pixel Goblin review” section to the public dashboard runbook requiring one desktop and one mobile screenshot before publishing achievement pages, dashboard copy, SVG diagrams, or major CSS changes.
- Create a small visual QA checklist for Hermes Agent Info. Exact change: add
docs/runbooks/public-ui-polish.mdwith checks for heading hierarchy, spacing, contrast, responsive layout, broken icons, long text wrapping, and whether sensitive internal details are absent from screenshots and page copy. - Add a polish gate to the achievement publishing workflow. Exact change: patch the achievement content skill or publishing prompt with: “Before marking a page ready, verify that the rendered page matches the markdown intent, uses consistent section spacing, and has no overflow, clipped text, unreadable SVG labels, or private operational details.”
Impact
This makes public Hermes surfaces feel deliberate rather than improvised. Screenshot-driven iteration catches issues that text review misses, especially spacing, hierarchy, dark-mode contrast, mobile overflow, and SVG readability. Better visual consistency also improves operational credibility: public dashboards become easier to trust, easier to share, and safer to maintain without exposing internal implementation details.
Effort
Small — the work is mainly adding one UI review runbook, one publishing checklist item, and a screenshot habit before release. No new frontend system is required unless repeated visual defects show that the current styling layer is too brittle.
Public page note
Safe public content includes the maturity principle, generic UI polish checklist, screenshot-review habit, CSS/SVG quality guidance, and the benefit of readable public dashboards. Internal-only content includes unreleased screenshots with private data, raw dashboard payloads, session excerpts, logs, credentials, environment values, private routes, internal file paths, and live operational controls.