Module export 

What a preset may contain, as a machine-readable document (Plan 0158 Phase 4).

A studio building a parameter panel, an expression editor or a table form has to know two things the engine already knows: every parameter a system and the engine stages accept, and every key a structural table accepts. Both are declared in the engine and read by the loader; this renders them.

The parameter half is generated, not restated

It walks the same ParamSpec declarations the generated block in presets/README.md is rendered from (ADR-0170) — the same rosters, in the same order — so the published table and this document cannot disagree about a name, a default or a range. core/tests/suite/preset.rs renders both from one walk and asserts they agree.

The structural half is declared beside its serde struct

Every [table] a preset may write carries a TableDesc next to the Raw* struct the loader deserializes it into. That is a second statement of the table’s shape and it is one on purpose: serde carries a field’s name and type, and none of what an editor needs — the closed roster a string is drawn from, the default the loader substitutes, the sentence that says what the key does. What stops the two drifting is a test, not a construction: core/src/preset/schema/tests.rs reads the field roster serde derived (through a Deserializer that answers nothing and records what it was asked for) and asserts it is exactly what the descriptor names.

No enumeration is written here. A KeyKind::Roster names the type that owns the closed set, and Roster::values asks it — so [feedback] warp’s roster is Warp::ALL and there is nothing here to fall out of step with it.

The hash

hash is FNV-1a over the document body — everything the export declares, without the hash field itself, which would otherwise be hashing its own output. A studio compares it against the one a player reports in hello to know whether the schema it built its panels from is the schema the player is running.

No JSON crate: the writer below is thirty lines and NFR section 4’s dependency gate asks for a justification longer than that.

Structs

KeyDesc

One key of one structural table.

TableDesc

One structural table a preset may write.

Enums

KeyKind

What one structural key accepts.

ParamSurface

Which [params] surface a per-system case is about.

Roster

A closed roster of accepted spellings, named by the type that owns it.

Constants

GENERIC_SCHEMA_PATH

Where the generic schema is committed, relative to the repository root.

SCHEMA_VERSION

The document format’s own version, carried as v so a consumer can refuse a shape it does not know. Independent of the workspace version and of the event stream’s v: this one moves when the document changes shape, which is rarer than either.

STAGE_LABELS

The engine-wide stages, labelled as a reader meets them rather than as the modules are named.

SYSTEM_SCHEMA_DIR

Where the per-system schemas are committed, relative to the repository root.

TABLES

Every table, root first. A KeyKind::Table names one of these.

TAPLO_CONFIG_PATH

Where the editor association is committed, relative to the repository root.

Functions

document

The whole schema as JSON, hash included.

editor_files

Every generated editor file, as (path relative to the repository root, content): the generic schema, one schema per system, and .taplo.toml.

family_rows

Every family-dependent parameter declaration in the engine, paired with the FamilyParam row that describes it — the lookup markdown_for needs, which the document does not, because push_roster already has the roster’s label in hand and this walk does not.

hash

The document’s stable hash.

hash_hex

The hash as the sixteen hex characters document prints and hello reports.

hash_str

FNV-1a, 64-bit, over text’s bytes — the function hash uses, exposed so a test can hash a deliberately perturbed copy of the document and assert the hash moved with it.

json_schema

The JSON Schema an editor completes preset TOML from, as committed to presets/preset.schema.json and associated with preset files by .taplo.toml.

param_rosters

Every parameter roster a preset may bind, labelled: one per system, then one per engine stage.

params_of

Every parameter one surface of kind accepts, in the order an author meets them: the system’s own roster first, then the engine stages’.

stage_count

How many of the rosters are engine stages rather than systems — the tail of param_rosters.

system_json_schema

The JSON Schema for a preset driving kind, self-contained, as committed under presets/schema/.

system_schema_path

The committed path of kind’s own schema, relative to the repository root.

table

The table named name, or None.

taplo_config

.taplo.toml: which schema Even Better TOML applies to which preset file.