Reaktor Module Review — Readiness, Graph Integration and Compounding Value

Reaktor architecture assessment · 12 September 2026 · Working-tree evidence, with proposed integration and execution design

Reaktor's greatest opportunity is to make every module contribute a reusable capability and a precise semantic description of that capability. Shared identities, typed contracts, dependency relationships, authorization, and evidence would then let a change in one module improve composition, debugging, deployment, and product learning together.

The framework already has substantial pieces of this system: typed runtime ports, graph-owned actors and routes, reusable services, object persistence, an editable graph document, a supervised tool executor, and a newly extracted headless workspace kernel. It does not yet have one canonical, immutable, revisioned graph model governing all these pieces. Several currently separate graph representations and platform adapters must converge through contracts and projections.

The strongest immediate investments, in the context of the Astra master plan, are:

1. Connect brief, app-owned design, real auth/data behavior, preview and independent export into the first public creation loop.
2. Repair the identity, contract, lifecycle and wiring laws needed by that loop, using a small compatible semantic kernel.
3. Make data growth, asynchronous effects, authority, deployment and recovery work through one reviewable plan and receipt path.
4. Prove Android and iOS capability choices separately; keep unsupported behavior explicit.
5. Use revision-bound telemetry, tests and performance evidence to measure first-app creation and correct later changes.
6. Use BestBuds as an integration and failure-case source; promote combinations that transfer to public apps, and consolidate thin or redundant modules.

Relationship to the Astra master plan

The Astra Reaktor Plan and Roadmap is the governing north star. This review is its source-grounded module assessment and integration design. The companion Module Execution Plan gives five ranked tasks per existing module/build/target unit, plus the supporting Python and delivery systems. It maps each task to the master plan's objectives, prerequisites and acceptance evidence.

The master plan's central test is whether Reaktor wins both the first hour, when an unfamiliar brief becomes a distinctive working application, and the hundredth change, when real behavior, data and design must survive growth. The first version of this review emphasized runtime hardening and operator impact analysis. Those remain valuable, but the updated delivery order places them inside the creation/growth path instead of making a universal kernel rewrite the prerequisite for creating an app.

Decisions refined by the follow-up source and document review

Auth now has a real lightweight artifact. reaktor-auth-core is included in the framework build and contains portable auth/authority models and local authorization logic. reaktor-auth re-exports it and retains the heavier adapters. The follow-up JVM test and dependency-boundary check passed; that result does not qualify every token/provider/native path.

Source intelligence now has its own contract module. A final inventory scan found the newly registered reaktor-code: renderer-independent document, position, diagnostic, completion, hover and definition contracts. UI and tooling re-export it, and the native source pane uses it through the JVM language-server adapter. The review includes this late addition separately, including stale-result/revision and range-law tasks. Its dependency check passed, but jvmTest had no source; adapter tests are not a substitute for contract conformance.

One public CLI is the selected direction. The 12 September workbench decision makes reaktor-cli the public command line and treats the closed reaktor-workbench target as transitional. A proposed open reaktor-workspace receives generic catalog/effect/environment/plan/ledger mechanisms; product recipes, classifications and private sessions stay in the closed contributor. This extraction and shared-host attachment are plans, not completed capabilities.

The semantic kernel and workspace kernel remain distinct. Finite identity/schema/revision/patch laws belong to the pure graph model. Workspace discovery, authorization orchestration, execution and ledger ownership belong to the project service. Neither should absorb product data authority, native runtimes or presentation. The compact kernel-v0 acceptance contract resolves the next implementable slice, including type witnesses/codecs, payload resolution, read-set fencing and redacted traversal.

Service supplies the operation concept; providers supply execution semantics. The updated Service design and Tidemark data layer align unary calls, subscriptions, publication and durable jobs under versioned operation contracts while retaining distinct implementations. Enums and illustrative interfaces in these proposals do not establish working transport, stream or durability support today.

The ecosystem matrix is a target-state register. Its broad coverage must not become a demand to finish every module and pane before the first release. The graph substrate's independent review correctly identifies that capacity risk. This review keeps complete coverage; the execution plan pulls a small set of dependencies into one weekly integrated journey. Proposed task horizons distinguish December contributions, later year-one work and conditional/archived work.

The master plan remains authoritative on calendar and scope. This document does not claim that past proposed September milestones have completed, assign developers without their decision, or turn all modules into simultaneous release blockers.

1. Scope, evidence, and rating method

What “every module” covers

This review inventories 37 Reaktor module/build directories: 34 modules included by the root settings, the dependeasy included build, the separate open reaktor-cli, and the excluded legacy reaktor-react. It also covers five BestBuds library/build slices, all 27 target directories, the major functional domains inside the shared product and workbench, and supporting matching, data-pipeline, design, and delivery systems.

The open/closed classification follows repository ownership in the project guides: reaktor/ is the open framework; bestbuds/ holds the closed products and workspace backend. This is a source-ownership classification, not a verification of public package availability or the license of every vendored dependency.

Inspected sibling repositories: reaktor/ and bestbuds/. Source references below are repository-relative; closed-source paths document the inspection without publishing their contents. Read-only consumer searches also covered Manna, GymBuddy, shibasis.dev, Nexergy, and bridge. BestBuds HEAD was bca6d240 (9 September); Reaktor HEAD was 57e83856 (27 August). Both trees had extensive uncommitted work. The assessment includes that work, especially the graph-runtime/kernel extraction. It is a working-tree assessment, not a review of only those commits or a released version. Other work was proceeding concurrently, so this scan is not an atomic snapshot.

Evidence includes build registration and dependencies, source APIs and implementations, explicit unsupported paths, source consumers, tests, and focused checks run for this review. Generated exports, generated design boards, vendored native libraries, and caches are not counted as independent authored modules. Thin deployable wrappers are evaluated with their owning Kotlin implementation. Older architecture audits supplied leads; current code was used to resolve important discrepancies.

The retained local audit archive contains inventory.json, which records paths, direct build dependencies, source/test inventories, literal import matches, and cached test metadata. source-fingerprints.json records file hashes at inventory time. Import counts are navigation aids: they miss dynamic use and some package re-exports, and imports from dev.shibasis.reaktor.graph cannot distinguish the runtime artifact from its UI re-export. They are not adoption or coverage percentages. The initial inventory covered 35 Reaktor directories; the follow-up adds the newly registered reaktor-auth-core and reaktor-code, bringing the reviewed module/build/target total to 69. Initial file counts remain dated inventory evidence, not a claim that concurrent work stopped. Saved logs named in the appendix are local audit evidence, not downloadable public artifacts.

How to read the ratings

No module receives level 4: this investigation did not establish fleet-wide reliability, crash-free usage, public compatibility commitments, deployment parity, traffic, or external adoption. Scores are ordinal engineering judgments, not a mathematical measure of quality. A high usage score can coexist with low stability. A pure algorithm can be high quality while its native adapters remain provisional. Platform-specific limits are called out in the entries.

“Impact” describes the present architectural contribution and the potential improvement if the proposed work succeeds. Acceptance gates and numerical targets are proposals, not measured results. Module-level source inspections are broad; this is not a line-by-line security audit of every source file.

Important corrections to older descriptions

2. What the graph is today, and what it should become

Existing graph surfaces

The correct convergence is a common semantic contract with adapters for these surfaces. It should preserve their useful differences. A product user, a service definition, a JVM activation, a database row, and an agent proposal must not become interchangeable just because each is representable as a vertex.

Proposed typed multilayer model

Use a directed, attributed, temporal multigraph with typed vertices, typed relations, and explicit layer membership. A multigraph permits multiple differently meaningful edges between the same endpoints. Heterogeneity supplies different entity and relation schemas. Multiplex views expose different relationship families over shared entity identities; the broader multilayer model also admits entities present in only some layers and typed connections between layers. This distinction follows the terminology organized in Kivelä et al., Multilayer Networks.

In notation, let V be canonical entities, L be semantic layers, P ⊆ V × L be the entity-layer incidences that actually exist, and E be identified, typed edges between incidences. Vertex and edge type functions select versioned schemas. A view chooses a bounded authorized subset; it does not create a second identity system. This formulation is a proposed Reaktor design, not an existing implementation or a requirement to use tensor storage.

Do not equate layers with modules: auth contributes to trust, runtime, data, delivery, and assurance. Do not create a separate complete graph copy for each environment, user, or timestamp. Environment, workspace, principal, time, and revision are explicit context dimensions; runtime activations are distinct entities linked to the definitions they instantiate.

Identity, contracts, and evidence are the enabling work

Identity. Introduce persistent definition IDs with content revisions; separate activation IDs and epochs; preserve provider-native resource IDs through namespaced references. A display label, graph path, generated UUID, or array position is insufficient as universal identity. Renames and layout changes must not create new semantic entities. ServiceDefinition → ACTIVATES → ServiceActivation → RUNS_ON → Pod is a chain of distinct entities, not four aliases for one node.

Contract identity. A port needs a namespaced contract ID and schema version, request/response/message schema, direction, cardinality, effect requirements, and declared transport semantics. Compatibility must distinguish a local callable from an asynchronous remote request or stream. Remote versions need explicit ordering, retry, idempotency, cancellation, timeout, and delivery guarantees. Displayed Kotlin class names and string equality cannot prove these properties.

Relations. Give edges stable identity, an allowed source/target schema, layer, ownership, provenance, validity interval, and confidence/assurance where relevant. Preserve dependency direction separately from data flow and request flow. A provider may be a dependency target while its emitted data flows toward the consumer. Do not reverse one edge ad hoc and then use it for blast-radius analysis.

Evidence. Evolve Fact into orthogonal origin, assurance, condition, freshness, scope, and provenance fields. A recent probe can observe a failure; an imported value can be unaudited; a source declaration can be accurate without proving deployment. A single enum ordered by ordinal cannot express these distinctions. A receipt must name the definition revision, activation/environment, actor, plan fingerprint, time, result, and relevant artifact/evidence digests.

Validation. Register executable shape checks for relation endpoints, port compatibility, ownership, tenant scope, cardinality, and revision consistency. Pure validators return typed findings. SHACL is useful prior art for constraints and validation reports; adopting RDF or a particular database is not required by this proposal.

Integration contract for every module

Every module should offer a graph-agnostic kernel plus an optional graph adapter. An illustrative contribution descriptor—not a shipped API—would contain:

ModuleContribution(
    identity = moduleIdAndRevision,
    contracts = exportedAndRequiredContracts,
    entitySchemas = ownedEntityTypes,
    relationSchemas = ownedRelations,
    projection = boundedReadAdapter,
    operations = declaredCommandsAndEffects,
    validators = pureContractChecks,
    observations = evidenceProducers,
    conformance = supportedTargetEvidence,
)

The library caller can still invoke SecretStore, NotificationsClient, Service, or a matching function directly. Installation supplies inspectable ownership, typed wiring, queries, and optional execution mediation. Being able to call a plain API without importing Graph is distinct from actually shipping a dependency-light artifact; the new reaktor-auth-core now provides the smaller artifact while the umbrella auth package retains its adapters.

Graph projections should contribute a new query, invariant, reusable operation, measurable optimization, or lifecycle guarantee. A node that only repeats its module's name earns little value. Keep scalar arithmetic, tight loops, native algorithms, large blobs, and every individual telemetry event out of the always-mounted canvas. Summaries and bounded on-demand records are sufficient.

Execution and scale rules

Use one path for human and agent effects: query/snapshot → proposal → typed patch or command → validation → fingerprinted plan → authority and policy → execution → reconciliation → receipt. The existing tooling/kernel path is a strong seed; it is not yet a universal mutation protocol for all modules.

Keep a small immutable definition core and separately owned observation/event stores. Use indexed adjacency, incremental projections, pagination, cursor-based subscriptions, explicit expired cursors, and bounded query budgets. Large media belongs in R2; relational records in their owning database; detailed spans in an observability backend. The graph holds typed references and selected summaries. A graph query that reaches an external source is a declared read effect with a freshness result, not a hidden side effect of traversing an edge.

Cross-store reads cannot promise a global transactional snapshot without machinery that does not exist today. Return the revision/watermark for each source, label partial results, and allow callers to request a bounded consistency level. Reified run/event entities can represent many-input/many-output actions without forcing an early hypergraph storage implementation.

3. Open Reaktor modules

