imcp 0.1.7 → 0.1.8-dev

package/docs/ONBOARDING_PAGE_DESIGN.md

@@ -1,260 +0,0 @@
-# Onboarding Page: JavaScript Design and Implementation
-
-This document outlines the JavaScript architecture and key implementation details for the dynamic onboarding page.
-
----
-
-## 1. File Structure and Roles
-
-The JavaScript logic is modularized into several files within `src/web/public/js/onboard/`:
-
-- **`index.js`**: Main entry point. Handles page initialization, event listeners for primary actions (form submission, tab switching), loading existing data, and orchestrates calls to other modules for more complex UI interactions like view toggling and validation.
-- **`formProcessor.js`**: Handles conversion between the HTML form and the `FeedConfiguration` JSON object. Contains logic for `formDataToFeedConfiguration` (Form → JSON), `populateForm` (JSON → Form), and `resetOnboardFormDynamicContent`. Also includes the `submitForm` handler.
-- **`uiHandlers.js`**: Manages dynamic UI manipulations, such as adding/removing server sections, environment variables, and server-specific requirements. Includes re-indexing logic, handlers for collapsible sections, view mode toggling (`toggleViewMode`), JSON data saving (`saveJsonData`), and clipboard operations (`copyJsonToClipboard`).
-- **`validationHandlers.js`**: Manages the validation process, including initiating validation requests (`handleValidation`). It also provides shared utility functions for polling operation status (`pollOperationStatus`) and updating the UI with operation results (`updateOperationDisplay`), which are used by both validation and publishing flows.
-- **`publishHandler.js`**: Manages the publishing process. This includes initiating publish requests (`handlePublish`), and utilizing shared functions from `validationHandlers.js` for polling status and displaying results.
-- **`templates.js`**: Contains HTML string templates for dynamically generated form sections (e.g., server items, environment variables, requirements).
-- **`state.js`**: Manages client-side state, primarily counters for dynamically added elements (servers, env vars per server, requirements per server).
-
----
-
-## 2. Core Data Model: `FeedConfiguration`
-
-The central data structure is `FeedConfiguration` (defined in `src/core/types.ts`). This object represents the entire configuration for a new server category.
-
-**Key aspects:**
-
-- `name`, `displayName`, `description`, `repository`: Basic category information.
-- `mcpServers: McpConfig[]`: Array of server configurations. Each `McpConfig` includes:
-  - `name`, `mode`, `description`, `schemas`, `repository`
-  - `installation`: Contains `command`, `args`, and `env` (an object mapping environment variable names to their configurations).
-  - `dependencies`: Contains `requirements: Array<{ name: string; version: string; order?: number; }>` (references to full requirement definitions).
-- `requirements: RequirementConfig[]`: Top-level array of unique, fully defined requirements. Each includes:
-  - `name`, `type` (npm, pip, command, etc.), `version`
-  - Optional: `alias` (for command type)
-  - Optional: `registry` (for private/custom registries like GitHub, Artifactory, local)
-
----
-
-## 3. Form to JSON Conversion (`formDataToFeedConfiguration`)
-
-Located in `formProcessor.js`, this function converts data from the HTML form into a `FeedConfiguration` object.
-
-**Process:**
-
-- **Parsing Strategy:** Iterates through `FormData` entries. Uses regex to identify and group fields belonging to specific servers, environment variables, and requirements based on their name attributes (e.g., `servers[0].name`, `servers[0].repository`, `servers[0].installation.env[0].name`).
-- **Server Processing:**
-  - Collects all fields for each server into a temporary map.
-  - Converts collected data into `McpConfig` objects.
-  - Environment variables are transformed from an array of objects into the `installation.env` object structure (key-value pairs).
-- **Requirement Processing:**
-  - For each server, its requirements are processed.
-  - **Server-Specific Dependencies:** An array of `{ name, version, order }` objects is created for `mcpServer.dependencies.requirements`.
-  - **Global Requirements List:** Full `RequirementConfig` objects (including type, alias, registry details) are constructed for each requirement defined in the form. These are added to a temporary map (`globalRequirementsMap`) to ensure uniqueness.
-  - **De-duplication Key:** The key `${type}|${name}|${version}` ensures requirements differing in type, name, or version are treated as distinct entries in the top-level `feedConfiguration.requirements` array.
-- **Output:** Returns a complete `FeedConfiguration` object.
-
----
-
-## 4. JSON to Form Conversion (`populateForm`)
-
-Located in `formProcessor.js`, this function populates the HTML form using a `FeedConfiguration` object. This is crucial when loading an existing category for editing or when switching from the JSON view back to the form view.
-
-**Process:**
-
-- **Form Reset:** Before populating, `resetOnboardFormDynamicContent()` (now part of `formProcessor.js` and called by `populateForm` itself) is invoked to clear existing dynamic elements and reset relevant state counters.
-- **Basic Fields:** Populates top-level category fields (`name`, `displayName`, etc.).
-- **Server Population:**
-  - Iterates through `feedConfig.mcpServers`.
-  - For each server, `window.addServer()` (from `uiHandlers.js`) is called to create the basic server UI block.
-  - Server-specific fields (`name`, `mode`, `description`, `repository`, `schema`, `installation` command/args) are populated.
-- **Environment Variables:** Iterates `server.installation.env`, calls `window.addEnvVariable()` for each, and populates its fields.
-- **Package Dependencies:**
-  - Iterates through `server.dependencies.requirements` (which are `{name, version, order}` objects, referred to as `depReq`).
-  - For each `depReq`, searches the top-level `feedConfig.requirements` array to find the corresponding full `RequirementConfig` object (`fullReq`) by matching `fullReq.name === depReq.name`.
-  - If `fullReq` is found, `window.addServerRequirement()` is called to create the UI block for this requirement within the server.
-  - All fields of the requirement (`type`, `version`, `alias`, `registry` details) are then populated using data from `fullReq` and `depReq.order`.
-  - Conditional UI elements (alias field, specific registry config sections) are toggled based on the requirement's type and selected registry.
-
----
-
-## 5. Dynamic UI Handling (`uiHandlers.js`, `templates.js`)
-
-- **`templates.js`**: Provides HTML string template functions (`serverTemplate`, `envVariableTemplate`, `serverRequirementTemplate`) that generate the necessary HTML for dynamic sections. This includes correct indices for name attributes, `onclick` handlers, and structures for collapsible sections with toggle icons.
-  - The `serverTemplate` structures each server item with collapsible sub-sections for "Package Dependencies" (which includes an "Add Dependency" button), "Startup Configuration", and "Environment Variables", in that order. It also includes a `server-content-scrollable` class on the main server content `div` for vertical scrolling.
-  - The `serverRequirementTemplate` (used within "Package Dependencies") includes a registry type dropdown that defaults to "Public Registry" and omits the "Local Registry" and placeholder options.
-  - Icon-only buttons with tooltips are used (e.g., the "Remove Server" button).
-- **`uiHandlers.js`**:
-  - **Adding Elements:**
-    - `addServer()`: Determines the new server's index. Inserts HTML using `serverTemplate` (which includes a collapsible server structure with sub-sections). Initializes state counters. Attaches an `onchange` event listener to the new server's mode `<select>` element, which calls `renderInstallationConfig`. Calls `renderInstallationConfig` to display the initial UI for the "Startup Configuration" section (defaulting to `stdio` fields). The server header is clickable to toggle its content visibility.
-    - `addEnvVariable(serverIndex)`, `addServerRequirement(serverIndex)`: Get current counter for the specific server, insert HTML using respective templates, and increment the counter.
-  - **Rendering Startup Configuration:**
-    - `renderInstallationConfig(serverIndex)`: This function is called when a server is added or its mode is changed. It populates the "Startup Configuration" section based on the server's current mode:
-      - If `sse`: Clears the startup configuration container (e.g., `installation-config-${serverIndex}`) and inserts an input field for `installation.url`. Hides the "Environment Variables" block.
-      - If `stdio` (or other): Clears the startup configuration container and inserts input fields for `installation.command` and `installation.args`. Shows the "Environment Variables" block.
-  - **Removing Elements:**
-    - `removeServer(serverIndexToRemove)`: Removes the server item from the DOM, then calls `reindexServers()`.
-    - `removeEnvVariable(serverIndex, envIndex)`, `removeServerRequirement(serverIndex, reqIndex)`: Remove the specific item. (Re-indexing of these sub-items happens within `reindexServers` when a parent server is re-indexed.)
-  - **Re-indexing:**
-    - `reindexServers()`: Called after a server is removed.
-      - Iterates through all remaining server items in the DOM.
-      - For each server item and its new sequential index (`newServerIndex`):
-        - Updates its `data-index` attribute.
-        - Updates its displayed title (e.g., "MCP Server #1").
-        - Updates name attributes of all form elements within it to reflect `newServerIndex`.
-        - Updates `onclick` handlers for all relevant buttons (remove server, add env var, add requirement, etc.) to use `newServerIndex`.
-        - Updates IDs of dynamically generated elements (e.g., `schema-path-`, `envVarsContainer_`, `server-requirements-list-`).
-        - Recursively re-indexes nested environment variables and server-specific requirements:
-          - Updates their `data-env-index`/`data-req-index`.
-          - Updates their input name attributes (e.g., `servers[newServerIndex].installation.env[newEnvIndex]...`).
-          - Updates their `onclick` and `onchange` handlers with new indices.
-          - Updates their dynamic IDs.
-      - After re-indexing all servers and their children, it rebuilds/updates `state.envCounters` and `state.serverRequirementCounters` and sets `state.serverCounter` to the new total.
-  - **Toggling Fields:**
-    - `toggleServerAliasField()`: Shows/hides the alias input based on requirement type (`command`).
-    - `toggleServerRegistryConfig()`: Shows/hides specific registry configuration sections based on the selected registry type.
-    - `browseLocalSchema()`: Uses File System Access API (with fallback) to allow users to select a local schema file, populating its name into the input field.
-    - `toggleSectionContent(contentId, iconElement)`: Generic handler to toggle the visibility of a content element (identified by `contentId`) and update an associated icon's state (e.g., chevron up/down). Used for all collapsible sections.
-    - `toggleViewMode(isJsonView)`: Handles switching between the form view and the JSON editor view. Manages data conversion and panel visibility.
-    - `saveJsonData()`: Handles submitting the data from the JSON editor.
-    - `copyJsonToClipboard()`: Copies the content of the JSON editor to the clipboard.
-
----
-
-## 6. State Management (`state.js`)
-
-Provides a simple client-side state store.
-
-- `state.serverCounter`: Tracks the total number of server sections. Managed by `setServerCounter()`, which is updated by `addServer()` and `reindexServers()`.
-- `state.envCounters` (`Map`): `serverIndex` → count for environment variables within each server.
-- `state.serverRequirementCounters` (`Map`): `serverIndex` → count for requirements within each server.
-
-These maps are updated by their respective add... functions and fully rebuilt by `reindexServers()` to ensure consistency after deletions and re-indexing.
-
----
-
-## 7. View Toggling (Form vs. JSON Editor — `uiHandlers.js` & `formProcessor.js`)
-
-A toggle switch allows users to switch between the standard form view and a raw JSON editor view.
-
-- **Switching to JSON View:**
-  - `getFormData(currentForm)` (from `formProcessor.js`) is called, which internally uses `formDataToFeedConfiguration` to get the `FeedConfiguration` object.
-  - This object is `JSON.stringify`-ed and displayed in a `<textarea>`.
-  - The form panel is hidden, and the JSON editor panel is shown.
-- **Switching back to Form View (from JSON):**
-  - The JSON content is read from `jsonEditorTextarea` and parsed.
-  - `resetOnboardFormDynamicContent()` (from `formProcessor.js`) is called by `populateForm` (also from `formProcessor.js`):
-    - Clears the `serversList` container in the DOM.
-    - Resets the main form (`onboardForm.reset()`).
-    - Resets state counters (`setServerCounter(0)`, `state.envCounters.clear()`, `state.serverRequirementCounters.clear()`) using imported functions/objects from `state.js`.
-  - `populateForm(parsedJsonData)` (from `formProcessor.js`) is called to reconstruct the form from the (potentially edited) JSON.
-  - If parsing or populating the form fails:
-    - An error notification is shown using `showToast()`.
-    - The view remains in JSON mode.
-    - The view mode toggle switch is ensured to be in the "JSON View" state.
-  - If successful, the JSON editor panel is hidden, and the form panel is shown.
-
-> The `toggleViewMode` function in `uiHandlers.js` orchestrates this. Application of JSON to the form (via `populateForm` in `formProcessor.js`) is automatic upon switching back to the form view. If it fails, the user stays in JSON view.
-
----
-
-## 8. Other Key Features (`index.js`, `formProcessor.js`, `validationHandlers.js`, `publishHandler.js`, `uiHandlers.js`)
-
-- **Loading Existing Category (`loadExistingCategory` in `index.js`)**: If a `?category=categoryName` URL parameter is present, fetches the category data from `/api/categories/:categoryName`, and then uses `populateForm()` (from `formProcessor.js`) to fill the form for editing. Errors are reported using `showToast()`.
-- **Publishing (`handlePublish` in `publishHandler.js`)**:
-  - Triggered by the "Publish" button.
-  - Calls `getFormData()` (from `formProcessor.js`) to get the current form data as `FeedConfiguration`.
-  - Sends an initial POST request to `/api/categories/onboard` with the `FeedConfiguration` object and an `isUpdate` flag.
-  - The "Publish" button shows a spinning loader icon and its text changes to "Publishing...". Both "Validate" and "Publish" buttons are disabled.
-  - **Polling for Status**: If the initial publish request is successful and the operation is not immediately completed or failed, `handlePublish` initiates polling. The shared `pollOperationStatus` function (from `validationHandlers.js`) is called, which periodically queries `GET /api/categories/:categoryName/onboard/status?operationType=FULL_ONBOARDING`. `pollOperationStatus` now returns a boolean to manage polling continuation.
-  - **Displaying Results**: The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays detailed progress, including individual steps, from both the initial publish call and subsequent status polls.
-  - **Completion/Failure**: Polling stops based on the status returned by `pollOperationStatus`. Upon completion or failure, buttons are reset, and `showToast()` displays messages. For detailed information on recent changes to polling and status display, see Section 9: "Enhanced Operation Status Polling and Display".
-- **Validation (`handleValidation` in `validationHandlers.js`)**:
-- **Validation (`handleValidation` in `validationHandlers.js`)**:
-  - The `validationStatusPanel` (unique per tab) is located under the "MCP Servers" section (or equivalent) and above the main action buttons ("Validate", "Publish"). It is a foldable panel.
-  - When the "Validate" button is clicked:
-    - Calls `getFormData()` (from `formProcessor.js`) to get the current form data as `FeedConfiguration`.
-    - Sends an initial POST request to `/api/categories/onboard/validate`.
-    - The "Validate" button shows a spinning loader icon and its text changes to "Validating...". Both "Validate" and "Publish" buttons are disabled.
-  - **Polling for Status**:
-    - If the initial validation request is successful and the operation is not immediately completed or failed, `handleValidation` initiates polling.
-    - The shared `pollOperationStatus` function (from `validationHandlers.js`) is called, which periodically queries `GET /api/categories/:categoryName/onboard/status?operationType=VALIDATION_ONLY` (using the category name from the form). `pollOperationStatus` now returns a boolean to manage polling continuation.
-  - **Displaying Results**:
-    - The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays detailed progress, including individual steps, from both the initial validation call and subsequent status polls.
-    - It handles different structures of the `validationStatus` object and overall operation status.
-  - **Completion/Failure**:
-    - Polling stops based on the status returned by `pollOperationStatus`.
-    - Upon completion or failure, buttons are reset. For detailed information on recent changes to polling and status display, see Section 9: "Enhanced Operation Status Polling and Display".
-- **Copy JSON (`copyJsonToClipboard` in `uiHandlers.js`)**: Copies the content of `jsonEditorTextarea` to the clipboard. Uses `showToast()` for feedback.
-- **Global Function Exposure**: Necessary UI handler functions (like `addServer`, `removeServer`, `toggleSectionContent`, etc.) are attached to the `window` object so they can be called from `onclick` attributes in the HTML templates.
-- **Custom Notifications**: Standard browser `alert()` calls have been replaced with a custom toast notification system (`showToast()` from `../notifications.js`). This system requires an `.alert-container` div in the host HTML (`onboard.html`) and uses CSS from `css/notifications.css` for styling. The `notifications.js` module handles the creation, display, and dismissal (manual and automatic) of these toasts without relying on Bootstrap's JavaScript.
-
----
-
-This summary covers the main design patterns and implementation choices made for the onboarding page's frontend logic.
-
----
-
-## 9. Recent Changes (May 2025)
-
-- **Requirement Lookup in `populateForm`:**
-  Requirement lookup for server dependencies now matches by `name` only (not `name` and `version`).
-
-- **UI and Validation Improvements:**
-
-  - Unique IDs are used for validation panels and buttons per tab to avoid cross-tab issues.
-  - Switching between tabs and view modes now preserves form data and ensures correct UI state.
-  - The JSON editor view is now properly toggled and content is preserved as expected.
-  - Polling for operation status (validation/publish) is more robust and status checks are case-insensitive.
-  - Progress steps for operations are now shown in a collapsible section for better feedback.
-
-- **General Cleanup:**
-  - Redundant diagnostic logs and experimental code were removed.
-  - Form reset logic was improved to avoid unwanted clearing of dropdowns or form fields.
-
-## 10. Server Validation System
-
-The server validation system consists of multiple components that work together to validate MCP server configurations. This ensures that servers are properly configured before they can be deployed.
-
-### Server Validator Architecture
-
-- **`IServerValidator` Interface**: Defines the common validation contract for all server validators:
-
-  - `validateServer(server: McpConfig, config: FeedConfiguration): Promise<boolean>`
-  - Implementations throw errors with descriptive messages when validation fails
-
-- **`ServerValidatorFactory`**: Factory class managing validator instances
-  - Maintains a singleton map of validators by type ('stdio' | 'sse')
-  - Provides methods to get appropriate validator for server mode
-  - Initializes validators on construction
-
-### Validator Implementations
-
-1. **StdioServerValidator**:
-
-   - Validates stdio-mode MCP server configurations
-   - Key validation steps:
-     - Verifies installation command exists and is executable
-     - Validates required environment variables
-     - Validates and installs dependencies using installer factory
-     - Tests server startup with path resolution for:
-       - Node commands: Resolves `${NPMPATH}` in arguments
-       - Python commands: Resolves `${PYTHON_PACKAGE}` in arguments
-     - Uses timeout-based server startup testing with output monitoring
-     - Comprehensive error handling and logging
-
-2. **SSEServerValidator**:
-   - Validates SSE-mode MCP server configurations
-   - Key validation steps:
-     - Verifies installation URL is present and valid
-     - Validates server mode is 'sse'
-     - Extensible design for additional SSE-specific validation
-
-### Error Handling
-
-- All validators provide detailed error messages through Error objects
-- Errors include specific validation failure reasons (e.g., missing command, invalid URL)
-- Logging is implemented throughout the validation process
-- Error messages propagate to the UI for user feedback
-
-This validation system ensures that server configurations are complete and functional before deployment, reducing runtime issues and improving reliability.

