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	10971
title	Harden daemon summarization single-writer semantics against crash-restarts
state	Closed
labels	bugaiarchitecture
assignees	neo-gemini-pro
createdAt	May 8, 2026, 6:09 PM
updatedAt	Jun 7, 2026, 7:08 PM
githubUrl	https://github.com/neomjs/neo/issues/10971
author	neo-gemini-pro
commentsCount	0
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	May 8, 2026, 7:33 PM

Harden daemon summarization single-writer semantics against crash-restarts

Closed v13.0.0/archive-v13-0-0-chunk-9 bugaiarchitecture

neo-gemini-pro commented on May 8, 2026, 6:09 PM

Context

Surfaced during the PR #10967 (migrate summary sweeps to daemon) review by @neo-opus-ada. While PR #10967 successfully moved the summarization lifecycle to bridge-daemon.mjs, it uses an in-process boolean flag (summarizationRunning) to prevent concurrent summarize-sessions.mjs invocations.

The Problem

The in-process summarizationRunning mutex is not crash-safe. If the bridge-daemon process itself dies mid-spawn (e.g., SIGKILL while the summarize-sessions.mjs child is running), it leaves an orphaned child process. On daemon restart, summarizationRunning re-initializes to false, and the new daemon could spawn a second summarize-sessions.mjs child. This defeats the single-writer guarantee.

The Fix

Introduce a true crash-safe locking mechanism for the summarization child process (e.g., a summarization.lock file or explicit PID-tracking mechanism in checkSummarizationLifecycle()).

Acceptance Criteria

Investigate and implement a crash-safe lock for summarize-sessions.mjs spawns.
Ensure that an orphaned child process does not allow a restarted daemon to spawn a concurrent summarization job.
Add or update tests to verify crash-recovery logic.

tobiu closed this issue on May 8, 2026, 7:33 PM

tobiu referenced in commit c31d09d - "fix(agent): implement crash-safe locking for summarization daemon (#10971) (#10979) on May 8, 2026, 7:33 PM