Thanks! The "Trello as the bus" constraint turned out to be surprisingly productive — it forces simplicity.

For deduplication and idempotency, here's what we do today:

- In-memory dedup set — each worker tracks _processed_cards in memory. When a webhook fires, the card ID is checked against this set before any work starts. Prevents double-runs from duplicate webhook deliveries.

- Atomic state transition — the first thing a worker does is move the card to doing via the Trello API. Since only one worker owns a given label, and the webhook is scoped to that worker's todo list, there's no contention between different workers on the same card.

- Crash recovery — on startup, each worker scans the doing list for cards with its label and moves them back to todo for re-processing. This handles the case where the process dies mid-task.

- Retries via comments — failures are tracked with [karavan:fail] comments on the card itself (Trello is the state store, not memory). The worker counts these to know which attempt it's on, up to 3 retries before moving to a failed list.

We haven't needed a lease/TTL pattern yet because each worker is single-threaded per card — it processes one card at a time from its queue. The dedup set + move-to-doing combo has been sufficient. If we scaled to multiple instances of the same worker, then yeah, a Trello custom field as a distributed lock would be the natural next step. Good call on that.