What is the Neural Link?

The Neural Link is a bi-directional bridge that connects AI agents directly to the Neo.mjs runtime. It lets agents inspect the Scene Graph, component state, event listeners, computed styles, and DOM rectangles, and mutate the running application in real time.

Why is Neo.mjs called an Application Engine instead of a framework?

Neo.mjs maintains persistent application objects in a worker-backed Scene Graph instead of compiling application state away into ephemeral DOM nodes. That architecture enables multi-window orchestration, runtime permutation, and deep AI introspection.

What is Context Engineering?

Context Engineering shapes the information and tool environment around AI agents. Neo.mjs implements it through Knowledge Base, Memory Core, GitHub Workflow, and Neural Link MCP servers for frontier harnesses, plus a File System MCP server for internal Neo.ai.Agent local loops.

What is the Neo.mjs Agent OS?

The Neo.mjs Agent OS is the repository Brain: source code and services for Memory Core, Knowledge Base, Active Hybrid GraphRAG, DreamService, Golden Path synthesis, A2A coordination, and Neural Link tooling.

Frontmatter

id	9546
title	Refactor Pipeline IPC to use Declarative Remote Configs (Instance Proxies)
state	Closed
labels	enhancementaiarchitecturecore
assignees	tobiu
createdAt	Mar 24, 2026, 9:19 PM
updatedAt	Mar 24, 2026, 9:34 PM
githubUrl	https://github.com/neomjs/neo/issues/9546
author	tobiu
commentsCount	1
parentIssue	9449
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]
closedAt	Mar 24, 2026, 9:34 PM

Refactor Pipeline IPC to use Declarative Remote Configs (Instance Proxies)

Closed v12.1.0/archive-v12-1-0-chunk-2 enhancementaiarchitecturecore

tobiu commented on Mar 24, 2026, 9:19 PM

Goal

Refactor the Neo.data.Pipeline class to utilize the declarative remote configuration for instance-to-instance IPC, replacing the procedural on-the-fly proxy generation.

Context

In issue #9453, we implemented the initial IPC routing for pipelines by explicitly calling Neo.currentWorker.generateRemote inside the read, create, and update methods.

This approach is highly procedural and violates the elegant, declarative design patterns of the framework. Neo.mjs heavily relies on defining capabilities statically (e.g., static config = { remote: ... }) and letting the class system or mixins handle the wiring.

We need to adopt "Option C" (Explicit remote Namespace on Instances): Instead of generating the proxy dynamically on every call, the Pipeline should define its remote capabilities in its static config. The framework should then automatically populate a this.remote object on the instance with pre-bound proxy functions during construction.

Acceptance Criteria

Add remote: { data: ['create', 'read', 'update'] } to the static config of Neo.data.Pipeline.
Update the initRemote method in src/core/Base.mjs (or the RMA mixin) to properly handle remote configs for non-singleton instances. If a class is not a singleton, it should generate the proxies and attach them to a remote property on the instance, organized by destination (e.g., this.remote.data.read).
Refactor Neo.data.Pipeline to remove the manual generateRemote calls and instead invoke the pre-generated proxies via this.remote.data[operation]({ ...params, remoteId: this.remoteId }).
Ensure the unit tests for RemoteMethodAccess and StoreParser continue to pass with this declarative architecture.

tobiu Mar 24, 2026, 9:31 PM

Input from Gemini 3.1 Pro:

✦ I have refactored the Pipeline IPC architecture to use declarative remote configs, adhering to the highest code quality standards of core.Base.

Implementation Details:

Removed the Procedural Hacks: The generateRemote calls inside read and executeRemoteOrLocal have been removed from Pipeline.mjs. The pipeline now simply declares static config = { remote: { data: ['create', 'read', 'update'] } }.

core.Base.initRemote Enhancement:

I modified initRemote() to correctly handle non-singleton classes.

If a class is not a singleton, it now dynamically generates a this.remote object containing pre-bound proxy functions during instance construction.

These instance-level proxies are designed to resolve this.remoteId at execution time, perfectly accommodating the asynchronous "Handshake" pattern where the target ID is populated after the remote thread instantiates the counterpart.

Strict Promise Resolution: The user rightly pointed out that Base.promiseRemotes(className, remote) was only being called for singletons, which risked leaving the #remotesReadyPromise hanging. With the new implementation, non-singletons don't need to await global registration (registerRemote), so the synchronous population of the this.remote object allows the lifecycle to continue without blocking.

Knowledge Base Enhancements: The comments inside initRemote have been thoroughly updated using the Knowledge Base Enhancement Strategy. They clearly articulate the intent, differentiating "Singleton Routing (Namespace-Driven)" from "Instance-to-Instance Routing (ID-Driven)", and documenting the "Handshake" resolution pattern for future context.

The pipeline now executes cleanly via this.remote.data[operation](params), restoring the elegant DX of the Neo.mjs framework. I will close this sub-issue.

tobiu cross-referenced by #9547 on Mar 24, 2026, 10:18 PM