Cursor rule

1---
2description: "DevOps and infrastructure: Docker, Kubernetes, Terraform, CI/CD. Load when editing Dockerfiles, compose, k8s manifests, Terraform, or workflow YAML — not for application code."
3globs: ["**/Dockerfile*", "**/*.tf", "**/docker-compose*.yml", "**/docker-compose*.yaml", "**/k8s/**", "**/.github/workflows/**", "**/.gitlab-ci.yml", "**/Jenkinsfile", "**/cloudbuild.yaml", "**/terraform/**", "**/helm/**"]
4alwaysApply: false
5---
6 
7# DevOps & Infrastructure Patterns
8 
9Mechanical reference for containerization, orchestration, IaC, and CI/CD. For general coding workflow (read-before-edit, minimal diff, verification labels), the always-on core **Code Discipline** and **App And Scaffold Discipline** sections are canonical.
10 
11Load this rule when touching infrastructure files matched by globs. For unfamiliar provider APIs or version-sensitive changes, verify against current official docs (or use the `deep-research` skill) — do not invent flags, resource names, or provider syntax.
12 
13---
14 
15## Before Changing Infrastructure
16 
171. Read existing Docker, compose, k8s, Terraform, Helm, and CI workflow files in this repo first.
182. Note pinned base images, provider versions, and environment naming — match them unless the task requires a deliberate upgrade.
193. Identify blast radius: prod deploy, secrets, stateful resources, and rollback path.
204. Prefer **plan / dry-run / validate** before **apply / deploy / push**.
21 
22---
23 
24## Validate Before Apply
25 
26| Tool | Smallest useful check |
27|------|------------------------|
28| Docker | `docker build -t test:local .` |
29| Compose | `docker compose config` |
30| Kubernetes | `kubectl apply --dry-run=client -f …` or `kubectl diff -f …` |
31| Terraform | `terraform fmt -check`, `terraform validate`, `terraform plan` |
32| Helm | `helm lint`, `helm template` (render locally) |
33| GitHub Actions | YAML syntax + action pin review; run workflow on a branch when safe |
34 
35Never recommend `terraform apply`, `kubectl apply`, or production deploy without a plan/dry-run step unless the user explicitly skips it.
36 
37---
38 
39## Decision Quick Reference
40 
41| Need | Prefer |
42|------|--------|
43| Local dev stack | Docker Compose when sufficient; k8s only when repo already uses it |
44| Secrets | Platform secret stores / CI secrets — never commit plaintext |
45| CI | Extend existing workflow patterns in `.github/workflows/` rather than inventing a parallel pipeline |
46| Image tags | Pin major.minor (or digest); avoid `:latest` in anything that ships |
47| Terraform state | Remote backend + locking when team/shared; do not hand-edit state |
48 
49---
50 
51## Common Traps
52 
53- **YAML tabs** — spaces only (2-space indent is standard).
54- **Unquoted YAML scalars** — quote version strings and booleans when they must stay strings (`"1.0"`, `"true"`).
55- **Secrets in repo** — no passwords, tokens, or keys in Dockerfile `ENV`, compose, or workflow YAML; use `${{ secrets.* }}`, K8s `secretKeyRef`, or TF variables from a vault.
56- **`:latest` base images** — pin `node:20-alpine`, `python:3.12-slim`, etc.; verify current tags against official registries.
57- **Blind apply** — skipping `plan` / dry-run on shared or production infra.
58- **Drift from repo conventions** — new services that ignore existing naming, networks, labels, or backend config.
59 
60---
61 
62## CI/CD Discipline
63 
64- Reuse job names, runner labels, cache keys, and artifact patterns already in the repo.
65- Pin third-party GitHub Actions to a commit SHA or semver tag — not `@main`.
66- Scope secrets to the minimum job that needs them.
67- For deploy workflows: require manual approval or environment gates when the repo already uses them; do not remove safety rails opportunistically.
68 
69---
70 
71## Security (infra-specific)
72 
73- Least-privilege IAM / service accounts; no admin credentials in CI logs.
74- Scan images when the repo already has Trivy/Snyk/similar — do not add heavy tooling unprompted.
75- Network policies / security groups: default deny between services unless the architecture requires otherwise.
76- Treat `.env`, kubeconfig, and TF state as sensitive — never paste contents into chat or commits.
77 
78---
79 
80## Verification After Changes
81 
82Match proof to the claim (see always-on status-verification rule):
83 
84| Change | Minimum proof |
85|--------|----------------|
86| Dockerfile / compose | `docker build` or `docker compose config` succeeds |
87| k8s manifest | dry-run or schema validation passes |
88| Terraform | `validate` + `plan` with expected diff |
89| CI workflow | YAML valid; optional dry-run on branch if user allows |
90 
91Label deploy/runtime behavior as `unverified` until exercised in the target environment.
92 
93---
94 
95## When NOT to Load This File
96 
97- Application logic, API handlers, or UI — use core **Code Discipline** instead.
98- Full cloud architecture from scratch — inspect the repo and ask on real forks (provider, region, existing VPC/cluster).
99