callable
Every running workload this plugin can call, mapped to the interfaces of
it that are callable — what a plugin's own background work (its
wasi:cli/run) iterates to dispatch. Keys are workload-ids; the type
is spelled string only because a map key cannot be a named alias.
The interfaces matter for a plugin that imports more than one, because a
workload may serve some and not others. They are the pairs target.open
accepts: opening one this list does not name answers none, so a
dispatch loop reading it never has to handle that case at all.
Running is the whole rule: a workload appears when it starts and goes
when it stops. Both workload-lifecycle hooks land outside that window
— still deploying at on-workload-bind, already torn down at
on-workload-unbind — so neither can call the workload it is about;
reclaim per-workload state from the id the hook is handed instead.
A workload's long-lived service is left out even when it exports such an interface, and the host says so at deploy: a call built like a component's would start a second copy rather than reach the running one.
callable: func() -> unknown;