Release & Launch Plan

You are a senior Product Lead / Tech Lead. Create the **Release & Launch Plan** for the current version.

## Positioning
Release is not "push code". It is to:
1) ship changes to real users under controlled risk
2) ensure fast stop-loss when issues occur
3) align user/team/business expectations

This document is the final statement of delivery responsibility.

## Preconditions
- PRD is completed and accepted
- Test/acceptance result is Go (or conditional Go)
- Rollback, downgrade, and monitoring capabilities exist
- Covers only the current release batch

## General requirements
- Must be rollbackable, monitorable, explainable
- Clarify who does what, when
- Avoid uncontrolled "big bang" releases
- If risk is not controllable, explicitly choose not to release

---

## Output structure

1) Release scope & version notes
- version identifier
- scope of changes
- user-visible changes
- internal/technical-only changes

2) Release strategy & cadence
- strategy: full rollout / phased rollout / canary
- time window
- any manual approval gates
- rollout order (multi-platform/multi-service)

3) Pre-launch checklist
- code/config/data readiness
- dependency/third-party status check
- feature flags status
- backups/rollback points/downgrade plan
- known risks and unfixed issues confirmation

4) Execution steps
- high-level steps (no commands)
- owner per step
- success criteria per step
- abort/rollback conditions

5) Rollback & downgrade
- triggers
- execution path
- downgrade/disable alternatives
- communication and logging requirements after rollback

6) Post-release monitoring
- key metrics to watch (usage, error rate, performance, business)
- observation windows (1h / 24h / 7d)
- alerts and response process
- decision owner

7) Internal & external communications
- internal release notes (eng/product/ops/support)
- external release notes/announcement bullets
- expectation management
- materials support/ops need

8) Release outcome & retrospective entry
- was the release successful?
- any rollback/downgrade triggered?
- do we need a postmortem?
- owner and timing

---

## Output requirements
- No deployment commands/scripts
- Steps must be executable and checkable
- Explicitly state conditions where we must stop release
- If risk exceeds acceptable level, explicitly recommend "do not release"

End with 3–5 bullet points:
"Did this release deliver the right changes under controlled risk?"