Token sync

What it would do

Own the mechanical half of the design token pipeline:

Export variables from the design source into the reviewed token file.
Transform that file into every consuming format — CSS custom properties, a typed module, platform formats, the documentation tables.
Open a pull request with the diff, described in terms of roles that changed rather than hex values that moved.
Report drift: values in consuming code that no longer match the source, and roles that exist on one side only.

Why a model rather than a script

Most of the above is a script, and where a script suffices it should be one.

Two parts are not. Describing the change is the first: a diff that says color-danger: #c8102e → #b91c1c is unreadable, and one that says “the danger role got darker; twelve components consume it, and the contrast of danger-on- surface improves from 4.2 to 5.1” is a review a person can actually do.

Explaining drift is the second. A raw list of mismatches is noise; a grouped account — these four are one abandoned rename, this one is a manual edit from March, these two are new roles never implemented — is a work list.

What it must not decide

Whether a token should change. That is a design system decision made by people, and the pull request exists precisely so that it stays one.

Nor may it resolve drift by editing downstream. A hand-edit downstream is a bug in the source; a machine making the same edit is the same bug, made faster and harder to notice.

What would make it safe

It only ever proposes. Nothing merges without a human.
Its output is reproducible — running it twice on the same input produces the same diff.
It fails loudly when the source and the generated files disagree, rather than reconciling them.
Its drift report is the same artefact a person would have written by hand, so a reviewer can check the reasoning and not only the conclusion.