Redis UX Acceptance · Config Workshop

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

This checks whether the Redis proof is simpler and more convincing than plain Helm for a skeptical Helm user.

Verdict

Current proof: credible, but not yet polished.

The underlying value is now visible:

correct variants
safe operations
immediate proof

The remaining UX problem is the command shape. The proof uses real cub installer commands, but the demo still exposes more flags than the final product should.

Easier Than Helm

What is better now:

Helm alone	Current ConfigHub proof
Render/install output is a moment in time.	The rendered variant is stored, checked, uploaded, and receipt-backed.
The operator must manually compare values, YAML, and releases.	`npm run redis:compare` proves Helm semantic equivalence and classifies differences.
Secrets can be mixed into rendered output.	Default Secret is separated; reuse-existing-secret is modeled as a target fact.

What is not yet easy enough:

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.

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.

cub installer setup --pull ... --base ... --work-dir ... --namespace ...

This is real, but not the final happy path. The future porcelain can be shorter only after the current proof stays correct.

Safer Than Helm

The proof is safer because it records:

source and dependency locks;
effective values;
variant revisions;
rendered object digests;
Helm equivalence receipts;
scan receipts and gates;
package determinism receipts;
ConfigHub upload and OCI-read receipt;
expected external Secret references.

Production is not falsely allowed. The current scan gate warns and blocks production until findings are resolved or explicitly waived.

Correct Versus Helm

The current proof shows:

Variant	Helm objects	cub installer objects	Explanation
default	14	15	All Helm objects match; cub adds Namespace support object and separates one Secret.
reuse-existing-secret	13	14	All Helm objects match; cub adds Namespace support object; target Secret is required externally.

Every intentional difference is named before upload.

Five-Minute Test

A skeptical user should understand this in under five minutes:

Helm generated the Redis objects.
ConfigHub preserved those objects as variants.
ConfigHub proved the output matches Helm.
ConfigHub separated or externalized secret handling.
ConfigHub uploaded the exact objects into named spaces.
ConfigHub exposed OCI-readable proof for the uploaded Units.

Acceptance Status

Requirement	Status
One install/render action	Pass, using current `cub installer setup`.
One review/proof action	Pass, using `npm run redis:compare` and `npm run verify`.
One publish/upload action	Pass, using `cub installer upload`.
Exact object proof	Pass.
Helm equivalence	Pass.
Intentional differences explained	Pass.
Scan/gate shown	Pass, with production blocked.
Hosted ConfigHub OCI proof	Pass for representative Units.
Final polished UX	Not yet; current commands need porcelain later.

Next UX Improvement

Keep the current proof as the invariant, then design a thin command wrapper or plugin that reduces the visible path to:

install
review
publish

Do not introduce that shorthand into executable docs until it exists.