OptionalappliesWhich styles or contexts the knob works in. A string rather than a fixed union so each
module can choose its own vocabulary — styling uses 'any-style' | 'tomtom-styles'.
OptionalavailableWhether the knob has anything to work on in the loaded style. Omitted by modules whose knobs
are always applicable; set to false by modules where a knob can be present in the catalogue
but do nothing on the current style.
The value in force now.
The value in force when nothing has been configured.
One-line description of what turning this knob does.
Stable, dotted identifier, e.g. labels.sizeFactor. Treat these as public API: they are what
a caller stores, diffs and passes back.
What kind of value the knob takes.
OptionaloptionsThe allowed values, for enum knobs.
Whether KnobDescriptor.current came from configuration rather than the default.
OptionalrangeInclusive bounds, for factor and number knobs.
A single, machine-readable description of one display knob.
Remarks
The point of describing knobs as data is that a caller — increasingly a coding agent rather than a person reading docs — can ask what a module actually exposes instead of guessing layer ids from training data. Three things follow from having it:
A visual editor cannot do any of those: it cannot be read, diffed, or put in a pull request.
Modules narrow this shape with their own descriptor type — e.g.
StylingKnobDescriptorrequiresavailableandappliesTo, while a module whose knobs are always applicable omits them.