# 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 `gitops/platform`, bounded-context
  backing services under `gitops/apps/systems`, and first-party runtimes under
  `gitops/apps/workloads`.
- Manage child Argo CD Applications through the permission-scoped
  ApplicationSets in `gitops/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.