Local-First Troubleshooting Packet

Before Rocky changes a live system, it should understand the failure. A local-first troubleshooting packet turns a vague issue into evidence that can be fixed and verified.

Official Hermes Agent docs: https://hermes-agent.nousresearch.com/docs

Packet contents

• The exact route, command, or workflow that fails.
• Expected behavior and observed behavior in plain language.
• Relevant source files, configuration keys, and public/private boundary notes.
• Log excerpts with secrets removed.
• Screenshots or contact sheets when the issue is visual.
• A rollback or no-deploy decision if checks fail.

Debugging flow

• Reproduce the problem as narrowly as possible.
• Inspect the source-of-truth file or live endpoint.
• Form one hypothesis and test it.
• Patch the smallest responsible cause.
• Rerun the original failure path and then broader checks.

Pitfalls

• Fixing from memory without reproducing the issue.
• Overwriting large files when a targeted patch is safer.
• Reporting a blocker as success because the desired output is easy to imagine.
• Skipping delayed logs for serverless flows that may fail after the HTTP response.

Verification steps

• Save the exact command output or URL status.
• Run local checks before deploy when possible.
• Verify the live mapped domain after deployment.
• Summarize what changed, what was tested, and what remains unknown.