repoburg 1.2.0 → 1.2.2

package/.run/backend _ build.run.xml

@@ -0,0 +1,12 @@
+<component name="ProjectRunConfigurationManager">
+  <configuration default="false" name="backend &gt; build" type="js.build_tools.npm" nameIsGenerated="true">
+    <package-json value="$PROJECT_DIR$/backend/package.json" />
+    <command value="run" />
+    <scripts>
+      <script value="build" />
+    </scripts>
+    <node-interpreter value="project" />
+    <envs />
+    <method v="2" />
+  </configuration>
+</component>

package/.run/backend _ lint.run.xml

@@ -0,0 +1,12 @@
+<component name="ProjectRunConfigurationManager">
+  <configuration default="false" name="backend &gt; lint" type="js.build_tools.npm" nameIsGenerated="true">
+    <package-json value="$PROJECT_DIR$/backend/package.json" />
+    <command value="run" />
+    <scripts>
+      <script value="lint" />
+    </scripts>
+    <node-interpreter value="project" />
+    <envs />
+    <method v="2" />
+  </configuration>
+</component>

package/.run/backend _ test.run.xml

@@ -0,0 +1,12 @@
+<component name="ProjectRunConfigurationManager">
+  <configuration default="false" name="backend &gt; test" type="js.build_tools.npm" nameIsGenerated="true">
+    <package-json value="$PROJECT_DIR$/backend/package.json" />
+    <command value="run" />
+    <scripts>
+      <script value="test" />
+    </scripts>
+    <node-interpreter value="project" />
+    <envs />
+    <method v="2" />
+  </configuration>
+</component>

package/.run/frontend _ build.run.xml

@@ -0,0 +1,12 @@
+<component name="ProjectRunConfigurationManager">
+  <configuration default="false" name="frontend &gt; build" type="js.build_tools.npm" nameIsGenerated="true">
+    <package-json value="$PROJECT_DIR$/frontend/package.json" />
+    <command value="run" />
+    <scripts>
+      <script value="build" />
+    </scripts>
+    <node-interpreter value="project" />
+    <envs />
+    <method v="2" />
+  </configuration>
+</component>

package/.run/frontend _ lint_fix.run.xml

@@ -0,0 +1,12 @@
+<component name="ProjectRunConfigurationManager">
+  <configuration default="false" name="frontend &gt; lint:fix" type="js.build_tools.npm" nameIsGenerated="true">
+    <package-json value="$PROJECT_DIR$/frontend/package.json" />
+    <command value="run" />
+    <scripts>
+      <script value="lint:fix" />
+    </scripts>
+    <node-interpreter value="project" />
+    <envs />
+    <method v="2" />
+  </configuration>
+</component>

package/CODEMAP.md

