Action catalog
An action is a named operation registered by a particular client composition. Its contract has four parts: the command parameters and target, the local authority needed to perform it, the result or error shape, and the observable limits of the underlying platform. The same action name can therefore have a narrower implementation in one runtime than in another.
This catalog groups related actions into substantial pages instead of giving every small operation its own fragment. It documents the handlers shipped by the core, browser, web, and console packages. Product-defined modules should document their own contracts alongside the product that registers them.
Read an action contract in four parts
For every invocation, check:
- Availability. The runtime must have registered the handler before startup and advertised it during the hello handshake.
- Addressing. Resource identifiers such as
tab_idandwindow_idbelong intarget; action-specific inputs belong inparams. - Authority. Central authorization, client-local policy, optional approval, platform permissions, and resource existence all have to agree.
- Evidence. An
appliedresult means the handler reached its defined success boundary. It does not automatically prove an irreversible external effect beyond that boundary.
Batch actions can apply only some items and report failures for the rest. Cancellation and lease loss are cooperative safety signals: they can fence a late result, but cannot undo work already performed by a browser, process, filesystem, or remote server.
Catalog map
- Core and custom actions covers the runtime probes,
cache_data, action descriptors, schema validation, handler context, and result rules. - Browser control actions covers tabs, windows, navigation, downloads, and the worker overlay.
- Page actions covers DOM reads, DOM changes, element waits, extension bridging, and cooperative web-page differences.
- Console actions covers logical flows, files, process execution, and machine-side downloads.
The catalog describes implementation contracts, not deployment policy. A production client should normally expose only the actions its role requires, then narrow them with local policy and operating-environment controls.