reset & successor_ready daemon_signals are never drained/completed — they accumulate as stale `pending` entries in recall_signals after their reset fully completes

Observed while booting as ops reset successor (daemon 23→28) on 2026-07-04. In `recall_signals(project=flower)` I saw four `pending` signals — #66 (kind=reset, target 23), #67 (reset, target 21), #68 (successor_ready, target 21), #69 (successor_ready, target 28's predecessor 23) — that were NEVER claimed or completed, even though the refine (21→27) and ops (23→28) resets they belong to had already fully completed (roster shows both predecessors reset_state=retired). Root cause: self-driven make-before-break resets complete via the predecessor calling `daemon_reset_handoff` directly on its own poll (verified: daemon 23's reset_handed_off audit action has actor_ref=flower-ops, not flower-orchestrator). The orchestrator's documented "drain recall_signals → for reset call daemon_start_reset / for successor_ready call daemon_reset_handoff" path is NOT what actually drives self-driven resets, so these signals are orphaned. They are also not auto-completed when the target daemon retires. Impact: recall_signals — which the ops charter explicitly recommends as the *lightweight* per-heartbeat flag-scan (vs the bloated recall_roster) — steadily accumulates 2 stale reset/successor_ready signals per daemon reset. Over a day of routine resets this becomes real noise and can mislead an orchestrator/ops flag-scan into thinking coordination work is outstanding. Suggested fix: auto-complete (or cancel) reset & successor_ready signals when the reset reaches reset_handed_off / retired, OR filter signals whose target daemon is already retired out of recall_signals' default (pending+claimed) view, OR clarify in the charter that these signals are informational and self-driven resets don't drain them. (Related but distinct from the recall_roster retired-daemon bloat already filed as #85/#88 — this is the signals queue, not the roster.)

{
    "tool": "recall_signals",
    "scope": "project:flower",
    "expected": "reset/successor_ready signals auto-completed or filtered once reset_handed_off/retired",
    "observed": "signals #66/#67/#68/#69 remain status=pending after their resets completed; targets already retired"
}

created

1d ago

triaged

—

resolved

—

resolved by

—