repoburg 1.2.0 → 1.2.2

package/visual-editor-proxy/node_modules/undici-types/util.d.ts

@@ -0,0 +1,18 @@
+export namespace util {
+  /**
+   * Retrieves a header name and returns its lowercase value.
+   * @param value Header name
+   */
+  export function headerNameToString(value: string | Buffer): string;
+
+  /**
+   * Receives a header object and returns the parsed value.
+   * @param headers Header object
+   * @param obj Object to specify a proxy object. Used to assign parsed values.
+   * @returns If `obj` is specified, it is equivalent to `obj`.
+   */
+  export function parseHeaders(
+    headers: (Buffer | string | (Buffer | string)[])[],
+    obj?: Record<string, string | string[]>
+  ): Record<string, string | string[]>;
+}

package/visual-editor-proxy/node_modules/undici-types/webidl.d.ts

@@ -0,0 +1,228 @@
+// These types are not exported, and are only used internally
+
+/**
+ * Take in an unknown value and return one that is of type T
+ */
+type Converter<T> = (object: unknown) => T
+
+type SequenceConverter<T> = (object: unknown, iterable?: IterableIterator<T>) => T[]
+
+type RecordConverter<K extends string, V> = (object: unknown) => Record<K, V>
+
+interface ConvertToIntOpts {
+  clamp?: boolean
+  enforceRange?: boolean
+}
+
+interface WebidlErrors {
+  exception (opts: { header: string, message: string }): TypeError
+  /**
+   * @description Throw an error when conversion from one type to another has failed
+   */
+  conversionFailed (opts: {
+    prefix: string
+    argument: string
+    types: string[]
+  }): TypeError
+  /**
+   * @description Throw an error when an invalid argument is provided
+   */
+  invalidArgument (opts: {
+    prefix: string
+    value: string
+    type: string
+  }): TypeError
+}
+
+interface WebidlUtil {
+  /**
+   * @see https://tc39.es/ecma262/#sec-ecmascript-data-types-and-values
+   */
+  Type (object: unknown):
+    | 'Undefined'
+    | 'Boolean'
+    | 'String'
+    | 'Symbol'
+    | 'Number'
+    | 'BigInt'
+    | 'Null'
+    | 'Object'
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#abstract-opdef-converttoint
+   */
+  ConvertToInt (
+    V: unknown,
+    bitLength: number,
+    signedness: 'signed' | 'unsigned',
+    opts?: ConvertToIntOpts
+  ): number
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#abstract-opdef-converttoint
+   */
+  IntegerPart (N: number): number
+
+  /**
+   * Stringifies {@param V}
+   */
+  Stringify (V: any): string
+
+  /**
+   * Mark a value as uncloneable for Node.js.
+   * This is only effective in some newer Node.js versions.
+   */
+  markAsUncloneable (V: any): void
+}
+
+interface WebidlConverters {
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-DOMString
+   */
+  DOMString (V: unknown, prefix: string, argument: string, opts?: {
+    legacyNullToEmptyString: boolean
+  }): string
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-ByteString
+   */
+  ByteString (V: unknown, prefix: string, argument: string): string
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-USVString
+   */
+  USVString (V: unknown): string
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-boolean
+   */
+  boolean (V: unknown): boolean
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-any
+   */
+  any <Value>(V: Value): Value
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-long-long
+   */
+  ['long long'] (V: unknown): number
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-unsigned-long-long
+   */
+  ['unsigned long long'] (V: unknown): number
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-unsigned-long
+   */
+  ['unsigned long'] (V: unknown): number
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-unsigned-short
+   */
+  ['unsigned short'] (V: unknown, opts?: ConvertToIntOpts): number
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#idl-ArrayBuffer
+   */
+  ArrayBuffer (V: unknown): ArrayBufferLike
+  ArrayBuffer (V: unknown, opts: { allowShared: false }): ArrayBuffer
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-buffer-source-types
+   */
+  TypedArray (
+    V: unknown,
+    TypedArray: NodeJS.TypedArray | ArrayBufferLike
+  ): NodeJS.TypedArray | ArrayBufferLike
+  TypedArray (
+    V: unknown,
+    TypedArray: NodeJS.TypedArray | ArrayBufferLike,
+    opts?: { allowShared: false }
+  ): NodeJS.TypedArray | ArrayBuffer
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-buffer-source-types
+   */
+  DataView (V: unknown, opts?: { allowShared: boolean }): DataView
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#BufferSource
+   */
+  BufferSource (
+    V: unknown,
+    opts?: { allowShared: boolean }
+  ): NodeJS.TypedArray | ArrayBufferLike | DataView
+
+  ['sequence<ByteString>']: SequenceConverter<string>
+  
+  ['sequence<sequence<ByteString>>']: SequenceConverter<string[]>
+
+  ['record<ByteString, ByteString>']: RecordConverter<string, string>
+
+  [Key: string]: (...args: any[]) => unknown
+}
+
+export interface Webidl {
+  errors: WebidlErrors
+  util: WebidlUtil
+  converters: WebidlConverters
+
+  /**
+   * @description Performs a brand-check on {@param V} to ensure it is a
+   * {@param cls} object.
+   */
+  brandCheck <Interface>(V: unknown, cls: Interface, opts?: { strict?: boolean }): asserts V is Interface
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-sequence
+   * @description Convert a value, V, to a WebIDL sequence type.
+   */
+  sequenceConverter <Type>(C: Converter<Type>): SequenceConverter<Type>
+
+  illegalConstructor (): never
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#es-to-record
+   * @description Convert a value, V, to a WebIDL record type.
+   */
+  recordConverter <K extends string, V>(
+    keyConverter: Converter<K>,
+    valueConverter: Converter<V>
+  ): RecordConverter<K, V>
+
+  /**
+   * Similar to {@link Webidl.brandCheck} but allows skipping the check if third party
+   * interfaces are allowed.
+   */
+  interfaceConverter <Interface>(cls: Interface): (
+    V: unknown,
+    opts?: { strict: boolean }
+  ) => asserts V is typeof cls
+
+  // TODO(@KhafraDev): a type could likely be implemented that can infer the return type
+  // from the converters given?
+  /**
+   * Converts a value, V, to a WebIDL dictionary types. Allows limiting which keys are
+   * allowed, values allowed, optional and required keys. Auto converts the value to
+   * a type given a converter.
+   */
+  dictionaryConverter (converters: {
+    key: string,
+    defaultValue?: () => unknown,
+    required?: boolean,
+    converter: (...args: unknown[]) => unknown,
+    allowedValues?: unknown[]
+  }[]): (V: unknown) => Record<string, unknown>
+
+  /**
+   * @see https://webidl.spec.whatwg.org/#idl-nullable-type
+   * @description allows a type, V, to be null
+   */
+  nullableConverter <T>(
+    converter: Converter<T>
+  ): (V: unknown) => ReturnType<typeof converter> | null
+
+  argumentLengthCheck (args: { length: number }, min: number, context: string): void
+}

