Latest Top-20 Refresh Plan

The top-20 catalog is not a one-time screenshot. It must stay current without silently changing what users deploy.

Current snapshot:

npm run top20:latest-refresh

Outputs:

data/latest-top20-refresh/review.csv
data/latest-top20-refresh/summary.md
data/latest-top20-refresh/work-orders.md
data/latest-top20-refresh/variant-work-orders.yaml
data/latest-top20-refresh/candidates/
data/latest-top20-refresh/promotion-readiness.md
data/latest-top20-refresh/promotion-readiness.csv
data/latest-top20-refresh/replacement-decisions/summary.md
data/latest-top20-refresh/replacement-decisions/decisions.csv

What The Snapshot Means

The snapshot compares the chart versions in the current supported top-20 catalog with the latest chart versions returned by Helm after helm repo update.

It does not mutate recipes or packages.

It answers:

Which supported catalog proofs are still on the latest chart?
Which charts need a new versioned proof path?
Which variant/product work should happen next even when the chart is current?

Current Result

As of the committed snapshot:

14 / 20 top-chart proofs are on the latest chart version
6 / 20 have newer upstream chart versions available

The current update rows are:

Candidate Proof Status

The retained update candidates now have proof-complete root paths under:

recipes/
packages/

The retained candidate source artifacts remain under:

data/latest-top20-refresh/candidates/

Verify them with:

npm run top20:latest-candidates:verify
npm run top20:latest-promote-root-paths:verify
npm run top20:latest-promotion-readiness:verify
npm run top20:latest-replacement-decisions:verify

These candidate artifacts prove the updated chart versions have their own recipe/package paths, rendered objects, Helm-equivalence evidence, ConfigHub proof receipts, live e2e observation receipts, live parity receipts, production-disposition boundary, catalog status, and top-100/top-500 refresh coverage.

They are not catalog-supported replacements. The replacement-decision output is the handoff checklist for choosing whether to replace, defer, or keep both the current supported version and the proof-complete candidate. If a retained candidate is already behind the latest upstream version, refresh or explicitly retain it before making a replacement decision.

Promotion Rule

A newer Helm chart version is only a candidate.

It becomes a supported ConfigHub catalog entry only when the new version has:

• a new recipes/<repo>/<chart>/<version>/ path;
• a new packages/<repo>/<chart>/<version>/ path;
• source lock, dependency lock, effective values, value model, control points, Helm plan, dossier, and pain report;
• supported install variants and rendered revision artifacts;
• regular Helm versus cub installer equivalence receipts;
• scan/gate receipts and installer-package receipts;
• ConfigHub upload, function scan, safe-ops, and server-side variant receipts;
• live e2e observation receipts;
• updated CATALOG.md, production disposition, top-100, and top-500 outputs.

No public catalog row should roll forward implicitly.

Redis Work In This Wave

Redis is already current at bitnami/redis@25.5.3.

The next Redis work is therefore variant-product proof, not chart-version refresh:

Redis/default -> Redis/prod-us-east
Redis/default -> Redis/prod-eu-west

That proof should use:

• the reviewed redis/default cub installer base;
• cub variant create for clone/link;
• the Variant Creator contract for UX/AX/FX consistency;
• TransformPaths/functions/placeholders only for allowed post-render refinements;
• target facts for the existing Redis Secret reference where used;
• receipts for clone, mutation sources, checks, approvals, and observations.

If a Redis choice changes the rendered Kubernetes object set, it is not a promotion variant. It goes back to the cub installer recipe/package path.

Kubara Overlay Work In This Wave

Kubara-style managed apps are not simply "public chart at latest version."

The import unit is usually:

managed wrapper chart
  + platform values
  + customer overlay values
  + dependency closure
  + render context
  + target facts

The first planned golden remains:

ExternalDNS/managed-aws -> ExternalDNS/customer-acme-prod

This must prove:

• customer overlay choices are classified before creation;
• rendered-object changes become new cub installer bases;
• post-render refinements become ConfigHub variants;
• ConfigHub Promotion shows the managed base and customer variant;
• receipts explain what changed and what remained target/live dependent.

This is a managed/commercial lane, not a free static catalog lane, because it uses private overlay values, target facts, approvals, gates, and receipts.

Order Of Work

1. Review the three latest-aligned retained candidates for target-scoped replacement decisions.
2. Refresh the three superseded retained candidates to the newer upstream versions or explicitly keep them for legacy patch and rollback evidence.
3. Create a new Redis update candidate for bitnami/redis@27.0.0.
4. Keep previous chart versions available for legacy patch and rollback review.
5. Generate and verify the Redis promotion Creator golden and receipts.
6. Generate and verify the ExternalDNS/Kubara managed overlay golden.
7. Recalculate top-100 and top-500 data from any changed catalog state.
8. Publish the website/catalog view from the generated chart catalog and proof data.

Review Command

npm run top20:latest-refresh
npm run top20:latest-refresh:verify
npm run top20:latest-promotion-readiness:verify
npm run top20:latest-replacement-decisions:verify
npm run refresh:survival:verify
npm run variant-goldens:verify
npm run top100:catalog:verify
npm run top500:catalog:verify
npm run site:verify

The refresh command depends on the locally configured Helm repositories and should be rerun after helm repo update.