@ariestools/browser-kit

Browser-facing config-driven launcher for provider actors used by pages, workers, service workers, and extension/plugin realms.

The package delegates platform-neutral catalog selection, provider planning, provisioning, actor construction, supervision, and sessions to @ariestools/actor-system. It adds a descriptor-free browser system manifest and attaches actors in other realms using typed proxy factories without resolving provider bindings again.

import {
  compileBrowserSystem,
  launchCompiledBrowserSystem,
} from '@ariestools/browser-kit'

const compiled = compileBrowserSystem({ actorCatalog, config, providerDescriptors })
const session = await launchCompiledBrowserSystem({ actorCatalog, compiled })

Compilation acquires no providers and constructs no actors. The compiled value retains installed descriptors and must stay in its owner realm. Use a BrowserSystemManifest plus a typed proxy adapter when another realm attaches. launchBrowserSystem remains the one-step compile-and-launch convenience.

Cross-realm manifests distinguish a compatible planId from the exact systemInstanceId. Neither identifier is authentication; realm adapters must authenticate their peers.

Retained startup

startBrowserSystem(options) returns synchronously before compilation. Its whenReady() joins the same compiled browser launcher; snapshot() and subscribe() retain the neutral bounded graph and resource events even when compilation or acquisition fails. Pass the handle to bindPageLifecycle or bindWorkerShutdown before awaiting readiness. A stop request waits for an in-flight factory and rolls back at the next owned acquisition checkpoint.

Runtime options, including diagnostic sinks, cancellation checkpoints and strict resident termination signals, pass through to actor-system. Custom provisioners remain responsible for enforcing declared access internally and reporting their actual acquisitions. Cross-realm attachment is a separate operation and does not yet expose this pre-boot handle.

Proxy factory authority

A proxy factory represents only the owner-selected monikers assigned to its provider ID in the attached system. Its transport facade permits requests for those monikers only, exposes no transport-close operation, and rejects new or late completed requests after that proxy's cleanup. The scope remains live during its own disposer and closes even if disposal fails. Remote provider dependencies execute in the owning realm; their declarations do not grant a proxy factory unrelated remote service access. The transport owner alone closes the shared connection after all proxy disposers have run.