Three issues from review of the setStatus change: - processEvent logged "slack response sent" even when postThreadReply had exhausted its fallback and delivered nothing. Check the returned ts and log a failure instead of claiming success. handleConfirmation's silent bail on an undelivered card gets the same treatment. - A refresh tick already in flight when stop() ran could land after the clear and leave a stale indicator. All setStatus calls now go through a per-thread promise queue, so the clear is ordered behind any outstanding refresh. - Slack stores one status per (channel, thread), so two mentions in the same thread ran concurrently and the first to finish tore down the second's indicator. Runs now share a refcounted lease per thread and only the last one to finish clears it. The concurrent-run behaviour is covered by a new test; the refresh ordering is structural (single queue) and would need a fake clock to exercise, since the refresh interval is 60s. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018vZGKg3npYcKypYaYEDkJr