feat(helm): ChromaDB collection provisioning — serviceChromaCollections PostSync Job

[izzywdev]

Context

ChromaDB is already deployed in the Helm chart (databases.yaml, chromadb.enabled: true) and shows healthy in Argo CD. The gap is the provisioning layer — the equivalent of service-db-provisioning.yaml that creates per-service Postgres roles/databases.

For ChromaDB there is no:

• serviceChromaCollections values block (analogous to serviceDatabases)
• PostSync Job that creates consumer-declared collections on the shared ChromaDB instance
• Entry in governance/datastore-provisioning.md for the ChromaDB recipe
• Entry in docs/consuming-repos/ for ChromaDB onboarding

What to build

1. helm/fuzeinfra/templates/service-chroma-provisioning.yaml

A PostSync Job (same pattern as service-db-provisioning.yaml) that iterates serviceChromaCollections in values and runs a Python one-liner to get_or_create_collection() for each entry. Image: chromadb/chroma:latest (ships the Python client). The Job is idempotent (get_or_create_collection is safe to re-run).

# values.yaml shape:
serviceChromaCollections:
  - name: fuzeplan-repo-digester    # logical name (for Job labelling)
    enabled: true
    collections:
      - _repo_digester_ready        # sentinel — health check
      # per-project collections are created dynamically by the service;
      # only shared/bootstrap collections go here

No per-service credential needed — ChromaDB in FuzeInfra runs without auth (internal cluster only, Traefik-only ingress). The Job just needs the ChromaDB host/port from the existing values.

2. Register FuzePlan repo-digester in values-contabo.yaml

serviceChromaCollections:
  - name: fuzeplan-repo-digester
    enabled: true
    collections:
      - _repo_digester_ready

3. governance/datastore-provisioning.md — add ChromaDB recipe section

Document the pattern: no credentials needed (unauthenticated, internal), collection names follow <service>_<purpose> convention, dynamic per-resource collections (e.g. repo_<projectId>) are NOT declared here (created by the service on demand).

4. docs/consuming-repos/CHROMADB_PROVISIONING.md

Mirror the MONGODB_PROVISIONING.md pattern: registry table of existing consumers + instructions for adding a new one.

Why no per-service credentials

Unlike Postgres/Mongo/Neo4j, FuzeInfra's ChromaDB instance runs without authentication (it's internal-only, no external ingress). Collection namespacing is the isolation mechanism — each service uses its own collection prefix. This is consistent with how ChromaDB is documented in docker/chromadb/README.md.

Acceptance criteria

• service-chroma-provisioning.yaml PostSync Job exists and passes helm lint
• serviceChromaCollections for fuzeplan-repo-digester enabled in values-contabo.yaml
• _repo_digester_ready sentinel collection verifiably created in prod ChromaDB after Argo sync
• governance/datastore-provisioning.md updated with ChromaDB section
• docs/consuming-repos/CHROMADB_PROVISIONING.md created

@claude

[claude]

Claude finished @izzywdev's task in 0s —— View job

---

I'll analyze this and get back to you.