Check design-system drift in CI

Try the comparison locally first

From your project folder, choose the branch or commit your work should be compared with. For example, use main when your feature branch contains commits after main. The base must already exist in your checkout; Saer never fetches it or changes your git history.

saer ci --base main

Use an exact commit SHA when reproducibility matters. An explicit base is required: comparing a clean CI checkout with its own HEAD would miss the committed changes you intended to check. Revision ranges and git options are refused.

Choose the gate policy

saer ci --base main --json

• Exit 0: no changed source lines, or the selected policy passes. Review findings remain visible as advisory results under the default deterministic-drift policy.
• Exit 1: deterministic drift found, or review findings under the stricter policy.
• Exit 2: the check could not complete, including missing access, missing base, unavailable analysis, parse failures or unexamined files. Do not treat this as a clean result.

saer ci --base main --strict

The result names the base, scope, verdict and policy. Static checks do not compile or execute your project and do not prove accessibility conformance or ticket completion. Continue to run your ordinary build, lint and tests.

Use a supported, trusted runner

Use an Apple Silicon Mac runner with Node 18 or newer and git. The template uses GitHub’s standard macos-15 Apple Silicon runner for public or private repositories. Runner use can consume included minutes or incur GitHub charges. Review your GitHub usage and spending settings before enabling a workflow. Earlier macos-14 templates need updating: GitHub retires that image on 2 November 2026. Linux and Intel runners are not supported by this build.

Create a CI runner key in your cloud project, then store it as the SAER_CI_TOKEN GitHub repository secret. Review the workflow once before enabling it. Normal trusted same-repository pull requests then run automatically, with no owner approval for every job. Keys are shown once, stored as hashes and can be revoked. Beta keys expire within 30 days or the trial. When paid plans open, paid connections will survive renewals while every operation still checks current access. They permit full analysis and uploads to their own cloud project, but cannot read cloud history or manage accounts. They are bearer credentials, not bound to GitHub workload identity; never expose them to untrusted branches or fork jobs.

Download the reviewable GitHub workflow. Review it before copying into .github/workflows/saer.yml. It uses pinned actions, checks out the PR head with an explicit base, disables persisted checkout credentials, installs the protected engine without browser sign-in, and runs saer ci --github. It does not install project dependencies, execute project scripts, upload reports or post PR comments.

If you enabled automatic summary history when creating the CI key, each full scan syncs those fields automatically. No separate upload step is needed. The key identifies its cloud project. Sync outages are shown as pending, while the local CI verdict still follows the configured drift policy.

The template refuses fork jobs instead of silently reporting a clean check. Use a repository whose workflow authors and write-access contributors you trust with this scoped key. Keep workflow changes under review and use CODEOWNERS where appropriate. The template does not use pull_request_target. An organisation can add its own environment approval policy, but it is not required by the normal Saer flow. Once verified in your repository, make Saer drift gate a required status check in your branch rules. Keep an explicit exception/review policy for cases that need human judgement.

Revoke a runner key in your cloud project. Trial expiry and revocation fail premium checks instead of falling back to a free preview. Manage your separate interactive installation on your beta page.

Use the same loop with your agent

The same changed-line engine is exposed through saer_check_changes. Agents can supply base_ref to compare with a local commit, or omit it to inspect their uncommitted changes against HEAD. Start with agent setup and keep the scan current.