Independent Review Brief · Config Workshop

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

Use this brief for independent reviews of the current ConfigHub Helm plan.

Scope

Review the new pathway:

public Helm chart catalog proof
enterprise-internal chart variants are out of scope

new chart proof repos
  -> HelmPlan
  -> ChartDossier
  -> recipe candidate
  -> variants
  -> variant revisions
  -> rendered release objects
  -> scans and gates
  -> ConfigHub OCI artifact receipts
  -> generated proof spreadsheets

Explicitly exclude legacy/reference artifacts:

data/top500-catalog-analysis/source/source-feature-scan.raw.json

The old render-and-vendor top-20 payload has been removed from the active tree. The source-feature scan may be mentioned only as input to the generated top-500 catalog analysis, not as the current proof path.

Source Docs

Read:

README.md
data/adversarial10/summary.md
data/adversarial10/proof-readiness.csv
docs/planning/agreed-execution-plan.md
docs/reference/chart-recipe-manifest-flow.md
docs/planning/archive/current-pathway-review.md
docs/planning/issue-backlog.md
docs/corpus/known-adversarial-charts.md
docs/planning/review-prompts.md
confighub/installer docs and package/render/upload/OCI/facts behavior

Review 1: Product Clarity

Review focus:

Would a skeptical Helm/GitOps user understand in 60 seconds why this is less
Helm pain rather than more platform ceremony?

Public framing:

Approve the Kubernetes objects Helm produced,
not the values you hope produced them.

Return:

Verdict.
Whether the happy path is no more complex than Helm for the first successful install.
Whether the happy path feels safer and more correct than Helm, not merely more instrumented.
Whether the value appears immediately: exact rendered objects, diff/review, scan/gate, and safe publish to ConfigHub OCI for GitOps pickup.
Three strongest claims.
Five likely user objections.
Crisp answer to each objection.
Any terms to cut, rename, or demote.
Whether variant sounds like a real governed object or just a values file.

Adoption standard:

The first demo should be no harder than Helm for a successful install.
Proof should appear automatically.
The workflow should feel safer and more correct than Helm alone.

Review 2: Architecture And Artifact Proof

Review focus:

Do the proposed artifacts prove chart -> recipe -> variant -> revision ->
rendered object -> scan/gate -> receipt?

Return findings:

P0: false, unsupported, or missing proof.
P1: gaps that weaken belief.
P2: clarity, structure, or naming improvements.

Also return:

Required repo tree.
Required schema list.
Minimal Redis proof.
What belongs in confighub/installer.
What requires ConfigHub model/API support.

Review 3: At-Scale Adversarial Verification

Review focus:

Can the plan prove itself against 20, 100, and 500 real charts, including
complex Helm behavior?

For the next milestone, "20 charts" means 20 full public-chart proof slices. It does not mean a broad readiness spreadsheet plus a handful of examples. Review top20-full-proof-target.md as the concrete target list and acceptance contract.

Review whether the plan covers:

source and dependency locks
lookup
generated secrets/certs/time/random functions
.Capabilities
required / fail
hooks/tests
CRDs/webhooks/RBAC/APIService
tpl
raw/extra manifest slots
mutable image tags
schema gaps and unknown values
upgrade, rollback, and live observation freshness

Return:

Required adversarial run matrix.
Required result objects.
Required spreadsheet tabs and columns.
Failure taxonomy.
P0 blockers before scaling.
Whether any P0 issue in docs/planning/issue-backlog.md is being ignored or bypassed by the written plan.
Whether #24 really comes first, before the repo generates more evidence artifacts.

Acceptance Standard

Every generated spreadsheet row must trace to artifacts and receipts:

row -> chart source -> lock -> HelmPlan -> recipe candidate -> variant ->
variant revision -> rendered digest -> scan/gate -> receipt -> next action

If a claim cannot be traced, it is not proof.

Current generated evidence to inspect:

