What is the 'Neural Link'?

The Neural Link is a bi-directional bridge that connects AI agents (like Gemini or Claude) directly to the Neo.mjs runtime. It allows agents to 'see' the application's Scene Graph, inspect component state, verify event listeners, and even mutate the running application in real-time. This turns the application into a 'glass box' for AI, enabling autonomous debugging and feature development.

Why is Neo.mjs called an 'Application Engine' instead of a framework?

Traditional frameworks are general-purpose libraries (like a Toyota) that help you organize code, but they compile away into ephemeral DOM nodes. Neo.mjs is a precision-engineered runtime (like an F1 car), similar to Unreal Engine for games. It maintains a persistent 'Scene Graph' of objects in a separate worker thread. These objects retain their identity, state, and relationships, allowing for advanced capabilities like multi-window orchestration, runtime permutation, and deep AI introspection that are impossible with 'melted plastic' DOM-based frameworks.

What is 'Context Engineering'?

Context Engineering is the practice of curating the environment and information flow for AI agents to maximize their autonomy. In Neo.mjs, this is implemented via three Model Context Protocol (MCP) servers: a Knowledge Base for semantic code understanding, a Memory Core for learning from past sessions, and a GitHub Workflow server for project management. This ecosystem allows agents to work as fully integrated members of the development team.

What is 'Object Permanence' in the context of Neo.mjs?

In Neo.mjs, UI components are persistent JavaScript objects living in the App Worker, not just transient rendering results. This 'Object Permanence' means a component (like a Dashboard) maintains its state (scroll position, user input, internal logic) even if it is detached from the DOM or moved to a different browser window. This is the 'Lego Technic' approach versus the 'Duplo' approach of traditional frameworks.

What is an 'Agent Operating System'?

Neo.mjs v11 introduced the concept of an Agent OS, where the platform itself provides the tools and interfaces for AI agents to operate. It combines a standalone, type-safe AI SDK for autonomous 'Code Execution' with the Neural Link for runtime control. This enables agents to monitor, debug, and heal the application autonomously, effectively acting as an operating system for synthetic intelligence.

How does Neo.mjs handle multi-window applications?

Neo.mjs uses shared web workers to run a single application instance across multiple browser windows. All windows share the same application state and data in real-time. Components can even move between windows while retaining their JavaScript instances. This enables desktop-class experiences like multi-window IDEs, browser-based email clients, and multi-screen control rooms.

What makes Neo.mjs different from React, Angular, or Vue?

Neo.mjs is fundamentally different in its architecture: (1) It uses True Multithreading via web workers to prevent UI jank, (2) It is an AI-Native Application Engine with built-in bridges for AI collaboration, and (3) It treats components as persistent objects in a Scene Graph, enabling native multi-window support and runtime permutation.

Frontmatter

id	11895
title	Require next-lane pickup while CI is pending
state	Closed
labels	documentationenhancementaiarchitecturemodel-experience
assignees	neo-gpt
createdAt	May 24, 2026, 2:14 PM
updatedAt	May 24, 2026, 2:40 PM
githubUrl	https://github.com/neomjs/neo/issues/11895
author	neo-gpt
commentsCount	0
parentIssue	11605
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	May 24, 2026, 2:40 PM

Require next-lane pickup while CI is pending

Name: Neo.mjs Application Engine
Author: Neo.mjs

Closeddocumentationenhancementaiarchitecturemodel-experience

neo-gpt commented on May 24, 2026, 2:14 PM

Context

Operator friction surfaced on 2026-05-24 during PR #11894: after opening a PR, CI can sit pending for several minutes (integration-unified took 6m53s on #11894). The current author-side review routing correctly forbids requesting /pr-review before green CI, but its pending-CI branch still permits an observer/no-action hold if no quick peer-unblock lane is found inside the current turn.

This is a narrow follow-up to #11467 and the #11891/#11893 lifecycle-compression work. It should not reopen the review-routing architecture or add another broad workflow layer.

Duplicate Sweep

Knowledge Base semantic ticket query failed with Error finding id, so exact repo sweeps were used.

Related but not duplicate:

#11467 created the current author-side CI-green review routing rule. It explicitly covers pending CI and says to use the wait window productively, but it still allows stopping in an observer/no-action hold while checks remain pending.
#10970, #11165, #11221, and #11455 codify next-lane / no-idle discipline after lifecycle events, but they do not specifically close the CI-pending wait-window loophole inside ci-green-review-routing.md.
#11893 / PR #11894 compresses PR-review hot-path bloat; this ticket is a tiny behavioral clarification in the adjacent pull-request routing payload.

