26 lines
1.5 KiB
Markdown
26 lines
1.5 KiB
Markdown
# 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.
|