One of the most useful habits in the current Hermes research pack is the shift from guessing to proving. When something changes, the better question is: what is the smallest check that can prove the expected state is actually true?
Start with the smallest visible checks
hermeshermes modelhermes sessions list
Inspect config when behavior drifts
Use ~/.hermes/config.yaml as a real state surface when behavior changes after restart, resume, or provider switch.
Check logs and runtime traces before you guess
When visible state is not enough, move one layer deeper and inspect logs, command output, and runtime traces before you jump to rebuild logic. Observability is not only about the final response in chat. It also includes whether the CLI reported the right model, whether session listings changed as expected, whether a restart actually cleared the symptom, and whether the active lane produced a concrete error instead of just going quiet.
- capture the exact command output when a check fails
- compare before/after state instead of relying on memory
- treat a silent or missing log line as useful evidence, not just a nuisance
Validate security posture, not just output
- approvals are
manual,smart, oroff - YOLO was enabled intentionally or accidentally
- backend/container settings still match the rollout plan
Use a narrow escalation order
- inspect first
- prove the expected state
- reconfigure second
- restart third when the failure is transient
- rebuild only after path, config, session, platform, approval, and editor/runtime bridge lanes were checked