Status Dashboard

This generated dashboard is the short front door for current project status. It joins the top100 readiness, top500 evidence map, proof lane, graph bridge, quirk, hook, GitOps, and live-parity tables without replacing them.

Use this page to answer:

What is working now?
Which claims are only partial?
Where are the main residues?
Which detailed CSV should I open next?

Current State

Next Work Queues

Use this section when the question is what should move next, not when the question is whether a specific receipt passed. Workstreams can overlap: one chart can need image, scan, lifecycle, and fresh evidence work before it becomes production-supported for a target scope.

Top100 Catalog Work

Hard Proof Gap Work

These rows are the top assignment queue for public charts where source-scan quirks, dependency closure, or hook routing could damage trust if overclaimed.

Remote Dependency Closure Work

These rows close provenance and refresh-survival gaps for public charts that pull remote, vendored, or non-exact dependencies.

Top20 Production Support Work

Latest Refresh Work

These rows are the current upstream-update queue for the supported top-20 catalog. A row here does not replace the supported catalog version by itself. It identifies the next proof or review action before a replacement can be considered.

Live Parity Work

Active Proof Queue

These are the current live parity rows where another run is not the first useful step. When a support artifact exists, it is linked here; otherwise the row still needs a support artifact or a direct receipt review before rerun.

Local Live Non-Pass Triage

Every chart/base row now has local-kind observation evidence. Passing rows prove that the rendered objects converged on the tested target. Non-pass rows are classified here so they become next actions rather than vague failures.

Use local-live-triage/summary.md for the full table with receipts and per-row next actions.

Hook And Lifecycle Work

Spreadsheet forms: next-work-queues.csv and active-proof-queue.csv.

Chart Use Answers

The Chart Use Guide is the user-facing route into the top-100 data. It answers whether a chart is ready to try from the public catalog, needs promotion review, needs a better base variant, or needs a limitation decision first.

Use chart-use-guide/summary.md for one row per top-100 chart and the next command or file to open.

Top100 Readiness

The top100 is model-supported, but not uniformly live-proven. Use top100-readiness/readiness.csv for one row per chart, and outcome-coverage/base-outcomes.csv for exact chart/base lane status.

Top500 Evidence Map

The top500 table is retained source reconnaissance joined to the current recipe/package corpus. It shows which retained source-scan rows now have current proof, which rows only have source facts, and where the retained source version differs from the maintained recipe version.

Use top500-catalog-analysis/summary.md for the narrative and top500-catalog-analysis/review.csv for one row per retained source-scan chart.

Top20 Catalog Status

This is the compact chart-by-chart view for the public catalog. It shows the supported base variants, current evidence strength, and lane counts. The CSV also includes each chart's feature summary for hooks, CRDs, generated Secrets, webhooks, values schemas, and other tracked quirks. Use top20-status.csv when you want the same data in a spreadsheet.

The table is deliberately lane-specific. A chart can be useful today without every lane passing for every base variant. The exact per-base rows are in outcome-coverage/base-outcomes.csv. The Base readiness column is generated from top20-base-readiness/base-readiness.csv, which is the better source when the question is which base variant to try first.

Live And Parity Residue

Non-pass live receipts are useful evidence. They usually identify a target prerequisite, runtime behavior, or provisioning boundary rather than a render parity failure.

Current semantic parity defect receipts:

ConfigHub/OCI live comparison: 0/199
two-cluster kind parity:       16/179

The two-cluster kind parity lane is the cleanest live comparison for chart/base rows: regular Helm is applied to one vanilla kind cluster and the cub installer rendered objects are applied to another vanilla kind cluster. The receipts then compare the live outcomes. Use live-kind-parity/summary.csv for those rows.

Live Parity Next Actions

The rerun plan groups non-pass rows by the work needed before another rerun is useful.

Use live-parity-rerun-plan/summary.md for the exact row, command, receipt, diagnosis, and follow-up.

Current ConfigHub/OCI live parity non-pass receipts:

Current two-cluster kind parity non-pass receipts:

Production Disposition Boundary

The top-20 catalog entries are currently supported for the declared local-test scope. Production support is tracked separately. A review-ready row has accepted dispositions for scan/gate warnings, lifecycle risks, target facts, storage policy, RBAC, webhook behavior, and extension slots. Final production support is recorded only in the target-scoped support decision artifacts.

Use production-disposition/summary.md for the full top-20 disposition table and scan-disposition-workdown/summary.md for the scan warning routes. Use production-support-decisions/summary.md for target-scoped support decision artifacts.

Derived Variant Evidence

Derived ConfigHub variants are the post-render half of the model. They start from reviewed uploaded bases and use cub variant create plus ConfigHub metadata, targets, gates, links, checks, and receipts. They do not rerender Helm.

The golden rows are in variant-goldens/derived-expansion-wave/work-orders.csv. Live create receipts are in runs/derived-variant-execution, and target-bound receipts are in runs/derived-variant-target-bound.

Quirk And Hook Residue

Extension Slot Coverage

Extension slots are Helm inputs that can inject raw manifests, templated snippets, config blocks, sidecars, extra volumes, or chart-specific config files. They are useful, but a populated slot changes the install shape. The supported catalog route is to keep them empty or controlled in the first base, then create a reviewed cub installer base when a slot is populated.

Use extension-slots/summary.md for the full NGINX-style extension-slot report.

Hook Residue

Hook rows are not support claims. Route-selected means the chart has an explicit handling plan; lifecycle-observed means that plan has runtime or execution evidence. The hook doctrine is Seven-Stage Helm Lifecycle and Hook Lifecycle Strategy.

The generated boundary table separates hook queue rows from hook-like controller lifecycle observations:

Open lifecycle-boundary/summary.md when the question is whether a row proves hook execution or only proves controller lifecycle observation.

How To Use This

Regenerate:

npm run status:dashboard
npm run status:dashboard:verify