Know whether an automation actually worked

1. Separate the evidence you need

The exercise checks the command attempt, actual JSON output, durable execution history and local destination separately. The input contains one synthetic record and a fixed source-window date. The script validates that a nonempty record list exists before writing a candidate and replacing last-good.json.

The script reports generation time separately from the source window. Its output states that delivery is local artifact only. This is deliberately narrower than a successful email or chat notification: no outside destination was tested, and a newly generated file does not make its source material current.

2. Isolate the job from existing schedules

The test used a new HERMES_HOME inside the test folder, a minimal nonsecret configuration, and a script under that home's scripts directory. No credentials were copied and existing schedules were left alone. The initial launcher attempted dependency preparation for the new root; the successful test instead used the existing installed Python environment and the Hermes CLI module directly.

Create an equivalent test job with --script check_fixture.py, --no-agent and --deliver local. The test job was created paused, explicitly resumed for the manual dispatch, and paused again afterward. A 24-hour schedule was stored but no repeating gateway or background service was started.

3. Observe what exit code zero failed to prove

An initial cron run against a paused job returned exit code zero while saying the job was paused or disabled. No artifact existed. After explicitly resuming only this test job, a manual run created the expected artifact and a completed durable execution. This difference is visible in the recorded commands and outputs.

Next, the source was changed to an empty record list. The script exited with code 3 and reported SOURCE_INCOMPLETE. On this installed build, the outer Hermes command still returned zero; durable job state showed error and run history showed a failed execution. The site therefore treats CLI exit status as one observation, never the sole verdict.

4. Verify preservation and shut down the trial

The last-good artifact contained exactly one synthetic record and the expected source-window date. After the incomplete-input attempt, its SHA-256 hash was unchanged. Run history retained both the completed and failed attempts. The test job ended paused, and the separate earlier trial job also remained paused.

The manual-dispatch phase established script execution, local output inspection, visible failure and last-good preservation. The later timed phase below adds evidence for due-time recurrence. Host wake behavior, model-backed scheduled reasoning and messaging delivery remain untested.

5. Observe real due-time recurrence

A separate test created an every-1-minute job in a new isolated data home. A bounded host loop called the real Hermes cron tick automatically, approximately every two seconds, and let Hermes decide when the stored job was due. The test never called cron run and never edited a next-run timestamp. It used the existing dependency environment and installed no gateway or OS service.

The first scheduled run was due at 20:22:26 Pacific on October 19 and recorded at 20:22:28. The second was due at 20:23:28 and recorded at 20:23:30. Both produced the expected local artifact; the job advanced its next due time. Exact offset-aware timestamps are in timed-receipt.json. These are observations on an awake local host, not a promise of second-level precision.

After the second success, the test changed the input to an empty record list. The third scheduled run was due at 20:24:30 and recorded an error at 20:24:31. The last-good output hash stayed identical, durable history retained the failure, and the test job ended paused. timed-commands.json preserves the commands and responses, while timed-observations.json separates due times, recorded attempts and outcomes.

This closes the specific gap between manual dispatch and waiting for stored due times. It still does not test model-backed scheduled reasoning, external messaging, sleep/wake recovery, a service restart or a production gateway running for days. The bounded test loop has stopped; no ongoing monitoring was installed.

How to adapt it

Keep deterministic collection and validation in a small script where practical. Validate required fields before promotion; retain a dated last-good artifact alongside a separate attempt record so failures remain visible. If the operation has external effects, reconcile partial work before retrying it.

Before trusting an unattended deployment, observe a genuine timed run on its intended host and check the destination independently. Do not use the fixture's local success as proof that a production timer or external notification works. Retain script errors and durable run records so the next operator can determine what actually happened.

Inspect and reproduce

The source fixtures, original model outputs, prompts and execution receipts are below. Use a separate folder and your existing Hermes setup. Replace <trial-folder> in prompts with that folder. A local test run is not evidence of unattended production reliability.

{
  "generatedAt": "2026-10-19T13:21:59.283994+00:00",
  "sourceWindowEnd": "2026-10-19T00:00:00Z",
  "count": 1,
  "records": [
    {
      "id": "sample-1",
      "source": "synthetic fixture"
    }
  ],
  "delivery": "local artifact only"
}