reaktor-core

Five priority tasks and Astra traceability.

Purpose and current implementation. Platform adapters, feature slots, permissions/storage hooks, concurrency capabilities, utility collections, and Fact/TruthClass form the lowest reusable substrate.

Quality Q2 · Stability S2. Small reusable primitives and current JVM checks are positives. Feature remains global bootstrap state. ConcurrencyCapabilityImpl creates an unparented SupervisorJob, replacing the parent context job; explicit close is therefore more reliable than assuming inherited cancellation. Truth categories currently collapse several dimensions.

Usage U3. BestBuds and GymBuddy import the core directly; most framework modules depend on it indirectly.

Vision and impact. Make scope ownership and evidence semantics reliable once, improving every higher layer.

Graph integration and combinations. Contribute scope/capability descriptors and evidence envelopes, not a node per utility. Combine runtime ownership with telemetry and kernel receipts so cancellation and disposal are observable. Put minimal reusable identity/evidence values here only when they truly have no graph-specific dependency.

Acceptance gate. Prove parent cancellation/disposal laws and distinguish imported, stale, failed, and live evidence without deriving health from origin alone.

Evidence: reaktor/reaktor-core/src/commonMain/kotlin/dev/shibasis/reaktor/core/framework/Feature.kt; reaktor/reaktor-core/src/commonMain/kotlin/dev/shibasis/reaktor/core/capabilities/ConcurrencyCapability.kt; reaktor/reaktor-core/src/commonMain/kotlin/dev/shibasis/reaktor/core/truth/Fact.kt.

reaktor-graph-port

Five priority tasks and Astra traceability.

Purpose and current implementation. Provides mutable typed provider/consumer wiring and graph traversal. Its authored TypeScript package also contains graph and hierarchical scope renderers used by web consumers.

Quality Q2 · Stability S2. Exact compatibility checks and explicit unwired invocation errors are useful. Type contains both a name and optional KClass: identical displayed names can still compare unequal. Multi-port connect can apply earlier edges before returning failure. TypeScript rendering in this low-level artifact complicates the intended UI boundary.

Usage U3. BestBuds, GymBuddy, and Manna; Manna uses the TypeScript scope model, not merely a dependency declaration.

Vision and impact. Become the contract boundary that makes independently developed modules compose predictably.

Graph integration and combinations. Version contract IDs; separate dependency/data/control relations; validate an entire wiring patch before commit. Pair compiler-generated schemas with FFI compatibility checks. Eventually expose web presentation through a suitable renderer package/re-export while preserving compatibility.

Acceptance gate. Equivalent Kotlin/JS/C++ schema identities must agree; an invalid batch must leave no partial connections; relation direction must survive serialization and rendering.

Evidence: reaktor/reaktor-graph-port/src/commonMain/kotlin/dev/shibasis/reaktor/portgraph/port/Port.kt; reaktor/reaktor-graph-port/src/commonMain/kotlin/dev/shibasis/reaktor/portgraph/graph/connect.kt; reaktor/reaktor-graph-port/ts/src/scope/types.ts.

reaktor-graph-runtime

Five priority tasks and Astra traceability.

Purpose and current implementation. The newly extracted headless owner of Graph/Node, actors, navigation, DI, lifecycle, visitors, repository/service nodes, and runtime serialization.

Quality Q2 · Stability S2. Boundary verification passed and the implementation has existing consumer tests. The new artifact has no dedicated test tree yet. Runtime objects remain mutable. Lifecycle transition callbacks can run for rejected transitions. Actor storage names are derived from actor keys without graph scope, and ask timeout begins after mailbox enqueue.

Usage U3. BestBuds kernel now depends directly on it; existing graph consumers obtain it through re-exports. These are shared source consumers, not proof of independent headless deployments.

Vision and impact. Supply a reliable execution model that can later realize immutable definitions on multiple targets.

Graph integration and combinations. Link DefinitionRevision to Activation/Epoch, ActorAddress, Mailbox, RouteTransition, and Invocation. Combine DB checkpoints, work scheduling, and telemetry; explicitly distinguish in-memory mailbox delivery from durable workflow execution.

Acceptance gate. Fix and test lifecycle/cancellation/ask-budget laws, scope actor persistence, and prove headless ownership before durable replay or remote placement.

Evidence: reaktor/reaktor-graph-runtime/build.gradle.kts; reaktor/reaktor-graph-runtime/src/commonMain/kotlin/dev/shibasis/reaktor/graph/core/Graph.kt; reaktor/reaktor-graph-runtime/src/commonMain/kotlin/dev/shibasis/reaktor/graph/core/node/ActorNode.kt; reaktor/reaktor-graph-runtime/src/commonMain/kotlin/dev/shibasis/reaktor/graph/capabilities/LifecycleCapability.kt.

reaktor-graph

Five priority tasks and Astra traceability.

Purpose and current implementation. Re-exports the runtime and supplies Compose nodes/rendering, route host adapters, and browser integration.

Quality Q3 · Stability S2. Useful product-backed composition with current graph JVM checks. The runtime/UI split is recent; API/import compatibility is being preserved but multi-platform release parity is unproven.

Usage U3. BestBuds and GymBuddy use graph routing; Manna and shibasis.dev also have source or TypeScript consumers.

Vision and impact. Make screen navigation and UI binding projections of the same behavior model used by headless hosts.

Graph integration and combinations. Add typed Screen, Route, Binding, and RenderInstance relationships to runtime identity. A selected UI action should lead to its handler, data writes, deployment, and observations. Keep executable state in runtime; keep host-specific rendering here.

Acceptance gate. A route retains semantic identity across source, Compose, and browser navigation, including back/forward and nested graphs, with target-specific conformance evidence.

Evidence: reaktor/reaktor-graph/build.gradle.kts; reaktor/reaktor-graph/src/commonMain/kotlin/dev/shibasis/reaktor/graph/ui/ComposeRenderer.kt; reaktor/reaktor-graph/ts/index.ts.

reaktor-io

Five priority tasks and Astra traceability.

Purpose and current implementation. HTTP/WebSocket transports, reconnection, route patterns, files, compression, serialization, and Android share-sheet support.

Quality Q2 · Stability S2. Useful platform implementation, but binary ObjectSerializer methods are TODO. A working HTTP/file path does not qualify all serialization or platform variants.

Usage U3. BestBuds and GymBuddy directly consume IO; services and storage extend its reach.

Vision and impact. Expose transport and resource behavior consistently so failures can be traced across local and remote calls.

Graph integration and combinations. Project Endpoint, Connection, Transfer, FileRef, RetryPolicy and their TRANSPORTS/READS/WRITES relations. Combine service contracts, auth, work retries, and telemetry using one invocation ID. Keep payload bodies outside routine graph snapshots.

Acceptance gate. Cancellation, reconnection, timeout, file ownership, and retry semantics must be declared and tested per adapter; unsupported serialization must never advertise capability.

Evidence: reaktor/reaktor-io/src/commonMain/kotlin/dev.shibasis.reaktor.io/network/websocket/WebSocket.kt; reaktor/reaktor-io/src/commonMain/kotlin/dev.shibasis.reaktor.io/serialization/ObjectSerializer.kt; reaktor/reaktor-io/src/commonMain/kotlin/dev.shibasis.reaktor.io/adapters/ShareAdapter.kt.

reaktor-service

Five priority tasks and Astra traceability.

Purpose and current implementation. Graph-agnostic typed Request/Response services and HTTP method handlers, interception, transport metadata, Spring routing, and JS handler integration.

Quality Q3 · Stability S3. A cohesive extraction with current integration tests. Transport neutrality is useful, but local invocation and remote delivery still have different failure and timing semantics.

Usage U2. Widely used within BestBuds services and Workers. Several framework integrations consume it; external product deployment counts are unknown.

Vision and impact. Make a service contract the shared unit for client generation, authorization, deployment, testing, and diagnostics.

Graph integration and combinations. Project ServiceContract, Operation, RequestSchema, ResponseSchema and Endpoint bindings. Join operations to port contracts, database queries, policy requirements, and spans. Generate contract tests and impact queries from these declarations.

Acceptance gate. The same declared operation must be traceable from local invocation through HTTP/Worker implementations, with preserved error, auth, timeout, and idempotency semantics.

Evidence: reaktor/reaktor-service/src/commonMain/kotlin/dev/shibasis/reaktor/service/Service.kt; reaktor/reaktor-service/src/commonMain/kotlin/dev/shibasis/reaktor/service/ServiceInterceptor.kt; reaktor/reaktor-service/src/commonTest/kotlin/dev/shibasis/reaktor/service/ServiceIntegrationTest.kt.

reaktor-db

The Data layer reading map owns this module’s detailed design. Current storage and implementation gates supersede old data inventories and fixed plans; Queues and Workflows defines the cloud execution profile.

Five priority tasks and Astra traceability.

Purpose and current implementation. Observable object stores/state, caching and retention, SQLite adapters, whole-database snapshot transfer, JVM CRUD integration, GraphQL access, and tenant-bound graph queries.

Quality Q3 · Stability S2. Current object/tenant-policy tests support the local primitives. Snapshot transfer is not conflict-resolving offline synchronization. The Cypher tenant guard is regex based and is not a complete authorization proof for arbitrary queries.

Usage U3. BestBuds and GymBuddy use local persistence. Server and graph-runtime consumers create substantial indirect dependence.

Vision and impact. Make data ownership, derivation, retention, and invalidation first-class across storage engines.

Graph integration and combinations. Project Store, SchemaRevision, QueryContract, MaterializedView, CacheEntrySummary, Migration and Checkpoint. Join each service/actor to its reads and writes. Combine schema changes with dependent service tests and product outcome analysis; use named bounded query adapters for external graph data.

Acceptance gate. Demonstrate stale-cache invalidation and schema-change impact on a real feature; enforce tenant scope at the owning backend and bound every external query.

Evidence: reaktor/reaktor-db/src/commonMain/kotlin/dev.shibasis.reaktor.db/core/ObjectStore.kt; reaktor/reaktor-db/src/commonMain/kotlin/dev.shibasis.reaktor.db/core/ObjectState.kt; reaktor/reaktor-db/src/commonMain/kotlin/dev.shibasis.reaktor.db/adapters/SyncAdapter.kt; reaktor/reaktor-db/src/commonMain/kotlin/dev.shibasis.reaktor.db/graph/GraphDbPolicy.kt.

reaktor-auth-core

Five priority tasks and Astra traceability.

Purpose and current implementation. The newly extracted portable authorization kernel contains auth requirements, contexts, local decisions and authority-resolution models. The umbrella auth module re-exports it; the closed workspace kernel now depends on it directly. Its Gradle boundary check rejects graph/runtime, UI, database and Spring dependencies.

Quality Q3 · Stability S2. A small cohesive boundary over existing authorization logic. The follow-up freshly executed two JVM tenant-superadmin cases and the dependency-boundary check successfully. This narrow evidence does not establish cross-platform policy parity, provider-token validation or resource-specific access enforcement.

Usage U2. Integrated through the umbrella auth artifact and the BestBuds workspace kernel. Independent published-package adoption has not been established.

Vision and impact. Make public apps, agents and headless tools share authorization meaning without importing presentation or backend hosting. This materially improves package closure and allows consistent policy fixtures across hosts.

Graph integration and combinations. Keep the kernel graph-agnostic. The optional auth projection publishes Requirement, Decision, PrincipalRef, GrantRef and validity metadata, joining Service operations, sensitive data reads and tooling plans. Token-bearing authority-resolution values must be converted to safe metadata before serialization into graph views. Combine auth-core + Service + tooling + public CLI to make the same operation understandable and enforceable in generated apps and operator tools.

Acceptance gate. A clean public consumer runs authorization without umbrella dependencies; nested alternatives cannot bypass enclosing context constraints; verified authority provenance, expiry and resource enforcement remain explicit at execution boundaries.

Evidence: reaktor/reaktor-auth-core/build.gradle.kts; reaktor/reaktor-auth-core/src/commonMain/kotlin/dev/shibasis/reaktor/auth/kernel/AuthKernel.kt; reaktor/reaktor-auth-core/src/commonMain/kotlin/dev/shibasis/reaktor/auth/kernel/Authority.kt; reaktor/reaktor-auth-core/src/commonTest/kotlin/dev/shibasis/reaktor/auth/kernel/TenantSuperadminTest.kt; bestbuds/modules/kernel/build.gradle.kts.

