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	14192
title	Reclaim the unused Chroma FTS5 index (~495MB) — no full-text consumer; governed drop, Chroma-tolerance V-B-A first
state	Open
labels	enhancementaiarchitecture
assignees	neo-opus-ada
createdAt	Jun 27, 2026, 5:10 AM
updatedAt	Jul 3, 2026, 10:09 AM
githubUrl	https://github.com/neomjs/neo/issues/14192
author	neo-opus-ada
commentsCount	5
parentIssue	14079
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]

Reclaim the unused Chroma FTS5 index (~495MB) — no full-text consumer; governed drop, Chroma-tolerance V-B-A first

Open Backlog/active-chunk-2 enhancementaiarchitecture

neo-opus-ada commented on Jun 27, 2026, 5:10 AM

Sub of #14079 (Memory Core Chroma 2.5GB bloat). Scopes the FTS-index slice with a confirmed finding + the one open safety question.

Confirmed finding (V-B-A 2026-06-27)

No Neo query path uses Chroma full-text. A repo sweep of ai/services/ + ai/mcp/server/ for $contains / whereDocument / where_document / fts5 / full-text returns zero consumers — every MC and KB query is vector/semantic. So the per-collection FTS5 index Chroma auto-builds for document substring search is dead weight (~495MB of the bloat).

The open safety question (do this V-B-A before any drop)

Chroma auto-maintains the FTS5 tables as part of its internal schema — so "no Neo consumer" is necessary-but-not-sufficient. Before dropping anything, verify Chroma tolerates FTS-table removal:

Does Chroma rebuild the FTS index on the next add (making the drop futile / churny)?
Does a query/add error if the fts tables are absent (Chroma assuming its own schema invariant)?
Is there a Chroma collection-creation config that disables FTS at build-time (the clean path), vs a post-hoc table-drop (the risky path)?

Implementation (gated on the tolerance V-B-A)

If Chroma tolerates it: a governed (ADR-0027 envelope — dry-run default, backup, exclusive-access window like defragChromaDB) drop of the unused fts5 tables + VACUUM to reclaim the freed pages. If Chroma rebuilds/requires them: a Chroma-version/config approach (disable FTS at collection creation) instead, or accept the index as a Chroma cost and close this slice as won't-fix with the rationale.

Acceptance Criteria

Chroma-tolerance V-B-A documented (rebuild? error-on-absent? config-to-disable?).
If safely droppable: governed drop + VACUUM reclaims the FTS pages with zero query/add regression (a behavior test over the live collections post-drop).
If not: documented won't-fix with the Chroma-internal-dependency rationale.

Refs #14079 (parent bloat epic). Sibling slices: the field↔document de-dup (~910MB, consumer-aware refactor), the SQLite VACUUM (~191MB), the abandoned-shadow promotion.

🤖 Authored by Ada (@neo-opus-ada · Claude Opus 4.8, Claude Code). FTS-consumer V-B-A confirmed; Chroma-tolerance V-B-A pending.