Next catalog tasks - Helm catalog (distilled queue)

Created: 2026-06-02. A prioritized top-20 queue distilled from the detailed plans - next-execution-plan.md (P0/P1/P2 gates), agreed-execution-plan.md (doctrine), issue-backlog.md (GitHub issues), catalog-promotion-next-candidates.md (wave-2), and the next80 / production-disposition data. It does not replace them; it is the executive work queue over them.

Three newer planning inputs sharpen this queue:

• serverless-verified-install-plan.md defines the no-login wedge: resolve a public package, verify it locally, apply it, write an in-cluster receipt, and show where ConfigHub Server starts.
• verified-install-commercial-model.md defines the paid security and operations model: factory scans, image digest inventory, signed artifacts, refresh SLAs, private catalogs, and fleet-wide queries.
• robust-sceptic-plan.md defines the public attack model: every claim needs a receipt or route, and the next hard tests are claims-register maintenance, blast-radius accuracy, torture fixtures, environment matrices, and external reproduction.

Where we actually are (so the queue is honest)

• Use generated status surfaces for current counts: data/status-dashboard/summary.md, data/master-catalog-matrix/matrix.html, data/outcome-coverage/summary.md, and data/production-support-decisions/summary.md.
• cub variant create now exists and is the real current substrate for downstream ConfigHub variants. Local CLI truth also shows cub variant promote and cub variant upload; cub variant release is not current.
• The catalog proves base/render variants much more strongly than derived ConfigHub variants. That is now an explicit gap, not a side note: derived variants need enough goldens, tutorials, metrics, and receipts that users can see them doing useful work.
• 100/100 charts are supported at Level 2; 54/100 are variant-rich. The remaining catalog work is user-shaped variants, derived variants, production dispositions, and runtime/GitOps evidence, not basic proof creation.
• Current chart facts show 25 hard gaps for recommended extra capabilities: 15 existing-secret gaps (#113), 3 template-CRD/no-crds gaps (#114), 6 curated-variant lanes, and 1 other gap.
• Production support decisions, draft state, and work items are generated data, not hand-maintained queue text. P0 #76 is closed as a verifier-backed import-path definition; downstream cub installer import helm implementation remains product work.

Outcome standard for this queue

Each task below should be judged by the outcome it proves, not by whether a doc or script was added. The catalog target is:

Every supported Helm chart default and declared main choice is reproducible,
ConfigHub-reviewable, live-cluster verified, and tied to receipts.

For a task to be done, it should leave behind:

• a named scope, such as chart-choice rows, derived variants, or live lanes;
• committed evidence, such as receipts, generated matrices, or verified docs;
• a verifier that fails when the evidence is missing or stale;
• user-facing wording that does not claim more than the evidence proves.

Default-only proof is not enough when the catalog advertises a non-default main choice. Derived ConfigHub variants are not "supported" until the uploaded base-plus-derived-variant path has clone/check/mutation receipts and, where the task is about delivery, live observation.

The newer sceptic plan adds two cross-cutting outcomes:

Now - derived variants and current CLI truth

1. Make cub variant create the explicit derived-variant substrate (#143) - add the command-surface doc, update Tutorial 4, make UX proposals consistent, update why-this-exists.md, and add a lightweight command-surface verifier. Do not document non-existent cub variant subcommands as current.
2. Execute and deepen the derived-variant expansion wave (#144) - the generated derived-expansion-wave now names 10 derived variants across 5 reviewed bases; turn those work orders into full clone/check/mutation receipts without hidden Helm rerender.
3. Prove promotion and environment management with derived ConfigHub variants (#145) - base -> staging or prod using cub variant create, target/gates/observation policy, upstream links, and low-noise review.
4. Keep the closed #76 import contract executable - the Helm import path from cub helm install to durable cub installer recipes is defined and verified; next work is product implementation and broader managed-overlay examples.

Next - base variants, production depth, and facts

1. Wave-2 real base-variant promotion - add user-shaped base variants to the 5 selected proof-grade charts (traefik, external-dns, velero, istiod, kyverno): real recipe variant + package base + rendered revision + scan/gate + Helm-equivalence receipt each.
2. Production support decisions for the top-20 - use the accepted production dispositions as review input; record target scope, required live checks, and support policy before moving any chart from catalog-supported (local-test) toward production-supported.
3. Target facts beyond required Secrets - map existing-CRD, API availability, namespace, storage class, ingress class, runtime class to installer-native external requirements, provided facts, cluster singleton facts, and collectors.
4. Per-chart weirdness-and-mitigations notes - make hooks, CRDs, webhooks, lookup, generated secrets, required values, RBAC, stateful storage, upgrade, and rollback visible for every catalog-supported chart.

Configuration-As-Data Value Lanes Inside helm-expt

1. Fleet inventory and CMDB views (#146) - generated chart/component/variant/Space/Unit/target/status views, explicitly distinguishing base variants from derived ConfigHub variants.
2. Fleet-scale mutation and codemod workflows (#147) - prove one controlled change across a labeled fleet slice, with preview, checks, gates, receipts, and route-back-to-base cases.
3. Policy, compliance, and security posture reports (#148) - roll scan/gate findings up across the rendered desired-state catalog and route remediations to base variant, derived variant, or delivery prerequisite.
4. Dependency graph and impact analysis (#149) - show which derived variants, Units, targets, and gates are affected by a base/chart/policy/target change.
5. Creator and agentic intent flow over cub variant create (#150) - human intent first, current CLI substrate underneath, checks/gates/receipts included, no broad formal-model lane.

GitOps, release, and UI story

1. Variant release / OCI handoff semantics (#151) - release vs tag, :latest, gates, validation, OCI publication, and what is current versus planned.
2. Promotion UI expectations (#152) - less noisy diffs, upstream-added fields, inherited/no-op distinctions, prod-only gates/targets/observation policy, and no confusing preview treatment.
3. Argo/OCI GitOps tutorial positioning (#153) - make Tutorial 6 bridge-independent, Argo/OCI-oriented, and honest about which runtime/GitOps receipts exist. Use the generated outcome coverage as the corpus source of truth, and add the missing live Helm-vs-ConfigHub dual-deploy comparison lane: live helm install compared with ConfigHub via controller OCI and ConfigHub via kubectl/apply.

Breadth, day-2, and adoption surfaces

1. Promote high-value next80 charts from default-only to user-shaped variants, then attach derived variants where the change is post-render ConfigHub refinement rather than Helm render shape.
2. Image digest resolution and hook lifecycle lanes - pin mutable images or gate them (#99), and turn hook-using charts into per-chart lifecycle dispositions.
3. Day-2 upgrade/rollback, consequence preview, and existing-Helm diagnostics - keep #11, #15, #16, #30, and related receipt work aligned with derived-variant propagation.
4. Public story surfaces - keep the Helm pain docs, CATALOG.md, status dashboard, and static site current, and make the first-run path simple enough for outside testers.
5. Claims register and sceptic scoreboard - maintain data/claims-register/summary.md as the page that maps each public claim to the evidence lane, receipt, route, or refusal that supports it. It should stay current as serverless, commercial, lifecycle, scan, signing, and ConfigHub graph claims change.
6. Blast-radius prediction accuracy harness - extend data/blast-radius-accuracy/summary.md beyond the first kube-prometheus-stack and Redis base-pair seeds. For selected density hotspots, mutate one input, predict affected objects/fields from the value and graph data, rerender, diff, and publish misses/phantoms. Until a row is measured, blast-radius and inheritance claims should stay scoped as partial evidence.

Suggested order

Treat 1-3 as the immediate correction: helm-expt needs more visible derived variants, and the docs must line up with the real cub variant create command. Tasks 18, 21, and 22 are now the strongest trust builders: lifecycle evidence, claim-to-receipt maintenance, and measured blast-radius accuracy. Tasks 9-13 remain the highest-value configuration-as-data lanes inside this repo. GitOps, release, and promotion UI come next because they make the product story legible without asking humans to follow every low-level CLI step.