Review and reduce core coupling to VSCode and Three.js

[bitkojine]

Description:

OpenAs3D aims to treat real systems as explorable 3D spaces, with the long-term intent that the core concepts (systems, entities, relationships, worlds) are reusable beyond VSCode or any specific rendering engine.

Right now, the codebase is likely tightly coupled to:

• VSCode extension APIs
• Three.js / rendering-specific constructs

This issue is to explicitly review and understand that coupling, and identify where refactoring would meaningfully improve the architecture without slowing development.

Design intent (target state):

• Core domain logic is written in pure TypeScript
• Core code does NOT depend on:
  • VSCode APIs
  • Three.js or any rendering framework
• VSCode and Three.js act as adapter layers around the core
• The core should be testable and reason-about-able without an editor or renderer

Task:

Review the codebase and determine to what extent current implementation violates this boundary.

Specifically:

1. Identify files, modules, or patterns where domain concepts (e.g. code objects, entities, graphs, relationships, navigation, analysis, worlds) directly import or depend on:

   • VSCode APIs
   • Three.js or rendering primitives

2. Classify coupling issues into:

   • Hard coupling (core logic cannot exist without VSCode / Three.js)
   • Leaky abstractions (domain models polluted by editor or rendering concerns)
   • Acceptable adapter-layer usage

3. Propose a realistic refactoring strategy to move toward:

   • A pure TypeScript core
   • Clear adapter layers for VSCode and rendering
   • Incremental steps (no rewrite)

4. Identify:

   • High-risk / high-churn areas
   • Low-hanging fruit that can be fixed quickly

5. Suggest concrete folder/module boundaries and dependency rules we should enforce going forward.

Constraints:

• Do not rewrite the project from scratch
• Optimize for shipping and iteration speed
• Assume this is an experimental but serious developer tool
• Avoid abstract theory; ground recommendations in the actual codebase

Outcome:

• Clear findings with examples
• Actionable refactoring recommendations
• A short, realistic “next steps” plan that can be executed over a few refactor passes

This issue is about improving long-term design clarity without killing momentum.