ragleap-ops v0.2.0 release notes

Helm chart (helm/ragleap-ops/) wrapping all four k8s/ manifests (db, app, voice, neo4j) with real configurable values.yaml — image tags, resource limits, storage sizes, probe timings, credentials.
Real database schema (db/schema.sql) is packaged into the chart via Helm's .Files.Get, copied verbatim from the repo's real schema file, not reproduced from memory.

neo4j's liveness probe had no explicit failureThreshold in the Helm template (unlike the raw k8s manifest, which was already correctly set) — defaulted to Kubernetes' built-in 3, too tight for JVM startup under CPU contention. Found via live helm install/helm upgrade testing on a real kind cluster (not caught by helm lint or helm template, since those don't exercise runtime behavior). Fixed to match the readiness probe's more generous timing (initialDelaySeconds: 60, failureThreshold: 6).

All four services (db, app, voice, neo4j) independently reached 1/1 Running with zero restarts for extended periods (60+ minutes) on a real kind cluster via helm install.
Added explicit resources.requests/limits for neo4j (512Mi memory request, 1Gi limit; CPU tuned to 50m during testing) after live testing on this session's VPS surfaced real host-level CPU/memory contention (the test VPS runs several other production services concurrently) — this is a permanent, worthwhile chart improvement, not a workaround specific to this host.

Full 4-service stack was demonstrated stable in bounded windows (60+ min) on a resource-constrained single-node test host that was also running unrelated production services. Extended (multi-hour) concurrent-stack stability was not verified on this specific host due to genuine host-level memory/CPU exhaustion (swap fully exhausted at points during testing) — not a chart defect, but an honest scope boundary on what was tested. A dedicated cluster (not sharing a host with other production workloads) is expected to have materially more headroom.
CPU resource values (cpu: 50m for neo4j) were tuned against a heavily constrained single-vCPU-allocatable test node and should be reviewed against real target-cluster capacity before production use, not assumed as a universal recommendation.
Same limitations as v0.1.0 still apply: app-env-secret.yaml/db-schema-configmap.yaml's real content are environment-specific and not shipped; PVC storage sizes remain placeholder defaults.