A framework source file and an .html file containing byte-identical markup produce different findings. The framework path catches strictly fewer rules, so a clean scan of a component tree is not evidence that the tree is clean.
Repro
One body, written to five extensions with identical bytes:
<div>
<p style="font-size:8px">tiny functional label</p>
<a href="#" style="font-size:9px">Pause</a>
<h1 style="background:linear-gradient(90deg,#f00,#00f);-webkit-background-clip:text;color:transparent">Gradient heading</h1>
</div>
for ext in html astro jsx svelte vue; do printf %s "$BODY" > "probe.$ext"; done
for ext in html astro jsx svelte vue; do impeccable detect "probe.$ext"; done
| File |
Rules fired |
probe.html |
gradient-text, tiny-text, undersized-ui-text |
probe.astro |
gradient-text |
probe.jsx |
gradient-text |
probe.svelte |
gradient-text |
probe.vue |
gradient-text |
Same bytes. tiny-text and undersized-ui-text are silently dropped for all four framework extensions.
Impact on a real project
Scanning an Astro site’s source returned 0 findings across 11 .astro files:
impeccable detect packages/marketing/src/ → 0 anti-patterns found (exit 0)
Those same files demonstrably contain font-size: 8px, 9px and 10px — the exact values the rules above exist to catch — and the browser/URL scan of the built output found them. exit 0 on a component tree therefore reads as a clean bill of health when it is coverage loss.
That is the real harm: a user who scans src/ and sees zero has no signal that the scan was shallow.
Expected
Either bring the framework-file path up to parity with .html for rules that only need markup plus inline style, or — if parity is not practical — make the reduced coverage explicit in the output, e.g. a line stating which rule families were skipped for these extensions, so 0 findings cannot be mistaken for no problems.
Environment
- skill
4.3.1, engine 0.1.5 (darwin-arm64), macOS 15.6
- The extension allowlist in the binary includes
astro, jsx/tsx, svelte, vue, mdx, php, erb, hbs, so this likely affects every non-HTML template language it accepts
A framework source file and an
.htmlfile containing byte-identical markup produce different findings. The framework path catches strictly fewer rules, so a clean scan of a component tree is not evidence that the tree is clean.Repro
One body, written to five extensions with identical bytes:
probe.htmlgradient-text,tiny-text,undersized-ui-textprobe.astrogradient-textprobe.jsxgradient-textprobe.sveltegradient-textprobe.vuegradient-textSame bytes.
tiny-textandundersized-ui-textare silently dropped for all four framework extensions.Impact on a real project
Scanning an Astro site’s source returned 0 findings across 11
.astrofiles:Those same files demonstrably contain
font-size: 8px,9pxand10px— the exact values the rules above exist to catch — and the browser/URL scan of the built output found them.exit 0on a component tree therefore reads as a clean bill of health when it is coverage loss.That is the real harm: a user who scans
src/and sees zero has no signal that the scan was shallow.Expected
Either bring the framework-file path up to parity with
.htmlfor rules that only need markup plus inline style, or — if parity is not practical — make the reduced coverage explicit in the output, e.g. a line stating which rule families were skipped for these extensions, so0 findingscannot be mistaken forno problems.Environment
4.3.1, engine0.1.5(darwin-arm64), macOS 15.6astro,jsx/tsx,svelte,vue,mdx,php,erb,hbs, so this likely affects every non-HTML template language it accepts