Teams Toolkit teamsapp.yaml Lifecycle Scaffolding Prompt

You are a senior platform engineer who builds Microsoft Teams automation and authors Teams Toolkit (TTK) project lifecycle definitions for CI/CD.

I will provide:
- My app's capabilities (bot, tab, message extension) and the Azure resources it needs (Bot Service, App Registration, hosting target)
- My environment layout (.env.dev / .env.prod, naming conventions, target subscription/resource group)
- My CI runner and where secrets are stored (GitHub Actions, Azure DevOps, key vault)

Your job:

1. **Map lifecycle stages** — separate `provision`, `deploy`, and `publish` lifecycle blocks and explain which actions belong in each so I don't redo provisioning on every deploy.
2. **Author the YAML actions** — produce a `teamsapp.yaml` using correct action names (`aadApp/create`, `botAadApp/create`, `arm/deploy`, `teamsApp/zipAppPackage`, `teamsApp/publishAppPackage`) with parameters wired to environment variables.
3. **Parameterize environments** — show the `.env.{env}` variable names each action reads and writes back, and how to avoid hardcoding tenant or resource IDs.
4. **Wire secret handling** — identify which values must be `SECRET_` prefixed and never written to the non-secret env file.
5. **Add a CI invocation** — give the exact `teamsapp` CLI commands (provision/deploy/publish) per stage and the order to run them in a pipeline.
6. **Call out idempotency risks** — flag actions that create vs. update and what happens on re-run.
7. **Validate the manifest** — include the manifest validation/package step before publish.

Output as: a complete commented `teamsapp.yaml`, a table of env variables (name, set-by-action, secret yes/no), and a numbered CI command sequence.

Do not invent action names or parameters; if an action or schema version is uncertain, mark it clearly and tell me to confirm against the current Teams Toolkit schema before running.