reaktor-auth

Five priority tasks and Astra traceability.

Purpose and current implementation. The re-exported reaktor-auth-core authorization kernel plus login adapters, JWT/session/service-account support, database repositories, transport interceptors, and substantial AuthNode/AuthRuntimeGraph projections.

Quality Q3 · Stability S2. One of the best examples of the dual-surface rule, with many targeted tests. The umbrella artifact still includes graph/UI/backend dependencies; callers needing only authorization can now use reaktor-auth-core. Generic port connect does not automatically call secured-port authorization helpers, so a secured type alone does not enforce access. Platform support is uneven.

Usage U3. BestBuds uses auth throughout; Manna and CompanyOS have authored TypeScript auth consumers. Current external login success was not exercised.

Vision and impact. Make authority visible, scoped, and enforceable along the same paths humans and agents execute.

Graph integration and combinations. Model Principal, Membership, Session, Grant, Requirement, Decision, and AuditReceipt. Connect effects and sensitive reads to requirements. Join secrets, services, data ownership, and kernel planning; show where enforcement actually occurs, not only where policy is declared.

Acceptance gate. Revocation and environment changes must invalidate execution authority; deny unauthorized reads and calls at every boundary, including generic wiring paths and remote adapters.

Evidence: reaktor/reaktor-auth-core/src/commonMain/kotlin/dev/shibasis/reaktor/auth/kernel/AuthKernel.kt; reaktor/reaktor-auth/src/commonMain/kotlin/dev/shibasis/reaktor/auth/graph/AuthNode.kt; reaktor/reaktor-auth/src/commonMain/kotlin/dev/shibasis/reaktor/auth/graph/SecuredPort.kt; reaktor/reaktor-auth/src/jvmMain/kotlin/dev/shibasis/reaktor/auth/runtime/AuthRuntimeGraph.kt.

reaktor-secrets

Five priority tasks and Astra traceability.

Purpose and current implementation. Versioned SecretRef/SecretStore APIs, in-memory support, and JVM/JS Google Secret Manager adapters; Cloudflare binding support lives in the Cloudflare module.

Quality Q2 · Stability S2. Clear separation between references and values, explicit unsupported writes, and a test surface. Live provider behavior, rotation, and operational policy were not verified.

Usage U2. The BestBuds server and Cloudflare framework adapter consume it; no broader authored product adoption found.

Vision and impact. Enable explainable credential dependencies and rotation impact without copying secret values into the graph.

Graph integration and combinations. Project only SecretRef, SecretVersion metadata, ConsumerBinding, AccessRequirement, and rotation receipts. Combine auth with deployment and query connections to find exactly which services require restart or revalidation after rotation.

Acceptance gate. Snapshots and errors must never serialize SecretValue payloads; changing a version must identify affected consumers and invalidate stale plans.

Evidence: reaktor/reaktor-secrets/src/commonMain/kotlin/dev/shibasis/reaktor/secrets/Secrets.kt; reaktor/reaktor-secrets/src/jvmMain/kotlin/dev/shibasis/reaktor/secrets/JvmGcpSecretManagerStore.kt; reaktor/reaktor-secrets/src/commonTest/kotlin/dev/shibasis/reaktor/secrets/SecretStoreTest.kt.

reaktor-security

Five priority tasks and Astra traceability.

Purpose and current implementation. Typed secure messaging/device/conversation contracts and a substantive C++ MLS++ engine/C ABI, with native test files.

Quality Q1 · Stability S1. Native mechanisms exist, but platform secret-box methods throw TODO and durable MLS state serialization is explicitly unfinished. This is not a product-ready end-to-end encryption stack.

Usage U0. No active import in the inspected product sources. Inclusion in Gradle is not usage.

Vision and impact. Eventually provide recoverable, auditable end-to-end messaging security as a composable capability.

Graph integration and combinations. Project DeviceIdentity, MembershipEpoch, KeyPackageRef, EncryptedEnvelope metadata, Revocation, and RecoveryCheck. Combine chat membership, notification delivery, storage retention, and auth identity. Do not expose keys or plaintext; resolve its separate AuthContext model deliberately.

Acceptance gate. Native/mobile interop, secure storage, crash recovery, membership changes, and key revocation must pass before product integration. Resolve the conflict between server-side plaintext moderation and encrypted content explicitly.

Evidence: reaktor/reaktor-security/src/commonMain/kotlin/dev/shibasis/reaktor/security/ReaktorSecurity.kt; reaktor/reaktor-security/src/commonMain/kotlin/dev/shibasis/reaktor/security/Snapshot.kt; reaktor/reaktor-security/src/androidMain/kotlin/dev/shibasis/reaktor/security/AndroidPlatformSecretBox.kt; reaktor/reaktor-security/cpp/rsec-mls-core/src/MlsEngine.cpp.

reaktor-cloudflare

Five priority tasks and Astra traceability.

Purpose and current implementation. Kotlin/JS adapters for Workers, Hono routing, bindings, R2, D1, Postgres, KV, Durable Objects/PartyServer, AI/vector services, ClickHouse, graph gateway, JWT verification, and service credentials.

Quality Q2 · Stability S2. Broad working substrate heavily integrated into the product fleet. No module-local authored test suite was found; much qualification lives in product JS/integration tests. Presence of a provider binding is not observed provider health.

Usage U2. Many BestBuds Worker implementations import it. The full deployed fleet and all provider adapters were not exercised.

Vision and impact. Make edge placement and bindings part of a typed system model rather than opaque deployment configuration.

Graph integration and combinations. Project WorkerDefinition/Deployment, Binding, DurableObjectClass/InstanceSummary, R2Bucket, D1Database and named endpoint capabilities. Join typed service operations to deployment and data planes; one binding change should identify affected handlers and required checks.

Acceptance gate. Prove environment-scoped bindings, credential audiences, DO lifecycle semantics, and a full request-to-storage receipt on one real service before extending the catalog.

Evidence: reaktor/reaktor-cloudflare/src/jsMain/kotlin/dev/shibasis/reaktor/cloudflare/Bindings.kt; reaktor/reaktor-cloudflare/src/jsMain/kotlin/dev/shibasis/reaktor/cloudflare/PartyServer.kt; reaktor/reaktor-cloudflare/src/jsMain/kotlin/dev/shibasis/reaktor/cloudflare/Graph.kt; reaktor/reaktor-cloudflare/src/jsMain/kotlin/dev/shibasis/reaktor/cloudflare/WorkerJwtVerifier.kt.

reaktor-google

Five priority tasks and Astra traceability.

Purpose and current implementation. Common Pub/Sub contracts, JVM/JS publish/pull/acknowledge adapters, service-account token support, and a JVM Sheets interactor.

Quality Q2 · Stability S2. Concrete server/JS integration; Android and Darwin Pub/Sub report unsupported. No module-local tests found. Do not advertise four-platform messaging parity.

Usage U2. BestBuds Pub/Sub/notification/server paths are the observed consumers.

Vision and impact. Bridge edge and server workflows with inspectable message and subscription semantics.

Graph integration and combinations. Add Topic, Subscription, DeliveryAttempt, Ack and DeadLetter references; join publication to the originating command and receiving actor/run. Pair Cloudflare, work, and telemetry to trace asynchronous paths without assuming global ordering or exactly-once delivery.

Acceptance gate. Test duplicate deliveries, retry/ack behavior, credentials, and correlation across JVM and JS; keep mobile capability unsupported until implemented.

Evidence: reaktor/reaktor-google/src/commonMain/kotlin/dev/shibasis/reaktor/google/PubSub.kt; reaktor/reaktor-google/src/jvmMain/kotlin/dev/shibasis/reaktor/google/JvmPubSubAdapter.kt; reaktor/reaktor-google/src/jsMain/kotlin/dev/shibasis/reaktor/google/WebPubSubAdapter.kt; reaktor/reaktor-google/src/androidMain/kotlin/dev/shibasis/reaktor/google/AndroidPubSubAdapter.kt.

reaktor-work

Five priority tasks and Astra traceability. The Work architecture selects direct platform profiles; its authenticated delivery roadmap owns removal, source audit and acceptance gates.

Purpose and current implementation. The legacy Meeseeks facade exposes one-time/periodic scheduling, cancellation and status through platform contexts. The selected replacement removes that dependency; WorkStore owns durable intent, WorkRuntime owns bounded attempts and WorkScheduler reconciles direct platform opportunities. These replacement contracts are proposed.

Quality Q1 · Stability S2. Scheduler integration is more complete than bundled business workers. For example SyncWorker logs completion and returns success without synchronizing data. No module-local tests found. The consumer JVM suite ignores its ten scheduling/status cases; its two active cases only construct the manager and payloads, so they do not verify scheduler initialization, serialization or business effects.

Usage U2. BestBuds initializes platform task managers. Initialization alone does not establish that every named worker performs useful work.

Vision and impact. Turn background intentions into recoverable, observable workflows with explicit idempotency and outcomes.

Graph integration and combinations. Own definitions, typed ports, scope and capabilities in headless graph-runtime; project persistent operation, schedule, attempt, fence, checkpoint and receipt without making every row an active node. Combine the authoritative outbox, media/IO and notification effects with direct WorkManager, BGTaskScheduler, browser hosts, Cloudflare Workflows/Queues/PubSub and Spring Quartz/queues/PubSub.

Acceptance gate. Remove vendor APIs and retire/import legacy state with one drainer owner. A killed/restarted upload or sync must resume or reconcile correctly; duplicate delivery and stale attempts must preserve one logical effect. Qualify native execution, browser storage/event lifetime and provider handoff separately.

Evidence: reaktor/reaktor-work/src/commonMain/kotlin/dev/shibasis/reaktor/work/TaskManager.kt; reaktor/reaktor-work/src/androidMain/kotlin/dev/shibasis/reaktor/work/AndroidTaskManager.kt; reaktor/reaktor-work/src/commonMain/kotlin/dev/shibasis/reaktor/work/workers/SyncWorker.kt.

reaktor-notification

Five priority tasks and Astra traceability.

Purpose and current implementation. Rich notification payload/category/action/scheduling/capability models, in-memory/dev harnesses, Android/iOS implementations, server records, a dispatch coordinator, and an optional NotificationsNode.

Quality Q3 · Stability S2. Much more substantial than its old brainstorming label. Current contract tests passed; native OS delivery, token rotation, and background constraints remain target-specific.

Usage U3. BestBuds and GymBuddy consume the module directly.

Vision and impact. Make notification delivery an observable product workflow rather than a fire-and-forget side effect.

Graph integration and combinations. Project Intent, RecipientEndpointRef, Consent, Category, DeliveryAttempt, ProviderReceipt, and RouteAction. Join chat/campaign/work triggers to auth and navigation. An accepted push is distinct from device delivery, presentation, and user engagement.

Acceptance gate. Track one intent through suppression, scheduling, retries, provider acceptance and action routing; distinguish missing permission from delivery failure and avoid duplicate presentation.

Evidence: reaktor/reaktor-notification/src/commonMain/kotlin/dev/shibasis/reaktor/notification/NotificationGraph.kt; reaktor/reaktor-notification/src/commonMain/kotlin/dev/shibasis/reaktor/notification/NotificationPayloads.kt; reaktor/reaktor-notification/src/jvmTest/kotlin/dev/shibasis/reaktor/notification/NotificationContractsTest.kt.

reaktor-location

Five priority tasks and Astra traceability.

Purpose and current implementation. Android fused-location and Darwin CoreLocation reads, a coordinate model, and a skeletal map interface.

Quality Q2 · Stability S1. Real native integrations and permission handling, but no local tests and a minimal value shape without time/accuracy/source metadata. Cancellation and repeated callbacks need target verification.

Usage U2. BestBuds platform setup and matching/analytics-related code consume it.

Vision and impact. Provide reliable, consent-aware geographic context without coupling product logic to location APIs.

Graph integration and combinations. Add LocationObservation with precision, observed time, consent scope and validity. Join matching, nearby events, and analytics through coarsened derived values; raw coordinates should not enter default graph views.

Acceptance gate. Expired or denied readings must remain distinguishable from zero coordinates; show that coarse location improves a real feature without requiring fine tracking.

