Kernel Services Checklist

The ObjectStack protocol defines 17 kernel services registered via the CoreServiceName enum. Each service maps to a set of protocol methods (57 total), governed by the ObjectStackProtocol interface.

Key architecture principle: The kernel itself only provides data and metadata (framework). Everything else — including auth and automation — is delivered by plugins. The current @objectstack/objectql package is an example kernel implementation to get the basic API running; production kernels will be rebuilt as new plugins.

Architecture Overview

┌─────────────────────────────────────────────────────────┐
│                     Kernel Layer                         │
│  ┌──────────────────┐  ┌──────────────────────────────┐ │
│  │  metadata (⚠️)   │  │  data + analytics (✅)       │ │
│  │  In-memory only   │  │  ObjectQL example kernel     │ │
│  │  DB persistence   │  │  Will be rebuilt as plugins  │ │
│  │  pending          │  │                              │ │
│  └──────────────────┘  └──────────────────────────────┘ │
├─────────────────────────────────────────────────────────┤
│                    Plugin Layer                           │
│  All other services: auth, automation, workflow, ui,     │
│  realtime, notification, ai, i18n, graphql, search,     │
│  file-storage, cache, queue, job                         │
│                                                          │
│  Discovery API reports: enabled/unavailable/degraded     │
│  per service so clients adapt their UI accordingly       │
└─────────────────────────────────────────────────────────┘

Service Overview

1. metadata Service ⚠️ Framework

Service Name: metadata · Criticality: required
Implementation: Kernel — SchemaRegistry (in-memory)
Route Mounts: /api/v1/meta, /api/v1, /api/v1/packages

Protocol Methods

Current Limitations

The metadata service is a framework — it works with an in-memory SchemaRegistry loaded from YAML/TS config files at startup.

Discovery: Per-Service Status

The discovery endpoint returns a services map so clients know what is available:

{
  "services": {
    "metadata": {
      "enabled": true, "status": "degraded",
      "route": "/api/v1/meta", "provider": "kernel",
      "message": "In-memory registry; DB persistence pending"
    },
    "data": {
      "enabled": true, "status": "available",
      "route": "/api/v1/data", "provider": "kernel"
    },
    "auth": {
      "enabled": false, "status": "unavailable",
      "message": "Install an auth plugin to enable"
    }
  }
}

2. data Service ✅ Implemented

Service Name: data · Criticality: required
Implementation: @objectstack/objectql → ObjectQL (IDataEngine)
Route Mount: /api/v1/data

Protocol Methods

Driver Support

3. analytics Service ✅ Implemented

Service Name: analytics · Criticality: optional
Implementation: @objectstack/objectql (driver-level capability)
Route Mount: /api/v1/analytics

Protocol Methods

Features

• Cube semantic queries: measures / dimensions / filters → ObjectQL aggregation
• Auto-generated metadata from SchemaRegistry (numeric → sum/avg, date → time dimensions)

4. auth Service ❌ Plugin Required

Service Name: auth · Criticality: required
Route Mount: /api/v1/auth — only exposed when a plugin registers the auth service

Plugin Requirements

The auth service covers both authentication (identity) and authorization (permissions). There is no separate permission service in CoreServiceName.

Spec Files: identity.zod.ts, role.zod.ts, organization.zod.ts, auth-config.zod.ts, tenant.zod.ts

5–7. Business Services ❌ Plugin Required

5. ui Service — 5 methods

listViews, getView, createView, updateView, deleteView
View CRUD, layout engine, action registry, permission filtering.

6. workflow Service — 5 methods

getWorkflowConfig, getWorkflowState, workflowTransition, workflowApprove, workflowReject
State machine engine, approval processes, audit trail.

7. automation Service — 1 method

triggerAutomation
Trigger engine, event triggers from ObjectQL hooks, flow executor, scheduled triggers.

8–11. Communication Services ❌ Plugin Required

8. realtime — 6 methods

realtimeConnect, realtimeDisconnect, realtimeSubscribe, realtimeUnsubscribe, setPresence, getPresence

9. notification — 7 methods

registerDevice, unregisterDevice, getNotificationPreferences, updateNotificationPreferences, listNotifications, markNotificationsRead, markAllNotificationsRead

10. ai — 4 methods

aiNlq, aiChat, aiSuggest, aiInsights

11. i18n — 3 methods

getLocales, getTranslations, getFieldLabels

12–17. Infrastructure Services ❌ Plugin Required

Recommended Development Phases

Phase 1: Foundation (P0)

Phase 2: Business Engine (P1)

Phase 3: Advanced Capabilities (P2)

Plugin Implementation Pattern

import type { Plugin } from '@objectstack/core';

export const authPlugin: Plugin = {
  name: 'plugin-auth',
  provides: ['auth'], // CoreServiceName value
  
  async init(ctx) {
    const engine = ctx.getService<IDataEngine>('data');
    const authService = new AuthServiceImpl(engine);
    ctx.registerService('auth', authService);
  },
  
  async start(ctx) {
    const auth = ctx.getService<IAuthService>('auth');
    await auth.onReady();
  },
  
  async stop(ctx) {
    const auth = ctx.getService<IAuthService>('auth');
    await auth.shutdown();
  },
};

When a plugin registers a service, the discovery endpoint automatically updates:

• services.auth.enabled → true, status → "available", route → "/api/v1/auth"
• routes.auth → "/api/v1/auth" appears in routes
• features capability flags update accordingly

Next Steps