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	13185
title	create_component — multi-window e2e (direct AC1: shared-worker per-window targeting proof)
state	Closed
labels	enhancementaitesting
assignees	neo-opus-vega
createdAt	Jun 14, 2026, 5:52 AM
updatedAt	Jun 14, 2026, 9:58 AM
githubUrl	https://github.com/neomjs/neo/issues/13185
author	neo-opus-vega
commentsCount	2
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	Jun 14, 2026, 9:58 AM

create_component — multi-window e2e (direct AC1: shared-worker per-window targeting proof)

Closed v13.1.0/archive-v13-1-0-chunk-2 enhancementaitesting

neo-opus-vega commented on Jun 14, 2026, 5:52 AM

Context

Split from #13157 per @neo-gpt's #13183 review (AC1 close-target/evidence audit). #13157's AC2 (get_component_tree visibility) + AC3 (single-window E2E) are delivered in #13183; this carries the remaining AC1: a direct multi-window proof.

Release classification: boardless — belt-and-suspenders (the mechanism is already sound by composition), not release-blocking.

The Problem

#13183's e2e runs /examples/button/base with isSharedWorker:false (single-window). AC1 — "multi-window targeting works when useSharedWorkers: true" — is covered by composition (create_component delegates to the window-agnostic, id-based call_method; component ids are globally unique across the single shared App Worker; so a create targeting parentId reuses the App Worker's existing per-window delta routing — no create_component-specific multi-window code). That argument is sound but not directly e2e-proven.

The Fix

A direct L3 proof: in a shared-worker multi-window app (template test/playwright/e2e/LivePreviewMultiWindow.spec.mjs for the 2nd-window / popout orchestration), create_component into a container that lives in window 2 (by its globally-unique parentId), and assert it renders in window 2's DOM (not window 1).

Acceptance Criteria

A shared-worker (isSharedWorker:true) multi-window e2e creates a component via create_component targeting a window-2 container's parentId.
The created component renders in window 2 (its parent's window), confirmed via the DOM and/or get_component_tree.

Related: #13157, #13183, #9846

Origin Session ID: 4cc428e3-cf36-4324-8646-1b96cb23fa4a