devops-infra-helm-charts-gcp/docs/global/SANCTITY_RULES.md

SANCTITY_RULES.md

Non-negotiable rules for the devops-infra-helm-charts repo. Read alongside AGENT_BOUNDARIES.md (per-operation Layer map) and coding-guidelines/helm-values.md (style).

These are the rules whose violation is a process incident, not a clever shortcut. Each one is the result of a real failure mode (or proximity to one).

---

R1 — main is production

Argo CD on every cluster reconciles from main. There is no staging branch. A merge is a deploy event.

• No experimentation on main. Always work on a feature/fix branch and open a PR.
• No force-push to main (enforced at GitHub org level).
• No "I'll just amend that" after merge. A new PR is the only path forward.

R2 — Sister repo is the routing layer; this repo is the values layer

devops-infra-helm-charts holds what gets installed and with what values. github.com/Meesho/devops-infra-argo-config holds where it gets routed (the Argo Application / ApplicationSet manifests).

• A new chart in helm-templates/ does nothing until an Application referencing it lands in the sister repo.
• A new cluster directory in helm-overrides/ does nothing until an ApplicationSet (or per-cluster Application set) covers it.
• Pair the two-repo change. Cite the sister-repo PR in the description here, and vice versa.

R3 — Production traffic surfaces are off-limits

Agent-initiated requests to int.meesho.int, prd.meesho.int, int.mrouter.int, prd.mrouter.int, and workload *.meeshogcp.in services are forbidden. Any accidental call can affect live traffic or data.

• Never curl, WebFetch, query, or otherwise probe these endpoints.
• The pre-commit hook telemetry endpoints (observe.meeshogcp.in/api/webhook, cursor-server.meeshogcp.in/api/v1/...) are automated hook infrastructure, not agent-initiated traffic. They are not a precedent for agent calls.

R4 — Pre-commit hooks must pass

