Implementation Status Matrix

This document provides a comprehensive overview of which protocols from @objectstack/spec have been implemented in the ObjectStack packages.

Status Legend

---

Core Infrastructure (Kernel)

Runtime & Kernel

Notes:

• Core package provides complete microkernel implementation
• Plugin system supports lifecycle hooks, dependency resolution, and service injection
• Event bus enables inter-plugin communication
• ObjectQL serves as the example kernel — a reference implementation that will be modularized into plugins

Data Infrastructure

Notes:

• ObjectQL implements complete IDataEngine interface
• Memory driver is reference implementation (basic CRUD only)
• Advanced query features (aggregations, window functions) require production drivers
• Memory driver supports aggregations (groupBy, count, sum, avg, min, max)

Metadata Framework

• Metadata API (list types, list items, get item) is fully functional
• Metadata is loaded from config files or dist/objectstack.json at startup and held in memory
• MetadataPlugin no longer registers sys_metadata / sys_metadata_history into the runtime or auto-bridges ObjectQL to DatabaseLoader
• Future: production Artifact API loader and durable local artifact cache

System Services

---

Data Layer (ObjectQL)

Core Data Modeling

Field Type Support:

Query Engine

Notes:

• Full query protocol is defined and implemented in ObjectQL engine
• Actual query capability depends on driver implementation
• Memory driver supports basic queries only
• Client SDK provides query builder utilities

---

API Layer (Transport)

HTTP & REST

The data (/data), metadata (/meta), and batch endpoints are implemented in @objectstack/rest (rest-server.ts); @objectstack/runtime re-exports RestServer from that package and provides the underlying HTTP server/dispatcher.

REST Endpoints Implemented:

Advanced Protocols

---

UI Layer (ObjectUI)

View System

Notes:

• All UI protocols are fully defined in spec
• Metadata API can retrieve UI definitions (views, apps, pages, dashboards, reports, actions)
• Active Studio/ObjectUI source lives in the sibling ../objectui repo and is bundled into packages/console via the objectui refresh workflow
• Metadata-admin curated forms now merge server-only fields back into the save payload, so a Studio form that exposes only part of a metadata type should not strip newer protocol properties
• The 2026-05-08 → 2026-06-08 ObjectUI scan covered 910 non-merge frontend commits. The largest functional clusters were metadata-admin/Studio, master-detail forms, reports/dashboards, record detail/related lists, action transport, flow designer, developer/API pages, AI draft publishing, and i18n.
• React SDK provides data hooks; the cross-surface renderer is still being completed in ObjectUI rather than in this backend repo

---

Automation Layer

Notes:

• Hook system is implemented in ObjectQL (beforeFind, afterInsert, etc.) — this is data-layer eventing, not workflow automation
• The flow/workflow engine ships in @objectstack/service-automation (engine.ts, builtin nodes, plugin.ts); approvals, webhooks, and triggers ship as plugin-approvals, plugin-webhooks, plugin-trigger-record-change, and plugin-trigger-schedule
• ETL and Sync protocols are defined but not yet implemented as plugins
• Discovery API reports automation service as unavailable until a plugin is registered

---

Security Layer

Auth Service (plugin-auth)

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

Notes:

