Graph Kernel Analysis · Reaktor Docs

The refined thesis

Reaktor is not primarily a framework full of features. It is a universal composition kernel. Modules provide focused capabilities. The graph combines them. Visitors interpret them. Capabilities adapt them. Commands mutate them safely. AI works productively because the whole system speaks one structured language.

Reaktor’s goal is not to be the best specialized tool for every individual concern. The goal is to be the best common language for composing most concerns.

Modules

Focused primitives: auth, layout, design, actors, pub/sub, permissions, chat, geo, notifications, queues, DB, APIs, deployment, analytics, telemetry, AI.

Graph

The common language that combines modules into apps, servers, workers, workflows, native bridges, tools, deployments, and AI-readable systems.

Tools & AI

DevTools, Blueprint, deployment planners, validators, and AI agents operate on snapshots, events, visitors, and commands instead of guessing from raw code.

Kernel ontology

The kernel should remain tiny. It should provide only the primitives needed to describe, inspect, validate, mutate, and deploy application structure. Everything else is module vocabulary.

Graph

Node

Port

Edge

Facet

Capability

Visitor

Snapshot

Command

Primitive	Responsibility	Why it matters
Graph	Owns nodes, indexes, scope, lifecycle, and events. It is the composition boundary.	Lets a product, feature, service, subsystem, deployment unit, or runtime island be represented as one coherent structure.
Node	Owns ports, lifecycle, capabilities, and facets. It is the unit of application structure.	Anything important can be a node: screen, route, service, actor, worker, repository, queue, native operation, AI tool.
Port	Declares a typed contract.	Ports make dependencies explicit, inspectable, replaceable, testable, deployable, and polyglot.
Edge	Connects a consumer contract to a provider contract.	Edges become the unit of wiring, tracing, replacement, transport, and deployment cuts.
Facet	Adds meaning without changing the kernel.	Navigation, services, actors, workflows, queues, React, Compose, deployment, and AI can all be plugins.
Capability	Describes what a runtime, platform, device, or environment can do.	Modules can gracefully upgrade or degrade across Android, iOS, Web, Workers, Spring, native, and React.
Visitor	Interprets the graph without changing the kernel.	Validation, deployment partitioning, AI context, telemetry, performance analysis, graphify, and source maps become visitors.
Event	Tells tools and runtimes what changed.	Blueprint, DevTools, telemetry, Shadow, performance panels, and AI diagnosis all consume graph events.
Snapshot	Gives tools and AI a read-only view.	Safe inspection, replay, comparison, prompt context, visual tooling, and remote debugging all use snapshots.
Command	Gives tools and AI a safe mutation language.	DevTools and AI do not poke runtime internals; they propose typed, validated graph commands.

Target kernel sketch

class Graph(
    val id: GraphId,
    val label: String,
    val runtime: ReaktorRuntime,
) {
    val nodes: NodeSet
    val edges: EdgeSet
    val facets: FacetSet

    val index: GraphIndex
    val lifecycle: LifecycleState
    val scope: GraphScope
    val events: GraphEventBus

    fun attach(node: Node): AttachResult
    fun detach(node: Node): DetachResult

    fun <C : Any> connect(
        consumer: ConsumerPort<C>,
        provider: ProviderPort<C>,
        facets: List<Facet> = emptyList(),
    ): Result<Edge<C>>

    fun snapshot(): GraphSnapshot
    fun execute(command: GraphCommand): CommandResult
}

open class Node(
    val graph: Graph,
    val id: NodeId,
    val label: String = "",
) {
    val ports: PortSet
    val facets: FacetSet
    val capabilities: CapabilityRequirements
    val lifecycle: LifecycleState
}

Kernel laws

The kernel should enforce a small number of hard laws. These laws keep the graph powerful without turning it into a monolith.

1. Identity is stable

Graphs, nodes, ports, edges, contracts, facets, capabilities, and commands need stable IDs. Runtime UUIDs are activation identities, not source/deployment identities.

2. Ports connect by contract

Local Kotlin types are implementation details. ContractId is the universal identity for polyglot and distributed boundaries.

