What problem does it solve? Queue consumers that ack messages naming unknown tenants or streams silently destroy recoverable, money-bearing work, and recovery sweeps that share the same static roster never find the loss. This Skill enforces a discipline where only genuinely unparseable messages are acked as poison, while unroutable-but-valid work is retried toward a configured dead-letter queue. ## Core Features & Use Cases - Ack vs retry decision rules: Distinguishes poison (unparseable body, ack with loud log) from unroutable-here (tenant outside a static roster, retry toward the DLQ). - Static roster gap detection: Flags workers whose tenant maps lag sibling services (api workers, sequencer DOs) that serve a wider tenant set. - Recovery sweep audit: Forces any sweep or cron to state its roster, since a sweep enumerating a compile-time tenant list recovers only those tenants. - Use Case: A Biller consumer receives a pod.signed trigger for a newly provisioned pool tenant not yet in its static map; instead of acking and losing the invoice, it calls message.retry() so the trigger lands in the declared dead-letter queue as a recoverable record. ## Quick Start Review this queue consumer's dispatch and error branches and tell me whether any ack path destroys work that a retry toward the DLQ could preserve.
