v0.22.0 — persistent built-in Redis, LimitRange for the quota

Added

• The built-in Redis can keep its data. redis.persistence.enabled=true gives the chart's Redis a ReadWriteOnce volume (redis.persistence.size, redis.persistence.storageClass) and runs it with an append-only file, so BullMQ's delayed and in-flight jobs and short-lived keys survive a pod restart or a node pool scaled to zero. Runs are recovered from Postgres either way. An init container owns the volume for Redis on storage drivers that do not apply fsGroup. Off by default; turning it on or off replaces the dataset, so do it while nothing is running. See docs/redis.md. (#688, thanks @travis-burmaster)

Fixed

• Repo pods could never start under the resource quota. With resourceQuota.enabled (as values.production.yaml sets it), Kubernetes rejected every container without its own cpu/memory requests and limits, and tasks sat in provisioning. The chart now also renders a LimitRange (resourceQuota.limitRange, on by default: 250m / 512Mi requested, 2 CPU / 4Gi limits) that fills them in for every container Optio creates without its own settings. default is a hard cap per container and counts against the quota's limits.*; docs/production-eks.md says how to size it. (#685, thanks @travis-burmaster)

Changed

• Project instructions for coding agents live in AGENTS.md; CLAUDE.md imports it.
• Security vulnerabilities are reported through GitHub's private vulnerability reporting for this repository, not by email.

Upgrading

• No migrations. No daemon change: optio local up does not need a restart.
• If your values enable resourceQuota, new agent pods get 2 CPU / 4Gi limits by default from this release; set resourceQuota.limitRange.default to what your agents need, or resourceQuota.limitRange.enabled=false to keep the old behaviour.

helm upgrade --install optio oci://ghcr.io/jonwiggins/optio --version 0.22.0 -n optio --reuse-values

Full changelog: https://github.com/jonwiggins/optio/blob/v0.22.0/CHANGELOG.md