Problem
Frontend-related checks are currently split across several runners, but their ownership boundaries are not explicit enough to prevent duplicated or confusing findings.
Relevant checks from cli/src/core.ts and schema/src/check-meta.ts include:
reactaccessibilityhtml-qualityfrontend-healthstylingdesign-consistency
Evidence from existing runners:
react includes framework-specific patterns and XSS-style checks.accessibility inspects a11y concerns that may overlap JSX/static HTML parsing.html-quality checks static HTML metadata, headings, images, scripts, and SEO-like rules.frontend-health checks mixed frameworks/icon libraries, loading states, DOM nesting, image optimization, heavy imports, and inline base64.styling checks Stylelint/CSS, mixed styling approaches, hardcoded colors, spacing scale, !important, duplicate Tailwind strings, and inline styles.design-consistency is a pro/AI-style check with separate availability semantics.
PAGS reports exposed this as multiple frontend-like categories producing separate issue counts without a clear rule for which check owns JSX, static HTML artifacts, screenshot HTML, styling policy, accessibility, and design consistency.
Why this belongs in VCQA
This is analyzer ownership and taxonomy inside VCQA. App repos can fix individual findings, but they cannot make the frontend check family internally coherent.
Proposed ownership model
Suggested boundaries:
react: React correctness, hooks, component safety, React-specific APIs.security: XSS and dangerous sinks, with React-specific context from react if needed.accessibility: semantic and ARIA accessibility only.html-quality: static HTML documents intended for delivery, not JSX comments, screenshots, generated fixtures, or framework templates unless configured.frontend-health: product/runtime UX health such as loading/error/empty states and asset delivery.styling: CSS/Tailwind/style-system policy only.design-consistency: optional/pro visual consistency analysis, clearly separated from deterministic frontend checks.
Acceptance criteria
- Each frontend-related rule has one canonical owner.
- Cross-runner duplicate findings are suppressed or linked.
- Static artifact and generated-file exclusions apply consistently across all frontend checks.
- Docs explain which frontend check to configure or suppress for each class of finding.
- Regression fixtures cover JSX, static HTML, generated screenshot HTML, Tailwind, CSS modules, and sanitizer-backed React rendering.
Related issues
Related but not a duplicate:
Problem
Frontend-related checks are currently split across several runners, but their ownership boundaries are not explicit enough to prevent duplicated or confusing findings.
Relevant checks from
cli/src/core.tsandschema/src/check-meta.tsinclude:reactaccessibilityhtml-qualityfrontend-healthstylingdesign-consistencyEvidence from existing runners:
reactincludes framework-specific patterns and XSS-style checks.accessibilityinspects a11y concerns that may overlap JSX/static HTML parsing.html-qualitychecks static HTML metadata, headings, images, scripts, and SEO-like rules.frontend-healthchecks mixed frameworks/icon libraries, loading states, DOM nesting, image optimization, heavy imports, and inline base64.stylingchecks Stylelint/CSS, mixed styling approaches, hardcoded colors, spacing scale,!important, duplicate Tailwind strings, and inline styles.design-consistencyis a pro/AI-style check with separate availability semantics.PAGS reports exposed this as multiple frontend-like categories producing separate issue counts without a clear rule for which check owns JSX, static HTML artifacts, screenshot HTML, styling policy, accessibility, and design consistency.
Why this belongs in VCQA
This is analyzer ownership and taxonomy inside VCQA. App repos can fix individual findings, but they cannot make the frontend check family internally coherent.
Proposed ownership model
Suggested boundaries:
react: React correctness, hooks, component safety, React-specific APIs.security: XSS and dangerous sinks, with React-specific context fromreactif needed.accessibility: semantic and ARIA accessibility only.html-quality: static HTML documents intended for delivery, not JSX comments, screenshots, generated fixtures, or framework templates unless configured.frontend-health: product/runtime UX health such as loading/error/empty states and asset delivery.styling: CSS/Tailwind/style-system policy only.design-consistency: optional/pro visual consistency analysis, clearly separated from deterministic frontend checks.Acceptance criteria
Related issues
Related but not a duplicate: