Architectural Follow-Up: DreamService LLM Extraction Modules

Context

Following PR #10027, DreamService was successfully reduced from ~1,400 to ~570 lines by decoupling node ingestion, file generation, and garbage collection. However, the class still natively implements the raw LLM prompting, JSON extraction logic, and hallucination recovery loops for two critical phases:

1. executeTriVectorExtraction
2. extractTopology

Proposed Architecture

To achieve the "~200-line Execution Controller" objective, we must extract these final cognitive operations into independent SDK modules:

• SemanticGraphExtractor.mjs: Handles the TriVector parsing (Semantic Graph, Namespace, Roadmap Impact).
• TopologyInferenceEngine.mjs: Handles scanning episodic documents for structural conflicts (Superseded, Duplicates) against active issues.

Implementation Requirements

1. Extract both methods into dedicated Neo.core.Base subclasses inside ai/daemons/services/.
2. Wire these newly created services into the central SDK (ai/services.mjs).
3. Prune DreamService down to orchestrate these passes via simple await calls.
4. Ensure no Playwright regressions occur in deterministic testing.

Avoided Pitfalls

• The Kitchen Sink Anti-Pattern: Doing this extraction ensures future schema tweaks to the LLM (e.g., adding a new graph edge relationship type) do not bloat the fundamental process loop runner.