3. Edges are explicit

Architecturally meaningful dependencies should appear as edges or facets. Hidden wiring should not matter for the graph model.

4. Facets add meaning

The kernel never learns “auth,” “route,” “actor,” “queue,” “React,” or “Cloudflare.” Modules attach facets.

5. Capabilities are observed

Modules do not branch on platform strings. They use capability profiles and strategy selection.

6. Visitors interpret

Validation, AI context, deployment, telemetry, source maps, documentation, and optimization are visitors.

7. Commands mutate

DevTools and AI emit typed graph commands. Runtime mutation happens through validation, not direct object poking.

8. Snapshots are read-only

Tools inspect snapshots and events. They modify graphs through commands and patches.

9. Code remains truth

The graph is projected from code/manifests and can be edited through structured commands, but visual editing must not become opaque truth.

10. Modules cannot bloat the kernel

New concerns register facets, validators, renderers, adapters, codegen, and command handlers.

Module model

A Reaktor module should do one concern well. It should contribute vocabulary to the graph, not expand the kernel.

interface ReaktorModule {
    val id: ModuleId
    val version: SemVer

    fun facets(): List<FacetSpec<*>>
    fun capabilities(): List<CapabilitySpec<*>>
    fun contracts(): List<ContractSpec<*>>

    fun validators(): List<GraphValidator>
    fun visitors(): List<GraphVisitor<*>>
    fun commandHandlers(): List<GraphCommandHandler<*>>

    fun renderers(): List<GraphRendererContribution>
    fun inspectors(): List<InspectorContribution>

    fun codegen(): List<CodegenContribution>
    fun runtimeAdapters(): List<RuntimeAdapter>
}

Module vocabulary

AuthFacet, RouteFacet, ServiceFacet, ActorFacet, QueueFacet, DeploymentFacet, ActionFacet, TelemetryFacet.

Runtime behavior

Modules install adapters, policies, codecs, transports, validators, inspectors, codegen, and command handlers.

Tooling surface

Modules contribute render hints, inspector panels, graph commands, source maps, validation messages, and AI schemas.

Example modules

reaktor-authreaktor-navigationreaktor-tactilereaktor-servicereaktor-dbreaktor-busreaktor-actorreaktor-workreaktor-notificationsreaktor-mediareaktor-locationreaktor-cloudflarereaktor-googlereaktor-ffireaktor-telemetryreaktor-devopsreaktor-aireaktor-mcpreaktor-desktop

Canonical runtime planes

Planes describe ownership boundaries. They prevent the runtime from collapsing into a monolith where every class knows too much.

Plane	Owns	Typical modules
Capability / environment	Device, platform, execution, network, renderer, permission, power, thermal, storage.	core, capability, permissions, media, location, notification adapters.
Graph / action	Routes, panes, payloads, lifecycle, ports, services, repositories, actions.	graph, graph-port, navigation, action, auth policy.
Transport / messaging	HTTP, WebSocket, queues, Pub/Sub, mesh, FFI, envelopes, retries, DLQ, idempotency.	service, io, bus, cloudflare, google, ffi.
Data / persistence	Local cache, object store, SQL, CRDTs, blobs, sync, archival, tenant isolation.	db, cloudflare D1/R2/KV, Supabase, Memgraph adapters.
UI / interaction	Compose, React, design tokens, tactile state, adaptive layouts, components, accessibility.	tactile, ui, compose, react host, layout, design.
Intelligence / tooling	Compiler, graphify, shadow, devtools, deployment, telemetry, MCP, AI copilot.	compiler, graphify, shadow, devops, flow, desktop, ai, mcp.

Targets and languages

Primary runtime targets

These should be first-class targets in the Reaktor runtime and deployment model:

AndroidiOSWebJS WorkerSpring Boot ServerCompose MultiplatformKotlin MultiplatformReact

Language tiers

Native: Kotlin

First-class: C++, TypeScript

Second layer: Dart, Go, Python, C#

The graph should not care about language-specific details. It should care about contracts, schemas, operation IDs, transport facets, runtime targets, capability profiles, and codecs.

Universal distributed/polyglot boundary

