production-readiness-review git:20260927.2f2f40bA

Immutable. This exact content never changes and is served at /api/v1/blob/0057c7f9476e3a95.

---
name: production-readiness-review
description: Reviews whether a feature branch is ready to run in production - deployment platform, data durability and backups, schema migrations, configuration and secrets, transport security, build and dependencies, observability, scaling and rollback - and produces a traffic-light report and a change list. Use it whenever the user asks if something is production ready, before a first deploy or a release, for a go-live checklist, deployment review, operational readiness, or when "production changes" left for later need to be addressed.
---

# Production readiness review

Most production failures come from assumptions nobody checked. Start by turning assumptions into facts.

## 1. Ask about the target

Ask in one round, with recommended options first. Skip what the repo already answers.

| Question | Why it matters |
| --- | --- |
| Where does it run (VPS, container, PaaS, serverless)? Is the disk persistent across deploys? | Data loss when state is stored on local disk |
| Is there a reverse proxy or load balancer? Which address does the app see? | Client IP for rate limits, trusted proxy settings |
| Is HTTPS terminated before the app? | Secure cookies, HSTS |
| How many instances? | In-memory state, stores that allow one writer, shared secrets |
| How are secrets and environment variables set? | Missing or weak secrets, the production mode of the runtime or framework |
| Where do logs go? Is there alerting? | Silent failures |
| How is it deployed and rolled back? Is there CI? | Broken builds, untested merges |

## 2. Review each area

| Area | Check |
| --- | --- |
| Data | Source of truth, backups and restore test, operations that delete data (confirmation, backup first) |
| Schema | Version marker, migrations for existing databases, a test that starts from the previous schema |
| Configuration | Every variable documented, validated at startup, safe defaults, failure messages |
| Transport and session security | HTTPS, HSTS, `Secure` cookies, trusted proxies, CORS scope |
| Build and dependencies | Runtime needs only production dependencies; generated assets built at build time; a dependency audit (for example `npm audit --omit=dev`, `pip-audit`, `composer audit`); engine versions tested |
| Observability | Logs enabled, errors logged with cause, audit events, no secrets in logs |
| Scale | In-memory limits and caches, concurrent writers, expensive operations (for example password hashing, reports) |
| Operations | Start, stop, health check, rollback, runbook for the top failures |

For heavy branches, run `red-team-review` with production-focused missions (operations, data durability, security in deployment) instead of reviewing alone.

## 3. Report and triage

Write `.scratchpad/<slug>/production-readiness-report.md` with `traffic-light-findings`:

- Facts confirmed by the user and assumptions still open.
- Findings per area.
- A "where to look first when it fails" table: symptom → first suspect.

Then run `triage-findings-list` to merge it with other open reports, and ask which changes to apply.