IMPERIAL Multi-Server Operations Professional

Mission family: IMPERIAL-SERVER-MESH Version: 1.0.0 Purpose: professionalize deployment, CRM runtime maintenance, health, evidence, topology and failover across the current three governed runtime nodes and future 20+ server fleets.

This skill preserves IMPERIAL Core's Federated Multi-Orchestrator Architecture. It does not create a global orchestrator.

Federated Runtime Node -> CRM Skill -> Local Guardian/Policy -> Server Mesh Heartbeat -> Supabase Mesh Registry -> Advisory Topology/Failover Plan -> Audit Evidence

Canonical boundaries:

• AI Passport remains separate from server identity.
• Server identity does not grant agent authority.
• Mesh membership does not grant T2/T3 CRM authority.
• Guardian Core / Approval Gateway / Audit Ledger remain authoritative for sensitive actions.
• ORION remains ALWAYS_ON and ADVISORY_ONLY.
• Public/Private Boundary is preserved.
• CRYPTO IMPERIAL Ecosystem Boundary is not collapsed into CRM/server operations.
• FREE_ONLY is fail-closed for nodes flagged as non-free.

• CRM-NODE-001 -> oromaskevic23/imperial-nca-runtime-recovery -> MAIN_NCA_RUNTIME.
• CRM-NODE-002 -> oromaskevic23/imperial-nca-31day-runtime -> NCA_31DAY_RUNTIME.
• CRM-NODE-003 -> oromaskevic23/imperial-morgan-runtime -> MORGAN_RUNTIME.

These are the three currently configured runtime projects. Future nodes are added to the canonical imperial_mesh.server_nodes registry by governed administration; runtime nodes cannot self-register.

Supabase schema: imperial_mesh. Edge Function: imperial-server-mesh. Authentication: dedicated server-only IMPERIAL_SERVER_MESH_KEY, stored encrypted in each runtime and verified by SHA-256 representation server-side.

Allowed runtime operations:

• heartbeat — node reports bounded health and CRM counts.
• registry — node reads non-secret topology metadata.
• node_get — node verifies its own or another registered node's non-secret mesh state.

Not exposed to runtime nodes:

• arbitrary node registration;
• privilege/capability grants;
• billing changes;
• secret retrieval;
• T2/T3 CRM authorization;
• financial execution.

runtime_adapter.ts executes the local imperial-crm-agent-professional maintenance cycle, verifies canonical CRM memory chain state, sends a signed server-mesh heartbeat, reads the node state back, and summarizes the topology.

RUNNING_BOUNDED means the server's CRM maintenance cycle, registry identity and canonical-memory verification passed. It does not mean every registered NCA is simultaneously doing CRM work.

The topology layer uses deterministic rendezvous assignment over only eligible nodes:

crm_enabled == true free_only == true state == RUNNING_BOUNDED

Workload keys can be assigned with configurable replicas. A degraded, CRM-disabled or non-free node is automatically excluded from new assignments.

The reference design is policy-limited to 64 nodes per operational mesh generation; this is a design/operational guardrail, not a database hard limit. Larger federations should be split into runtime domains and coordinated through the existing Federated Multi-Orchestrator Architecture.

self_test.ts runs a deterministic 24-node topology test:

• 24 nodes (>20 requirement);
• 2,400 workload keys;
• 3 replicas per workload;
• 7,200 total assignments;
• unique replicas;
• all 24 nodes receive work;
• degraded node excluded;
• CRM-disabled node excluded;
• non-free node excluded;
• distribution balance checked.

Current passing evidence: 11/11 PASS, min assignments 280, max 330, max/min ratio ~1.18.

Truth boundary: this proves the software topology supports a 24-node configuration. It does not claim 24 physical servers are currently deployed.

• mesh_client.ts — authenticated Server Mesh API client.
• topology.ts — eligible-node filtering, rendezvous assignment, replication and topology summary.
• runtime_adapter.ts — CRM maintenance + canonical chain + heartbeat/readback.
• self_test.ts — 24-node scale/failover test.

Prefer reuse of existing healthy watchdog/interval cycles instead of creating duplicate cron jobs. This avoids unnecessary scheduler load and respects free-tier cron limits.

A node is promoted through server states only on evidence: REGISTERED -> CONFIGURED -> TESTED -> RUNNING_BOUNDED.

Never use LIVE, RUNNING, or VERIFIED based solely on file presence.