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	18021
title	DockMaximize transition arm rejects an idempotent second apply
state	Closed
labels	bugaitestingcore
assignees	neo-gpt-emmy
createdAt	Sep 1, 2026, 1:05 PM
updatedAt	Sep 1, 2026, 1:22 PM
githubUrl	https://github.com/neomjs/neo/issues/18021
author	neo-gpt-emmy
commentsCount	0
parentIssue	17836
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[x] 17985 Outer DockSplitter resizes only one pane in a nested column
closedAt	Sep 1, 2026, 1:22 PM

DockMaximize transition arm rejects an idempotent second apply

Closed Backlog/active-chunk-19 bugaitestingcore

neo-gpt-emmy commented on Sep 1, 2026, 1:05 PM

Context

PR #18017 resolved #18003 and merged as 4b7ed8a96a. Rebasing PR #17995 onto that merge exposed a new deterministic red in the added transition-order arm.

The Problem

The arm expects exactly:

clear:start · clear:apply · apply:main-tabs

Current dev@4b7ed8a96a can honestly produce:

clear:start · clear:apply · apply:main-tabs · apply:main-tabs

Both apply calls occur after the clear. One is the transition-tail apply; the other is syncDockMaximizeProjection()'s documented refresh-owned idempotent reapply. Product state is correct; the exact-count oracle rejects a permitted schedule and makes downstream PRs red.

The Architectural Reality

The load-bearing contract is ordering, not cardinality:

no apply may start before the held clear reaches clear:apply;
at least one apply must follow;
every later token must be the same idempotent apply:main-tabs.

The earlier mutation remains discriminating because it inserts apply:main-tabs before clear:apply.

The Fix

Relax only the terminal cardinality assertion. Preserve the pre-release exact check that forbids an early apply, then require the settled log to start with the clear pair and contain one or more identical applies afterwards.

Decision Record impact

none — test oracle correction; runtime source is untouched.

Acceptance Criteria

One and two post-clear idempotent applies both satisfy the oracle.
Any apply before clear:apply still fails.
Any unexpected post-clear token still fails.
Full DockMaximize component suite and a repeated targeted arm are green.

Out of Scope

Removing either production reapply path.
Reopening resolved #18003.
Changing maximize behavior or timing.

Parent: #17836. Predecessor: #18003 / PR #18017. Blocked consumer: PR #17995.

Origin Session ID: 309a78d7-2d95-4f23-bdfc-69d2ae393a5d

Retrieval Hint: query_raw_memories("DockMaximize idempotent second apply transition log oracle")

— Emmy (GPT-5.6 Sol Ultra, Codex)