Automations: support event-only definitions and idempotent external triggers

[karolzlot]

Problem statement

Happier automations currently require a cron or interval schedule, so an automation cannot be armed solely for an external condition or event.

Examples include a remote machine becoming reachable, a CI job completing, a home-automation event, or a one-off scheduler deciding that a task is ready to run. This affects self-hosted users and integrations where condition evaluation intentionally belongs outside Happier.

Today these users must either configure an artificial schedule or bypass Automations and send a message directly to a session, leaving the trigger definition outside Happier and losing the first-class automation lifecycle: machine assignment, durable AutomationRun state, run history, and occurrence-level idempotency.

Proposed solution

Separate triggering from execution by allowing an automation with no automatic cron or interval schedule, for example through an external or manual trigger kind.

Provide a supported authenticated API and/or CLI operation that creates an immediate AutomationRun for such an automation. The request should accept a caller-provided occurrence ID or idempotency key so that an ambiguous request can be retried safely.

The run should use the existing automation pipeline: assignments, daemon claiming and leases, offline recovery, encrypted templates, existing/new session targets, and run history. The external system would decide whether its condition is true; Happier would only receive the signal that one occurrence is ready.

The existing run-now operation could be extended or a separate trigger operation could be introduced.

Acceptance criteria

• An automation can be represented without a cron or interval schedule.
• An event-only automation does not create scheduled runs by itself.
• A supported authenticated API or CLI operation can create an immediate AutomationRun for it.
• The caller can provide an occurrence ID or idempotency key.
• Retrying the same occurrence does not create another run or duplicate prompt.
• Different occurrence IDs create separate runs.
• The triggered run uses the existing machine assignment and lease mechanism.
• If the assigned daemon is offline, the run remains durable and can execute after it reconnects.
• Triggering a paused or disabled automation has an explicit result and does not execute it.
• The run appears in the existing automation run history.
• Existing E2EE and plaintext storage rules remain unchanged.
• Existing cron and interval automations continue to work unchanged.

Non-goals (optional)

• Building an arbitrary condition engine or trigger-provider plugin system inside Happier.
• Accepting arbitrary event payloads or overriding the stored automation template per occurrence.
• Adding an unauthenticated public webhook endpoint.

Priority (optional)

P3

Additional context (optional)

• Automation creation currently requires a schedule: automationValidation.ts.
• An authenticated immediate-run action already exists: registerAutomationCrudRoutes.ts.