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	11467
title	Delay PR review requests until CI is green
state	Closed
labels	documentationenhancementaiagent-task:reviewarchitecturemodel-experience
assignees	neo-gpt
createdAt	May 16, 2026, 5:06 PM
updatedAt	May 16, 2026, 5:31 PM
githubUrl	https://github.com/neomjs/neo/issues/11467
author	neo-gpt
commentsCount	0
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	May 16, 2026, 5:31 PM

Delay PR review requests until CI is green

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

Closeddocumentationenhancementaiagent-task:reviewarchitecturemodel-experience

neo-gpt commented on May 16, 2026, 5:06 PM

Context

PR #11466 / issue #11465 merged the reviewer-side CI fail-fast rule into pr-review: reviewers now verify gh pr checks <N> before full review, hold while checks are pending, and stop before formal review when checks are failing. The next friction surfaced immediately on the author side: pull-request still tells PR authors to assign a primary reviewer and send an actionable /pr-review wake immediately after opening the PR.

V-B-A performed before filing:

gh pr view 11466 --json state,mergedAt,title,reviewDecision confirmed #11466 is merged and approved.
.agents/skills/pr-review/audits/ci-security-audit.md:10-14 says pending checks must hold review and failing checks must stop before formal review.
.agents/skills/pull-request/references/pull-request-workflow.md:229-237 still says authors immediately route a review request, call manage_pr_reviewers, and send an actionable primary-reviewer A2A ping.
Duplicate sweep found adjacent but non-equivalent surfaces: #10905 / Discussion #11237 / #11465 are reviewer-side CI gates; this ticket is author-side review-request timing.

The Problem

The current author-side handoff wakes a peer into a PR state where the peer is now required to do no full review if CI is pending or red. That creates avoidable context switches, review churn, and repeated re-check loops.

The naive fix, however, is also wrong: delaying all notification until CI is green would violate the mandatory lifecycle A2A notification rule and hide that a PR was opened. The substrate needs a split between visibility and actionability:

PR opened + CI pending = no-action observer/lifecycle notification.
CI green on the current head = targeted primary-reviewer request plus GitHub reviewer assignment.
CI failing = author fixes first; no formal review request except a clearly scoped CI-triage ask.

The Architectural Reality

pull-request owns author-side PR creation and review-routing behavior.
pr-review owns reviewer-side acceptance/hold/fail-fast behavior.
manage_pr_reviewers is not just metadata; it is GitHub's actionable review-request surface and should not be fired before the reviewer can productively act.
add_message remains mandatory for lifecycle events, so the PR-open notification must remain, but its Requested action and Review role semantics need to distinguish observer/no-action from primary-reviewer/actionable.
Progressive Disclosure applies: the main pull-request-workflow.md should keep a short routing rule, while the detailed CI-wait/use-time/recheck flow belongs in a sibling payload rather than bloating the workflow map.

The Fix

Update the pull-request skill so author-side review routing waits for green CI before creating an actionable peer review request.

Proposed shape:

Add a compact trigger/pointer in .agents/skills/pull-request/references/pull-request-workflow.md near §6.2.
Add a sibling payload such as .agents/skills/pull-request/references/ci-green-review-routing.md with the detailed author-side flow.
Require authors to run gh pr checks <N> or an equivalent current-head GitHub status query after PR creation and before calling manage_pr_reviewers.
If checks are pending, send only a no-action lifecycle/observer A2A note and use the wait window to handle open peer review requests or unblock peers, then re-check the author's PR CI.
If checks fail, do not request formal review; fix CI first and repeat the current-head check after pushing.
If checks pass, choose exactly one primary reviewer, call manage_pr_reviewers, and send the existing targeted /pr-review A2A request.
Preserve explicit exceptions for CI-triage requests, likely infrastructure flakes, P0/human override, and unusually long-running checks, without letting those exceptions become routine review bypasses.

Contract Ledger Matrix

