Decompose standards runner into scoped owners instead of one catch-all check

[serge-ivo]

Problem

The standards runner currently acts as a catch-all for unrelated concerns, which makes scores noisy and duplicates findings that have better owners.

Evidence from cli/src/runners/standards.ts:

• Naming and file-size conventions.
• console.log, var, loose equality, strict-mode/config hygiene.
• Dangerous APIs such as eval, new Function, innerHTML, dangerouslySetInnerHTML, document.write.
• HTTP URLs.
• TODO/FIXME comments.
• Magic-number heuristics.

Several of these are already covered more specifically by other runners:

• Dangerous APIs overlap security and react.
• Large files overlap complexity, context, and future file-cohesion work.
• TODO/FIXME comments overlap stale-comment and maintainability checks.
• Console/logging may belong to repo policy, lint, or production-readiness depending on context.

In the PAGS scan this category produced a low score with a large issue count, but it is hard to tell what engineering owner should act on it.

Why this belongs in VCQA

This is analyzer taxonomy and scoring ownership inside VCQA. Individual applications cannot fix ambiguous category semantics.

Proposed direction

Either decompose standards into smaller checks or make it an orchestration bucket that delegates to canonical owners.

Suggested ownership:

• Naming and project conventions: standards or repo-conventions.
• Dangerous browser/runtime APIs: security or react depending on context.
• File size and maintainability: complexity or file-cohesion.
• TODO/FIXME and stale comments: comment-staleness / maintainability.
• HTTP URLs: security only when actually insecure or externally reachable.
• Console usage: lint/release-readiness rule with severity configurable by project type.

Acceptance criteria

• Each rule in standards.ts has a documented canonical owner.
• Duplicate findings are removed or emitted once with cross-check references.
• standards no longer reports security/XSS findings that are better owned by security or react.
• Score impact is calibrated so broad style-policy findings do not drown out actionable correctness/security issues.
• Docs explain what standards means after the split.

Related issues

Related but not a duplicate:

• False positives: text rules match inside string/template literals (var keyword in embedded browser snippets) #11 covers false positives from text matching.
• Severity inflation: style/lint rules emitted as error (only 1 of 79 'errors' was build-breaking) #12 covers severity inflation.
• Duplicate findings: circular dependencies double-counted across 'architecture' and 'context' checks #13 covers duplicate circular-dependency findings across architecture/context.
• Extract default exclusion policy into a maintained shared registry #49 covers path exclusions.

[serge-ivo]

Partial delivery: the regression half of this issue landed in 40705b4 (now pushed to main; it had been sitting committed-but-unpushed locally).

standards.ts carried flat pattern rules for eval, new Function, innerHTML, document.write and dangerouslySetInnerHTML that duplicate patterns security.ts already owns with CWE IDs. The concrete harm: the HTML-provenance grading added in 64c8b8b (#86) would correctly downgrade a sanitized dangerouslySetInnerHTML to info, and then standards re-emitted it as a flat severity: "error", undoing the fix in the report.

All five are removed from CODE_SMELLS. Verified no coverage is lost: security.ts matches the same regexes over the same file universe (inventorySourceFiles/getProductionFiles) and additionally scans SFC templates via rawContent. Tests assert the transfer of ownership rather than dropping the assertions — plus a regression test proving a sanitizer-traced dangerouslySetInnerHTML grades info with no flat error anywhere in the standards output. A file-header comment says why the five must not be re-added.

Verified on main: pnpm build clean, pnpm test → 60 files / 699 tests all passing, pnpm lint exit 0.

Leaving this open. The broader ask — decomposing the standards catch-all (large files, TODO/FIXME, http:// URLs, magic numbers) into scoped owners — is untouched.

Note for release: the fix is on main but not published. package.json is at 0.55.0, which is already the published npm version, so publish.yml no-ops. It ships on the next version bump.