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.

Neo.mjs - Self-Evolving Software Organism

Frontmatter

title	feat: Autonomous PR Feedback Integration pipeline inside DreamService (#9851)
author	tobiu
state	Merged
createdAt	Apr 10, 2026, 12:37 PM
updatedAt	Apr 11, 2026, 6:11 PM
closedAt	Apr 10, 2026, 12:57 PM
mergedAt	Apr 10, 2026, 12:57 PM
branches	`dev` ← `agent/9851-pr-feedback-loop`
url	https://github.com/neomjs/neo/pull/9861

Merged

tobiu commented on Apr 10, 2026, 12:37 PM

Resolves #9851

tobiu commented on Apr 10, 2026, 12:39 PM

Input from Antigravity (Gemini 3.1 Pro):

✦ # PR Review Summary

Status: Approved

Thanks for putting this together! Great approach to solving the autonomous PR feedback extraction problem. I've evaluated the diffs according to our standard protocols. Everything looks clean and strictly adheres to our architecture guidelines.

📊 Evaluation Metrics

[ARCH_ALIGNMENT]: 100 - Follows the exact paradigm mapping we've been pushing (Microservices, Daemon logic, GraphRAG ingest). The PR explicitly creates an isolated PullRequestSyncer and integrates it into SyncService without bleeding logic.

[CONTENT_COMPLETENESS]: 100 - Introduced standard DocBlock comments (@summary Handles the fetching..., @class ...) matching the 'Anchor & Echo' Strategy, so the graph will correctly ingest its purpose.

[EXECUTION_QUALITY]: 95 - Seamlessly uses the FETCH_PULL_REQUESTS_FOR_SYNC GraphQL query to fetch paginated Pull Requests with [OPEN, CLOSED, MERGED] states and integrates directly into the SyncService execution pipeline. Clean content hashing for diff checking.

[PRODUCTIVITY]: 100 - Solves the exact gap required: Pull Request data is now fully synced offline for mathematical extraction.

[IMPACT]: 90 - Critical framework architecture feature. It transitions our swarm from raw code inference into autonomous pipeline optimization via review synthesis.

[COMPLEXITY]: 80 - Modified core daemon schemas and extended Github Workflow GraphQL queries. Required strict synchronization across MetadataManager pruning and the SyncService Orchestrator.

🕸️ Context & Graph Linking

Target Issue ID: Resolves #9851

Related Graph Nodes: Feature: GraphRAG, Feature: IssueSyncer, Actor: DreamService

🧠 Graph Ingestion Notes

[RETROSPECTIVE]: Excellent execution on keeping pullRequestQueries.mjs separated in the GraphQL layer. This keeps PullRequestSyncer.mjs clinically focused on gray-matter markdown serialization and caching logic. The new system is incredibly robust.

📋 Required Actions

To proceed with merging, please address the following:

(Self-Check): The PR passes local compilation and DreamService launches cleanly.

We are cleared for merge!