pre-commit-scripts/runner.sh invokes TruffleHog (verified-secret scan with webhook telemetry). CAC and Yaak hooks exist but are no-ops here (their gating paths — configs/ and api-collections/ — don't exist in this repo). TruffleHog is the last-line secret scan.

• Never bypass with --no-verify, git commit -n, or by removing the hook.
• Never weaken a hook to "just get this through" — fix the upstream cause.
• A verified TruffleHog hit means a secret is staged. Real secrets belong in external-secrets (per-cluster), backed by GCP Secret Manager / Vault — not in custom-values.yaml.

R5 — Per-cluster scheduling is bespoke; never copy across clusters

Each cluster has its own node-pool topology. Some clusters use GKE Autopilot's cloud.google.com/compute-class: keys (k8s-central-prd-ase1, k8s-dsgpu-prd-ase1, k8s-shared-int-ase1); standard clusters use dedicated: keys. Per-Contour-instance, per-cluster mappings are recorded in contour-nodeselector-tolerations-summary.md.

• Never copy nodeSelector / tolerations / computeClass blocks between clusters without rewriting them from scratch against the destination cluster's topology.
• Always read the matrix before editing any Contour values; cross-reference sibling cluster files for non-Contour scheduling.
• Wrong values strand pods on wrong nodes or leave them Pending indefinitely.

R6 — Surgical edits only

The repo has ~30 cluster directories × dozens of apps each. The whole point of per-cluster overrides is divergence — accumulated, deliberate, often for tiered traffic or specialised hardware.

• Never "normalise" values across clusters in the same PR as a feature change. Cross-cluster clean-ups are their own PRs with their own scope and CMRs.
• Never auto-update labels, image tags, or comments on apps you weren't asked to touch.
• One change-type per PR. Reviewer cognition matters; rollback granularity matters.

R7 — helm-templates/<chart>/ is mostly upstream

Most charts here are vanilla upstream pulled via helm pull. The local Chart.yaml is often a thin wrapper that declares the upstream chart as a dependency. Editing a templates/*.yaml or the chart's own values.yaml silently forks the chart, and the fork is clobbered on the next upstream sync.

• Never edit helm-templates/<chart>/templates/ or values.yaml casually. If a fork is intentional, follow fork-upstream-chart and document the reason in the chart's README.md.
• Never bump Chart.yaml dependencies[].version without (a) reading the upstream changelog, (b) running helm dependency update to refresh Chart.lock, and (c) calling out the bump in the PR description.

R8 — Versioned chart siblings stay live during migrations

<chart> ↔ <chart>-green (blue-green), <chart> ↔ <chart>-vX.Y.Z (pinned upgrade target), <chart> ↔ <chart>-latest (work-in-progress), <chart> ↔ <chart>-old (retired but still referenced). Both directories may be referenced by Argo Applications during the migration window.

• Never delete a versioned sibling without confirming zero references in github.com/Meesho/devops-infra-argo-config.
• Never "consolidate" siblings into one chart in a maintenance PR. The split is intentional (ADR-A2).

R9 — fullnameOverride is load-bearing

Helm's fullnameOverride controls the name of every released Service, Deployment, StatefulSet, ConfigMap, Secret, and PVC. Service DNS, PVC binding, ConfigMap references in other apps, and Argo Application names downstream all depend on it being stable.

• Never change fullnameOverride in any custom-values.yaml.
• A release-name migration is its own headline-of-the-PR change with platform-team approval, a documented before/after map, and an explicit reason.

R10 — manifests/ is cluster-wide singletons

manifests/storageclass/*.yaml is repo-global; a wrong StorageClass affects every PVC on every cluster that consumes it. manifests/priorityclass/<cluster>/*.yaml is per-cluster but cluster-wide; a wrong PriorityClass changes scheduling priority for every pod that references it.

• Never edit manifests/storageclass/ or manifests/priorityclass/<cluster>/ without platform-team review.
• Never delete a StorageClass referenced by an existing PVC — Kubernetes will not remove the StorageClass while bindings remain, but new PVCs will fail to provision.

R11 — Image tags go through Meesho's Artifact Registry mirror

Production overrides pin images to asia-southeast1-docker.pkg.dev/meesho-devops-admin-0622/admin/sre/<image>, not upstream Docker Hub or Quay. The mirror exists for supply-chain control and rate-limit isolation.

• Never introduce a Docker Hub / Quay / GCR / ECR upstream tag in a production override.
• Never use :latest or unpinned tags in production overrides; an Argo CD reconcile is not the same as a controlled rollout.

R12 — repository.yaml is automation-owned

Generated by registry-bootstrap. Hand edits will be silently overwritten on the next bootstrap run.

• Never hand-edit repository.yaml. If owner data is wrong, fix it in the upstream registry that feeds registry-bootstrap.

R13 — Branch protection trumps everything

Direct push to main is blocked at the GitHub org level. PRs go through code review.

• Never propose workflows that bypass branch protection. If a hotfix is genuinely urgent, the path is "open a PR with a hotfix/* branch and request emergency review," not "force-push to main."

R14 — Pre-existing schema/label drift is not yours to fix

Some clusters have inconsistencies in label values, indentation, key ordering, or comment style — accumulated technical-debt items. Some apps lack values keys their newer siblings have. Some clusters use long BU names (supply) while others use short (supl).

• Never normalise label or BU values in unrelated PRs. Cross-cutting clean-ups are their own PRs with their own scope and CMRs.
• Never reformat a YAML file in passing. Diffs full of indentation churn drown out the real change.

---

What "non-negotiable" means

Each rule above has a documented reason and is the result of a real failure mode (or proximity to one). If you find yourself wanting to break a rule, the path is:

1. Write up the case in a doc (or PR description) explaining what would change and why.
2. Loop in the platform team for review.
3. If the rule should change, change the rule first in this file (with a PR to update it), then act.
4. If the rule should not change, find another way.

A merge that violates a rule here is a process incident, not a clever shortcut.