imcp 0.0.13 → 0.0.15

package/src/web/public/js/notifications.js

@@ -1,33 +1,68 @@
-// Function to show a Bootstrap alert notification
+// Function to show a toast notification
 function showToast(message, type = 'success') {
     const alertContainer = document.querySelector('.alert-container');
+    if (!alertContainer) {
+        console.error('Alert container not found. Notifications will not be displayed.');
+        return;
+    }
     const alertId = `alert-${Date.now()}`;
-    
+
+    let iconHtml = '';
+    switch (type) {
+        case 'success':
+            iconHtml = '<i class="bi bi-check-circle-fill alert-icon"></i>';
+            break;
+        case 'error':
+            iconHtml = '<i class="bi bi-x-octagon-fill alert-icon"></i>'; // Changed icon for error
+            break;
+        case 'info':
+            iconHtml = '<i class="bi bi-info-circle-fill alert-icon"></i>';
+            break;
+        case 'warning':
+            iconHtml = '<i class="bi bi-exclamation-triangle-fill alert-icon"></i>';
+            break;
+        default:
+            iconHtml = '<i class="bi bi-bell-fill alert-icon"></i>'; // Default icon
+    }
+
     const alertHtml = `
-        <div id="${alertId}" class="alert alert-${type} alert-dismissible fade show" role="alert">
-            ${type === 'success' ?
-                '<i class="bi bi-check-circle-fill me-2"></i>' :
-                '<i class="bi bi-exclamation-triangle-fill me-2"></i>'
-            }
-            ${message}
-            <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
+        <div id="${alertId}" class="alert alert-${type}" role="alert">
+            ${iconHtml}
+            <span>${message}</span>
+            <button type="button" class="btn-close" aria-label="Close"></button>
         </div>
     `;
-    
+
     alertContainer.insertAdjacentHTML('beforeend', alertHtml);
-    
+
     const alertElement = document.getElementById(alertId);
-    
-    // Remove the alert after 5 seconds
-    setTimeout(() => {
-        const bsAlert = new bootstrap.Alert(alertElement);
-        bsAlert.close();
-    }, 3000);  // Reduced to 3 seconds
-    
-    // Remove the element after animation
-    alertElement.addEventListener('closed.bs.alert', () => {
-        alertElement.remove();
+    if (!alertElement) return;
+
+    // Trigger the slide-in animation
+    // Adding a slight delay to ensure the element is in the DOM before adding the 'show' class
+    requestAnimationFrame(() => {
+        requestAnimationFrame(() => { // Double requestAnimationFrame for more reliable transition start
+            alertElement.classList.add('show');
+        });
     });
+
+
+    const closeButton = alertElement.querySelector('.btn-close');
+
+    const dismissAlert = () => {
+        alertElement.classList.remove('show'); // Trigger slide-out animation
+        // Wait for fade out animation to complete before removing
+        alertElement.addEventListener('transitionend', () => {
+            alertElement.remove();
+        }, { once: true }); // Ensure event listener is removed after execution
+    };
+
+    if (closeButton) {
+        closeButton.addEventListener('click', dismissAlert);
+    }
+
+    // Auto-dismiss after 5 seconds (increased from 3)
+    setTimeout(dismissAlert, 5000);
 }
 
 // Function to show a confirmation dialog using custom modal system
@@ -35,7 +70,7 @@ function showConfirm(title, message) {
     return new Promise((resolve) => {
         const modalId = `confirm-modal-${Date.now()}`;
         const modalHtml = `
-            <div id="${modalId}" class="modal">
+            <div id="${modalId}" class="modal" style="display: none;">
                 <div class="modal-content" style="max-width: 400px; margin: 15% auto;">
                     <div class="modal-header">
                         <h3 class="text-lg font-semibold text-gray-700">${title}</h3>
@@ -54,19 +89,23 @@ function showConfirm(title, message) {
                 </div>
             </div>
         `;
-        
+
         document.body.insertAdjacentHTML('beforeend', modalHtml);
-        
+
         const modalElement = document.getElementById(modalId);
-        modalElement.style.display = 'block';
-        
+        // Trigger display after a short delay to allow CSS transitions if any are added later for modals
+        requestAnimationFrame(() => {
+            modalElement.style.display = 'block';
+        });
+
+
         // Handle confirm button click
         modalElement.querySelector('.confirm-button').addEventListener('click', () => {
             modalElement.style.display = 'none';
             modalElement.remove();
             resolve(true);
         });
-        
+
         // Handle cancel button click
         modalElement.querySelector('.cancel-button').addEventListener('click', () => {
             modalElement.style.display = 'none';

package/src/web/public/js/onboard/ONBOARDING_PAGE_DESIGN.md

@@ -0,0 +1,338 @@
+# 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).
+- **`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` AND `fullReq.version === depReq.version`.
+  - 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 using the shared `pollOperationStatus` function (from `validationHandlers.js`). This function periodically calls `GET /api/categories/:categoryName/onboard/status`.
+  - **Displaying Results**: The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays the results from both the initial publish call and subsequent status polls in the relevant status panel. It shows overall status, messages, PR info (if available), and detailed validation results if included in the publish response.
+  - **Completion/Failure**: Polling stops when the status is 'COMPLETED', 'FAILED', or 'succeeded'. Upon completion or failure, the "Publish" button reverts to its original state, and both "Validate" and "Publish" buttons are re-enabled. Success and error messages are displayed using `showToast()`.
+- **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 using the shared `pollOperationStatus` function (from `validationHandlers.js`).
+    - This function uses the `onboardingId` (category name) from the validation response to periodically call `GET /api/categories/:categoryName/onboard/status`.
+  - **Displaying Results**:
+    - The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays the results from both the initial validation call and subsequent status polls in the relevant status panel.
+    - It handles different structures of the `validationStatus` object in the response, including displaying overall status, messages, and detailed results for each server if `validationStatus.serverResults` is present.
+  - **Completion/Failure**:
+    - Polling stops when the status is 'COMPLETED', 'FAILED', or 'succeeded'.
+    - Upon completion or failure, the "Validate" button reverts to its original state ("Validate" text and icon), and both "Validate" and "Publish" buttons are re-enabled.
+- **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 Fixes and Changes (May 2025)
+
+This section documents significant fixes and behavior changes implemented recently.
+
+- **Visibility of Existing Category Servers:**
+
+  - **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.
+
+- **Requirement Lookup in `populateForm`:**
+
+  - **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.
+
+---
+
+## 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.