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	19773
title	Five-beat scene 2 has not reached its native return since 09-02
state	Closed
labels	bugaitestingdashboard
assignees	neo-opus-vega
createdAt	Oct 15, 2026, 9:00 PM
updatedAt	Oct 16, 2026, 12:15 AM
githubUrl	https://github.com/neomjs/neo/issues/19773
author	neo-opus-vega
commentsCount	0
parentIssue	16498
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]
closedAt	Oct 16, 2026, 12:15 AM

Five-beat scene 2 has not reached its native return since 09-02

Closed Backlog/active-chunk-9 bugaitestingdashboard

neo-opus-vega commented on Oct 15, 2026, 9:00 PM

Sub of #16498. Discharging it needs this scene run headed while the operator watches the return, and right now the run never gets that far.

Context

Headed on the operator's display, 2026-10-15 18:52–19:22Z. The #16756 place-cycle arm passed; its receipt is on #16498. WorkstationFiveBeatNL.spec.mjs → scene 2 (native titlebar) failed at one gate after another. Each one showed up only after the one before it was cleared:

run	head / change	red
1	`298ef00ff2`, natural landing	`boot()` → `assertStageGeometryPublished` (`:371`): parity 87 > 2
2	same, `NEO_FILM_DISPLAY_BOUNDS=2156,60,1920,1080`	same, 87
3	local oracle patch (Fix 1)	parity passes for all three windows; then `movedPromise` (`:2231`) times out after 15 s because the popup never moved
4	same, module cache warm	native drag runs; then `:2357` reports `unknown item "metrics"`
5	`b392a7444f`, module cache deleted first	the moved check passes on a cold cache (down→up 925 ms); then the `:2379` catalog has no `metrics`
6	`c8f078691d`, transfer oracle (Fix 3)	the return commits as predicted (`:2412`), then a proxy residue at `:2451`. The operator saw no drop zone, and the popup's top-left corner sat outside the main body: gate 4a
8	`c009e2edfb`, corner aim	an edge-right preview is accepted and the return commits; residue → #19775. The operator saw the arrows away from the corner: gate 4b
9	aim probe	the cross centres exactly on the aimed box (878, 209), but the popup moved −60 px in x for a −154 px hand move. A plain Chrome popup reproduces this with an opener under the path, and drags exactly without one
10	`e4bc26c85a` + #19779's fix	closed-loop hand: `corrections: 1`, the corner lands within 0.25 px; scene 2 passes end-to-end (10.0 s)

The Problem

The scene only runs headed, on darwin, with NEO_FILM_TAKE=1, so no CI tier ever runs it. That let four gates drift without anyone noticing. All four are test-side.

The parity oracle compares two different origins. readBrowserSurface (test/playwright/e2e/utils/filmStage.mjs) records inner.x/y = screenX/screenY, which is the frame origin. Since #18068 (09-02), manager.Window.calculateGeometry has published innerRect at the viewport origin. The two differ by the chrome height, 87 px here.
The moved-window timer started before the gesture did. The drag's swift -e compile ran inside the 15 s moved and retained witnesses. With a cold module cache, the compile used up the whole window.
The return was modelled as a placement inside main. Since #18677 (09-14), VesselWorkspace#onTearOutDocumentChange has moved a torn-out pane into the vessel's own workspace with transferItem, so main's catalog drops the record by design. Scene 1 already asserts that ownership (:1718).
The hand did not deliver the corner.
- 4a: Since #18059 (09-02), the native drop has anchored on the popup's outer top-left corner (inset nativeWindowDropAnchorInset). The coordinator's JSDoc rejects the centre because it "hid every drop target under the popup", yet the hand aimed the centre.
- 4b: Even when aimed at the corner, an open-loop hand falls short. The window server resists a popup whose edge meets another window's edge, which absorbed 94 px of x. A human hand corrects by eye, so the swift hand now does too.

The Architectural Reality

Design authority:

Gate 1: the src/manager/Window.mjs calculateGeometry JSDoc says "outerRect is therefore the frame itself and innerRect the frame shifted by the chrome."
Gate 3: the VesselWorkspace#onTearOutDocumentChange summary says "Admits a full popup Workspace and transfers its pane through one Group transaction."
Gate 4: the DragCoordinator#nativeWindowDropAnchorInset JSDoc says "a corner exposes two sides of the selected region and tracks the hand on the titlebar."

Decision Record impact: none. All four fixes are test-only.

The Fix

assertStageGeometryPublished compares outerRect.x/y with the observed frame origin, and innerRect.width/height with the observed inner size (c33f11d96e).
warmNativeInput() pays for the swift compile before any timed witness opens, and fails fast without HID access. nativeInputEnv() is the one environment both scripts share (b392a7444f).
The oracle reads the vessel document beside the main one before the return, and validates the landing as the transferItem out of the vessel (c8f078691d).
The hand brings the popup's corner anchor onto the hit-tested target point, with the inset read live from the coordinator (ee96513390, c009e2edfb). It then reads the frame back and corrects until the corner lands, reporting the landing (e4bc26c85a).

Acceptance Criteria

Gate 1: on a headed run, precondition parity is ≤ 2 for every staged window (runs 3–6).
Gate 2: the scene passes the moved check with a cold module cache (run 5, with the cache directory deleted before the run).
Gate 3 is classified with a receipt (run 5's catalog plus the vessel's ownership contract), and the instrument is fixed to match.
One headed run, aiming the corner anchor, reaches the native return and passes it while the operator watches (run 10, which needs #19779's fix for the cleanup check). This is #16498's human-QA arm.

Out of Scope

#16498's own code; the place-cycle arm is green.
Hosted CI for this headed scene. #19655 owns the headless tier.

#16498 (parent) · #18068 (geometry) · #18677 (vessel ownership) · #18059 (corner anchor) · #19775 (withdrawn: off-contract gesture) · #19533 · #19655 · #15252

Sweeps: live latest-20 open at 18:58:35Z, no equivalent. Keyword sweeps film-stage geometry / manager.Window parity / five-beat scene 2 / swift module cache found nothing open. A2A last 30: no overlapping claim. Own assignments: #16498 is the only one on this surface. MC rationale sweep: no prior decision on the parity oracle.

Origin Session ID: d224fd7e-cf9a-4197-8413-2871327ec30b Retrieval Hint: "five-beat scene 2 parity oracle corner anchor native return"

tobiu referenced in commit 4e796bb - "test(workstation): scene 2 reaches its native return again (#19773) (#19776) on Oct 16, 2026, 12:15 AM

tobiu closed this issue on Oct 16, 2026, 12:15 AM