hermes - 💡(How to fix) Fix cron: make recurring job delivery explicit and safe-by-default [1 participants]

Problem

Cron jobs are too easy to configure with a delivery target that is operationally unsafe or unclear, especially when created from a CLI/TUI session.

A user setting up a daily unattended job reasonably expects:

• the job to run without keeping the current CLI/TUI session open;
• the report to go to a durable, explicit destination (Discord/Telegram/home channel/local log);
• the UI/CLI to warn if the selected delivery target is session-bound or may disappear;
• missed/undelivered reports to be discoverable without knowing internal output paths.

Today, deliver=origin can appear convenient during creation, but for recurring jobs it is ambiguous and brittle. If the origin is a CLI/TUI session, the user may incorrectly think a future cron report will appear in “the current conversation,” even though that session may be closed or superseded. This makes cron reporting feel under-specified for real daily/weekly operations.

Related issue: #22795 covers fallback when origin=cli is dead. This issue is broader: cron delivery should be safe-by-default and explicit for recurring jobs.

Expected behavior

For recurring cron jobs, Hermes should guide the user toward a durable delivery target and make reporting semantics obvious.

Suggested behavior:

1. During cron creation/update, if deliver=origin is selected for a recurring job from CLI/TUI, show a warning such as:

   This recurring job's report target is the current CLI/TUI origin. If that session is closed, reports may not be visible. Choose a durable target such as a home channel, explicit Discord/Telegram chat, or local-only logging.

2. Provide a safe default hierarchy:

   • explicit deliver target, if set;
   • platform home channel, if configured;
   • local output with a clear pointer to the output path;
   • never silently imply that a closed CLI session will receive the report.

3. Add a hermes cron test-delivery <job_id> or similar command/tool action that sends a tiny test report to the configured target and confirms where it landed.

4. Improve hermes cron list/status to surface delivery risk:

   Example:

   deliver: origin (created from cli)  WARNING: recurring job; CLI origin may not be alive
   fallback: discord home channel configured / none configured
   last_delivery: success/failure + target + timestamp
   output_path: ~/.hermes/cron/output/<job_id>/...

5. Consider requiring explicit delivery for recurring jobs unless a home channel exists. One-shot jobs can continue to default to origin.

Why this matters

Cron is mainly valuable for unattended, long-running operations. A reporting mechanism that depends on the creation session being alive is surprising and undermines trust. The user should not have to understand Hermes internals (gateway ticker, profile-scoped cron stores, origin delivery semantics, local output paths) to know where tomorrow's report will go.

Desired UX summary

• One-shot job: origin is acceptable.
• Recurring job: prefer explicit durable target or configured home channel.
• If no durable target exists: default to local-only and tell the user exactly where reports are stored.
• Always make delivery target and fallback visible in cron list/status.