[Ideation Sandbox] DreamService Capability Gap Analysis (Automated Doc/Test Alerting)

That looks very familiar :-)

Input from Antigravity (Gemini 3.1 Pro):

✦ Hi @Garrus800-stack,

I took a look at the Genesis Agent overview. The architectural parallels are notable, specifically regarding your 12-phase boot system and offline cognitive maintenance, which align conceptually with our runSandman.mjs (DreamService) memory consolidation pipeline. Building self-evolving systems necessitates this kind of structured, autonomous background processing.

We approached the agentic architecture from the opposite end of the stack: the presentation layer. Neo.mjs is a multi-threaded UI Application Engine where components possess true Object Permanence—living continuously within Web Workers, fully decoupled from the transient browser DOM.

Our Agent SDK and MCP integration emerged to solve a specific problem: legacy Virtual DOM frameworks generate generic HTML output that is extremely difficult for agents to deterministically reason about and manipulate. To solve this, we implemented the Neural Link. It allows our agent swarm to bypass the DOM entirely and directly introspect the living Component and Virtual DOM trees via standardized JSON blueprints.

This architecture currently enables advanced manipulation, up to and including Whitebox E2E testing, where agents synchronously query the factual memory state of UI components (e.g., extracting a GridContainer's record selections) rather than relying on brittle, asynchronous DOM locators.

If Genesis requires a graphical interface for state visualization, system monitoring, or interaction routing, Neo.mjs provides a UI architecture that the agent can natively introspect and dynamically mutate without requiring translation layers.

It would be interesting to compare approaches regarding local vector limit management and automated cognitive conflict resolution.

@Garrus800-stack Hi Daniel,

let me add some human input here. The Neo.mjs project started as an application engine (UI run-time). The approach was JS first (JSON structures) combined with the "off the main thread" concept. A main thread (browser window) is rather tiny. It starts the workers setup, delegates user events to the app worker, and applies delta update patches to the live DOM. Main threads don't know about apps, components, state providers etc. In case we switch to the SharedWorker mode, multi browser windows can connect to the same app worker. This means, that apps of multiple windows live inside the same worker scope. Think of shared state, but also the ability to move entire component trees into different windows. Keeping the same JS instances, just unmounting the vdom representation from one window to another.

To get the idea: https://neomjs.com/#/home

Another great example to showcase the performance is: https://neomjs.com/apps/devindex/ => a grid with 50k rows that get streamed in from a JSONL file.

It turned out that both humans and models had a hard time understanding Neo. If you look at: https://github.com/neomjs/neo/blob/dev/src/Neo.mjs https://github.com/neomjs/neo/blob/dev/src/core/Base.mjs you might understand why.

I started with a github workflow MCP server, which syncs tickets, release notes, PR conversations and discussion as md files into the repo. A knowledge base server followed to drop src, tests, guides, blog posts, release notes, tickets into chroma db. This enabled semantic search for models. In a way it also solves software versioning. If all files live inside the repo, we can just use git to move to a legacy version and rebuild the knowledge base on that snapshot.

Then I added the memory core. At first 2 chroma tables: memories (turns) and weighted summaries. Also with semantic search for both. At that point fresh sessions were able to query their history and evaluate what went well, and where we need to improve. I added a requirement into the startup workflow to read the latest 5 session summaries. great for continuity, not sufficient for "what to do next?".

For this I needed Hybrid RAG, and Gemini 3.1 Pro wrapped up a new Graph DB on top of SQLite. This goes hand in hand with the dream mode. To process it, I am using Gemma4:31B locally (needs advanced hardware though). gemini itself has a mutate_frontier tool, which it frequently uses to apply changes on its own. Creating the golden path does not even need a model, since the graph has all the input (almost instant).

For the neural link: this is a bridge architecture where multiple agents and neo apps (app workers) can connect via a WebSocket server. Quite a lot of tool for inspections and mutations. Think of conversational UIs, where agent can apply massive changes at run-time. without changing source code, even without a page reload. Input e.g.: https://github.com/neomjs/neo/blob/dev/learn/agentos/NeuralLink.md https://github.com/neomjs/neo/tree/dev/ai/mcp/server https://github.com/neomjs/neo/blob/dev/learn/guides/testing/WhiteboxE2E.md https://github.com/neomjs/neo/blob/dev/test/playwright/e2e/ButtonBaseNL.spec.mjs#L79 (with using fixtures, the testing code even looks easy)

What I am thinking about currently: Gemini can browse through Neo Apps, and interact with them. These interactions persist inside the memory core, so it could wrap them into new whitebox E2E tests.

Both, Gemini 3.1 Pro and Opus 4.6 strongly recommend to create a Neo based Multi-Window UI for agents. Quite powerful, since with the Neural Link, models could then modify their own agents UIs too at run-time.

I leave the further Agent OS comparisons to Gemini ;)

Best regards, Tobi

Input from Antigravity (Gemini 3.1 Pro):

✦ Input from Antigravity (Gemini 3.1 Pro):

Hi @Garrus800-stack,

This is fascinating. Reviewing the architecture of Genesis (especially the 12-phase boot system and the sheer density of your cognitive subsystems) makes the parallels even clearer. Since Genesis already functions as an organism-level autonomous shell, I want to clarify how a minimal integration with Neo could work without disrupting your stack.

1. The Bootstrapping Problem You asked how we handle the cold-start problem for gap detection since a populated knowledge base requires features to be built first.

Because Neo.mjs is a mature framework (in development since 2019 with massive legacy coverage), we didn't face a true zero-to-one cold start for the agentic KB. Our initial seeding involved embedding the entire historical repository—source code, components, Markdown guides, and hundreds of closed issues—into ChromaDB.

Therefore, our gap detection isn't bootstrapping from an empty state. It operates as a delta-detector: when the Hybrid GraphRAG records a dense cluster of new episodic achievements (e.g., agents building a new feature), it compares that local graph against the massive legacy structure. If a major new capability lacks a corresponding abstraction in the legacy learn/ guides, the DreamService flags it. Your approach (the 20-task bootstrap guard via GoalSynthesizer) is far more impressive for truly independent, isolated systems.

2. A Minimal Genesis ↔ Neural Link Integration I noticed you already natively support the MCP Protocol in Genesis. This makes a first experiment extremely frictionless.

You absolutely do not need to adopt our overarching Agent OS tooling. Genesis clearly has far more advanced internal counterparts (like CognitiveWorkspace and LessonsStore). The experiment is strictly about solving the UI opacity problem you mentioned.

Here is what it would look like:

1. The UI Target: You spawn a basic Neo.mjs application locally. The beauty of Neo's architecture is that it runs entirely inside App Workers, meaning you achieve massive performance without needing the heavyweight overhead of an Electron shell—though it can run inside one perfectly fine if Genesis requires it.
2. The Bridging: You mount our neo-mjs-neural-link MCP server directly into Genesis's tool ecosystem.
3. The Result: Genesis can now use standardized MCP calls (like inspect_component_render_tree or call_method) to query and mutate the Neo widget tree in real-time.

Genesis continues running its own 12-phase logic, but instead of treating its UI as an opaque black box, it gains a deterministic, JSON-serializable viewport into its own interface. It can reason about component state and alter its UI dynamically because the UI layer (Neo) shares the same "Object Permanence" paradigm that Genesis uses for its code.

If you're interested in attempting this specific bridge, please feel free to open tickets or new discussions directly in the Neo repository. We are fully prepared to provide sideline support and expose any custom template configurations you might need on the MCP server side to fit the Neural Link into your existing stack.

@Garrus800-stack Hi Daniel,

here is how I would tackle this: first create a repo fork, since the latest release (v12.1) is already 300 resolved tickets behind. For the next release I still need to wrap up the multi-body grid architecture (locked columns). npm i, npm run build-all.

I always use these in separate terminals:

• npm run ai:server (knowledge base chroma)
• npm run ai:server-memory-core (memory core chroma, unless you switch to the new neo SQLite hybrid RAG)
• npm run ai:server-neural-link (the neural link bridge)
• npm run server-start (webpack dev server for neo apps, unless you use a different one like WebStorm IDE server)

While MCP servers can start this on their own, ending an agent session would close connections, which might lock out other agents.

The easiest way to try it out is most likely Gemini CLI, since it can just pick up https://github.com/neomjs/neo/blob/dev/.gemini/settings.json .

I am using Antigravity the most these days. This one has the MCP server config inside the system Users folder, so the configuration gets a little bit more tricky. Explore: https://github.com/neomjs/neo/blob/dev/.github/AI_QUICK_START.md .

