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	14815
title	Keeper external create_component parity proof
state	Open
labels	enhancementaitestingnot-code-readydeferred-by-design
assignees	[]
createdAt	8:12 PM
updatedAt	8:50 PM
githubUrl	https://github.com/neomjs/neo/issues/14815
author	neo-gpt
commentsCount	1
parentIssue	14783
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]

Keeper external create_component parity proof

Open Backlog/active-chunk-4 enhancementaitestingnot-code-readydeferred-by-design

neo-gpt commented on 8:12 PM

Context

Issue #14783 requires the Neural Link capability matrix to name v13.2+ gap entries and ensure each gap is filed as a leaf before the matrix merges. The tour-runner gap is already covered by #14640. The remaining explicit gap is the keeper parity boundary recorded in #14765: keeper-created instances get pane chrome in that lane, while external Neural Link create_component inserts intentionally stay bare in v1.

This ticket makes that boundary executable instead of tribal: the implementation must prove whether external create_component inserts should remain bare, gain a registration bridge, or expose a separate handoff path.

The Problem

The keeper creation pipeline and the Neural Link create_component tool both materialize live components, but they do not currently promise the same product affordances. #14765 deliberately scopes pane chrome to keeper-created instances and names external/NL-created chrome as a recorded follow-up. Without a parity proof, later journey work can assume the wrong thing: either treating an external NL insert as keeper-owned when it is not, or preserving a bare insert when the product journey expects keeper chrome.

The Architectural Reality

create_component is a Neural Link write-locked tool in ai/mcp/server/neural-link/openapi.yaml, dispatched through ComponentService.createComponent.
Keeper materialization owns registry provenance, title binding, dispose, promote, and paneRef semantics in the #14765 lane.
The safe boundary is not a hidden equivalence. External NL insertion has no keeper provenance stamp today; the parity decision must be explicit and test-backed.

The Fix

Add the smallest proof lane that compares keeper-created and external-NL-created materialization:

Build a focused fixture or test rig that creates one keeper-owned component and one external create_component insert into the same stage/root.
Assert the current boundary explicitly: which one receives keeper chrome/registry affordances, which one does not, and why.
If product parity is required, add the narrow registration/handoff path that converts an external NL insert into a keeper-owned record; otherwise document the boundary in the keeper/Neural Link reference surface.
Feed the outcome back into the Neural Link capability matrix so the create_component row and gap section stay truthful.

Contract Ledger Matrix

Target Surface	Source of Authority	Proposed Behavior	Fallback	Docs	Evidence
`create_component` external insert	`ai/mcp/server/neural-link/openapi.yaml` + `ComponentService.createComponent`	Creates a live component without silently claiming keeper provenance	Structured tool error on invalid config/target	Neural Link capability matrix	Unit/e2e proof for external insert boundary
Keeper materialized pane	#14765	Registry-owned instances receive title/dispose/promote chrome	Bare render if no keeper ownership exists	Keeper docs or matrix notes	Parity fixture compares keeper vs external insert

Decision Record impact

none. This is a parity/proof leaf under the existing keeper and Neural Link architecture; it does not amend an ADR.

Acceptance Criteria

A focused proof creates both a keeper-owned component and an external create_component insert against the same materialization surface.
The test asserts the exact chrome/registry/provenance difference, including title, dispose, promote, and paneRef behavior where applicable.
If external NL inserts are meant to gain keeper ownership, the registration path is explicit, validates the same safety invariants, and does not bypass keeper registry truth.
If external NL inserts intentionally remain bare, the boundary is documented and linked from the Neural Link capability matrix.
The #14783 matrix gap section points to this ticket and no longer carries an unfiled keeper parity gap.

Out of Scope

Changing create_component schema vocabulary · broad keeper UX redesign · implementing tour-runner primitives (covered by #14640) · generic dock operation parity.

Avoided Traps

Do not make create_component silently mint keeper registry state just because the rendered outcome looks similar. Provenance is the contract; if parity exists, the handoff must be explicit and test-backed.

Parent matrix: #14783. Existing recorded boundary: #14765. Keeper live-generation consumer: #14762. Tour-runner gap already filed: #14640.

Live latest-open sweep: checked latest 20 open issues at 2026-07-04T18:11:39Z; no equivalent keeper external create_component parity ticket found. A2A in-flight sweep: checked last 30 messages at 2026-07-04T18:11:39Z; no competing claim for this scope.

Origin Session ID: 6439a7c5-5f2f-4658-9226-835c317c7a0b Retrieval Hint: "keeper external create_component parity chrome provenance registry handoff"