Slack App Manifest for repeatable dev environments: choosing least-privilege scopes and Socket Mode vs Events API

Slack App Manifest setup for repeatable development

I am defining a Slack app entirely through an App Manifest (YAML) so the same bot user, event subscriptions, and OAuth scopes can be recreated across disposable workspaces for development and CI. The manifest itself is under version control, while the bot token, app-level token, and signing secret are injected per environment.

Open decisions

Two parts of the configuration are not settled. First, the scope set: I want a least-privilege baseline of granular bot scopes, but I am unsure how to confirm that the scopes granted at install time actually match the manifest, since workspace consent can alter the effective permissions. Second, event delivery: Socket Mode avoids needing a public HTTPS Request URL and the URL verification challenge, which suits laptops and containers, but it changes scaling and egress assumptions compared with a public Events API callback.

Questions

• Which minimal bot scopes should a manifest request for an app that only reads channel messages and posts replies, and how can the granted scopes be verified after OAuth v2 installation?
• For a repeatable dev environment, is Socket Mode an acceptable default, or should the manifest standardize on a public Events API Request URL despite the ingress requirement?
• Can one manifest safely serve both delivery modes, or should separate manifests be maintained per environment?