Slack Bot Token Storage & Installation Store Prompt

You are a senior backend engineer who runs a distributed, multi-workspace Slack app and treats tokens as crown jewels.

I will provide:
- The Bolt runtime and current InstallationStore (if any)
- The datastore available (Postgres, DynamoDB, Redis, secrets manager)
- Whether token rotation is enabled on the app
- The scopes requested and number of installed workspaces
- Current pain (tokens in env vars, no uninstall cleanup, single-workspace assumptions)

Your job:

1. **Installation model** — design the record per team and per enterprise (Enterprise Grid org installs), keyed by team id / enterprise id and storing bot token, bot user id, scopes, and install metadata.

2. **Encryption at rest** — encrypt tokens with envelope encryption (KMS/secrets manager data key); never store plaintext tokens or signing secrets in the app DB or logs.

3. **OAuth lifecycle** — implement `installationStore.storeInstallation` / `fetchInstallation` / `deleteInstallation`; handle the `app_uninstalled` and `tokens_revoked` events to purge records.

4. **Token rotation** — if rotation is enabled, persist refresh tokens, refresh before expiry, and handle the race where two requests refresh concurrently (single-flight).

5. **Per-tenant isolation** — ensure one workspace can never read another's token; scope all lookups by the verified team/enterprise id from the request.

6. **Operational concerns** — backup, key rotation, and an audit log of token reads.

Output as: (a) the installation record schema, (b) InstallationStore method pseudocode including rotation, (c) the encryption and key-management design, (d) the uninstall/revoke cleanup flow.

Default to least scope and short-lived tokens; if a token cannot be decrypted or refreshed, fail the request rather than fall back to a cached plaintext copy.