Dedicated Website Plan

The GitHub repo proves the work. A dedicated website should make the work easy to understand and try.

Goal

The website should answer three questions in under a minute:

Why is this better than using Helm alone?
Which chart and variant should I start with?
What proof exists that it works?

It should also answer the next operational question without sending the reader back into the repo:

What do I do after the first install?

The answer should be concrete: choose or create variants, upload or deliver through ConfigHub, inspect Units, compare variants, run scans, approve changes, observe live state, operate custom apps and stacks, and know when a chart needs managed support rather than public-catalog use.

Website work should be checked with the persona UX strategy: persona-ux-strategy.md. That audit uses novice, Helm-fluent, GitOps, SRE, maintainer, AI-curious, and skeptical-reviewer personas to test whether the public site is understandable before users reach the proof surfaces.

It should not expose the full internal noun ladder first. The first impression should be:

Use Helm charts.
Ship ConfigHub variants.
Get correct variants, safe operations, immediate proof.

Primary Pages

1. Home

Purpose:

Explain the problem, show the happy path, and separate free public use from
managed ConfigHub operations.

Content:

• the promise: use public Helm charts, but make the resulting config explicit, variant-aware, reviewable, and observable;
• a five-stage adoption ladder: cub helm template, cub helm install, public cub installer catalog package, live parity proof, ConfigHub operations;
• proof counters drawn from generated status data, not hand-edited numbers;
• a "what is not claimed" link next to the proof counters;
• start buttons: inspect catalog, try Redis, open variants, open apps and operations, and read the serious-chart proof;
• clear note that Helm remains the source chart ecosystem.

2. Helm Catalog

Purpose:

Show what a user can install or inspect.

Content:

• chart cards grouped by category;
• recommended first variant;
• supported variants;
• chart version and latest-version status;
• proof status;
• complete-core status and missing lanes;
• hook, CRD, webhook, secret, storage, and extension-slot flags;
• pain/risk summary;
• free/managed route: public catalog, promotion review, better base needed, limitation decision, or managed overlay;
• install/download action.

Data source:

data/master-catalog-matrix/matrix.csv
data/chart-use-guide/chart-use-guide.csv
data/top100-user-readiness/readiness.csv
data/production-support-decisions/decisions.csv
recipes/*/*/*/CATALOG.md

3. Chart Page

Purpose:

Turn one chart into a confident install decision.

Content:

• chart/version/source digest;
• supported variants;
• "what Helm pain this absorbs";
• rendered object inventory;
• regular Helm equivalence result;
• scan/gate status;
• live e2e evidence;
• ConfigHub proof receipts;
• known production dispositions;
• hard quirks and the exact route for each: rendered, target fact, lifecycle route, observed, blocked, refused, or not applicable;
• previous-version/legacy-patch link when relevant.

Data source:

recipes/<repo>/<chart>/<version>/
runs/<chart>-confighub-proof/latest/
runs/top20-local-kind/<chart-variant>/
data/master-catalog-matrix/matrix.csv
data/hook-disposition/top100-hook-dispositions.csv

Detailed spec: per-chart-fact-sheet-spec.md - the full section list, the exact data source per item, a solid / needs-more-testing status for each, and the "level of support vs evidence depth" rule.

4. Variants

Purpose:

Explain base variants, derived ConfigHub variants, promotion, and the boundary
between render-time choices and post-render refinements.

Content:

• when to create a base variant;
• when to create a derived variant;
• when to go back to the recipe/import path;
• first command flow: cub installer setup, upload, cub variant create, cub variant promote --dry-run;
• links to Redis, Prometheus, kube-prometheus-stack, and promotion receipts;
• honest note that promotion proof is row-specific and must stay visible in the matrix.

Base variant: changes Helm render input or object shape.
Derived ConfigHub variant: changes target, labels, approvals, links, scans,
or selected post-render fields after upload.
Delivery prerequisite: changes what must exist before Argo/Flux/apply can
converge.

Current generated page:

site/variants.html

5. Apps

Purpose:

Show what happens after the first install: public charts, custom apps, stacks,
and platform groups become one managed desired-state graph with variants and
promotion.

Content:

• six-stage path from inspect to serverless try-out to sign-up to server try-out to day-2 operations to managed/private use;
• explicit Day 0 / Day 1 distinction for public charts, custom apps, stacks, platform groups, variants, and promotion;
• links to variants, custom apps, operations, private paths, and chart pages;
• clear free/account/paid boundary.

Current generated page:

site/journey.html

6. Custom Apps And Stacks

Purpose:

