UNOFFICIAL/EXPERIMENTAL
You do not need every document on a first pass. Stop after step 6 if you only want the practical user flow.
First 10 Minutes
Use this route when you are trying to understand the product quickly.
| Question | Open | Why |
|---|---|---|
| What is this offering? | Offering | The Helm user value story without the full proof corpus. |
| Which path should I take? | Choose Your Path | Direct render, one-shot upload, public catalog, and ConfigHub-managed operations. |
| Can I try it now? | Try Now | A short public package OCI path and the serious-chart check. |
| What package do I pull? | Installer Package OCI Refs | The public oci:// refs for catalog packages, and how they differ from ConfigHub delivery OCI. |
| Who signed this package? | Verifying Catalog Package Signatures | Check the publisher, immutable manifest digest, and signed package annotations with cosign. |
| How do Helm, AICR, cub installer, promotions, and fleet examples fit together? | Config Catalog Demonstrations | The maintained status of each source path and the five ConfigHub App examples. |
| What should I see after each command? | Expected Results And Clusters | Output snippets, cluster choices, bring-your-own Kubernetes, cub cluster up, and optional npm proof checks. |
| How do chart presets relate to Helm values? | Helm Chart Presets And Values | Why the catalog offers useful chart-specific presets instead of claiming every values combination. |
| How do I verify a claim? | Verification | The landing page for npm proof commands, user-side checks, committed receipts, and live lanes. |
| What can AI safely help with? | AI-Assisted Helm Changes | How AI proposals stay bounded by diff, gate, approval, delivery, and observation. |
| What if my chart breaks? | Broken Chart Triage | A practical route from failure to render gap, target prerequisite, lifecycle route, image issue, runtime issue, or model gap. |
| What known gaps should I trust you to show? | Known Gaps We Surface | Current watch findings such as credentials, prune, CRD ordering, drift coverage, and SSA conflict UX. |
| What is the whole catalog status? | Master matrix | One product/status view across chart versions, bases, variants, lanes, gaps, and next actions. |
| What hard questions should I ask? | Hard Questions | Hooks, upgrades, overlays, target prerequisites, false-green sync, and refusal boundaries. |
| What can be built on the held data? | App-readiness proof | A read-only RBAC app over already-rendered objects, showing why explicit config becomes useful data. |
The Choose Your Path page is the quickest way to decide between direct render, one-shot upload, public catalog packages, and ConfigHub-managed operations. The Tutorial Sequence also links each stage to a companion UX proposal. Those proposal files are product sketches, not extra required reading for the first pass.
If your first question is "why is this more than a one-shot upload or GitOps import?", read Why This Exists.
| Step | File | Read It For |
|---|---|---|
| 1 | ConfigHub Helm Catalog Offering | The public value story in one short read. |
| 2 | Generative GitOps Fit | How this repo maps to the broader generated-config and AI/GitOps thesis. |
| 2a | Reverse-Reconcile Design | The live-to-desired frontier: what is machine-checkable today and what requires a new cub write-back capability. |
| 2b | cub-scout Diff Design | The field-level desired-vs-live frontier for dry-run and drift across Argo, Flux, or cub-direct delivery. |
| 2c | App-readiness proof | A small read-app over rendered RBAC that shows how held config becomes queryable product data. |
| 2d | Config Catalog Demonstrations | How Helm, AICR, cub installer, promotions, Kubara, Sveltos, and the five Apps enter one base-variant and policy model. |
| 2e | Kubara Platform Example | A real Kubara generation, the rendered Argo CD base, the CRDs and hook work around it, and the checks that have not run yet. |
| 3 | Try Now | The shortest Redis and kube-prometheus-stack paths. |
| 3a | Expected Results And Clusters | What users should see after each step, what cluster they need, and which npm proof checks are optional. |
| 4 | Choose Your Path | Which path fits: direct render, one-shot upload, public catalog, or ConfigHub operations. |
| 5 | What You Get | The product model in one short read. |
| 6 | Helm Chart Presets And Values | Why public chart presets are the useful support surface, how they map to repo base variants, and why this is not an every-values-combination claim. |
| 7 | Installer Package OCI Refs | The public package refs users pull with cub installer setup --pull oci://..., plus the difference between package OCI and delivery OCI. |
| 8 | Helm Render Intents | The compact two-layer model: base variants for render, managed variants after render, with the full proof chain underneath. |
| 9 | Verification | The landing page for npm proof commands, committed evidence, fresh live lanes, and render-record-route. |
| 10 | Choosing Commands | When to use helm template, cub installer, cub variant upload, cub variant create, and repo verifiers. |
| 11 | AI-Assisted Helm Changes | How AI can propose changes without bypassing diffs, gates, approvals, delivery, or observation. |
| 12 | Broken Chart Triage | How to turn a broken chart into a named render, target, lifecycle, image, runtime, or model finding. |
| 13 | Known Gaps We Surface | Why current watch findings are visible and how to read them. |
| 14 | Outcomes And Tests | What the repo promises, which tests prove each promise, and where the CSVs live. |
| 15 | Helm Pain Points | Which Helm pains are tracked generally and per chart. |
| 16 | Helm Upgrade Crash Example | How an opaque Helm upgrade becomes staged, reviewed, rehearsed, gated, and observed. |
| 17 | Tutorial Sequence | A short show-and-tell path with commands, checks, and expected results. |
| 18 | Current Proof Status | What is proven now and which generated summaries are authoritative. |
| 19 | Hard Questions Before You Trust The Catalog | Short answers for skeptical Helm users: hooks, upgrades, overlays, false-green sync, free versus managed, and how to challenge the model. |
| 20 | What We Refuse To Claim | Why watchlist rows and blocked strict witnesses are part of the trust model. |
| 21 | Why Synced Is Not Working | Why object presence or GitOps sync can still miss broken runtime state. |
| 22 | Target Prerequisites | Why hard charts need explicit CRDs, Secrets, lifecycle checks, and target facts beyond YAML parity. |
| 23 | Why This Does Not Collapse | How hooks, quirks, config volume, and blocked rows stay visible instead of becoming hidden risk. |
| 24 | Verify It Yourself | Commands for checking corpus files, rendered installs, parity receipts, and cub-scout receipts. |
| 25 | Production Support Decisions | How a review-ready chart becomes production-supported for one target scope. |
| 26 | Chain Of Proof | Which tool proves which boundary: render, ConfigHub desired state, delivery, and live observation. |
| 27 | Top-100 Readiness | How to read the top-100 corpus: public catalog, promotion candidates, default-only rows, and limitation decisions. |
| 28 | Chart Use Guide | One generated answer per top-100 chart: use now, promote, improve the base, or decide a limitation first. |
| 29 | Top-100 Status | Plain-English answers: what works today, what needs prerequisites or review, and how it differs from plain Helm. |
| 30 | Verification Lanes | What each proof lane means and what it does not prove. |
| 31 | Live Parity | How to read pass, watch, blocked, and rerun rows in the live Helm-vs-ConfigHub lanes. |
| 32 | Large ConfigHub Operations | How to watch a 100+ Unit upload/apply/GitOps path without collapsing it into a vague hang. |
| 33 | How The Harness Works | The project lifecycle and the value of proofs, uploads, variants, and receipts. |
| 34 | Creating Variants | The base variant versus derived ConfigHub variant distinction. |
| 35 | cub Variant Command Surface | The current cub variant create syntax and what is not a current variant command. |
| 36 | Choosing Base Variants, Derived Variants, And Delivery Changes | The routing rule before OCI or GitOps delivery. |
| 37 | Adopting Existing Apps | How Argo, Flux, KRM, rendered manifests, and existing apps enter the ConfigHub model. |
| 38 | Custom Overlay Example | A plain ExternalDNS example for wrapper charts, customer values, target facts, and Creator flow. |
| 39 | Prometheus Promotion Example | A concrete promotion example that keeps the Helm install shape stable. |
| 40 | Prometheus High-Fanout Example | Why a small Helm base choice can affect many objects and target prerequisites. |
| 41 | Serious Chart Proof | The concise kube-prometheus-stack proof path: what passes, what is scoped, and what remains. |
| 42 | Extension Slots | How raw manifests, tpl snippets, sidecars, config blocks, and add-on slots are routed. |
| 43 | NGINX Configuration Files | How NGINX serverBlock, streamServerBlock, extraDeploy, and config-file checks fit the variant model. |
| 44 | Introduction To The Harness | The deeper recipe-generation workflow and the table for where Helm pieces belong. |
| 45 | Product Support Tiers | Which scenarios fit public catalog, managed import, or commercial support. |
| 46 | Maintenance SLA | How catalog entries are refreshed, patched, and supported. |
| 47 | Hook Lifecycle Strategy | Why Helm hooks need explicit lifecycle routes and receipts. |
| 48 | Inspect An OCI Package | Identify an OCI package, resolve its digest, and list the exact Kubernetes objects and lifecycle clues before choosing what to do with it. |
| 49 | Change An OCI Package | Change one named field, keep the source and check records, and build a new OCI without a ConfigHub account or server. |
| 50 | Your App To Live | Continue from plain Kubernetes YAML into ConfigHub variants, releases, Argo CD delivery, and promotion. |
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.
Detailed doctrine and historical design material now lives under docs/reference so it does not look like the first-run user flow. Use it when you need the deeper model:
| Reference | Read It For |
|---|---|
| Seven-Stage Helm Lifecycle | The doctrine for render parity and for routing hooks, CRDs, target facts, generated values, overlays, GitOps, and observations. |
| Chain Of Proof | The user-facing boundary map for render proof, ConfigHub proof, delivery proof, and live proof. |
| Direct Cub Helm Model | Historical and plugin-specific reference for the separate cub-helm command surface; the public site uses Helm, cub installer, and cub variant upload as its front doors. |
| Customization Algorithm | The detailed routing algorithm for values, overlays, wrapper charts, and post-render variants. |
| Catalog Doctrine | The catalog model for defaults, parameterized bases, standard forks, and derived fills. |
| Customization Decision Tree | The design-level decision tree behind the customization flow. |
| Fork Vocabulary | Canonical naming for base variant dimensions. |
| Per-Chart Recipes | The recommended target recipe and variant surface for top-20 charts. |
| Complete Corresponding Model | The completeness contract behind the larger ConfigHub replaces-Helm claim. |
The order is intentionally user-first:
try it
understand the proof path
create variants
route customizations
read worked examples
then inspect reference doctrine only when needed