shipping-and-launch

<core_principle> Every launch must be reversible, observable, and incremental. The goal is not just to deploy — it's to deploy safely, with monitoring in place and a rollback plan ready before the first user is affected. </core_principle>

<pre_launch_checklist> Complete ALL sections before deploying. A failed item is a blocked deployment.

Code Quality

• All tests pass (unit, integration, e2e)
• Build succeeds with no errors or warnings
• Code reviewed and approved (requesting-code-review was executed)
• No debug statements or TODO items that must be resolved before launch
• Error handling covers expected failure modes

Security (cross-reference secure-coding-standard)

• No secrets in code or version control
• Dependency audit clean (npm audit / pip-audit / dotnet list package --vulnerable / equivalent) — no Critical/High issues
• Input validation on all user-facing endpoints
• Authentication and authorization checks in place
• Security headers configured (CSP, HSTS)
• Rate limiting on auth endpoints
• CORS restricted to known origins

Performance (cross-reference performance-optimization)

• No N+1 queries in critical paths
• All list endpoints paginated
• Read-only DB queries skip change tracking where the ORM supports it
• DB indexes in place for critical query paths
• Caching configured for high-frequency reads

Infrastructure

• All environment variables set in production environment
• Database migrations applied (or scripted and ready)
• Health check endpoint exists and responds 200
• Logging and error reporting active and verified
• SSL/TLS configured

Documentation

• Second Brain updated (via finishing-a-development-branch → Second Brain ingest)
• API documentation current (api-registry.md reflects new endpoints)
• ADRs written for any new architectural decisions
• Changelog or release notes updated </pre_launch_checklist>

<feature_flag_strategy> Ship behind feature flags to decouple deployment from release. Code enters production inactive; users are enabled incrementally.

Lifecycle:

1. DEPLOY with flag OFF     → Code is live but inactive. Zero user impact.
2. ENABLE for team/internal → Test in real production environment, real data.
3. CANARY (5% of users)     → Monitor for 24-48h. Compare metrics vs. baseline.
4. GRADUAL ROLLOUT          → 25% → 50% → 100%, monitoring at each step.
5. FULL ROLLOUT             → 100% of users. Monitor for 1 week.
6. CLEAN UP                 → Remove flag and dead code path within 2 weeks.

Rules:

• Every flag has a named owner and an expiration date — no orphaned flags
• Never nest feature flags (creates exponential test combinations)
• Always test BOTH flag states (on and off) in CI
• For mobile apps: flags are the primary rollback mechanism since you cannot force app updates </feature_flag_strategy>

<staged_rollout>

Rollout Sequence

1. Deploy to staging         → Full test suite + manual smoke test of critical flows
2. Deploy to production      → Feature flag OFF. Verify health check, check for new errors.
3. Enable for team           → 24-hour internal monitoring window.
4. Canary (5%)               → 24-48h window. Compare metrics vs. baseline (see thresholds below).
5. Gradual increase          → 25% → 50% → 100%. Same monitoring at each step.
6. Full rollout              → Monitor for 1 week. Remove feature flag.