• All security protocols (identity + permission) are delivered by a single auth plugin — matching CoreServiceName
• Client SDK supports bearer token header — but token validation requires the auth plugin
• Auth route (/auth/*) only appears in Discovery when the auth plugin is registered
• Fine-grained authorization (RLS, sharing, territory) is internal to the auth plugin
• Phase-1 RBAC enforcement is live end-to-end: REST → ObjectQL → SecurityPlugin middleware now receives a populated ExecutionContext (userId, tenantId, positions, permissions). Default member_default permission set ships a wildcard RLS rule organization_id == current_user.organization_id plus per-object overrides sys_organization_self (id == current_user.organization_id) and sys_user_self (id == current_user.id) for the global tables that lack an organization_id column. The earlier tenantField indirection (RLS expressions written against an abstract tenant_id column then rewritten to the configured physical column at compile time) was removed — the placeholder, the column name, and RLSUserContext.organization_id are now the same name end-to-end. The legacy objectql.registerTenantMiddleware (hardcoded where.tenant_id injection that pre-dated SecurityPlugin) has been removed; SecurityPlugin is the sole authority for tenant isolation. Analytics now uses the same reusable read scope via security.getReadFilter, so dataset-bound dashboards/reports do not bypass RLS. Verified cross-organization isolation on pnpm dev:crm across sys_organization, sys_member, sys_user, sys_user_permission_set, sys_position_permission_set. Anonymous traffic is denied by default (the ADR-0056 D2 default-deny flip landed: requireAuth defaults to true); an explicit requireAuth: false opt-out logs a boot-time warning, and public forms do not depend on any fall-open — they carry a declaration-derived publicFormGrant (ADR-0056 Option A).
• OWD / sharing-model enforcement is live and proven end-to-end (ADR-0056): private, public_read, public_read_write, and controlled_by_parent are enforced through plugin-sharing + plugin-security and verified by dogfood proofs over the real HTTP stack. object.sharingModel accepts the canonical OWD vocabulary only (private / public_read / public_read_write / controlled_by_parent) — the legacy read / read_write / full aliases were removed from the enum (ADR-0090 D4), and an unset sharingModel on a custom object resolves to private (ADR-0090 D1). RLS owner policies resolve current_user.email in addition to id / organization_id / positions (#2054). Permission sets may declare isDefault: true as the install-time suggestion to bind the set to the built-in everyone position (ADR-0090 D5, superseding the ADR-0056 D7 fallback-profile mechanism).

---

AI Layer

Notes:

• Complete AI protocol suite defined
• The ObjectOS runtime ships agents, model registry, conversation, tools, skills, and an eval harness
• RAG/embedding is provided by @objectstack/service-knowledge plus the knowledge-memory, knowledge-ragflow, and embedder-openai plugins (all open)
• Cost tracking, predictive, and the DevOps agent protocols remain spec-only

---

Integration Layer

---

QA & Testing

Features Implemented:

• TestSuite, TestScenario, TestStep schemas ✅
• HTTP adapter for testing ✅
• MSW integration for browser mocking ✅
• QA runner in core ✅

---

Implementation Roadmap

Phase 1: Core Infrastructure ✅ COMPLETE

• Microkernel & Plugin System
• Logging System
• Service Registry
• Event Bus
• API Registry

Phase 2: Data Layer ✅ COMPLETE

• ObjectQL Engine
• Schema Registry
• Protocol Implementation
• Basic Query Support
• CRUD Operations
• Hook System

Phase 3: API Layer ✅ COMPLETE

• REST Server
• HTTP Server (Hono)
• Endpoint Generation
• Discovery API
• Metadata API
• Batch Operations
• HTTP Caching

Phase 4: Client SDKs ✅ COMPLETE

• TypeScript Client
• React Hooks
• Query Builder
• Error Handling

Phase 5: Developer Tools ✅ COMPLETE

• CLI Tools
• Config Validation
• Development Server
• Metadata Management

Phase 6: Advanced Features 🚧 IN PROGRESS

• Production Database Drivers — @objectstack/driver-sql (PostgreSQL/MySQL dialects), @objectstack/driver-mongodb, and @objectstack/driver-sqlite-wasm ship; additional dialect coverage ongoing
• GraphQL API
• OData Support
• Realtime Subscriptions
• WebSocket Support

Phase 7: UI Layer 🟡 IN PROGRESS

• UI Renderer
• Studio metadata-admin engine — generic metadata list/detail/edit surfaces, live preview, draft/publish/rollback, create-mode forms, server-side diagnostics, package scoping, and skew-safe curated inspectors
• Form conditional rules — ObjectUI supports visibleWhen, readonlyWhen, requiredWhen, row-scoped inline-grid rules, and required-on-submit enforcement
• Master-detail forms — inline subforms, spreadsheet-style line items, atomic batch create/edit, lookup auto-fill, line ordering, duplicate/reorder, and subtotal/tax/total stack
• Record detail + related lists — derived related lists, record-page assignment, action slots, system/audit sections, and opt-in reference rail
• Dashboard renderer/editor — widget layout persistence, drill-downs, pivot/funnel/table/list widgets, type-aware cells, and per-widget dataset binding authoring (dataset, dimensions, values)
• Report renderer/editor — spec-native summary/matrix/joined reports, chart/KPI blocks, drill-downs, dataset-bound reports, and i18n labels
• Flow/page designers — typed flow node config panels, simulator/debug runner, page block canvas, slotted record pages, and schema-driven block inspectors
• Action transport — row/global/header actions, modal parameter collection, visible CEL, popup-safe open actions, and nested action runner sharing
• Developer/admin console surfaces — Integrations & APIs, public forms, flow runs, approvals inbox, settings, marketplace/package management, AI draft review/publish
• List View Renderer full protocol parity
• Cross-surface UI Renderer full protocol parity
• Theme Engine

Phase 8: Automation (Plugin) 🟡 IN PROGRESS

• Flow Engine Plugin
• Approval Node Plugin
• ETL Pipeline Plugin
• Trigger Registry Plugin

Phase 9: Security (Plugin) 🟡 PHASE-1 LANDED

• Authentication Plugin (@objectstack/plugin-auth, better-auth)
• Authorization Plugin — @objectstack/plugin-security enforces CRUD/FLS/RLS in the ObjectQL middleware chain; REST → ObjectQL now propagates ExecutionContext end-to-end (Phase-1)
• Row-Level Security — default member_default permission set applies a wildcard organization_id == current_user.organization_id rule plus per-object overrides sys_organization_self / sys_user_self. The earlier tenantField rewrite indirection was removed: RLS column, placeholder, and RLSUserContext.organization_id use the same canonical name end-to-end
• Analytics RLS bridge — @objectstack/service-analytics auto-bridges to security.getReadFilter(object, context) and fails closed when read-scope resolution cannot be safely applied
• Multi-tenancy — verified cross-organization isolation on pnpm dev:crm (Alice@OrgAlpha vs. Bob@OrgBeta only see their own records across sys_organization, sys_member, sys_user, and sys_*_permission_set link tables)
• Legacy objectql.registerTenantMiddleware removed — SecurityPlugin is now the sole tenant-isolation authority
• Organization-Wide Defaults / sharing model — private, public_read, public_read_write, and controlled_by_parent enforced via plugin-sharing + plugin-security, proven by dogfood over the real HTTP stack (ADR-0056). Canonical vocabulary only — legacy aliases removed from the enum (ADR-0090 D4); unset custom-object OWD resolves to private (ADR-0090 D1)
• Sharing Rule evaluator — criteria rules re-evaluated on afterInsert / afterUpdate (plugin-sharing/rule-hooks.ts); enforced recipients are user / position / unit_and_subordinates (business-unit-subtree widening, ADR-0057 D5 / ADR-0090 D3); owner-type rules and group/guest recipients remain [experimental — not enforced]
• Everyone-baseline suggestion — a permission set may set isDefault: true as the install-time suggestion to bind it to the built-in everyone position; resolved per-request as an additive baseline, no fallback cliff (ADR-0090 D5)
• Default-deny for anonymous traffic — the global default-deny flip landed (ADR-0056 D2): requireAuth defaults to true, explicit requireAuth: false opt-outs warn at boot, and public forms self-authorize via publicFormGrant (Option A)
• Studio RLS visual editor
• Per-user×org permission cache
• Audit UI / denied-access logging

Phase 10: AI Integration 📋 PLANNED

• Agent Framework
• RAG Pipeline
• NLQ Engine
• Model Registry

---

Summary Statistics

Overall Implementation Status

Implementation Coverage

Implementation spans every layer of the platform. Core infrastructure, data modeling, the REST API, client SDKs, security (Phase-1), automation, AI, and integration all have shipping implementations. Remaining gaps are concentrated in specific protocols (OData/GraphQL, cross-surface UI renderer parity, sharing/territory authorization, ETL/Sync, and a handful of governance and AI-cost services) rather than entire layers. Refer to the per-layer tables above for protocol-level status.

Core Functionality Status

---

Package Feature Matrix

The REST server, endpoint generation, and data/meta/batch endpoints are implemented in the @objectstack/rest package (not shown as a column above); @objectstack/runtime re-exports RestServer from it.

---

Next Steps