package/visual-editor-proxy/node_modules/undici-types/websocket.d.ts

@@ -0,0 +1,150 @@
+/// <reference types="node" />
+
+import type { Blob } from 'buffer'
+import type { MessagePort } from 'worker_threads'
+import {
+  EventInit,
+  EventListenerOptions,
+  AddEventListenerOptions,
+  EventListenerOrEventListenerObject
+} from './patch'
+import Dispatcher from './dispatcher'
+import { HeadersInit } from './fetch'
+
+export type BinaryType = 'blob' | 'arraybuffer'
+
+interface WebSocketEventMap {
+  close: CloseEvent
+  error: ErrorEvent
+  message: MessageEvent
+  open: Event
+}
+
+interface WebSocket extends EventTarget {
+  binaryType: BinaryType
+  
+  readonly bufferedAmount: number
+  readonly extensions: string
+
+  onclose: ((this: WebSocket, ev: WebSocketEventMap['close']) => any) | null
+  onerror: ((this: WebSocket, ev: WebSocketEventMap['error']) => any) | null
+  onmessage: ((this: WebSocket, ev: WebSocketEventMap['message']) => any) | null
+  onopen: ((this: WebSocket, ev: WebSocketEventMap['open']) => any) | null
+
+  readonly protocol: string
+  readonly readyState: number
+  readonly url: string
+
+  close(code?: number, reason?: string): void
+  send(data: string | ArrayBufferLike | Blob | ArrayBufferView): void
+
+  readonly CLOSED: number
+  readonly CLOSING: number
+  readonly CONNECTING: number
+  readonly OPEN: number
+
+  addEventListener<K extends keyof WebSocketEventMap>(
+    type: K,
+    listener: (this: WebSocket, ev: WebSocketEventMap[K]) => any,
+    options?: boolean | AddEventListenerOptions
+  ): void
+  addEventListener(
+    type: string,
+    listener: EventListenerOrEventListenerObject,
+    options?: boolean | AddEventListenerOptions
+  ): void
+  removeEventListener<K extends keyof WebSocketEventMap>(
+    type: K,
+    listener: (this: WebSocket, ev: WebSocketEventMap[K]) => any,
+    options?: boolean | EventListenerOptions
+  ): void
+  removeEventListener(
+    type: string,
+    listener: EventListenerOrEventListenerObject,
+    options?: boolean | EventListenerOptions
+  ): void
+}
+
+export declare const WebSocket: {
+  prototype: WebSocket
+  new (url: string | URL, protocols?: string | string[] | WebSocketInit): WebSocket
+  readonly CLOSED: number
+  readonly CLOSING: number
+  readonly CONNECTING: number
+  readonly OPEN: number
+}
+
+interface CloseEventInit extends EventInit {
+  code?: number
+  reason?: string
+  wasClean?: boolean
+}
+
+interface CloseEvent extends Event {
+  readonly code: number
+  readonly reason: string
+  readonly wasClean: boolean
+}
+
+export declare const CloseEvent: {
+  prototype: CloseEvent
+  new (type: string, eventInitDict?: CloseEventInit): CloseEvent
+}
+
+interface MessageEventInit<T = any> extends EventInit {
+  data?: T
+  lastEventId?: string
+  origin?: string
+  ports?: (typeof MessagePort)[]
+  source?: typeof MessagePort | null
+}
+
+interface MessageEvent<T = any> extends Event {
+  readonly data: T
+  readonly lastEventId: string
+  readonly origin: string
+  readonly ports: ReadonlyArray<typeof MessagePort>
+  readonly source: typeof MessagePort | null
+  initMessageEvent(
+    type: string,
+    bubbles?: boolean,
+    cancelable?: boolean,
+    data?: any,
+    origin?: string,
+    lastEventId?: string,
+    source?: typeof MessagePort | null,
+    ports?: (typeof MessagePort)[]
+  ): void;
+}
+
+export declare const MessageEvent: {
+  prototype: MessageEvent
+  new<T>(type: string, eventInitDict?: MessageEventInit<T>): MessageEvent<T>
+}
+
+interface ErrorEventInit extends EventInit {
+  message?: string
+  filename?: string
+  lineno?: number
+  colno?: number
+  error?: any
+}
+
+interface ErrorEvent extends Event {
+  readonly message: string
+  readonly filename: string
+  readonly lineno: number
+  readonly colno: number
+  readonly error: any
+}
+
+export declare const ErrorEvent: {
+  prototype: ErrorEvent
+  new (type: string, eventInitDict?: ErrorEventInit): ErrorEvent
+}
+
+interface WebSocketInit {
+  protocols?: string | string[],
+  dispatcher?: Dispatcher,
+  headers?: HeadersInit
+}

