UNOFFICIAL/EXPERIMENTAL
Read it as chart-by-chart readiness, not as a blanket support claim.
What A User Should Take From It
The top-100 corpus answers three different questions:
Can I try this from the public catalog?
Start with the 20 top-20 catalog entries.
Is there already a maintained recipe/package proof?
Yes, for all 100 charts in this corpus.
Is this chart ready to be promoted as a public catalog offer?
Only after useful variants, selected live lanes, and any named limitations
have been reviewed.The top-100 data is most useful for choosing the next chart to promote. It is not a promise that every chart is already a polished user offer.
For a Helm-user first-read, use Top-100 Status, In Plain English. It projects this readiness data into five user-facing groups and explains what a user must provide before trying each chart.
If you already know the chart name, use the generated Chart Use Guide. It gives one short answer per top-100 chart: use the public catalog now, promote after review, design a better base variant first, or decide a named limitation before promotion.
Current Shape
100 charts have maintained recipe/package proof artifacts.
20 charts are public top-20 catalog entries with at least one live evidence lane.
80 charts are proof-grade but not catalog-supported yet.
54 charts already have more than one base variant.
46 charts are still default-only.
25 charts have at least one named hard gap for a recommended capability.The generated source of truth is:
The shortest chart-name lookup is:
The compact next80 work queue is:
The strict coverage work queue is:
The first strict promotion-review wave is:
Hook and lifecycle work is tracked separately from render proof:
The spreadsheet-friendly CSV is:
The Four Buckets
| Bucket | Meaning | User answer |
|---|---|---|
try-from-public-catalog | A top-20 catalog entry exists. At least one base has live evidence. | Good demo/catalog candidate. Check the exact base before claiming GitOps, live parity, or production support. |
promote-after-review | Recipe/package proof and useful variants exist, but catalog review is not done. | Good next promotion candidate. Needs catalog review and selected live lanes. |
needs-useful-variant | The default render proves the mechanism, but the chart does not yet have a compelling user-shaped base. | Do not present it as a good catalog offer yet. Add realistic variants first. |
limitation-decision-first | A named capability gap affects the recommended path. | Decide whether to support, disclose, or defer the capability before promotion. |
The user-facing status page uses the same source data with one extra split: promote-after-review becomes either works-with-target-prerequisites or works-with-operator-review, depending on whether the next obstacle is mostly a user-provided target input or an operator review.
What The Counts Mean
Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.
render-parity means regular Helm and cub installer setup produce equivalent Kubernetes objects under recorded inputs.
in-ConfigHub, local_live, gitops_live, and live_parity are separate lanes. A chart can be proof-grade with render parity while still missing live or GitOps evidence for some bases.
hard_gap does not mean the chart is broken. It means a useful capability is not yet handled as a supported path. Common examples are:
existing-secret path not exposed by the chart
HA path needs a separate curated variant
CRDs cannot be cleanly disabled
the chart's topology belongs to a different chart or product decisionRead hard gaps together with the adoption bucket. A top-20 catalog chart can still be a good public example while carrying a hard gap for another path, such as HA or existing-secret support. A limitation-decision-first row is stricter: the named gap affects the next promotion path and needs a support, disclosure, or deferral decision first.
How To Use It
Start with the generated summary when choosing what to work on next:
Use the CSV when comparing many charts:
Start with the workability column when you want the simple answer: try now from the public catalog, use as proof pending catalog review, add a real user-shaped variant first, or make a limitation decision before promotion.
For the next80 specifically, use the generated action queue:
| Question | Use |
|---|---|
| Which next80 charts are closest to catalog promotion? | next80-queues.csv, queue promotion-review |
| Which next80 charts need a named limitation decision? | next80-queues.csv, queue limitation-review |
| Which next80 charts need a better base variant first? | next80-queues.csv, queue user-shaped-variant |
That queue also includes top-500 rank, source features, package path, and the per-chart Helm pain report so the first review does not start from a blank page.
Then drill down:
| Question | Use |
|---|---|
| What exact bases exist for this chart? | recipes/<repo>/<chart>/<version>/CATALOG.md |
| Which lanes pass for each base? | base-outcomes.csv |
| Which chart features or gaps matter? | feature-outcomes.csv |
| Which hook routes still need lifecycle receipts? | Hook Route Candidates, Hook Lifecycle Queue, and Reviewed Source Hook Routes |
| Which charts are next for strict promotion review? | Top-100 Promotion Wave |
| Which older variant-design worksheet can inform future bases? | catalog-promotion-wave2 |
| Which production decision is still missing? | Production Next Actions |
Promotion Rule
A top-100 chart should not move from proof-grade to catalog-supported just because it renders.
Promotion should show:
useful base variants
render parity
scan/gate receipts
clear target facts and lifecycle routes
at least one selected live lane where appropriate
plain user guidance for when to use each variantThat is how the top-100 becomes a useful catalog rather than a spreadsheet of successful renders.