asobi_ops_features (asobi v0.72.5)

View Source

The installed feature set, as the ops read plane reports it.

Core and every installed extension are reported in the same shape - #{name, version, capabilities} - so a console reads one row type and does not branch on which half of the deployment a feature came from.

This is the endpoint the console uses to decide which of its built-in screens to render: it ships the quests screens and shows them when quests is installed. That is the whole mechanism, and it is why the endpoint reports the extension's version as well as its name - a console rendering against a schema that has moved should be able to say so rather than fail oddly.

Capabilities report what is configured, not what is compiled in: a console needs to know whether Steam auth will work on this deployment, and "the module exists" does not answer that. Each entry is a name and a boolean only - never the configured value, which is usually a secret.

lua is the exception and is a module check, because since the runtime merged into asobi there is nothing to configure: it is present in every stock release. It stays in the list so a console rendering against a stripped custom release still gets an answer rather than an absent key.

Summary

Functions

capabilities()

Core capabilities, sorted by name so the response is stable.

extensions()

Installed extensions, in dependency order, in the same shape as core.

features()

Functions

capabilities()

-spec capabilities() -> [#{name := binary(), enabled := boolean()}].

Core capabilities, sorted by name so the response is stable.

extensions()

-spec extensions() -> [map()].

Installed extensions, in dependency order, in the same shape as core.

Read from asobi_extensions:resolve/0's memoised result, so this costs a persistent_term read and can never disagree with the set the node actually booted with.

An extension's capabilities are the manifest keys it declares something under - rpc, lua, tables - reported as the same #{name, enabled} pair core uses. They say what the extension contributes, never what it contains: no method name, no table name, nothing an operator has not already been told by installing it.

features()

-spec features() -> map().