A divergence is a finding, and a patch is its fix. In FISYCO, a patch never goes straight into your branches. It arrives as a pull request from a new branch, and merging that pull request is the approval.
Two kinds of patch
A replacement follows from the finding itself, so no AI model is involved. For example (illustrative), a hard-coded #2563EB becomes color.accent, whose value is #2563EB. Replacements are batched, so one pull request can cover many places across several files.
A design patch is drafted by an AI model from the numbers on both sides, then checked. It passes only if fewer properties differ and nothing that matched before differs now, in any variant. Each design patch comes as its own pull request for one component. A patch that can't be proven is not shipped.
Each kind of difference (design, tokens, icons and illustrations) has its own autonomy level: Off, Suggests or Acts on its own. Every kind starts at Off.
What patches don't cover
FISYCO proves patches without running the code. Values are checked inside the component, so a style overridden from outside, by an app theme or a wrapper, isn't covered.
FISYCO never patches a home-made twin of a system component. Replacing it with the system component changes its API, so that work goes to a person or an AI agent.
Patch pull requests open on GitHub only. GitLab and Bitbucket get indexing and the pull request check.
Related
- Patches and autonomy: how far FISYCO may patch on its own, for each kind of difference.
- Bypass
- Automatic pull request