recipes/bitnami/redis/25.5.3/
packages/bitnami/redis/25.5.3/
docs/demo/redis/
data/adversarial10/
docs/planning/top20-full-proof-target.md
recipes/metrics-server/metrics-server/3.13.0/
packages/metrics-server/metrics-server/3.13.0/
recipes/ingress-nginx/ingress-nginx/4.15.1/
packages/ingress-nginx/ingress-nginx/4.15.1/
recipes/jetstack/cert-manager/v1.20.2/
packages/jetstack/cert-manager/v1.20.2/
recipes/external-secrets/external-secrets/2.5.0/
packages/external-secrets/external-secrets/2.5.0/
recipes/argo-cd/argo-cd/9.5.15/
packages/argo-cd/argo-cd/9.5.15/
recipes/bitnami/postgresql/18.6.7/
packages/bitnami/postgresql/18.6.7/
recipes/bitnami/rabbitmq/16.0.14/
packages/bitnami/rabbitmq/16.0.14/
recipes/prometheus-community/kube-prometheus-stack/85.3.3/
packages/prometheus-community/kube-prometheus-stack/85.3.3/
recipes/grafana/loki/7.0.0/
packages/grafana/loki/7.0.0/
recipes/longhorn/longhorn/1.11.2/
packages/longhorn/longhorn/1.11.2/
recipes/bitnami/mysql/14.0.3/
packages/bitnami/mysql/14.0.3/
recipes/grafana/grafana/10.5.15/
packages/grafana/grafana/10.5.15/
recipes/hashicorp/vault/0.32.0/
packages/hashicorp/vault/0.32.0/
recipes/secrets-store-csi-driver/secrets-store-csi-driver/1.6.0/
packages/secrets-store-csi-driver/secrets-store-csi-driver/1.6.0/
recipes/prometheus-community/prometheus/29.8.0/
packages/prometheus-community/prometheus/29.8.0/
recipes/bitnami/mongodb/19.0.7/
packages/bitnami/mongodb/19.0.7/
recipes/bitnami/nginx/24.0.2/
packages/bitnami/nginx/24.0.2/
recipes/grafana/tempo/1.24.4/
packages/grafana/tempo/1.24.4/
recipes/hashicorp/consul/2.0.0/
packages/hashicorp/consul/2.0.0/

data/adversarial10/ is a readiness and blocker harness, not final certification. Review it for whether each row is clear, generated, and receipt-backed, then identify what is still missing before those charts become full recipe/variant/revision proofs.

metrics-server/metrics-server@3.13.0 is the first row promoted from that harness. Review whether its target fact, APIService, RBAC, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern after Redis.

ingress-nginx/ingress-nginx@4.15.1 is the second row promoted from that harness. Review whether its default and admission-disabled variants, admission webhook, Helm hook lifecycle, RBAC, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for admission-webhook charts.

jetstack/cert-manager@v1.20.2 is the third row promoted from that harness. Review whether its default and crds-enabled variants, CRD lifecycle, admission webhook, Helm startup hook lifecycle, RBAC, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for CRD-heavy control-plane charts.

external-secrets/external-secrets@2.5.0 is the fourth row promoted from that harness. Review whether its default and no-crds variants, 23-CRD default render, disabled dependency lock, admission webhook, webhook Secret/cert controller, RBAC, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for CRD-heavy controller charts.

argo-cd/argo-cd@9.5.15 is the fifth row promoted from that harness. Review whether its default and no-crds variants, three-CRD default render, disabled redis-ha dependency lock, hook lifecycle policy, generated Secret ownership, StatefulSet policy, GitOps handoff, RBAC, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for GitOps controller charts.

bitnami/postgresql@18.6.7 is the sixth row promoted from that harness. Review whether its generated-passwords and existing-secret variants, generated fact binding, target Secret binding, Bitnami common dependency lock, hook lifecycle policy, StatefulSet/PVC policy, extension-slot review, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for stateful generated-credential charts.

bitnami/rabbitmq@16.0.14 is the seventh row promoted from that harness. Review whether its generated-passwords and existing-secret variants, generated fact binding for password and Erlang cookie, target Secret binding for both external Secrets, Bitnami common dependency lock, StatefulSet/PVC policy, clustering policy, extension-slot review, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for stateful generated-credential charts with clustering material.

prometheus-community/kube-prometheus-stack@85.3.3 is the eighth row promoted from that harness. Review whether its default and no-crds variants, generated fact binding for Grafana admin password, 10-CRD default render, umbrella dependency lock, admission webhook observation gates, cluster RBAC, dashboard ConfigMap normalization, extension-slot review, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for large umbrella monitoring charts.

