Architecture

Boot sequence

At a high level, the current WordPress runtime works like this:

1. The plugin entrypoint loads the SDK/runtime autoloaders.
2. The Hub constructs a hub-scoped SdkContext through SdkContextFactory.
3. ModuleRuntimeLoader discovers module.json files from wp-content/meteorack/modules.
4. Each module boots inside crash isolation.
5. The runtime injects the parsed ModuleJson metadata.
6. The module receives a slug-scoped SdkContext through onSdkReady().
7. The Hub registers modules and API routes after boot.

Context scoping

SdkContextFactory currently splits services into two categories:

• Shared singletons: auth, http, license, tokens, channel
• Slug-scoped services: logger, cache, settings, events, scheduler, storage, secrets

That means each module gets isolated settings/cache/logging namespaces while still sharing auth and remote communication primitives.

Module discovery

The runtime supports both flat and categorized discovery paths:

• wp-content/meteorack/modules/{slug}
• wp-content/meteorack/modules/core/{slug}
• wp-content/meteorack/modules/adapters/{slug}
• wp-content/meteorack/modules/dev/{slug}

Modules are sorted by priority before boot.

Runtime boundaries

The WordPress runtime is the primary execution environment today.

The standalone runtime currently exists only as a thin foundation. Treat standalone support as incomplete until the missing service implementations are added and documented.

Package boundaries

The private duplicate stage currently treats the JavaScript package map in Package Boundaries as canonical. Placeholder @meteorack/modules-sdk* manifests under meteorack-platform/packages/ are not the source of truth for the future SDK split.