openmixer — generated API reference
    Preparing search index...

    Interface RestIndexBody

    The resource index at the router's root — how a client discovers what this desk declares.

    interface RestIndexBody {
        allow: readonly ResourceMethod[];
        confirms: ConfirmSheet;
        defaults: Readonly<Record<string, object>>;
        demand: DemandSheet;
        ok: true;
        resources: readonly string[];
        travels: Readonly<Record<string, ResourceTravels>>;
    }
    Index
    allow: readonly ResourceMethod[]
    confirms: ConfirmSheet

    Every confirm-gated operation this desk declares, path → ConfirmGate — the fourth row-wide declaration beside travels, defaults and demand, derived by the registry from the rows that carry the confirm clause (row grammar, "Confirm: the eighth clause"). The published policy and the enforced one are the same declaration: the registry refuses a bare fire on these rows with CONFIRM_REQUIRED, so a client reads this to SHOW a preview before the tap, never to decide whether to send.

    defaults: Readonly<Record<string, object>>

    What a FRESH instance of each row is, keyed by path — the starting half of the declaration whose travel half is travels.

    A client binds a control's range from travels and its reset value, detent or return-to-numeric from here, so neither is a constant in its bundle. Rows with no desk-wide starting point are absent, exactly as rows with no travel are.

    demand: DemandSheet

    Which rows are PUMP-FED and so must be DECLARED by a client displaying them — the demand gate's contract (§3d), keyed by path, derived from the console's pump table through RestRouterOptions.pumped. The third row-wide declaration beside travels and defaults: a row absent here is board state and needs no declaration.

    ok: true
    resources: readonly string[]

    Every registered path template, e.g. /channel/{kind}/{index}/headAmp.

    travels: Readonly<Record<string, ResourceTravels>>

    The whole desk's declared TRAVELS, path → field → what that field may be — so a client binds every numeric control it will draw from ONE request, at the URL it already reads to discover the entities.

    Here rather than at a /contract of its own because the contract generates the URLs (2026-08-11 ruling): a second declaration address would put the desk's declaration somewhere the contract never generated. It is the same door, answering richer.

    A field whose travel belongs to the INSTANCE carries perInstance and NO limit — a preamp's gain span is a property of the box behind that channel, so the number here would be a plausible wrong one. Those four are asked for with OPTIONS at the instance's own URL.