Top 100 Full Proof Target · Config Workshop

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.

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.

The current public proof surface is 100 public Helm charts:

20 bespoke proofs with chart-specific variants and mitigations;
80 generated full proofs with the same minimum artifact contract.

Current generated status:

recipe/package proof artifacts: 100 / 100
supported at Level 2:           100 / 100
variant-rich:                    54 / 100
default-only:                    46 / 100
hard gap in chart facts:         25 / 100

Level-2 support means the chart has a render-equivalent, readable, usable, verifiable, honestly scoped model with quirks accounted for. It does not mean every useful base variant has already been built, and it does not mean production support.

The next-80 lane is generated from:

data/next80-full-proofs/corpus.yaml

Generated outputs:

data/next80-full-proofs/proof-index.csv
data/next80-full-proofs/summary.md
recipes/<repo>/<chart>/<version>/
packages/<repo>/<chart>/<version>/

Every next-80 chart must prove:

pinned chart source and dependency closure;
deterministic regular Helm render under Kubernetes 1.30.0;
a Recipe, HelmPlan, ChartDossier, ValueModel, and ControlPoints file;
a default Variant and digest-bound VariantRevision;
rendered release objects and object inventory;
render, Helm-equivalence, scan, install-gate, and installer-package receipts;
deterministic cub installer package output;
cub installer setup output semantically matching regular Helm output, aside from the allowed Namespace support object.

Verification:

npm run next80:verify
npm run next80:verify:packages
npm run verify

The lane is intentionally strict. Charts that render with Helm but change semantics through the installer/Kustomize round trip do not count as passing full proofs. They belong in the adversarial backlog until the difference is classified and mitigated.

The current corpus has no known package-equivalence hard gap. The former six #124 failures were fixed by regenerating the affected packages without the post-render namespace transformer and preserving target-facts collectors where needed.

Currentness And Promotion

The top-100 proof surface has two different maturity levels:

top-20: catalog-supported public entries with bespoke variants and live proof
next-80: generated proof-grade artifacts

The next-80 entries are not all default-only anymore. Some already have basic machine-generated variants such as default/no-crds. Promotion work should focus on useful user-shaped variants and production dispositions, not merely on increasing the variant count.

The top-20 set now has a latest-version refresh lane:

data/latest-top20-refresh/
npm run top20:latest-refresh

That lane should be applied to the top-100 only after the seven current top-20 update candidates are refreshed. Otherwise the repo would produce a larger but less trustworthy matrix.

The top-100 update sequence is:

Keep the top-20 catalog-supported rows current and live-tested.
Promote a small wave of next-80 charts into bespoke, user-shaped variants.
For each promoted chart, add catalog status, production disposition, ConfigHub proof receipts, and live e2e receipts.
Only then add latest-version currentness columns for the broader top-100.

Generated next-80 rows remain valuable, but they are not the same as catalog-supported entries until a human/product review has selected the variants a real Helm user would choose.