Current Pathway Review

This review intentionally excludes source-feature-only reconnaissance as product proof:

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 scan is useful history and input to the generated top-500 catalog analysis, not the main pathway for executing the current Helm mission.

Verdict

The mission is clear:

Use Helm charts. Ship ConfigHub variants. Make Helm output easier to review,
vary, verify, and operate.

Lead with:

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

The adoption bar is stricter than "works":

not harder than Helm
not riskier than Helm
not wrong compared with Helm

Scope:

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

The plan is credible if it proves this chain with new artifacts:

chart source
  -> recipe candidate
  -> install variants
  -> immutable variant revisions
  -> exact rendered release objects
  -> scans and gates
  -> ConfigHub OCI artifact receipts
  -> optional direct-apply receipts for local/test paths
  -> observation receipts with freshness

The repo now has 20 top-chart catalog entries with bespoke multi-variant proof, 20/20 local kind live/e2e receipts, 100 machine-proof recipes, and a generated top-500 catalog analysis. The top-500 remains analysis, not certification, but the top-20 and top-100 proof surfaces are now real artifacts rather than a planning packet.

Current proof surface:

recipes/bitnami/redis/25.5.3/
packages/bitnami/redis/25.5.3/
docs/demo/redis/
data/adversarial10/
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/

The next step is to close production dispositions for the mandatory top-20 catalog entries and then promote more top-500 rows from analysis into receipt-backed recipe/variant/revision proofs.

Earlier review concerns to keep guarding against:

• Product: the first demo must be simpler than Helm. Keep internal nouns out of the first user path.
• Operator: real Helm pains must stay tied to receipts and runnable artifacts.
• Architecture: build schemas and verifier first, or the repo will produce decorative evidence.
• Benchmark: top-500 is reconnaissance, not certification. A spreadsheet without receipts is chart-count reporting.

What The Repo Does Well

• States the mission and sales pitch clearly.
• Defines the canonical object model: chart, recipe, variant, variant revision, deployment, receipt.
• Names the simple UX as the thing that must be proven first: one install, clear diff/review, safe publish to ConfigHub OCI, proof generated automatically.
• Adds the adoption standard that the flow must feel easier, safer, and more correct than Helm from first use.
• Separates fast install through ConfigHub's OCI endpoint from deferred serverless work.
• Defines HelmPlan and ChartDossier as the process and knowledge artifacts.
• Makes Helm pain absorption explicit: every weirdness needs a model home, policy, status, and proof.
• Keeps workerless ConfigHub honest: live truth requires external observation receipts with freshness.

Current Gaps

The verifier is now the main protection against stale proof claims:

schemas/
scripts/verify-artifact-chain.mjs
scripts/generate-adversarial10-harness.mjs --verify
npm run verify

npm run verify validates the current top-20 proof artifacts, installer packages, ConfigHub proof lanes, local live/e2e receipts, generated catalogs, top-100 proof surface, top-500 analysis, latest-version refresh outputs, and tamper-detection self-tests.

Remaining gaps are productization and maintenance, not proof absence:

• product cub installer import helm / analyze / compare / scan surfaces;
• Creator flows over cub variant create;
• broader production disposition and GitOps/runtime evidence;
• ongoing latest-version refresh, legacy patch, and top-500 promotion work.

The Redis proof artifacts now exist:

recipes/bitnami/redis/25.5.3/
  helm-plan.yaml
  chart-dossier.yaml
  recipe.yaml
  source-lock.yaml
  dependency-lock.yaml
  control-points.yaml
  value-model.yaml
  effective-values.yaml
  variants/
  revisions/
  receipts/
  reports/

packages/bitnami/redis/25.5.3/
  installer.yaml
  bases/default/upstream.yaml
  bases/reuse-existing-secret/upstream.yaml

The first generated matrix output is:

data/adversarial10/
  corpus.yaml
  corpus.lock.yaml
  summary.md
  proof-readiness.csv
  charts/*/helm-plan.yaml
  charts/*/render-receipt.yaml

It still needs larger generated matrix outputs:

data/top20/
data/top100/
data/top500/
  chart-corpus-lock.yaml
  proof-readiness.csv
  control-point-summary.csv
  matrix.xlsx
  methodology.md

The spreadsheet must be generated from artifacts and receipts. It should be a proof index, not the proof itself.

