1. Add examples/ingress-cert-manager.yaml — a two-document file containing
   both a chart values fragment (ingress block with cert-manager annotations
   for the Let's Encrypt HTTP-01 flow) and a cluster-scoped ClusterIssuer
   manifest applied with kubectl. Helm reads only the first document; the
   second is for cluster operators. Closes the rubric-4 'TLS by default' gap
   without making cert-manager a chart dependency.

2. NOTES.txt: warn when secrets.relayPrivateKey or secrets.gitHookHmacSecret
   are set inline. Both are labeled 'NOT recommended' in values.yaml comments;
   a render-time warning makes the operator see it. Includes pointer to
   examples/secret-sample.yaml for the canonical fix.

Verified: helm install --dry-run renders the cert-manager annotations
correctly; inline-secret warning fires for one or both keys with proper
comma joining; default install stays silent on both. helm lint clean.

Co-authored-by: Tyler Longwell <tlongwell@squareup.com>
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>

values.yaml: expand 9 flow-style mappings (livenessProbe/readinessProbe/
startupProbe httpGet, resources requests/limits, securityContext
seccompProfile, containerSecurityContext capabilities, postgresql and
redis primary.persistence) to block style. The chart-testing default
yamllint config (lintconf.yaml) flags any spaces inside flow braces;
empty {} and [] forms are kept where they're idiomatic (podAnnotations,
nodeSelector, etc.) since those don't have inner-brace spacing.

.github/workflows/helm-chart.yml: SHA-pin the five third-party action
refs flagged by zizmor (unpinned-uses) and Semgrep:
  azure/setup-helm@v4              -> 1a275c3b... # v4.3.1 (x2)
  helm/chart-testing-action@v2.7.0 -> 0d28d314... # v2.7.0 (x2)
  helm/kind-action@v1.10.0         -> 0025e74a... # v1.10.0
Matches the pinning pattern Sami established in .github/workflows/
docker.yml. actions/checkout and actions/setup-python were not flagged
(zizmor allowlists first-party actions/* refs) so left as-is.

Verified locally: ct.yaml + helm dependency build + helm template
against ci/quickstart, tests/fixtures/ha, and tests/fixtures/
production-existing-secret all render clean. helm lint clean.

Co-authored-by: Tyler Longwell <tlongwell@squareup.com>
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>

…n suite

helm-unittest 0.8.2 runs `failedTemplate` asserts per-template in the
suite's `templates:` list. With multiple templates listed and `fail`
firing from only one (e.g. serviceaccount.yaml's `include buzz.validate`),
the assertion sees "No failed document" for the other-template scope and
the test fails despite the overall render failing.

Two fixes:

1. Scope `validation_test.yaml` to `templates/deployment.yaml` only.
   That's the entry point with `include "buzz.validate"`, sufficient to
   exercise every guard. Side benefit: positive renders that asserted
   `hasDocuments: count: 2` had the wrong number anyway (production
   profile renders 5 docs, not 2).

2. New `render_test.yaml` covers positive renders with the full
   template list — needed because deployment.yaml's checksum annotation
   does `include (print $.Template.BasePath "/secret-chart.yaml")`,
   which only resolves if secret-chart.yaml is loaded by the suite.
   Asserts target specific fields with per-assert `template:` instead
   of fragile document counts.

Also adjusts the "ownerPubkey is not 64 lowercase hex" test to match
the schema-validation error pattern, since values.schema.json's regex
runs before template rendering and is the actual gate.

Local: `helm unittest` → 19/19 passing across 4 suites.
Co-authored-by: Tyler Longwell <tlongwell@squareup.com>
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>

…Secret

The quickstart profile composed DATABASE_URL/REDIS_URL in the chart-managed
Secret with chart-generated passwords, but the CloudPirates postgres/redis
subcharts each generated their *own* independent passwords and bound their
Services at names the URLs didn't match. Result: a default
`helm install --set quickstart=true` brought pg/redis up but the relay could
never authenticate (password mismatch) or, for redis, never resolve the host
(`-redis-master` Service does not exist in standalone mode).

- Point postgresql.auth.existingSecret / redis.auth.existingSecret at the
  chart-managed Secret (`<fullname>-relay`) with matching key names, so the
  servers initialize with the exact password the relay's URL embeds — one
  source of truth instead of two diverging randoms.
- Fix the composed REDIS_URL host: standalone CloudPirates redis renders
  `<release>-redis`, not `<release>-redis-master`.
- Correct two no-op persistence paths (redis.master.* / postgresql.primary.*)
  to the keys CloudPirates actually reads (redis.persistence /
  postgresql.persistence); the prior nesting was silently ignored.
- Add a regression test asserting DATABASE_URL/REDIS_URL resolve to the real
  subchart Service hosts and never `-redis-master`.

Verified live on a kind/docker-desktop cluster against the published
ghcr.io/block/buzz:0.1.0 image: pg+redis 1/1, relay logs "Postgres connected",
psql/redis-cli with the chart-secret passwords succeed (select 1 / PONG).
The relay still CrashLoops on absent schema (relation "events" does not exist)
because :0.1.0 predates the auto-migration code (#988) — connectivity is fixed;
schema bootstrap lands with #988 + a re-cut image.

Co-authored-by: Tyler Longwell <tlongwell@squareup.com>
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>

randAlphaNum 64 emits letters g-z, which are neither hex nor bech32, so
nostr::Keys::parse rejects the autogenerated BUZZ_RELAY_PRIVATE_KEY and the
relay crashes at startup with "invalid BUZZ_RELAY_PRIVATE_KEY". Pipe through
sha256sum to produce exactly 64 lowercase hex chars — a valid secp256k1 secret
key. Add a unittest asserting the autogen key matches ^[0-9a-f]{64}$ so the
bug can't regress.

Co-authored-by: Tyler Longwell <tlongwell@squareup.com>
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>

The quickstart profile now stands up MinIO and Typesense in-cluster
alongside the existing Postgres + Redis subcharts, so the relay starts
with zero external services and passes its A3 S3 conformance probe. The
production profile leaves minio.enabled/typesense.enabled off and points
s3.endpoint + typesense.url (or BUZZ_S3_* / TYPESENSE_URL via
existingSecret) at managed services.

- values.yaml: minio + typesense.enabled/image/persistence blocks; pinned
  MinIO image tags (minio:RELEASE.2025-09-07T16-13-09Z,
  mc:RELEASE.2025-08-13T08-35-41Z); corrected the misleading quickstart
  flag comments (it is an intent marker, not a behavior switch).
- templates: quickstart-minio{,.init}.yaml + quickstart-typesense.yaml
  Deployments with bucket-create Job, existingSecret-conflict guards.
- _validate.tpl: typesense guard now keys on .enabled; added symmetric
  S3-source guard (relay hard-fails its S3 probe without storage).
- _helpers.tpl: buzz.relaySelectorLabels (selectorLabels + component:relay)
  scopes the relay Deployment/Service/PDB so they no longer match the
  bundled MinIO/Typesense pods.
- NOTES.txt + README: document the bundled quickstart and external prod.
- tests: 28/28 across 6 suites — bundled render, S3/TYPESENSE_URL
  composition, S3-missing + minio-existingSecret guards, selector isolation.

Co-authored-by: Tyler Longwell <tlongwell@squareup.com>
Signed-off-by: Tyler Longwell <tlongwell@squareup.com>