package/visual-editor-proxy/package.json

@@ -0,0 +1,21 @@
+{
+  "name": "visual-editor-proxy",
+  "version": "1.0.0",
+  "description": "Proxy server for Repoburg Visual Editor",
+  "main": "dist/main.js",
+  "scripts": {
+    "start": "node dist/main.js",
+    "dev": "npm run build && node dist/main.js",
+    "build": "tsc && npm run build:client",
+    "build:client": "esbuild client/src/main.ts --bundle --outfile=client/dist/main.js --minify"
+  },
+  "devDependencies": {
+    "@types/express": "^4.17.21",
+    "@types/node": "^20.12.12",
+    "esbuild": "^0.21.4",
+    "ts-node": "^10.9.2",
+    "typescript": "^5.4.5"
+  },
+  "author": "",
+  "license": "ISC"
+}

package/visual-editor-proxy/tsconfig.json

@@ -0,0 +1,21 @@
+{
+  "compilerOptions": {
+    "module": "commonjs",
+    "declaration": true,
+    "removeComments": true,
+    "emitDecoratorMetadata": true,
+    "experimentalDecorators": true,
+    "allowSyntheticDefaultImports": true,
+    "target": "es2021",
+    "sourceMap": true,
+    "outDir": "./dist",
+    "baseUrl": "./",
+    "incremental": true,
+    "skipLibCheck": true,
+    "strictNullChecks": false,
+    "noImplicitAny": false,
+    "strictBindCallApply": false,
+    "forceConsistentCasingInFileNames": false,
+    "noFallthroughCasesInSwitch": false
+  }
+}

