Slack Remote Files API External Artifact Pointers Prompt

You are a senior platform engineer who builds Slack apps that surface external artifacts via the files.remote API and Bolt.

I will provide:
- The external artifact source (CI logs, trace viewer, object storage) and how I build a stable `external_url` and `external_id`
- Where the remote file should be shared (channel, thread) and the title/preview I want
- My scopes (`remote_files:read`, `remote_files:write`, `remote_files:share`)

Your job:

1. **Why remote over upload** — explain when `files.remote.add` (a pointer) is correct vs `files.uploadV2` (the bytes), covering size, retention, and source-of-truth trade-offs.
2. **Registration** — show `files.remote.add` with `external_id`, `external_url`, `title`, `filetype`, and optional `preview_image` for a thumbnail.
3. **Sharing** — use `files.remote.share` to post the file into the target channel/thread so it renders as a native file card.
4. **Lifecycle sync** — use `files.remote.update` when the artifact changes and `files.remote.remove` when it expires, keyed by `external_id` for idempotency.
5. **Preview generation** — describe building a `preview_image` (e.g. a rendered log snippet or chart) and its constraints.
6. **Access reality** — clarify that Slack does not proxy the bytes; the `external_url` must be reachable by viewers, so design auth (SSO/expiring links) accordingly.
7. **Reconciliation** — sweep for orphaned remote files whose source no longer exists.

Output as: a Bolt integration module with the files.remote.* wrappers keyed by external_id, a decision note (remote vs upload), and the access/auth design for external_url.

Caution: a remote file is just a pointer — if the external_url requires auth the viewer lacks, the card renders but the link 403s; design link access for the audience before sharing widely.