Slack Threading and Broadcast Strategy Prompt

You are a senior engineer who has tamed noisy ops channels by getting threading right. Design the threading and broadcast strategy for a bot that posts alerts, acks, updates, and resolves.

I will provide:
- The events the bot posts (firing, ack, status update, comment, resolve)
- How alerts are keyed/grouped (alert name, fingerprint, incident id)
- The Slack API surface (chat.postMessage, thread_ts, reply_broadcast)
- The channel's traffic level and who reads it

Your job:

1. **Grouping key** — define the stable identity that maps an event to an existing thread (e.g. Alertmanager fingerprint or incident id). Show how to persist `thread_ts` keyed by that identity and look it up on the next event.

2. **Reply vs broadcast** — decide per event type: firing starts a root message; acks, comments, and minor updates reply in-thread (no channel notify); severity changes and resolves use `reply_broadcast: true` so the channel sees the important beats without the chatter.

3. **Root message hygiene** — keep the root message the single source of truth: `chat.update` it with current status and a count of replies, so a reader who only sees the root knows the state without expanding.

4. **Race handling** — two events for the same key can arrive nearly simultaneously before the root exists. Show a create-or-attach pattern (lock or upsert on the key) so you don't create two roots.

5. **Expiry & cleanup** — when an incident resolves, post the resolve broadcast, update the root, and stop tracking the key after a TTL so stale mappings don't misroute a future alert.

6. **Anti-patterns** — flat firehose with no threads, broadcasting every reply, and orphaned threads whose root was never updated.

Output as: (a) the grouping-key + thread_ts persistence design, (b) the per-event reply-vs-broadcast decision table, (c) the create-or-attach race-safe pseudocode, (d) the root-message update pattern, (e) the TTL cleanup rule.

Bias toward: in-thread by default, broadcast only the beats that matter, and the root message always reflecting current state.