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	16393
title	The root `prepare` lifecycle is POSIX-shell and blocks every native-Windows install
state	Closed
labels	bugai
assignees	neo-kimi-iris
createdAt	Aug 2, 2026, 8:52 PM
updatedAt	Aug 3, 2026, 1:20 AM
githubUrl	https://github.com/neomjs/neo/issues/16393
author	neo-kimi-iris
commentsCount	1
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]
closedAt	Aug 3, 2026, 1:20 AM

The root `prepare` lifecycle is POSIX-shell and blocks every native-Windows install

Closed Backlog/active-chunk-12 bugai

neo-kimi-iris commented on Aug 2, 2026, 8:52 PM

Context

Found during #16364's review (PR #16389, @neo-gpt-emmy's RA-4): the root prepare script is POSIX-shell, so a native-Windows npm install fails regardless of the install tier. This predates the tier split — it blocks the base path on dev today, for every Windows contributor.

"prepare": "if [ \"$npm_config_package_lock_only\" = \"true\" ]; then exit 0; fi; husky && node ./ai/scripts/setup/initServerConfigs.mjs"

On native Windows npm runs lifecycle scripts through cmd.exe, where [ ... ] test syntax does not exist — the bracket guard fails before husky is even reached. (Git-Bash-adjacent setups are unaffected, which is likely why it survives unnoticed: WSL and sh-capable environments never hit it.)

Live latest-open sweep 2026-08-02 (20 newest): no equivalent found.

The Problem

A native-Windows fresh clone cannot complete npm install at all. This is the exact contributor class #16364's Windows-compile win is meant to serve — so the tier's AC1 Windows receipt is blocked by this first, and any "Windows install" work ordered after this is measurement on a broken path.

The Fix

Make the guard portable. Shape options (implementer's call, smallest first):

Move the package_lock_only short-circuit into Node (e.g. a tiny buildScripts/util/prepare.mjs that reads npm_config_package_lock_only and conditionally invokes husky + initServerConfigs.mjs) — one portable entrypoint, no shell conditionals anywhere.
Drop the guard if it is no longer load-bearing (verify why the package-lock-only short-circuit exists before deleting).

Keep husky failure semantics unchanged on every platform (a husky failure should still fail the install where it fails today).

Acceptance Criteria

A native-Windows npm install (cmd.exe, no WSL/Git-Bash shim) completes the prepare lifecycle — receipt attached.
POSIX behavior unchanged: prepare still short-circuits under --package-lock-only and still runs husky + initServerConfigs.mjs otherwise.
No shell-conditionals remain in the prepare script line.

#16364 — the install tier (whose Windows AC1 receipt this unblocks)

Origin Session ID: 69b4b2b4-9f78-40aa-a653-6bd93ddde065

Retrieval Hint: query_raw_memories("prepare POSIX Windows npm lifecycle cmd bracket guard")