data class OperationId(
    val namespace: String,
    val name: String,
    val version: Int,
)

data class OperationContract(
    val id: OperationId,
    val request: SchemaId,
    val response: SchemaId,
    val effects: Set<EffectKind>,
)

Android ConsumerPort<Auth.SignIn>
    -- Edge + TransportFacet(HTTP) -->
Spring ProviderPort<Auth.SignIn>

Worker ConsumerPort<Webhook.Process>
    -- Edge + TransportFacet(QUEUE) -->
JVM ProviderPort<Webhook.Process>

Kotlin ConsumerPort<Image.Encode>
    -- Edge + FfiFacet(C++) -->
C++ ProviderPort<Image.Encode>

Minimum extension vocabulary

These facets and capabilities cover most applications without requiring the kernel to understand any specific domain.

Structural facets

RouteFacet, UiFacet, ContainerFacet, PaneFacet, ServiceFacet, RepositoryFacet, ActorFacet, WorkflowFacet, QueueFacet, PubSubFacet, NativeFacet, ExternalFacet, DeploymentFacet, TelemetryFacet, PolicyFacet, ActionFacet, StateFacet, DataFacet, CapabilityRequirementFacet.

Edge facets

NavigationFacet, AttachmentFacet, InvocationFacet, TransportFacet, AsyncMessageFacet, FfiFacet, DataReadFacet, DataWriteFacet, AuthPolicyFacet, RetryFacet, CacheFacet, CircuitBreakerFacet, BackpressureFacet, TraceFacet, DeploymentCutFacet.

Capability facets

Camera, MediaPicker, Location, Maps, PushNotification, LocalNotification, Haptics, CredentialAuth, SecureStorage, OfflineDb, ObjectStorage, RealtimeSocket, Queue, PubSub, Workflow, DurableState, EdgeCompute, ServerCompute, NativeCompute, AiInference, VectorSearch, Payment, Analytics, Telemetry.

Dominant graph shapes

Most applications reduce to combinations of a small number of graph shapes. If these are first-class, Reaktor covers the majority of real applications.

1. Route + Screen + State

RouteNode
    -> ScreenNode
    -> ControllerState
    -> Repository

Covers mobile apps, web apps, desktop apps, dashboards, and CRUD apps.

2. Service + Repository

Controller
    -> ServiceOperation
    -> Repository
    -> Database

Covers APIs, server apps, admin tools, and client/server apps.

3. Offline-first sync

LocalRepository
    -> MutationQueue
    -> SyncService
    -> RemoteRepository

Covers field apps, consumer apps, mobile-first SaaS, and disconnected workflows.

4. Async workflow

ServiceRequest
    -> Queue
    -> Worker
    -> WorkflowStep
    -> Retry / DLQ

Covers commerce, notifications, media processing, automation, and document processing.

5. Realtime room / actor

RoomRoute
    -> ActorRef
    -> Mailbox
    -> PubSub/WebSocket
    -> Persistence

Covers chat, collaboration, presence, multiplayer, and live dashboards.

6. Capability strategy

FeatureNode
    -> CapabilityRequirement
    -> StrategySelector
    -> Native / Emulated / Fallback

Covers camera, location, push, haptics, storage, native compute, offline, and network quality.

7. Deployment cut

ConsumerPort
    -> Edge + DeploymentCutFacet
    -> ProxyNode
    -> ProviderPort

Covers mobile/server, server/worker, Kotlin/C++, React/Kotlin, and edge/origin boundaries.

8. AI command loop

GraphSnapshot
    -> AI Visitor Context
    -> GraphCommand
    -> Validator
    -> PatchPlanner
    -> Compile/Test

Covers DevTools, copilots, agents, generated UI, deployment assistants, and automation.

Representative application set

These examples provide a representative, near-exhaustive sample suite. They are not just demos; they are acceptance tests for whether the kernel can cover 80% of application types.

1 Notes / Personal Knowledge App

Category: basic CRUD + offline-first + sync.

Representative apps: notes, tasks, habit tracker, personal CRM, journaling, bookmark manager.

AndroidiOSWebDesktop