Evidence: reaktor/reaktor-location/src/commonMain/kotlin/dev/shibasis/reaktor/location/LocationAdapter.kt; reaktor/reaktor-location/src/androidMain/kotlin/dev/shibasis/reaktor/location/AndroidLocationAdapter.kt; reaktor/reaktor-location/src/iosMain/kotlin/dev/shibasis/reaktor/location/DarwinLocationAdapter.kt.

reaktor-sensors

Five priority tasks and Astra traceability.

Purpose and current implementation. A deliberately narrow step-counter API with availability/permission state, Android since-boot baseline math, and Darwin CMPedometer support.

Quality Q3 · Stability S2. Good separation of pure arithmetic from platform adapters; current Android unit checks passed. No browser/JVM pedometer is claimed. Device accuracy and lifecycle still need device evidence.

Usage U2. GymBuddy is the substantive consumer, even though BestBuds does not import it.

Vision and impact. Prove that small device capabilities can contribute typed observations with reusable source semantics.

Graph integration and combinations. Project SensorCapability, DailyBaseline and StepObservation; compose with health-store reconciliation, persistence, and permissions. Preserve reboot/date/source context rather than storing an unexplained count.

Acceptance gate. Validate reboot, day rollover, permission denial, unsupported devices, and source replacement without double counting; test the real adapters separately from arithmetic.

Evidence: reaktor/reaktor-sensors/src/commonMain/kotlin/dev/shibasis/reaktor/sensors/StepCounter.kt; reaktor/reaktor-sensors/src/androidMain/kotlin/dev/shibasis/reaktor/sensors/AndroidStepCounter.kt; reaktor/reaktor-sensors/src/commonTest/kotlin/dev/shibasis/reaktor/sensors/StepMathTest.kt.

reaktor-health

Five priority tasks and Astra traceability.

Purpose and current implementation. Health Connect/HealthKit adapters for steps and workout sessions, permission-specific capability queries, and StepMerge reconciliation with phone sensor data.

Quality Q3 · Stability S2. Cohesive narrow contract and passing Android unit checks. The zero-value fallback in the merge is a chosen heuristic, not proof that a zero means unsynced. Store/platform privacy behavior differs.

Usage U2. GymBuddy consumes the health APIs. A framework-wide usage score should include it.

Vision and impact. Connect user-owned health observations and sessions to applications while preserving consent and provenance.

Graph integration and combinations. Project HealthStore, PermissionGrant, Session and time-bounded aggregate observations. Combine sensors, local DB, notifications and work; represent merge precedence and source ambiguity as evidence.

Acceptance gate. Show no double counting, correct date boundaries, partial permission handling, and idempotent session writes. Graph access must never imply access to the underlying health records.

Evidence: reaktor/reaktor-health/src/commonMain/kotlin/dev/shibasis/reaktor/health/Health.kt; reaktor/reaktor-health/src/androidMain/kotlin/dev/shibasis/reaktor/health/AndroidHealthConnect.kt; reaktor/reaktor-health/src/iosMain/kotlin/dev/shibasis/reaktor/health/DarwinHealthKit.kt; reaktor/reaktor-health/src/commonTest/kotlin/dev/shibasis/reaktor/health/StepMergeTest.kt.

reaktor-media

Five priority tasks and Astra traceability.

Purpose and current implementation. Camera/gallery selection, image loading/cache, upload/service helpers and platform adapters. Speech recognition/synthesis classes are presently empty adapter shells.

Quality Q2 · Stability S2. Useful camera/gallery paths are mixed with incomplete capabilities; no module-local tests found. Plain MediaUploader does not itself establish the product auth policy; authenticated callers need the proper client/interceptor.

Usage U2. BestBuds chat, profile, camera/gallery and design surfaces consume it.

Vision and impact. Make media acquisition, transformation, moderation and delivery one traceable pipeline.

Graph integration and combinations. Project MediaAssetRef, Capture/Transform/Upload tasks, ContentType, CachePolicy and ModerationDecision. Combine R2, services, durable work and notifications. Only bounded metadata and lineage should enter the graph; bytes remain in storage.

Acceptance gate. One capture/upload journey must survive permission denial, cancellation, offline retry and moderation failure with correct ownership and no orphaned public asset.

Evidence: reaktor/reaktor-media/src/commonMain/kotlin/dev/shibasis/reaktor/media/gallery/GalleryAdapter.kt; reaktor/reaktor-media/src/commonMain/kotlin/dev/shibasis/reaktor/media/service/MediaUploader.kt; reaktor/reaktor-media/src/commonMain/kotlin/dev/shibasis/reaktor/media/service/MediaService.kt; reaktor/reaktor-media/src/commonMain/kotlin/dev/shibasis/reaktor/media/speech/SpeechRecognizer.kt.

reaktor-telemetry

Five priority tasks and Astra traceability.

Purpose and current implementation. OpenTelemetry, Firebase Analytics and Crashlytics adapters; Graph.instrument observes lifecycle/navigation and port events on existing nodes.

Quality Q2 · Stability S1. Useful hooks, but no module-local tests. The inspected instrumentation has no clear span-ending/disposal path, does not automatically attach to later nodes, and recursively passes the original parent context. It is not a complete causal trace of the graph.

Usage U2. BestBuds app/server paths use it. Lack of import in another product does not prove no backend telemetry exists there.

Vision and impact. Make the framework explain runtime behavior and observation coverage for each graph path.

Graph integration and combinations. Join spans and metrics to activation IDs, port operations, release/config revisions and environments. Add causation links across queued/batched work; OpenTelemetry span links are useful for this. Pair performance and kernel receipts so a regression identifies the affected product path.

Acceptance gate. Prove span lifetime, dynamic attach/detach, propagation and sampling behavior; mark uninstrumented edges and dropped events instead of implying complete coverage.

Evidence: reaktor/reaktor-telemetry/src/commonMain/kotlin/dev/shibasis/reaktor/telemetry/GraphTelemetry.kt; reaktor/reaktor-telemetry/src/commonMain/kotlin/dev/shibasis/reaktor/telemetry/TelemetryAdapter.kt; reaktor/reaktor-telemetry/src/commonMain/kotlin/dev/shibasis/reaktor/telemetry/AnalyticsAdapter.kt.

reaktor-performance

Five priority tasks and Astra traceability.

Purpose and current implementation. Report models, collectors, performance scopes, app/web/server vitals, Lighthouse interpretation, budgets, JVM output and a failure-preserving measurement harness.

Quality Q3 · Stability S2. Good reusable evidence machinery with passing current tests. It does not establish that all products enforce budgets, or that a microbenchmark gain improves a user journey.

Usage U2. BestBuds has explicit performance integration; framework serialization work has related benchmark infrastructure.

Vision and impact. Become the mechanism that decides whether a module and its combinations actually earn their complexity.

Graph integration and combinations. Project Benchmark, Scenario, SampleSet, Budget, Regression and ArtifactDigest. Link each result to exact source/target and the service/UI paths it covers. Combine compiler, FlexBuffer, FFI, graph layout, and deployment choices using end-to-end measurements.

Acceptance gate. Require comparable baselines and report uncertainty, allocation, latency, size and failure rate; block only on declared budgets with a reproducible workload.

Evidence: reaktor/reaktor-performance/src/commonMain/kotlin/dev/shibasis/reaktor/performance/ReaktorPerformanceHarness.kt; reaktor/reaktor-performance/src/commonMain/kotlin/dev/shibasis/reaktor/performance/ReaktorPerformanceBudgets.kt; reaktor/reaktor-performance/src/commonTest/kotlin/dev/shibasis/reaktor/performance/ReaktorPerformanceCollectorTest.kt.

reaktor-flexbuffer

Five priority tasks and Astra traceability.

Purpose and current implementation. Substantial portable binary encoding/decoding, generated coders, accessor views, pooling, platform fast paths, native wrappers and extensive benchmark/hardening sources.

Quality Q3 · Stability S1. Technically ambitious and better tested than its product adoption suggests. Validation is opt-in; public decode does not automatically establish safe untrusted-buffer handling. Object decode still materializes values, and ByteArray encoding copies output.

Usage U1. Mostly framework experiments and BestBuds serialization diagnostics; a dependency declaration does not prove the product hot path uses it.

Vision and impact. Substantially reduce serialization and crossing costs when measured in a complete workload.

Graph integration and combinations. Project WireSchema, CodecVersion, BufferOwnership and ABI/Benchmark evidence. Combine compiler-generated schemas with service/FFI boundary negotiation; validate at trust boundaries and keep internal fast paths separate.

Acceptance gate. Demonstrate cross-language round trips, malformed-input rejection, schema evolution, bounded lifetime and an end-to-end gain over the existing format—not just faster isolated encoding.

Evidence: reaktor/reaktor-flexbuffer/src/commonMain/kotlin/dev/shibasis/reaktor/flexbuffer/core/FlexBuffers.kt; reaktor/reaktor-flexbuffer/src/commonMain/kotlin/dev/shibasis/reaktor/flexbuffer/flatbuffers/FlexBufferValidator.kt; reaktor/reaktor-flexbuffer/src/jvmTest/kotlin/dev/shibasis/reaktor/flexbuffer/FlexBufferHardeningTest.kt.

October evidence update (4 October 2026). The current review includes real Chrome and physical S23/iPhone measurements, JSON and Protobuf, allocations and wire sizes. Four dedicated repros fail: map hashing, valid-empty-map validation, explicit-null defaults and generated required-field/layout rejection. These remain adoption blockers; Android public bulk-view wins are experiments, not shipped kernels. The complete book contributes a proposed mutable-memory design, not an implemented runtime.

reaktor-ffi

Five priority tasks and Astra traceability.

Purpose and current implementation. A native Hermes/JSI integration, module Switch registry, invocation interfaces and a FlexPayload convention.

Quality Q1 · Stability S1. Core transport methods and argument decoding are TODO. JVM/JS native probes explicitly report unavailable behavior. Native hello/demo paths do not establish a universal graph protocol or code-push runtime.

Usage U1. BestBuds has a native probe; broader production crossing was not found.

Vision and impact. Eventually let optimized Kotlin/C++/JS capabilities participate under one contract with honest cost and lifecycle semantics.

Graph integration and combinations. Project NativeModule, FunctionContract, WireSession, BufferHandle and negotiated target profile. Join compiler/FlexBuffer/performance to runtime calls and ownership. Adopt the existing graph-protocol design incrementally; do not treat its specification as implemented.

Acceptance gate. Complete one bounded call/stream with cancellation, errors, ownership and version negotiation on two actual runtimes before claiming general parity.

Evidence: reaktor/reaktor-ffi/src/commonMain/kotlin/dev/shibasis/reaktor/ffi/switch/Switch.kt; reaktor/reaktor-ffi/src/commonMain/kotlin/dev/shibasis/reaktor/ffi/payload/FlexPayload.kt; reaktor/reaktor-ffi/src/commonMain/kotlin/dev/shibasis/reaktor/ffi/transport/Transport.kt; reaktor/reaktor-ffi/src/jvmMain/kotlin/dev/shibasis/reaktor/ffi/NativeBridge.jvm.kt.

October evidence update (4 October 2026). Codec measurements in the current review do not measure production frame/trunk latency. The canonical FFI guide distinguishes native hello proofs, TODO transport/arguments, proposed ownership and future acceptance gates. Codec correctness and layout/lifetime proof precede rollout.

reaktor-compiler

Five priority tasks and Astra traceability.

Purpose and current implementation. KSP processors for exposure/JS wrapper work and generated FlexCoder encoding/decoding/accessors.

Quality Q2 · Stability S2. Concrete generator implementation with unit tests. Unsupported types can emit TODO comments or generated runtime errors. This is not yet the canonical graph compiler, normalizer, or proof/lowering pipeline.

Usage U1. Build-time integration through Dependeasy and Struct-based codec generation; usage is chiefly internal tooling.

Vision and impact. Turn declarations into reusable machine-checkable contracts, source mappings and target conformance data.

Graph integration and combinations. Emit Symbol→Contract→Schema→GeneratedArtifact relationships and compatibility fingerprints. Combine ports, services and FFI to catch integration errors during compilation. Keep human-authored source and generated projections clearly owned.

Acceptance gate. Unsupported schemas must fail clearly at generation time; deterministic output and compatibility tests must connect generated artifacts to exact source declarations.

