Repo Consistency Review · 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.

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

Verdict

The repo now has a clearer shape:

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.

README -> current mission and simple UX claim
docs/ -> doctrine, harness introduction, maintenance, customization, promotion review
recipes/ -> chart proof artifacts
packages/ -> executable cub installer packages
data/ -> generated review outputs
data/top500-catalog-analysis/ -> current top-500 proof index and source-scan input

The old top-20 render-and-vendor payload is removed from the active tree. The current proof path is recipes/ plus packages/, verified against regular Helm renders and cub installer.

Current Logical Flow

Pick a public Helm chart and version.
Render it with regular Helm under pinned inputs.
Capture a HelmPlan, ChartDossier, source/dependency locks, control points, and value model.
Create one or more install variants.
Store immutable variant revisions with rendered release objects.
Run scans and install gates against the exact rendered objects.
Build an executable cub installer package under packages/.
Compare cub installer setup output with the regular Helm baseline.
Generate catalog-promotion review output.
Promote only after human/product review assigns explicit catalog status.

What Is Consistent

The public claim is stable: correct variants, safe operations, immediate proof.
The written doctrine now favors executable installer, cub, and ConfigHub capabilities over documentation-only mitigations whenever those capabilities exist, fit the chart behavior, and improve simplicity, safety, or proof.
Redis, the promoted top-20 recipes, and the next-80 recipes all use current packages/ executable fixtures.
npm run verify checks current artifact chains instead of obsolete archive receipts.
The catalog-promotion review separates machine proof from catalog support.

What Still Needs Tightening

The old top-500 matrix should be recalculated in the new catalog-proof shape.
Every chart should get an explicit catalog-status.yaml; support status should not be inferred from proof tier.
Redis should be the first deliberate catalog-supported entry, with warning gates and production dispositions stated plainly.
The repo needs an upgrade/legacy-patch review lane for old chart versions.
The README should continue to favor short user commands and keep internal nouns in the docs, not the happy path.

Current Review Boundary

Do not use the removed top-20 archive or the old matrix to judge the current plan. They explain how we learned the control points. The current plan is judged by current recipes, current packages, current receipts, generated reviews, and repeatable Helm-vs-cub installer comparisons.