Repository operating rules

Treat the Gitea origin as the canonical deployment repository.
Production is disabled; do not create or enable production Applications without a complete production design and explicit approval.
Never commit Terraform state, provider directories, plan files, tfvars, Vault init JSON, unseal/recovery material or plaintext credentials.
A Vault API object may be owned by only one Terraform state.
Keep secret payloads outside Terraform resources and data sources.
Classify shared capabilities under platform, bounded-context backing services under systems, and first-party runtimes under workloads.
Manage child Argo CD Applications through the permission-scoped ApplicationSets in platform/control-plane/argocd; do not add explicit child Applications or use the default AppProject.
Add new ApplicationSet entries with autoSync: "false" and open each gate only after its documented external prerequisites have been verified.
Keep vault-foundation, vault-workloads, and vault-database as separate states. A delegated state must not own the policy or login role that grants its own execution identity.
Routine GitOps automation changes Git only; direct cluster mutation is reserved for documented bootstrap and recovery runbooks.
Run make validate before handing off repository changes.
Do not apply to a live cluster unless the user explicitly requests live deployment and the kube context has been verified.