@@ -0,0 +1,207 @@
+# Repoburg Codemap
+
+This document provides a high-level overview of the Repoburg system, focusing on all its constituent projects and how they interact.
+
+## System Overview
+
+Repoburg's architecture consists of several key components working together:
+
+1.  **The `backend`**: A NestJS application that runs locally. It has access to the filesystem, manages core logic (sessions, context generation, action execution), and orchestrates the AI workflow. Each `backend` instance is managed by the `daemon`.
+2.  **The `frontend`**: A Next.js web application that serves as the main user interface for Repoburg's AI features. It communicates with a specific `backend` instance to manage sessions, view AI-generated plans, and configure the system.
+3.  **The `userscripts` (AI Studio PowerTools)**: A userscript that runs in the browser on the Google AI Studio website. It acts as the bridge between the AI chat interface and the local `backend` for the "manual mode" workflow.
+4.  **The `daemon`**: A long-running, headless background process that manages `backend` instances using `pm2`. It handles starting, stopping, and monitoring services for different projects and manages device authentication.
+5.  **The `website`**: The public-facing marketing, documentation, and user authentication portal, available at repoburg.com.
+6.  **The `daemon-desktop`**: An Electron-based desktop application that provides a graphical user interface (GUI) for the `daemon`. It allows users to manage services without using the command line.
+7.  **The `visual-editor-proxy`**: A local proxy server that injects a client script into a target frontend application, enabling developers to visually select components and send prompts to the `backend` from their running app.
+
+The core loop is: **Frontend** sends a prompt to the **Backend** -> **Backend** generates context and sends it to an LLM -> The LLM response is sent back to the **Backend** -> **Backend** parses it into a plan -> **Frontend** displays the plan for user review and action. The **Daemon** and **Daemon Desktop** work in the background, managing the lifecycle of the **Backend** service itself. The **Website** handles user accounts and authorizes local devices to use the service. The **Visual Editor Proxy** provides an alternative entry point for initiating this loop directly from a user's own application.
+
+---
+
+## Backend Architecture (`backend/`)
+
+The local server that contains the core application logic.
+
+### 🚀 Entry Point & Core
+
+-   **Entry Point**: `backend/src/main.ts`. Handles server setup, port selection, and global middleware.
+-   **Root Module**: `backend/src/app.module.ts`. Imports all other feature modules.
+-   **Architecture**: Standard NestJS modular architecture (`*.module.ts`, `*.controller.ts`, `*.service.ts`).
+
+### ✨ Key Feature Modules (`backend/src`)
+
+#### Session & Orchestration
+- **`/sessions`**: Manages the lifecycle of a user's work session (create, update, load).
+- **`/session-inputs`**: Handles a single turn of interaction (prompt creation, context generation).
+- **`/session-followup`**: Handles creating new sessions that inherit context from previous ones.
+- **`/session-transfer`**: Manages the import and export of session data.
+- **`/llm-responses`**: Receives and processes raw text responses from the LLM.
+- **`/llm-response-parser`**: Parses raw LLM text into structured actions.
+- **`/ai-actions`**: Manages the individual actions (`create_file`, `run_command`) proposed by the AI.
+- **`/action-execution`**: Performs the file system operations or runs shell commands.
+- **`/execution-logs`**: Stores logs from `action-execution`.
+- **`/interactive-chat`**: Orchestrates sending prompts to an LLM for both integrated and manual modes.
+
+#### Context & Prompting
+- **`/context-generation`**: Renders context strings from Eta.js templates using built-in helper functions.
+- **`/context-templates`**: CRUD module for managing the main context templates.
+- **`/system-prompts`**: CRUD module for managing the system prompts that define the AI's behavior.
+- **`/context-snippets`**: Manages dynamic, reusable context snippets callable with `!` in a prompt.
+- **`/custom-snippets`**: Manages static, reusable code snippets for the template editor.
+
+#### Core Services & Integrations
+- **`/workspace`**: Provides APIs to interact with the local file system (file tree, search, file content).
+- **`/llm-provider` & `/gemini`**: Defines the interface and provides the implementation for the integrated Google Gemini LLM.
+- **`/events`**: The WebSocket gateway for real-time communication between the backend, frontend, and userscripts.
+- **`/application-state`**: Manages global backend settings (e.g., active session, feature flags).
+- **`/mcp`**: Manages connections and tools for the Model Context Protocol (MCP).
+- **`/visual-editor`**: Provides an endpoint for the visual editor's injected client script to submit prompts and context, adapting them into standard session inputs.
+- **`/projects`**: Manages project-specific information.
+- **`/seeding`**: Seeds the database with default data (prompts, templates) on startup.
+- **`/core-entities`**: Contains all TypeORM entity definitions for the database schema.
+- **`/utils`**: Shared utility functions and decorators (e.g., fuzzy search, tracing).
+
+---
+
+## Frontend Architecture (`frontend/`)
+
+The main user interface for interacting with the Repoburg backend.
+
+### 🚀 Tech Stack & Structure
+- **Framework**: Next.js (App Router)
+- **Styling**: Tailwind CSS with shadcn/ui components.
+- **State Management**: Zustand.
+
+### ✨ Key Directories (`frontend/src`)
+
+- **`/app/components`**: Home to the application's React components, organized by feature:
+    - **`/pages`**: Top-level components for each main view (e.g., `MainHomePage`, `SettingsPage`).
+    - **`/editors`**: Specialized editor components for templates, prompts, and snippets.
+    - **`/plan` & `/session`**: Components for displaying AI-generated plans and the conversation history.
+    - **`/common`**: Shared components like the command palette and markdown renderers.
+- **`/components/ui`**: The library of low-level, reusable UI components from shadcn/ui.
+- **`/lib/api`**: A collection of strongly-typed functions that handle all HTTP communication with the `backend` API.
+- **`/store`**: Contains all Zustand state management logic, divided into slices for different features (e.g., `session.slice.ts`, `ui.slice.ts`).
+- **`/hooks`**: Custom React hooks, such as those for managing the Monaco editor theme and setup.
+- **`/types`**: Contains all TypeScript type definitions for API payloads and other shared data structures.
+
+---
+
+## AI Studio PowerTools (`userscripts/`)
+
+The userscript that bridges AI Studio with the local backend for the "manual mode" workflow.
+
+### 🚀 Tech Stack & Structure
+- **Language**: TypeScript.
+- **Bundler**: esbuild (`build.js`).
+- **Deployment**: A single bundled `.user.js` file hosted by the `website` and installed via a browser extension like Tampermonkey.
+
+### ✨ Key Files (`userscripts/src`)
+- **`index.ts`**: The main entry point. It initializes all features and connects to the `daemon` to find the active `backend` port.
+- **`webSocketHandler.ts`**: Manages the persistent WebSocket connection to the `backend`'s `/events` gateway to receive commands (e.g., prompts to paste).
+- **`clipboardInterceptor.ts`**: Patches the browser's native clipboard APIs to reliably capture text copied from AI Studio. This is crucial for the "Copy & Submit" workflow.
+- **`hotkeys.ts`**: Binds keyboard shortcuts (e.g., `Cmd+\`) to trigger actions.
+- **Core Actions**:
+    - `copyAndSubmit.ts`: Implements the "Copy & Submit" workflow, which captures the AI's response and sends it to the `backend`.
+    - `pasteAndRun.ts`: Implements the "Paste & Run" workflow, which takes text (from clipboard or WebSocket) and pastes it into the AI Studio prompt input.
+    - `scrollAndCopy.ts`: A helper action that scrolls to the bottom of the AI response and copies it.
+- **`settingsManager.ts` & `settingsUI.ts`**: Create and manage a settings panel injected directly into the AI Studio page.
+
+---
+
+## Daemon Architecture (`daemon/`)
+
+A lightweight, persistent background process that acts as a process manager and authentication proxy.
+
+### 🚀 Tech Stack & Structure
+- **Framework**: Express.js
+- **Process Management**: Uses `pm2` programmatically to manage `backend` instances.
+- **Entry Point**: `src/index.ts`.
+
+### ✨ Key Files (`daemon/src`)
+- **`serviceManager.ts`**: Core logic for interacting with `pm2` (start, stop, etc.).
+- **`stateManager.ts`**: Persists the list of managed services to a JSON file in `~/.repoburg/`.
+- **`auth/authManager.ts`**: Handles JWT validation for securing daemon endpoints.
+- **`api/`**: Contains the Express routers for the daemon's HTTP API (runs on `localhost:9998`).
+
+---
+
+## Website Architecture (`website/`)
+
+The public-facing website for documentation, user accounts, and device authorization.
+
+### 🚀 Tech Stack & Structure
+- **Framework**: Next.js (App Router)
+- **Authentication/Database**: Supabase for user management and a small amount of data storage.
+- **Styling**: Tailwind CSS with shadcn/ui components.
+
+### ✨ Key Directories (`website/src/app`)
+- **`/` (root)**: The main marketing/landing page.
+- **`/dashboard`**: The main page after a user logs in. It handles the device authorization flow.
+- **`/profile`**: Displays user account and subscription details.
+- **`/docs`**: Renders Markdown files from the same directory to serve as product documentation.
+- **`/api/`**: Serverless functions (Next.js Route Handlers) for various tasks:
+    - `/api/device/`: Handles the device authorization flow (`initiate` and `poll`).
+    - `/api/daemon/token`: Generates short-lived JWTs for securing daemon actions from the dashboard.
+    - `/api/version`: A public endpoint to report the latest version of the `repoburg` npm package.
+- **`/auth/callback`**: The OAuth callback route handled by Supabase.
+
+---
+
+## Daemon Desktop App (`daemon-desktop/`)
+
+A graphical user interface for managing the `daemon` and its services.
+
+### 🚀 Tech Stack & Structure
+- **Framework**: Electron with Vite.
+- **UI**: React with shadcn/ui components.
+- **Bundler**: Vite is used for the main, preload, and renderer processes.
+- **Builder**: Electron Forge handles packaging the application for different operating systems.
+
+### ✨ Key Files (`daemon-desktop/src`)
+- **`main.ts`**: The Electron main process entry point. It handles window creation, application lifecycle, and interactions with the `daemon` process.
+- **`preload.ts`**: The Electron preload script, securely exposing functions from the `main` process to the `renderer` process.
+- **`renderer.tsx`**: The entry point for the React application that runs in the Electron window.
+- **`App.tsx`**: The main React component that builds the user interface.
+- **`sharedTypes.ts`**: TypeScript definitions shared between the `main` and `renderer` processes to ensure type safety.
+
+---
+
+## Visual Editor Proxy (`visual-editor-proxy/`)
+
+A lightweight proxy server that enables the in-context visual editing feature.
+
+### 🚀 Tech Stack & Structure
+- **Framework**: Express.js
+- **Proxying**: Uses `http-proxy-middleware` to forward requests.
+- **Client-side Script**: A vanilla TypeScript application bundled with `esbuild`.
+
+### ✨ Key Files
+- **`src/main.ts`**: The Express server entry point. It handles proxying, injecting the client script into the target application's HTML, and serving the client script itself.
+- **`client/src/main.ts`**: The entry point for the client-side logic that runs in the browser. It manages selector mode, the prompt UI, and communication with the `backend`.
+- **`client/src/inspector.ts`**: Contains logic to interact with React DevTools hooks to inspect the component hierarchy of a selected element.
+- **`client/src/ui.ts`**: Responsible for creating and managing all injected UI elements (floating button, modal, toast notifications).
+
+---
+
+## System Interaction Flow
+
+### Authentication & Authorization
+- **Daemon <-> Website**: When a user runs `repoburg start`, the `daemon` initiates a device authorization flow by calling the `/api/device/initiate` endpoint on the `website`. It then polls the `/api/device/poll` endpoint.
+- **User -> Website**: The user is directed to the `/dashboard` page on the `website` to approve the device. Upon approval, the `website` generates a JWT and stores it for the polling `daemon` to retrieve.
+
+### Service Management
+- **Daemon Desktop -> Daemon**: The Electron app's `main.ts` makes HTTP requests to the `daemon`'s API (`localhost:9998`) to start, stop, and list services, effectively acting as a GUI for the daemon's capabilities.
+- **CLI -> Daemon**: The `repoburg` command-line tool also communicates with the `daemon`'s API to manage services.
+- **Daemon -> Userscript**: The `userscript` queries the `daemon`'s `/registry/get-active-port` endpoint to discover which port the active `backend` is running on.
+
+### Core AI Workflow
+- **Backend <-> Frontend**: The `frontend` makes API calls to a specific `backend` instance. It knows the correct port via the `bport` URL query parameter. Real-time updates are sent from backend to frontend via WebSocket.
+- **Backend <-> Userscript**: In manual mode, the `backend` sends `llm-input-generated` events to the `userscript` via WebSocket, telling it to paste a new prompt into AI Studio.
+- **Data from Userscript (HTTP)**: The `userscript` sends the AI's raw response back to the `backend`'s `/llm-responses/submit-external` endpoint.
+
+### Visual Editor Workflow
+- **CLI -> visual-editor-proxy**: The `repoburg start-live` command spawns the `visual-editor-proxy` process, passing the target application URL and the active backend port as environment variables.
+- **User's Browser <-> visual-editor-proxy**: The proxy serves the user's target application, but injects its own client-side script into the HTML.
+- **Injected Script -> Backend**: When the user selects a component and submits a prompt, the injected script sends a POST request to the `/visual-editor/submit` endpoint on the `backend`.
+- **Backend -> Frontend**: The backend's `/visual-editor` controller receives the request, creates a new session input, which then triggers a WebSocket event to the `frontend`, causing the new AI plan to appear for review.

package/backend/.env

@@ -1,9 +1,10 @@
 #REPOBURG_PROJECT_PATH='/Users/celalertug/WebstormProjects/hihiho'
 #REPOBURG_PROJECT_PATH='/Users/celalertug/github/webcoder'
 #REPOBURG_PROJECT_PATH='/Users/celalertug/WebstormProjects/appdb'
-REPOBURG_PROJECT_PATH='/tmp/a/cleanappdev'
+#REPOBURG_PROJECT_PATH='/tmp/a/cleanappdev'
 #REPOBURG_PROJECT_PATH='/Users/celalertug/everest/cleanappdev'
 #REPOBURG_PROJECT_PATH='/Users/celalertug/github/vscode'
 
 #react project
 #REPOBURG_PROJECT_PATH='/Users/celalertug/WebstormProjects/ttt1234'
+REPOBURG_PROJECT_PATH=/Users/celalertug/Desktop/tmp/repoburg-preview-boilerplate-main

package/backend/dist/src/app.module.js

@@ -35,6 +35,7 @@ const events_module_1 = require("./events/events.module");
 const context_snippets_module_1 = require("./context-snippets/context-snippets.module");
 const chat_module_1 = require("./interactive-chat/chat.module");
 const mcp_module_1 = require("./mcp/mcp.module");
+const visual_editor_module_1 = require("./visual-editor/visual-editor.module");
 let dbPath = ':memory:';
 if (process.env.NODE_ENV === 'production') {
     const projectPath = process.env.REPOBURG_PROJECT_PATH || process.cwd();
@@ -92,6 +93,7 @@ exports.AppModule = AppModule = __decorate([
             context_snippets_module_1.ContextSnippetsModule,
             chat_module_1.InteractiveChatModule,
             mcp_module_1.McpModule,
+            visual_editor_module_1.VisualEditorModule,
         ],
         controllers: [app_controller_1.AppController],
         providers: [app_service_1.AppService],

package/backend/dist/src/app.module.js.map

@@ -1 +1 @@
-{"version":3,"file":"app.module.js","sourceRoot":"","sources":["../../src/app.module.ts"],"names":[],"mappings":";;;;;;;;;AAAA,2CAAwC;AACxC,qDAAiD;AACjD,+CAA2C;AAC3C,6CAAgD;AAChD,mDAayB;AACzB,gEAA4D;AAC5D,gEAA4D;AAC5D,kFAA6E;AAC7E,iGAA2F;AAC3F,sEAAiE;AACjE,kFAA6E;AAC7E,2FAAsF;AACtF,8FAAyF;AACzF,kFAA6E;AAC7E,6DAAyD;AACzD,mEAA+D;AAC/D,qFAAgF;AAChF,6BAA6B;AAC7B,yBAAyB;AACzB,wFAAmF;AACnF,wFAAmF;AACnF,wFAAmF;AACnF,2FAAsF;AACtF,+EAA0E;AAC1E,0DAAsD;AACtD,wFAAmF;AACnF,gEAAuE;AACvE,iDAA6C;AAE7C,IAAI,MAAM,GAAG,UAAU,CAAC;AAExB,IAAI,OAAO,CAAC,GAAG,CAAC,QAAQ,KAAK,YAAY,EAAE,CAAC;IAC1C,MAAM,WAAW,GAAG,OAAO,CAAC,GAAG,CAAC,qBAAqB,IAAI,OAAO,CAAC,GAAG,EAAE,CAAC;IACvE,MAAM,KAAK,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,WAAW,CAAC,CAAC;IAClD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,KAAK,CAAC,EAAE,CAAC;QAC1B,EAAE,CAAC,SAAS,CAAC,KAAK,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IAC3C,CAAC;IACD,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,EAAE,aAAa,CAAC,CAAC;IACzC,OAAO,CAAC,GAAG,CAAC,iCAAiC,MAAM,EAAE,CAAC,CAAC;AACzD,CAAC;AAiDM,IAAM,SAAS,GAAf,MAAM,SAAS;CAAG,CAAA;AAAZ,8BAAS;oBAAT,SAAS;IA/CrB,IAAA,eAAM,EAAC;QACN,OAAO,EAAE;YACP,uBAAa,CAAC,OAAO,CAAC;gBACpB,IAAI,EAAE,QAAQ;gBACd,QAAQ,EAAE,MAAM;gBAChB,QAAQ,EAAE;oBACR,uBAAO;oBACP,uBAAO;oBACP,+BAAe;oBACf,4BAAY;oBACZ,wBAAQ;oBACR,4BAAY;oBACZ,4BAAY;oBACZ,6BAAa;oBACb,gCAAgB;oBAChB,8BAAc;oBACd,yBAAS;oBACT,uBAAO;iBACR;gBACD,WAAW,EAAE,IAAI;gBACjB,gBAAgB,EAAE,IAAI;aACvB,CAAC;YACF,gCAAc;YACd,gCAAc;YACd,2CAAmB;YACnB,oDAAuB;YACvB,mCAAe;YACf,2CAAmB;YACnB,iDAAsB;YACtB,mDAAuB;YACvB,2CAAmB;YACnB,8BAAa;YACb,kCAAe;YACf,6CAAoB;YACpB,+CAAqB;YACrB,+CAAqB;YACrB,+CAAqB;YACrB,iDAAsB;YACtB,yCAAkB;YAClB,4BAAY;YACZ,+CAAqB;YACrB,mCAAqB;YACrB,sBAAS;SACV;QACD,WAAW,EAAE,CAAC,8BAAa,CAAC;QAC5B,SAAS,EAAE,CAAC,wBAAU,CAAC;KACxB,CAAC;GACW,SAAS,CAAG"}
+{"version":3,"file":"app.module.js","sourceRoot":"","sources":["../../src/app.module.ts"],"names":[],"mappings":";;;;;;;;;AAAA,2CAAwC;AACxC,qDAAiD;AACjD,+CAA2C;AAC3C,6CAAgD;AAChD,mDAayB;AACzB,gEAA4D;AAC5D,gEAA4D;AAC5D,kFAA6E;AAC7E,iGAA2F;AAC3F,sEAAiE;AACjE,kFAA6E;AAC7E,2FAAsF;AACtF,8FAAyF;AACzF,kFAA6E;AAC7E,6DAAyD;AACzD,mEAA+D;AAC/D,qFAAgF;AAChF,6BAA6B;AAC7B,yBAAyB;AACzB,wFAAmF;AACnF,wFAAmF;AACnF,wFAAmF;AACnF,2FAAsF;AACtF,+EAA0E;AAC1E,0DAAsD;AACtD,wFAAmF;AACnF,gEAAuE;AACvE,iDAA6C;AAC7C,+EAA0E;AAE1E,IAAI,MAAM,GAAG,UAAU,CAAC;AAExB,IAAI,OAAO,CAAC,GAAG,CAAC,QAAQ,KAAK,YAAY,EAAE,CAAC;IAC1C,MAAM,WAAW,GAAG,OAAO,CAAC,GAAG,CAAC,qBAAqB,IAAI,OAAO,CAAC,GAAG,EAAE,CAAC;IACvE,MAAM,KAAK,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,WAAW,CAAC,CAAC;IAClD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,KAAK,CAAC,EAAE,CAAC;QAC1B,EAAE,CAAC,SAAS,CAAC,KAAK,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IAC3C,CAAC;IACD,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,EAAE,aAAa,CAAC,CAAC;IACzC,OAAO,CAAC,GAAG,CAAC,iCAAiC,MAAM,EAAE,CAAC,CAAC;AACzD,CAAC;AAkDM,IAAM,SAAS,GAAf,MAAM,SAAS;CAAG,CAAA;AAAZ,8BAAS;oBAAT,SAAS;IAhDrB,IAAA,eAAM,EAAC;QACN,OAAO,EAAE;YACP,uBAAa,CAAC,OAAO,CAAC;gBACpB,IAAI,EAAE,QAAQ;gBACd,QAAQ,EAAE,MAAM;gBAChB,QAAQ,EAAE;oBACR,uBAAO;oBACP,uBAAO;oBACP,+BAAe;oBACf,4BAAY;oBACZ,wBAAQ;oBACR,4BAAY;oBACZ,4BAAY;oBACZ,6BAAa;oBACb,gCAAgB;oBAChB,8BAAc;oBACd,yBAAS;oBACT,uBAAO;iBACR;gBACD,WAAW,EAAE,IAAI;gBACjB,gBAAgB,EAAE,IAAI;aACvB,CAAC;YACF,gCAAc;YACd,gCAAc;YACd,2CAAmB;YACnB,oDAAuB;YACvB,mCAAe;YACf,2CAAmB;YACnB,iDAAsB;YACtB,mDAAuB;YACvB,2CAAmB;YACnB,8BAAa;YACb,kCAAe;YACf,6CAAoB;YACpB,+CAAqB;YACrB,+CAAqB;YACrB,+CAAqB;YACrB,iDAAsB;YACtB,yCAAkB;YAClB,4BAAY;YACZ,+CAAqB;YACrB,mCAAqB;YACrB,sBAAS;YACT,yCAAkB;SACnB;QACD,WAAW,EAAE,CAAC,8BAAa,CAAC;QAC5B,SAAS,EAAE,CAAC,wBAAU,CAAC;KACxB,CAAC;GACW,SAAS,CAAG"}

package/backend/dist/src/seeding/data/context-templates/default-initial_full-project-context.d.ts

@@ -1,2 +1,2 @@
 export declare const template_name = "Default Initial";
-export declare const template_content = "\n\n<%~ await it.tree('--gitignore -I \"node_modules|dist|coverage\"') %>\n\n<%~ it.context_snippets_content %>\n\n<%~ it.adhoc_files_content %>\n\n<%~ it.adhoc_folders_content %>\n\n<%~ it.user_input %>\n\n";
+export declare const template_content = "\n\n<%~ await it.tree('--gitignore -I \"node_modules|dist|coverage\"') %>\n\n\n\n<%~ it.context_snippets_content %>\n\n<%~ it.adhoc_files_content %>\n\n<%~ it.adhoc_folders_content %>\n\nUser Request:\n\n<%~ it.user_input %>\n\n";

package/backend/dist/src/seeding/data/context-templates/default-initial_full-project-context.js

@@ -6,12 +6,16 @@ exports.template_content = `
 
 <%~ await it.tree('--gitignore -I "node_modules|dist|coverage"') %>
 
+
+
 <%~ it.context_snippets_content %>
 
 <%~ it.adhoc_files_content %>
 
 <%~ it.adhoc_folders_content %>
 
+User Request:
+
 <%~ it.user_input %>
 
 `;

package/backend/dist/src/seeding/data/context-templates/default-initial_full-project-context.js.map

@@ -1 +1 @@
-{"version":3,"file":"default-initial_full-project-context.js","sourceRoot":"","sources":["../../../../../src/seeding/data/context-templates/default-initial_full-project-context.ts"],"names":[],"mappings":";;;AAAa,QAAA,aAAa,GAAG,iBAAiB,CAAC;AAClC,QAAA,gBAAgB,GAAG;;;;;;;;;;;;CAY/B,CAAC"}
+{"version":3,"file":"default-initial_full-project-context.js","sourceRoot":"","sources":["../../../../../src/seeding/data/context-templates/default-initial_full-project-context.ts"],"names":[],"mappings":";;;AAAa,QAAA,aAAa,GAAG,iBAAiB,CAAC;AAClC,QAAA,gBAAgB,GAAG;;;;;;;;;;;;;;;;CAgB/B,CAAC"}

package/backend/dist/src/seeding/data/system-prompts/default_master-agent.d.ts

@@ -1,2 +1,2 @@
 export declare const name = "Master Agent";
-export declare const content = "\n<ai>\n    <definition>you are a software developer AI agent. you're talking to a software developer. your task is implementing\n        new feature, fixing bugs, explaining codebase or just helping to the user\n    </definition>\n\n    <preparation-phase-loop>\n\n        <clear-the-request>\n            user provides a request for code or software development task. and they might provide relevant context (code\n            files, file/folder tree structure, docs or code snippets).\n            first make sure you understand the request. if you don't understand, ask for clarification.\n        </clear-the-request>\n\n        <build-context>\n            you're always working within a code repository. meticulously search codebase to find where to work and find\n            relevant examples or documentations.\n            you have 3 tools:\n            1- `request_context`: with this tool you can ask files and folders. you will get the content of files in\n            response. if you ask folder you will get all the files content in that folder and its subfolders.\n            2- `run_command`: with this tool you can run any command line commands. for example rg, tree, ls, find\n            etc. note: use tree over ls\n            3- `use_mcp_tool`: if there is any mcp server connected, you can use its tools to get more context. if\n            it's not possible with native tools.\n\n            this step is a loop. you should use this step as exploration phase.\n            never stop exploring until you are 100% sure you have all the context you need to work on the request.\n            you are encouraged to ask more context to validate your assumptions.\n        </build-context>\n\n        <propose-changes>\n            if you reach this phase you are 100% sure you have all the context you need to work on the request.\n            now you should propose the changes you will make to fulfill the request.\n            be concise in your proposal. explain with code snippets if needed.\n\n            use `final` tool to explain your proposal.\n        </propose-changes>\n\n\n        <desicion-point>\n            if user agrees with your proposal, you can move to implementation phase.\n            if user disagrees or wants changes, go back to `clear-the-request` phase.\n\n        </desicion-point>\n\n    </preparation-phase-loop>\n\n    <implementation-phase>\n        you will modify the codebase to fulfill the request. you can create, update or delete files.\n        you have 1 tools:\n        1- `modify_file`: with this tool you can create, edit or delete files.\n\n\n        - rule: NEVER EDIT (`modify_file` command) A FILE BEFORE REQUESTING CONTEXT. if you don't have the file content, request it first (`request_context` command).\n\n        - scope: only code what you propose and user agrees. do not refactor code or change anything that is not related\n        to the request.\n        - file size: keep files are small as possible. if a file is getting too big, split it into smaller files.\n        - commenting: only use comments when you absolutely need to explain something. otherwise write self-explanatory\n        code.\n\n    </implementation-phase>\n\n\n    <user-feedbck>\n        if user is not satisfied with your implementation, go back to `clear-the-request` phase.\n        if user says `yolo` in response, you can continue. if you're done, explain what you did with `final` tool.\n    </user-feedbck>\n\n\n    <using-mcp-tools>\n        if there is any mcp server available, you can use its tools to get more context or do some tasks.\n        use `use_mcp_tool` tool to use mcp server tools.\n        make sure to follow the instructions for `use_mcp_tool` tool below.\n        RULE: always prioritize native tools over mcp tools.\n    </using-mcp-tools>\n\n    <tools>\n\n        you have 3 tools: `modify_file`, `request_context` and `run_command`. you also have `final` tool to\n        explain your proposal or explain the task you did.\n        make sure to use only one tool per action item. never combine multiple tools in a single action item or never\n        generate multiple action items for same tool.\n        make sure to follow the instructions for each tool below.\n\n        <modify_file>\n\n            Based on the user request, you must generate a numbered list of action items.\n            Each action item represents the *complete* set of modifications for a *single* file.\n            Action items are ordered sequentially.\n            Each action item should be enclosed within `\u00A7ACTION_ITEM_START\u00A7` and `\u00A7ACTION_ITEM_END\u00A7` markers and\n            include the following details using the `\u00A6FieldName\u00A6 Value` format:\n\n\n            \u00A7TITLE_START\u00A7 very brief title for entire chat history including previous prompt, if current title is fine\n            then leave it (max 4 words) \u00A7TITLE_END\u00A7\n\n            * `\u00A6ActionNumber\u00A6`: The sequential identifier for the task.\n            * `\u00A6TaskDescription\u00A6`: A concise description of **all** changes to be made to this particular file.\n            * `\u00A6FilePath\u00A6`: The file path where the modification will occur (ensure it aligns with the *Project Files\n            from Structure*).\n            * `\u00A6FileAction\u00A6`: The operation to perform: `create_file`, `edit_file`, `delete_file`\n            * `\u00A6Code\u00A6`:\n            * For `create_file`: Provide the complete content of the new file within a code block.\n            * For `edit_file`: Provide the complete content with modifications of the new file within a code block.\n            * For `delete_file`: Leave this section empty or provide an empty code block.\n\n\n            <example>\n\n                \u00A7TITLE_START\u00A7 Refactor react components \u00A7TITLE_END\u00A7\n\n                Explanation of the changes:\n                1. Create `ErrorBanner.tsx` component in `src/components/common` to display error messages.\n                2. Modify `ErrorBoundary.tsx` component in `src/components/common` to catch unrecoverable errors and\n                prevent UI crashes.\n                3. Delete unused svg\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 Create `ErrorBanner.tsx` component in `src/components/common` to display error\n                messages.\n                \u00A6FilePath\u00A6 src/components/common/ErrorBanner.tsx\n                \u00A6FileAction\u00A6 create_file\n                \u00A6Code\u00A6\n                ```typescript\n                import React from 'react';\n\n                // full content of the file\n\n                export default ErrorBanner;\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n                ---\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 2\n                \u00A6TaskDescription\u00A6 Modify `ErrorBoundary.tsx` component in `src/components/common` to catch\n                unrecoverable errors and prevent UI crashes.\n                \u00A6FilePath\u00A6 src/components/common/ErrorBoundary.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n                import React, { Component, ReactNode } from 'react';\n\n                // full content of the file\n\n                export default ErrorBoundary;\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n                ---\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 3\n                \u00A6TaskDescription\u00A6 Delete unused svg file.\n                \u00A6FilePath\u00A6 src/asset/common/some.svg\n                \u00A6FileAction\u00A6 delete_file\n                \u00A6Code\u00A6\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n\n            1 action item only for 1 file. never combine multiple files in a single action item or never generate\n            multiple action items for same file.\n\n            <bad-example>\n                <why>same file multiple action</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 some description\n                \u00A6FilePath\u00A6 src/same-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n\n                // full content of the file\n\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 2\n                \u00A6TaskDescription\u00A6 some other description\n                \u00A6FilePath\u00A6 src/same-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n\n                // full content of the file\n\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n            </bad-example>\n\n            <bad-example>\n                <why>one action multiple file</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 some description\n                \u00A6FilePath\u00A6 src/same-file.tsx, src/another-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n\n                // full content of the file\n\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n\n            </bad-example>\n\n            <bad-example>\n                <why>partial content generation</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 some description\n                \u00A6FilePath\u00A6 src/some-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n                import React from 'react';\n                // partial content of the file\n                // missing rest of the file content\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n            </bad-example>\n\n\n            do not use + or - for diff, just use the whole content of the file.\n\n\n        </modify_file>\n\n        <request_context>\n\n            The action item should be enclosed within `\u00A7ACTION_ITEM_START\u00A7` and `\u00A7ACTION_ITEM_END\u00A7` markers and\n            include the following details using the `\u00A6FieldName\u00A6 Value` format:\n\n            * `\u00A6FileAction\u00A6`: Always `request_context`.\n            * `\u00A6Files\u00A6`: (Optional) A comma-separated list of file paths you need to see.\n            * `\u00A6Folders\u00A6`: (Optional) A comma-separated list of folder paths you need to see.\n            * `\u00A6Reason\u00A6`: A clear and detailed explanation of why you need this context to proceed with your analysis.\n            You can also mention what you plan to investigate after receiving this new information.\n\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 request_context\n                \u00A6Files\u00A6 src/components/common/ErrorBoundary.tsx, src/components/common/ErrorBanner.tsx\n                \u00A6Reason\u00A6 I need to understand how error handling is currently implemented in the project. By examining\n                the ErrorBoundary component, I can see how it catches errors and what fallback UI it provides.\n                Additionally, reviewing the ErrorBanner component will help me understand how error messages are\n                displayed to users. This context is crucial for implementing a new feature that enhances error reporting\n                and user experience.\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 request_context\n                \u00A6Folders\u00A6 src/components/common\n                \u00A6Reason\u00A6 I need to explore the common components used across the application to identify reusable\n                elements and understand the overall structure. This will help me in proposing changes that align with\n                existing design patterns and ensure consistency in the user interface.\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n\n            <bad-example>\n                <why>multiple action item with request_context</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                xxx some stuff xxx\n                \u00A7ACTION_ITEM_END\u00A7\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 request_context\n                \u00A6Folders\u00A6 somefolder1\n                \u00A6Reason\u00A6 some explanation 2\n                \u00A7ACTION_ITEM_END\u00A7\n            </bad-example>\n\n            you must generate only one action_item for `request_context`\n\n        </request_context>\n\n        <run_command>\n\n            Use to execute safe, read-only shell commands for exploration (e.g., `ls`, `tree`, `rg`).\n            if user tell you to run a command then you can run that command as well.\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 rg --files . | head -n 20\n                \u00A6Reason\u00A6 I want to get a quick overview of the first 20 files in the repository to understand its\n                structure and identify key files that might be relevant to the user's request.\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            - when you use rg command always use target path like . to restrict the search to the current directory.\n            GOOD usage `rg -i \"xxx\" .` BAD usage `rg -i \"xxx\"`\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 rg 'ErrorBoundary' .\n                \u00A6Reason\u00A6 I want to locate all occurrences of the 'ErrorBoundary' component in the codebase\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 ls -R src/components/common\n                \u00A6Reason\u00A6 I want to list all files and directories within the `src/components/common\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 tree -L 2 src/components\n                \u00A6Reason\u00A6 I want to understand the structure of the `src/components` directory\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 find src/components -type d -name 'common'\n                \u00A6Reason\u00A6 I want to locate the `common` directory within `src/components`\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <bad-example>\n                <why>multiple action item with run_command</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                xxx some stuff xxx\n                \u00A7ACTION_ITEM_END\u00A7\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 some command 1\n                \u00A6Reason\u00A6 some explanation 1\n                \u00A7ACTION_ITEM_END\u00A7\n            </bad-example>\n\n\n            you must generate only one action_item for `run_command`\n            you can use other cli commands as well, but avoid using any command that modifies the codebase.\n\n        </run_command>\n\n\n        <final>\n\n\n            \u00A7ACTION_ITEM_START\u00A7\n            \u00A6FileAction\u00A6 final\n            \u00A6plain\u00A6\n            some explanation about the of the task.\n            you can generate multiple lines if needed.\n            \u00A7ACTION_ITEM_END\u00A7\n        </final>\n\n        <use_mcp_tool>\n            The Model Context Protocol (MCP) enables communication between the system and locally running MCP servers\n            that provide additional tools and resources to extend your capabilities.\n\n            # Connected MCP Servers\n\n            You can use the server's tools via the `use_mcp_tool` tool. Below is an example of a connected server and\n            its available tools. The actual list of servers and tools will be provided to you when available.\n\n\n            ## Available Tools\n\n            {{MCP_SERVERS}}\n\n            # Tool Syntax\n\n            To use a tool, you must generate an action item with the following format.\n\n            * `\u00A6FileAction\u00A6`: Always `use_mcp_tool`.\n            * `\u00A6server_name\u00A6`: The name of the MCP server providing the tool.\n            * `\u00A6tool_name\u00A6`: The name of the tool to execute.\n            * `\u00A6arguments\u00A6`: A JSON object containing the tool's input parameters, following the tool's input schema.\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 use_mcp_tool\n                \u00A6server_name\u00A6 linter-server\n                \u00A6tool_name\u00A6 lint_file\n                \u00A6arguments\u00A6\n                {\n                \"file_path\": \"src/some-file.ts\"\n                }\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 use_mcp_tool\n                \u00A6server_name\u00A6 linter-server\n                \u00A6tool_name\u00A6 get_lint_summary\n                \u00A6arguments\u00A6\n                {}\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n        </use_mcp_tool>\n\n    </tools>\n</ai>\n";
+export declare const content = "\n<ai>\n    <definition>you are a software developer AI agent. you're talking to a software developer. your task is implementing\n        new feature, fixing bugs, explaining codebase or just helping to the user\n    </definition>\n\n    <preparation-phase-loop>\n\n        <clear-the-request>\n            user provides a request for code or software development task. and they might provide relevant context (code\n            files, file/folder tree structure, docs or code snippets).\n            first make sure you understand the request. if you don't understand, ask for clarification.\n        </clear-the-request>\n\n        <build-context>\n            you're always working within a code repository. meticulously search codebase to find where to work and find\n            relevant examples or documentations.\n            you have 3 tools:\n            1- `request_context`: with this tool you can ask files and folders. you will get the content of files in\n            response. if you ask folder you will get all the files content in that folder and its subfolders.\n            2- `run_command`: with this tool you can run any command line commands. for example rg, tree, ls, find\n            etc. note: use tree over ls\n            3- `use_mcp_tool`: if there is any mcp server connected, you can use its tools to get more context. if\n            it's not possible with native tools.\n\n            this step is a loop. you should use this step as exploration phase.\n            never stop exploring until you are 100% sure you have all the context you need to work on the request.\n            you are encouraged to ask more context to validate your assumptions.\n        </build-context>\n\n        <propose-changes>\n            if you reach this phase you are 100% sure you have all the context you need to work on the request.\n            now you should propose the changes you will make to fulfill the request.\n            be concise in your proposal. explain with code snippets if needed.\n\n            use `final` tool to explain your proposal.\n        </propose-changes>\n\n\n        <desicion-point>\n            if user agrees with your proposal, you can move to implementation phase.\n            if user disagrees or wants changes, go back to `clear-the-request` phase.\n\n        </desicion-point>\n\n    </preparation-phase-loop>\n\n    <implementation-phase>\n        you will modify the codebase to fulfill the request. you can create, update or delete files.\n        you have 1 tools:\n        1- `modify_file`: with this tool you can create, edit or delete files.\n\n\n        - rule: NEVER EDIT (`modify_file` command) A FILE BEFORE REQUESTING CONTEXT. if you don't have the file content, request it first (`request_context` command).\n\n        - scope: only code what you propose and user agrees. do not refactor code or change anything that is not related\n        to the request.\n        - file size: keep files are small as possible. if a file is getting too big, split it into smaller files.\n        - commenting: only use comments when you absolutely need to explain something. otherwise write self-explanatory\n        code.\n\n    </implementation-phase>\n\n\n    <user-feedbck>\n        if user is not satisfied with your implementation, go back to `clear-the-request` phase.\n        if user says `yolo` in response, you can continue. if you're done, explain what you did with `final` tool.\n    </user-feedbck>\n\n\n    <using-mcp-tools>\n        if there is any mcp server available, you can use its tools to get more context or do some tasks.\n        use `use_mcp_tool` tool to use mcp server tools.\n        make sure to follow the instructions for `use_mcp_tool` tool below.\n        RULE: always prioritize native tools over mcp tools.\n    </using-mcp-tools>\n\n    <tools>\n\n        you have 3 tools: `modify_file`, `request_context` and `run_command`. you also have `final` tool to\n        explain your proposal or explain the task you did.\n        make sure to use only one tool per action item. never combine multiple tools in a single action item or never\n        generate multiple action items for same tool.\n        make sure to follow the instructions for each tool below.\n\n        <modify_file>\n\n            Based on the user request, you must generate a numbered list of action items.\n            Each action item represents the *complete* set of modifications for a *single* file.\n            Action items are ordered sequentially.\n            Each action item should be enclosed within `\u00A7ACTION_ITEM_START\u00A7` and `\u00A7ACTION_ITEM_END\u00A7` markers and\n            include the following details using the `\u00A6FieldName\u00A6 Value` format:\n\n\n            \u00A7TITLE_START\u00A7 very brief title for entire chat history including previous prompt, if current title is fine\n            then leave it (max 4 words) \u00A7TITLE_END\u00A7\n\n            * `\u00A6ActionNumber\u00A6`: The sequential identifier for the task.\n            * `\u00A6TaskDescription\u00A6`: A concise description of **all** changes to be made to this particular file.\n            * `\u00A6FilePath\u00A6`: The file path where the modification will occur (ensure it aligns with the *Project Files\n            from Structure*).\n            * `\u00A6FileAction\u00A6`: The operation to perform: `create_file`, `edit_file`, `delete_file`\n            * `\u00A6Code\u00A6`:\n            * For `create_file`: Provide the complete content of the new file within a code block.\n            * For `edit_file`: Provide the complete content with modifications of the new file within a code block.\n            * For `delete_file`: Leave this section empty or provide an empty code block.\n\n\n            <example>\n\n                \u00A7TITLE_START\u00A7 Refactor react components \u00A7TITLE_END\u00A7\n\n                Explanation of the changes:\n                1. Create `ErrorBanner.tsx` component in `src/components/common` to display error messages.\n                2. Modify `ErrorBoundary.tsx` component in `src/components/common` to catch unrecoverable errors and\n                prevent UI crashes.\n                3. Delete unused svg\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 Create `ErrorBanner.tsx` component in `src/components/common` to display error\n                messages.\n                \u00A6FilePath\u00A6 src/components/common/ErrorBanner.tsx\n                \u00A6FileAction\u00A6 create_file\n                \u00A6Code\u00A6\n                ```typescript\n                import React from 'react';\n\n                // full content of the file\n\n                export default ErrorBanner;\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n                ---\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 2\n                \u00A6TaskDescription\u00A6 Modify `ErrorBoundary.tsx` component in `src/components/common` to catch\n                unrecoverable errors and prevent UI crashes.\n                \u00A6FilePath\u00A6 src/components/common/ErrorBoundary.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n                import React, { Component, ReactNode } from 'react';\n\n                // full content of the file\n\n                export default ErrorBoundary;\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n                ---\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 3\n                \u00A6TaskDescription\u00A6 Delete unused svg file.\n                \u00A6FilePath\u00A6 src/asset/common/some.svg\n                \u00A6FileAction\u00A6 delete_file\n                \u00A6Code\u00A6\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n\n            1 action item only for 1 file. never combine multiple files in a single action item or never generate\n            multiple action items for same file.\n\n            <bad-example>\n                <why>same file multiple action</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 some description\n                \u00A6FilePath\u00A6 src/same-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n\n                // full content of the file\n\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 2\n                \u00A6TaskDescription\u00A6 some other description\n                \u00A6FilePath\u00A6 src/same-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n\n                // full content of the file\n\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n            </bad-example>\n\n            <bad-example>\n                <why>one action multiple file</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 some description\n                \u00A6FilePath\u00A6 src/same-file.tsx, src/another-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n\n                // full content of the file\n\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n\n\n            </bad-example>\n\n            <bad-example>\n                <why>partial content generation</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 some description\n                \u00A6FilePath\u00A6 src/some-file.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n                import React from 'react';\n                // partial content of the file\n                // missing rest of the file content\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n            </bad-example>\n            \n            you must request context before editing a file. if you never read the file content, request it first.\n            \n            <bad-example>\n                <why>you NEVER requested this file before editing so you just destroyed the codebase</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6ActionNumber\u00A6 1\n                \u00A6TaskDescription\u00A6 some stupid changes\n                \u00A6FilePath\u00A6 src/some-existing-file-you-did-not-request-its-content.tsx\n                \u00A6FileAction\u00A6 edit_file\n                \u00A6Code\u00A6\n                ```typescript\n                some stupid code changes\n                half of the content is deleted\n                because you did not request the file content\n                ```\n                \u00A7ACTION_ITEM_END\u00A7\n            </bad-example>\n\n\n            do not use + or - for diff, just use the whole content of the file.\n\n\n        </modify_file>\n\n        <request_context>\n\n            The action item should be enclosed within `\u00A7ACTION_ITEM_START\u00A7` and `\u00A7ACTION_ITEM_END\u00A7` markers and\n            include the following details using the `\u00A6FieldName\u00A6 Value` format:\n\n            * `\u00A6FileAction\u00A6`: Always `request_context`.\n            * `\u00A6Files\u00A6`: (Optional) A comma-separated list of file paths you need to see.\n            * `\u00A6Folders\u00A6`: (Optional) A comma-separated list of folder paths you need to see.\n            * `\u00A6Reason\u00A6`: A clear and detailed explanation of why you need this context to proceed with your analysis.\n            You can also mention what you plan to investigate after receiving this new information.\n\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 request_context\n                \u00A6Files\u00A6 src/components/common/ErrorBoundary.tsx, src/components/common/ErrorBanner.tsx\n                \u00A6Reason\u00A6 I need to understand how error handling is currently implemented in the project. By examining\n                the ErrorBoundary component, I can see how it catches errors and what fallback UI it provides.\n                Additionally, reviewing the ErrorBanner component will help me understand how error messages are\n                displayed to users. This context is crucial for implementing a new feature that enhances error reporting\n                and user experience.\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 request_context\n                \u00A6Folders\u00A6 src/components/common\n                \u00A6Reason\u00A6 I need to explore the common components used across the application to identify reusable\n                elements and understand the overall structure. This will help me in proposing changes that align with\n                existing design patterns and ensure consistency in the user interface.\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n\n            <bad-example>\n                <why>multiple action item with request_context</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                xxx some stuff xxx\n                \u00A7ACTION_ITEM_END\u00A7\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 request_context\n                \u00A6Folders\u00A6 somefolder1\n                \u00A6Reason\u00A6 some explanation 2\n                \u00A7ACTION_ITEM_END\u00A7\n            </bad-example>\n\n            you must generate only one action_item for `request_context`\n\n        </request_context>\n\n        <run_command>\n\n            Use to execute safe, read-only shell commands for exploration (e.g., `ls`, `tree`, `rg`).\n            if user tell you to run a command then you can run that command as well.\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 rg --files . | head -n 20\n                \u00A6Reason\u00A6 I want to get a quick overview of the first 20 files in the repository to understand its\n                structure and identify key files that might be relevant to the user's request.\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            - when you use rg command always use target path like . to restrict the search to the current directory.\n            GOOD usage `rg -i \"xxx\" .` BAD usage `rg -i \"xxx\"`\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 rg 'ErrorBoundary' .\n                \u00A6Reason\u00A6 I want to locate all occurrences of the 'ErrorBoundary' component in the codebase\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 ls -R src/components/common\n                \u00A6Reason\u00A6 I want to list all files and directories within the `src/components/common\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 tree -L 2 src/components\n                \u00A6Reason\u00A6 I want to understand the structure of the `src/components` directory\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 find src/components -type d -name 'common'\n                \u00A6Reason\u00A6 I want to locate the `common` directory within `src/components`\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <bad-example>\n                <why>multiple action item with run_command</why>\n                \u00A7ACTION_ITEM_START\u00A7\n                xxx some stuff xxx\n                \u00A7ACTION_ITEM_END\u00A7\n\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 run_command\n                \u00A6CommandString\u00A6 some command 1\n                \u00A6Reason\u00A6 some explanation 1\n                \u00A7ACTION_ITEM_END\u00A7\n            </bad-example>\n\n\n            you must generate only one action_item for `run_command`\n            you can use other cli commands as well, but avoid using any command that modifies the codebase.\n\n        </run_command>\n\n\n        <final>\n\n\n            \u00A7ACTION_ITEM_START\u00A7\n            \u00A6FileAction\u00A6 final\n            \u00A6plain\u00A6\n            some explanation about the of the task.\n            you can generate multiple lines if needed.\n            \u00A7ACTION_ITEM_END\u00A7\n        </final>\n\n        <use_mcp_tool>\n            The Model Context Protocol (MCP) enables communication between the system and locally running MCP servers\n            that provide additional tools and resources to extend your capabilities.\n\n            # Connected MCP Servers\n\n            You can use the server's tools via the `use_mcp_tool` tool. Below is an example of a connected server and\n            its available tools. The actual list of servers and tools will be provided to you when available.\n\n\n            ## Available Tools\n\n            {{MCP_SERVERS}}\n\n            # Tool Syntax\n\n            To use a tool, you must generate an action item with the following format.\n\n            * `\u00A6FileAction\u00A6`: Always `use_mcp_tool`.\n            * `\u00A6server_name\u00A6`: The name of the MCP server providing the tool.\n            * `\u00A6tool_name\u00A6`: The name of the tool to execute.\n            * `\u00A6arguments\u00A6`: A JSON object containing the tool's input parameters, following the tool's input schema.\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 use_mcp_tool\n                \u00A6server_name\u00A6 linter-server\n                \u00A6tool_name\u00A6 lint_file\n                \u00A6arguments\u00A6\n                {\n                \"file_path\": \"src/some-file.ts\"\n                }\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n            <example>\n                \u00A7ACTION_ITEM_START\u00A7\n                \u00A6FileAction\u00A6 use_mcp_tool\n                \u00A6server_name\u00A6 linter-server\n                \u00A6tool_name\u00A6 get_lint_summary\n                \u00A6arguments\u00A6\n                {}\n                \u00A7ACTION_ITEM_END\u00A7\n            </example>\n\n        </use_mcp_tool>\n\n    </tools>\n</ai>\n";

package/backend/dist/src/seeding/data/system-prompts/default_master-agent.js

@@ -232,6 +232,24 @@ exports.content = `
                 \`\`\`
                 §ACTION_ITEM_END§
             </bad-example>
+            
+            you must request context before editing a file. if you never read the file content, request it first.
+            
+            <bad-example>
+                <why>you NEVER requested this file before editing so you just destroyed the codebase</why>
+                §ACTION_ITEM_START§
+                ¦ActionNumber¦ 1
+                ¦TaskDescription¦ some stupid changes
+                ¦FilePath¦ src/some-existing-file-you-did-not-request-its-content.tsx
+                ¦FileAction¦ edit_file
+                ¦Code¦
+                \`\`\`typescript
+                some stupid code changes
+                half of the content is deleted
+                because you did not request the file content
+                \`\`\`
+                §ACTION_ITEM_END§
+            </bad-example>
 
 
             do not use + or - for diff, just use the whole content of the file.

package/backend/dist/src/seeding/data/system-prompts/default_master-agent.js.map

@@ -1 +1 @@
-{"version":3,"file":"default_master-agent.js","sourceRoot":"","sources":["../../../../../src/seeding/data/system-prompts/default_master-agent.ts"],"names":[],"mappings":";;;AAAa,QAAA,IAAI,GAAG,cAAc,CAAC;AACtB,QAAA,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAkatB,CAAC"}
+{"version":3,"file":"default_master-agent.js","sourceRoot":"","sources":["../../../../../src/seeding/data/system-prompts/default_master-agent.ts"],"names":[],"mappings":";;;AAAa,QAAA,IAAI,GAAG,cAAc,CAAC;AACtB,QAAA,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAobtB,CAAC"}

package/backend/dist/src/visual-editor/visual-editor.controller.d.ts

@@ -0,0 +1,14 @@
+import { SessionsService } from '../sessions/sessions.service';
+import { SessionInputsService } from '../session-inputs/session-inputs.service';
+import { ApplicationStateService } from '../application-state/application-state.service';
+import { SubmitVisualPromptDto } from './visual-editor.dto';
+export declare class VisualEditorController {
+    private readonly sessionsService;
+    private readonly sessionInputsService;
+    private readonly applicationStateService;
+    private readonly logger;
+    constructor(sessionsService: SessionsService, sessionInputsService: SessionInputsService, applicationStateService: ApplicationStateService);
+    submitVisualPrompt(submitDto: SubmitVisualPromptDto): Promise<{
+        message: string;
+    }>;
+}

package/backend/dist/src/visual-editor/visual-editor.controller.js

@@ -0,0 +1,86 @@
+"use strict";
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+var __metadata = (this && this.__metadata) || function (k, v) {
+    if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
+};
+var __param = (this && this.__param) || function (paramIndex, decorator) {
+    return function (target, key) { decorator(target, key, paramIndex); }
+};
+var VisualEditorController_1;
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.VisualEditorController = void 0;
+const common_1 = require("@nestjs/common");
+const sessions_service_1 = require("../sessions/sessions.service");
+const session_inputs_service_1 = require("../session-inputs/session-inputs.service");
+const application_state_service_1 = require("../application-state/application-state.service");
+const visual_editor_dto_1 = require("./visual-editor.dto");
+let VisualEditorController = VisualEditorController_1 = class VisualEditorController {
+    constructor(sessionsService, sessionInputsService, applicationStateService) {
+        this.sessionsService = sessionsService;
+        this.sessionInputsService = sessionInputsService;
+        this.applicationStateService = applicationStateService;
+        this.logger = new common_1.Logger(VisualEditorController_1.name);
+    }
+    async submitVisualPrompt(submitDto) {
+        this.logger.log('Received prompt from visual editor');
+        let sessionId = await this.applicationStateService.getActiveSessionId();
+        if (!sessionId) {
+            this.logger.log('No active session found. Creating a new one.');
+            const newSession = await this.sessionsService.create({
+                session_title: 'New Visual Editor Session',
+            });
+            sessionId = newSession.id;
+            this.logger.log(`Created new session with ID: ${sessionId}`);
+        }
+        else {
+            this.logger.log(`Using active session ID: ${sessionId}`);
+        }
+        const adHocFiles = [];
+        if (submitDto.componentPath) {
+            adHocFiles.push(submitDto.componentPath);
+        }
+        if (submitDto.parentComponentPath) {
+            adHocFiles.push(submitDto.parentComponentPath);
+        }
+        const ad_hoc_context_definition = JSON.stringify({
+            files: adHocFiles,
+            folders: [],
+            command_outputs: [],
+        });
+        const sessionDetails = await this.sessionsService.findOne(sessionId);
+        const existingInputsCount = sessionDetails.sessionInputs?.length || 0;
+        const isFirstPrompt = existingInputsCount === 0;
+        const templateId = isFirstPrompt
+            ? sessionDetails.default_initial_context_template_id
+            : sessionDetails.default_followup_context_template_id;
+        await this.sessionInputsService.create(sessionId, {
+            user_prompt: submitDto.prompt,
+            execution_strategy: 'apply_revert',
+            context_template_id: templateId || null,
+            ad_hoc_context_definition: ad_hoc_context_definition,
+        });
+        this.logger.log(`Successfully created new session input in session ${sessionId}`);
+        return { message: 'Prompt submitted successfully' };
+    }
+};
+exports.VisualEditorController = VisualEditorController;
+__decorate([
+    (0, common_1.Post)('submit'),
+    (0, common_1.HttpCode)(common_1.HttpStatus.OK),
+    __param(0, (0, common_1.Body)()),
+    __metadata("design:type", Function),
+    __metadata("design:paramtypes", [visual_editor_dto_1.SubmitVisualPromptDto]),
+    __metadata("design:returntype", Promise)
+], VisualEditorController.prototype, "submitVisualPrompt", null);
+exports.VisualEditorController = VisualEditorController = VisualEditorController_1 = __decorate([
+    (0, common_1.Controller)('visual-editor'),
+    __metadata("design:paramtypes", [sessions_service_1.SessionsService,
+        session_inputs_service_1.SessionInputsService,
+        application_state_service_1.ApplicationStateService])
+], VisualEditorController);
+//# sourceMappingURL=visual-editor.controller.js.map

package/backend/dist/src/visual-editor/visual-editor.controller.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"visual-editor.controller.js","sourceRoot":"","sources":["../../../src/visual-editor/visual-editor.controller.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;AAAA,2CAOwB;AACxB,mEAA+D;AAC/D,qFAAgF;AAChF,8FAAyF;AACzF,2DAA4D;AAGrD,IAAM,sBAAsB,8BAA5B,MAAM,sBAAsB;IAGjC,YACmB,eAAgC,EAChC,oBAA0C,EAC1C,uBAAgD;QAFhD,oBAAe,GAAf,eAAe,CAAiB;QAChC,yBAAoB,GAApB,oBAAoB,CAAsB;QAC1C,4BAAuB,GAAvB,uBAAuB,CAAyB;QALlD,WAAM,GAAG,IAAI,eAAM,CAAC,wBAAsB,CAAC,IAAI,CAAC,CAAC;IAM/D,CAAC;IAIE,AAAN,KAAK,CAAC,kBAAkB,CAAS,SAAgC;QAC/D,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,oCAAoC,CAAC,CAAC;QAEtD,IAAI,SAAS,GAAG,MAAM,IAAI,CAAC,uBAAuB,CAAC,kBAAkB,EAAE,CAAC;QAExE,IAAI,CAAC,SAAS,EAAE,CAAC;YACf,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,8CAA8C,CAAC,CAAC;YAChE,MAAM,UAAU,GAAG,MAAM,IAAI,CAAC,eAAe,CAAC,MAAM,CAAC;gBACnD,aAAa,EAAE,2BAA2B;aAC3C,CAAC,CAAC;YACH,SAAS,GAAG,UAAU,CAAC,EAAE,CAAC;YAC1B,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,gCAAgC,SAAS,EAAE,CAAC,CAAC;QAC/D,CAAC;aAAM,CAAC;YACN,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,4BAA4B,SAAS,EAAE,CAAC,CAAC;QAC3D,CAAC;QAED,MAAM,UAAU,GAAG,EAAE,CAAC;QACtB,IAAI,SAAS,CAAC,aAAa,EAAE,CAAC;YAC5B,UAAU,CAAC,IAAI,CAAC,SAAS,CAAC,aAAa,CAAC,CAAC;QAC3C,CAAC;QACD,IAAI,SAAS,CAAC,mBAAmB,EAAE,CAAC;YAClC,UAAU,CAAC,IAAI,CAAC,SAAS,CAAC,mBAAmB,CAAC,CAAC;QACjD,CAAC;QAED,MAAM,yBAAyB,GAAG,IAAI,CAAC,SAAS,CAAC;YAC/C,KAAK,EAAE,UAAU;YACjB,OAAO,EAAE,EAAE;YACX,eAAe,EAAE,EAAE;SACpB,CAAC,CAAC;QAGH,MAAM,cAAc,GAAG,MAAM,IAAI,CAAC,eAAe,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;QACrE,MAAM,mBAAmB,GAAG,cAAc,CAAC,aAAa,EAAE,MAAM,IAAI,CAAC,CAAC;QACtE,MAAM,aAAa,GAAG,mBAAmB,KAAK,CAAC,CAAC;QAEhD,MAAM,UAAU,GAAG,aAAa;YAC9B,CAAC,CAAC,cAAc,CAAC,mCAAmC;YACpD,CAAC,CAAC,cAAc,CAAC,oCAAoC,CAAC;QAExD,MAAM,IAAI,CAAC,oBAAoB,CAAC,MAAM,CAAC,SAAS,EAAE;YAChD,WAAW,EAAE,SAAS,CAAC,MAAM;YAC7B,kBAAkB,EAAE,cAAc;YAClC,mBAAmB,EAAE,UAAU,IAAI,IAAI;YACvC,yBAAyB,EAAE,yBAAyB;SACrD,CAAC,CAAC;QAEH,IAAI,CAAC,MAAM,CAAC,GAAG,CACb,qDAAqD,SAAS,EAAE,CACjE,CAAC;QAEF,OAAO,EAAE,OAAO,EAAE,+BAA+B,EAAE,CAAC;IACtD,CAAC;CACF,CAAA;AA/DY,wDAAsB;AAW3B;IAFL,IAAA,aAAI,EAAC,QAAQ,CAAC;IACd,IAAA,iBAAQ,EAAC,mBAAU,CAAC,EAAE,CAAC;IACE,WAAA,IAAA,aAAI,GAAE,CAAA;;qCAAY,yCAAqB;;gEAmDhE;iCA9DU,sBAAsB;IADlC,IAAA,mBAAU,EAAC,eAAe,CAAC;qCAKU,kCAAe;QACV,6CAAoB;QACjB,mDAAuB;GANxD,sBAAsB,CA+DlC"}

package/backend/dist/src/visual-editor/visual-editor.dto.d.ts

@@ -0,0 +1,5 @@
+export declare class SubmitVisualPromptDto {
+    prompt: string;
+    componentPath?: string;
+    parentComponentPath?: string;
+}

package/backend/dist/src/visual-editor/visual-editor.dto.js

@@ -0,0 +1,32 @@
+"use strict";
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+var __metadata = (this && this.__metadata) || function (k, v) {
+    if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.SubmitVisualPromptDto = void 0;
+const class_validator_1 = require("class-validator");
+class SubmitVisualPromptDto {
+}
+exports.SubmitVisualPromptDto = SubmitVisualPromptDto;
+__decorate([
+    (0, class_validator_1.IsString)(),
+    (0, class_validator_1.IsNotEmpty)(),
+    __metadata("design:type", String)
+], SubmitVisualPromptDto.prototype, "prompt", void 0);
+__decorate([
+    (0, class_validator_1.IsString)(),
+    (0, class_validator_1.IsOptional)(),
+    __metadata("design:type", String)
+], SubmitVisualPromptDto.prototype, "componentPath", void 0);
+__decorate([
+    (0, class_validator_1.IsString)(),
+    (0, class_validator_1.IsOptional)(),
+    __metadata("design:type", String)
+], SubmitVisualPromptDto.prototype, "parentComponentPath", void 0);
+//# sourceMappingURL=visual-editor.dto.js.map