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	13120
title	Relocate the dock-zone subsystem to src/ (reusable Neo layout topic)
state	Closed
labels	enhancementairefactoringarchitecture
assignees	neo-opus-ada
createdAt	Jun 13, 2026, 9:02 PM
updatedAt	Jun 14, 2026, 12:42 AM
githubUrl	https://github.com/neomjs/neo/issues/13120
author	neo-opus-ada
commentsCount	0
parentIssue	13030
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	Jun 14, 2026, 12:42 AM

Relocate the dock-zone subsystem to src/ (reusable Neo layout topic)

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

neo-opus-ada commented on Jun 13, 2026, 9:02 PM

Context

Operator direction (2026-06-13, reviewing PR #13116): "dock zones sounds more like a neo layout topic, and should be available to other apps => src folder." This is the out-of-scope follow-up to the docking-line PRs, and it resolves the placement-coherence question the line surfaced.

Release classification: boardless — harness/dashboard line refactor, not a v13 release blocker.

The Problem

The dock-zone subsystem currently lives split across hemispheres:

model: AgentOS.dock.DockZoneModel in apps/agentos/dock/ (PR #13116, #13115)
adapter: Neo.dashboard.DockLayoutAdapter in src/dashboard/ (PR #13107, #13105)

Root cause: learn/agentos/HarnessDockZoneModel.md is internally inconsistent on ownership — the decision-tree (line ~35) says "place the adapter in the harness app layer", while the Split/Tab Adapter Boundary (line ~289) says "ownership starts in the Agent Harness / dashboard layer." The two PRs each followed a different line, producing the split. @neo-opus-vega's #13107 RA1 flagged the adapter placement specifically.

The Architectural Reality

The dock-zone model + adapter are reusable docking primitives, not harness-specific UI — the contract's own Demand Validation names the Portal learning workspace as the candidate second consumer; the harness is merely the first. They are pure-JSON / config-projection logic with no apps/agentos coupling. So the operator's call — a Neo layout topic in src/, available to other apps — is the correct durable home, and it makes the harness app a consumer of the subsystem rather than its owner.

The Fix

Move AgentOS.dock.DockZoneModel (apps/agentos/dock/DockZoneModel.mjs) into src/, renamed to the Neo.* namespace (Neo.dashboard.DockZoneModel to co-locate with the adapter, or Neo.dock.DockZoneModel if the subsystem warrants its own home).
Confirm/co-locate Neo.dashboard.DockLayoutAdapter in the same src/ home.
Run structural-pre-flight to choose the exact sub-location (src/dashboard/ to match the adapter, vs a new src/dock/); record the decision.
Reconcile learn/agentos/HarnessDockZoneModel.md's ownership inconsistency to bless the single src/ home (the line ~35 / ~289 contradiction).
Relocate the unit spec (test/playwright/unit/apps/agentos/dock/ → the matching test/playwright/unit/.../) and update imports / references.

Pure relocation + contract-doc reconciliation — no behavior change.

Contract Ledger Matrix

Target Surface	Source of Authority	Proposed Behavior	Fallback	Evidence
`DockZoneModel` namespace/location	operator direction + `HarnessDockZoneModel.md` (reconciled)	Moves to `src/` under `Neo.*`; behavior identical	If a sub-location is contested, structural-pre-flight rationale recorded in the PR	Relocated unit spec passes unchanged
`HarnessDockZoneModel.md` ownership boundary	this ticket	Single `src/` home; the ~35/~289 contradiction removed	n/a	Doc diff + the two PRs cite the reconciled boundary

Decision Record impact

aligned-with ADR 0020; amends learn/agentos/HarnessDockZoneModel.md (reconciles the ownership-decision inconsistency to a single src/ home).

Acceptance Criteria

DockZoneModel lives under src/ in the Neo.* namespace, co-located with DockLayoutAdapter; structural-pre-flight decision recorded.
HarnessDockZoneModel.md ownership guidance is internally consistent and names the single src/ home.
The relocated unit spec passes unchanged (behavior identical); imports/references updated.
Resolves @neo-opus-vega's #13107 RA1 placement concern (cite this ticket in #13107).

Out of Scope

Any behavior change to the model/adapter (pure relocation + doc reconciliation).
The drag-time producer and the live workspace integration (separate docking leaves).

Sequencing

Do after PR #13116 (model) and PR #13107 (adapter) merge — relocating before they land would churn open PRs. Until then this stays parked.

Parent: #13030. Refs #13012, #13115, #13116, #13105, #13107. Source of authority: learn/agentos/HarnessDockZoneModel.md.

Origin Session ID: 4c598c8f-d8a7-4288-9420-e825a45d310e Retrieval Hint: "relocate dock-zone subsystem src DockZoneModel DockLayoutAdapter reusable layout HarnessDockZoneModel ownership reconcile"