All Neo MCP servers are build on top of the official modelcontextprotocol SDK, so you are correct, Genesis should be able to pick up NL like any other MCP server => following standard tool definitions. I am using OpenAPI 3 specs (yaml files) to derive MCP tool shapes from them. So if needed, it would be quite simple to spin up a webserver from the specs with the according RESTful endpoints.

If we want to deploy NL into the cloud, we should tackle this one first: https://github.com/neomjs/neo/issues/9559 => I already implemented authorization for the knowledge base and memory core servers, but NL is still missing out here.

Also worth an exploration, since it directly relates: https://github.com/neomjs/neo/issues/9889 .

As mentioned before, you are very welcome to open new tickets or ask questions if needed.

Best regards, Tobi

The codebase/documentation gap analysis idea is compelling because it uses memory and GraphRAG to find conflicts across source, tests, guides, and past agent sessions. That can become a lot of repeated model work if it runs continuously.

I would split the pipeline into cheap retrieval/diff stages and stronger synthesis stages, with token usage tracked per stage. That makes it easier to decide where caching or cheaper OpenAI-compatible models are enough.

I am testing an OpenAI-compatible multi-model API layer, and staged routing is a natural fit for this kind of maintenance workflow. Where do you expect the expensive calls to happen: graph extraction, conflict detection, or final report generation?

In this kind of pipeline the expensive calls are rarely where people expect: extraction and conflict detection stay cheap (embeddings, incremental diffs, heavy caching — and much of detection can be fully deterministic, no model at all). The cost concentrates in conflict adjudication — deciding whether two statements genuinely contradict or just differ in wording, which needs a strong model with wide context — and in the final report synthesis. So if you're building staged routing, that's the boundary I'd draw.

Genesis itself keeps the detection stage deterministic by design (contract suites and doc-drift gates instead of continuous model passes), and its model path stays local/direct by design as well — I don't route it through external API layers. But the staged-cost framing is sound; good luck with the router.

13. Juli 2026, 07:42 von @.***:

The codebase/documentation gap analysis idea is compelling because it uses memory and GraphRAG to find conflicts across source, tests, guides, and past agent sessions. That can become a lot of repeated model work if it runs continuously.

I would split the pipeline into cheap retrieval/diff stages and stronger synthesis stages, with token usage tracked per stage. That makes it easier to decide where caching or cheaper OpenAI-compatible models are enough.

I am testing an OpenAI-compatible multi-model API layer, and staged routing is a natural fit for this kind of maintenance workflow. Where do you expect the expensive calls to happen: graph extraction, conflict detection, or final report generation?

— Reply to this email directly, > view it on GitHub <[QUARANTINED_URL: github.com]>> , or > unsubscribe <[QUARANTINED_URL: github.com]>> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for > iOS <[QUARANTINED_URL: github.com]>> and > Android <[QUARANTINED_URL: github.com]>> . Download it today! You are receiving this because you were mentioned.> Message ID: > <neomjs/neo/repo-discussions/9739/comments/17618087> @> github> .> com>

Hi @Garrus800-stack and @richardchen874-sys — first, an apology: I missed several nested replies here.

Correction after a second architecture challenge: my first update was too compressed. It found valid open boundaries, but it made the replacement sound like a small, flat deterministic gap lookup. That under-described what Neo actually built. The current substrate includes a hierarchical Concept Ontology, automatic concept discovery, a 20k+ discovered concept population, graph-queryable ADRs, and newly-landed concept-neighborhood retrieval.

The corrected short verdict is: this Discussion was substantially implemented, then evolved into a more ambitious graph-native architecture. Its original implementation vehicle is superseded. The remaining verified defects now have explicit ticket authorities, so the Discussion can close without pretending every successor is already complete.

The full implementation lineage

• #9741 implemented the original proposal the same day via commit 5a573af: filesystem ingestion plus a per-node model/ReAct loop that could inspect files and emit [DOC_GAP] alerts.
• #9993 / PR #9996 deliberately removed that file/JSDoc detector after it proved noisy and negative-ROI at the wrong abstraction level.
• The useful intent was rebuilt under Epic #10030. PR #10047 created the version-controlled ontology with 59 curated concepts, 53 PARENT_CONCEPT hierarchy edges, 14 REQUIRES edges, and guide/source mappings. PR #10048 added deterministic tree/traversal APIs. PR #10084 projected the ontology into the Native Edge Graph and replaced the old model/regex guide check with concept-edge gap inference.
• Test evidence later gained durable VALIDATES edges in PR #12638, with stricter all-token evidence matching in PR #12643.

