| ## Stand-alone Web App CLI Simulation (React+Three.js) ### 1. Introduction This document outlines the specifications for a stand-alone web application designed to simulate a Command Line Interface (CLI) experience within a web browser. The application will be purely conceptual, requiring no backend infrastructure, and will leverage client-side technologies to mimic the look, feel, and basic functionality of a CLI. ### 2. Requirements * **Stand-alone:** The application must function entirely within the user's browser without requiring a server or backend connection. * **Web-based:** Accessible via a standard web browser. * **CLI Simulation:** Visually and interactively emulate a terminal or command-line environment. * **No Backend:** All processing, state management, and data storage must occur client-side. * **Conceptual:** Focus on demonstrating the *concept* of a web-based CLI, not on replicating a full-featured OS or complex application. ### 3. User Interface (UI) * **Layout:** A single-page application layout. * **Output Area:** A scrollable, read-only area displaying command history, outputs, and system messages. This area should visually resemble terminal output (e.g., monospace font, distinct text colors for commands, output, and errors). * **Input Area:** A text input field at the bottom, mimicking a command prompt, where users can type commands. It should display a prompt symbol (e.g., `> ` or `$ `). * **Cursor:** A blinking cursor within the input field. * **Styling:** CSS will be used to achieve a terminal-like appearance, including: * Background color (e.g., dark grey, black). * Text color (e.g., light grey, green, white). * Monospace font (e.g., Consolas, Monaco, Courier New). * Input field styling to blend with the output area. * **Interactivity:** * User input is captured upon pressing `Enter`. * The entered command is displayed in the output area, prefixed with the prompt symbol. * The input field is cleared after `Enter` is pressed. * Command output (or error messages) is displayed below the entered command in the output area. * Support for basic navigation (e.g., up/down arrow keys for command history). ### 4. Core Functionality & Data Flow * **Client-Side Technologies:** * **HTML:** Structure of the page (output area, input field). * **CSS:** Styling for terminal appearance. * **JavaScript:** Handles all logic: * **Input Parsing:** Capturing and parsing user commands. * **Command Mapping:** Associating command strings with specific JavaScript functions. * **State Management:** Maintaining application state (e.g., current directory, simulated file system, command history) in memory. * **Output Rendering:** Dynamically updating the DOM to display results. * **Virtual File System (VFS):** * A JavaScript object (e.g., nested objects or a Map) will simulate a file system structure (directories and files). * Operations like `ls`, `cd`, `cat`, `mkdir`, `touch`, `rm` will be implemented as JavaScript functions that manipulate this in-memory VFS. * **Command Execution Flow:** 1. User types a command in the input field and presses `Enter`. 2. JavaScript captures the command string. 3. The command is added to the command history and displayed in the output area. 4. The command string is parsed to identify the command name and its arguments. 5. A command handler function (mapped via JavaScript object/Map) is invoked. 6. The handler function interacts with the VFS and application state. 7. The handler function returns output (text, error message, or status). 8. The returned output is displayed in the output area. 9. Application state is updated if necessary. * **State Persistence (Optional):** * `localStorage` or `sessionStorage` can be used to persist the VFS and command history across page reloads, enhancing the simulation. ### 5. Conceptual Technical Insights * **No Backend:** Emphasizes client-side JavaScript's capability to manage complex application logic and state without server intervention. This is achieved through in-memory data structures and browser storage APIs. * **SQL-like Conceptualization:** While no actual SQL database is used, the *logic* of data manipulation (storing command history, managing state, representing file structures) can be conceptually mapped to SQL operations (INSERT, SELECT, UPDATE, DELETE on tables like `CommandHistory`, `AppState`, `FileSystem`). This provides a familiar paradigm for understanding data management, even in a client-side context. * **Libraries:** Libraries like `xterm.js` can be integrated to provide a more robust and feature-rich terminal emulation experience, handling rendering, input, and advanced terminal behaviors. * **SPA Architecture:** The application will follow a Single Page Application pattern, where JavaScript dynamically updates the content of a single HTML page, eliminating the need for full page reloads and providing a seamless user experience. ### 6. Example Commands (Conceptual) * `help`: Displays a list of available commands. * `ls`: Lists files and directories in the current VFS directory. * `cd <directory>`: Changes the current directory in the VFS. * `cat <file>`: Displays the content of a file in the VFS. * `echo <text>`: Prints the provided text to the output. * `clear`: Clears the output area. * `history`: Displays the command history. | |
| ## T20-MAS Web App Specification (Conceptual, Stand-alone) ### 1. Introduction This document outlines the conceptual specification for a stand-alone, no-backend T20-MAS (Task-Oriented Multi-Agent System) Web Application. The focus is on defining the architecture, components, and data structures required for such a system to operate entirely within a web browser environment, without relying on server-side infrastructure. ### 2. Overall Goal Generation of a Specification of a stand-alone T20-MAS Web App, no backend, purely conceptual. ### 3. Architectural Context and Insights * **Client-Side Execution:** All MAS logic, communication, and state management must reside within the browser's JavaScript environment. This necessitates adapting the core MAS framework for client-side execution. * **No Backend:** Eliminates server-side persistence, APIs, and computation. All data storage and processing are local to the user's browser session, simplifying deployment but limiting scalability and inter-user data sharing. * **MAS in the Browser:** Requires browser-compatible implementations for components like the `MessageBus` (e.g., using browser-native events) and LLM integrations (e.g., WebLLM, `fetch` to browser-accessible APIs). * **Conceptual Focus:** The specification defines the structure and interfaces without requiring a full implementation, abstracting LLM and MessageBus interactions for future browser-specific adaptations. ### 4. Core Components and Interfaces #### 4.1. Agent Definition (`runtime/agent.py` basis) * **`Agent` Class:** The fundamental unit of the MAS. Responsible for executing tasks based on its profile (name, role, goal) and system instructions. * **Methods:** `__init__`, `subscribe`, `publish`, `receive_feedback`, `update_system_prompt`, `execute_task`, `_run`. * **Adaptation:** This class structure would be the blueprint for JavaScript agent implementations. #### 4.2. Core Runtime (`runtime/core.py` basis) * **`ExecutionContext`:** Manages the state and context for a workflow, including plans and artifacts. * **Methods:** `record_artifact`, `record_initial`. * **`Session`:** Manages the runtime context, including session ID, agent list, state, and artifact storage. * **Methods:** `add_artifact`, `get_artifact`. * **Client-Side Adaptation:** Session state and artifacts would be managed using browser storage APIs (`localStorage`, `sessionStorage`, IndexedDB). #### 4.3. Message Bus (`runtime/message_bus.py` basis) * **`MessageBus`:** Facilitates communication between agents. * **Methods:** `subscribe`, `publish`. * **Client-Side Adaptation:** Implementation would likely use browser event mechanisms (`CustomEvent`, `BroadcastChannel`) or a simple in-memory pub/sub pattern. #### 4.4. LLM Integration (`runtime/llm.py` basis) * **`LLM` Abstract Base Class:** Defines the interface for interacting with Large Language Models. * **Methods:** `generate_content`. * **Client-Side Adaptation:** Concrete implementations would use browser-based LLM libraries (e.g., WebLLM) or `fetch` requests to accessible LLM APIs. #### 4.5. Orchestration (`runtime/orchestrator.py` basis) * **`Orchestrator` Agent:** Responsible for generating and managing the workflow plan. * **Methods:** `generate_plan`. * **Plan Structure (`runtime/custom_types.Plan`):** Defines the high-level goal, reasoning, roles, and tasks. * **Client-Side Adaptation:** Plan generation would involve client-side LLM calls. #### 4.6. System (`runtime/system.py` basis) * **`System` Class:** Encapsulates the entire MAS, handling configuration, agent instantiation, and workflow execution. * **Methods:** `setup`, `start`, `run`. * **Client-Side Adaptation:** The `System` class logic would need to be adapted to manage client-side agents, state, and communication. ### 5. Conceptual Database Schema Given the stand-alone, no-backend constraint, the 'database' refers to client-side storage (e.g., `localStorage`, IndexedDB). The logical schema includes: * **`Session`**: Tracks session ID, start/end times, goal, and status. * **`AgentProfile`**: Stores agent details (ID, name, role, goal, model) linked to a session. * **`Task`**: Records task details (ID, description, agent, dependencies, status, output) linked to a session. * **`Artifact`**: Stores generated artifacts (name, content, type) linked to a task and session. * **`Feedback`**: Captures feedback (rating, comment) linked to a session, task, or agent. **Schema Representation (JSON-like):** ```json { "schema": { "Session": [ {"name": "sessionId", "type": "string", "primaryKey": true}, {"name": "startTime", "type": "timestamp"}, {"name": "endTime", "type": "timestamp", "nullable": true}, {"name": "goal", "type": "string"}, {"name": "status", "type": "string"} ], "AgentProfile": [ {"name": "agentId", "type": "string", "primaryKey": true}, {"name": "sessionId", "type": "string", "foreignKey": "Session.sessionId"}, {"name": "name", "type": "string"}, {"name": "role", "type": "string"}, {"name": "goal", "type": "string"}, {"name": "model", "type": "string"} ], "Task": [ {"name": "taskId", "type": "string", "primaryKey": true}, {"name": "sessionId", "type": "string", "foreignKey": "Session.sessionId"}, {"name": "agentId", "type": "string", "foreignKey": "AgentProfile.agentId"}, {"name": "description", "type": "string"}, {"name": "dependencies", "type": "list<string>"}, {"name": "startTime", "type": "timestamp"}, {"name": "endTime", "type": "timestamp", "nullable": true}, {"name": "status", "type": "string"}, {"name": "output", "type": "string", "nullable": true} ], "Artifact": [ {"name": "artifactId", "type": "string", "primaryKey": true}, {"name": "taskId", "type": "string", "foreignKey": "Task.taskId"}, {"name": "sessionId", "type": "string", "foreignKey": "Session.sessionId"}, {"name": "name", "type": "string"}, {"name": "content", "type": "string"}, {"name": "contentType", "type": "string"} ], "Feedback": [ {"name": "feedbackId", "type": "string", "primaryKey": true}, {"name": "sessionId", "type": "string", "foreignKey": "Session.sessionId"}, {"name": "taskId", "type": "string", "foreignKey": "Task.taskId", "nullable": true}, {"name": "agentId", "type": "string", "foreignKey": "AgentProfile.agentId", "nullable": true}, {"name": "rating", "type": "number", "nullable": true}, {"name": "comment", "type": "string", "nullable": true}, {"name": "timestamp", "type": "timestamp"} ] } } ``` ### 6. Conceptual SQL Schema Below are conceptual SQL `CREATE TABLE` statements based on the schema design. These are illustrative and would require adaptation for specific browser storage implementations (e.g., using JavaScript APIs for IndexedDB). ```sql -- Table: Session CREATE TABLE IF NOT EXISTS Session ( sessionId TEXT PRIMARY KEY, startTime TIMESTAMP NOT NULL, endTime TIMESTAMP, goal TEXT, status TEXT NOT NULL CHECK (status IN ('active', 'completed', 'aborted')) ); -- Table: AgentProfile CREATE TABLE IF NOT EXISTS AgentProfile ( agentId TEXT PRIMARY KEY, sessionId TEXT NOT NULL, name TEXT NOT NULL, role TEXT NOT NULL, goal TEXT, model TEXT, FOREIGN KEY (sessionId) REFERENCES Session(sessionId) ); -- Table: Task CREATE TABLE IF NOT EXISTS Task ( taskId TEXT PRIMARY KEY, sessionId TEXT NOT NULL, agentId TEXT NOT NULL, description TEXT NOT NULL, dependencies TEXT, -- Storing as JSON array string startTime TIMESTAMP NOT NULL, endTime TIMESTAMP, status TEXT NOT NULL CHECK (status IN ('pending', 'running', 'completed', 'failed')), output TEXT, FOREIGN KEY (sessionId) REFERENCES Session(sessionId), FOREIGN KEY (agentId) REFERENCES AgentProfile(agentId) ); -- Table: Artifact CREATE TABLE IF NOT EXISTS Artifact ( artifactId TEXT PRIMARY KEY, taskId TEXT NOT NULL, sessionId TEXT NOT NULL, name TEXT NOT NULL, content TEXT, -- Storing content as TEXT contentType TEXT, FOREIGN KEY (taskId) REFERENCES Task(taskId), FOREIGN KEY (sessionId) REFERENCES Session(sessionId) ); -- Table: Feedback CREATE TABLE IF NOT EXISTS Feedback ( feedbackId TEXT PRIMARY KEY, sessionId TEXT NOT NULL, taskId TEXT, agentId TEXT, rating REAL, comment TEXT, timestamp TIMESTAMP NOT NULL, FOREIGN KEY (sessionId) REFERENCES Session(sessionId), FOREIGN KEY (taskId) REFERENCES Task(taskId), FOREIGN KEY (agentId) REFERENCES AgentProfile(agentId) ); ``` ### 7. Key Considerations for Implementation * **Technology Stack:** A modern JavaScript framework (e.g., React, Vue, Angular) for the UI, and potentially a WebAssembly-based runtime for core MAS logic if performance is critical. * **LLM Integration:** Utilize libraries like `web-llm` or `transformers.js` for client-side inference, or `fetch` API calls to accessible LLM endpoints. * **State Management:** Leverage IndexedDB for robust storage of session data, tasks, and artifacts. `localStorage` can be used for simpler configuration or session metadata. * **Communication:** Implement a browser-native `MessageBus` using `BroadcastChannel` or `CustomEvent` for inter-agent communication within the same browser context. * **Deployment:** As a stand-alone web app, it can be deployed as static files (HTML, CSS, JavaScript) to any web server or hosting service (e.g., GitHub Pages, Netlify, Vercel). ### 8. Scope and Limitations * **Conceptual:** This specification is conceptual and does not include implementation details for browser-specific adaptations. * **Stand-alone:** No backend server is involved; all processing occurs client-side. * **Limited Scalability:** Performance and memory are constrained by the user's browser capabilities. * **No Data Sharing:** Each user session is independent; data is not shared between users. |