Autonomous Cron Job Release Discipline

Scheduled Rocky jobs are useful because they can keep work moving without waiting for a human at the keyboard. They are also risky when they publish, deploy, or notify people automatically. Treat every autonomous cron run as a small release.

Official Hermes Agent docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/cron

Operating model

A scheduled job should do three things well: gather current evidence, make a bounded change, and verify the result before it tells anyone the work is done. If the job cannot safely complete the loop, it should stop and report the blocker instead of inventing progress.

Release checklist

• Confirm the working directory and the exact public surface the job is allowed to edit.
• Inspect current source files before changing them.
• Avoid recursive scheduler changes unless the task explicitly asks for scheduler maintenance.
• Keep public/private boundaries clear: public pages should not pull private datastore files or internal project details.
• Generate or modify only the allowed artifacts.
• Run syntax, route, search, and visual checks before deploy.
• Deploy only after checks pass.
• Verify the live mapped domain and at least one new or changed URL.
• Report commands, revision IDs, generated assets, and blockers plainly.

Safe default behavior

When a cron job lacks clarification, use the most conservative reasonable interpretation. For a public wiki expansion, that means adding fewer high-quality pages instead of many weak stubs, avoiding private examples, and skipping deployment if validation fails.

Common pitfalls

• Publishing filler because the job has a quota-like prompt.
• Treating a build success as equivalent to live verification.
• Forgetting that generated images can contain unwanted readable text.
• Creating temporary artifacts inside the deploy context and shipping them accidentally.
• Reporting a notification or deployment as complete before checking the live route.

Verification steps

• Run the relevant parser or syntax checker.
• Start a local server and check the changed route.
• Search for the new content through the public search UI or search index.
• Capture desktop and mobile screenshots when the page is visual.
• After deploy, fetch the live canonical URL and sitemap entry.