[audit] Baseline pre-existing RTL applicability gaps
- Dominant language
- TypeScript
- Stars
- 13.1k
- Forks
- 1.1k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 669
Description
## Problem
The applicability contract added in #5365 began with an empty verified-N/A registry. The first full-library sweep reports more than 200 unexplained all-N/A components, almost all of which predate the contract.
Filtered `pr-rtl` runs currently return nonzero whenever a touched component is one of those pre-existing gaps. That forces unrelated component changes to add an N/A declaration or a new target before their own CI can become clean, and mixes rollout debt with regressions introduced by the PR.
## Expected rollout
- Snapshot the unresolved set from a clean full-library run as explicit coverage debt, not as verified N/A.
- Keep baseline debt visible in PR and weekly reports without treating it as newly introduced.
- Continue to fail new coverage gaps, RTL behavior failures, stale verified-N/A declarations, malformed registries, and missing curated stories.
- Report a baseline entry as stale once the component becomes measured, is verified N/A, or leaves the component roster, so the debt list can only shrink.
- Keep newly added components fail-closed when they have neither applicable measurement nor a reviewed N/A declaration.
## Acceptance criteria
- A filtered run over a pre-existing baseline gap reports known debt and exits successfully when no other finding exists.
- The same run over an unlisted gap exits nonzero.
- A baseline entry that becomes measured or verified N/A is reported stale and exits nonzero until removed.
- The full weekly summary separates known coverage debt from new gaps and actual RTL failures.
- Unit tests cover all transitions, including removed components and invalid baseline entries.
Contributor guide
Research direction
Read the applicability contract introduced in #5365, then run a clean full-library sweep and a filtered pr-rtl run to observe current findings. Trace the verified-N/A registry, PR and weekly reporting paths, and the unit-test entry points named in the issue. Done means baseline debt and new failures are separated, all listed transitions are covered, and invalid or stale entries fail as specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- ci-cd, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100