Release Collector full run can drop APIs after js-yaml 5 parser failures

[hdamker]

Problem description

A full Release Collector run generated PR #262 with removals from
data/releases-master.yaml and the derived reports. The removals do not appear
to come from CAMARA repository release changes. They appear to come from the
workflow installing unpinned js-yaml, which started resolving to
js-yaml@5.0.0 after that version was published on 2026-06-20.

The previous successful full run on 2026-06-19 resolved to js-yaml@4.2.0.
With js-yaml@5.0.0, several historical OpenAPI files fail YAML parsing with
deficient indentation errors. analyze-release.js currently catches those
per-file parse errors and continues, so the affected OpenAPI files are skipped.
In a full run, update-master.js then rebuilds the master data with the smaller
API lists.

PR #262 drops these API entries from release metadata:

• ConnectedNetworkType r1.1 and r1.2: drops
  connected-network-type-subscriptions
• DeviceReachabilityStatus r1.1 and r1.2: drops
  device-reachability-status-subscriptions
• DeviceRoamingStatus r1.1 and r1.2: drops
  device-roaming-status-subscriptions
• DeviceStatus r2.1 and r2.2: drops
  connected-network-type-subscriptions,
  device-reachability-status-subscriptions, and
  device-roaming-status-subscriptions
• TrafficInfluence r1.1: drops traffic-influence, leaving the release
  with an empty apis list

Expected action

Do not merge PR #262 as-is. First land a short hotfix that pins the Release
Collector workflow dependency back to js-yaml@4.2.0 and rerun the full
collector workflow for review.

As possible evolution after the hotfix, the Release Collector should consider
deterministic dependency management and safer legacy metadata extraction:

• add a workflows/release-collector/package.json and lockfile;
• switch collector jobs to npm ci;
• add Dependabot coverage for that package directory;
• log and persist enough run provenance to identify the workflow run, source
  SHA, Node/npm versions, and resolved dependency versions;
• make legacy OpenAPI analysis extract only the metadata the collector needs
  (info and servers) instead of parsing whole OpenAPI files;
• surface potential API removals in the workflow summary / PR body as review
  warnings, not as automatic workflow failures or automatic preservation of old
  data.

The metadata-only extraction approach is worth considering because native
release-metadata.yaml is already authoritative when present, and the OpenAPI
path is only needed for legacy releases. The collector does not need to validate
paths, schemas, examples, or callbacks to populate release metadata.

Additional context

There is a separate question about whether the stricter js-yaml@5.0.0
behavior should influence CAMARA linting or validation rules. That should be
handled separately in the tooling repository, because it affects validation
policy beyond the Release Collector.

[hdamker]

Hotfix status update:

• fix(release-collector): pin js-yaml dependency #264 pinned the Release Collector workflow installs to js-yaml@4.2.0 and was merged.
• Full Release Collector analysis/staging run #27911475018 completed successfully after the hotfix.
• The regenerated metadata PR Review: CAMARA release data updates from Release Collector bot #265 was reviewed and merged. The previously affected API entries were present; the PR only changed generated timestamps.
• Production deploy run #27911708976 completed successfully.

The immediate parser-induced data-drop risk is addressed. Follow-up hardening for deterministic dependency management, safer legacy metadata extraction, and better review diagnostics can continue separately under this issue.