Recurring loops expire silently after 7 days — no recreation hook, no alert

[rafafortes]

Summary

Recurring loops (LoopCreate with a cron trigger) expire after seven days unless recreated — documented at docs/REFERENCE.md:50 ("Recurring loops expire after seven days unless recreated; fire limits bound repeated execution"). There is no automatic recreation, no expiry event/notification, and no documented way to detect that a recurring loop has silently stopped firing.

Impact (observed in production)

A daily cron loop (0 8 * * *, maxFires 30) created on 2026-08-28 will silently stop firing around 2026-08-29+7d. The consuming window only notices by checking LoopList every cycle and comparing against the expected set — a manual, error-prone reconciliation. If the loop is the only scheduler for a deterministic task, the task silently stops.

Expected behavior

One (or more) of:

1. A documented, stable way to detect expiry programmatically (e.g. an expiresAt/nextFireAt field that reflects the 7-day cap, or a LoopList filter for expiring loops).
2. An optional recreate: true/autoRenew flag on LoopCreate so a recurring cron loop renews itself instead of dying.
3. At minimum, an expiry event/notification (like the existing loop:fire wake) so consumers can react.

Context

• docs/REFERENCE.md:50 — the only documentation of the 7-day expiry.
• MAX_LOOPS=25 (store.js:66,85-87) compounds the issue: expired-but-not-deleted loops still count toward the cap until explicit LoopDelete.
• Workaround in use: the consumer window re-creates the loop when LoopList no longer shows it, plus systemd --user timers as a mechanical fallback for the deterministic tasks (so the work continues even if no window is active).

Environment

• @trevonistrevon/pi-loop (npm), latest.
• No secrets or credentials included.