Finding
Visual proof is weak when Hermes reports that a dashboard, UI, or public page “works” without capturing and reviewing evidence of what a user would actually see.
Current
A typical Hermes installation can inspect files, run tests, search pages, and use browser tooling, but UI verification often stops at text output, successful commands, or route availability. That leaves a gap for layout regressions, broken styling, missing content, incorrect navigation, hidden error states, or changes that pass backend checks while still looking wrong in the browser. Screenshot Hunter turns visual QA into an operational habit instead of an occasional afterthought.
Suggested
- Add a screenshot requirement for UI-facing changes. Exact change: add a “Visual QA required” rule to
docs/runbooks/browser-qa.mdor the UI deployment runbook stating that dashboard, public page, achievement page, and browser-visible changes require at least one screenshot or browser observation before the task is called complete. - Define what the screenshot must prove. Exact change: patch the relevant Hermes Agent Info or dashboard QA prompt with: “For each UI change, verify the target route loads, the expected heading/content is visible, navigation still works, no obvious visual error is present, and the screenshot matches the intended change.”
- Store visual evidence safely and summarize it publicly. Exact change: add a completion checklist item to the task verification habit: “Reference only the public-safe screenshot conclusion in site content or reports; keep raw screenshots internal when they contain private dashboards, user data, authenticated UI, tokens, internal URLs, or operational controls.”
Impact
This makes UI work evidence-based instead of assertion-based. It catches the class of failures that command-line checks miss: broken layouts, incomplete rendering, stale public pages, and visual regressions after dashboard or content changes. It also improves confidence in Hermes Agent Info pages because recommendations can be backed by visible proof without exposing sensitive screenshots.
Effort
Small — the change is mainly a QA rule, a screenshot checklist, and a safe evidence-handling habit. No new architecture is required unless the installation lacks working browser or screenshot tooling.
Public page note
Safe public content includes the achievement meaning, the visual QA principle, generic screenshot checklist language, and the operational benefit of proving UI behavior. Internal-only content includes raw screenshots of private dashboards, authenticated pages, customer data, credentials, tokens, internal URLs, browser logs, filesystem paths, and any visual evidence that exposes live operational controls.