Remote Dependency Closure

This generated report joins public top-100 source-scan dependency risk to the dependency locks in maintained recipe artifacts.

It answers:

Which popular charts depend on remote or vendored subcharts, and what exact
dependency closure evidence do we already have?

This is not a live dependency resolver and not a support claim. It uses the committed source scan, maintained recipe metadata, and dependency-lock.yaml files.

Current Reading

source top-100 rows with remote, vendored, or non-exact dependencies: 49
rows with a maintained dependency lock:                         19/49
source-only rows without a maintained recipe:                   30/49
locked rows with dependencies but no dependency provenance:      0/49
non-exact dependency rows frozen to Chart.lock:                  9/49
frozen range rows with refresh-survival evidence:                4/9
P0 source rows:                                                  33
active P0 work rows:                                             21
keep-current rows:                                               14
P1 source rows:                                                  14
P2 source rows:                                                  2

Closure Status

Workstreams

Highest Priority Active Work Rows

Most Common Locked Repositories

How To Use This

• If the row has source-version-lock-present, the maintained recipe has a dependency lock for the same chart version seen in the source scan.
• If the row has modeled-version-lock-present, the maintained recipe has a lock for the catalog version, but the source scan and model version differ. Use refresh-survival evidence before replacing or promoting the chart.
• If join_status is chart-name-version-alias, the source repository and maintained recipe repository differ, but the chart name and version match. Keep that alias visible when presenting catalog coverage.
• If the row is source-only-no-maintained-recipe, create a recipe/import candidate before making catalog claims.
• If dependencies are locked but lock_dependency_provenance is missing, backfill a Chart.lock digest or explicitly document the source of the dependency list.
• If dependency_range_policy is freeze-to-chart-lock, the maintained path does not resolve dependency ranges during install. It uses the committed dependency lock, and any re-resolution must happen through a refresh candidate with its own proof.
• If refresh_survival_status is present, the row is connected to the top-20 refresh-survival surface. That is update-review evidence, not a live upgrade proof.

Files

Regenerate:

npm run remote-deps:closure
npm run remote-deps:closure:verify