Skip to content

Configuration fields and bindings ​

Configuration is declared as a field array in the manifest. Each key is unique; the host owns validation, draft handling and commits. Values are per instance/display and saved in the active layout, rather than a separate settings file.

Ordinary fields ​

Each field requires key, label and type. Keys start with an ASCII letter followed by letters, digits or underscores. description is optional up to 1024 UTF-16 units; group is an optional 1–80-unit heading ordered by first occurrence. Ordinary fields require legal defaults; resource/secret fields default to null and cannot contain author paths, bindings or credentials.

TypeValue
booleanJSON boolean
stringString, optional maxLength
integerSafe integer, optional minimum/maximum
numberFinite number, optional minimum/maximum
enumString from unique nonempty options values
multiEnumUnique string array from options
colorOpaque #RRGGBB
directoryHost directory bindingId or null
launchTargetHost launch-target bindingId or null
secretHost secret bindingId or null

Options are value/label pairs. Bounds must be ordered and defaults legal. Ordinary shareable defaults false; resource/secret fields cannot be shareable. On schema changes, the host retains only same-key/type valid values, uses defaults for new/invalid values and removes deleted fields; it never converts secrets to plain strings or restores revoked bindings.

Use current declared types and constraints from the host contract. Provide valid defaults, human-readable labels and explicit sharing choices. config.get returns the current complete object. config.set accepts ordinary field values and returns the validated committed configuration; it is not a way to create grants or replace resource bindings.

Listen to config.changed after initialization and update existing rendering/tasks. Replacing a poll period requires cancelling the old timer. A reload cannot silently discard unsaved management drafts; automatic activation waits and manual actions use the host's save/discard/continue workflow.

Resources and secrets ​

Directory, launch-target and secret fields hold a bindingId or null rather than an arbitrary author path or secret body. Resource selection belongs to trusted host UI. Author text cannot create authorization. HTTP secret headers use a reference to the chosen secret; component credentials are a separate namespace.

Shared layouts omit private/unshareable values and never grant or restore permissions. A string that resembles a bindingId is not evidence that it is a resource reference. Binding replacement/cleanup relies on declared field types. Configuration adaptation is host-controlled; components do not supply migration scripts.

See SDK types, security and the synchronized Chinese source for the complete field grammar.

Exact method signatures and complete machine budgets are shared in SDK declarations.

Current host contract · SDK 0.1.1 · MIT