asobi_ops_features (asobi v0.84.0)

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 screens to render. A composed console bundle carries the screens of every extension it was built with, and renders each one only when this endpoint says that extension is installed - so one bundle serves a staging node and a production node whose extension sets differ. 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.

The set is read from asobi_extensions:resolve/0's memoised result, so it can never disagree with the set the node actually booted with. console is the one capability that is not read from there: it is a file check, so it costs a stat per extension and it reports what is on disk now rather than what was resolved at boot. That is what makes it a diagnosis - see ships_console/1.

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

features()

-spec features() -> map().