The Problem

The current ci-green-review-routing.md pending branch has the right first half and the wrong terminal affordance:

Correct: do not call manage_pr_reviewers while CI is pending.
Correct: do not send actionable /pr-review A2A before green CI.
Correct: send a no-action lifecycle notification so the swarm sees the PR exists.
Weak: if checks are still pending and no quick peer-unblock lane appears, the author may leave the PR in observer/no-action hold and stop.

That stop path contradicts the nightshift and post-review-pickup direction: pending CI is asynchronous work owned by GitHub Actions, not a human-only blocker and not a reason for the agent to idle. The author should park a recheck obligation and pick the next positive-ROI lane.

Architectural Reality

Primary surfaces:

.agents/skills/pull-request/references/ci-green-review-routing.md
.agents/skills/post-review-pickup/references/post-review-pickup-workflow.md
.agents/skills/pull-request/references/pull-request-workflow.md §6.2 pointer

No new skill, no new audit file, no AGENTS.md expansion.

The Fix

Amend the pending-CI branch to make CI wait windows explicitly asynchronous:

Keep the no-action PR-open lifecycle notification while CI is pending.
Replace the observer/no-action terminal stop with an explicit next-lane requirement.
Require authors to record/rely on a concrete recheck trigger: watchdog heartbeat, next turn, or after completing the next short lane.
Preserve the green-CI gate: actionable reviewer assignment and /pr-review A2A still wait until current-head CI is green.
Add an anti-pattern row for waiting on long-running CI instead of parking a recheck and picking up the next lane.

Contract Ledger Matrix

Target Surface	Source of Authority	Proposed Behavior	Fallback	Docs	Evidence
Pending-CI author routing	This ticket + #11467 + post-review-pickup no-idle discipline	Pending CI parks reviewer routing, posts no-action visibility, then requires next-lane pickup or a named external blocker	If CI fails, author returns and fixes before review request	`ci-green-review-routing.md`	Text diff + skill-manifest lint
Review request timing	Existing CI-green gate	Reviewer assignment remains green-only	CI-triage route remains available on failure	same payload	Grep confirms no early `/pr-review` request path
Lifecycle pickup	#11455 / post-review-pickup	PR-open with pending CI is not a halt-state by itself	Legit halt only after backlog self-survey hits an existing formal halt criterion	`post-review-pickup-workflow.md` if needed	Text diff and no new substrate file

Decision Record Impact

Aligned with ADR 0007 / ADR 0008: this is an in-place workflow payload rewrite, not a new rule surface. Disposition: rewrite of existing CI-routing prose, with no new file.

Acceptance Criteria

AC1: ci-green-review-routing.md pending-CI branch no longer allows an observer/no-action stop solely because checks are still pending.
AC2: Pending CI explicitly tells authors to park a recheck obligation and pick up the next positive-ROI lane, review request, or backlog ticket.
AC3: Green-CI reviewer routing remains unchanged: exactly one primary reviewer via GitHub reviewer request plus one targeted A2A after current-head checks pass.
AC4: Failing-CI path remains unchanged: no formal review request; author fixes or routes CI-triage only if explicitly needed.
AC5: No new skill, no new audit file, no AGENTS.md expansion.
AC6: node ai/scripts/lint/lint-skill-manifest.mjs --base origin/dev passes.

Out of Scope

No changes to reviewer-side CI fail-fast rules.
No changes to GitHub Actions runtime.
No reviewer auto-assignment before green CI.
No broad rewrite of pull-request workflow.

Avoided Traps

Rejected: requesting review before CI is green. That wakes a reviewer into mandatory hold work.
Rejected: waiting synchronously for long CI. That burns agent focus while GitHub Actions owns the work.
Rejected: adding another lifecycle skill. The existing CI-routing payload owns this narrow branch.

Parent compression line: #11605
Related: #11467, #10970, #11165, #11221, #11455, #11891, #11893, PR #11894

Origin Session ID: 967e325b-d90a-43f4-9e91-c212e9bda746

Handoff Retrieval Hints:

Query Memory Core for CI pending review routing observer no-action hold next lane integration-unified.
Exact payload: .agents/skills/pull-request/references/ci-green-review-routing.md.

tobiu referenced in commit 9c68581 - "docs(pull-request): require next-lane pickup during pending CI (#11895) (#11896) on May 24, 2026, 2:40 PM

tobiu closed this issue on May 24, 2026, 2:40 PM