InterBrainMVP

Of course. This is an excellent and crucial point in your development process. You’ve correctly identified the central tension between traditional front-end architectures optimized for component reusability (Layered/Atomic) and modern architectures optimized for AI context and maintainability (Vertical Slice).

Let’s synthesize the insights from both answers and forge a definitive architectural guide for your DreamVault project. The goal is to create a document that is not only clear for you but can be pasted directly into your AI assistant’s context window to ensure every development session starts with a shared understanding of “how we build things here.”


ARCHITECTURE.md: A Guide for AI-First Development of InterBrain

1. Core Philosophy: AI Readability >= Human Readability

Software engineering is changing. Our primary collaborator is increasingly an AI assistant. Traditional architectures, like the Layered Architecture, were designed to help humans manage complexity by grouping files by their technical type (components, hooks, services). While this works, it scatters the context for any single feature across the entire codebase, making it difficult and token-expensive for an AI to grasp.

Our goal is to adopt a Pragmatic Hybrid Architecture that combines three powerful concepts:

  1. Command Palette Abstraction: All backend operations are exposed as Obsidian commands, creating a clean separation between UI and business logic.
  2. Vertical Slice Architecture: We organize our code by feature, not by technical type. Everything a feature needs to function (its UI, state, logic) lives in a single, self-contained folder.
  3. Atomic Design Principles: For UI elements that are truly shared across multiple features (like a generic button or modal), we maintain a separate, shared component library.

This hybrid approach gives us the best of both worlds: extreme token efficiency when working on a specific feature, clean abstraction between frontend and backend, and a robust system for reusable, foundational UI.

2. The Project Structure

Here is the definitive folder structure for the InterBrain Obsidian plugin. This structure is designed to be self-explanatory for both human and AI developers.

interbrain-plugin/
├── main.ts                     # Plugin entry point - registers all commands
├── manifest.json               # Plugin metadata for Obsidian
├── package.json               # Dependencies and build scripts
├── src/
│   ├── commands/               # Command palette command definitions
│   │   ├── dreamnode-commands.ts # DreamNode operations (save, create, delete)
│   │   ├── spatial-commands.ts   # 3D space navigation and layout
│   │   └── git-commands.ts       # Git operations (weave, share, sync)
│   │
│   ├── services/               # Service layer for business logic
│   │   ├── git-service.ts        # Git operations with AI assistance
│   │   ├── dreamnode-service.ts  # DreamNode management
│   │   ├── vault-service.ts      # Obsidian Vault API wrappers
│   │   └── ui-service.ts         # User feedback and notifications
│   │
│   ├── dreamspace/             # Core 3D/spatial domain logic
│   │   ├── nodes/              # DreamNode "game objects"
│   │   │   ├── NodeObject.tsx    # The <mesh> and R3F logic for a node
│   │   │   └── useNodeState.ts   # Hook for managing a single node's state
│   │   │
│   │   ├── DreamspaceCanvas.tsx # Main R3F Canvas component
│   │   └── DreamspaceView.ts   # Obsidian WorkspaceLeaf integration
│   │
│   ├── features/               # Self-contained features (Vertical Slices)
│   │   ├── repo-management/    # Creating, renaming, bundling nodes
│   │   │   ├── RepoPanel.tsx     # The UI panel for this feature
│   │   │   ├── useGitBundle.ts   # Hook for bundling logic
│   │   │   └── README.md         # AI-readable summary of this feature
│   │   │
│   │   └── dream-talk/         # Media viewing for selected nodes
│   │       ├── DreamTalk.tsx     # The main component
│   │       └── README.md
│   │
│   ├── components/             # Shared UI (Atomic Design)
│   │   ├── atoms/              # Basic building blocks
│   │   │   ├── Button.tsx
│   │   │   └── Input.tsx
│   │   │
│   │   └── molecules/          # Composed components
│   │       └── Modal.tsx
│   │
│   └── types/                  # TypeScript type definitions
│       ├── dreamnode.ts          # DreamNode type definitions
│       └── spatial.ts            # 3D space type definitions
│
└── styles.css                  # Plugin-specific styles

3. The Development Workflow: Rules of the Game

To maintain architectural coherence, we will follow these rules when developing:

Rule #1: Commands Before UI. Before building any UI component, create the command palette commands it will use. Start with stub commands that log what would happen, then build the UI to call those commands.

Rule #2: Service Layer Abstraction. Commands delegate to services, never perform git operations directly. Services handle the actual business logic and can be tested independently.

Rule #3: UI Calls Commands. UI components use this.app.commands.executeCommandById() to trigger operations. Never call services directly from UI - always go through the command palette.

Rule #4: Default to the Feature Slice. When creating a new component, hook, or utility, always create it inside the folder of the feature it belongs to. For example, a new button for managing Git history goes in /features/git-history/GitButton.tsx. This keeps features highly cohesive and AI-friendly by default.

Rule #5: Promote to Shared Only on Second Use. Do not abstract prematurely. Only when you need to use a component in a second feature should you “promote” it to the shared /components directory. The process is a simple refactoring task perfect for an AI: “Take /features/git-history/GitButton.tsx, move it to /components/atoms/Button.tsx, make its props generic, and update the import paths.”

Rule #6: The /dreamspace is for Core Spatial Logic. The /dreamspace folder is special. It is not a user-facing feature; it is the fundamental “engine” of the application. It contains the 3D canvas, camera controls, and the base logic for rendering and interacting with nodes and edges. UI panels that interact with the dreamspace (like a details panel) are considered separate features and belong in the /features directory.

Rule #7: Document for the AI. Every feature folder in /features/ should contain a README.md. This file will serve as a high-level summary for the AI.

Example /features/repo-management/README.md: This feature handles all repository management tasks. It provides a UI (RepoPanel.tsx) for users to create, rename, and bundle DreamNodes. It calls commands like 'interbrain:create-dreamnode' and 'interbrain:weave-dreams' which delegate to the GitService for actual operations.

4. Command Palette Integration Patterns

Command Registration:

// In main.ts
this.addCommand({
  id: 'save-dreamnode',
  name: 'Save DreamNode',
  callback: async () => {
    const node = this.getCurrentDreamNode();
    await this.services.git.commitWithAI(node);
    this.services.ui.showSuccess('DreamNode saved');
  }
});

UI Integration:

// In React components
const handleSave = () => {
  // @ts-ignore - Obsidian app is available globally
  app.commands.executeCommandById('interbrain:save-dreamnode');
};

Service Layer:

// Services handle actual business logic
export class GitService {
  async commitWithAI(dreamNode: DreamNode) {
    const message = await this.generateCommitMessage(dreamNode);
    await this.executeShellCommand(`git commit -m "${message}"`);
  }
}

This workflow gives you a clear, powerful, and token-efficient way to build your application, leveraging the strengths of your AI assistant at every step. It respects the interconnected nature of your front-end while providing clean abstraction between UI and backend operations through the command palette.