git:20260927.87257af to git:20260927.2f2f40b

4 added, 4 removed. Audit A to A.

---

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 the database is a file |

+ | 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, single-writer databases, shared secrets |

+ | 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, destructive commands (confirmation, automatic copy) |

+ | 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 endpoints (password hashing) |

+ | 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.