Evidence: reaktor/reaktor-compiler/src/main/kotlin/dev/shibasis/reaktor/compiler/ReaktorProcessor.kt; reaktor/reaktor-compiler/src/main/kotlin/dev/shibasis/reaktor/compiler/FlexCoderProcessor.kt; reaktor/reaktor-compiler/src/test/kotlin/dev/shibasis/reaktor/compiler/FlexCoderPropertyLayoutTest.kt.

dependeasy

Five priority tasks and Astra traceability.

Purpose and current implementation. Gradle convention plugins, dependency/platform configuration, Kotlin/JS export setup, CMake/cinterop/Prefab tasks and native bootstrap.

Quality Q2 · Stability S2. A high-impact operational substrate with substantial implementation but no local authored unit test tree. It can perform native bootstrap during configuration. Browser tests are disabled by the shared web configuration; declared targets therefore exceed routine checked coverage.

Usage U3. Framework, BestBuds, GymBuddy and other sibling composite builds depend on its conventions.

Vision and impact. Make supported build profiles reproducible and expose the real build/dependency graph to impact analysis.

Graph integration and combinations. Project BuildTarget, ToolchainProfile, Dependency, GeneratedArtifact and CheckExecution. Join source changes to affected target builds and runtime capabilities. Keep this build graph authoritative for build facts rather than recreating it from UI guesses.

Acceptance gate. Provide a clean-machine conformance matrix, explicit browser tests, minimal-consumer checks and measured build budgets; qualify Java 21 tooling versus Java 25 runtime consumers.

Evidence: reaktor/dependeasy/src/main/kotlin/dev/shibasis/dependeasy/plugins/LibraryPlugin.kt; reaktor/dependeasy/src/main/kotlin/dev/shibasis/dependeasy/settings/NativeBootstrap.kt; reaktor/dependeasy/src/main/kotlin/dev/shibasis/dependeasy/web/WebConfigure.kt; reaktor/dependeasy/src/main/kotlin/dev/shibasis/dependeasy/Version.kt.

reaktor-code

Five priority tasks and Astra traceability.

Purpose and current implementation. A newly registered KMP contract separates source intelligence from both its renderer and language-server implementation. One common source defines URI/version/text, zero-based UTF-16 positions, spans, diagnostics, completion, hover, definition locations and document lifecycle. Optional defaults and an explicit unavailable status allow editing without a server.

Quality Q2 · Stability S1. A focused dependency boundary over coroutines, with a Gradle check excluding renderer, tooling and LSP dependencies. No module-local behavioral tests were present at the follow-up scan. The interface is useful, but document-version correlation, stale response handling, cancellation and range semantics need conformance before advertising cross-editor/server interchangeability. The adjacent editor and JVM LSP adapters are separate implementations with their own tests.

Usage U2. Re-exported by reaktor-ui and reaktor-tooling; the editor state/document code, JVM language-server session and BestBuds GraphSourcePane consume it. These are internal framework/workbench consumers, not evidence of external adoption.

Vision and impact. Make source editing a reusable plain capability so creator, workbench, IDE and agent changes can share semantic feedback without importing one renderer or server. This improves the first custom-code edit and later refactoring while keeping source the owner of algorithms.

Graph integration and combinations. An optional adapter links SourceDocument/Revision and SourceSpan to Symbol, Contract, Definition and Diagnostic evidence. A language-server session is an activation with availability and lifetime; a completion is a proposal, not authority to modify arbitrary files. Combine code + UI + tooling/LSP + compiler + graph/flow so a selected port opens its real implementation, a source edit produces revision-bound findings, and accepted changes update the same semantic view.

Acceptance gate. A plain non-UI consumer can host the contract; out-of-order responses and closed documents cannot overwrite newer diagnostics or selections; one source→graph→source round trip preserves identity and owned source. UTF-16, empty/backward selections and multiline replacement semantics are covered explicitly.

Evidence: reaktor/reaktor-code/build.gradle.kts; reaktor/reaktor-code/src/commonMain/kotlin/dev/shibasis/reaktor/code/CodeIntelligence.kt; reaktor/reaktor-tooling/src/jvmMain/kotlin/dev/shibasis/reaktor/tooling/lsp/LanguageServerSession.kt; reaktor/reaktor-ui/src/commonMain/kotlin/dev/shibasis/reaktor/ui/code/CodeEditorState.kt; bestbuds/modules/engine/src/jvmMain/kotlin/ai/bestbuds/reaktor/workbench/render/compose/graph/GraphSourcePane.kt.

reaktor-ui

Five priority tasks and Astra traceability.

Purpose and current implementation. Compose tokens/themes/atoms/molecules, component specifications, selected authored TypeScript/JS components and the MachineSignal workbench design system.

Quality Q3 · Stability S2. A large reusable UI foundation with parity/adaptive tests, but multiple authored platform surfaces need continued reconciliation. MachineSignal currently uses a fixed dark token system; design references alone do not prove light/high-contrast support.

Usage U3. BestBuds, GymBuddy and Manna consume parts of it through different surfaces.

Vision and impact. Make meaning, accessibility and evidence legible through reusable components rather than per-pane styling.

Graph integration and combinations. Project ComponentSpec, TokenSet, Variant, SemanticRole, Interaction and RenderEvidence. Join UI actions to service operations and requirements; connect design revisions to impacted components and visual checks. MachineSignal remains the sole truth-to-appearance mapping.

Acceptance gate. One component contract must produce consistent semantics and tested behavior across supported renderers; distinguish design tokens from observed runtime status.

Evidence: reaktor/reaktor-ui/src/commonMain/kotlin/dev/shibasis/reaktor/ui/core/components/ComponentSpec.kt; reaktor/reaktor-ui/src/commonMain/kotlin/dev/shibasis/reaktor/ui/machinesignal/MachineSignalTokens.kt; reaktor/reaktor-ui/src/commonMain/kotlin/dev/shibasis/reaktor/ui/core/adaptive/AuthoredLayout.kt; reaktor/reaktor-ui/ts/src/index.ts.

compose-flow

Five priority tasks and Astra traceability.

Purpose and current implementation. Generic Compose canvas, node/edge primitives, hit testing, handles, viewport gestures, minimap and selection/reconnection machinery.

Quality Q3 · Stability S2. Current JVM tests passed. Historical JS/Android path-test failures reflect missing native graphics initialization/mock support; they do not establish current desktop failure, but cross-target graphics qualification remains incomplete.

Usage U2. Primarily the Reaktor workbench through reaktor-flow. This indirect consumer matters more than direct import counts.

Vision and impact. Keep large, layered graphs readable and manipulable with a small generic canvas API.

Graph integration and combinations. Render bounded projections and interaction state without acquiring Reaktor semantics. Combine reaktor-flow layer filtering and performance budgets with stable selection, semantic zoom and incremental updates.

Acceptance gate. Meet frame-time and interaction budgets on representative dense graphs; preserve pointer anchors, selection and camera across scope/layer changes on each supported platform.

Evidence: reaktor/compose-flow/src/commonMain/kotlin/dev/shibasis/composeflow/compose/ReactFlow.kt; reaktor/compose-flow/src/commonMain/kotlin/dev/shibasis/composeflow/compose/interaction/FlowViewportGestures.kt; reaktor/compose-flow/src/jvmTest/kotlin/dev/shibasis/composeflow/compose/interaction/FlowDesktopViewportPlatformBridgeTest.kt.

reaktor-flow

Five priority tasks and Astra traceability.

Purpose and current implementation. Reaktor graph adaptation, scope disclosure, architecture snapshots, measurement/layout, styles, selections, document/session/commands and editor composition.

Quality Q3 · Stability S2. Substantial current tests passed. AddEdge validates existence and port roles but not full contract type compatibility. Document editing and runtime mutation remain separate mechanisms.

Usage U2. BestBuds desktop and prototype surfaces are the major consumers; Manna has a related TypeScript scope path rather than the same native renderer.

Vision and impact. Make the multilayer graph a usable development instrument, with every visual relation carrying inspectable semantics.

Graph integration and combinations. Add layer-aware lenses, typed edge legends, evidence/temporal filtering, change previews and provenance-preserving collapsed summaries. Connect GraphEditorSession patches to canonical validation/planning instead of mutating runtime objects from gestures.

Acceptance gate. A visual edit must explain contract violations and affected layers before execution; a filtered/collapsed view must never imply that hidden dependencies ceased to exist.

Evidence: reaktor/reaktor-flow/src/commonMain/kotlin/dev/shibasis/reaktor/flow/graph/document/GraphDocument.kt; reaktor/reaktor-flow/src/commonMain/kotlin/dev/shibasis/reaktor/flow/graph/document/GraphCommands.kt; reaktor/reaktor-flow/src/commonMain/kotlin/dev/shibasis/reaktor/flow/graph/document/GraphEditorSession.kt; reaktor/reaktor-flow/src/commonMain/kotlin/dev/shibasis/reaktor/flow/graph/model/ReaktorArchitecture.kt.

reaktor-tooling

Five priority tasks and Astra traceability.

Purpose and current implementation. Graph-agnostic discovery/task/plan/receipt vocabulary, supervised process execution, source seals, bounded output, cancellation, device/IDE/database/Kubernetes inspection and loopback MCP transport.

Quality Q3 · Stability S2. Strong reusable boundary with meaningful JVM tests; the initial focused task succeeded using its cached test result. A later integration attempt encountered compile errors while new native infrastructure adapters were appearing, then passed on recheck after the source changed (see the verification appendix). Their live behavior remains unqualified. Discovery is based on source/config parsing, not a complete semantic compiler. The executor can record to a supplied sink, but durable storage and policy belong to a host; default event persistence is not guaranteed.

Usage U2. BestBuds kernel/engine and both CLI families use it; Conductor also reuses execution.

Vision and impact. Turn existing specialist tools into composable operations with inspectable effects and evidence.

Graph integration and combinations. Project Tool, Task, Plan, Process, Artifact and Receipt relationships; bind source definitions and environment to execution. Combine cloud/build/database/device operations with one kernel policy path. Record query coverage and parse failures as evidence.

Acceptance gate. Fingerprint, definition-seal, cancellation and redaction tests must cover each adapter; every advertised successful operation must either verify its artifact or label it unverified.

Evidence: reaktor/reaktor-tooling/src/jvmMain/kotlin/dev/shibasis/reaktor/tooling/SupervisedProcessExecutor.kt; reaktor/reaktor-tooling/src/jvmMain/kotlin/dev/shibasis/reaktor/tooling/JvmProjectDiscovery.kt; reaktor/reaktor-tooling/src/commonMain/kotlin/dev/shibasis/reaktor/tooling/ToolingModels.kt; reaktor/reaktor-tooling/src/jvmMain/kotlin/dev/shibasis/reaktor/tooling/mcp/LoopbackMcpServer.kt.

reaktor-mcp

Five priority tasks and Astra traceability.

Purpose and current implementation. A compact transport-independent JSON-RPC read-tool/resource registry with initialization, lists, calls, resources, ping and batch handling.

Quality Q2 · Stability S2. Useful implementation, no module-local test tree; kernel/tooling integration tests exercise it. Transport, caller authority, query budgets and redaction are host responsibilities. Read-only annotations alone do not enforce purity of arbitrary callbacks.

Usage U2. BestBuds kernel, desktop and server integrations; not a placeholder anymore.

Vision and impact. Expose authorized graph knowledge and plans through a stable agent-facing protocol.

Graph integration and combinations. Describe QueryContract, ResourceView, SnapshotRevision and ResultEvidence. Pair kernel projection with typed identities, bounded selectors and read-set receipts. Keep mutation proposals separate from the current read server and from approval authority.

Acceptance gate. The same read contract must return the same scoped evidence through CLI/MCP/UI; prove limits and redaction, and qualify remote authentication before remote hosting.

Evidence: reaktor/reaktor-mcp/src/commonMain/kotlin/dev/shibasis/reaktor/mcp/McpProtocol.kt.

reaktor-conductor

Five priority tasks and Astra traceability.

Purpose and current implementation. Agent specs, conversation/event documents, context compilation, Ask/Broadcast/Council/Pipeline/Planned protocols and supervised Codex/Claude CLI adapters.

