Production Safety

Never modify production databases, infrastructure, or SSM parameters directly. Zero exceptions. Source: AGENTS.md

Production is sacred at Dedalus. A "quick fix" to prod that bypasses the pipeline creates invisible state drift and has caused outages. This principle emerged from a real incident where a constraint was dropped in production while running code still referenced it in an ON CONFLICT clause, bricking all MCP credential provisioning with 42P10: there is no unique or exclusion constraint matching the ON CONFLICT specification.

Specific Prohibitions

• No DROP INDEX, ALTER TABLE, or any DDL against prod Supabase, whether via MCP, the SQL editor, or the dashboard.
• No aws ssm put-parameter or terraform apply targeting prod resources.
• No manual ECS task definition updates in prod.

The Rules

Migrations and code ship together. Never apply a migration to an environment where the code that depends on it has not been deployed. If adding a column, the code that reads it ships in the same deploy. If dropping a constraint, the code that uses the new constraint ships first.

Never run DDL against prod manually. Not from a REPL, not from Supabase MCP, not from the dashboard SQL editor. If it needs to happen, it goes through a migration file in version control, reviewed and deployed through the pipeline.

Fix-forward, not patch prod. If a migration breaks prod, the fix is a new migration plus code change deployed through the pipeline. Manually patching prod creates invisible state that drifts from what the migration history says should exist.

Dev and preview are for breaking. Test migrations there. Verify the code works with the new schema. Only then promote to prod.

Promotion Path

All changes follow the promotion path: dev -> preview -> prod. A migration that lands on prod without its companion code change will break prod. Database commands are dry-run by default; use --execute to mutate.

Agent-specific rule

Agents make production safety both more important and easier to violate. They can run shell commands quickly, chain tools without fatigue, and misread natural-language intent as permission. Therefore production authority must be encoded in the harness, not left to vibes.

This is Agent Security Model applied to production: authority and side effects need policy, audit, and human gates.

Why This Matters

The underlying insight is about state coherence. When you modify production directly, the running system's state diverges from what your version control says it should be. Every subsequent deployment, migration, or debugging session operates on false assumptions. The cost of a "quick fix" is not the fix itself but the invisible drift it creates.

Concept Position

---

Timeline

• 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Never modify production databases, infrastructure, or SSM parameters directly. Zero exceptions. Source: AGENTS.md. Source: User request, 2026-07-01
• 2026-06-19 | Added the agent-specific production safety rule: encode prod authority in harness/policy, not in natural-language restraint. Source: whole-wiki concept review, 2026-06-19