imcp 0.0.19 → 0.1.2

package/dist/web/server.js

@@ -6,9 +6,12 @@ import { SUPPORTED_CLIENT_NAMES } from '../core/metadatas/constants.js';
 import { serverService } from '../services/ServerService.js';
 import { feedOnboardService } from '../core/onboard/FeedOnboardService.js';
 import { openBrowser } from '../utils/osUtils.js';
-import { Logger } from '../utils/logger.js';
+import { Logger, EventType, EventStatus } from '../utils/logger.js';
 import { configProvider } from '../core/loaders/ConfigurationProvider.js';
 import { onboardStatusManager } from '../core/onboard/OnboardStatusManager.js';
+import { InstallOperationManager } from '../core/loaders/InstallOperationManager.js';
+import { systemSettingsManager } from '../core/loaders/SystemSettingsManager.js';
+import { getAppVersion } from '../utils/versionUtils.js';
 const __dirname = path.dirname(fileURLToPath(import.meta.url));
 const app = express();
 // Middleware
@@ -252,6 +255,31 @@ app.get('/api/categories/:categoryName/onboard/status', async (req, res) => {
         });
     }
 });
+// Get installation operation status
+app.get('/api/categories/:categoryName/servers/:serverName/installation/status', async (req, res) => {
+    try {
+        const { categoryName, serverName } = req.params;
+        const details = await InstallOperationManager.getInstance(categoryName, serverName).getDetails();
+        if (!details) {
+            return res.status(404).json({
+                success: false,
+                error: `No installation operation found for server ${serverName} in category ${categoryName}`
+            });
+        }
+        const response = {
+            success: true,
+            data: details
+        };
+        res.json(response);
+    }
+    catch (error) {
+        const message = error instanceof Error ? error.message : 'Unknown error';
+        res.status(500).json({
+            success: false,
+            error: `Failed to get installation operation status for server ${req.params.serverName} in category ${req.params.categoryName}: ${message}`
+        });
+    }
+});
 // Uninstall tools from a server
 app.post('/api/categories/:categoryName/uninstall', async (req, res) => {
     try {
@@ -290,6 +318,60 @@ app.post('/api/categories/:categoryName/uninstall', async (req, res) => {
         });
     }
 });
