Catch design-system drift after merges

Why use this

1. A frontend team may merge individually reasonable changes that gradually diverge from shared components and styling rules. Reviewers need to know whether a difference is accidental drift, an approved exception or a necessary new design pattern.

2. This job could assemble evidence-linked findings after merges and propose narrowly scoped follow-up work. Keeping exceptions and visual uncertainty visible helps the team avoid generating mechanical cleanup tickets that remove intentional design choices.

Why an agent / simpler alternative

Useful judgment

Interpret design rules in changed code, distinguish exceptions and connect findings to the relevant component or token.

Simpler alternative

Use linting for violations that can be expressed reliably as fixed rules.

Unsuitable when

The task would rewrite intentional exceptions, merge fixes automatically or judge visual quality without suitable review.

Proposed inputs

1. Name

   Merged-change scope

   Owner

   Maintainer

   Minimum scope

   Approved diffs and merge identifiers

   Quality check

   Exclude unmerged work and generated output

2. Name

   Design-system rules

   Owner

   Design owner

   Minimum scope

   Relevant tokens, components and approved exceptions

   Quality check

   Check rule versions and applicable contexts

Access and setup — proposed or unknown

Proposed minimum

1. Review supplied diffs and rule excerpts; no repository access, ticket creation or code execution.

Compatibility unknowns

1. Current component mapping, issue integration, visual tooling and runtime compatibility are unknown.

External actions requiring approval

1. Creating tickets, changing code, opening pull requests or sharing private design materials requires authorization.

Expected deliverable and review checks

Proposed artifact

Drift findings with code locations, applicable rules, exception questions and proposed corrective scope.

Critical checks

1. Trace each finding to a rule; preserve exceptions; distinguish code-level suspicion from rendered visual evidence.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   An intentional experiment resembles a violation

   Why it matters

   Cleanup may undo an approved design choice

   Proposed response

   Check exception scope and hold the finding.

2. Signal

   A token alias is treated as a hardcoded value

   Why it matters

   The audit creates false positives

   Proposed response

   Resolve the reference chain before proposing a change.

Effort and cost — unknown

Setup work

1. Define rule precedence and audit boundaries.

Ongoing review

1. Designers and maintainers review findings before fixes.

Unknowns

1. Rule coverage, rendering needs, review volume and tool costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent three diffs using a hardcoded spacing value, approved exception and token alias; classify proposed findings only.

Acceptance checks

1. Preserve the exception; resolve the alias; label visual checks unperformed; create no ticket or patch.

Stop conditions

1. Stop if rule authority or exception status cannot be established.

Limits

1. A textual drift review cannot establish rendered consistency, accessibility or correctness of a proposed fix.