The first promoted row from that matrix is:

metrics-server/metrics-server@3.13.0

It proves the next reusable shape after Redis: a public chart row can become a recipe, two variants, rendered revisions, target fact requirements, scan/gate receipts, and a deterministic cub installer package/setup proof.

The second promoted row is:

ingress-nginx/ingress-nginx@4.15.1

It proves the admission-webhook chart shape: a default variant with admission Service and ValidatingWebhookConfiguration, an admission-disabled variant that deliberately removes those objects, admission webhook and Helm hook lifecycle gates, cluster RBAC gates, and deterministic cub installer package/setup proof.

The third promoted row is:

jetstack/cert-manager@v1.20.2

It proves the CRD-heavy control-plane chart shape: a default variant with zero CRDs, a crds-enabled variant with the six cert-manager CRDs, CRD lifecycle and upgrade gates, admission webhook observation gates, Helm startup hook lifecycle gates, cluster RBAC gates, and deterministic cub installer package/setup proof.

The fourth promoted row is:

external-secrets/external-secrets@2.5.0

It proves the CRD-heavy controller chart shape: a default variant with 23 CRDs, a no-crds variant with zero CRDs, source and dependency locks including the disabled bitwarden-sdk-server dependency, admission webhook observation gates, webhook Secret/cert-controller observation, cluster RBAC gates, and deterministic cub installer package/setup proof.

The fifth promoted row is:

argo-cd/argo-cd@9.5.15

It proves the GitOps controller chart shape: a default variant with three CRDs, a no-crds variant with zero CRDs, source and dependency locks including the disabled redis-ha dependency, Helm hook lifecycle gates, generated Secret ownership gates, StatefulSet policy, GitOps handoff policy, cluster RBAC gates, and deterministic cub installer package/setup proof.

The sixth promoted row is:

bitnami/postgresql@18.6.7

It proves the generated-credential stateful chart shape: a generated-passwords variant that binds auth.postgresPassword, an existing-secret variant that declares target Secret postgresql/postgresql-auth, source and dependency locks including the Bitnami common dependency, hook lifecycle gates, StatefulSet/PVC policy, extension slot review, and deterministic cub installer package/setup proof.

The seventh promoted row is:

bitnami/rabbitmq@16.0.14

It proves the generated-credential stateful chart shape with clustering material: a generated-passwords variant that binds auth.password and auth.erlangCookie, an existing-secret variant that declares target Secrets rabbitmq/rabbitmq-auth and rabbitmq/rabbitmq-erlang-cookie, source and dependency locks including the Bitnami common dependency, StatefulSet/PVC and clustering policy, extension-slot review, and deterministic cub installer package/setup proof.

The eighth promoted row is:

prometheus-community/kube-prometheus-stack@85.3.3

It proves the large umbrella monitoring stack shape: a default variant that binds Grafana admin password and renders 10 Prometheus Operator CRDs, a no-crds variant that omits CRDs, source and dependency locks for the CRD, kube-state-metrics, node-exporter, Grafana, and windows-exporter dependencies, admission webhook observation gates, cluster RBAC gates, dashboard ConfigMap normalization, extension-slot review, and deterministic cub installer package/setup proof.

The ninth promoted row is:

grafana/loki@7.0.0

It proves the blocked-default storage chart shape: a default render blocker for missing loki.storage.bucketNames.chunks, single-binary-filesystem and simple-scalable-minio variants, source and dependency locks for MinIO, grafana-agent-operator, and rollout-operator, storage/schema binding, MinIO object-store fixture, cluster RBAC, StatefulSet/PVC policy, Loki ConfigMap normalization, extension-slot review, and deterministic cub installer package/setup proof.

The tenth promoted row is:

longhorn/longhorn@1.11.2

It proves the storage control-plane chart shape: default and ui-ingress variants, 22 Longhorn CRDs, pre-upgrade hook policy, admission/recovery observation, cluster RBAC gates, privileged storage workload policy, StorageClass/default-setting policy, UI ingress policy, and deterministic cub installer package/setup proof.

The eleventh promoted row is:

bitnami/mysql@14.0.3

It proves the generated-credential stateful chart shape for MySQL: generated-passwords and existing-secret variants, generated fact binding for root/user/replication passwords, target Secret binding for mysql/mysql-auth, Bitnami common dependency lock, hook lifecycle policy, StatefulSet/PVC policy, extension-slot review, and deterministic cub installer package/setup proof.

