FISYCO can fix some differences between your code and the design system by itself and deliver the fix as a pull request. You decide how far it goes, separately for each class of change. This page explains the autonomy levels, how FISYCO proves an edit before it ships, and what you find in the pull request.
Before you start
- The design system in code is set up for the project. See Connect the design system.
- The repository is on GitHub. GitLab and Bitbucket get indexing and the pull request check, but FISYCO opens patch pull requests on GitHub only.
- The FISYCO GitHub app has Contents: write. Reading the code needs only read access; writing is needed for patches alone.
Autonomy per class of change
Autonomy is a ladder, not one switch. Each class of change gets its own level, because each is proven differently:
Every class starts at Off. The levels mean:
To set the levels:
- Open the project, then Design system in code under From code.
- Open Settings and find Autonomy.
- Pick a level for each class. The card also shows Pull requests in the last day.
Changing autonomy takes a project maintainer or a workspace admin or owner.
Start with Suggests. Watch what FISYCO would change, then move token and asset replacements to Acts on its own first. Their proof is exact, so they are the easiest to trust.
At Suggests, a fixable difference waits under Waiting for you on Differences. Choose Fix now on its row, and FISYCO prepares that one edit with the same proof and the same daily budget. Twins, components built outside the system, are never fixed automatically: use Hand to an agent instead. See Differences between code and design.
How FISYCO proves an edit
FISYCO never executes your code. It reads files through your Git provider's API and analyses them statically: no build, no render, no screenshots. An edit that can't be proven is never shipped, at any level.
Token and asset replacements: equality
A token bypass is a literal whose value equals a token. An asset copy is an inline drawing with the same geometry as a library asset. The edit follows from the finding itself, so no AI model is involved.
FISYCO reads the current files on the target branch and applies the replacements. A replacement it can't prove by equality is left out of the batch.
Design differences: values
For a component that differs from its design pair, an AI model drafts the edit from facts with numbers on both sides. FISYCO then computes the component again from the patched source and compares it with the design layer by layer.
The edit passes only if fewer properties differ, and nothing that matched before differs now, in any variant. Otherwise it's refused, and the refusal is kept with its reason.
The proof has a limit, and FISYCO states it: values match inside the component. A style overridden outside it, by the app theme or a wrapper, isn't covered.
The Patches tab
Patches lists what FISYCO did and what it refused. Filter by All, Shipped or Refused. Each row shows the Outcome (Matched, Refused or No change needed), the Initiator, the Patch class, Proven by, the number of Edits and the pull request.
Open a row to see the edits as a diff and the Verification block: variant, proof, patch class and commit. See the comparison with the design opens the component side by side with its Figma pair. For more on that view, see Compare components with the design.
When something blocks patches, the tab shows Still missing before patches with what to fix, for example autonomy that is off or an app that may not write code.
What arrives in the pull request
FISYCO commits to a new branch and opens a pull request against your target branch, or the repository's default branch if none is set. It never pushes to your branches directly.
- Token and asset replacements are batched, so one pull request can cover many places across several files. The body lists what was replaced and where, and states the proof: each literal equals its token, or each fragment has the asset's geometry.
- A design fix comes as its own pull request for one component. The body has a table with the columns Variant, Property, Design and Code now, how the edit was proven, what still differs, and the note that no code was executed.
Approving a patch means merging its pull request. There is no approve button in FISYCO, so your team's review stays the gate.
When someone comments on the pull request, FISYCO replies with facts about what it changes. It doesn't rewrite the code in reply: the branch belongs to your team.