Quality Q3 · Stability S1. A coherent portable model and passing current tests. It lacks the governed broker connection, durable receipts/recovery, enforced worktree isolation and full graph projection. Protocol bookkeeping can be deterministic while model outputs are not.

Usage U1. An internal terminal/tooling capability. No current BestBuds app/engine source import was found; build substitution alone is not integration.

Vision and impact. Use evidence-aware agents to produce better changes and investigations while retaining reviewable provenance.

Graph integration and combinations. Project Mission, Agent, ContextPacket, Proposal, TypedDependency, Run and Receipt. Add typed causal edges, inclusion reasons, dependency read sets and base revisions. Combine MCP retrieval, kernel effect control, tests and performance so agent output is checkable work.

Acceptance gate. One agent must complete a bounded mission through the shared broker with a receipt; then measure whether councils improve quality after accounting for token cost and latency. Interruptions must preserve unknown external outcomes.

Evidence: reaktor/reaktor-conductor/src/commonMain/kotlin/dev/shibasis/reaktor/conductor/Conductor.kt; reaktor/reaktor-conductor/src/commonMain/kotlin/dev/shibasis/reaktor/conductor/Thread.kt; reaktor/reaktor-conductor/src/commonMain/kotlin/dev/shibasis/reaktor/conductor/ContextCompiler.kt; reaktor/reaktor-conductor/src/jvmMain/kotlin/dev/shibasis/reaktor/conductor/cli/CliAgentRuntime.kt.

reaktor-cloud

Five priority tasks and Astra traceability.

Purpose and current implementation. Provider inventory/tool models, supervised Dagger/Pulumi/Wrangler integration, run registry and Kotlin/JVM observability infrastructure code.

Quality Q2 · Stability S2. Useful planning/execution support and a custom E2E harness; live cloud conformance was not run. Source inventory is not deployed state. Product-specific observability definitions inside the open module deserve cleaner packaging.

Usage U2. Many workbench panes/tool adapters use it; this is operator usage, not evidence of deployment volume.

Vision and impact. Connect desired infrastructure, delivered artifacts and observed resources into one explorable system.

Graph integration and combinations. Project Provider, Stack, ResourceDefinition, DeploymentPlan, ResourceObservation and Release. Combine build artifacts, service bindings, data residency and telemetry for precise change impact and drift reconciliation.

Acceptance gate. A preview must name exact source/stack/effect scope; an execution result must distinguish process success from reconciled infrastructure and verified application behavior.

Evidence: reaktor/reaktor-cloud/src/commonMain/kotlin/dev/shibasis/reaktor/cloud/CloudProviders.kt; reaktor/reaktor-cloud/src/jvmMain/kotlin/dev/shibasis/reaktor/cloud/PulumiToolProvider.kt; reaktor/reaktor-cloud/src/jvmMain/kotlin/dev/shibasis/reaktor/cloud/DaggerToolProvider.kt; reaktor/reaktor-cloud/src/e2e/kotlin/dev/shibasis/reaktor/cloud/CloudToolE2e.kt.

reaktor-cli

Five priority tasks and Astra traceability.

Purpose and current implementation. Separate open Kotlin/JVM CLI for project discovery, lifecycle tasks, topology/introspection, deployment selection and framework shortcuts.

Quality Q2 · Stability S2. A substantial CLI with regression/E2E sources, outside the root Gradle module list. It is distinct from the new closed reaktor-workbench CLI and does not own its kernel.

Usage U1. Internal operator/frontend use; invocation frequency and third-party adoption unknown.

Vision and impact. Become the one public command line selected in the workbench decision. Move generic workspace catalog, plans, environment and ledger mechanics into the proposed open workspace layer, and converge the closed CLI through product contributors. This is planned extraction; the two command models still exist today.

Graph integration and combinations. Use the same Task, Plan, Query and Receipt schemas as other hosts. Render graph selections and explain impact in the terminal; avoid a separate command execution truth model. Combine discovery with build and cloud providers.

Acceptance gate. Generic framework tasks must work without BestBuds source or credentials; command output and exit status must preserve structured outcomes and exact effect scope.

Evidence: reaktor/reaktor-cli/build.gradle.kts; reaktor/reaktor-cli/src/main/kotlin/dev/shibasis/reaktor/cli/Main.kt; reaktor/reaktor-cli/src/e2e/kotlin/dev/shibasis/reaktor/cli/ToolingE2eSmoke.kt.

reaktor-web

Five priority tasks and Astra traceability.

Purpose and current implementation. A registered module containing empty/toy WebView classes; no usable native WebView contract was found.

Quality Q0 · Stability S0. Its name and platform folders overstate the implementation. There is no current behavior to qualify.

Usage U0. No active source consumer found.

Vision and impact. Only worth developing if a real embedded-web use case cannot be met through the existing host/IO layers.

Graph integration and combinations. If justified, project EmbeddedDocument, OriginPolicy, BridgeContract and NavigationSession; combine auth, IO, media permissions and UI semantics. Do not represent browser-content execution as graph-authorized merely because it is embedded.

Acceptance gate. First prove a required product journey and isolation/navigation/bridge behavior. Until then keep it explicitly unavailable.

Evidence: reaktor/reaktor-web/src/commonMain/kotlin/dev/shibasis/reaktor/web/WebView.kt; reaktor/reaktor-web/src/androidMain/kotlin/dev/shibasis/reaktor/web/AndroidWebView.kt; reaktor/reaktor-web/build.gradle.kts.

reaktor-tactile

Five priority tasks and Astra traceability.

Purpose and current implementation. A reserved build artifact with no implementation source.

Quality Q0 · Stability S0. No quality or stability claim is possible. The applicable Reaktor guide explicitly says not to extend this placeholder.

Usage U0. No consumer found.

Vision and impact. Haptic feedback may improve interaction, but a dedicated module has not earned its place. Current guidance favors leaving this frozen.

Graph integration and combinations. If the project later revisits ownership, typed Interaction→FeedbackPattern→DeviceCapability relations could combine UI, accessibility, notifications and hardware support. This is a conditional design option, not a recommendation to implement against the current guide.

Acceptance gate. Require a concrete substantial interaction benefit and an ownership decision before creating a new subsystem.

Evidence: reaktor/reaktor-tactile/README.md; reaktor/reaktor-tactile/build.gradle.kts.

reaktor-react

Five priority tasks and Astra traceability.

Purpose and current implementation. Historical React Native JSI/C++/Kotlin interop, with old flatinvoker names and platform bridge code.

Quality Q1 · Stability S0. Explicitly excluded from the root build. No current test or active product-consumer evidence. It should not be confused with active web React code in graph/UI packages.

Usage U0. No current authored consumer found.

Vision and impact. Preserve useful bridge learnings without carrying two competing universal interop stacks.

Graph integration and combinations. Prefer migrating any proven mechanism into the supported FFI contract path if a React Native consumer appears. A future renderer/bridge adapter should expose capabilities and ABI evidence through FFI and UI schemas.

Acceptance gate. Remain archived unless a real consumer justifies conformance work; do not count its presence as a supported target.

Evidence: reaktor/reaktor-react/build.gradle.kts; reaktor/reaktor-react/cpp/droid/Invoker.cpp.

4. Closed Reaktor and BestBuds modules

BestBuds modules/kernel — workspace backend

Five priority tasks and Astra traceability.

Purpose. The new Java 25 headless backend owns workspace catalog/policy, environment selection, sealed planning, execution receipts, persistence, database/auth sessions, connection checks and MCP read projection. KernelGraph wires operations, database, auth and connection services through actual typed ports. Desktop borrows those services; CLI and headless MCP can host the same backend implementation.

Quality Q3 · Stability S2 · Usage U2. This is a strong extraction with a runtime dependency boundary check and real loopback/process integration tests. Current kernel checks succeeded, with one skipped test in the recorded suite. The extraction is recent and uncommitted. Each process owns its own kernel; GUI and CLI do not automatically synchronize state, and concurrent hosts must not share the same explicit state file. It is a workspace kernel, not the future canonical graph compiler kernel.

Vision and impact. Make workspace operations coherent across all interfaces. This can remove duplicated environment/approval logic, allow useful headless automation, and let agents inspect the same evidence as a human operator.

Graph integration. Promote workspace, environment, task, prepared plan, source seal, operation run, connection/session and receipt to typed entities with stable identities. Link plans to their complete definition/read set and observations to their actual source scope. Reuse open tooling for mechanics; extract generic project-service behavior into the proposed public workspace layer, keeping BestBuds-specific task recipes, private sessions and policy here. The one-command-line decision governs this next boundary change. The plain operations/session API must remain useful without rendering a graph.

Combinations and gate. Kernel + tooling + auth + MCP + Conductor should produce one governed run visible identically in desktop and terminal. Pass environment-change, stale-plan, restart, sensitive-output, cancellation and session-lifetime tests. Before introducing a shared daemon, specify concurrency/locking, authorization and persistence separately; API sharing already delivers value without a daemon.

Evidence: bestbuds/modules/kernel/src/main/kotlin/ai/bestbuds/reaktor/kernel/KernelGraph.kt, bestbuds/modules/kernel/src/main/kotlin/ai/bestbuds/reaktor/kernel/ReaktorKernel.kt, bestbuds/modules/kernel/src/main/kotlin/ai/bestbuds/reaktor/workbench/operations/OperationalControlPlane.kt, bestbuds/modules/kernel/src/test/kotlin/ai/bestbuds/reaktor/kernel/KernelIntegrationTest.kt.

BestBuds modules/engine — workbench and presentation

Five priority tasks and Astra traceability.

Purpose. Hosts the operator shell, graph selection/navigation, panes, inspectors, source/preview/device tooling and renderer bridges. The native DesktopWorkbenchGraph has 13 mode routes, including App/UI preview; 12 are in the visible mode list. Common fixture-based workbench graphs, browser prototype rendering and generated design reference boards also coexist in this module.

Quality Q2 · Stability S2 · Usage U2. Many real panes, graph bindings and design/truth tests exist. The newly extracted backend and desktop graph considerably improve ownership. The large module still contains several generations of workbench/prototype implementation and a large generated reference surface. A graph route for a pane proves that it is mounted/wired, not that every promised tool inside it is implemented or observing a live system.

Vision and impact. Give developers one persistent context through source, behavior, data, authority, delivery and evidence. The key quality measure is whether a developer can understand and complete a real change with less context loss.

Graph integration. Treat panes as lenses over canonical entities, with shared workspace/revision/environment/principal/time/selection/run context. Preserve complete typed selections across mode switches. Keep generic canvas work in compose-flow, semantic layout/adaptation in reaktor-flow, and shell state here. Reuse kernel sessions and effects; do not add pane-specific execution paths.

Combinations and gate. A selected message handler should remain selected when moving to its database query, deployment, policy and trace. A returned observation should name the exact revision and source; reference boards must remain reference boards. Evaluate task completion, incorrect health inference, navigation continuity and context-switch effort, in addition to visual parity.

Evidence: bestbuds/modules/engine/src/jvmMain/kotlin/ai/bestbuds/reaktor/workbench/graph/DesktopWorkbenchGraph.kt, bestbuds/modules/engine/src/jvmMain/kotlin/ai/bestbuds/reaktor/workbench/render/compose/shell/WorkbenchModes.kt, bestbuds/modules/engine/src/jvmMain/kotlin/ai/bestbuds/reaktor/workbench/render/compose/shell/WorkbenchModePanes.kt, bestbuds/modules/engine/README.md.

BestBuds modules/app — shared product and Worker implementations

Five priority tasks and Astra traceability.

Purpose. The product composition root includes nested chat/campaign/discover/event/friend/profile/palette/dev graphs, repositories, state interactors, chat actors, service clients/contracts, native setup and the Kotlin/JS implementations behind the Worker fleet.

Quality Q2 · Stability S2 · Usage U2. The main chat/auth/repository flows have substantive implementation and architecture/interactor tests. The module mixes production-oriented flows with fixture-driven events and prototype entry points. Its cached app test report is useful historical evidence, not a fresh qualification of all product workflows. The root BestBuds singleton/global feature bootstrap also limits clean multi-instance reasoning.

Vision and impact. This is the flagship proof that Reaktor's abstractions can produce a real social product. Its purpose is successful, safe, sustained user relationships; framework expressiveness is valuable when it improves that outcome and the speed/reliability of delivering it.

