ChiefOS | Get more from the AI you already use

# Production readiness review

Turn a working prototype into a defensible production system. Treat “production ready” as a claim that must be supported by evidence about the product's real users, failure modes, data, infrastructure, and operating environment.

This method coordinates specialized coding methods. Do not replace those methods with a generic checklist. Select only the branches that match the product and the work authorized by the user.

Establish the target

Read the repository instructions and enough of the codebase to answer:

What user problem and critical journeys does the product support?
Who can access it, and what data or actions are sensitive?
What environment is it expected to run in?
What traffic, latency, availability, recovery, and support expectations are credible now?
Which parts are prototypes, generated scaffolding, manual operations, or known shortcuts?
What does the user mean by “ready”: private pilot, limited beta, public launch, or regulated production?

Use `codebase-onboarding` when the repository is unfamiliar. Use `brainstorming` or `codebase-design` when the intended behavior or module boundaries are unresolved.

Do not require enterprise architecture for a small pilot. Match the strength of each control to the actual consequence of failure.

Build an evidence map

Inspect the repository and available runtime evidence. Record findings under these lanes:

**Product behavior** — critical journeys, edge cases, empty states, errors, permissions, accessibility, and mobile behavior.
**Architecture** — module boundaries, hidden coupling, duplicated state, configuration, dependencies, and change isolation.
**Data** — schema constraints, migrations, integrity, privacy, retention, backup, restore, and destructive operations.
**Identity and security** — authentication, authorization, secrets, untrusted input, dependencies, auditability, and abuse controls.
**Reliability** — timeouts, retries, idempotency, concurrency, partial failure, recovery, observability, and capacity.
**Quality evidence** — type checks, linting, unit and integration tests, end-to-end coverage, browser checks, and reproducible defect cases.
**Delivery** — build reproducibility, environment parity, configuration, CI, deployment, rollback, health checks, and release ownership.
**Operations** — alerts, logs, dashboards, runbooks, incident response, support path, cost visibility, and accountable owners.

For every material claim, distinguish:

**Observed:** directly supported by code, configuration, test output, logs, or a live check.
**Inferred:** likely from the available evidence but not directly verified.
**Unknown:** important and still unverified.

Prioritize by failure consequence

Rank gaps by the combination of impact, likelihood, exposure, and difficulty of recovery.

**Blocker:** a credible path to data loss, unauthorized access, financial harm, unusable critical journeys, or an unrecoverable deployment.
**Before launch:** a material reliability, correctness, accessibility, or operating gap that should be closed for the stated release level.
**Scheduled hardening:** a real weakness with an acceptable temporary control and a named follow-up.
**Optional:** improvement whose cost exceeds its current risk reduction.

Avoid counting findings as a proxy for seriousness. One broken authorization boundary matters more than dozens of style issues.

Route the work

Choose specialized methods from the evidence map:

`codebase-design` for architecture and module seams
`frontend-design` or `ui-ux-pro-max` when an interface lacks an intentional visual direction or product-specific design system
`frontend-patterns` or `backend-patterns` for implementation conventions
`shadcn` and `vercel-composition-patterns` when the selected React implementation uses shadcn/ui or needs reusable component APIs
`vercel-react-best-practices` or `vercel-react-native-skills` for web or native performance work
`ui-animation` when motion, gestures, transitions, or reduced-motion behavior are material
`api-design` for contracts, errors, pagination, versioning, and rate limits
`database-migrations` for schema and data changes
`diagnosing-bugs` for failures that lack a tight reproduction loop
`test-driven-development` for new behavior and regression fixes
`security-review` for sensitive input, identity, secrets, payments, or privileged actions
`hardcode-audit` for environment-specific values and stale embedded constants
`e2e-testing` for critical user journeys
`web-design-guidelines`, the appropriate accessibility method, `browser-qa`, and `impeccable` for rendered behavior and interface quality
`deployment-patterns` for CI, health checks, rollback, and release mechanics
`ai-regression-testing` for products whose behavior depends on prompts, models, tools, or agent decisions

Use `writing-plans` when the repair spans multiple files or systems. Keep the plan ordered by dependencies and risk reduction, with explicit verification at each seam.

Execute and verify

When the user asked for the fixes, continue through implementation within the available authorization. Do not stop after producing the assessment.

For each repair:

Create or identify a pass/fail signal for the specific risk.
Make the smallest coherent change that closes it.
Run the narrow check that proves the change.
Run affected integration or browser checks.
Record fresh evidence and any remaining uncertainty.

Use `verification-before-completion` before claiming the work is complete. Run the repository's required checks, inspect user-facing behavior when it changed, and report any check that could not run. Use `finishing-a-development-branch` when the change is ready to integrate.

Output

Return a concise production-readiness record:

```text Release target - intended environment and audience - critical journeys - readiness definition

Decision - ready / ready with conditions / not ready - evidence supporting the decision

Priority gaps - severity - observed evidence - consequence - repair or temporary control - owner or next action

Completed repairs - change - verification evidence

Remaining unknowns - what is unverified - how to verify it

Next release gate - exact checks or decisions required ```

Do not claim the system is production ready because it builds, deploys, or has tests. The readiness decision follows the stated release target and the strongest available evidence across all material lanes.