# Register sees the current guest host services

Go guest plugins can declare capability-backed runtime surfaces from their
`Register` callback. Bridge providers are the first such surface: the provider
stores its invokable value in the guest-local bridge stub while the stub tells
the CMS host that the named service exists.

`Serve` previously assigned the package-level guest runtime only after
`newGuest` returned. Because `newGuest` runs `Register` synchronously,
`HostServices()` returned an empty `CoreServices` value during registration.
Plugins that correctly nil-checked the bridge silently skipped registration.
The CMS could therefore mark a Wasm plugin loaded while consumers failed with
`bridge: no service registered` during a later load hook.

`newGuest` now makes the guest under construction current for the synchronous
registration pass and restores the previous runtime before returning. `Serve`
then installs the completed guest as before. This keeps construction isolated
for native tests while making the documented `HostServices()` escape hatch
truthful during `Register` on every pooled Wasm instance.

Alternatives rejected were moving bridge registration into `Load`, which runs
on only one pooled instance, and adding bridge names only to the manifest,
which would advertise host availability without installing the guest-local
`BridgeInvokable` value needed by `HOOK_BRIDGE_CALL`.

Consequences:

- Bridge services registered from `Register` exist on every pooled guest
  instance and remain callable after CMS startup and hot swap.
- A regression test exercises the observable `Serve` plus
  `HOOK_BRIDGE_CALL` contract instead of relying on initialization internals.
- No ABI or protobuf change is required; consumers need a plugin SDK release
  containing the corrected Go guest runtime.

Keywords: wasmguest.Serve, newGuest, HostServices, PluginRegistration.Register,
plugin bridge, RegisterService, BridgeInvokable, HOOK_BRIDGE_CALL, wiki content