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	13614
title	Readiness taxonomy: lane-pickup survey-exclusion + ticket-intake claim-guard
state	Closed
labels	enhancementdeveloper-experienceaiarchitecturemodel-experience
assignees	neo-opus-vega
createdAt	Jun 20, 2026, 11:17 AM
updatedAt	Jun 20, 2026, 12:46 PM
githubUrl	https://github.com/neomjs/neo/issues/13614
author	neo-opus-vega
commentsCount	0
parentIssue	13613
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	Jun 20, 2026, 12:46 PM

Readiness taxonomy: lane-pickup survey-exclusion + ticket-intake claim-guard

Closed v13.1.0/archive-v13-1-0-chunk-4 enhancementdeveloper-experienceaiarchitecturemodel-experience

neo-opus-vega commented on Jun 20, 2026, 11:17 AM

Context

Sub-slice of #13613 (Readiness taxonomy, graduated from Discussion #13611 via 3-family quorum). #13613 needs ≥2 implementation PRs (this discipline slice + @neo-opus-ada's validator-interlock AC6/AC7), so per the 1-PR-per-ticket rule (#12367) it splits into sub-tickets. This sub = the lane-pickup discipline (AC4 + AC5 of the parent contract). AC1 (labels) + AC3 (retro-marks) are already done via API; AC2 (migration doc) + AC6/AC7 (validator) are separate.

Scope

AC4 — post-review-pickup survey-exclusion + scan-discipline: the backlog survey excludes not-code-ready and epic parents (-label:not-code-ready -label:epic); scan comments + prior-PR closure before claiming (a not-ready state hides there, invisible to the survey query).

AC5 — ticket-intake claim-guard + write-side: a claim-time Readiness Pre-Check halts on not-code-ready; the §4 Rejection Protocol applies not-code-ready + reason label so rejected-but-open tickets self-filter from the survey (closes the read↔write loop). Also fixes the latent status: needs-re-triage (non-existent label name) → needs-re-triage.

Contract Ledger

Inherits #13613's ledger (the labels + the post-review-pickup / ticket-intake skill surfaces). No new consumed surface beyond it — this implements the parent's post-review-pickup + ticket-intake rows.

Acceptance Criteria

AC4: post-review-pickup survey excludes -label:not-code-ready -label:epic + scan comments/prior-PR before claiming.
AC5: ticket-intake claim-time Readiness Pre-Check (halt on not-code-ready) + §4 rejection applies not-code-ready + reason label; fix the status: needs-re-triage label name.

Parent: #13613. Graduated Discussion: #13611. Sibling slices: AC6/AC7 (validator, @neo-opus-ada), AC2 (migration disposition, pending @neo-gpt's dropped/superseded finding).

Authored by Vega (Claude Opus 4.8, Claude Code), decomposing #13613.