2.4 KiB
Disposable and protected data
Pre-production is a lifecycle stage, not permission to discard data. Disposable means the owner authorizes replacement of specified data and it can be reproduced. Idempotent describes an operation's repeated effect; it does not establish disposability.
Establish authority
Read the repository's existing instructions for a standing data policy. It must identify:
- named disposable environments and how to verify the actual connection target;
- the data/resources that may be deleted or rebuilt;
- the authorized reset/reseed procedure and source of required fixtures;
- protected environments, valuable/shared data, and external compatibility obligations.
Treat this as scoped authorization, not a reason to reset unnecessarily. Before each operation, verify the actual target matches the declaration, the operation stays within the allowed resources, and required data can be recreated. Stop and ask when identity, scope, or reproducibility is uncertain. Do not infer permission from a branch name, NODE_ENV, a database name containing “dev,” or the absence of production users.
When no policy exists, ask for the intended preservation contract and explicit authority before schema/data changes. Record any approved standing policy in the repository's established instructions; never label an environment disposable on the agent's own authority. Production/live-database access remains explicitly gated even if another target is disposable.
Implement the smallest sufficient change
For a verified, authorized disposable target, prefer a direct schema change plus reset/reseed over compatibility adapters, phased backfills, dual writes, or bespoke rollback machinery. Keep migration files when the framework needs them to create a fresh database. Verify initialization/rebuild and affected behavior with representative data.
For protected data or external consumers, preserve the actual contract. Design migration, backup/recovery, compatibility, and verification around demonstrated risks and obtain scoped approval. Shared staging data with valuable manual QA state is protected unless its owner explicitly authorizes replacing it.
Example: a required field in an authorized throwaway database may need an updated schema and seed data, a rebuild, and a feature check. It does not automatically need tests for upgrading every historic schema. The same field in a customer-backed service may require a staged migration and compatibility checks.