The Detector's Mechanical Floor

Live mode lets a person choose among rendered alternatives, but not every quality question needs a person to notice it first. Impeccable's detector turns a defined subset of frontend quality into repeatable findings that can run over source files, static HTML, rendered pages, browser overlays, and edit hooks. This chapter explains the detector's shared registry, the different engines that consume it, and the boundary that matters most: a clean scan is evidence about the configured rules, not a verdict on the design.

One registry defines what the system can name

The detector is not a collection of unrelated scripts that happen to print similar warnings. Its current Rust registry contains 61 built-in rules. A registry entry carries a stable ID, a category, a name, a description, optional scopes, and a severity. Some entries also connect the rule to a skill section or guideline. That metadata gives a finding a durable identity beyond the wording of one report.

The categories provide a first distinction. slop rules describe recognizable patterns associated with generated interfaces, such as a side-tab accent border, an overused font, gradient text, nested cards, a decorative radial glow, a hero eyebrow, or a repeated aphoristic copy rhythm. quality rules describe failures that can affect readability, structure, accessibility, or implementation integrity, such as low contrast, broken images, skipped headings, text overflow, clipped menus, or content hidden at rest. The categories help explain a finding, but they do not decide its exit code or make one category more real than the other.

A slop finding can still matter to a product, while a quality finding can be isolated or intentional. The category is descriptive context, not a substitute for inspecting the surface and its use scene.

Severity supplies another distinction. Most findings default to warnings. Some are advisory, meaning the detector can report them without treating them as automation failures. The registry includes advisory examples such as decorative blinking cursors, numbered section labels, em-dash overuse, and certain design-system drift. Error-level rules include failures such as an uncaught script error or content that remains invisible after its reveal handlers have run. This partition prevents a stylistic signal from blocking a pipeline in the same way as a broken page.

The registry also declares scopes. The current built-in scopes include type and layout, which let a caller narrow a scan without inventing a second rule taxonomy. A typography-focused pass can ask about type rules. A layout-focused pass can concentrate on structure and overflow. The rule keeps one identity while appearing in the contexts where it makes sense.

The exact current count matters because the repository contains documentation from more than one point in time. The current registry test asserts 61 built-in rules, and the generated registry JSON represents those rules. An older CLI contract snapshot enumerates 59 IDs and identifies an earlier package state. The safe statement is not to average the numbers or repeat whichever one appears first. Current counts belong to the current registry; the older document remains a historical contract for the stable concepts it still describes.