apiVersion: catalog.confighub.com/v1alpha1 kind: DemoProgram metadata: name: config-catalog spec: architecture: name: OCI in, managed configuration, OCI out frontDoor: problem: Helm charts, AICR recipes, installer packages, existing YAML, and existing OCI packages all need useful checks or changes before teams can rely on them. result: Starting examples can prepare source before OCI, inspect an existing OCI, or produce a new OCI after checking or changing its contents, without requiring ConfigHub Server or an account. accessModel: serverless: The work does not depend on ConfigHub Server. It can run as a local command, in CI, or eventually as a hosted public service. anonymous: The work uses no ConfigHub account. Public OCI packages remain useful before anyone claims and saves a configuration. composable: The work can sit before OCI, after OCI, or between an input OCI and an output OCI. A user can choose one shape or combine several; ConfigHub is not required until they want saved records and managed operations. inputs: - Helm charts and their values - AICR recipes and generated bundles - cub installer packages with preset configurations - Kubara, Sveltos, and existing Kubernetes YAML output: A literal configuration OCI, an inspection result, or both, plus a source record that names the inputs, prerequisites, lifecycle work, and evidence. anonymousFlows: - shape: work -> OCI result: Start with a Helm chart, AICR recipe, installer package, or Kubernetes files; inspect and test the result; then build a deployable OCI package. insertion: source -> anonymous work -> OCI -> delivery - shape: OCI -> work result: Pull an existing public OCI package to inspect its objects, explain its requirements, run checks, or compare it with another version. insertion: OCI -> anonymous inspection or testing - shape: OCI -> work -> OCI result: Pull an OCI package, check or change its exact objects, and serve the resulting OCI package without taking ownership of it in ConfigHub. insertion: OCI -> anonymous work -> OCI -> delivery executionModes: - id: local-command name: Local command status: available result: Run the public tools without a ConfigHub account. The current receipt proves this path and keeps the files and OCI references under the user's control. - id: ci-job name: CI job status: available result: Run the same non-interactive commands in CI. The current GitHub Actions receipt proves anonymous public OCI pull, rendering, OCI creation, and pull-back comparison without ConfigHub credentials. - id: hosted-public name: Public hosted service status: planned result: Inspect, test, and serve public configuration without signing in, then claim it later. Anonymous use does not create private history, saved edits, variants, or approvals. claimBoundary: before: Anonymous users can build, inspect, test, pull, and serve public OCI packages. action: Claim this configuration in ConfigHub. after: ConfigHub saves the objects and their history so a team can transform, approve, promote, and roll them out. A team can claim at whichever OCI boundary needs managed records; claiming is not a required first step. managedExamples: After a configuration is claimed or uploaded, variants, promotions, releases, Apps, apply gates, and fleet examples use ConfigHub Server and require an account. configHub: problem: A deployable OCI file is useful, but teams still need to share it, change it, review it, promote it, and understand where it is used. result: ConfigHub stores the exact objects as Units and keeps their source, variants, diffs, checks, approvals, promotions, and observations together. operations: - Store and query exact Kubernetes objects - Create base and derived variants - Compare, test, approve, and promote changes - Record lifecycle routes, releases, and live observations existingFlow: before: Git -> CI -> OCI -> Argo CD or Flux -> Kubernetes withConfigHub: Git -> CI -> OCI -> ConfigHub -> OCI -> Argo CD or Flux -> Kubernetes firstStep: ConfigHub can publish the same specs and user-supplied metadata unchanged. The release adds only the confighub.com/origin provenance annotation. later: A team can create named variants, apply policy, promote reviewed changes, and roll them out to selected clusters. fanOut: One recorded configuration can produce specific outputs for environments, customers, regions, or cluster groups. delivery: problem: Delivery should not rerender the source package and produce a different result after review. result: cub release publish creates an immutable Space release OCI from the reviewed ConfigHub Units. The same reviewed objects can also be packaged as a portable OCI for anonymous or external consumers. consumers: - Argo CD - Flux - direct apply rule: Each catalog configuration earns a delivery claim only when its own release OCI, controller result, and workload result have a receipt. catalogNavigation: startingQuestion: What do you already have? startingPoints: - Helm chart and values - AICR recipe or bundle - cub installer package - Existing OCI package - Kubernetes YAML nextQuestion: What do you want to do next? nextJobs: - Inspect and verify - Install - Upload and save - Customize - Promote - Deliver - Operate - Build an App entryOrder: - Ready-made configurations - Package and artifact choices - Inputs, prerequisites, CRDs, hooks, and other work before install - ConfigHub upload - Variants, upgrades, and promotions - Delivery evidence - Current limits rule: Keep the detailed evidence pages. Use this order on catalog entry pages so a person can choose a starting point and a next action before reading the proof details. reviewQuestions: rule: Every example and catalog entry must answer these questions in plain English and link to the exact files or receipts that support the answer. questions: - question: What can a new user do first? standard: Give one short path from a named input to one inspected, deployable result before introducing ConfigHub accounts, fleets, policy, or Apps. - question: Is testing and understanding this configuration easier than using Helm normally? standard: Show the rendered objects, the recorded inputs, the relevant comparison or parity result, and the command that repeats the check. - question: Can I find the hooks, CRDs, prerequisites, and other chart quirks? standard: List them beside the package, explain what each one does, name who performs it, and distinguish a proved route from a proposed route. - question: Can I use the rendered-manifest pattern without giving up my Helm chart? standard: Keep the chart as source, make the literal Kubernetes objects easy to inspect and save, and explain how later edits and upgrades are handled. - question: Can source-to-OCI be automated? standard: Name the repeatable command or workflow, record the source and output digests, and state which steps still require a person or target-specific input. - question: Can I bring the chart and values my team or AI produced? standard: Render them without applying, compare them with known configurations, point out risky or unusual changes, and let the user deploy or save the reviewed result. - question: What happens after the first deployment? standard: Show how the same reviewed result can become a saved base, a development or production variant, a promotion, and an OCI delivered through Argo CD, Flux, or direct apply. - question: What has not been proved? standard: Keep missing controller paths, upgrades, target checks, and product work visible. Do not turn one passing path into a general claim. exampleJourney: rule: Every example starts with one person getting one deployable result. Saved configuration, environments, rollout, and Apps come afterward. examples: - id: ready-made-package level: basics name: Pull, inspect, and verify a ready-made package status: available problem: You want to deploy a public package, but you need to know what it contains and why this configuration was chosen. result: Pull one public installer OCI without an account, inspect the exact Kubernetes objects and recorded Helm inputs, then check the parity, prerequisite, route, and verification evidence before deployment. steps: - Choose a ready-made configuration from the catalog. - Pull the recorded package digest and render it locally. - Read the objects, Helm render intent, prerequisites, CRD and hook routes, and known limitations. - Run the named verification command or inspect the committed receipt. - Deploy only after the result matches the target you intend to use. evidence: - data/installer-oci-packages/summary.md - data/helm-render-intents/summary.md - data/outcome-coverage/summary.md - docs/user/verify-it-yourself.md limits: - Evidence is scoped to the named chart, version, preset configuration, render inputs, and proof lane. - id: bring-your-own-configuration level: basics name: Bring your own chart and values status: available problem: You have a chart and values written by your team or an AI, and you do not want to apply plausible configuration without seeing what it creates. result: Render the chart into exact Kubernetes objects, compare it with chart defaults and known catalog configurations, identify prerequisites and risky changes, then deploy it or save the reviewed result. steps: - Supply the chart, version, values, namespace, release name, and target capabilities. - Render the exact objects without applying them. - Compare the result with the chart defaults and relevant catalog configurations. - Review the object diff, placeholders, Secrets, CRDs, hooks, dependencies, and checks. - Deploy the reviewed files or claim them in ConfigHub. evidence: - examples/byo-helm-values/ai-values.yaml - examples/byo-helm-values/reviewed-values.yaml - data/byo-helm-values-review/summary.md - data/byo-helm-values-review/review.yaml - data/byo-helm-values-review/public-and-confighub.md - runs/byo-helm-values-proof/receipt.yaml - runs/byo-helm-values-proof/public-oci-receipt.yaml - runs/byo-helm-values-proof/confighub-upload-receipt.yaml - data/byo-helm-values-deploy-proof/summary.md - runs/byo-helm-values-deploy-proof/receipt.yaml - data/byo-helm-values-promotion-proof/summary.md - runs/byo-helm-values-promotion-proof/receipt.yaml - data/byo-helm-values-staging-deploy-proof/summary.md - runs/byo-helm-values-staging-deploy-proof/receipt.yaml - docs/user/choosing-commands.md - docs/reference/direct-cub-helm-model.md - docs/user/ai-assisted-helm-changes.md - data/ai-change-review/summary.md limits: - The worked NGINX example checks one deterministic values proposal. It does not claim that every private chart or generated values file can be judged automatically. - The required Secret was supplied separately and its value was not recorded. The exact example has passed Argo CD delivery at three replicas, a development-to-staging promotion to four replicas, and a second Argo CD delivery at four ready replicas. - Flux delivery, rollback, chart upgrade, and fleet rollout have not run for this configuration. - id: claim-and-customize level: managed name: Save the reviewed result and change it status: available problem: Local files are useful for one deployment, but a team needs shared history and changes that remain visible. result: Upload the reviewed objects as a ConfigHub base variant, then change exact Kubernetes fields in named derived variants. steps: - Upload the literal configuration OCI or rendered files. - Check the imported Units against the reviewed object inventory. - Create a named development or customer variant. - Make one exact field change and review the diff. - Publish a new OCI only after the revision is accepted. evidence: - docs/user/variants-after-upload.md - data/base-variant-records/summary.md - data/catalog-oci-delivery-proof/summary.md - data/byo-helm-values-promotion-proof/summary.md - runs/byo-helm-values-promotion-proof/receipt.yaml limits: - A field that changes the Helm render belongs in a new rendered base; post-render fields belong in derived variants. - id: upgrade-and-promote level: managed name: Upgrade and promote through environments status: available problem: Copying values or manifests between environments hides the exact change and makes upgrades hard to repeat. result: Reconcile a candidate base, keep the intended post-render changes, preview the affected variants, and promote the accepted revision in sequence. steps: - Compare the current and candidate source versions. - Reapply the recorded derived changes to the candidate objects. - Run checks and inspect the exact mutations. - Promote through development and staging in order. - Require approval before the production revision is delivered. evidence: - runs/redis-upgrade-app-proof/receipt.yaml - data/redis-upgrade-app-proof/summary.md - data/byo-helm-values-promotion-proof/summary.md - runs/byo-helm-values-promotion-proof/receipt.yaml - docs/user/day2-upgrade-rollback.md limits: - The current CLI dry-run does not yet print a useful human mutation preview. - id: deliver-and-roll-out level: delivery name: Deliver one reviewed OCI and roll it out status: available problem: A reviewed configuration is not useful until the intended controller applies the same objects and the workload becomes healthy. result: Publish one immutable OCI, reconcile its digest through Argo CD or Flux, and record controller and workload results for each target. steps: - Publish the approved Units as one release OCI. - Pin the exact digest in the delivery controller. - Reconcile one development target. - Advance the same accepted revision to a sibling environment. - Roll it out to a small target set and record every result. evidence: - data/byo-helm-values-deploy-proof/summary.md - runs/byo-helm-values-deploy-proof/receipt.yaml - data/byo-helm-values-staging-deploy-proof/summary.md - runs/byo-helm-values-staging-deploy-proof/receipt.yaml - runs/oci-deploy-stage-rollout-proof/receipt.yaml - data/oci-deploy-stage-rollout-proof/summary.md - docs/user/app-to-live-walkthrough.md limits: - The current flagship receipts use small local target sets, not a large production fleet. - id: lifecycle-work level: advanced name: Manage the CRDs, hooks, and setup work around a package status: available problem: Some packages need CRDs, certificates, jobs, or checks in a specific order that a flat manifest bundle does not perform by itself. result: Keep that work beside the package, name who runs each step, execute only the supported path, and retain a receipt. steps: - Read the chart-specific lifecycle routes. - Apply CRDs and wait before dependent custom resources. - Run or replace the chart-specific setup work. - Deliver the ordinary objects. - Check readiness and record what actually ran. evidence: - docs/demo/hooks-crds/kube-prometheus-stack.md - data/hooks-crds-app/summary.md - data/kps-lifecycle-route-proof/summary.md - runs/kps-lifecycle-route-proof/receipt.yaml - data/kps-gitops-lifecycle-proof/summary.md - runs/kps-gitops-lifecycle-proof/receipt.yaml - data/lifecycle-routes/summary.md limits: - Seven fresh-install steps passed in the direct script. The no-crds 85.3.3 to 86.1.0 path also passed through Argo CD and Flux, including setup-Job replacement and post-upgrade checks. - A route is automatic only for the chart, version, delivery path, and execution receipt that proves it. - id: apps level: apps name: Use an App for a repeated operational job status: example-only problem: Upgrade review, RBAC review, fleet assignment, and AI change review require several configuration operations to work together. result: Use saved configuration, checks, approvals, delivery, and observations as one repeatable operational workflow. steps: - Choose the operational question the App answers. - Select the saved configurations and targets in scope. - Produce exact proposed changes and affected-target results. - Run policy and approval before delivery. - Observe the rollout and keep the decision record. evidence: - data/app-readiness/summary.md - docs/demo/apps/ai-change-review.md - docs/demo/apps/rbac-review.md limits: - The current Apps are reproducible demonstrations, not finished ConfigHub App interfaces. pathways: - id: helm name: Helm chart to managed configuration problem: A Helm chart can hide the final Kubernetes objects, risky defaults, prerequisites, and upgrade changes behind its templates. result: Pick a reviewed chart configuration, inspect the literal objects and the Helm record, upload them as a ConfigHub base variant, then make reviewed environment variants. status: available workedExample: status: working result: The Redis example pulls a public package, shows the exact Helm inputs and Kubernetes objects, checks Helm parity, and can continue into ConfigHub. limit: The result applies to the named Redis versions and preset configurations, not every Helm chart. steps: - Choose a chart and preset configuration in the Helm Ops Catalog. - Pull the cub installer package and render it without a ConfigHub account. - Inspect the objects, render intent, routes, prerequisites, and receipts. - Upload the rendered files or a literal configuration OCI bundle as a base variant. - Create test, development, staging, and production variants from that base. entrypoints: - site/charts/index.html - site/try.html - docs/user/helm-presets-and-values.md - docs/user/variants-after-upload.md evidence: - data/helm-render-intents/summary.md - data/installer-oci-packages/summary.md - data/outcome-coverage/summary.md limits: - A passing render does not prove that every target prerequisite or live delivery lane passes. - id: aicr name: AICR bundle to managed configuration problem: AICR can produce a versioned AI infrastructure recipe and deployment bundle, but teams still need to record which bundle and remaining inputs each cluster should run. result: Keep the AICR recipe, remaining inputs, generated files, and OCI digest together. Upload the literal configuration OCI as a ConfigHub base variant, then use the same policy and promotion process as other configuration sources. status: partial workedExample: status: working result: The AICR example publishes a source OCI and a 17-Application literal OCI, imports the literal objects into ConfigHub, and promotes one reviewed change from development to staging. limit: Argo CD delivery and a live GPU workload have not run. steps: - Generate and review an AICR recipe for a named target. - Build a Flux, Argo CD, or Helm bundle and record every remaining install-time input. - Keep the recipe, bundle checksums, and generation receipt together. - When the generated OCI is still a source package, render it once more and put the literal Kubernetes or controller objects in a separate OCI for ConfigHub upload. - For Flux OCI output, record the required OCIRepository, source-watcher controller, and ExternalArtifact feature gate. - Upload the literal bundle as a ConfigHub base variant. - Confirm that the system-configuration policy stops an unapproved dry-run before any target is used. - Promote derived variants only after the rendered diff and target checks pass. entrypoints: - docs/demo/aicr/eks-h100-training-kubeflow.md - examples/aicr/eks-h100-training-kubeflow/aicr.yaml evidence: - examples/aicr/eks-h100-training-kubeflow/generation-receipt.yaml - examples/aicr/eks-h100-training-kubeflow/recipe.yaml - examples/aicr/eks-h100-training-kubeflow/flux-oci-bundle - examples/aicr/eks-h100-training-kubeflow/local-oci-manifest.json - examples/aicr/eks-h100-training-kubeflow/argocd-oci-receipt.yaml - examples/aicr/eks-h100-training-kubeflow/public-oci-receipt.yaml - examples/aicr/eks-h100-training-kubeflow/confighub-upload-receipt.yaml - examples/aicr/eks-h100-training-kubeflow/apply-policy-receipt.yaml - examples/aicr/eks-h100-training-kubeflow/promotion-readiness-receipt.yaml - runs/aicr-variant-promotion-proof/receipt.yaml - data/aicr-variant-promotion-proof/summary.md - runs/aicr-oci-roundtrip-proof/receipt.yaml - data/aicr-oci-roundtrip-proof/summary.md - examples/aicr/eks-h100-training-kubeflow/argocd-rendered limits: - The original Git-oriented Flux bundle retains AICR's generated YOUR_ORG/YOUR_REPO placeholder and is not deployable. - The OCI-oriented Flux bundle is generated and checksum-verified, but it has only been pushed to a temporary local registry. - The Argo CD source package and the 17-object literal configuration OCI are public in Google Artifact Registry and passed anonymous pull checks at their recorded digests. - ConfigHub imported the 17 exact Application objects from the public literal configuration OCI as one policy-covered base variant. - The persistent helm-catalog organization has a base, development, and staging chain. Development changes only the kube-prometheus-stack Application to use a target-owned Grafana Secret; staging received that exact reviewed change. - A dry-run left development unchanged, a second dry-run left staging unchanged, and required approval remains attached to all three Spaces. - A separate live round trip proved that ConfigHub can publish those 17 Applications as a release OCI and that the pulled release keeps every Kubernetes field, with only the ConfigHub origin annotation added. - A separate scratch run remains as supplementary evidence for the same base-to-development-to-staging behavior. - Argo CD delivery and live GPU-cluster reconciliation have not run. - id: cub-installer name: cub installer package to managed configuration problem: A team may need several chart-specific preset configurations and repeatable local rendering without introducing a server into the first test. result: cub installer carries the chart, preset configurations, values, and supporting files in one OCI package, then renders the selected preset locally or uploads it to ConfigHub. status: available workedExample: status: working result: Public catalog packages pull without a registry login, render locally, write one selected configuration as OCI, and verify the output by reading it back. limit: The lifecycle route for hooks, CRDs, setup jobs, and target prerequisites remains specific to each preset configuration. steps: - Pull a public installer package with no registry login. - Select one preset configuration. - Render and inspect the package locally. - Keep the result as files, or write the selected non-secret objects as OCI with cub installer setup --output-oci. - Upload the chosen result when the team wants shared records and variants. entrypoints: - docs/user/installer-oci-packages.md - docs/user/try-now.md evidence: - data/installer-oci-packages/summary.md limits: - An installer package OCI can contain several preset configurations. The rendered OCI contains one selected preset. --output-oci excludes separated secret files, records the source package and selected base, and checks the output object set by reading it back. A chart with hooks, CRDs, setup jobs, or target prerequisites still needs the route recorded for that preset. - id: literal-yaml name: Plain Kubernetes YAML to managed configuration problem: A team may already have reviewed Kubernetes YAML and should not need to wrap it in a chart or run another renderer before ConfigHub can record it. result: Upload the files as exact Kubernetes objects, keep their source identity, and use the saved base for later variants, promotions, releases, and Apps. status: available workedExample: status: working result: Four committed YAML files become four ConfigHub Units, one per object. A receipt reads the Units back and proves that the stored object set matches the supplied files. limit: The focused receipt proves import only. It does not claim Kubernetes apply, controller delivery, promotion, rollback, or workload health. steps: - Start with reviewed Kubernetes YAML. - Upload it without a Helm or AICR render step. - Read the stored Units back and compare their object-set hash with the files. - Keep one README Unit beside the configuration so a new user can understand the example. - Continue with the official ConfigHub tutorial when the base needs changes, promotion, or delivery. entrypoints: - examples/plain-yaml/acme-web/README.md - docs/user/adopting-existing-apps.md - docs/user/app-to-live-walkthrough.md evidence: - runs/literal-yaml-upload-proof/receipt.yaml - data/literal-config-examples/summary.md limits: - The plain YAML example has no Helm parity question because there is no chart or render step. - The current focused receipt stops after exact ConfigHub import and policy attachment. - id: anonymous-oci name: Public OCI inspection and packaging problem: A team may want to inspect, test, or repackage public configuration without creating an account or handing ownership to another service. result: Pull an OCI package, work with the exact objects, and produce a deployable OCI package. Claim it in ConfigHub only when the team wants saved history, variants, approvals, promotions, or fleet rollout. status: partial workedExample: status: working result: Local and CI proofs pull public packages without ConfigHub credentials, inspect or change exact objects, build OCI, and compare the output after pulling it back. The reviewed NGINX change is also published as a permanent public OCI and imported into a ConfigHub Space at its recorded digest. limit: The hosted anonymous service is planned. Some delivery proofs still use workflow artifacts or temporary registries and are labeled that way. steps: - Start with source files or an existing public OCI package. - Inspect and test the exact configuration objects. - Keep the result as working files, package it as OCI, or do both. - Pull the resulting package again and compare its objects with the reviewed files. - Claim the configuration in ConfigHub when it needs stored operations. entrypoints: - docs/user/serverless-mode.md - docs/reference/config-catalog-doctrine.md - docs/planning/config-catalog-demo-program.md evidence: - runs/serverless-oci-gitops-proof/receipt.yaml - data/serverless-oci-gitops-proof/summary.md - runs/anonymous-oci-ci-proof/receipt.yaml - data/anonymous-oci-ci-proof/summary.md - runs/oci-deploy-stage-rollout-proof/receipt.yaml - data/oci-deploy-stage-rollout-proof/summary.md - runs/anonymous-oci-transform-proof/public-oci-receipt.yaml - runs/existing-oci-upload-proof/receipt.yaml - data/literal-config-examples/summary.md limits: - The NGINX receipt proves anonymous public installer OCI pull, local rendering with no ConfigHub token, output OCI pull-back, and Flux reconciliation at the recorded output digest. - The CI receipt proves the same public input can be rendered, checked, packaged as OCI, and pulled back in GitHub Actions without ConfigHub credentials. - The CI output is a workflow artifact containing an OCI image layout, not a public registry package. - The Flux proof used a temporary local registry. - The reviewed NGINX replica change has a separate permanent public-registry receipt and exact ConfigHub import receipt. - Direct import of an OCI with companion JSON records needs the merged confighub/sdk PR #11 fix. It is newer than cub v0.2.5 and awaits the next cub release. - A hosted public workbench remains separate work. - id: oci-delivery name: One reviewed bundle through Argo CD, Flux, or direct apply problem: Teams want to keep their delivery controller and know that it is applying the Kubernetes objects they reviewed, rather than rendering another result from Helm values. result: ConfigHub can publish one reviewed object set as a release OCI. Argo CD, Flux, or a recorded direct-apply path can consume the same files without rendering the chart again. status: partial workedExample: status: working result: NGINX and the hook fixture have passed recorded OCI delivery through Argo CD, Flux, and direct apply without rerendering the reviewed objects. limit: These receipts do not cover every catalog configuration. steps: - Start with the exact Kubernetes objects held as ConfigHub Units. - Run the checks and approval required for that configuration. - Publish the approved revision once as a ConfigHub release OCI. - Point Argo CD, Flux, or the recorded direct-apply path at that artifact. - Record controller status and workload observations for this configuration. entrypoints: - docs/user/gitops-adopter-guide.md - docs/user/cub-deployment-path.md evidence: - runs/oci-hook-delivery-proof/receipt.yaml - data/oci-hook-delivery-proof/summary.md - runs/catalog-oci-delivery-proof/bitnami-nginx-24-0-2-http-clusterip.yaml - data/catalog-oci-delivery-proof/summary.md - runs/oci-deploy-stage-rollout-proof/receipt.yaml - data/oci-deploy-stage-rollout-proof/summary.md limits: - The live three-consumer receipt proves this delivery mechanism with one small routed-hook fixture. - The NGINX receipt proves the first exact catalog base through Argo CD, Flux, and direct apply from one ConfigHub Space release OCI. - The combined NGINX receipt proves one OCI import, one congruent ConfigHub output with only the confighub.com/origin annotation added, sequential development and staging promotions, a portable anonymous OCI output, and Argo CD reconciliation at one digest on two clusters. - These receipts do not prove that every catalog base has been delivered through all three paths. - A catalog entry earns a controller-delivery claim only when that exact configuration has its own receipt. - id: promotions name: Test, development, staging, and production promotions problem: Copying values files between environments makes it hard to tell what changed and whether production still matches the reviewed configuration. result: Upload one base variant, keep environment changes as derived variants, preview the exact mutations, and promote them in order with production approval. status: partial workedExample: status: working result: Redis and NGINX examples record derived changes, promote them in order, publish reviewed OCI artifacts, and check the resulting workloads. limit: The current CLI still lacks a useful human mutation preview for one promotion dry-run. steps: - Create environment variants from one base. - Make or import a reviewed change. - Preview the mutations before promotion. - Promote through test, development, staging, and production. - Check delivery and live observations after each rollout. entrypoints: - docs/user/variants-after-upload.md - docs/user/app-to-live-walkthrough.md evidence: - data/variant-promotion/summary.md - runs/redis-default-confighub-proof/latest/variant-promotion-receipt.yaml - data/fleet-promotion/live-nginx-registry-migration.yaml - runs/oci-deploy-stage-rollout-proof/receipt.yaml - data/oci-deploy-stage-rollout-proof/summary.md - runs/redis-upgrade-app-proof/receipt.yaml - data/redis-upgrade-app-proof/summary.md limits: - The older NGINX fleet receipt proves four stored environment records and policy assignment but not cluster delivery. - The combined NGINX receipt proves base-to-development-to-staging promotion, a two-cluster Argo rollout, exact live-object agreement, and workload convergence. The observation receipts were recorded locally and were not submitted to ConfigHub observation storage. - The Redis receipt proves a chart-version upgrade that keeps a post-render replica change, promotes in two waves, and reaches two Argo CD clusters. The current mutation-preview command returned no text, so the human preview remains a product gap. - id: kubara name: Kubara platform configuration to a cluster fleet problem: A platform stack can span Terraform, Helm, policies, and cluster-specific choices that should be managed as one declared fleet record. result: Treat Kubara as a platform configuration producer, record its generated configuration as base variants, and assign reviewed variants to cluster groups. status: partial workedExample: status: working result: One approved Kubara configuration passed its recorded route work, OCI delivery, Argo CD bootstrap, and a healthy Metrics Server result on one cluster. limit: The example does not yet cover the full service profile or a multi-cluster rollout wave. steps: - Generate a Kubara platform configuration for a declared cluster class. - Separate infrastructure creation from Kubernetes configuration. - Render the generated Argo CD bootstrap and record CRDs, hooks, Secrets, and target prerequisites beside it. - Upload the Kubernetes configuration as a base variant with its source record. - Run the required CRDs, target Secrets, and hook work before delivering the prepared configuration OCI. - Let the delivered Kubara Argo CD assign the selected platform services. - Assign derived variants to cluster groups and rollout waves. entrypoints: - docs/demo/kubara/local-platform.md - examples/kubara/local-platform/README.md - docs/corpus/kubara-customized-overlays.md evidence: - examples/kubara/local-platform/generation-receipt.yaml - examples/kubara/local-platform/confighub-upload-receipt.yaml - examples/kubara/local-platform/route-intent.yaml - examples/kubara/local-platform/rendered/object-inventory.json - examples/kubara/local-platform/local-config-oci-manifest.json - runs/kubara-oci-delivery-proof/receipt.yaml - data/kubara-oci-delivery-proof/summary.md - docs/corpus/kubara-customized-overlays.md limits: - The repo now has a reproducible Kubara v0.12.0 generation, Argo CD render, route record, and local OCI layout. - ConfigHub pulled the local OCI, recorded the 75 non-Secret objects in one policy-covered Unit, required approval, and published a private release. - A live route handled the three Argo CD CRDs, two target-owned Secrets, and Redis initializer before delivery. It deferred the ClusterExternalSecret and gRPC Ingress because their target prerequisites were absent. - A temporary portable OCI delivered 69 prepared objects through bootstrap Argo CD. Kubara Argo CD became ready and its one selected Metrics Server Application became Synced and Healthy. - The live receipt covers one kind cluster and one downstream service. It does not prove permanent public publication, the full seven-service profile, or a multi-cluster promotion wave. - id: sveltos name: ConfigHub desired state delivered through Sveltos problem: Fleet operators need a declarative way to assign platform components to matching clusters and keep placement separate from package creation. result: ConfigHub manages the reviewed ClusterProfile and related configuration; Sveltos selects clusters and reconciles the declared add-ons. status: partial workedExample: status: working result: A reviewed ClusterProfile moved from one pilot cluster to two staging clusters at a second OCI digest, and Sveltos restored a deliberately drifted value. limit: The proof uses two local clusters and does not test a failed rollout wave. steps: - Review the ClusterProfile and the chart versions it assigns. - Upload it to ConfigHub and attach the standard catalog checks. - Deliver the reviewed object to a Sveltos management cluster. - Let Sveltos select matching workload clusters and install the add-on. - Change a managed field and check that Sveltos restores the reviewed value. entrypoints: - docs/demo/sveltos/kyverno-fleet.md - examples/sveltos/kyverno-fleet/README.md - examples/sveltos/kyverno-fleet/clusterprofile.yaml evidence: - examples/sveltos/kyverno-fleet/clusterprofile.yaml - examples/sveltos/kyverno-fleet/source-lock.yaml - examples/sveltos/kyverno-fleet/live-receipt.yaml - runs/sveltos-oci-delivery-proof/receipt.yaml - data/sveltos-oci-delivery-proof/summary.md limits: - The original live receipt records a manual export and kubectl apply. A newer receipt proves approval, private ConfigHub release, local portable OCI packaging, anonymous pull, and Argo CD delivery without copying the ClusterProfile with kubectl. - Sveltos itself was installed directly as a pinned management-cluster prerequisite, and the portable OCI used a temporary registry. - The current OCI receipt starts with one pilot cluster, then removes one reviewed selector label and records healthy Kyverno results on two staging clusters at a second OCI digest. - The current wave used two local kind clusters. It does not prove a large production fleet or a rollout that pauses after a failed target. apps: - id: upgrade-app name: Upgrade App problem: A chart or package upgrade can change many clusters at once, and a green source diff does not show which workloads will be affected. result: Show fleet impact, test the candidate configuration, promote it in waves, and check the rollout. status: partial workedExample: status: working result: Redis upgrades from chart 25.5.3 to 27.0.0 without losing a post-render replica change, moves through development and staging, reaches two Argo CD clusters, and rolls back. limit: This is a guarded demonstration and receipt, not a finished ConfigHub App interface. steps: - Compare the current and candidate base variants. - Find every derived variant and target that inherits the change. - Run configuration checks and selected live tests. - Approve and promote in waves. - Compare desired and observed state after rollout. entrypoints: - docs/user/day2-upgrade-rollback.md - data/blast-radius-fleet/summary.md - data/redis-upgrade-app-proof/summary.md evidence: - data/blast-radius-accuracy/summary.md - data/blast-radius-fleet/summary.md - runs/redis-upgrade-app-proof/receipt.yaml - data/redis-upgrade-app-proof/summary.md limits: - One continuous Redis proof now imports chart 25.5.3, records a post-render replica change, reconciles chart 27.0.0 without losing that change, promotes through development and staging, and checks the same OCI digest on two Argo CD clusters. - The proof is a guarded script and receipt, not a finished ConfigHub App interface. - cub variant promote --dry-run -o mutations returned no text. The dry runs changed no stored data, but the current CLI does not yet give a useful human mutation preview. - The portable OCI used a temporary local registry, and the live observations were recorded locally rather than submitted to ConfigHub observation storage. - id: hooks-crds-app name: Hooks and CRDs App problem: A complex chart may need CRDs, certificate setup, jobs, and checks in a particular order. A rendered YAML bundle alone does not explain or perform that work. result: Keep the chart, record its install and upgrade sequence beside the rendered objects, block incomplete routes from apply, and keep receipts for the delivery paths that have actually run. status: partial workedExample: status: working result: Kube Prometheus Stack passes the recorded CRD, certificate, workload, webhook, and runtime sequence on fresh installs and on an 85.3.3 to 86.1.0 upgrade through Argo CD and Flux. limit: ConfigHub does not yet select and execute the chart-specific route automatically. steps: - Start from the Kube Prometheus Stack 85.3.3 no-crds preset and its recorded Helm inputs. - Apply the ten CRDs and wait for them before applying dependent custom resources. - Prepare the webhook certificate, apply the ordinary objects, and check readiness in the recorded order. - Choose the recorded Argo CD, Flux, or direct-apply implementation for each step. - Store every route as a checked LifecycleRoute and keep the execution receipts beside it. entrypoints: - docs/demo/hooks-crds/kube-prometheus-stack.md - docs/user/chart-hooks-what-happens.md - docs/user/target-prerequisites.md evidence: - data/hooks-crds-app/summary.md - data/hooks-crds-app/live-receipt.yaml - data/kps-lifecycle-route-proof/summary.md - runs/kps-lifecycle-route-proof/receipt.yaml - data/kps-gitops-lifecycle-proof/summary.md - runs/kps-gitops-lifecycle-proof/receipt.yaml - data/lifecycle-routes/summary.md - runs/crd-ordering-gap/receipt.yaml - runs/hook-execution-proof/receipt.yaml - runs/oci-hook-delivery-proof/receipt.yaml - data/hook-lifecycle/receipts/prometheus-community-kube-prometheus-stack/default/latest.yaml limits: - Seven Kube Prometheus Stack fresh-install steps passed in the direct script. The no-crds 85.3.3 to 86.1.0 upgrade passed through Argo CD and Flux. - The top-level Kube Prometheus Stack routes remain automatic false because ConfigHub does not yet choose and execute them across every delivery path. - The controller proof does not cover rollback, long soak, or automatic post-success removal of every temporary hook resource. - The smaller hook fixture is automatic only because the same packaged Job ran through Argo CD, Flux, and direct apply. - The route policy rejects incomplete or unsupported automatic claims; it does not decide which routes a chart needs. - id: rbac-review-app name: RBAC Review App problem: Risky permissions are hard to find when application configuration is split across charts, repositories, and clusters. result: Query the imported Kubernetes objects, find broad access, and propose exact corrections for review. status: partial workedExample: status: working result: One review removes unnecessary Secret access, keeps ConfigMap access, requires approval, publishes OCI, and reaches Kubernetes through Argo CD. limit: The example does not yet build a complete RBAC binding graph across a live fleet. steps: - Read Role, ClusterRole, and binding Units across selected Spaces. - Report broad verbs, resources, and subjects. - Propose a concrete object diff. - Publish the approved objects as OCI and let Argo CD deliver the correction. entrypoints: - docs/demo/apps/rbac-review.md - data/app-readiness/summary.md evidence: - data/app-readiness/summary.md - data/rbac-review-live-proof/summary.md - runs/rbac-review-live-proof/receipt.yaml limits: - The catalog-wide scan reads committed default renders; it does not yet query binding graphs across a live fleet. - The live example proves one exact namespaced correction, approval, private ConfigHub release, portable OCI output, Argo CD reconciliation, and Kubernetes permission change. - The portable OCI used a temporary anonymous registry. A permanent public package, Flux delivery, and fleet rollout remain separate work. - id: fleet-platform-app name: Fleet Platform App problem: Platform teams need to assign different system configurations to cluster groups without losing a central source of record. result: Assign Helm, AICR, Kubara, or Sveltos-based platform configurations to clusters and manage rollout waves from ConfigHub. status: partial workedExample: status: working result: Kubara proves one platform target, while Sveltos proves a pilot and two-cluster expansion with separate reviewed OCI digests and drift recovery. limit: A large mixed-source fleet rollout with failure-based pausing remains open. steps: - Classify configuration as a user workload, system service, or system configuration. - Select the base variant and small install-time input set for each cluster class. - Preview the affected clusters. - Promote in waves and observe each target. entrypoints: - docs/reference/config-catalog-doctrine.md - data/blast-radius-fleet/summary.md evidence: - data/blast-radius-fleet/summary.md - data/environment-matrix/summary.md - data/fleet-promotion/live-nginx-registry-migration.yaml - runs/oci-deploy-stage-rollout-proof/receipt.yaml - data/oci-deploy-stage-rollout-proof/summary.md - runs/redis-upgrade-app-proof/receipt.yaml - data/redis-upgrade-app-proof/summary.md - runs/sveltos-oci-delivery-proof/receipt.yaml - data/sveltos-oci-delivery-proof/summary.md limits: - The live NGINX fleet proves a Helm-derived base and four managed environments. The combined OCI receipt separately proves sequential promotion and one reviewed output on two Argo CD clusters, with exact-object and convergence receipts from cub-scout. - Sveltos proves a reviewed pilot selector, a second approved revision, two OCI digests, target-by-target Kyverno results on two clusters, and drift recovery on each target. - Kubara proves one approved platform configuration through route work, OCI, Argo CD, Kubara Argo CD readiness, and one healthy downstream Metrics Server Application. A large mixed-source fleet wave remains open. - id: ai-change-review-app name: AI Change Review App problem: An agent can change values or Kubernetes fields faster than a person can check the resulting objects and fleet impact. result: Turn the suggestion into exact objects and diffs, run checks, require the right approval, and keep the decision record. status: partial workedExample: status: working result: The example finds an unpinned image and inline API key, clears the reviewed replacement, and proves that approval controls the ConfigHub apply dry-run. limit: Kubernetes delivery, promotion, rollback, GPU workload health, and live observation have not run for this candidate. steps: - Let the agent propose values or object edits. - Render or apply the proposal to a derived variant. - Show the exact object and fleet diff. - Run schema, placeholder, security, and target checks. - Approve, promote, observe, or unwind the change. entrypoints: - docs/demo/apps/ai-change-review.md - docs/user/ai-assisted-helm-changes.md - config-catalog/policies/catalog-standard.yaml evidence: - data/ai-change-review/receipt.yaml - data/ai-change-review/summary.md - runs/ai-change-review-live-proof/receipt.yaml - data/ai-change-review-live-proof/summary.md - data/app-readiness/summary.md - data/claims-register/summary.md limits: - The committed training-runtime example proves exact local objects, diffs, and deterministic checks. - A live ConfigHub run reported the unsafe nested AICR image, blocked the inline API key, and left the reviewed candidate clear. It stored the reviewed object without changing its Kubernetes fields, blocked an OCI-target dry run until the exact head revision was approved, and allowed the same dry run after approval. - The four-node capacity rule remains a repository check rather than a ConfigHub Function. - The ordinary Deployment image and probe checks are limited to Kubernetes workload kinds they understand, so they do not report findings for this AICR custom resource. - Kubernetes apply, promotion, rollback, GPU workload health, and live observation have not run for this candidate.