The foundation: one design system, one CI

What it is

Four products on three stacks (Astro, Flutter, Cocos Creator) share one source of truth for colour, type, shape and breakpoints. A change to one JSON file restyles every product, and CI regenerates every output and fails if the committed files differ.

The generated files are committed on purpose: the Cocos build runs on Windows and the Flutter build runs without Node, so neither can depend on the generator at build time.

Key decisions

• CI runs only what changed. A filter job builds the job matrix as JSON from the changed folders, so skipped jobs never even get a runner. If it cannot find a comparison point, after a first push or a force-push, everything runs: silently skipping work is worse than running too much.
• Pinned and self-contained. Flutter is pinned to an exact version and the archive’s SHA-256; if the archive changes, CI stops. No third-party GitHub Actions are used.
• Rules a linter can’t express. A rule checker enforces gates that must stay at zero: no Google Fonts requests, no dynamic colour, no deprecated ColorScheme fields, no pill shapes outside chips, and the notification-receiver rule from Fatura Defteri.
• Ratchets for migration debt. Other rules, such as off-scale font sizes or hand-written opacity, have a committed baseline count that may only fall. A red check from day one teaches people to ignore it; a ratchet keeps the debt shrinking.
• Material 3 state layers. Hover, focus, pressed and disabled states use the Material 3 opacities on every surface, web included.

Proof

• 280 commits from 4 September to 13 October 2026.
• The token package has its own tests.
• Every product reads generated tokens instead of hand-written colours.