RouteFacet:
    /notes
    /notes/{id}
    /search
    /settings

RepositoryFacet:
    NotesRepository
    TagRepository

ServiceFacet:
    SyncService

DataFacet:
    Local ObjectStore
    Remote sync endpoint

Key concerns: offline-first cache, local mutation queue, conflict resolution, search, adaptive layout, optional auth.

Proves: Reaktor can be lightweight. A small app should feel simpler than combining navigation, SQLite, DI, sync, and platform adapters manually.

2 Consumer Mobile App with Auth and Profile

Category: mainstream mobile app shell.

Representative apps: fitness app, dating app, personal finance, travel app, food app.

AndroidiOSWeb

AuthGraph:
    OnboardingRoute
    LoginRoute
    ProfileSetupRoute

MainGraph:
    HomeRoute
    ProfileRoute
    SettingsRoute
    NotificationsRoute

ServiceGraph:
    AuthService
    UserService
    ProfileService

CapabilityGraph:
    CredentialAuth
    PushNotification
    SecureStorage

Key concerns: auth state gates routes, onboarding result flows into main graph, capability fallback, push opens typed graph route, telemetry links actions to routes/services.

Proves: Reaktor can replace navigation + auth flow + capability handling for mainstream mobile apps.

3 Offline Field-Service App

Category: offline-first enterprise mobile.

Representative apps: inspection app, field sales, delivery ops, utility repair, health worker app.

AndroidiOSSpring Boot

AssignmentGraph:
    JobListRoute
    JobDetailRoute
    ChecklistRoute
    SignatureRoute
    MediaCaptureRoute

RepositoryGraph:
    JobRepository
    ChecklistRepository
    PhotoRepository

WorkGraph:
    SyncWork
    UploadMediaWork
    RetryFailedReportsWork

CapabilityGraph:
    Camera
    Location
    OfflineDb
    NetworkQuality

Key concerns: offline for days, images/signatures, sync retry, conflict resolution, geotagging, audit trail.

Proves: Capability profiles and graceful degradation are not optional; they are core to serious apps.

4 Social / Messaging App

Category: real-time consumer social.

Representative apps: BestBuds, chat apps, communities, dating chat, event social.

AndroidiOSWebJS WorkerSpring Boot

ClientGraph:
    ChatListRoute
    ChatRoute
    FriendProfileRoute
    GroupProfileRoute
    MediaPickerRoute

ActorGraph:
    ChatRoomActor
    PresenceActor
    TypingIndicatorActor

BusGraph:
    MessagePublished
    MessageDelivered
    NotificationRequested

NotificationGraph:
    PushFanoutWorkflow
    ReceiptHandler

Key concerns: WebSocket/PartySocket, actor-per-room, offline message cache, typing/presence, media upload, notification fanout, route from notification.

Proves: Realtime, offline, notifications, media, and actors can compose visibly instead of becoming ten separate frameworks.

5 Event / Wedding Media App

Category: event + media + roles + AI image processing.

Representative apps: Mehmaan, weddings, conferences, school events, sports tournaments, creator galleries.

AndroidiOSWebWorkerServer

EventGraph:
    EventListRoute
    EventDetailRoute
    AlbumRoute
    UploadRoute
    RSVPRoute
    VendorRoute
    GuestManagementRoute

MediaGraph:
    LocalImagePicker
    UploadQueue
    FaceRecognitionService
    AlbumIndexService
    R2StorageNode

RoleGraph:
    HostRole
    GuestRole
    VendorRole
    ManagerRole

Key concerns: role-based navigation, module pricing, upload/indexing, face recognition, vendor/guest workflows, notifications.

Proves: Modular app concerns and role-specific flows can be graph-native.

6 Marketplace / Ecommerce / Inventory

Category: transactions + catalog + inventory + workflows.

Representative apps: Nexergy, Shopify-like stores, B2B ordering, restaurant ordering, warehouse apps.

WebAndroidiOSSpring BootWorker

CatalogGraph:
    ProductListRoute
    ProductDetailRoute
    SearchRoute

CartGraph:
    CartRoute
    CheckoutRoute
    PaymentRoute

