4. Provision the platform core

The platform core is the minimum set of resources that must exist for a Mnemose deployment to be operational. It is described declaratively by CoreManifest, lives in @mnemose/bootstrap, and is the canonical source of truth for:

• Control-plane tenant ID
• Queue topic names (commands / events)
• Required core agent-kernel entries (UUID, label, role, permission tier, platform)

Prerequisite: 2. Deploy the platform complete. If you have already onboarded the control-plane tenant via Step 3, the manifest’s tenantId will match it. Otherwise the manifest can be applied against any tenant scope.

The manifest

packages/bootstrap/src/core-manifest.ts

export type CoreManifest = {
  tenantId: string;
  topics: { commands: string; events: string };
  subscriptions: { commandRunner: string; iamEscalation: string };
  kernels: CoreKernelEntry[];
};

export function coreManifestForEnv(
  env: "development" | "staging" | "production",
): CoreManifest;

The topics names map onto the Cloudflare Queues created by infra/index.ts (mnemose-commands-<env> / mnemose-events-<env>); the subscriptions names are retained from the Pub/Sub era and remain the canonical subscription identifiers.

The same manifest drives:

Consumer	How it uses the manifest
infra/index.ts	Pulumi config keys seeded by the manifest names
scripts/bootstrap-local-dev.mjs	Local dev applies the manifest to local wrangler state and dev kernel rows
services/gateway (platformCore query)	Compares enrolled agent_kernels rows against manifest.kernels
services/gateway (provisionPlatformCore mutation)	Upserts every manifest.kernels row with .onConflictDoNothing()
apps/console/Fleet/PlatformCorePanel	Renders health derived from the resolver

Inspect core health

In the console, navigate to /fleet. The <PlatformCorePanel> at the top of the view shows one of three states:

State	Visual	Meaning
Loading	Spinner	First poll in progress
Healthy	Green strip — “Platform core healthy — N kernels online”	All manifest kernels exist and are online
Unhealthy	Amber card — per-kernel badges + “Provision Core” / “Reconnect” buttons	At least one manifest kernel is missing or offline

You can also call the query directly:

query CoreHealth {
  platformCore {
    healthy
    kernels {
      id
      label
      role
      platform
      permissionTier
      status   # "online" | "offline" | "pending" | "missing"
    }
  }
}

Provision missing kernels

If the panel reports unhealthy, click Provision Core (or run):

mutation Provision {
  provisionPlatformCore
}

The resolver in services/gateway/src/schema/platform.ts iterates the manifest and inserts every kernel row with ON CONFLICT DO NOTHING. It is idempotent and safe to call repeatedly — existing rows are untouched.

The inserted rows start with status: "pending". They transition to "online" when the matching kernel process enrolls and connects to the broker (see 5. Enroll a remote kernel).

How assessCoreHealth decides

packages/bootstrap/src/core-health.ts

export function assessCoreHealth(
  manifest: CoreManifest,
  enrolledKernels: { id: string; status: string }[],
): CoreHealth;

Pure function — no DB, no I/O. Used in the gateway resolver, the CLI, and tests. Compares manifest IDs against enrolled rows:

• Row absent → status: "missing"
• Row present and status is online/offline/pending → use that value
• Row present, status is anything else → status: "offline" (defensive)

healthy = manifest.kernels.length > 0 && all status === "online".

Customising the manifest

The dev manifest is the only concrete one today. Staging and production manifests are stubbed in core-manifest.ts — populate them with stable UUIDs that match the kernel hosts the deployment will use.

When changing the manifest:

1. Bump the UUIDs (or keep them — they are stable per environment).
2. Update infra/Pulumi.<stack>.yaml config keys to match topic/subscription names.
3. Re-deploy: queues are idempotent, provisionPlatformCore upserts any new kernel rows.

Next

→ 5. Enroll a remote kernel