+// System Settings API
+app.get('/api/settings', async (req, res) => {
+    try {
+        const settings = await systemSettingsManager.getSystemSettings();
+        const response = {
+            success: true,
+            data: settings
+        };
+        res.json(response);
+    }
+    catch (error) {
+        const message = error instanceof Error ? error.message : 'Unknown error';
+        res.status(500).json({
+            success: false,
+            error: `Failed to get system settings: ${message}`
+        });
+    }
+});
+app.post('/api/settings', async (req, res) => {
+    try {
+        const newSettings = req.body;
+        const updatedSettings = await systemSettingsManager.createOrUpdateSystemSettings(newSettings);
+        const response = {
+            success: true,
+            data: updatedSettings
+        };
+        res.json(response);
+    }
+    catch (error) {
+        const message = error instanceof Error ? error.message : 'Unknown error';
+        res.status(500).json({
+            success: false,
+            error: `Failed to update system settings: ${message}`
+        });
+    }
+});
+// API to get package version
+app.get('/api/version', async (req, res) => {
+    try {
+        const appVersionData = await getAppVersion();
+        const response = {
+            success: true,
+            data: appVersionData
+        };
+        res.json(response);
+    }
+    catch (error) {
+        const message = error instanceof Error ? error.message : 'Unknown error';
+        res.status(500).json({
+            success: false,
+            error: `Failed to get package version: ${message}`
+        });
+    }
+});
 export async function startWebServer(port = 3000) {
     return new Promise((resolve, reject) => {
         const server = app.listen(port, () => {
@@ -299,9 +381,19 @@ export async function startWebServer(port = 3000) {
             openBrowser(url).catch(err => {
                 console.warn(`Failed to open browser: ${err.message}`);
             });
+            // Track IMCP serve event
+            Logger.trackEvent(EventType.IMCP_SERVE, {
+                status: EventStatus.SUCCESS,
+                port: port,
+            });
             resolve();
         });
         server.on('error', (error) => {
+            Logger.trackEvent(EventType.IMCP_SERVE, {
+                status: EventStatus.FAILED,
+                errorMessage: error instanceof Error ? error.message : String(error),
+                port: port
+            });
             reject(error);
         });
     });

package/{src/web/public/js/onboard → docs}/ONBOARDING_PAGE_DESIGN.md

@@ -15,8 +15,6 @@ The JavaScript logic is modularized into several files within `src/web/public/js
 - **`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).
-- **`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).
 
 ---
 
@@ -73,7 +71,7 @@ Located in `formProcessor.js`, this function populates the HTML form using a `Fe
 - **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` AND `fullReq.version === depReq.version`.
+  - 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.
@@ -197,132 +195,22 @@ This summary covers the main design patterns and implementation choices made for
 
 ---
 
-## 9. Recent Fixes and Changes (May 2025)
+## 9. Recent Changes (May 2025)
 
-This section documents significant fixes and behavior changes implemented recently.
-
-- **Visibility of Existing Category Servers:**
+- **Requirement Lookup in `populateForm`:**
+  Requirement lookup for server dependencies now matches by `name` only (not `name` and `version`).
 
-  - **Issue:** When selecting an existing category in the "Create Server in Existing Category" tab, the container holding the list of existing MCP servers (`existingCategoryMcpServersContainer`) and the servers themselves were not becoming visible, even though the data was being fetched and `populateForm` was called.
-  - **Root Cause Analysis:** Extensive logging revealed that `existingCategoryMcpServersContainer` was being correctly unhidden before `populateForm` was called. However, immediately after `populateForm` completed, the container was found to be hidden again. The exact mechanism causing this re-hiding was elusive but seemed to occur synchronously within or immediately after `populateForm`'s execution, despite `populateForm` itself not directly hiding the container. Standard form reset (`form.reset()`) was ruled out as the cause.
-  - **Solution:**
-    1.  In `templates.js`, the `serverTemplate` was modified to ensure that the main content `div` of a server item (`server-content-${serverIndex}`) includes the `hidden` class by default. This allows the `toggleSectionContent` function to correctly manage its visibility.
-    2.  In `uiHandlers.js`, within the `addServer` function, if a server is being rendered as `isReadOnly` (i.e., an existing server), its content section (`#server-content-${newServerIndex}`) is explicitly made visible by removing the `hidden` class. This ensures that existing servers are expanded by default when displayed.
-    3.  **Crucially**, in `index.js`, within the `handleExistingCategorySelection` function, after `populateForm` is called to display the existing servers, a line was added to explicitly call `mcpServersContainer.classList.remove('hidden');`. This ensures that the main container for these servers is visible, overriding whatever was causing it to become hidden.
-  - **Outcome:** Existing servers for a selected category are now correctly displayed and visible.
+- **UI and Validation Improvements:**
 
-- **Requirement Lookup in `populateForm`:**
+  - 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.
 
-  - **Issue:** The logic in `formProcessor.js` (`populateForm`) for finding the full `RequirementConfig` for a server's dependency was matching on both `name` and `version`.
-  - **Change Request:** The lookup should only be based on the requirement `name`, ignoring the `version` specified in the server's dependency list when matching against the global `feedConfig.requirements`.
-  - **Solution:** In `formProcessor.js`, the line:
-    `const fullReq = (feedConfig.requirements || []).find(r => r.name === depReq.name && r.version === depReq.version);`
-    was changed to:
-    `const fullReq = (feedConfig.requirements || []).find(r => r.name === depReq.name);`
-    The associated warning message was also updated to reflect this change in lookup behavior.
-
-- **Code Cleanup:**
-
-  - All diagnostic `console.log` statements added during the debugging of the visibility issue were removed from `index.js`, `formProcessor.js`, and `uiHandlers.js`.
-  - The experimental `requestAnimationFrame` logic for forcing a reflow in `formProcessor.js` was removed as it was not the solution to the visibility problem.
-
-- **Tab Switching and View Mode Toggling Enhancements:**
-
-  - **Context:** A series of changes were made to improve the user experience related to switching between the main onboarding tabs ("Create New Category", "Create Server in Existing Category") and toggling between the Form view and JSON editor view.
-  - **Issues Addressed & Solutions:**
-    1.  **JSON View Buttons Hidden (`uiHandlers.js`):**
-        - **Problem:** Buttons like "Cancel" and "Publish JSON" were visible in the JSON editor view, which was not desired.
-        - **Solution:** The `toggleViewMode` function in `uiHandlers.js` was updated to explicitly hide the `jsonEditorActionsContainer` when switching to JSON view.
-    2.  **JSON View Content Preservation (`uiHandlers.js`):**
-        - **Problem:** Clicking the JSON view toggle switch again while already in JSON view would cause the editor's content to be re-processed or cleared.
-        - **Solution:** The `toggleViewMode` function in `uiHandlers.js` now checks if the target view (Form or JSON) is already active. If so, it returns early, preventing unnecessary re-rendering and preserving the current content.
-    3.  \*\*Tab Switching Logic Improvements (`index.js`):
-        - **Problem 1:** Clicking on a main navigation tab that was already active would still trigger tab switching logic, potentially causing unnecessary view updates.
-        - **Solution 1:** The `switchTab` function in `index.js` now checks if the `targetTab` is the same as the `activeTab`. If so, it returns immediately.
-        - **Problem 2:** When switching away from the "Create New Category" tab and then back to it (without being in an edit-category scenario), any entered form data was lost due to an automatic form reset.
-        - **Solution 2:** The automatic call to `resetOnboardFormDynamicContent('onboardForm')` within `switchTab` for the "Create New Category" tab (in non-edit scenarios) was removed. This allows form data to be preserved when tabbing away and back.
-        - **Problem 3:** If the JSON view was active and a user clicked on a different main navigation tab, the new tab's form content could render on top of or alongside the still-visible JSON editor.
-        - **Solution 3:** The `switchTab` function in `index.js` was updated. If the JSON view is active when a tab switch is initiated, it now first calls `toggleViewMode(false, ...)` to programmatically switch back to the Form view (for the currently active tab) before proceeding to display the content of the newly selected tab. This ensures a clean transition from JSON view to the new tab's form view.
-  - **Outcome:** These changes provide a more stable, predictable, and user-friendly experience when navigating between tabs and view modes. Data entered by the user is better preserved, and UI rendering artifacts during transitions are avoided.
-
-- **Dropdown Reset, Form Disappearance, and Misplaced Validation (May 2025 - Current Session):**
-  - **Context:** A series of interconnected issues were addressed to improve the stability and correctness of the "Create New Server in Existing Category" tab and its interaction with view toggling and validation.
-  - **Issues Addressed & Solutions:**
-    1.  **Existing Category Dropdown Reset (`formProcessor.js`):**
-        - **Problem:** After selecting a category from the `existingCategorySelect` dropdown on the "Create New Server in Existing Category" tab, the dropdown would immediately reset to its default "Select a category" or "Loading..." state.
-        - **Root Cause:** The `populateForm` function, called upon category selection, invoked `resetOnboardFormDynamicContent`. Inside `resetOnboardFormDynamicContent`, the line `formToReset.reset()` was being called for the `onboardServerForm` (the form containing the dropdown). This `HTMLFormElement.reset()` method reverts all form controls to their initial HTML values.
-        - **Solution:** The `resetOnboardFormDynamicContent` function in `formProcessor.js` was modified. The `formToReset.reset()` call is now conditional: it is skipped if `formId` is `'onboardServerForm'`, thus preserving the dropdown's selected value. Other dynamic content clearing (server list, counters) within the function remains active.
-    2.  **Form Disappearance on JSON Toggle (Existing Category Tab - `formProcessor.js`):**
-        - **Problem:** On the "Create New Server in Existing Category" tab, if a category was selected (displaying its basic info and servers), then the view was toggled to JSON and back to Form view, the displayed category information would vanish.
-        - **Root Cause:** When `toggleViewMode` (in `uiHandlers.js`) switched from JSON back to Form view, it called `populateForm`. However, `populateForm` lacked specific logic to re-populate the basic category information fields (name, display name, description, repository) for the `onboardServerForm`. Additionally, the containers for this basic info (`existingCategoryBasicInfoContainer`) and the MCP servers (`existingCategoryMcpServersContainer`) were not being explicitly made visible again after `resetOnboardFormDynamicContent` (called by `populateForm`) might have hidden them or cleared their content.
-        - **Solution:**
-          - An `else if (formId === 'onboardServerForm' && feedConfig)` block was added to `populateForm` in `formProcessor.js`. This block now explicitly populates the read-only basic category information fields using the `feedConfig` data.
-          - Within this new block, `existingCategoryBasicInfoContainer.classList.remove('hidden')` and `existingCategoryMcpServersContainer.classList.remove('hidden')` are called to ensure these sections are visible.
-    3.  **Validation Results on Wrong Tab (Multiple Files):**
-        - **Problem:** Clicking the "Validate" button on the "Create New Server in Existing Category" tab would display the validation results in the validation panel of the "Create New Category" tab.
-        - **Root Cause:** Validation panels, content areas, and buttons on both tabs shared common HTML IDs (e.g., `validationStatusPanel`, `validateButton`). JavaScript's `getElementById` would typically find the first matching element in the DOM, leading to the incorrect panel being targeted.
-        - **Solution (Multi-file update):**
-          - **HTML (`onboard.html`):** All relevant validation-related element IDs were made unique for each tab (e.g., `validationStatusPanelNewCategory`, `validateButtonNewCategory`, `validationStatusPanelExistingCategory`, `validateButtonExistingCategory`).
-          - **Event Listeners (`index.js`):** Event listeners for the "Validate" buttons were updated to target these new unique IDs.
-          - **Validation Logic (`validationHandlers.js`):**
-            - The `handleValidation` function was updated to accept `activeTab` and `currentSelectedCategoryData` as parameters. It now dynamically determines the correct, unique element IDs for the panel, content area, form, validate button, and publish button based on the `activeTab`.
-            - The `pollValidationStatus` function was modified to accept these dynamic element IDs as parameters, ensuring it updates the UI on the correct tab during polling.
-            - The call to `getFormData` within `handleValidation` was adjusted to pass the `forExistingCategoryTab` flag and `currentSelectedCategoryData` when validating for the "Create Server in Existing Category" tab.
-          - **Form Reset Logic (`formProcessor.js`):**
-            - The `resetOnboardFormDynamicContent` function was updated. When resetting validation panels, it now determines the correct unique panel ID and content ID based on the `formId` parameter, ensuring it hides and clears the appropriate panel for the active tab.
-  - **Outcome:** These fixes ensure that the "Create New Server in Existing Category" tab functions correctly with respect to category selection, view toggling, and validation display, providing a more robust and intuitive user experience.
-
-- **API Data Integrity and UI State for "Create Server" Tab (May 2025 - Current Session):**
-  - **Context:** Two issues were addressed related to the "Create Server in Existing Category" tab's interaction with backend APIs and UI feedback during operations.
-  - **Issues Addressed & Solutions:**
-    1.  **Incomplete Data Sent to API:**
-        - **Problem:** When using the "Validate" or "Publish" buttons on the "Create Server in Existing Category" tab, only the data for the newly added server(s) was being sent to the backend, omitting the data of the existing category to which they were being added.
-        - **Solution:**
-          - The `handleValidation` function in `validationHandlers.js` was updated. It now retrieves the new server data using `getFormData` and then merges it with the `currentSelectedCategoryData` (the full data of the existing category) before sending the combined `FeedConfiguration` to the `/api/categories/onboard/validate` endpoint.
-          - Similarly, the `handlePublish` function in `publishHandler.js` was updated to perform the same merge of new server data with `currentSelectedCategoryData` before sending the complete payload to the `/api/categories/onboard` endpoint.
-        - **Outcome:** The backend now receives the full, correct `FeedConfiguration` when a new server is validated or published within an existing category.
-    2.  **Persistent Spinner on Publish Failure:**
-        - **Problem:** If a publish operation failed (e.g., backend returns a "FAILED" status), the "Publish" button would remain in its loading state (displaying a spinner icon) instead of reverting to its active state.
-        - **Root Cause:** The status check within the `pollOperationStatus` function (in `validationHandlers.js`) was case-sensitive when comparing the received status string (e.g., "failed") against expected terminal states (e.g., "FAILED"). If the casing didn't match, the logic to reset button states wasn't triggered.
-        - **Solution:**
-          - The `pollOperationStatus` function in `validationHandlers.js` was modified to convert the received status string to uppercase before comparing it against 'COMPLETED', 'FAILED', or 'SUCCEEDED'. This makes the check case-insensitive.
-          - Additionally, the direct error/failure handling paths within `handlePublish` (in `publishHandler.js`) were enhanced to ensure both "Publish" and "Validate" buttons are comprehensively reset (disabling, innerHTML, and opacity classes) if the initial publish call itself fails or returns a terminal status immediately.
-        - **Outcome:** The "Publish" and "Validate" buttons now reliably revert to their default active states when an operation (validation or publish) concludes with a failure, regardless of the casing of the status string from the backend or whether the failure occurs immediately or during polling.
-  - **Overall Outcome:** These changes improve the reliability of data submission and provide more accurate UI feedback for asynchronous operations on the "Create Server in Existing Category" tab.
-
-- **Enhanced Operation Status Polling and Display (May 2025 - Current Session):**
-  - **Context:** Significant improvements were made to the handling of asynchronous operations (validation and publishing), including more detailed progress display, robust polling, and clearer API interactions.
-  - **Issues Addressed & Solutions:**
-    1.  **Server-Side API (`server.ts` - `/api/categories/:categoryName/onboard/status`):**
-        -   The endpoint now requires an `operationType` query parameter (e.g., `VALIDATION_ONLY`, `FULL_ONBOARDING`).
-        -   The response payload (`OperationStatus`) was enhanced to include:
-            -   `steps`: An array of objects detailing each step of the operation (name, serverName, timestamp, status, errorMessage).
-            -   `operationType`: Reflects the type of operation being tracked, taken from the status object.
-            -   `feedConfiguration`: Conditionally included for successful `VALIDATION_ONLY` operations if present in the result.
-            -   The `onboardingId` in the response is `categoryName_operationType`.
-            -   The `message` field in the response now prioritizes the last step's name or an overall error message.
-    2.  **Client-Side Polling Logic (`validationHandlers.js` - `pollOperationStatus`):**
-        -   The function now accepts an `operationType` parameter, which is passed to the API.
-        -   It returns a boolean promise (`Promise<boolean>`) indicating whether polling should continue, allowing the caller (`handleValidation` or `handlePublish`) to manage `clearInterval`.
-        -   Calls `ensureProgressToggleListener` to ensure the UI for displaying progress steps is interactive.
-        -   Status comparisons (`COMPLETED`, `FAILED`, `SUCCEEDED`) are now case-insensitive.
-    3.  **Operation Initiation (`publishHandler.js` - `handlePublish`, `validationHandlers.js` - `handleValidation`):**
-        -   When initiating polling, these functions now pass the correct `operationType` (`FULL_ONBOARDING` for publish, `VALIDATION_ONLY` for validate) and use the original `finalFeedConfiguration.name` as the `categoryName` for the polling request.
-        -   They now manage `clearInterval` based on the boolean returned by `pollOperationStatus`.
-        -   Both handlers call `ensureProgressToggleListener` at the beginning to prepare the UI for status updates.
-        -   `handlePublish` includes improved error handling for the initial publish request, ensuring UI elements are correctly updated even if the initial call fails or returns a terminal status.
-    4.  **UI Display (`validationHandlers.js` - `updateOperationDisplay`):**
-        -   A new collapsible "Progress" section is displayed, showing detailed `steps` from the API response. Each step includes:
-            -   A status icon (error, in-progress spinner, success).
-            -   The step name, server name (if applicable), and timestamp.
-            -   An error message for the step, if any.
-        -   The visibility of the "Progress" section is managed by `ensureProgressToggleListener` (which attaches a click handler to the section header) and the `toggleSectionContent` utility.
-        -   The `operationType` is now displayed.
-        -   The logic for displaying the overall status spinner has been updated to cover more in-progress states (e.g., `PENDING`, `VALIDATING`, `PRCREATING`, `PUBLISHING`) and uses case-insensitive comparisons.
-    5.  **Progress Section Toggling (`validationHandlers.js` - `ensureProgressToggleListener`):**
-        -   A new exported utility function, `ensureProgressToggleListener`, was added. It attaches a click event listener to the status content element. This listener delegates to `toggleSectionContent` (from `uiHandlers.js`) when the progress section header is clicked, allowing users to expand or collapse the detailed list of progress steps. The listener is attached only once per status content element.
-  - **Outcome:** These changes provide users with more granular and interactive feedback on long-running operations, improve the robustness and accuracy of status polling, and align client-server communication for tracking asynchronous onboarding tasks.
----
+- **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
 
@@ -331,6 +219,7 @@ The server validation system consists of multiple components that work together
 ### 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
 
@@ -342,6 +231,7 @@ The server validation system consists of multiple components that work together
 ### Validator Implementations
 
 1. **StdioServerValidator**:
+
    - Validates stdio-mode MCP server configurations
    - Key validation steps:
      - Verifies installation command exists and is executable

package/docs/Telemetry.md

@@ -0,0 +1,136 @@
+# 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

@@ -0,0 +1,26 @@
+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

@@ -0,0 +1,91 @@
+# 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

@@ -0,0 +1,41 @@
+# 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_