Keeping this current

Adding, renaming, or retiring a preset touches two places:

1. presets/<name>.toml — the preset file itself. That is all the shipping takes: core/build.rs globs the directory, so the embedded list and the preset-count test follow automatically. There is no array to extend and no count to bump.
2. Parameter roster — if the preset showcases a control worth pointing an author at.

Adding a parameter to a system touches the scene’s set_param match, the PARAMS const beside it (the two are guarded against drift by declared_params_match_set_param in core/tests/suite/preset.rs), and the table in Parameter roster.

Adding an expression variable, function, or operator touches core/src/preset/expr.rs and The expression language in this file — and every other place that re-types the roster, in the same commit: the short list in Parameter roster, and the preset-author skill’s SKILL.md and references/grammar.md. Four copies of a list is four chances to drift, and a stale roster silently costs the content lane a capability. A change to the grammar is ADR territory — flag it rather than quietly widening the vocabulary here.

--schema’s grammar object is not one of those copies and needs no hand edit: it is generated from the same declarations the parser reads, and a test diffs it against them in both directions. What a new name owes there is one regeneration. The document is also committed, as docs/specs/player-schema.json, for the studio’s tests to read, and core/tests/suite/preset_schema.rs fails until RLX_UPDATE_PRESET_SCHEMA=1 cargo nextest run -p rlx-core --test suite preset_schema:: rewrites it (Developing has the whole set that command covers).

Format stability: the app is pre-1.0 and in active development, so the preset format may still change between releases. Preset-format stability begins at 1.0.0.

---