Independent Review Brief

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