Graph integration. Maintain a product recipe graph over shared framework contracts: user journey → route/action → interactor/actor → service operation → query/store → deployment → observation/outcome. Project social/matching knowledge separately from executable application objects, joining them through typed references and scoped evidence. BestBuds domain names belong here; reusable mechanics should graduate into Reaktor only after proving broader value.

Combinations and gate. Use “join → complete profile → form group → send message → moderate → deliver notification → measure outcome” as the end-to-end integration scenario. Assert correctness under offline use, account changes, blocks, retries and environment differences. A fixture-filled screen or success return must not count as end-to-end capability.

Evidence: bestbuds/modules/app/src/commonMain/kotlin/ai/bestbuds/app/BestBuds.kt, bestbuds/modules/app/src/commonMain/kotlin/ai/bestbuds/app/data/actors/ChatActor.kt, bestbuds/modules/app/src/commonMain/kotlin/ai/bestbuds/app/data/interactors/EventInteractors.kt, bestbuds/modules/app/src/jsMain/kotlin/ai/bestbuds/app/cloudflare/core/BestBudsWorker.kt.

BestBuds modules/design — product design system

Five priority tasks and Astra traceability.

Purpose. Product themes, tokens and reusable components over Reaktor UI, plus the Human Signal/product prototype composition.

Quality Q3 · Stability S2 · Usage U2. Concrete reusable components and design tests exist. Prototype assets and authored screens are not evidence of integrated backend behavior. Keep its product identity distinct from MachineSignal's operator language while sharing the underlying component mechanisms.

Vision and impact. Make product features visually and behaviorally consistent while reducing the amount of code needed for new screens.

Graph integration. Describe token sets, components, variants, accessibility roles and interactions; link each used component to routes, requirements and validation evidence. Combine UI semantics with service/data contracts so a disabled or loading action has an explainable cause.

Gate. A shared component change should identify affected screens and relevant visual/behavior checks. Generated/reference designs must not substitute for interactive acceptance.

Evidence: bestbuds/modules/design/build.gradle.kts, bestbuds/modules/design/src.

modules/engine/prototype-browser / enginePrototype — browser publication slice

Five priority tasks and Astra traceability.

Purpose. A JS-only build slice compiles selected canonical prototype sources/resources from engine without loading the full product/backend dependency graph.

Quality Q2 · Stability S1 · Usage U1. The boundary is intentional and useful for distributing a design/prototype experience. It is not a browser build of the complete desktop kernel and live operator workbench.

Vision and impact. Provide cheap browser access to design exploration and eventual qualified web graph interactions.

Graph integration. Publish an explicit capability/profile descriptor: reference visualization, fixture interactions and any real graph tools each have distinct provenance. Pair shared graph-document contracts with browser renderer conformance. A promoted feature must prove a real service/query adapter before being labeled operational.

Evidence: bestbuds/modules/engine/prototype-browser/build.gradle.kts, bestbuds/modules/engine/src/commonMain/kotlin/ai/bestbuds/reaktor/prototype.

Workbench functional modules inside engine

These are logical subsystems, not separate Gradle modules. All have internal workbench usage; the U score below rates the actual operational path, not presence in the menu. Q/S are conservative judgments of the assembled surface. The canonical wiring is in DesktopWorkbenchGraph and WorkbenchModePanes linked above; bestbuds/modules/engine/src/jvmMain/kotlin/ai/bestbuds/reaktor/workbench/render/compose/panes contain the implementation.

5. BestBuds functional domains

This section expands the shared app module so that independent product capabilities are not hidden under one overall score. Except where marked U1, these are U2 source consumers within BestBuds. Their Worker wrappers are listed separately in section 6.

Source map: bestbuds/modules/app/src/commonMain/kotlin/ai/bestbuds/app/data/interactors, bestbuds/modules/app/src/commonMain/kotlin/ai/bestbuds/app/data/actors, bestbuds/modules/app/src/commonMain/kotlin/ai/bestbuds/app/data/services, bestbuds/modules/app/src/jsMain/kotlin/ai/bestbuds/app/cloudflare, bestbuds/modules/app/src/commonMain/kotlin/ai/bestbuds/app/data/analytics/BestBudsEvents.kt, bestbuds/modules/app/src/jsMain/kotlin/ai/bestbuds/app/cloudflare/analytics/AnalyticsWorkerRepository.kt, bestbuds/modules/app/src/jsMain/kotlin/ai/bestbuds/app/cloudflare/core/BestBudsRequest.kt.

Matching and graph-data subsystems outside Gradle

models/neo4j-airflow-sync: Q2/S1/U2. DAGs perform user/relationship synchronization, grouping, cleanup and exports. The daily grouping source still executes its own greedy/merge/rebalance algorithm; it does not import matcher v2. The grouping export includes undirected block exclusions and writes chat_members. This is meaningful orchestration source, but the scheduler's deployed version and last successful run were not checked. Project each Extract/Transform/Match/Write stage, dataset revision, constraint set and run receipt. Join relational records, graph embeddings and campaign/chat creation so partial materialization can be detected and resumed. Gate: replay a complete fixture run and injected partial failures with no duplicate campaigns or unsafe assignments. bestbuds/models/neo4j-airflow-sync/dags.

models/matcher-v2: Q3/S1/U1. A more composable pure pipeline builds a KNN graph, detects communities, and refines groups under hard constraints. It has tests and synthetic demos. The current KNN path is brute cosine, the implemented community path is Louvain-oriented, and activity scoring remains unused. README claims about HNSW/Leiden and replacing the old pipeline must not be read as completed production migration. Project separate weighted similarity, geography, age/preference and signed exclusion relations; record source completeness and renormalize missing optional signals. A MatchRun should retain model/weights/constraints/input revision, feasible groups, leftovers and reasons. Combine social blocks, campaign assignment, notifications and outcome evaluation. Gate: zero hard-constraint violations, reproducibility, leftover/quality metrics, runtime scaling, then a controlled comparison against v1. bestbuds/models/matcher-v2/matcher_v2/group_former.py, bestbuds/models/matcher-v2/matcher_v2/scoring.py, bestbuds/models/matcher-v2/tests/test_form_groups.py.

models/algorithm: Q1/S1/U1. Older matcher/database/performance experiments, including a base Matcher that simply groups all members together. Treat it as historical exploration, not another supported production matching engine. Preserve benchmark/algorithm provenance in the graph; consolidate useful experiments into the qualified matcher harness. Gate: no active product path silently imports an experimental implementation. bestbuds/models/algorithm/algorithm.

Knowledge import and graph gateway: Q2/S2/U2. BestBuds also hosts Manna KG imports, schema discovery and server graph/GraphQL routes. Memgraph/domain data and runtime graph definitions are distinct. The improvement is federated, typed references: Resource/Concept/Task relations can inform development or learning without granting an agent ambient access to every tenant's knowledge. Gate: named-query authorization, exact tenant binding, pagination, bounded expansion, provenance and import revision checks. bestbuds/targets/reaktorServer/src/main/kotlin/ai/bestbuds/server/GraphGateway.kt, bestbuds/cloud/k3s/build-knowledge-graph-import.py.

6. Every BestBuds target and supporting delivery module

Targets are packaging, hosting or deployment units. They can substantially improve reach, operation or reliability without each inventing new framework primitives. For thin wrappers, Q/S include the owning implementation and hosting boundary; U2 means a substantive source-integrated product path, not measured production traffic. The target link in each row opens its five priority tasks. Source/configuration paths appear in the evidence appendix.

Reaktor/product hosts

Worker fleet and operational targets

Worker implementation evidence: bestbuds/modules/app/src/jsMain/kotlin/ai/bestbuds/app/cloudflare. Important host-specific evidence: bestbuds/targets/configServer/src/index.ts, bestbuds/modules/app/src/jsMain/kotlin/ai/bestbuds/app/cloudflare/diagnostics/DataProbeWorker.kt, bestbuds/targets/reaktorServer/src/main/kotlin/ai/bestbuds/server/ServerApplication.kt, bestbuds/targets/companyOS/worker/graph.ts, bestbuds/targets/reaktorWeb/worker/index.ts.

Supporting systems that should contribute to the graph

Named visions that are not independent implemented modules

The code inventory contains no standalone implemented artifact named reaktor-data, reaktor-mesh, reaktor-bus, reaktor-surface, or reaktor-arena. Related documents and partial primitives exist. Their absence as artifacts does not make the ideas valueless; it means their quality/stability/usage cannot be rated as shipping modules.

7. Combinations with the highest potential return

The release-level composition is create → grow → diagnose/recover → deploy/export. Engine + UI/design + auth-core/auth + Service/DB + tooling/CLI + telemetry/tests should turn an unseen brief into functioning source, then apply a role/schema/design change while preserving data and behavior. Its payoff is a shorter path to a correct accepted application and later change; measure both against a strong baseline with the same model and total time/cost. The combinations below are mechanisms that improve that journey. Their local priority labels do not supersede the master plan's creation-first release scope.

The unit of success should be a useful cross-layer task. The following combinations create capabilities none of their modules provides alone. Priority reflects source readiness, breadth of benefit and implementation risk—not a measured return on investment.

1. Service-to-production impact analysis — first priority

Combine: compiler/source index + ports/runtime + service + DB + cloud + kernel + tests + telemetry.

Scenario: change the message-send contract or its schema. The graph follows Symbol → Contract → Handler → Query/Store and Handler → BuildArtifact → Deployment → Activation. It identifies affected callers, scopes, migrations, Worker bindings, tests and observed paths. The operator sees why each entity is included.

Substantial improvement: replace manual cross-repository impact reconstruction with a reviewable dependency closure. The compiler contributes declaration accuracy, storage adds data impact, delivery links it to running systems, and evidence distinguishes intended from deployed behavior.

Gate: seed a set of known changes with independently reviewed affected entities; require no missed mandatory dependency in that set. Measure precision, query latency and diagnosis time. Unknown dynamic dependencies must remain explicit rather than silently omitted. Initial target: at least halve the manual navigation effort on these representative tasks without degrading correctness.

2. Reliable messaging and notifications under failure — first priority

Combine: app ChatActor + service + IO + DB + work + Cloudflare/PartyServer + moderation + notifications + telemetry.

Scenario: a user sends media while temporarily offline; upload resumes, message persistence succeeds, moderation is delayed and notification delivery retries. These are separate outcomes linked to one user intent.

Substantial improvement: the graph can explain where the intent stopped, retry the appropriate operation and avoid duplicating completed effects. A persistent outbox/checkpoint supplies durability; transport alone cannot.

Gate: inject cancellation, duplicate requests, lost acknowledgements, moderator timeout, token rotation and restart. Verify one logical message and correctly reconciled delivery states. Do not promise exactly-once distributed execution; use idempotent effects and explicit deduplication boundaries. Measure time-to-visible-message, lost/duplicate effects and time-to-diagnosis.

3. Authority-aware operations and credential rotation — first priority

Combine: auth + secrets + kernel + tooling + DB + cloud + MCP.

Scenario: an operator loses a grant, switches environment or rotates a secret after a plan was prepared. The graph identifies dependent operations and connection checks; stale authority/configuration invalidates the plan.

Substantial improvement: authority and resource dependencies can be examined together. This avoids a separate permission dashboard that cannot explain which concrete runtime path is affected.

Gate: enforce authorization at execution/read boundaries, not just in graph presentation. Revoke mid-session, change environment and rotate the version; prove a stale plan cannot reuse the old authorization. MCP output exposes scoped references and decisions without disclosing credentials.

4. Evidence-backed agent work — second priority

Combine: Conductor + MCP + kernel/tooling + graph/source contracts + tests + performance + optional worktree isolation.

Scenario: an agent receives a bounded graph slice with reasons for inclusion, proposes a patch against an exact revision, identifies read/write sets, runs the appropriate checks and returns a receipt with source/artifact digests.

Substantial improvement: the agent uses the framework's shared context and execution model; a human can verify the proposal without reconstructing its entire conversation. The gain comes from typed context and evidence, not merely from running more agents.

Gate: start with one agent and one operation contract. Measure task correctness, useful accepted changes, unsupported claims, latency, tokens and rework. Add a council only when an ablation shows the additional reviewer improves the total result enough to justify its cost. Parallel writers require isolated working state and conflict/read-set validation; Conductor's existing workspace-mode field does not supply that isolation.

