UNOFFICIAL/EXPERIMENTAL. This is the canonical roadmap index for helm-expt. It does not replace generated status surfaces or GitHub issues. It explains the current product direction, the active workstreams, and which planning files are authoritative for each kind of question.
Updated: 2026-07-27.
How To Read The Roadmap
Use generated data for moving status and use GitHub issues for execution. Use this file for priority, ownership, and product shape.
| Question | Source |
|---|---|
| How much of the agreed Top 50 is complete? | Top 50 Completion Plan. |
| What should we work on next? | This roadmap, Next Execution Plan, and GitHub issues. |
| What is the state of one chart, version, and variant? | Master Catalog Matrix. |
| Which claims are backed, partial, planned, or refused? | Claims Register. |
| Which outcome is promised and how is it tested? | Outcome Evidence Contract. |
| Which public pages must stay truthful? | chart-claim-integrity:verify and site:ux:verify. |
| Which historical notes explain how we got here? | Planning files marked as handovers, dated audits, or archive material. |
Do not copy live counts into roadmap prose. Counts belong in generated data.
Current Product Goal
helm-expt should help a person turn configuration they already use into a reviewed, deployable OCI package, then show why ConfigHub is useful after that:
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.
Start with Helm first, then support AICR, cub installer packages, existing OCI, and Kubernetes YAML.
Let people inspect, test, and produce public OCI without a ConfigHub account.
Record source inputs, exact objects, prerequisites, hooks, CRDs, checks, and receipts.
Let a team claim the reviewed result in ConfigHub when it needs shared history, variants, approvals, promotions, or fleet rollout.
Publish exact reviewed objects as OCI for Argo CD, Flux, or direct apply.
Keep unsupported cases and missing evidence visible.Helm remains the first and deepest path. The wider boundary is:
source -> inspect and test -> OCI
OCI -> inspect or change -> OCI
OCI -> ConfigHub -> reviewed variants and operations -> OCI -> deliveryThe proof machinery supports that story. It should not be the first thing a new visitor has to understand.
Active Workstreams
| Workstream | Current objective | Primary surfaces | Main trackers |
|---|---|---|---|
| Public website and guides | Make the site clear enough for a new Helm user, with short guide pages and deeper docs one click away. | site/*.html, Dedicated Website Plan, persona UX audits. | #679, #753. |
| Chart catalog and matrix | Keep the top-100 chart catalog useful, honest, and navigable by chart/version/base/variant. | Master Catalog Matrix, Chart Use Guide, Top-100 Readiness. | #106, #113, #114. |
| Live evidence and hard charts | Keep hard chart behavior receipted: CRDs, webhooks, hooks, target facts, generated facts, storage, runtime health, and GitOps sync. | Current Proof Status, Live Parity Rerun Plan, Lifecycle Boundary. | #248, #714, #882. |
| Variants and promotion | Show base variants, derived ConfigHub variants, promotion, and app workflows as ordinary ConfigHub value. | Creating Variants, Variant Promotion Model, Variant Promotion. | #143-#153, #948. |
| Render-input capture and renderer integration | Ensure one-shot Helm adoption records the inputs needed for repeatable render, upgrade, and rollback, and align with Argo CD / Flux renderer sources where those are already the source of truth. | Choosing Commands, Why This Exists, ConfigHub Data Model. | Upstream ConfigHub #3393, #4369, helm-expt #76. |
| ConfigHub/cub product blockers | Keep product gaps exposed by the corpus linked to upstream implementation work without overstating what helm-expt itself owns. | Issue Backlog, Variant Promotion Closeout. | #682, upstream ConfigHub issue #4609. |
| Errors, omissions, and UX guards | Prevent false chart-page claims and placeholder leaks from returning. | Chart Claim Integrity Audit, Test Map. | PR #1024, #1025, #1026, #1027, PR #1028. |
| AI-assisted apps and operations | Turn the ConfigHub data model into a substrate for AI-assisted app changes, RBAC/task-specific tools, and safer operations. | AI-Assisted Helm Changes, Broken Chart Triage, future app examples. | #949 and future app/example issues. |
Release Guardrails
The broad verifier should prevent regressions in the claims that users see.
| Guard | Purpose |
|---|---|
docs:verify | Every authored doc has a declared role and valid local links. |
site:verify | Generated site pages match the site generator. |
site:ux:verify | Chart pages do not leak unresolved action placeholders or raw work-dir placeholders. |
chart-claim-integrity:verify | Chart pages do not make claims contradicted by their cited receipts. |
npm-scripts:catalog:verify | The npm script catalog matches package.json. |
Run scoped checks while editing. Use npm run verify as the broad release gate after focused checks pass. A passing verifier means committed evidence is self-consistent; it does not replace a fresh live run.
Planning File Roles
The active planning corpus has three tiers.
| Tier | Files | Role |
|---|---|---|
| Canonical | This file, Top 50 Completion Plan, Issue Backlog, Next Execution Plan. | Current roadmap, evidence-linked completion status, issue groups, and launch workstreams. The Top 50 source is config-catalog/top50.yaml. |
| Lane-specific | Dedicated Website Plan, Robust Sceptic Plan, Fuzz Corpus Tests Roadmap, Hook Route Execution Plan, Maintenance Strategy, Verified Install Commercial Model. | Active product or test lanes. These should link back here when priorities change. |
| Snapshot or review input | Handover docs, dated persona audits, dated claim audits, independent review briefs, older execution plans. | Evidence, review history, or context. These are not authoritative for current counts. |
When adding a new planning file, add its role to Documentation Map and decide whether it is canonical, lane-specific, or a snapshot.
Roadmap Cleanup Rules
- Do not create another broad roadmap without updating this file.
- Dated files are logs or audits unless they explicitly say otherwise.
- Generated data remains the authority for counts.
- GitHub remains the authority for execution state.
- User-facing claims must be backed by receipts, generated data, or an explicit planned/refused status.
- If a planning note is no longer current, either archive it or add a short status note at the top.
Near-Term Cleanup Still Worth Doing
| Item | Why |
|---|---|
Split the very long npm run verify script into named suites. | The current command is hard to inspect and easy to conflict on. Tracked in #1029. |
| Continue archiving old handoff snapshots. | The repo has many useful historical notes that should not look like current instructions. |
| Keep website copy smaller than the docs behind it. | The site should explain the product path; detailed proof belongs in guides and generated data. |
| Keep chart-page warnings visible but less scary. | Warnings are product honesty, not failure, when they tell users what remains to stage or decide. |