The twelfth promoted row is:

grafana/grafana@10.5.15

It proves the dashboard control-plane app chart shape: a chart-deprecation marker in the source lock, generated-passwords and existing-secret-ingress variants, generated Grafana admin credential binding, target Secret binding for grafana/grafana-admin, UI ingress policy, cluster RBAC review, deployment/provisioning/sidecar/Secret extension gates, and deterministic cub installer package/setup proof.

The thirteenth full proof row is:

hashicorp/vault@0.32.0

It proves the security-sensitive stateful control-plane chart shape: 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, cluster RBAC review, Secret/env extension gates, and deterministic cub installer package/setup proof.

The fourteenth full proof row is:

secrets-store-csi-driver/secrets-store-csi-driver@1.6.0

It proves the node-level CSI driver chart shape: 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, and deterministic cub installer package/setup proof.

The fifteenth full proof row is:

prometheus-community/prometheus@29.8.0

It proves the bundled monitoring stack chart shape: default and server-only-ephemeral variants, Alertmanager/exporter/pushgateway component selection, Prometheus scrape ConfigMap review, server PVC/storage retention policy, cluster RBAC review, remote read/write and exposure extension slots, and deterministic cub installer package/setup proof.

The sixteenth full proof row is:

bitnami/mongodb@19.0.7

It proves the stateful database topology chart shape: 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, and deterministic cub installer package/setup proof.

The seventeenth full proof row is:

bitnami/nginx@24.0.2

It proves the simple web-service chart shape and shows that even a small public chart can hide Helm pain: default self-signed TLS generation is controlled, http-clusterip disables generated TLS for a deterministic internal service, existing-tls-ingress declares backend and ingress TLS Secrets, and the proof records ingress exposure, NetworkPolicy, PDB, service exposure, static-site supply-chain slots, metrics add-ons, raw/template extension slots, and deterministic cub installer package/setup proof.

The eighteenth full proof row is:

grafana/tempo@1.24.4

It proves the observability storage chart shape: the literal chart deprecation is recorded, local-persistent captures local WAL/traces PVC settings, s3-query-observability moves S3 credentials to a target Secret and adds query ingress, NetworkPolicy, and ServiceMonitor, and the proof records the required Prometheus Operator API capability, StatefulSet/headless-Service runtime risk, raw/template extension slots, and deterministic cub installer package/setup proof.

The nineteenth full proof row is:

hashicorp/consul@2.0.0

It completes the 20-chart target with the service-mesh/control-plane shape: default-control-plane records the chart-default Consul posture, and secure-mesh-existing-secrets enables TLS, ACLs, gossip encryption, mesh gateways, and UI ingress using declared target Secrets. The proof records 28 CRDs, cluster RBAC, injector webhooks, lifecycle Jobs, rendered Secrets, StatefulSet storage, gateway topology, raw/template extension slots, and deterministic cub installer package/setup proof.

The Redis proof now contains the first complete proof slice. Remaining Redis day-2 extensions still include:

upgrade-simulation-receipt.yaml
rollback-simulation-receipt.yaml

Current Redis package proof status:

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.

What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.

packages/bitnami/redis/25.5.3 exists
cub installer package is byte-deterministic across two local runs
cub installer setup --base default matches Helm semantically, plus Namespace
cub installer setup --base reuse-existing-secret matches Helm semantically, plus Namespace
Kubara spaces helm-redis-default and helm-redis-reuse-existing-secret exist
ConfigHub hosted OCI returns unit-level manifests for representative StatefulSets

Observation is not optional for the workerless claim. A missing or stale observation receipt must be visible as "unknown/stale", not implied live truth.

The simple UX proof artifacts now exist:

demo-script.md
cli-transcript.txt
ux-acceptance.md

They should continue to show:

• commands a Helm user can run without learning the full model first
• the immediate value returned by each command
• where the user sees rendered objects, diffs, scans, gates, and next action
• where receipts live for proof after the simple path succeeds
• why the path is easier, safer, and correct versus Helm

Each chart readiness artifact must be easy to read. The first view should be a readiness card, not an audit dump:

Chart
Status
Variants
Objects
Helm match
Scan/gate result
Publish readiness
Risks handled
Needs decision
Proof links

