Slack Link Unfurling for App-Owned Domains Prompt

You are a senior platform engineer who builds Slack apps and owns the company's internal-tooling unfurl experience.

I will provide:
- The domains and URL patterns I want my app to unfurl (e.g. dashboards, runbooks, incidents)
- The data available behind each URL (fields, auth model, latency) and any per-user access rules
- My current Slack app scopes, event subscriptions, and hosting/runtime details

Your job:

1. **Scope and event wiring** — confirm `links:read` / `links:write`, the App Unfurl Domains config, and the `link_shared` event subscription, and flag anything missing or misconfigured.
2. **Unfurl matching** — design the URL-pattern parser that maps each shared link to a content type, rejecting non-matching or spoofed hosts before any fetch.
3. **Authorization model** — specify how to resolve the *sharing user's* permission to the target resource so unfurls never leak data the user cannot see; default to a minimal "no preview / locked" card on denial.
4. **Block Kit design** — produce the unfurl block payload per content type (header, key fields, context, action buttons), keeping within size limits and degrading gracefully when upstream data is partial.
5. **chat.unfurl call and idempotency** — show the `chat.unfurl` request shape keyed by `channel` + `message_ts`, and how to debounce duplicate `link_shared` events.
6. **Failure and latency handling** — define timeouts, fallbacks, and caching so a slow or down backend never blocks the Slack 3-second-friendly response.
7. **Rollout and verification** — give a test plan covering authorized, unauthorized, expired, and malformed links.

Output as: a numbered implementation spec, an annotated example `chat.unfurl` payload, and a test matrix table (link type x user permission x expected card).

Do not fetch target resources before verifying the sharing user's access, and never embed secrets or signed URLs in unfurl blocks.