# ConfigHub Workshop (helm-expt)

> A public configuration catalog and test workshop. It retains exact source records, Kubernetes objects, lifecycle work, checks, and evidence for Helm, AICR, Timoni, OCI, YAML, and ConfigHub paths.

- [Configs](https://confighub.github.io/helm-expt/site/configs.json): the Configs section, one row per Catalog entry with its format, version, base, object count, flattening verdict and listing URL. Schema: https://confighub.github.io/helm-expt/site/configs.schema.json.
- [Stacks](https://confighub.github.io/helm-expt/site/stacks.json): the Stacks section, one row per shipped stack with its parts, whether each part was checked, and the cub stack check command to try it. Schema: https://confighub.github.io/helm-expt/site/stacks.schema.json.
- [Apps](https://confighub.github.io/helm-expt/site/apps.json): the Apps section, one row per worked example app with its delivery, its default-branch address and the commit it was last checked at. Schema: https://confighub.github.io/helm-expt/site/apps.schema.json.
- [Plugins](https://confighub.github.io/helm-expt/site/plugins.json): the Plugins section, one row per public cub plugin with its state, latest release and install command. Schema: https://confighub.github.io/helm-expt/site/plugins.schema.json.
- [Guides](https://confighub.github.io/helm-expt/site/guides.json): the Guides section, one row per known path an agent walks with a person, grouped by where the reader starts, the five journeys first. Schema: https://confighub.github.io/helm-expt/site/guides.schema.json.
- [ConfigHub Workshop agent skill](https://confighub.github.io/helm-expt/site/.well-known/agent-skills/config-workshop/SKILL.md): installable instructions for resolving exact Catalog entries, checking user configuration, reviewing promotions, and keeping checks and limits visible.
- [Deep Dives](https://confighub.github.io/helm-expt/site/guides.html#guides-deep-dives): longer staged journeys; existing Guides remain in their topic groups.
- [AI fleet repair and prevention](https://confighub.github.io/helm-expt/site/ai-chaos-in-production.html): recorded kind-fleet demonstration, agent refusal and a separate deterministic parity check. Read the [pinned demo README](https://github.com/confighub/sveltos-confighub/blob/9838de43597e0ea3946e1cebb489e8ae92cd195c/demo/README.md) and [agent contract](https://github.com/confighub/sveltos-confighub/blob/9838de43597e0ea3946e1cebb489e8ae92cd195c/demo/agents/README.md) before execution; requires dedicated resources and approval.
- [Use ConfigHub Workshop with an AI agent](https://confighub.github.io/helm-expt/site/ai.html): installation, realistic tasks, machine records, and the boundary between a proposed change and a reviewed result.
- [Catalog JSON](https://confighub.github.io/helm-expt/site/catalog.json): machine-readable summary of the catalog: components, retained versions, packaged configurations, counts, and the repo data paths they come from.
- [Change feed](https://confighub.github.io/helm-expt/site/changes.json): exact chart versions, aliases, package digests, declared coverage, canonical pages, and evidence URLs.
- [Change feed schema](https://confighub.github.io/helm-expt/site/changes.schema.json): the versioned JSON Schema for changes.json.
- [Component Catalog](https://confighub.github.io/helm-expt/site/charts/): 112 components, all 139 retained package versions, their packaged configurations, and version-specific publication or readiness evidence.
- [Master catalog matrix](https://confighub.github.io/helm-expt/site/matrix.html): one row per chart, version, and base with lane dispositions, hooks, quirks, and next actions.
- [Generated at](https://confighub.github.io/helm-expt/site/generated-at.txt): the timestamp of the last site generation.
- [Official ConfigHub tutorial](https://docs.confighub.com/get-started/tutorial/): the canonical product journey from one component through release, change, production, and promotion.
- [Try Redis](https://confighub.github.io/helm-expt/site/try.html): render and inspect one public Redis configuration with no ConfigHub Server or account.
- [Deploy one thing, and look before you do](https://confighub.github.io/helm-expt/site/deploy-one-thing.html): follow one Catalog entry, bitnami-nginx-24-0-2-http-clusterip, from its exact objects to a release on a local kind cluster with Argo CD. The commands are that entry's nextSteps, at https://confighub.github.io/helm-expt/site/listings/bitnami-nginx-24-0-2-http-clusterip.json. The end state shown is one dated run of 2026-10-08, which is a log and no receipt.
- [Try AICR](https://confighub.github.io/helm-expt/site/try-aicr.html): anonymously pull one retained AICR configuration, verify the seven-file CPU-starter selection, and write a local OCI without a cluster or GPU.
- [Timoni Redis source entry](https://confighub.github.io/helm-expt/site/d/examples/timoni/redis-8-10-1/README.html): one immutable module, its typed options, seven exact objects, master-first lifecycle work, and current test limits.
- [Check my config](https://confighub.github.io/helm-expt/site/ask.html): investigate a new chart, values set, AICR recipe, OCI package, Kubernetes object set, or existing deployment; compare exact objects; and retain a review record.
- [Run shared local checks](https://confighub.github.io/helm-expt/site/ask.html#check-command): after a source tool has written Kubernetes YAML, install the released plugin and run `cub check --format json --output cub-check.json ./rendered`. It is local and advisory; it does not upload, apply, or prove target behavior.
- [Promote my config](https://confighub.github.io/helm-expt/site/promote.html): compare current and proposed Kubernetes objects in the browser, retain their hashes, and see which tests remain before staging or production.
- [Configuration review schema](https://confighub.github.io/helm-expt/site/review.schema.json): the versioned record linking a question, source, object hashes, comparison, checks, limits, and recommendation.
- [Complete workshop result schema](https://confighub.github.io/helm-expt/site/workshop-result.schema.json): one browser-local bundle containing the exact files, their hashes, completed checks, omitted checks, and local or managed next steps.
- [CI report schema](https://confighub.github.io/helm-expt/site/workshop-ci-report.schema.json): the bounded Markdown/JSON report derived from WorkshopResult for local CI, pull-request comments, and AI tools.
- [Promotion review schema](https://confighub.github.io/helm-expt/site/promotion-review.schema.json): the record linking current and proposed objects, source-aware field changes, lifecycle work, exact target results, and checks that have not run.
- [Configuration decision schema](https://confighub.github.io/helm-expt/site/configuration-decision.schema.json): the source-neutral record for accepted fixes, rejected findings, scoped exceptions, managed validation, approvals, promotion, delivery, and authority boundaries.
- [Completed NGINX decision chain](https://github.com/confighub/helm-expt/blob/main/data/config-review-decision-chain/summary.md): six accepted fixes, one narrow exception, a retained ConfigHub decision Unit, development-to-staging promotion, and two Argo CD test results.
- [Base variant records](https://confighub.github.io/helm-expt/site/base-variant-records.json): source-neutral Catalog records joining each maintained base to its exact source, objects, OCI package, prerequisites, lifecycle routes, policy, and evidence status.
- [Catalog listing index](https://confighub.github.io/helm-expt/site/listings/index.json): every maintained entry with its listing URL, format, version, base, object count, exact digest, and flattening verdict.
- [Chart files](https://confighub.github.io/helm-expt/site/charts/nvidia-gpu-operator.json): one file for each Helm chart at charts/{chart-slug}.json, with its versions newest first, each base's listing, object file and SHA-256, one stored summary line for each version step, and the commands that compute any other diff. Schema: https://confighub.github.io/helm-expt/site/chart.schema.json.
- [Stack manifest schema](https://confighub.github.io/helm-expt/site/stack-manifest.schema.json): the existing Stack YAML contract used by `cub stack check`, with one explicit source per component, optional receipt discovery, planes and ordering.
- [Compose and check a stack](https://confighub.github.io/helm-expt/site/d/docs/reference/stack-manifest-contract.html): select parts, write a manifest, check it, and render locally. Roles are discovery hints, not readiness; an operator is not a running database.
- [Catalog listing schema](https://confighub.github.io/helm-expt/site/listing.schema.json): the versioned schema every per-listing file follows, whatever format the configuration came from.
- [One catalog listing](https://confighub.github.io/helm-expt/site/listings/bitnami-redis-25-5-3-default.json): the uniform listing for one entry, showing identity, source, flattened objects, OCI, variants, routing, lifecycle, assessment, and evidence in one file.
- [Why did Helm ignore my values?](https://confighub.github.io/helm-expt/site/why-did-helm-ignore-my-values.html): compare the render with and without each supplied values key. `cub config values <chart> --values my-values.yaml` does this for every key in one run, locally and with no account. Add `--repo <url>` for a chart in a Helm repository, and `--out values-report.json --render-out candidate.yaml` to keep the report and the rendered objects for the next change; the [Values Guide](https://confighub.github.io/helm-expt/site/d/docs/user/workshop-values-guide.html#check-your-own-chart) walks it on your own chart.
- [Did this chart version change?](https://confighub.github.io/helm-expt/site/did-this-chart-version-change.html): compare current package bytes with retained digests.
- [Did your Bitnami chart stop pulling?](https://confighub.github.io/helm-expt/site/did-your-bitnami-chart-stop-pulling.html): find a tested, verified successor for a Bitnami chart that no longer pulls anonymously.
- [See what a gpu-operator upgrade changes](https://confighub.github.io/helm-expt/site/d/docs/user/workshop-gpu-operator-upgrade-guide.html): render two versions of NVIDIA's public gpu-operator chart with `helm template` and compare them with `cub config diff`, for a version upgrade, a patch upgrade and a driver version change. The Catalog holds this chart, and [its chart page](https://confighub.github.io/helm-expt/site/charts/nvidia-gpu-operator.html) compares the retained versions.
- [Make a stack from Catalog entries](https://confighub.github.io/helm-expt/site/d/docs/user/workshop-stack-from-catalog-guide.html): compose NVIDIA's gpu-operator, nvsentinel and cluster-readiness-engine entries into one local stack with `cub stack compose`, check them together with `cub stack check`, and swap one entry. Nothing is applied or uploaded.
- [Review one change before it ships](https://confighub.github.io/helm-expt/site/d/docs/user/workshop-review-a-change-guide.html): take one image tag change to a small app with a dev and a prod environment. Part 1 lists the objects it affects in each environment with `kustomize build` and `cub config diff`, with no account. Parts 2 and 3 need an account. They propose the change in ConfigHub, show the gate refusing it, approve it, release it and read the record. One account wrote and approved the change in the recorded run.
- [Harden Argo CD before production](https://confighub.github.io/helm-expt/site/d/docs/user/workshop-argocd-hardening-guide.html): turn security advice into a checked values variant of the Catalog's argo-cd base with `cub config values`, compare it with `cub config diff`, and keep it as a variant with a staging and production path.
- [Deploy with Flux or Argo CD](https://confighub.github.io/helm-expt/site/deploy-with-flux-or-argo.html): render any catalog chart to a controller-native OCI with one command and no account.
- [Why do development and production differ?](https://confighub.github.io/helm-expt/site/why-do-dev-and-prod-differ.html): use related configurations and promotion history instead of copied values files.
- [Does the cluster match the approved configuration?](https://confighub.github.io/helm-expt/site/does-cluster-match-approved-config.html): compare desired and live objects within the field coverage named by the receipt.
- [Is my configuration right?](https://confighub.github.io/helm-expt/site/ask.html): the check flow, the FAQ, and the public question intake.
- [Detailed Redis walkthrough](https://confighub.github.io/helm-expt/site/redis-walkthrough.html): add Helm parity, Kubernetes, OCI, upgrade, promotion, delivery, and rollback.
- [Examples](https://confighub.github.io/helm-expt/site/testing.html): working examples for starting inputs, managed operations, platforms, and ConfigHub Apps.
- [Release, promote and roll back](https://confighub.github.io/helm-expt/site/how-it-works.html): the Guide to ConfigHub's four verbs, release by digest, promote, gate on an approval, and roll back. [How ConfigHub works](https://confighub.github.io/helm-expt/site/how-confighub-works.html) explains where they fit.
- [The five journeys](https://confighub.github.io/helm-expt/site/guides.html#guides-journeys): each starts from a problem a person brings to their agent, such as values that did nothing or fixes an assistant undid. Their rows lead guides.json.
- [Docs](https://confighub.github.io/helm-expt/site/docs.html): explanations by topic, including AI, GitOps and deployment, with general references under All technical references.
- [Catalog docs](https://confighub.github.io/helm-expt/site/catalog-docs.html): the complete per-entry demonstration and corpus documentation index.
- [All technical references](https://confighub.github.io/helm-expt/site/docs.html#all-references): the complete guide and evidence index, on Docs.
- [Continue with ConfigHub](https://confighub.github.io/helm-expt/site/confighub.html): sign up, follow the official tutorial, or read the ConfigHub blog.
- [Catalog](https://confighub.github.io/helm-expt/site/charts/index.html): every tested component and version, with its image, receipt, and the commands to check and verify it.
- [Kubara with ConfigHub](https://confighub.github.io/helm-expt/site/bring-kubara-into-confighub.html): manage your clusters' add-ons with Kubara, and approve every change to them in ConfigHub with cub kubara. Kubara calls the set a platform. Plan and render offline first, then apply, hand over, check and hand back, with each step's undo, the known limits and the live evidence.
- [Kubara six-step tutorial](https://confighub.github.io/helm-expt/site/d/docs/demo/kubara/adoption.html): the earlier path, before cub kubara: choose, generate, push to Git, create OCI, load the selected organization, and deploy applications while Argo CD remains the reconciler.
- [Repo README](https://github.com/confighub/helm-expt#readme): the proof corpus itself: recipes, receipts, verifiers, and how the evidence is produced.

## Machine contract

Use changes.json to resolve an exact chart and version. Its schema_version defines the field meanings.

Read coverage before citing a verdict. Missing coverage means we have not checked that claim.

Use the canonical chart URL and cite the evidence URLs. Page copy is a guide, while receipts hold the evidence.

Schema version 1 keeps existing field meanings stable. A breaking change uses a new major version.

The retention object is computed from committed package receipts, license evidence, and upstream-republish records. Normal catalog refreshes are additive. Do not infer that a version was checked before its oldest_publication_receipt_at value.

When upstream_republished_version_pairs is non-zero, use the linked drift evidence. A version string alone is not enough to identify those bytes.

Every maintained entry has one listing at listings/{id}.json, whatever format it came from. Build that URL from the entry id, so reading one entry never means downloading the catalog. listing.schema.json defines the fields and listingVersion pins their meanings.

A listing is a projection of the BaseVariantRecord it names in generatedFrom. That record decides catalog membership, and the listing repeats its digests rather than computing new ones.

Read a listing's coverage before citing a verdict. Only checked counts as evidence. A lane that reads not_declared was never declared, so it is not a pass, and a partial lane left a recorded caveat behind.

Every listing carries nextSteps, the same five steps in the same order: get the exact objects, compare with another version or base, upload it as a variant, deploy it, promote a change. Each step has a state read from that listing and the commands that entry supports. A step whose state is not-available carries no command and says what would unblock it. A command marked needsAccount contacts ConfigHub, and one marked writes changes data there.

Every Helm chart has one page at charts/{chart-slug}.html and the same content as data at charts/{chart-slug}.json. The slug is the chart name in lower case, with each run of other characters replaced by one hyphen. chart.schema.json defines the fields and chartVersion pins their meanings.

A diff between two versions or two bases is not stored. Compute it from the two object files the chart file names: fetch both, check each file's SHA-256 against objects.sha256, then run cub config diff on the pair. The summaries array holds one line for each adjacent pair of versions, and it is the only diff content the site stores.

A lifecycle route is a proposal until a destination resolves it, so automatic stays false until a run proves otherwise. A planned OCI reference names where a bundle would go and has not been pushed.

When an entry is absent, render locally. Ask the user before filing a public issue.