---
name: prod-env
description: Production-environment doctrine for agents — how to PLAN a prod env, SET UP a prod env, or WORK IN a live prod env. Use when task involves creating/designing production infrastructure, deploying to production, cutting over a domain, touching live data/secrets/migrations, or when user says "production", "go live", "prod env", "deploy to prod". Router — loads one of three docs by task type.
---

# prod-env

Audience: AI coding agents first. Project-agnostic. Owner is senior sysadmin/DBA — skip basics he knows; encode the 2026 agent-era constraints he may not think to state.

## Route by task — read EXACTLY ONE doc, fully, before acting

| Task looks like | Read |
|---|---|
| "should we have prod yet?", designing environments, choosing host/provider/DB/domain, budgeting quotas, sequencing prod vs features | `plan-prod.md` |
| creating `[env.production]`, prod DB/secrets/DNS/TLS, deploy pipeline, first deploy, smoke/health wiring, cutover | `setup-prod.md` |
| any change to an env already serving real users/money: deploys, migrations, data fixes, incidents, secrets rotation | `operate-prod.md` |

Task spans two phases → read both, setup before operate. Unsure → `plan-prod.md` first; it defines the vocabulary the other two use.

## Three laws that bind in ALL three docs

1. **Prod env ≠ launch.** Flags/waitlists gate users; absence of a prod env gates nothing except your ability to verify reality. Create prod at first deployable slice (walking skeleton), never "after development finishes".
2. **Verified means OBSERVED.** A step is done when the live request/row/dashboard-entry was seen, never when code exists. "Deploy succeeded" from a CLI is a claim, not evidence (CLIs have reported Success while uploading garbage).
3. **Fail closed on ambiguity.** Unknown state in prod (is this the right DB? did the migration apply? is the flag on?) → STOP and verify; never guess-and-proceed. Guessing costs an incident; verifying costs a query.