5. Matching that improves real relationships — second priority

Combine: social/profile/block data + matcher v2 + knowledge/embedding graph + campaigns + notifications + analytics + auth/consent.

Scenario: generate feasible groups with explanations, then relate introductions to actual conversation participation and later user outcomes. Maintain similarity, geography and exclusion as different relation families. A hard block cannot be weakened into a low weighted score.

Substantial improvement: constraints, assignments and outcome feedback become one reproducible loop. Missing optional location is treated as unknown; model versions and data freshness explain why recommendations differ.

Gate: first qualify v2 offline against v1: zero hard-constraint violations, deterministic seeded outputs where promised, leftovers and quality/runtime metrics. Then use a controlled rollout/experiment for product impact. Do not optimize only notification volume, message count or time spent; evaluate meaningful participation and user-reported quality. Health/sensor data should remain outside matching unless a distinct consented product purpose justifies it.

6. Measured polyglot acceleration — second/third priority

Combine: compiler + FlexBuffer + FFI + ports/service + performance + telemetry.

Scenario: replace one expensive serialization or compute segment with a generated/native path while preserving the same operation contract and runtime observation link.

Substantial improvement: schema generation reduces glue, serialization reduces crossing cost, and native compute can improve a real hot path. Each piece alone may yield little end-to-end benefit if another boundary dominates.

Gate: benchmark a complete product scenario on the supported targets, including validation, copying, allocation, startup and failure handling. Record target profile and binary/schema revision. Pursue only when profiles identify a bottleneck; keep the conventional implementation as the correctness reference. Native ownership and untrusted-input safety are prerequisites, not optional performance overhead to omit from the comparison.

7. Design-to-behavior traceability — second priority

Combine: UI/design + graph/flow + source/compiler + services + preview/device tools + accessibility/parity tests.

Scenario: change an interaction requirement, inspect its component/route, preview the affected screens and verify the backing operation and error states on the relevant targets.

Substantial improvement: a visual design becomes connected to behavior and acceptance, while shared component changes reveal their real consumer set.

Gate: a selected design element maps to a stable component/interaction identity and a tested behavior path. Measure implementation rework and task completion. Compare observed rendering with specification; never use exported design scenes to claim a functional workbench.

8. Data lifecycle and deletion completeness — second priority

Combine: auth/account state + DB/schema + R2/media + graph derivatives + analytics + backups/purge + kernel receipts.

Scenario: deactivate an account, identify all owned and derived data, execute the declared retention policy, and record completion or explicit exceptions.

Substantial improvement: deletion and recovery become dependency-aware workflows. Relational cleanup, graph invalidation and media cleanup can no longer silently diverge.

Gate: use a synthetic account with known derived copies, caches and backups. Prove completeness against that inventory, correct retries, and the declared treatment of retained backups. Scope the result: no finite test establishes the absence of unknown copies outside the registered systems.

9. Device-context features with truthful observations — later, driven by GymBuddy

Combine: health + sensors + core permissions/truth + DB + work + notifications + UI.

Scenario: use a health-store total when available, fall back to device steps under explicit rules, display missing/denied data honestly and schedule a user-requested reminder.

Substantial improvement: native capability modules become reusable producers of contextual evidence, and the graph explains the source and limitations of what the user sees.

Gate: test watch/phone overlap, stale sync, midnight/timezone, reboot and permission changes on actual devices. Keep aggregated/referenced health data within its authorization boundary; a general development graph need not ingest personal measurements.

10. Documentation that invalidates with code — low-cost, broad value

Combine: module descriptors + source/compiler/build index + docs graph + test evidence + workbench/MCP.

Scenario: moving runtime classes into a new artifact marks an old architectural claim as needing review, updates ownership links and preserves the claim's source revision.

Substantial improvement: documentation stops accumulating unsupported “stable,” “implemented,” or “production” labels. This benefits developers and agent context simultaneously.

Gate: every implementation-status claim in the module catalog cites a current source or qualified check. A changed dependency or removed capability creates a typed finding; generated navigation is not itself implementation truth.

How to measure combinatorial improvement

For a task and metric oriented so higher is better, compare baseline B, improvement A, improvement C, and their composition A+C. The interaction term is:

interaction = value(A+C) - value(A) - value(C) + value(B)

A positive value suggests more-than-additive benefit for that metric. Use repeated comparable tasks, record uncertainty and normalize for task difficulty. For latency/cost, reverse the orientation or compare reductions consistently. Some capabilities are complementary prerequisites, so evaluate successful task completion as well as continuous metrics.

Use a small shared scorecard: correctness, time-to-verified-change, time-to-diagnosis, operational failure/recovery, resource cost, and product outcome. Include the ongoing maintenance cost of the module/combination. Do not multiply ordinal Q/S/U ratings or add raw graph edge counts and call the result impact. More relations help only when they are correct, discoverable, affordable and useful.

8. Execution roadmap and framework acceptance bar

The Module Execution Plan is the detailed five-task-per-module backlog. Its critical path groups the work into integrated outcomes. The Astra master plan owns the two-developer calendar and cut order.

The highest-value additions to the first review's roadmap are the real creation loop, public workspace/CLI independence, two capability strategy families and model-to-runtime failure evidence. Runtime hardening, semantic mapping and impact analysis are still essential; deliver them with the created feature and an existing consumer instead of as a disconnected platform rewrite.

The module admission bar

Before calling a module a substantial improvement, require:

1. A useful conventional API: a minimal consumer can adopt the capability without a workbench or mandatory graph construction.
2. A meaningful graph contribution: a new useful query, invariant, operation, evidence producer, optimization or lifecycle guarantee.
3. An explicit operating contract: schemas, ownership, assumptions/guarantees, effects, capability requirements and supported target/error/delivery semantics.
4. A demonstrated local benefit: a real creation, growth, debugging or operation task improves over the preceding implementation.
5. A demonstrated composition benefit: another module or recipe gains useful behavior without product-specific glue in the framework core.
6. Qualified evidence: source, fixture, test, observed state and proposed behavior remain distinct and bound to revision, target and assumptions.
7. A sustainable footprint: dependency weight, startup/runtime overhead, cognitive load and maintenance cost are justified.

An author conformance kit should exercise a plain-library sample, opt-in graph installation, exported schemas, one useful query/operation, a prevented counterexample, bounded observations and target evidence. One generated app and one existing consumer prove the early shared boundary. Later independent maintainers prove ecosystem extensibility. No separate marketplace, universal compiler or pane for every module is required to start.

Source findings that drive the first tasks

These are dated findings, not an instruction to overwrite concurrent fixes. Re-check the named source and existing tests when taking a task. If a finding has been resolved, close the task with current evidence and preserve its regression case instead of reimplementing it.

9. Complete Reaktor rating index

These values summarize the qualified judgments in the module entries. They should not be used without the platform and usage caveats above.

10. Evidence and coverage appendix

Inventory coverage

The following artifact inventory is generated from the checked source paths. File counts include authored code, examples and certain wrapper files, so they indicate scope rather than implementation quality. Test counts count files, including fixtures, not independent assertions or coverage. Generated/vendor content is excluded heuristically. Supporting systems outside these build directories are assessed separately above.

Follow-up verification and scope

The Astra follow-up freshly ran ./gradlew :reaktor-auth-core:jvmTest :reaktor-auth-core:verifyAuthCoreBoundary --console=plain: successful, two JVM cases, zero failures/errors/skips, and the boundary check executed. The log is retained as astra-followup/auth-core-checks.log. This supplements the initial checks below; it does not rerun the entire earlier matrix. The follow-up also rechecked module registration, auth dependencies, public/closed CLI boundaries, and the specific core/runtime/graph laws used to rank tasks. Other implementation evidence remains dated to the initial source scan.

The last inventory pass found reaktor-code, created while this assessment was being integrated. Its common contract, build boundary and actual UI/tooling/workbench consumers were inspected. ./gradlew :reaktor-code:jvmTest :reaktor-code:verifyCodeBoundary --console=plain succeeded: the boundary check executed, compilation was up to date, and jvmTest was NO-SOURCE. No new behavioral test pass is implied. Evidence is retained in astra-followup/code-checks.log.

Verification performed for this review

The selected framework and graph/platform tasks, kernel checks, and final focused workbench check completed successfully. This is a scoped result, not a clean full build of every advertised target. Gradle reused some existing test results. The report preserves those distinctions rather than describing every passing result as a newly executed test.

Two unsuccessful attempts also matter for interpreting these results. The first graph/platform invocation requested jvmTest on health/sensors, which do not register that target; the command was corrected to testDebugUnitTest. That task-selection error is not evidence of failing health/sensor behavior. The initial workbench invocation then failed compilation on limitBytes, DatabaseJvmClient, and WorkerJvmClient in Reaktor tooling. New infrastructure sources appeared while the review was running; the same focused workbench command was repeated after that source change and passed. No source fix was made by this review. Keep the workbench-focused-checks.log as evidence of this non-atomic working-tree sequence, not as a claim that the final rechecked path is still broken.

Reported test cases and execution status

The following case counts come from task XML, captured in verified-test-results.json. They count reported cases, including skips, and are not line/branch coverage or full-platform qualification. All listed XML reports had zero failures and errors when captured.

The skipped kernel case is configuredMemgraphReturnsRealCatalogAndPagedRecordsThroughDesktopSession, which requires explicit live-read opt-in. Therefore the suite does not establish successful access to a deployed Memgraph instance.

Scope not freshly qualified

This review did not execute a full release matrix, browser/JS integration suite, iOS/device suite, complete BestBuds app suite, FFI/MLS native conformance matrix, live auth/provider integration, production matching run, CI deployment, or live cloud inventory. Existing app test artifacts and older renderer/native failures supplied investigation leads; they were not treated as current universal pass/fail results. No new benchmark was run, so potential performance gains remain hypotheses.

Source drift and newly appearing infrastructure adapters

The closing comparison found 14 inventoried source files changed and eight newly appearing tooling source files; no inventoried source path had disappeared. source-drift.json records the comparison. The source/test counts above describe the initial inventory, so these additions are not silently folded into its denominators. The comparison and final checks themselves do not freeze future edits.

The new reaktor/reaktor-tooling/src/commonMain/kotlin/dev/shibasis/reaktor/tooling/infra/InfrastructureOperation.kt and reaktor/reaktor-tooling/src/jvmMain/kotlin/dev/shibasis/reaktor/tooling/infra/NativeExecution.kt add direct JVM Kubernetes, PostgreSQL/Memgraph/ClickHouse and authenticated Worker operations alongside supervised CLI execution. They include request fingerprints, definition checks, session-owned clients/tunnels, cancellation and output limits. Kernel planning/execution and connection sources were changing to consume these providers. This strengthens the direction proposed here: describe the effect independently of the transport, and let CLI and native providers return comparable evidence. Compilation in the final workbench recheck does not qualify their live behavior. The next gate is provider contract tests for read/effect classification, credential and environment scope, cancellation, bounded results, stale plans, and equivalent receipts across providers.

The stable finding is architectural: source inventory, operational definitions, runtime wiring and observations need explicit revisions and provenance. The changes during this review are themselves a useful demonstration of why one undated “green” module label would be misleading.

Primary architecture references

• Astra master plan: governing north star, scope and sequence.

• Module execution plan: five priority tasks per module/target.

• reaktor/AGENTS.md.

• bestbuds/AGENTS.md.

• Current workbench layer architecture.

• Canonical atlas: architecture intentions and implementation distinctions.

• Graph protocol: explicitly a specification.

• Data graph proposal.

• Conductor implementation and gaps.

External conceptual references

The recommendations in this report are engineering proposals grounded primarily in the local source. Three external references clarify vocabulary and mechanisms:

• Kivelä et al., Multilayer Networks: distinctions among multilayer and multiplex graph structures, used in section 2.
• W3C Shapes Constraint Language: prior art for typed graph constraints and validation reports, used in section 2; not a prescribed storage migration.
• OpenTelemetry Tracing API: span contexts and links for causal observations. A queued or batched action may link multiple causal spans rather than fit one parent tree; that informs the telemetry proposal.

No production records, secret values, user analytics, live cloud inventories, or private CompanyOS evidence payloads were exported for this review. Source evidence, current checks, historical artifacts, and proposed architecture remain distinct throughout.