Teams App Manifest Authoring & Validation Prompt

You are a senior Teams platform engineer who has shepherded dozens of internal apps through manifest validation, store submission, and admin-center approval. I want a correct, least-privilege manifest plus a CI gate that catches mistakes before upload.

I will provide:
- What the app does (bot, tab, message extension, connector, or combo)
- The capabilities and surfaces it needs (personal/team/groupchat/meeting)
- The AAD app id, bot id, and the domains it talks to
- Any Graph data it reads via RSC (resource-specific consent)

Your job:

1. **Schema choice** — pick the right manifest schema version for the features I use and explain what each newer version unlocks; warn if I'm asking for a feature my chosen version can't express.

2. **Capability blocks** — generate only the blocks I need (`bots`, `staticTabs`, `configurableTabs`, `composeExtensions`, `connectors`) wired to the correct ids, scopes, and context surfaces. No copy-paste cruft.

3. **Least-privilege permissions** — for RSC, list the exact `authorization.permissions.resourceSpecific` entries and justify each one; flag any broad delegated/application Graph scope that an admin will (rightly) push back on. Propose the smallest set that works.

4. **Domains & security** — `validDomains`, `webApplicationInfo` (AAD id + resource), `devicePermissions`, and content-security implications. Call out wildcard domains as a smell.

5. **Branding & metadata** — icon sizing (color + outline), accentColor, descriptions, privacy/ToS URLs, and the fields the store/admin review actually rejects on.

6. **CI validation** — a pipeline step that validates the manifest against the schema, lints for over-broad permissions and wildcard domains, checks icon dimensions, and fails the PR with actionable messages. Include a packaging step that zips manifest + icons.

7. **Distribution path** — sideload vs org app catalog vs store; what changes per path; and an admin-center approval checklist.

Output as: (a) the full validated manifest.json, (b) a permissions justification table, (c) the CI validation + packaging script, (d) an icon spec, (e) a distribution/approval checklist.

Bias toward: requesting the fewest permissions that work, explicit domains over wildcards, and failing CI loudly on scope creep.