grafana/loki@7.0.0 is the ninth row promoted from that harness. Review whether its blocked default render, single-binary-filesystem and simple-scalable-minio variants, storage/schema binding, MinIO object-store fixture, dependency lock, cluster RBAC, StatefulSet/PVC policy, Loki ConfigMap normalization, extension-slot review, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for charts that cannot render safely from defaults.

longhorn/longhorn@1.11.2 is the tenth row promoted from that harness. Review whether its default and ui-ingress variants, 22 Longhorn CRDs, pre-upgrade hook policy, admission/recovery observation, cluster RBAC, privileged storage workload policy, StorageClass/default-setting policy, UI ingress policy, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for storage control-plane charts.

bitnami/mysql@14.0.3 is the eleventh row promoted from that harness. Review whether its generated-passwords and existing-secret variants, generated fact binding for root/user/replication passwords, target Secret binding, Bitnami common dependency lock, hook lifecycle policy, StatefulSet/PVC policy, extension-slot review, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for stateful generated-credential charts.

grafana/grafana@10.5.15 is the twelfth row promoted from that harness. Review whether its chart-deprecation marker, generated-passwords and existing-secret-ingress variants, generated admin credential binding, target Secret binding, UI ingress policy, cluster RBAC review, deployment and extension-slot gates, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for dashboard/control-plane application charts.

hashicorp/vault@0.32.0 is the thirteenth full public-chart proof row. Review whether its default and ha-raft-ui variants, TLS posture review, injector admission webhook review, StatefulSet storage and HA Raft policy, init/unseal operate-policy gates, service exposure review, RBAC review, Secret/env extension-slot gates, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for security-sensitive stateful control-plane charts.

secrets-store-csi-driver/secrets-store-csi-driver@1.6.0 is the fourteenth full public-chart proof row. Review whether its default and sync-secret-rotation variants, SecretProviderClass CRD lifecycle, CSIDriver kubelet integration, Linux DaemonSet and hostPath policy, cluster RBAC review, synced Secret ownership, rotation/provider-health policy, provider identity integration gates, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for node-level CSI driver charts.

prometheus-community/prometheus@29.8.0 is the fifteenth full public-chart proof row. Review whether its default and server-only-ephemeral variants, bundled dependency lock, Alertmanager/exporter/pushgateway component selection, scrape ConfigMap review, server PVC/storage retention policy, cluster RBAC review, remote read/write and exposure extension slots, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for bundled monitoring stack charts.

bitnami/mongodb@19.0.7 is the sixteenth full public-chart proof row. Review whether its generated-passwords and existing-secret-replicaset variants, generated root password binding, target Secret binding, replica-set and arbiter StatefulSets, persistent storage, NetworkPolicy/PDB policy, hook lifecycle review, tpl configuration slots, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for stateful database topology charts.

bitnami/nginx@24.0.2 is the seventeenth full public-chart proof row. Review whether its http-clusterip and existing-tls-ingress variants, generated TLS mitigation, declared TLS target Secrets, ingress exposure, NetworkPolicy, PDB, service exposure, static-site supply-chain slots, metrics add-ons, raw/template extension slots, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for simple web-service charts.

grafana/tempo@1.24.4 is the eighteenth full public-chart proof row. Review whether its deprecated-chart marker, local-persistent and s3-query-observability variants, local/S3 storage backend policy, target S3 credential Secret, query ingress, ServiceMonitor capability, NetworkPolicy, StatefulSet/headless-Service runtime risk, raw/template extension slots, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for observability storage charts.

hashicorp/consul@2.0.0 is the nineteenth full public-chart proof row and twentieth target chart. Review whether its default-control-plane and secure-mesh-existing-secrets variants, 28 CRDs, cluster RBAC, injector webhooks, TLS/ACL/gossip target Secrets, gateway topology, UI ingress, lifecycle Jobs, rendered Secrets, StatefulSet storage, raw/template extension slots, scan/gate, and cub installer package evidence are convincing enough to serve as the repeatable pattern for service-mesh/control-plane charts.

Every happy-path demo must also pass the simple UX test:

one install command
one review/diff path
one publish path to ConfigHub OCI for GitOps pickup
clear scan/gate status
receipts available after the fact
Helm-equivalent output where expected
every intentional difference explained