package/docs/Telemetry.md

@@ -1,136 +0,0 @@
-# Application Insights Telemetry Integration
-
-This document describes the telemetry implementation in the MCP SDK using Azure Application Insights.
-
-## Overview
-
-The MCP SDK integrates Azure Application Insights for telemetry tracking across various operations. This provides insights into server operations, requirement updates, and system health.
-
-## Implementation Details
-
-### TelemetryService
-
-Located in `src/services/TelemetryService.ts`, this service provides a centralized interface for telemetry operations:
-
-- Initialization with Application Insights configuration
-- Event tracking
-- Exception tracking
-- Trace logging
-- Metric tracking
-- Data flushing capability
-
-```typescript
-// Example usage:
-TelemetryService.trackEvent("eventName", { property: "value" });
-TelemetryService.trackException(error, { context: "operation" });
-```
-
-### Key Features
-
-1. **Cloud Role Tagging**: Services are tagged as 'imcp' for clear identification in Application Insights
-2. **Batch Processing**: Configured with a max batch size of 250 events
-3. **Automatic Error Handling**: Graceful handling of initialization failures
-
-## Integration Points
-The telemetry service is integrated at key points throughout the system:
-
-### User Identity Tracking
-- GitHub user information persistence for Mac/Linux systems
-- Automatic alias extraction from Microsoft accounts
-- Cross-platform username resolution (using OS username for Windows)
-
-### Server Operations
-- Server installation/uninstallation tracking
-- Operation success/failure monitoring
-- Target client tracking
-
-### Requirement Management
-- Requirement update tracking
-- Version change monitoring
-- Update operation status tracking
-
-### Feed Management
-- Feed onboarding process monitoring
-- Sync operations tracking
-- Configuration changes tracking
-
-## Event Types
-
-The system tracks several types of events:
-
-1. **Server Events**
-   - Installation (`SERVER_INSTALL`)
-   - Uninstallation (`SERVER_UNINSTALL`)
-
-2. **Requirement Events**
-   - Updates (`REQUIREMENT_UPDATE`)
-
-3. **Feed Events**
-   - Onboard (`FEED_ONBOARD`)
-   - Validate (`FEED_VALIDATE`)
-
-4 **IMCP Events**
-   - IMCP serve (`IMCP_SERVE`)
-
-## Best Practices
-1. **Error Tracking**
-   - Always include error messages in failed operations
-   - Track operation context with properties
-
-2. **Event Properties**
-   - Include relevant identifiers (categoryName, serverName)
-   - Track operation status
-   - Include version information when applicable
-   - Include user alias in events (automatically handled by Logger)
-
-3. **User Identity Persistence**
-   - Store GitHub user information (alias, name, email) for Mac/Linux users
-   - Skip persistence for Windows users (uses OS username)
-   - Only persist for Microsoft accounts (username ending with _microsoft)
-   - Cache user information to avoid repeated API calls
-   - Include version information when applicable
-
-4. **Performance Monitoring**
-   - Use metric tracking for performance-sensitive operations
-   - Implement proper batching for high-volume events
-
-## Configuration
-
-The telemetry service is configured with:
-- Azure resource: [imcp-telemetry](https://ms.portal.azure.com/#@microsoft.onmicrosoft.com/resource/subscriptions/b211ffce-ec5c-4267-b15c-138d440e3fbc/resourcegroups/aicoder/providers/microsoft.insights/components/imcp-telemetry/overview)
-- Instrumentation Key: `c5fc06c7-a96c-4d80-9aff-bc9c933db0d1`
-- Cloud Role: `imcp`
-- Batch Size: 250 events
-
-## User Identity in Telemetry
-
-The system implements user identity tracking through the Logger class (`src/utils/logger.ts`):
-
-1. **User Resolution**
-   - Windows: Uses OS username directly via `os.userInfo()`
-   - Mac/Linux: Uses GitHub alias stored in user info file
-   - Falls back to OS username if user info is unavailable
-
-2. **Identity Storage**
-   - Location: Stored in system-specific settings directory
-   - Format: JSON file containing alias, name, and email
-   - Updates: Managed during GitHub authentication
-
-3. **Identity Usage**
-   - All telemetry events automatically include username/alias
-   - Consistent user tracking across sessions
-   - Microsoft account validation ensures organizational identity
-
-## Future Improvements
-
-1. **Enhanced Metrics**
-   - Add performance metrics for key operations
-   - Implement custom metric dimensions
-
-2. **Error Analysis**
-   - Implement more detailed error categorization
-   - Add correlation IDs for related operations
-
-3. **User Analytics**
-   - Track user interaction patterns
-   - Monitor feature usage statistics

package/memory-bank/activeContext.md

@@ -1,26 +0,0 @@
-ru# Active Context
-
-## Current Focus
-
-- [2025-05-16 09:22:21] - Task completed: Made "IMCP Server Manager" title in `src/web/public/index.html` clickable, linking to `index.html`.
-- [YYYY-MM-DD HH:MM:SS] - Initializing Memory Bank.
-
-## Recent Changes
-
-- [YYYY-MM-DD HH:MM:SS] - Created activeContext.md.
-- [2025-05-16 13:28:00] - Refactored `InstallationService` to delegate requirement handling to the new `RequirementService`. Updated `RequirementService` to correctly handle `reqConfig` scoping and type fallbacks in `processRequirementUpdates`.
-
-## Open Questions/Issues
-
-- None
-
-[2025-05-16 16:07:29] - Current Focus: Completed redesign of installation operation status and polling. New InstallOperationManager and associated types/APIs implemented. Step recording integrated into relevant services and installers.
-[2025-05-17 00:26:11] - Refactoring InstallOperationManager: Now instance-based per category/server, with new file structure for status persistence. Current focus is on updating all usages and ensuring compatibility with the new API and file layout.
-[2025-05-17 15:02:39] - Current Focus: Completed refactoring of `RequirementService.ts` to use the new instance-based `InstallOperationManager` and its `recording`/`recordingAsync` methods. This aligns it with the updated `InstallOperationManager` architecture.
-[2025-05-17 15:26:20] - Current focus: Refactored all requirement installer classes and factory to support InstallOperationManager step recording. All install methods now accept a recorder and log critical steps for install operations.
-[2025-05-18 13:21:30] - Current Focus: Completed implementation of main modal refresh logic. This involved:
-  - Modifying `loadingModal.js` to dispatch a `refreshMainModalContent` event on close.
-  - Updating `installation.js` to store `categoryName` and `serverName` in `localStorage`.
-  - Adding an event listener in `modal.js` to retrieve these values and call `showInstallModal` with both parameters, resolving previous "Server configuration not found" errors.
-  - This replaces the previous page reload behavior, improving UX.
-[2025-05-18 11:33:18] - Current Focus: Standardized all step recording names for installation/onboarding operations by introducing `src/core/metadatas/recordingConstants.ts`. This file now serves as the single source of truth for static step names and documents dynamic step name patterns, ensuring consistency across backend and frontend.

package/memory-bank/decisionLog.md

@@ -1,91 +0,0 @@
-# Decision Log
-
-This file records significant architectural or technical decisions, including rationale and implications.  
-Update this file with a timestamped entry whenever a major decision is made.
-
----
-
----
-
-[2025-05-15 19:56:12] - Memory Bank updated to reflect onboarding page architecture and features as described in [`docs/ONBOARDING_PAGE_DESIGN.md`](../docs/ONBOARDING_PAGE_DESIGN.md).
-
-- Modular JS architecture for onboarding UI, form-to-JSON, validation, publishing, and state.
-- Central `FeedConfiguration` model for category/server/requirement data.
-- Enhanced UX: dynamic sections, toggling, notifications, robust validation/publishing.
-- Recent improvements: server visibility, requirement lookup, async feedback, tab/view handling.
-  [2025-05-15 20:48:27] - Implemented MCP Server Duplication Feature.
-- Added a duplicate button to the right of the delete button in the server item template (`src/web/public/js/onboard/templates.js`).
-- Modified `duplicateServer` function in `src/web/public/js/onboard/uiHandlers.js` to correctly retrieve data from the server to be duplicated, even if it's read-only. This was achieved by temporarily enabling form fields of the source server item before calling `getFormData`.
-- Ensured that the duplicated server is always created as a new, editable server, and all its content (including environment variables and requirements) is copied from the original server.
-- The `populateServerManually` function ensures that sub-items (env vars, requirements) of the duplicated server are also created in an editable state.
-- This functionality applies to both "Create New Category" and "Create Server in Existing Category" tabs.
-- Fixed the error "Could not retrieve data for the server to duplicate" when duplicating read-only servers.
-
-[2025-05-16 00:34:40] - [Fixed duplicate server functionality]
-- Issue: Duplicating non-first servers failed with "Could not retrieve data" error
-- Fix: Modified duplicateServer() to temporarily enable ALL disabled fields before form submission
-- Impact: Ensures complete server data is captured regardless of position in list
-- Files affected: src/web/public/js/onboard/uiHandlers.js
-[2025-05-16 13:27:43] - Refactored requirement management logic from `InstallationService` into a new dedicated `RequirementService`. `InstallationService` now delegates requirement-related tasks (checking status, installing, updating) to `RequirementService`. This improves separation of concerns and modularity.
-
-[2025-05-16 16:07:20] - Redesigned the operation status and polling mechanism for Installation in both frontend and backend. This involved creating a new InstallOperationManager, new types for operation details, an API endpoint for status retrieval, and integrating step recording into InstallationService, RequirementService, and BaseClientInstaller. This provides more granular tracking of installation progress.
-
-[2025-05-16 16:50:05] - Added 'overallStatus' to InstallOperationDetails and updated InstallOperationManager to manage it. Modified frontend polling in 'src/web/public/js/modal/installation.js' to use the new installation status API and display detailed steps.
-
-[2025-05-16 17:03:17] - Enhanced the display of installation steps in the loading modal. Modified 'messageQueue.js' to support step-specific formatting (icons, success/failure states) and updated 'installation.js' to pass these options. Added CSS in 'modal.css' for the new step display styles.
-
-[2025-05-16 17:08:31] - Refined installation step display: made fonts smaller, increased compactness, and added timestamps for each step. Updated 'modal.css' and 'messageQueue.js' accordingly. 'installation.js' now passes the timestamp.
-
-[2025-05-16 17:19:37] - Overhauled the installation loading modal UI. 'loadingModal.js' now dynamically creates a new structure with an overall status (icon + text) and a detailed steps list. 'installation.js' was updated to use new functions in 'loadingModal.js' for status and step updates. 'messageQueue.js' was simplified as direct DOM manipulation for steps is now in 'loadingModal.js'. Added extensive CSS in 'modal.css' for the new layout and styling.
-
-[2025-05-16 17:23:42] - Fixed error caused by removed 'delayedAppendInstallLoadingMessage'. Updated 'modalSetup.js' and 'installation.js' (uninstallTools function) to use the new 'updateOverallInstallStatus' from 'loadingModal.js' for general status messages during uninstallation.
-
-[2025-05-16 17:26:13] - Final fix for 'delayedAppendInstallLoadingMessage' error: removed unused import from 'installModal.js'.
-
-[2025-05-16 17:29:59] - Corrected 'src/web/public/js/modal/index.js' barrel file: removed imports and re-exports of 'delayedAppendInstallLoadingMessage' and 'appendInstallLoadingMessage' as they no longer exist. Added new exports for 'updateOverallInstallStatus' and 'addInstallationStep'.
-
-[2025-05-16 17:31:35] - Corrected 'src/web/public/js/modal.js' (another barrel file): removed import and global assignment of 'appendInstallLoadingMessage'. Added missing exports for 'showInstallLoadingModal' and 'hideInstallLoadingModal'.
-
-[2025-05-16 17:46:59] - Implemented reset of installation operation status. Added `resetOperation` method to `InstallOperationManager.ts` to delete existing status for a server. Called this method at the beginning of `InstallationService.ts#install` to ensure a clean state for new installations.
-
-[2025-05-16 17:51:01] - UI adjustments for installation loading modal:
-  - Added a close button (X) to the top-right corner with functionality to hide the modal.
-  - Ensured installation steps are explicitly left-aligned using `justify-content: flex-start`.
-  - Modified the 'completed' status icon to be a checkmark within a green circle.
-  - Reviewed and confirmed the 'in-progress' spinner icon.
-
-[2025-05-16 17:53:42] - Refined step message alignment in installation loading modal: Added `align-items: flex-start` and `text-align: left` to `.step-info`, and `text-align: left` with `width: 100%` to `.step-message` in `modal.css` to ensure text content is fully left-aligned.
-
-[2025-05-16 17:55:32] - UI adjustment for installation loading modal: Removed the "Details" header text from above the steps list in `loadingModal.js`.
-
-[2025-05-16 17:57:02] - Corrected removal of "Details" header in installation loading modal: Entire line `<div class="steps-list-header">Details</div>` was removed from `loadingModal.js` instead of being commented out with an invalid HTML comment.
-
-[2025-05-17 00:26:02] - Refactored InstallOperationManager to require categoryName and serverName in the constructor, removed singleton/static pattern, and changed status file storage to per-category/server at Settings_Dir/InstallOperationStatus/CategoryName/ServerName.json. This enables instance-based management and more granular status persistence.
-
-[2025-05-17 15:02:27] - Refactored `RequirementService.ts` to use instance-based `InstallOperationManager`.
-- The `processRequirementUpdates` and `checkAndInstallRequirements` (including its helper `installRequirementsInBackground`) methods in [`src/services/RequirementService.ts`](src/services/RequirementService.ts:0) were updated.
-- They now obtain an `InstallOperationManager` instance using `InstallOperationManager.getInstance(categoryName, serverName)`.
-- The core logic within these methods, and the individual requirement processing loops, are now wrapped with `iom.recording()` or `iom.recordingAsync()` for robust step tracking and error handling.
-- This change aligns `RequirementService.ts` with the new instance-based, per-category/server architecture of `InstallOperationManager` introduced in [2025-05-17 00:26:02].
-- Rationale: Simplifies step recording, centralizes status management within the `InstallOperationManager` instance, and improves consistency across services.
-- Implications: Removed direct calls to the deprecated global `installOperationManager.recordStep` and adopted the more structured `recording` pattern.
-
-[2025-05-17 15:26:09] - Updated all requirement installer classes and interface to support step recording via InstallOperationManager. All install methods now accept an optional recorder and record critical steps using recordStep/recording.
-
-[2025-05-18 13:21:30] - Implemented main modal refresh on loading modal close, replacing page reload.
-- Rationale: Improve UX by maintaining main modal context and avoiding disruptive page reloads after installation/uninstallation operations shown in the loading modal.
-- Implementation Details:
-  - `src/web/public/js/modal/loadingModal.js`: Modified `hideInstallLoadingModal` to dispatch a custom event `refreshMainModalContent` instead of causing a page reload.
-  - `src/web/public/js/modal/installation.js`: Modified `handleBulkClientInstall` to store `categoryName` as `lastSelectedCategory` and `serverName` as `lastSelectedServerName` in `localStorage` when an installation process begins. This ensures the context is available for the refresh.
-  - `src/web/public/js/modal.js`: Added an event listener for `refreshMainModalContent`. This listener retrieves `lastSelectedCategory` and `lastSelectedServerName` from `localStorage`. If both are valid, it calls `window.showInstallModal(lastSelectedCategory, lastSelectedServerName)` to refresh the content of the main installation modal.
-- Debugging: Iteratively refined the logic in `modal.js` to correctly handle and validate `lastSelectedCategory` and `lastSelectedServerName` to prevent errors when calling `showInstallModal`. This was crucial for ensuring `showInstallModal` received the necessary `serverName` argument, resolving "Server configuration not found" errors.
-[2025-05-18 11:33:12] - Added `src/core/metadatas/recordingConstants.ts` as the canonical source for all step recording names used in installation and onboarding operations. This file centralizes all static step names as constants and documents dynamic step name patterns, improving consistency and discoverability for step-based operation tracking across backend and frontend.
-
-[2025-05-18 20:46:46] - Reduced the height and key size in the System Environment Variables section of the settings UI for a more compact and modern appearance. This involved decreasing row padding, shrinking the key column width, and reducing the key font size in `src/web/public/js/settings.js`.
-
-[2025-05-18 21:00:26] - Macro resolution logic updated: Now resolves macro values (${PYTHON_PACKAGE}, ${NPMPATH}, ${BROWSER_PATH}) by first checking SystemSettingsManager (system settings), and only falls back to previous behavior if not found. This centralizes macro configuration and improves consistency across the system.
-
-[2025-05-19 00:14:06] - Updated settings page UI and functionality:
-  - Removed "NPM Global Package Path" field from `src/web/public/settings.html` and `src/web/public/js/settings.js`.
-  - Added a descriptive prompt "Stored and used for mcp server installation environments." with a question icon (`bx-help-circle`) on the same line as the "User Configurations" title in `src/web/public/settings.html`.
-  - Modified `src/web/public/js/settings.js` to render user configuration values as `type="password"` if the key contains "key". Added an eye icon button *inside* the value input field to toggle visibility for these password fields, maintaining original input box sizes.

package/memory-bank/productContext.md

@@ -1,41 +0,0 @@
-# Product Context
-
-This file contains the high-level project description, goals, features, and overall architecture for the onboarding page and related systems.
-
----
-
-## Onboarding Page Overview
-
-- **Purpose:** Dynamic onboarding UI for configuring new server categories and MCP servers.
-- **Frontend Structure:** Modular JavaScript in [`src/web/public/js/onboard/`](src/web/public/js/onboard):
-  - `index.js`: Entry point, tab switching, event listeners, loading/editing categories.
-  - `formProcessor.js`: Converts form ↔ JSON (`FeedConfiguration`), validation, populating UI.
-  - `uiHandlers.js`: Dynamic UI (add/remove servers, env vars, requirements), view toggling, section collapsing.
-  - `templates.js`: HTML templates for servers, env vars, requirements.
-  - `state.js`: Tracks counters for dynamic elements.
-  - `validationHandlers.js`: Validation logic, polling, progress display.
-  - `publishHandler.js`: Handles publishing, status polling, and feedback.
-
----
-
-## Core Data Model
-
-- **FeedConfiguration** (see [`src/core/types.ts`](src/core/types.ts)):
-  - `name`, `displayName`, `description`, `repository`
-  - `mcpServers`: Array of server configs (mode, install, env, dependencies)
-  - `requirements`: Unique, fully defined requirements (type, name, version, registry, alias)
-
----
-
-## Key Features
-
-- Dynamic form sections for servers, environment variables, and requirements.
-- Toggle between form and JSON editor views.
-- Robust validation and publishing flows with polling and progress UI.
-- Custom notification system for user feedback.
-- Enhanced UX for editing, tab switching, and error handling.
-- All code and UI logic is aligned with [`docs/ONBOARDING_PAGE_DESIGN.md`](../docs/ONBOARDING_PAGE_DESIGN.md).
-
----
-
-_Last updated: 2025-05-15_

package/memory-bank/progress.md

@@ -1,35 +0,0 @@
-# Progress Log
-
-- [YYYY-MM-DD HH:MM:SS] - Initializing Memory Bank.
-
-- [2025-05-16 09:22:36] - Completed: Made "IMCP Server Manager" title clickable in `src/web/public/index.html`.
-- [2025-05-16 13:28:10] - Completed: Refactored requirement management from `InstallationService` to `RequirementService`. Fixed `reqConfig` scoping and type fallbacks in `RequirementService.processRequirementUpdates`.
-
-[2025-05-16 16:07:34] - Completed: Redesign installation operation status and polling mechanism.
-  - Added `InstallOperationDetails` type to `src/core/metadatas/types.ts`.
-  - Created `InstallOperationManager` in `src/core/loaders/InstallOperationManager.ts`.
-  - Added API endpoint for installation status in `src/web/server.ts`.
-  - Integrated `recordStep` in `InstallationService`, `RequirementService`, and `BaseClientInstaller`.
-
-[2025-05-16 16:50:21] - Enhanced installation status:
-  - Added `overallStatus` to `InstallOperationDetails` in `src/core/metadatas/types.ts`.
-  - Updated `InstallOperationManager` in `src/core/loaders/InstallOperationManager.ts` to manage `overallStatus`.
-  - Modified frontend polling in `src/web/public/js/modal/installation.js` to use the new API `/api/categories/:categoryName/servers/:serverName/installation/status` and display detailed steps.
-
-[2025-05-17 00:26:16] - Began refactoring InstallOperationManager to be instance-based per category/server, with new file structure for status. Memory bank updated to reflect architectural and pattern changes.
-
-[2025-05-17 15:02:44] - Completed: Refactored `RequirementService.ts` to use instance-based `InstallOperationManager` and its `recording`/`recordingAsync` methods. This involved updating `processRequirementUpdates`, `checkAndInstallRequirements`, and `installRequirementsInBackground`.
-
-[2025-05-18 11:33:23] - Completed: Standardized step recording names by creating `src/core/metadatas/recordingConstants.ts`. This centralizes static step names and documents dynamic patterns for installation/onboarding operations.
-
-[2025-05-18 13:21:30] - Completed: Implemented main modal refresh logic to replace page reload.
-  - `loadingModal.js`: Dispatches `refreshMainModalContent` event on close.
-  - `installation.js`: Stores `categoryName` and `serverName` in `localStorage`.
-  - `modal.js`: Listens for event, retrieves context from `localStorage`, and calls `showInstallModal` with both `categoryName` and `serverName`.
-  - This resolves "Server configuration not found" errors and improves UX.
-[2025-05-17 15:26:15] - Refactored all requirement installer classes and factory to support InstallOperationManager step recording. All install methods now accept a recorder and log critical steps.
-
-[2025-05-19 00:14:13] - Completed: Updated settings page (`src/web/public/settings.html` and `src/web/public/js/settings.js`):
-  - Removed "NPM Global Package Path" display.
-  - Added prompt with a question icon for User Configurations, displayed on the same line as the section title.
-  - Implemented secret input type for keys containing "key" in User Configurations, with an eye icon button *inside* the value input field to toggle visibility (maintaining original input box sizes).

package/memory-bank/systemPatterns.md

@@ -1,10 +0,0 @@
-# System Patterns
-
-- [YYYY-MM-DD HH:MM:SS] - Initializing Memory Bank.
-
-[2025-05-18 13:21:30] - Implemented an event-driven modal refresh pattern for the installation UI.
-  - Pattern: Instead of page reloads, the loading modal (`loadingModal.js`) dispatches a custom DOM event (`refreshMainModalContent`) upon closing.
-  - Context Persistence: The initiating action (e.g., in `installation.js`) stores necessary context (like `lastSelectedCategory` and `lastSelectedServerName`) in `localStorage`.
-  - Event Handling: The main modal controller (`modal.js`) listens for this event, retrieves context from `localStorage`, and re-initializes/refreshes its content (`showInstallModal`) with the persisted context.
-  - Benefit: This decouples the loading modal from the main modal, allows for non-disruptive UI updates, and maintains user context effectively.
-[2025-05-17 00:26:06] - Changed InstallOperationManager from singleton/static to instance-based, with per-category/server file storage pattern: Settings_Dir/InstallOperationStatus/CategoryName/ServerName.json. This introduces a more granular, object-oriented persistence and management pattern for install operation status.