fix(ci): resolve RTL scope to public components

[cixzhang]

Cause

pr-rtl received source-directory names from PR analysis. That works for conventional PascalCase component folders, but a lowercase source group such as packages/core/src/intl/ was reported as intl. The RTL audit could not associate that name with the public IntlProvider component, so its fail-closed coverage result was unknown/intl instead of identifying the actual new component with no RTL evidence.

What changed

PR analysis now emits a dedicated rtlComponents scope:

• conventional component folders keep their existing name;
• lowercase source groups derive renderable component names from PascalCase .tsx files;
• unresolved groups are preserved so the audit still fails closed rather than silently skipping them.

The RTL CI job consumes this scope with a fallback for older analysis artifacts. Other PR-reporting and accessibility component names remain unchanged.

User impact

RTL findings now name the component contributors need to fix. For #5684, the audit scope becomes AlertDialog,IntlProvider rather than AlertDialog,intl; the new provider still correctly remains a coverage gap until it has a story or reviewed N/A evidence. This does not baseline or suppress the finding.

Testing

• npx --yes pnpm@11.10.0 exec vitest run .github/scripts/analyze-pr.test.mjs --testTimeout=120000
• pre-commit repository checks
• reproduced feat(i18n): introduce new design for IntlProvider and useIntl #5684 analysis against its current head: rtlComponents = ["AlertDialog", "IntlProvider"]
• ran the Chromium RTL audit against the failing Storybook artifact with the corrected scope; no visual RTL regression was found, and the remaining fail-closed finding names IntlProvider

No changeset: CI analysis only; no package behavior or public API change.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Sep 3, 2026 5:13pm UTC

[cixzhang]

Semantic verdict: request changes

A contributor can still get a false RTL coverage gap for a private helper. The resolver now treats every PascalCase .tsx file in a lowercase group as public: in a group whose barrel exports only PublicProvider, my probe also emitted PrivateHelper. The existing component-discovery guard rejects this filename-only rule for exactly that reason.

Can we derive the names from the group’s public barrel, preserve the unresolved-group fallback, and add an unexported PascalCase helper to the regression test?

[Reviewed by Robohands]

[github-actions]

PR Analysis Report

📚 Storybook Preview

View Storybook for this PR
GitHub Pages may take up to a minute to hydrate after deploy.

🧪 Sandbox Preview

View Sandbox for this PR
GitHub Pages may take up to a minute to hydrate after deploy.

No new or modified components detected.

Bundle Size Summary

No component packages changed.

Accessibility Audit

Status: No accessibility violations detected.

---

_{Generated by PR Enrichment workflow | Storybook | Sandbox | View full report}

[cixzhang]

Semantic verdict: request changes

Thanks — the current head still scopes RTL by PascalCase filenames rather than the public export surface. In a lowercase group whose barrel exports only IntlProvider, the analyzer also emits an unexported PrivateHelper, so a contributor gets a false coverage gap for code nobody can import.

Could we derive rtlComponents from the group’s public barrel, preserve the unresolved-group fallback, and add that private-helper regression case?

[Reviewed by Robohands]