Provide a deeper example inside Apps for cases where a real application
is several public charts plus a custom service, wrapper chart, overlay values,
private inputs, target facts, or existing live state.

Content:

• where each piece belongs: public chart, custom app Unit, wrapper chart, overlay values, derived variant, private catalog;
• Day 0 composition versus Day 1 change management;
• links to the managed overlay golden, app-readiness surface, custom overlays guide, and private paths;
• clear note that private sources and production responsibility are managed product lanes.

Current generated page:

site/custom-apps.html

7. Ops

Purpose:

Turn the strongest post-render product functions into one readable product
page: scans, gates, delivery, observation, adoption, upgrades, rollback, bulk
patching, and fleet operations.

Content:

• operation cards with status, boundary, command, value, and evidence link;
• bulk scan, bulk patch, fleet operations, upgrade, rollback, and observation as productisation targets;
• clear note that variants and promotion are application SDLC, while operations makes releases governed and observable;
• clear watch/planned wording where receipts or product implementation are not complete.

Current generated page:

site/operations.html

8. FAQ

Purpose:

Answer hard skeptical questions without making the first screen a proof lab.

Content:

• hooks, secrets, target prerequisites, GitOps false green, upgrades, custom values, free versus managed, and what is not claimed;
• any unanswered question becomes a P1 hard-question issue rather than vague copy.

Current generated page:

site/hard-questions.html

9. Docs

Purpose:

Keep deeper doctrine available without overwhelming first-time users.

Start with:

• choose your path;
• choosing commands;
• creating variants;
• custom overlays;
• verification lanes;
• hook lifecycle strategy.

Current generated page:

site/docs.html

10. Database And Deep Proof

Purpose:

Make skeptical reviewers trust the catalog without turning proof into the main
product navigation.

Content:

• Helm Catalog links to site/matrix.html as the current database of supported charts and variants;
• Docs links to generated evidence and claims register;
• site/proof.html remains a deep reviewer reference, not a main menu item;
• proof counters and generated status should come from generated data, not hand-maintained copy.

Current generated pages:

site/matrix.html
site/proof.html

Productisation And Test Roadmap

The website should track the features that carry the most product value, not only the proof lanes. Each feature needs accommodation, tests, and a product surface.

public page -> concise user flow -> evidence surface -> verifier or receipt -> product surface

Planning docs should stay private/internal unless they are distilled into one of these product pages. Proof data is the evidence underneath; the public product path should stay chart-first, application-first, and operation-aware.

Free / Authenticated Boundary

The website can allow low-friction browsing without letting anonymous users abuse infrastructure:

The free path must be genuinely useful. It should let a Helm user inspect a popular chart, pull a public package, run the verifier, and understand the supported variants without needing a sales conversation. Authentication becomes necessary when the service stores private inputs, creates private variants, uses managed compute, publishes to managed OCI, or provides support/SLA.

Website UX Doctrine

• Lead with the happy path, not the artifact taxonomy.
• Show charts first, variants underneath.
• Every claim links to a receipt or generated artifact.
• "Latest available" and "supported proof version" must be visibly separate.
• If a chart is popular but production-disposition-blocked, say so clearly.
• Keep Kubara/private-overlay workflows out of the free public catalog unless they are explicitly marked managed examples.
• Make hard cases visible early. Kube-prometheus-stack should be the serious chart proof, not an appendix.
• Do not make proof receipts feel like the product. The product path is choose, install, inspect, verify, operate. Receipts are the evidence behind it.
• Do not imply that signatures equal safety. Signatures prove integrity and origin; scans, policies, support scope, and live receipts carry safety claims.

First Website Slice

Build the launch website from generated repo data:

/                       home
/catalog                chart catalog
/catalog/redis          Redis chart page
/catalog/redis/default  Redis default variant page
/catalog/kube-prometheus-stack serious chart page
/proof                  how the harness works
/status                 master matrix / proof status
/pricing-or-tiers       free, authenticated, managed, enterprise
/docs                   selected doctrine links

The Redis page should be the polished first demo. NGINX should show the small web/live path. Kube-prometheus-stack should show the serious chart proof. The next chart pages should be PostgreSQL, cert-manager, External Secrets, ingress-nginx, and Argo Rollouts.

Launch acceptance:

• the home page explains the value without using internal harness vocabulary;
• the catalog page can be filtered by "ready to try", "needs prerequisites", "operator review", "needs better base", and "not ready";
• every chart page links to source chart URL, recipe URL, package base, variant file, proof receipts, known quirks, and next action;
• the status page shows generated timestamp, matrix link, and top residues;
• the proof page includes the current hard limits, not only successes;
• all pages are generated or verified by npm run site:verify.