Skip to main content
Join the waitlist

Checks

Find where saved code leaves your app’s design system, then review a specific repair.

Coming from the Fragments CLI or MCP server? They're retired; checks now run in the app.

  1. Run a check

    Open Checks in the right panel and choose Check now or Check again. It reads saved source against the components and values found in the project. A saved fragments.config.json adds explicit project rules; a project can be checked before it has that file.

    Findings cover Colour, Spacing, Type, Radius and Components within the supported source forms. The desktop also reports accessible-name defects found on pictured pages. Suggestions are listed separately and do not count toward the source check’s failure.

  2. Read the finding

    Expand a finding to read why it was reported and see its places. Source findings name a file and line; a defect measured on a page may name the page when its source line is unknown. Use that location to review the affected code or element.

    Replace is offered for supported token replacements. A nearby value that would look different is a suggestion to review, not an automatic replacement. Ask puts the repair request in Chat for you to review before sending. After a repair, rerun the check and inspect the affected interface.

  3. Review coverage

    Open Where it looks to see the scan’s scope and anything it could not read. A result for selected files does not establish the state of the whole app. Missing inputs, malformed source and unsupported expressions can leave coverage incomplete; no findings is not a pass when the check could not finish its read.

    The engine reads supported static CSS and SCSS, including Modules, and supported classes and markup. It does not evaluate arbitrary Sass or JavaScript. Indented Sass, unresolved style expressions and theme-dependent object styles can require further review. Pictured accessibility findings are desktop evidence and are not included in the saved-source CI verdict.

Use approved tokens

When the project has an approval list, adding a token does not automatically make it approved. Its uses still count until you review the token in Design system and choose Approve, or replace it with an approved value.

The list lives in .fragments/tokens.json. Creating the first rule or making a Strict baseline approves the app’s existing tokens when no list exists. Without an approval list, discovered tokens remain eligible; detection alone is not a recorded approval decision.

Choose the project policy

In Settings → Project → Drift in CI, choose Allowed or Strict. Allowed is the advisory mode: findings are listed without failing the project check. Strict fails on counted findings beyond the saved baseline. With no mode chosen, the project check fails on any counted finding.

An incomplete read cannot pass in any mode, including Allowed. Review the proposed files before applying a policy change. Nothing is committed automatically, and the change appears in Changes with Undo.

A mode choice does not make CI run. Where Add to CI is available, Fragments prepares a GitHub Actions workflow for review. It blocks merging only if the repository requires that check. Review changes to the rules, baseline and checker alongside the code they govern.

Understand the baseline

Strict keeps existing findings in .fragments/baseline.json after a complete read. They remain a backlog; new findings beyond it fail. Turning Strict off and on keeps the previous baseline. Keep today’s drift explicitly replaces it with the current findings. Tighten removes allowances for findings already fixed so they cannot return unnoticed.

The baseline counts occurrences of a rule and value within each file, rather than tracking individual lines. Fixing one occurrence and adding the same value elsewhere in that file can leave the count unchanged. Review the diff as well as the result. See the review and Undo guide for the surrounding workflow.

Next steps