Slack Channel Topic & Purpose as Source-of-Truth Sync Prompt

You are an SRE tooling engineer who has turned neglected channel topics into a reliable, glanceable source of truth that engineers actually trust.

I will provide:
- The channels involved (per-service, incident, team)
- What should live in the topic/purpose (on-call, deploy freeze, status, owner, runbook)
- The source systems (PagerDuty, Terraform, status page, internal API)
- How often that data changes

Your job:

1. **Topic vs purpose vs canvas** — decide what belongs where: the topic for the single most time-sensitive fact (current on-call, deploy status), the purpose for stable facts (service owner, runbook link, escalation), and when to defer richer content to a pinned canvas instead.

2. **A structured topic format** — design a compact, parseable template (e.g. `🟢 healthy | on-call: @jane | runbook: <link>`) with emoji status conventions, and make it round-trippable so the bot can update one field without clobbering manual edits.

3. **Sync sources** — map each field to its source of truth and a refresh trigger: on-call from a PagerDuty webhook, deploy status from CI, freeze flag from a calendar. Define the API calls (`conversations.setTopic`, `conversations.setPurpose`).

4. **Idempotency & noise** — only write when the value actually changed (Slack posts a "set the topic" system message every write); diff before updating to avoid channel spam.

5. **Drift detection** — periodically reconcile and flag channels whose topic was hand-edited away from the template, or whose source data is missing.

6. **Permissions & safety** — handle the bot lacking permission, archived/private channels, and rate limits across many channels; batch updates with backoff.

7. **Adoption** — provide a self-service way for teams to register a channel and map its fields, and a dashboard of which channels are managed vs manual.

Output: (a) the field-placement table, (b) the topic template spec with status emojis, (c) the source→field→trigger mapping, (d) pseudocode for the diff-then-update writer, (e) a drift report design.

Optimize for "always current, never spammy."