OrderGraph:
    CreateOrderService
    InventoryReservationService
    PaymentService
    OrderWorkflow
    FulfillmentQueue

AdminGraph:
    InventoryDashboard
    PricingDashboard
    VendorDashboard

Key concerns: transactional flow, inventory consistency, payment orchestration, async fulfillment, audit trail, admin dashboards.

Proves: Reaktor can model business workflows, not just app UI.

7 SaaS Admin Dashboard

Category: web/backend CRUD + permissions + analytics.

Representative apps: CRM, HR dashboards, internal tools, admin portals, analytics dashboards.

ReactWebSpring BootWorker

AdminShellGraph:
    DashboardRoute
    UserManagementRoute
    RoleManagementRoute
    AuditLogRoute
    SettingsRoute

ServiceGraph:
    UserAdminService
    RoleService
    AuditService
    MetricsService

PolicyGraph:
    RBACPolicy
    AuditPolicy
    TenantIsolationPolicy

Key concerns: RBAC, tenant isolation, audit logs, search/filter/table layouts, exports, analytics, AI query assistant.

Proves: React/Web/Spring systems can adopt graph-native services, policies, actions, and AI context.

8 Collaborative Realtime Editor

Category: multiplayer real-time + CRDT + presence.

Representative apps: docs, whiteboards, design tools, coding rooms, Figma-like tools.

WebReactJS WorkerDurable Objects

DocumentGraph:
    DocumentRoute
    EditorRoute
    PresencePane
    CommentsPane

ActorGraph:
    DocumentRoomActor
    PresenceActor
    CursorActor

SyncGraph:
    CRDTSyncService
    SnapshotService
    ConflictResolver

Key concerns: room identity, WebSockets, CRDT state, presence/cursors, comments, storage snapshots, concurrent editing.

Proves: PartyKit/Durable Object-style rooms can become graph-visible actors.

9 Notification and Campaign System

Category: messaging infrastructure.

Representative apps: push notification service, marketing campaigns, engagement engine, alerting platform.

WorkerSpring BootAndroidiOSWeb

IntakeGraph:
    NotificationRequestService
    CampaignTriggerService
    WebhookReceiver

BusGraph:
    NotificationRequestedQueue
    FanoutQueue
    ReceiptQueue
    DeadLetterQueue

DeliveryGraph:
    AndroidFcmSender
    IosApnsSender
    WebPushSender
    RetryClassifier

ClientGraph:
    NotificationActionRouter
    OpenRouteAction
    MarkReadAction

Key concerns: fanout, retry classification, receipts, invalid endpoint cleanup, campaign scheduling, typed route/action on click.

Proves: Backend messaging concerns can be graphs, not just screens.

10 IoT / Geo / Logistics System

Category: device telemetry + location + routing + real-time map.

Representative apps: fleet tracking, delivery tracking, sensor monitoring, logistics, smart city dashboards.

AndroidiOSWorkerSpring BootWeb Dashboard

DeviceGraph:
    LocationCollectorNode
    SensorCollectorNode
    UploadBatchWork

EdgeGraph:
    TelemetryIngestWorker
    RateLimiter
    GeoPartitionActor

ServerGraph:
    DeviceRegistryService
    TripService
    AlertService
    AnalyticsService

DashboardGraph:
    MapRoute
    VehicleDetailRoute
    AlertRoute

Key concerns: streaming telemetry, location permissions, batching, edge ingestion, geo partitioning, alerting, live dashboard.

Proves: Edge ingestion, real-time dashboards, location, queue/pubsub, and alerts can compose.

11 AI Tutor / Learning Platform

Category: AI app + knowledge graph + adaptive UI.

Representative apps: Manna, course tutor, coding coach, onboarding assistant, study aid.

AndroidiOSWebSpring BootWorkerAI Providers

LearningGraph:
    CourseRoute
    LessonRoute
    QuizRoute
    ReviewRoute
    ProgressRoute

KnowledgeGraph:
    ConceptNode
    PrerequisiteEdge
    MasteryStateRepository

