Top-100 APIService Coverage

This generated report joins the source-scan APIService signal to maintained recipe/package rows and committed runtime evidence.

APIService objects need a stricter runtime contract than ordinary rendered objects. The desired object can match while Kubernetes API aggregation, CA trust, or backing service readiness still fails. This report therefore keeps four facts separate:

rendered APIService object observed
backing workload observed
Helm-vs-ConfigHub live parity observed
aggregated API availability observed

Current Reading

source top-100 APIService rows:          5
maintained APIService recipe rows:       5
maintained rows outside source top-100:  3
catalog-supported APIService rows:       1
rows with API aggregation observation:   2
rows with object/workload observation:   2
rows with two-cluster parity only:       0
rows still source-detected only:         3
aggregated API availability receipts:    2
compatible capability bases created:     1
capability-profile candidates observed:  1
active proof/import work orders:          5

Only rows with both an Available=True APIService condition and a successful aggregated API query receipt claim aggregated API availability. Today that evidence exists for Metrics Server and KEDA.

Prometheus Adapter also has a live-tested capability-profile route. Adding apiregistration.k8s.io/v1 to the render profile changes the chart's APIService from the refused apiregistration.k8s.io/v1beta1 object to a target-supported apiregistration.k8s.io/v1 object. That route is now a maintained proof base, apiservice-v1-capability; it still needs the normal ConfigHub, live, GitOps, and APIService runtime proof lanes before catalog promotion.

Coverage Status

Source Top-100 Rows

Maintained APIService Rows

This appendix includes maintained recipe/package rows with APIService source signals even when the source chart sits outside the source top-100 slice. It keeps target compatibility blockers visible without changing the source-top-100 counts above.

Maintained status counts:

Capability Profile Candidates

These rows are live-tested routes from a refused current base to a possible future maintained base. They are not current catalog support claims.

Runtime Contract

APIService rows become trusted runtime evidence only when one committed receipt records all of these facts for the selected chart/base:

Current contract rows:

How To Use This

• api-aggregation-observed means committed runtime evidence records both APIService Available=True and a successful aggregated API query.
• object-and-workload-observed means the APIService object and backing workload were observed in committed receipts. It is still not an aggregated API availability claim.
• two-cluster-parity-only means regular Helm and cub installer reached live semantic parity, but there is no dedicated APIService observation.
• modeled-needs-runtime-observation means recipe proof exists, but runtime APIService evidence is missing.
• target-api-version-refused means a target-scoped compatibility decision records that the rendered APIService API version is unsupported for the tested target profile. It is not a global chart refusal.
• compatible-base-created-needs-standard-lanes means a compatible maintained proof base exists, but it still needs ConfigHub proof, live, GitOps, parity, and APIService runtime evidence before stronger support claims.
• source-signal-not-rendered-in-maintained-bases means the source scan found APIService templates, but the maintained recipe bases do not render APIService objects. Runtime aggregation evidence is not owed until a base enables that path.
• source-detected-needs-recipe means the source scan found an APIService, but the chart is not yet a maintained recipe/package row.

Files

Regenerate:

npm run apiservice:coverage
npm run apiservice:coverage:verify