package/CODEBASE_MAP.md

@@ -1,212 +0,0 @@
-# Codebase Map: Your Guide to navigating This Project
-
-This document is a high-level map for AI agents and developers to understand the structure and purpose of this monorepo. It is generated by traversing the file tree and summarizing each component's role.
-
-## 1. Project Overview
-
-This project is an AI-powered coding assistant designed to help developers understand, refactor, and generate code. It consists of several key components: a **backend** service that orchestrates AI interactions, a **frontend** web application for user interaction, and a **daemon** for local machine operations.
-
----
-
-## 2. Root Level & Project Configuration
-
-This section describes the key files at the root of the monorepo that define its structure and behavior.
-
--   `package.json`: The main configuration file for the monorepo.
-    -   **`workspaces`**: Defines the packages that make up the monorepo (`frontend`, `backend`, `website`, `daemon`).
-    -   **`bin`**: This is critical. It registers the command-line executables (`repoburg`, `repoburg-daemon`, `repoburg-backend`) that are made available when the package is installed globally.
-    -   **`scripts`**: Contains top-level scripts for running, building, and developing the various workspaces.
--   `platform-cli.js`: The implementation of the main `repoburg` command-line tool. It's a Node.js script that uses `commander` to parse arguments and makes HTTP requests to the local `daemon` API to manage services (start, stop, list, etc.).
--   `postinstall.js`: A script that runs automatically after `npm install`. Its purpose is to set the correct executable permissions (`chmod 755`) for the bundled binaries (`rg`, `tree`) located within the `backend` package.
-
----
-
-## 3. Backend (`/backend`)
-
-The backend is a NestJS application responsible for the core logic of the AI assistant. It manages state, orchestrates multi-step AI tasks, and handles all database interactions.
-
-### Key Backend Modules (`backend/src/`)
-
--   #### `orchestration/`
-    -   **Purpose**: This module is the heart of the system's automation capabilities. It manages the execution of "Orchestration Scripts" - multi-step tasks where each step is a prompt sent to the LLM. It's a state machine that can run, pause, stop, and resume these long-running tasks.
-    -   **Key Files**:
-        -   `orchestration.service.ts`: The core engine. It manages the state of the active orchestration run (e.g., `RUNNING`, `PAUSED`, `WAITING_FOR_LLM_RESPONSE`). It's a singleton that controls the step-by-step execution loop.
-        -   `orchestration.controller.ts`: The public-facing REST API. Exposes endpoints for two primary functions: Script Management (CRUD for orchestration files) and Execution Control (start, stop, proceed, etc.).
-        -   `orchestration-fs.service.ts`: A dedicated service to handle all file system operations for orchestration scripts, which are stored in `.repoburg/orchestrations`. It manages the original scripts (`.rc.md`) and the temporary "run" copies (`.run.rc.md`) that are consumed during execution.
-        -   `orchestration-parser.service.ts`: A simple utility that parses a script file, splitting it into an array of distinct prompts based on the `$$$$` separator.
-        -   `orchestration.types.ts`: Defines the critical data structures and enums (`OrchestrationStatus`, `OrchestrationMode`, `OrchestrationRunState`) that govern the state machine.
-
--   #### `sessions/`
-    -   **Purpose**: Manages the lifecycle of a user's interaction. A `Session` is the primary container for a conversation or task, holding together user prompts, AI responses, and associated context (like the system prompt and context templates). This module handles creating, retrieving, updating, and deleting these sessions from the database.
-    -   **Key Files**:
-        -   `sessions.service.ts`: Contains the core business logic for session management. It performs all database operations (CRUD) for the `Session` entity and handles the logic for setting the "active" session for the application.
-        -   `sessions.controller.ts`: The REST API for sessions. It exposes endpoints for managing the entire lifecycle of a session, including creating new sessions, listing existing ones, setting the active session, and importing/exporting sessions.
-        -   `session.dto.ts`: Defines the data transfer objects and enums (`SessionStatus`) used for validating API requests and structuring responses.
-
--   #### `session-inputs/`
-    -   **Purpose**: Represents a single "turn" or interaction within a `Session`. This module's primary responsibility is to take a user's raw prompt and assemble the final, complete context string that will be sent to the LLM. It acts as the preparation and dispatch layer for LLM calls.
-    -   **Key Files**:
-        -   `session-inputs.service.ts`: The main service that orchestrates the creation of a `SessionInput`. It triggers the context generation process and then hands off the final prompt to the `ChatService` for the actual LLM interaction.
-        -   `session-input-context.service.ts`: A critical service responsible for **assembling the context**. It combines context from multiple sources: context templates, ad-hoc file/folder requests, and reusable `!snippet` commands. It also enforces token limits. **Look here to understand how prompts are built.**
-        -   `session-inputs.controller.ts`: The REST API for creating new turns within a session. It's nested under `/sessions/:sessionId/inputs`.
-
--   #### `interactive-chat/`
-    -   **Purpose**: Manages the stateful, turn-by-turn conversation with the LLM. It holds the history of a conversation for each session, provides it to the LLM provider for context, and handles the actual `generateContent` call. It distinguishes between an "integrated" flow (where it calls the LLM and processes the response automatically) and a "manual" flow (where it just emits the generated prompt for an external tool to use).
-    -   **Key Files**:
-        -   `chat.service.ts`: The core of the module. It maintains a map of `ChatState` (history and system prompt) for each session. Its `sendMessage` method is the primary entry point for communicating with the LLM.
-
--   #### `llm-provider/`
-    -   **Purpose**: An abstraction layer for communicating with any Large Language Model. It defines a generic `LlmProvider` interface that the rest of the application uses, decoupling the core logic from any specific LLM implementation (like Gemini).
-    -   **Key Files**:
-        -   `llm-provider.interface.ts`: Defines the contract for any LLM provider, including the `generateContent` method and the data structures for requests. It also defines the `LLM_PROVIDER` injection token.
-        -   `llm-provider.module.ts`: Wires up the concrete implementation. This is where you would swap `GeminiLlmProvider` for another provider if needed.
-
--   #### `gemini/`
-    -   **Purpose**: The concrete implementation of the `LlmProvider` interface for Google's Gemini models. It handles authentication, error parsing, and the specifics of making streaming API calls to the Gemini service.
-    -   **Key Files**:
-        -   `gemini-llm.provider.ts`: Implements the `generateContent` method. It uses the `gemini-core` package to manage configuration and authentication, constructs the request with history and system prompts, and processes the streaming response.
-
--   #### `llm-response-parser/`
-    -   **Purpose**: A crucial utility that acts as a translator. It takes the raw, semi-structured text response from the LLM and parses it into validated, machine-readable `AIActionDto` objects. This module is the bridge between the LLM's output and the structured actions the system can execute.
-    -   **Key Files**:
-        -   `llm-response-parser.service.ts`: Contains the primary `parse` method, which splits a response into an optional "explanation" and a series of action blocks. It handles various edge cases like missing end tags.
-        -   `parsing.constants.ts`: Defines the special tags (e.g., `ACTION_ITEM_START`) and field names (e.g., `¦FilePath¦`) that form the contract for the LLM's structured output.
-        -   `dto/ai-action.dto.ts`: Defines the `AIActionDto` class, the structured data format that is the output of this service.
-
--   #### `ai-actions/`
-    -   **Purpose**: This module translates the LLM's textual response into structured, executable actions (`AIAction`). It manages the entire lifecycle of these actions, from creation and parsing to execution, state changes (e.g., approving, reverting), and batch operations.
-    -   **Key Files**:
-        -   `ai-action-creation.service.ts`: The entry point for this module. It takes the raw string from the LLM, uses the `LlmResponseParserService` to turn it into `AIActionDto` objects, and then creates the initial `AIAction` database records. It contains different logic paths based on the execution strategy (`review_first`, `apply_revert`, `auto_apply`).
-        -   `ai-actions.service.ts`: Manages the state and lifecycle of a **single** `AIAction`. It contains the core logic for operations like `approveAction`, `discardAction`, `confirmKeepAction`, and, most importantly, `revertAction`, which knows how to undo file system changes.
-        -   `ai-action-batch.service.ts`: Handles operations on a **group** of actions for a given `SessionInput`. This is used by the controller for "Apply All", "Revert All", etc. It orchestrates calls to `AIActionsService` for individual actions.
-        -   `ai-actions.controller.ts`: The REST API that exposes both single-action controls (e.g., approve one action) and batch controls (e.g., revert all actions for an input).
-
--   #### `action-execution/`
-    -   **Purpose**: This is the lowest-level module responsible for the actual execution of file system and shell commands. It is a critical security boundary, ensuring that all operations are safe and restricted to the project's workspace.
-    -   **Key Files**:
-        -   `action-execution.service.ts`: A simple service with methods like `createFile`, `editFile`, `deleteFile`, and `runCommand`. Its most important feature is the `resolveAndValidatePath` method, which prevents path traversal attacks by ensuring all file paths are relative and within the project's root directory.
-
----
-
-## 4. Frontend (`/frontend`)
-
-The frontend is a Next.js application built with React and TypeScript. It provides the entire user interface for interacting with the AI assistant. It uses `Zustand` for state management and `Shadcn/ui` for the component library.
-
-### Key Frontend Pages (`frontend/src/app/components/pages/`)
-This directory contains the top-level components for each major screen of the application.
-
--   #### Core Workflow & Interaction
-    -   `MainHomePage.tsx`: The main application router. It displays a dashboard of navigation cards and renders the other page components based on the current application state. **This is the main hub of the UI.**
-    -   `PlanInteractionPage.tsx`: The primary screen for interacting with the AI's generated plan. It displays the list of `ActionItemBlock` components, allowing the user to approve, discard, revert, or confirm actions.
-    -   `SessionHistoryPage.tsx`: Displays a table of all past sessions, allowing users to load, delete, import/export, or create follow-up sessions.
-
--   #### Customization & Management
-    -   `ContextManagementPage.tsx`: A CRUD interface for managing `Context Templates`, which are used to build prompts.
-    -   `SystemPromptsManagementPage.tsx`: A CRUD interface for managing `System Prompts`, which define the AI's core behavior.
-    -   `OrchestrationsManagementPage.tsx`: A CRUD interface for managing and running multi-step automation scripts (`Orchestration Scripts`).
-    -   `ContextSnippetsManagementPage.tsx`: A CRUD interface for managing dynamic `Prompt Snippets` (e.g., `!my-snippet`) that can be used in prompts.
-    -   `CustomSnippetsManagementPage.tsx`: (Likely deprecated or for internal use) A CRUD interface for `Template Snippets` used within the template editor itself.
-    -   `SettingsPage.tsx`: A page for configuring global and session-level settings, such as execution strategy, manual LLM mode, and platform updates.
-    -   `IntegrationsPage.tsx`: Provides instructions and links for installing external integrations, like the AI Studio PowerTools userscript.
-
-### Key Frontend Components (`frontend/src/app/components/`)
-This section describes the key sub-directories containing the building blocks for the pages above.
-
--   #### `session/`
-    -   **Purpose**: Contains all the components that make up the primary user interaction view: the chat history, the prompt input box, and the session control panel.
-    -   **Key Files**:
-        -   `CurrentSessionPage.tsx`: The main orchestrator for the session view. It assembles the `SessionControls`, `ConversationDisplay`, and `PromptInput` into a complete, interactive page. It also manages the state for the `@`, `#`, and `!` context pickers.
-        -   `ConversationDisplay.tsx`: Renders the list of turns in a conversation by mapping over session inputs and displaying `UserMessageBlock` and `AIMessageBlock` components.
-        -   `PromptInput.tsx`: The main textarea for user input. It handles prompt submission, keyboard shortcuts, and the logic for adding ad-hoc context.
-        -   `SessionControls.tsx`: The left-hand panel in the UI, which groups together session actions, information, and settings.
-        -   `AIMessageBlock.tsx` & `UserMessageBlock.tsx`: Components that render a single turn in the conversation for the AI and the user, respectively.
-        -   `ManualLLMInterface.tsx`: A special component that only appears when "Manual LLM" mode is active, providing the UI for copying the prepared prompt and pasting the LLM's response.
-
--   #### `plan/`
-    -   **Purpose**: Contains the components used to build the `PlanInteractionPage`. These are responsible for displaying each AI-proposed action, showing code diffs, and providing the controls to manage them.
-    -   **Key Files**:
-        -   `ActionItemBlock.tsx`: The main collapsible component for a single AI action. It assembles the header, content, and footer.
-        -   `ActionItemHeader.tsx`: Displays the title, type, and status of an action.
-        -   `ActionItemContent.tsx`: The body of the block. It intelligently renders a `DiffEditor` for code changes, a summary for `run_command` actions, or the list of requested items for `request_context`.
-        -   `ActionItemFooter.tsx`: Displays the contextual buttons for a single action (e.g., "Approve", "Revert") based on the current execution strategy and action status.
-        -   `PlanGlobalControls.tsx`: The header bar on the plan page that contains batch-action buttons like "Apply All Approved" or "Revert All".
-        -   `ExecutionLogSummary.tsx`: A summary view at the bottom of the page that displays the final outcome of any executed actions.
-
-### Frontend Data Layer
-
--   #### `lib/api/`
-    -   **Purpose**: This directory contains the client-side functions for making requests to the `backend` API. It acts as a typed SDK for the frontend. Each file typically corresponds to a specific controller on the backend (e.g., `session.ts` for `SessionsController`).
-    -   **Key Files**:
-        -   `client.ts`: Contains the base `handleResponse` logic for all API calls, standardizing error handling and JSON parsing. It also determines the backend API URL.
-        -   `index.ts`: Exports all API functions for easy consumption by the state stores.
-
--   #### `store/`
-    -   **Purpose**: This is the global state management layer, built with Zustand. It centralizes all application state and the logic for mutating that state. UI components primarily read from these stores and call their action functions.
-    -   **Key Files**:
-        -   `sessionStore.ts`: **The main store for the application.** It combines several "slices" to manage all aspects of a user's session, including the session data itself, UI state, and action logic.
-        -   `session/*.slice.ts`: These files break down the `sessionStore` into logical units: `session.slice` for session lifecycle, `actions.slice` for handling AI actions, `manualLlm.slice` for the manual workflow, and `ui.slice` for UI state.
-        -   Other store files (`contextTemplateStore.ts`, `systemPromptStore.ts`, etc.): These are standalone stores that manage the state for specific management pages (e.g., the list of all context templates).
-
----
-
-## 5. Daemon (`/daemon`)
-
-The daemon is a persistent background service that runs on the user's local machine. It is responsible for managing the lifecycle of backend services and handling system-level tasks like authentication and updates. It communicates via a local REST API on port `9998`.
-
-### Key Daemon Components (`daemon/src/`)
-
--   `index.ts`: The entry point for the daemon. It sets up an Express server and WebSocket server to handle incoming requests.
--   `serviceManager.ts`: The core logic for managing backend processes. It uses `pm2` to start, stop, restart, and monitor backend instances for different projects.
--   `stateManager.ts`: A singleton that persists the daemon's state (list of services, active port) to a JSON file in `~/.repoburg/services.json`.
--   `authManager.ts`: Handles all authentication logic. It verifies JWTs received from the website, stores them securely, and checks their validity. The public key for JWT verification is hardcoded here.
--   `api/`: This directory defines the REST endpoints for the daemon:
-    -   `services.ts`: Endpoints for managing services (start, stop, list, etc.).
-    -   `auth.ts`: Endpoints for the device authentication flow (initiating login, checking status).
-    -   `registry.ts`: Endpoints for the frontend to register its port, so the daemon knows which UI to open.
-    -   `system.ts`: Endpoints for system-level operations like triggering a self-update.
--   `middleware/checkAuth.ts`: An Express middleware that protects sensitive daemon endpoints by verifying the user's authentication status via `authManager`.
-
----
-
-## 6. Daemon Desktop (`/daemon-desktop`)
-
-This is an Electron application that provides a graphical user interface for the `daemon`. It allows users to manage services, check daemon status, and handle updates without using the command line.
-
-### Key Desktop Components (`daemon-desktop/src/`)
-
--   `main.ts`: The Electron **main process**. Its primary responsibility is to create the application window and to spawn/manage the `repoburg-daemon` as a child process. It also handles all native OS interactions (like file dialogs) and exposes them securely to the UI via IPC.
--   `preload.ts`: The Electron **preload script**. This is a critical security layer that creates a bridge between the Node.js environment of the main process and the browser environment of the renderer process. It defines the `window.electronAPI` object, which is the only way the React app can communicate with the main process.
--   `renderer.tsx` & `App.tsx`: The **renderer process**, which is the React application itself. `App.tsx` is the root component that builds the UI. It uses the `window.electronAPI` to send commands to the main process (e.g., to start the daemon or list services) and listens for status updates.
-
----
-
-## 7. Website (`/website`)
-
-This is a Next.js application that serves as the public-facing homepage, documentation site, and user authentication portal for the entire Repoburg service.
-
-### Key Website Components (`website/src/app/`)
-
--   `/page.tsx`: The main public landing page for the project.
--   `/docs`: The documentation section. It uses Markdown files from the same directory and a dynamic slug route (`[[...slug]]/page.tsx`) to render the content.
--   `/login`, `/profile`, `/dashboard`: These pages handle user authentication and account management, using Supabase for the backend. The dashboard provides a web interface to see and manage services controlled by the local daemon.
--   `/api/`: Contains server-side API routes crucial for the authentication flow.
-    -   `device/initiate`: Called by the `daemon` to start the device authorization process. It creates a unique device code and returns a login URL.
-    -   `device/poll`: Polled by the `daemon` to check if a user has approved the device code. Returns the access token once approved.
-    -   `daemon/token`: Generates short-lived tokens for authenticated browser sessions to make authorized requests to the local daemon.
-
----
-
-## 8. Userscripts (`/userscripts`)
-
-This package contains the source code for the "AI Studio PowerTools" Tampermonkey userscript. This script is designed to be installed in a user's browser to create a seamless integration between the Repoburg application and Google's AI Studio (or a similar web-based LLM).
-
-### Key Userscript Components (`userscripts/src/`)
-
--   `index.ts`: The main entry point for the userscript. It initializes all features, including querying the local daemon to find the active backend port.
--   `webSocketHandler.ts`: Connects to the Repoburg backend's WebSocket server. It listens for `llm-input-generated` events and automatically triggers the `pasteAndRun` action in AI Studio.
--   `hotkeys.ts`: Sets up global keyboard shortcuts (e.g., `Cmd+\`) that work on the AI Studio page to trigger specific actions.
--   `copyAndSubmit.ts`: Implements the `Cmd+\` functionality. It programmatically copies the latest AI response from the page and submits it to the Repoburg backend via an HTTP request.
--   `pasteAndRun.ts`: Implements the `Cmd+'` functionality. It reads from the clipboard and pastes the content into the AI Studio prompt box, then programmatically clicks the "Run" button.
--   `clipboardInterceptor.ts`: A clever utility that patches the browser's native clipboard functions (`writeText` and `execCommand('copy')`) to reliably capture the content being copied by the AI Studio web app.
--   `autoSubmitOnFinish.ts`: A feature that uses a `MutationObserver` to detect when the AI has finished generating a response, then automatically triggers the `copyAndSubmit` flow.
--   `settingsUI.ts` & `settingsManager.ts`: Provides an on-page settings panel to configure the userscript's behavior, such as the Repoburg URL and execution strategy.