AiGraph:
    TutorAgent
    QuestionGenerator
    FeedbackService
    RetrievalService

WorkGraph:
    SpacedReviewScheduler
    ProgressAggregator

Key concerns: personalized learning state, AI tutor, retrieval, spaced repetition, quiz generation, feedback, analytics, provenance.

Proves: AI works better with structured graph context than raw app code.

12 AI Agent Operations / Workflow Automation

Category: durable workflows + AI tools + humans-in-the-loop.

Representative apps: support automation, sales ops, deployment agent, moderation queue, document processing.

Spring BootWorkerWeb DashboardAI Services

TriggerGraph:
    IncomingTicketWebhook
    FileUploadedEvent
    ScheduledScan

AgentGraph:
    TriageAgent
    SummarizerAgent
    PolicyChecker
    HumanApprovalRoute

WorkflowGraph:
    ExtractDataStep
    ClassifyStep
    ApproveStep
    ExecuteStep
    CompensateStep

ToolGraph:
    EmailTool
    CRMTool
    PaymentTool
    DeploymentTool

Key concerns: tool permissions, human approval, durable state, retries, audit logs, prompt/tool schemas, MCP exposure.

Proves: AI agents become graph-governed workers, not uncontrolled scripts.

13 Edge API Platform

Category: serverless APIs + workers + queues.

Representative apps: API gateway, webhook router, BFF, ingestion layer, SaaS edge platform.

JS WorkerSpring BootD1/R2/KVExternal Services

EdgeGraph:
    AuthMiddlewareNode
    RateLimiterNode
    RouterNode
    CacheNode
    WebhookReceiver

ServiceGraph:
    UserServiceProxy
    BillingServiceProxy
    SearchServiceProxy

QueueGraph:
    WebhookQueue
    RetryQueue
    DeadLetterQueue

StorageGraph:
    D1Node
    R2Node
    KVNode

Key concerns: edge routing, auth, cache, queue buffering, retries, dead letters, worker deployment, service proxying.

Proves: Workers/queues/storage can be modeled as first-class graph modules.

14 Native C++ Media / Compute Pipeline

Category: native high-performance subsystem.

Representative apps: image/video processing, face recognition, game-engine bridge, ML preprocessing, audio pipeline.

AndroidiOSC++KotlinWeb/WASM optional

ClientGraph:
    MediaPickerRoute
    PreviewRoute
    ProcessingRoute

NativeGraph:
    FaceDetectorNativeNode
    ImageCompressorNativeNode
    VideoTranscoderNativeNode

ServiceGraph:
    UploadService
    ModerationService
    MetadataService

CapabilityGraph:
    NativeCompute
    GpuAcceleration
    MemoryBudget

Key concerns: FFI boundary, binary schemas, memory ownership, native acceleration, fallback if native unavailable, latency/memory telemetry.

Proves: C++ can be a first-class provider through contracts and FFI.

15 Brownfield React + Spring Incremental Adoption

Category: migration path.

Representative apps: existing SaaS products, enterprise portals, legacy web apps.

ReactSpring BootWebJVM

BrownfieldGraph:
    ReactRouteProjection
    SpringControllerProjection
    ServiceOperationCatalog
    AuthPolicyProjection
    TelemetryProjection

ReaktorIslandGraph:
    NewFeatureRoute
    NewFeatureService
    NewFeatureRepository

Key concerns: no rewrite, graphify existing routes/services, wrap Spring endpoints, expose React actions, gradually replace one feature.

Proves: Reaktor can be adopted incrementally, not only in greenfield systems.

16 Reaktor Desktop / Developer Tooling App

Category: control plane + live runtime + visual editing.

Representative apps: Reaktor Desktop itself, deployment console, monitoring console, visual editor.

Compose DesktopJVMRemote Debug TargetsWeb optional

AppRunnerGraph:
    RunAppAction
    DeviceTargetSelector
    RuntimeBridge

GraphEditorGraph:
    GraphCanvas
    NodeInspector
    EdgeInspector
    PatchPreview

DevToolsGraph:
    LayoutInspector
    StateWatch
    ServiceTracer
    PerformancePanel

