Data providers for the admin Runtime page (/admin/runtime).
Everything here is read from the running system — behaviours, schema
reflection, protobuf message props, the plugin registry — rather than
hand-maintained, so the page cannot drift from the code. The two exceptions
are documented where they occur: hook prose is parsed from the SDK source at
compile time (the core callbacks carry no @doc), and realtime events come
from GamendWeb.RealtimeEvents, which a drift test keeps honest.
Each provider returns a list of plain maps with a precomputed lowercase
:search blob the LiveView filters on.
Summary
Functions
Advisory lock namespaces (from the registry the locks require).
Channel routes from the socket registry.
Every Ecto schema, the server's own and each plugin's: table, fields and associations.
Every callable plugin function, on the same basis as the config page's
"Available functions": static module exports (signature + @doc from BEAM
metadata via Gamend.Hooks.exported_functions/1) unioned with
dynamically registered RPC exports. payload marks the typed-hook message
pair when one is registered.
Every environment variable the server can read, with live set/unset state (secret-like values masked).
Server→client events: core's drift-tested registry plus every event a plugin
declared via realtime_events/0 and can push with
Gamend.Realtime.push_to_user/3.
Category a hook belongs to, derived from its name (not source position).
Category order for grouped rendering.
All lifecycle hook callbacks with kind, implementers, and SDK docs.
A mermaid flowchart of the whole schema, one subgraph box per domain.
Migration status across every migration directory the deployment uses.
Notification codes a client may receive, core and plugin-declared.
Loaded plugins with their hook module and export counts.
Every loaded protobuf message: the server's own plus every plugin's.
Plugin-registered scheduled jobs (see Gamend.Schedule).
Functions
Advisory lock namespaces (from the registry the locks require).
Channel routes from the socket registry.
Every Ecto schema, the server's own and each plugin's: table, fields and associations.
A plugin's schemas are grouped under the plugin's name rather than its module namespace, so a game that ships tables gets its own box in the diagram automatically — no registration step.
Every callable plugin function, on the same basis as the config page's
"Available functions": static module exports (signature + @doc from BEAM
metadata via Gamend.Hooks.exported_functions/1) unioned with
dynamically registered RPC exports. payload marks the typed-hook message
pair when one is registered.
Every environment variable the server can read, with live set/unset state (secret-like values masked).
Sourced from Gamend.Settings.all/0 plus any variables a plugin declares
through env_vars/0. This used to be reconstructed by regex-scraping the
runtime config's source and parsing .env.example prose, because nothing
declared the settings; the declaration replaced both.
Server→client events: core's drift-tested registry plus every event a plugin
declared via realtime_events/0 and can push with
Gamend.Realtime.push_to_user/3.
Category a hook belongs to, derived from its name (not source position).
@spec hook_group_order() :: [String.t()]
Category order for grouped rendering.
All lifecycle hook callbacks with kind, implementers, and SDK docs.
A mermaid flowchart of the whole schema, one subgraph box per domain.
erDiagram has no clustering, so the all-domains overview uses a flowchart
instead: nodes are tables listing every field, edges are foreign keys
labelled by their column, and each domain gets a visible box. Cross-domain
edges are drawn thicker so the seams between domains stand out.
Migration status across every migration directory the deployment uses.
Uses the same path resolution as mix host.migrate, so a host application's
own migrations (not just core's) are listed — otherwise a game that ships
tables would see an incomplete history here.
Notification codes a client may receive, core and plugin-declared.
Loaded plugins with their hook module and export counts.
Every loaded protobuf message: the server's own plus every plugin's.
Plugin messages are found by scanning each plugin's modules rather than only the ones registered as KV/hook schemas, so a game sees its whole wire schema here — including messages it has defined but not yet wired up.
Plugin-registered scheduled jobs (see Gamend.Schedule).