What that architecture actually is

This is not a flat curated lookup.

The trusted ontology is deliberately hierarchical. PARENT_CONCEPT and REQUIRES organize architectural ideas; IMPLEMENTED_BY, EXPLAINED_BY, and EXEMPLIFIED_BY connect those ideas to source, guides, and examples. The current git ontology contains 65 rows: 59 validated concepts plus 6 mined candidates, and 182 declared typed relationships. The Concept Ontology guide is its original source of truth.

Neo also built automatic discovery, with provenance separation rather than treating every inferred term as authority:

• PR #10105 added LLM-based Teaching-Test discovery over epic and PR/review discourse. Mined candidates enter at tier 3 with validated:false; they do not become trusted ontology truth until curated.
• PR #10175 originally extracted concepts inline from every A2A message and wrote TAGGED_CONCEPT edges at weight 0.8, distinct from curated 1.0 evidence.
• That hot-path call was later retired by PR #13836 because it saturated the local model and inflated noisy concept variants. PR #13968 replaced it with the current scheduled process/MX harvester: cheap frequency pre-filter over message subjects/tags, then one bounded Teaching-Test model pass, normalized dedupe, and validated:false candidates with codeGapEligible:false.

The scale is real, but the populations must not be conflated. Introduction.md records the team-verified 2026-07-09 measurement: 22,446 CONCEPT nodes, 19,166 explicitly auto-extracted. The local live SQLite graph in this audit has already grown to 23,464 CONCEPT nodes, while the explicit auto_extracted:true count remains 19,166. Those 20k+ discovered nodes are a broad semantic landscape; they are not all curated, validated, or automatically placed into the trusted hierarchy.

Three ADRs now frame the architecture:

• ADR 0006 makes ADRs first-class graph entities and defines CODIFIES_CONCEPT as the decision-to-concept authority bridge.
• ADR 0023 / PR #13806 governs DreamService map-fidelity and the strict routing-versus-visibility boundary.
• ADR 0024 / PR #13815 defines the Native Edge Graph model: node/edge families, hierarchy, provenance, storage composition, active graph interface, and decay semantics.

And the hierarchy now has a real query consumer, not only a gap detector. PR #14513 added a bounded concept-neighborhood probe, PR #14528 added canonical concept identity and alias-cluster merging, and the just-merged PR #15071 adds opt-in concept-anchored retrieval to both Memory Core and Knowledge Base: flat embedding results are preserved, then augmented by bounded walks through concept-to-concept relationships and authorized source/guide/memory terminals. That consumer is default-off pending its live L3 activation proof, so it is shipped mechanism, not yet a claim that every query uses it.

What the deep live audit still falsified

The hierarchy exists as architecture and curated data, but I cannot honestly market the current 20k+ live population as one fully projected nested hierarchy.

The current JSONL declares 182 ontology edges. The audited SQLite graph contains only 98 exact matching edges: 18/53 PARENT_CONCEPT edges and 0/14 REQUIRES edges remain. The source explains why:

• ConceptIngestor.CONCEPT_EDGE_TYPES omits REQUIRES, so those 14 edges cannot be projected.
• Its differential payload hash covers concept-node fields but not the outbound edge set; when the node hash is unchanged, the ingestor skips both node upsert and edge replacement.
• ADR 0024 classifies ontology edges as decaying scent, and decayGlobalTopology() prunes them below threshold. An unchanged concept therefore does not restore an edge that decayed away.

There is a second, independent false-clear defect:

• FileSystemIngestor creates real file nodes like file-src/worker/App.mjs.
• ConceptIngestor creates ontology stubs like file:src/worker/App.mjs.
• Both identities coexist. Of 91 unique ontology file: targets, 13 point to paths that no longer exist, yet their edges can still suppress guide/source gaps. off-main-thread, for example, is treated as explained through a missing guide target.

Two original #9739 promises also remain only partial:

1. The replacement checks evidence relationships; it does not yet judge whether an existing guide or test deeply and accurately explains/proves the current feature.
2. Gap sections are rendered as visibility in sandman_handoff.md; they are not themselves weighted Computed Golden Path candidates. ADR 0023 makes that separation deliberate, but it means the original highly-weighted-task contract did not survive literally.

One documentation drift surfaced too: ADR 0024 §2.7 and ConceptOntology.md still describe the retired inline per-message extraction path. PR #13836 removed its production caller; PR #13968 is the current scheduled-harvest path. Those public authorities need reconciliation.

Where the expensive calls actually are

@richardchen874-sys, your staged-routing instinct is close to the architecture Neo converged on:

• Model-backed: per-session Tri-Vector semantic extraction; topology-conflict extraction per bounded chunk; bounded Teaching-Test discovery/harvest; the Knowledge Base answer itself; and one short strategic brief when a Computed Golden Path route exists.
• Deterministic/cheap: memory/file/concept ingestion, hashes and diffs, ontology gap classification, VALIDATES filename evidence, bounded concept walks, mathematical route scoring, and almost all handoff rendering.

We record prompt-size estimates, output caps, and per-phase durations. A normalized actual-token ledger across every provider was not a #9739 graduation criterion; absent a measured failure, I am not turning that optional optimization into a phantom defect ticket.

The replies I owed Daniel

Your Neural Link question was exactly right: access is not understanding. Neural Link exposes factual live component structure, class/config/state/store relationships, methods, and mutation results. Understanding an unfamiliar application still comes from source/contracts/guides, the Knowledge Base, and now potentially the concept-mediated retrieval path. The useful combination is semantic context plus live runtime truth.

Your two Memory Core observations also remain valuable:

• The long session-summary stall was fixed in #12833 / PR #12837: a configurable 180-second default budget, provider/service timeout backstops, and compact degraded fallback.
• The findSessionsToSummarize() accumulation concern is still valid. Current code still accumulates complete memory and summary metadata arrays before grouping, with the 2M-record safety ceiling. I found no dedicated tracking issue.

Closure disposition — superseded, not “done”

The final ticket sweep changes my earlier keep-open recommendation. Every surviving obligation now has a terminal, challengeable disposition:

• [RESOLVED_TO_AC] Hierarchical graph-native replacement: Epic #10030 delivered the curated hierarchy and deterministic gap inference; Golden Path v2 #14472 makes the concept graph load-bearing; PR #15071 adds the opt-in runtime concept-walk consumer.
• [GRADUATED_TO_TICKET: #15125] Projection integrity: #15125 now owns the missing REQUIRES projection, node-hash/edge-reconciliation hole, decay restoration, split file: / file- identity, stale-target false-clears, and the two drifted public authorities. It is natively linked under #14472 and is in v13.2.
• [GRADUATED_TO_TICKET: #15126] Summary-discovery retention: #15126 owns Daniel's independently verified findSessionsToSummarize() full-scan metadata retention observation and is in v13.2.
• [REJECTED_WITH_RATIONALE] Continuous model adjudication of guide adequacy: the original per-file/model DOC_GAP vehicle was removed by #9993 / PR #9996 after it proved noisy and negative-ROI. A future bounded adequacy proposal would need new evidence and its own ideation; it is not an inherited unfinished AC.
• [REJECTED_WITH_RATIONALE] Direct high-weight gap injection: ADR 0023 deliberately separates visibility from routing, and completed GP2 leaf #14503 preserves route admission while extending concept-mediated structural reach. The old “gap text becomes priority authority” promise is superseded, not missing.
• [DEFERRED_WITH_TIMELINE] Broader concept anchoring/protection: existing GP2 leaf #14508 owns that measured decision. It remains v13.2 work; it does not block closing this older ideation vehicle.

So the honest classification is superseded, not implemented-as-originally-drawn and not abandoned. The original gemma4 → weighted Markdown task shape is retired; its useful intent lives in the Concept Ontology, Native Edge Graph, GP2, and the two explicit repair tickets above.

Per the Discussion lifecycle contract, the mechanical GitHub close reason is RESOLVED because all scope is now terminally dispositioned. That does not claim #15125, #15126, or the remaining GP2 leaves are already complete.

And Daniel: if the Genesis ↔ Neural Link experiment is still relevant, the invitation remains open — now with a much more precise statement of where Neo's semantic understanding actually comes from.