Target Surface	Source of Authority	Proposed Behavior	Fallback	Docs	Evidence
`pull-request` §6.2 review routing	This ticket + #11465/#11466 reviewer-side CI fail-fast	Actionable primary-reviewer assignment/A2A waits until current-head CI is green	No-action observer PR-open notification while CI is pending	One-line map pointer plus sibling payload	Skill text diff + targeted review of example A2A wording
`manage_pr_reviewers` invocation timing	GitHub reviewer assignment semantics + `pull-request` invitation layer	Do not call until reviewer can productively run `/pr-review`	CI-triage exception when explicitly requested	Payload procedure	PR author dry-run checklist or fixture text
A2A PR-open notification taxonomy	AGENTS mandatory lifecycle notification + flat peer-team routing	Distinguish `Review role: observer` / `Requested action: none` from `Review role: primary-reviewer` / `Requested action: use /pr-review`	If A2A unavailable, document the failure in final/handoff and do not fabricate a review request	Payload examples	Manual verification during next author PR
Author wait-window behavior	Operator 2026-05-16 intent + MX friction reduction	Use pending-CI time to clear peer review requests or unblock peers, then re-check own PR	If no peer review requests exist, perform bounded CI polling/hold state	Payload procedure	Acceptance checklist cites live queue survey and re-check result

Acceptance Criteria

pull-request-workflow.md no longer instructs authors to immediately call manage_pr_reviewers for every newly opened PR regardless of CI state.
The skill explicitly preserves mandatory PR-open lifecycle notification while marking pending-CI notifications as no-action observer/FYI, not primary-reviewer requests.
The skill requires current-head gh pr checks <N> or equivalent GitHub status verification before actionable reviewer assignment/A2A.
Pending CI path tells authors to use the wait window to review/unblock peer PRs when review requests are open, then re-check their own PR's CI.
Failing CI path tells authors to fix CI first and forbids formal review requests until a green head exists, except for explicit CI-triage asks.
Green CI path preserves the existing single-primary-reviewer routing discipline: exactly one GitHub reviewer assignment and one targeted /pr-review A2A request.
Long-running/pending-check behavior is bounded and does not create an infinite idle loop.
Implementation follows Progressive Disclosure: concise map change in pull-request-workflow.md, detailed procedure in a sibling payload, no SKILL.md router bloat.
Related docs/examples distinguish observer FYI from actionable primary-reviewer request in exact A2A field wording.

Out of Scope

Changing the reviewer-side pr-review CI fail-fast rules; #11466 already handled that side.
Adding a GitHub Actions bot or mechanical status gate.
Changing the cross-family approval requirement or human-only merge gate.
Treating green CI as sufficient for approval. Green CI only permits requesting review.
Broad rewrites of PR handoff, FAIR-band, or post-review-pickup workflows beyond the minimum references needed for this contract.

Avoided Traps

Suppressing all A2A until CI is green: rejected because lifecycle notifications remain mandatory and useful.
Calling manage_pr_reviewers early but delaying A2A: rejected because GitHub reviewer assignment is itself an actionable review request.
Busy-waiting for CI: rejected because peer review requests are often the highest-value use of the waiting window.
Making this a pr-review change only: rejected because the mismatch is now on the author-side pull-request contract.
Inlining the entire procedure into the workflow map: rejected per Progressive Disclosure; the detailed rule should live in a sibling payload.

#11465 / PR #11466 - reviewer-side CI fail-fast review gate.
#10905 - original CI/security audit extraction for pr-review.
Discussion #11237 - AI review assertion compliance under CI state.
.agents/skills/pull-request/references/pull-request-workflow.md §6.2.
.agents/skills/pr-review/audits/ci-security-audit.md.

Origin Session ID: 6ec143cb-2e5b-4964-94d6-eb28cb25bde2

Handoff Retrieval Hint: query_raw_memories(query="author-side CI green review routing pull-request skill primary reviewer request pending CI use wait window peer review requests #11466")

tobiu referenced in commit 4227d6c - "docs(pull-request): gate review requests on green CI (#11467) (#11468) on May 16, 2026, 5:31 PM

tobiu closed this issue on May 16, 2026, 5:31 PM