DeploymentGraph:
    PartitionPreview
    DeployAction
    RollbackAction

AiGraph:
    BlueprintCopilot
    GraphQueryTool
    PatchPlannerTool

Key concerns: live graph inspection, component layout inspector, runtime mutation, patch persistence, deployment partitioning, AI assistance, graph event timeline.

Proves: The engine can build its own editor.

Coverage matrix

The examples cover the dominant concerns across roughly 80% of application systems. They should be treated as an architectural acceptance matrix for the kernel.

Concern	Covered by examples
Navigation	1, 2, 3, 4, 5, 6, 7, 11, 15, 16
Auth / RBAC	2, 3, 4, 5, 6, 7, 12, 13, 15
Offline-first data	1, 3, 4, 5, 10, 11
Server APIs	2, 3, 4, 6, 7, 10, 13, 15
Async queues / PubSub	3, 4, 6, 9, 10, 12, 13
Notifications	2, 3, 4, 5, 6, 9, 10
Media	5, 14
Geo / maps	3, 10
Realtime / WebSocket	4, 8, 10
Actors	4, 8, 10
Workflows	6, 9, 12
Payments / transactions	6, 12
Admin dashboards	7, 9, 10, 13, 16
AI / agents	11, 12, 16
DevTools / inspection	16, plus all examples through snapshots/events
Deployment partitioning	4, 6, 8, 9, 10, 13, 16
Polyglot / FFI	14, 15
React integration	7, 8, 15
Cloudflare Workers	4, 8, 9, 10, 13
Spring Boot	3, 4, 6, 7, 10, 12, 15
Brownfield adoption	15

Implementation plan

Highest leverage move: turn the current object graph into a manifest-backed, contract-identified, evented, facet-based graph runtime.

Build next

1. ContractId + SchemaId

Required for polyglot services, FFI, AI, deployment partitioning, TypeScript/C++ clients, and schema evolution.

2. FacetSet

Add typed meaning to Graph, Node, Port, and Edge without subclass explosion.

3. CapabilityProfile

Make platform/runtime availability first-class and strategy-driven.

4. GraphSnapshot

Evolve current graph JSON into a typed runtime snapshot model for tools and AI.

5. GraphEventBus

Emit node/edge/facet/lifecycle changes for DevTools, telemetry, Shadow, and AI diagnosis.

6. GraphCommand v0

Add generic commands: AddNode, RemoveNode, AddPort, ConnectPorts, SetFacet, RemoveFacet.

7. GraphValidator

Core validates IDs, contracts, edges, and facets. Modules validate routes, services, deployment, auth, and bus rules.

8. ModuleRegistry

Modules register facets, capabilities, validators, visitors, renderers, inspectors, codegen, and adapters.

9. Route attachment roles

Replace “first attached node” with PrimaryView, Controller, Guard, Loader, Prefetcher, Analytics, ErrorBoundary.

10. Transport-neutral services

Operation identity must be separate from endpoint and transport.

Golden samples

sample-notes — small CRUD/offline-first app.
sample-mobile-shell — auth, navigation, profile, capability fallback.
sample-social — real-time, offline, actors, notifications, media.
sample-edge-api — Workers, queues, storage, service proxying.
sample-brownfield-react-spring — incremental adoption.
sample-reaktor-desktop-devtools — the engine builds its own editor.

Final design heuristic

Can this be expressed as:
    a contract,
    a facet,
    a capability,
    a visitor,
    an event,
    a snapshot field,
    or a command?

If yes:
    it belongs in a module.

If no:
    either the kernel is missing a primitive,
    or the feature is trying to smuggle a framework into the kernel.

Reaktor is the graph-native composition language for application concerns. Kotlin is the native implementation. C++ and TypeScript are first-class peers. Other languages enter through contracts. Modules provide primitives. The graph combines them. Visitors interpret them. Capabilities adapt them. Tools inspect them. AI modifies them safely.

Do not build 80 frameworks in a trench coat. Build a small kernel, a huge vocabulary, and an ecosystem where every concern can become a node, port, edge, facet, capability, event, snapshot, command, and visitor interpretation.