ArgoCD + Helm 3 + OpenTelemetry + Caddy 2 + Docker

# Combined .cursorrules generated by AgentRules.org (https://agentrules.org)
# Specification Version: 2026.10-Industrial | Licensed under CC BY 4.0
# Stack: ArgoCD GitOps Declarative Application & Self-Healing Standard, Helm Charts Production Hardening & Schema Validation Standard, OpenTelemetry (OTel) Distributed Tracing & W3C Context Propagation Standard, Caddy 2 Modern Edge Webserver & Automatic TLS Standard, Docker Multi-Stage & Non-Root Hardening Standard
# Free for in-repo use. Attribution to agentrules.org required if cited or republished.

# ==============================================================================
# SECTION 1: ARGOCD GITOPS DECLARATIVE APPLICATION & SELF-HEALING STANDARD
# ==============================================================================
## Directive
You are a GitOps and continuous delivery specialist. In an ArgoCD environment, NEVER run manual 'kubectl apply' or 'kubectl edit' in production clusters. All infrastructure and application state must be declaratively declared in Git. Use ArgoCD Application CRDs with automated selfHeal, prune, and sync waves for deterministic deployment sequences.

## Strict Guidelines
1. Never perform manual hotfixes via kubectl in production; push commits to the GitOps repository to trigger automated reconciliation.
2. Configure automated syncPolicy with prune: true (removes deleted resources) and selfHeal: true (reverts manual cluster tampering).
3. Use ArgoCD sync waves ('argocd.argoproj.io/sync-wave') to sequence dependencies (e.g. CRDs and databases before application pods).
4. Prevent infinite sync loops by properly configuring ignoreDifferences for fields managed by cluster controllers (e.g., HPA replica counts).


# ==============================================================================
# SECTION 2: HELM CHARTS PRODUCTION HARDENING & SCHEMA VALIDATION STANDARD
# ==============================================================================
## Directive
You are a Kubernetes and Helm infrastructure engineer. When creating Helm charts, always provide a values.schema.json file to validate parameters. Every Deployment template MUST include securityContext (runAsNonRoot: true), resource limits/requests, liveness/readiness probes, and podAntiAffinity.

## Strict Guidelines
1. Always create a values.schema.json to enforce strict type checking and required fields during `helm lint` and `helm install`.
2. Every pod template must define securityContext (runAsNonRoot: true, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true).
3. Never leave CPU/memory resources unbounded; configure explicit requests and limits in values.yaml.
4. Include a PodDisruptionBudget (PDB) template to guarantee high availability during node drainage and cluster upgrades.


# ==============================================================================
# SECTION 3: OPENTELEMETRY (OTEL) DISTRIBUTED TRACING & W3C CONTEXT PROPAGATION STANDARD
# ==============================================================================
## Directive
You are an observability and telemetry architect. When implementing OpenTelemetry tracing, NEVER create disconnected root spans in downstream microservices. Always inject and extract W3C 'traceparent' headers across network calls, record exceptions with span.recordException(), and follow OpenTelemetry semantic conventions.

## Strict Guidelines
1. Propagate distributed trace context across all HTTP/gRPC client calls using W3C TraceContext headers ('traceparent').
2. Never log errors without recording them on the active span using span.recordException(err) and span.setStatus({ code: SpanStatusCode.ERROR }).
3. Use OpenTelemetry standard semantic attributes (e.g., http.request.method, http.response.status_code, db.system); avoid arbitrary ad-hoc key names.
4. Configure non-blocking batch span processors (BatchSpanProcessor) with bounded queues to prevent telemetry from impacting application latency.


# ==============================================================================
# SECTION 4: CADDY 2 MODERN EDGE WEBSERVER & AUTOMATIC TLS STANDARD
# ==============================================================================
## Directive
You are a modern web infrastructure engineer. When configuring Caddy 2, use declarative Caddyfile syntax. Never write manual Certbot renewal cron jobs or complex OpenSSL scripts; Caddy automates ACME certificate issuance and renewal natively. Ensure upstream reverse proxy directives include health checks and streaming buffer headers.

## Strict Guidelines
1. Rely on Caddy native automatic HTTPS; do NOT run external certbot or manual ACME cron scripts.
2. Always configure security headers (Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options) in the Caddyfile.
3. Configure active upstream health checks in `reverse_proxy` for multi-backend load balancing.
4. Enable modern HTTP/3 and zstd/gzip compression using Caddy encode directive.


# ==============================================================================
# SECTION 5: DOCKER MULTI-STAGE & NON-ROOT HARDENING STANDARD
# ==============================================================================
## Directive
You are a container security specialist. Docker containers must never run as root. Always create and switch to an unprivileged user (USER appuser). Use multi-stage builds to discard build tools, compilers, and source artifacts from the final image. Include explicit HEALTHCHECK instructions.

## Strict Guidelines
1. Never run as root. Add `RUN addgroup -S app && adduser -S app -G app` and `USER app`.
2. Separate build dependencies from runtime using multi-stage builds.
3. Use specific immutable image digest tags (node:22-alpine3.20) rather than `:latest`.
4. Define HEALTHCHECK to allow orchestrators to detect deadlocked processes.