# APIService Proof Work Orders

This generated queue turns the APIService coverage report into assignable
proof work. APIService rows are high value because a rendered object can match
regular Helm while Kubernetes API aggregation still fails after apply.

## Work Queue

| Priority | Chart | Version | Current state | Work type | First task | Done when |
| ---: | --- | --- | --- | --- | --- | --- |
| 1 | `kedacore/keda` | 2.19.0 | `api-aggregation-observed` | `catalog-promotion-decision` | decide whether KEDA enters a catalog promotion wave using the two-cluster parity and ConfigHub OCI APIService receipts | KEDA has either a target-scoped production/support decision or a named reason to stay proof-grade |
| 2 | `k8s-dashboard/kubernetes-dashboard` | 7.14.0 | `source-detected-needs-recipe` | `recipe-import-plus-runtime-proof` | create the recipe/import candidate, then add APIService readiness and runtime aggregation checks | the chart has a maintained recipe row plus a pass/watch/refused aggregation receipt |
| 2 | `prometheus-community/prometheus-adapter` | 5.3.0 | `compatible-base-created-needs-standard-lanes` | `compatible-base-standard-lanes` | run ConfigHub proof, local live, live Helm-vs-ConfigHub parity, and APIService runtime contract for apiservice-v1-capability | the maintained apiservice-v1-capability base has live aggregation evidence through the standard lanes |
| 4 | `datadog/datadog` | 3.214.0 | `source-detected-needs-recipe` | `recipe-import-plus-runtime-proof` | create the recipe/import candidate, then add APIService readiness and runtime aggregation checks | the chart has a maintained recipe row plus a pass/watch/refused aggregation receipt |
| 5 | `bitnami/metrics-server` | 7.4.12 | `source-detected-needs-recipe` | `duplicate-chart-decision` | decide whether Bitnami Metrics Server should be imported separately or routed to the existing upstream Metrics Server catalog entry | the row is either modeled with APIService readiness or intentionally refused as a duplicate package route |
| 8 | `metrics-server/metrics-server` | 3.13.0 | `api-aggregation-observed` | `keep-fresh-pattern` | keep the Metrics Server runtime/GitOps aggregation receipt fresh and reuse its checks as the next chart pattern | existing api-aggregation-observed row remains fresh and reproducible |
| 9 | `fairwinds-stable/goldilocks` | 10.3.0 | `source-signal-not-rendered-in-maintained-bases` | `render-path-recorded` | no runtime APIService test is owed for the current maintained bases; create an APIService-enabled base only if product chooses to support that path | render-path notes record the conditional dependency path and the current bases remain APIService-free |
| 9 | `fairwinds-stable/vpa` | 4.11.0 | `source-signal-not-rendered-in-maintained-bases` | `render-path-recorded` | no runtime APIService test is owed for the current maintained bases; create an APIService-enabled base only if product chooses to support that path | render-path notes record the conditional dependency path and the current bases remain APIService-free |

## Receipt Contract

For a row to become `api-aggregation-observed`, it needs committed evidence
for the selected chart/base:

~~~text
rendered APIService object observed
backing workload observed
APIService Available=True observed
aggregated API query or target-specific equivalent observed
freshness timestamp recorded
~~~

KEDA now has both two-cluster parity and ConfigHub OCI/Argo API aggregation
evidence. Its next question is product scope: whether to promote it to a
catalog-supported entry for a named target profile, or keep it proof-grade.
Kubernetes Dashboard, Datadog, and Bitnami Metrics Server need import/catalog
decisions before a runtime aggregation receipt can close the gap. Prometheus
Adapter has a maintained recipe and the old bases render an APIService version
the tested target does not serve. The compatible `apiservice-v1-capability`
proof base now exists and has candidate live evidence; the next task is to run
the standard ConfigHub, live, parity, and APIService runtime lanes for that
maintained base. Goldilocks and
VPA have render-path notes: their current maintained bases do not render
APIService objects, so they do not owe runtime aggregation evidence unless a
future base enables that path.

## Files

| File | Purpose |
| --- | --- |
| `top100-apiservice-coverage.csv` | Current APIService state per top-100 source row. |
| `work-orders.csv` | Same queue in spreadsheet form. |
| `render-path-notes.md` | Render-path decisions for maintained rows whose APIService source signals are not active in current bases. |
| `target-compatibility-decisions.md` | Target-scoped compatibility decisions for maintained rows that render unsupported APIService versions. |
| `capability-profile-candidates.md` | Live-tested candidate bases for target-compatible APIService rendering. |
| `promotion-reviews/README.md` | APIService promotion-review packets for rows with enough runtime evidence to discuss catalog scope. |
| `data/runtime-gitops/receipts/metrics-server-metrics-server/default/latest.yaml` | Existing Metrics Server pattern receipt. |
| `data/runtime-gitops/receipts/kedacore-keda/default/latest.yaml` | KEDA ConfigHub OCI/Argo APIService receipt. |

Regenerate:

~~~sh
npm run apiservice:coverage
npm run apiservice:coverage:verify
~~~