The order is deliberate: can I use this safely, why, then raw receipts.

20 / 50 / 100 / 500 Proof Ladder

For 20 charts, prove depth with 20 full public-chart proof slices:

• include Redis as the first full proof;
• promote rows from data/adversarial10/ into chart proof folders;
• add enough additional public chart rows to reach 20;
• require recipe and package directories for every chart;
• require at least the default variant per chart;
• require at least one second meaningful variant where relevant;
• run deterministic render checks;
• run cub installer package and cub installer setup;
• produce a Helm equivalence report;
• produce scan receipt and install gate per rendered revision;
• include explicit CRD-heavy charts in the set;
• choose the adversarial set from known-adversarial-charts.md;
• make every generated spreadsheet row traceable to receipts, not just source scans.

The concrete target list and acceptance contract live in top20-full-proof-target.md.

For 50 charts, prove breadth without losing clarity:

• repeat the same readiness-card output
• include more public chart categories
• keep every row traceable to artifacts and receipts

For 100 charts, prove automation:

• run the same HelmPlan journey without bespoke manual analysis
• classify every chart as viable, viable-with-control-points, blocked, or unknown
• require every blocked chart to name the blocking control point
• generate proof-readiness spreadsheets from artifacts

For 500 charts, prove corpus scale:

• source locks and dependency locks
• HelmPlan pain reports
• control-point classifications
• recipe viability
• rendered variant revisions where viable
• bulk scan/gate results
• aggregate failure catalog

At-Scale Adversarial Verification

ConfigHub should verify at scale by running chart proof jobs across a matrix of:

• chart versions
• Kubernetes capability profiles
• default, HA, TLS, reuse-existing-secret, restricted, and provider variants
• target fact value profiles
• generated secret/cert/time policies
• hooks, CRDs, webhooks, RBAC, raw manifests, and tpl controls
• scanner policy bundles
• upgrade and rollback paths

Each run should produce:

HelmPlan result
Recipe result
VariantRevision result
HelmEquivalenceReport
RenderReceipt
ScanReceipt
InstallGate
OCIArtifactReceipt
ApplyReceipt only when the run explicitly uses a direct-apply path
ObservationReceipt when a live target is involved

Adversarial tests should deliberately include charts that use lookup, random functions, hooks, CRDs, webhooks, raw manifest slots, non-exact dependencies, schema gaps, unknown values, and upgrade-sensitive state.

P0 Before Scaling

The authoritative issue list is docs/planning/issue-backlog.md. The following open P0s must be complete or deliberately reclassified before the 20/100/500 proof can be believable:

• #24 Artifact schema and receipt verifier. The current verifier is real but not complete.
• #4 HelmPlan pain report for each analyzed chart. data/adversarial10/ is the first generated slice.
• #5 EffectiveValues@sha with value precedence and provenance.
• #6 Dead, unknown, or ignored value detection where possible.
• #7 Value-to-rendered-field explanation for key settings.
• #29 Capability profile catalog for finite, digest-bound capability profiles.
• #28 Generated fact receipt schema for passwords, certs, UUIDs, and time values.
• #30 Upgrade and rollback simulation receipts.
• #27 Observation freshness SLO for workerless proof.
• #25 Top-N adversarial run harness that can produce generated spreadsheets from artifacts. The 10-chart foundation exists but does not yet close the issue.

Acceptance Standard

A skeptical reviewer should be able to choose any row in the new spreadsheet and follow it to:

chart source
source lock
recipe candidate
variant
variant revision
rendered object digest
scan/gate result
receipt
next action or blocker

If the row cannot be traced to artifacts and receipts, it is not proof.

Separately, a skeptical Helm user should be able to run the happy-path demo and say within five minutes:

I see exactly what will be installed.
I see what changed.
I see whether it passed checks.
I can publish it safely for GitOps pickup.
I did not have to learn a new platform ceremony first.

If that does not happen, the proof is too complex even if the artifacts are technically complete.

No-go criteria:

• the user must learn the full ConfigHub object model before first value
• ConfigHub output differs from Helm without an explanation
• scan/gate/receipt concepts block the first useful result instead of helping it
• the next action is less clear than Helm's next action
• rollback, promotion, or publication feels riskier than the Helm/GitOps path