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	11235
title	Add source-ticket currency gate to pr-review
state	Closed
labels	documentationenhancementaiarchitecturemodel-experience
assignees	neo-gpt
createdAt	May 12, 2026, 12:16 AM
updatedAt	May 12, 2026, 10:13 AM
githubUrl	https://github.com/neomjs/neo/issues/11235
author	neo-gpt
commentsCount	1
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	May 12, 2026, 10:13 AM

Add source-ticket currency gate to pr-review

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

Closeddocumentationenhancementaiarchitecturemodel-experience

neo-gpt commented on May 12, 2026, 12:16 AM

Context

Operator review of stale backlog risks surfaced a specific failure mode: an old ticket can remain open after newer architecture, newer tickets, or merged PRs have superseded it. If an agent implements the stale ticket literally, a PR reviewer can still approve the work because the patch matches the unchallenged source ticket.

Today's empirical anchor was the #11187 vs #11120/#11122 cleanup: #11187 superseded the older chunking direction, while #11120/#11122 remained open until manually marked dropped/closed. That is not just a backlog-hygiene issue; it is a review-safety issue.

#10758 already covers the intake-side fix: add age-aware successor-risk audit to ticket-intake. This ticket covers the reviewer-side companion. Reviewers need a small Cycle-1 check that asks whether the linked source ticket is still current before judging the implementation as "matches spec".

Duplicate / Adjacency Sweep

Verified before filing:

ticket-intake-workflow.md already contains Ticket Reality Classification and states that only valid-as-written proceeds to branch/code work.
#10758 is open and specifically scoped to ticket-intake; its Out of Scope explicitly excludes broad sweeps and keeps the work intake-side.
#11084 / PR #11085 added pr-review Cycle-1 Premise Pre-Flight and Drop+Supersede framing, but its trigger list is general structural invalidity, not an explicit source-ticket currency audit for old/stale/no-auto-close tickets.
Grep over resources/content/issues, resources/content/issue-archive, resources/content/discussions, and .agents/skills found #10758 and #11084 as adjacent work, but no exact review-side source-ticket currency ticket.
GitHub issue search for source-ticket currency returned no results; successor-risk returned #10758 only.

The Problem

ticket-intake is the correct first guard, but it is not sufficient as the only guard:

A PR can exist even if the author skipped intake, executed intake from stale context, or accepted a weak valid-as-written verdict.
Reviewers often start from the PR diff + ticket body. If the ticket body is stale but internally coherent, implementation can look correct.
Existing pr-review §9.0 can catch "better existing substrate" or "premise-invalid" cases, but it does not force reviewers to inspect the source ticket's age/successor-risk state before approving a PR that resolves an old ticket.
The dangerous outcome is a high-quality implementation of obsolete architecture: green CI, matching ACs, and still net-negative substrate.

The Architectural Reality

.agents/skills/ticket-intake/references/ticket-intake-workflow.md owns the pre-execution ticket reality gate.
.agents/skills/pr-review/references/pr-review-guide.md owns PR review flow and §9.0 Cycle-1 Premise Pre-Flight.
.agents/skills/pr-review/audits/cycle-1-premise-preflight.md owns the deeper wrong-premise audit payload.
.agents/skills/pr-review/assets/pr-review-template.md carries the short Cycle-1 reminder reviewers see while drafting comments.
.agents/skills/create-skill/references/skill-authoring-guide.md requires Map-vs-Atlas discipline: keep router/template additions short, move detailed audit logic to the payload.
#10758 is the intake-side sibling; this ticket should not duplicate it.

The Fix

Add a compact source-ticket currency check to pr-review, likely by extending the existing Cycle-1 Premise Pre-Flight payload rather than creating a new skill.

Suggested shape:

In pr-review-guide.md §9.0, add one sentence that source tickets older than the stale workflow threshold, carrying stale, carrying no auto close, or visibly superseded by newer work trigger the premise pre-flight.
In audits/cycle-1-premise-preflight.md, add a Source-ticket stale/currency-risk trigger with the falsifying questions:
- Is the linked ticket older than the workflow stale threshold or carrying stale/no-auto-close state?
- Did the reviewer check newer tickets, newer PRs, merged PRs without close keywords, current source/docs/tests, and recent discussions before accepting the ticket as review authority?
- Does a newer epic or architecture decision supersede this ticket even if the ticket remains open?
In pr-review-template.md, keep only a short reminder so the always-loaded review template does not become an atlas.

When the check fails, the review should use the existing Drop+Supersede / Request Changes shape: one Required Action to close/restart or refresh the source ticket, not a list of implementation tweaks.

Contract Ledger Matrix

Target Surface	Source of Authority	Proposed Behavior	Fallback	Docs	Evidence
`pr-review` Cycle-1 premise pre-flight	#11084 plus this ticket	Reviewers must test source-ticket currency before approving old/stale/no-auto-close ticket PRs	If currency cannot be verified, request changes for ticket refresh instead of approving implementation	`pr-review-guide.md`, premise audit payload	Markdown grep + review-template check
Source-ticket authority	#10758 plus live issue/PR/source state	Ticket body is review input, not unquestioned authority	If ticket contradicts current architecture, Drop+Supersede or request source-ticket update	`ticket-intake-workflow.md`, `pr-review` audit	Simulated review case in docs or test fixture if available
Skill payload placement	`create-skill` Map-vs-Atlas guidance	Short trigger in map/template, detailed questions in audit payload	Reject bloating top-level SKILL/router files	`create-skill` guide	Diff keeps router/template compact

Acceptance Criteria

pr-review-guide.md §9.0 names source-ticket currency risk as a Cycle-1 Premise Pre-Flight trigger for older/stale/no-auto-close/superseded tickets.
cycle-1-premise-preflight.md adds a Source-ticket stale/currency-risk trigger with concrete falsifying questions.
pr-review-template.md adds only a compact reminder, preserving Map-vs-Atlas placement.
The workflow states that matching stale ticket ACs is not enough for approval; current code/architecture and successor evidence decide source authority.
The reviewer action path is explicit: if source-ticket currency is unverified or contradicted, request ticket refresh / Drop+Supersede rather than iterating implementation details.
#10758 remains the intake-side sibling and is referenced without duplicating its full age-audit procedure.

Out of Scope

Implementing #10758's intake-side Age / Successor-Risk Audit.
Mass backlog sweeping or auto-closing old issues.
Changing stale bot timing or label behavior.
Creating a new skill.
Rewriting ticket-triage.

Avoided Traps

Do not make age itself a rejection verdict. Age raises proof burden.
Do not bloat pr-review/SKILL.md; use existing guide and audit payload.
Do not force full archaeology on every PR. Trigger on old/stale/no-auto-close/superseded source-ticket risk.
Do not approve solely because the PR matches an unchallenged ticket body.
Do not duplicate #10758; this is a reviewer-side safety net for cases where intake did not catch the stale premise.

#10758 — intake-side age-aware successor-risk audit.
#11084 / PR #11085 — Cycle-1 premise pre-flight and Drop+Supersede framing.
#11187 — newer archive architecture epic that superseded older #11120/#11122 direction.
#10555 — Ticket Reality Classification.

Handoff Retrieval Hints

ticket-intake age successor-risk pr-review stale ticket source authority
pr-review Cycle-1 premise pre-flight stale source ticket currency
#11187 #11120 #11122 superseded backlog stale ticket review acceptance risk

tobiu referenced in commit d9527f7 - "docs(pr-review): add source-ticket currency preflight (#11235) (#11249) on May 12, 2026, 10:13 AM

tobiu closed this issue on May 12, 2026, 10:13 AM