@zohodesk/testinglibrary 0.0.42-n20-experimental → 0.0.44-n20-experimental

package/.github/styleGuides/Steps_README.md

@@ -1,653 +0,0 @@
-# Step Definitions Style Guide
-
-## Table of Contents
-
-1. [Imports & BDD Setup](#1-imports--bdd-setup)
-2. [Step Definition Syntax](#2-step-definition-syntax)
-3. [Context Destructuring](#3-context-destructuring)
-4. [Assertions](#4-assertions)
-5. [Test Data Management](#5-test-data-management)
-6. [CacheLayer & Data Sharing](#6-cachelayer--data-sharing)
-7. [Internationalization (i18N)](#7-internationalization-i18n)
-8. [Multi-Actor & Hooks](#8-multi-actor--hooks)
-9. [Helper Functions & Utilities](#9-helper-functions--utilities)
-10. [Barrel Exports (index.js)](#10-barrel-exports-indexjs)
-11. [Anti-Patterns to Avoid](#11-anti-patterns-to-avoid)
-12. [Checklist for New Step Definitions](#12-checklist-for-new-step-definitions)
-
----
-
-### Naming Conventions
-
-| Artifact | Convention | Examples |
-|----------|-----------|----------|
-| **Module folders** | PascalCase | `Ticket/`, `CustomModule/`, `UserManagement/` |
-| **Spec files** | PascalCase | `SetupNavigation.spec.js`, `ContractCRUD.spec.js` |
-| **Feature files** | PascalCase, matching spec | `SupervisorCRUD.feature` |
-| **Assertion files** | PascalCase + `Assertions` suffix | `SetupAssertions.js`, `BusinessHoursAssertion.js` |
-| **Selector files** | PascalCase + `Selectors` suffix | `LayoutruleSelectors.js`, `DashboardSelectors.js` |
-| **Utility files** | PascalCase + `Utils` suffix | `TicketUtils.js`, `BusinessHourHelper.js` |
-| **Index files** | Lowercase | `index.js` |
-
-
-### Logic Placement Rules
-
-When deciding where to place code, strictly follow these data flow rules:
-- **If it is a locator string** → `dom-selectors/` (pure constants and builder helpers).
-- **If it clicks, fills, or reads UI** → `page-object-model/` (factory functions using selectors).
-- **If it wires a Gherkin step to a POM call** → `steps/` (thin Given/When/Then wiring).
-- **If it validates an outcome** → `assertions/` (if reused across 2+ spec files) or inline in the step itself.
-
----
-
-## 1. Imports & BDD Setup
-
-### Standard Import Block
-
-Every spec.js file **must** begin with the BDD framework import and destructuring:
-
-```javascript
-import { createBdd } from '@zohodesk/testinglibrary';
-
-const { Given, When, Then } = createBdd();
-```
-
-- Import `And` only when needed: `const { Given, When, Then, And } = createBdd();`
-
-### Import Order (Recommended)
-
-Follow this import grouping, separated by blank lines:
-
-```javascript
-// 1. Framework imports
-import { createBdd, expect } from '@zohodesk/testinglibrary';
-
-// 2. Cross-module POM / shared imports
-import { FormActions } from '../../CommonActions';
-import { getModuleObj } from '../../Ticket/utils/ticketUtils';
-
-// 3. Module-local POM imports (via barrel export)
-import { ContractsDetailView, ContractFormPOM, ContractListPOM } from '../index';
-
-// 4. Assertions
-import Assertions from '../../_assertions/Assertions';
-import ContractAssertions from '../assertions/ContractAssertions';
-
-// 5. Constants (i18N keys, test data) — NOT selectors (selectors belong in POM only)
-import { I18N_KEYS } from '../constants/contractConstants';
-
-// 6. BDD destructuring (always last before step definitions)
-const { Given, When, Then } = createBdd();
-```
-
----
-
-## 2. Step Definition Syntax
-
-### Given / When / Then Separation
-
-Maintain strict semantic separation:
-
-| Keyword | Purpose | Example |
-|---------|---------|---------|
-| **Given** | Set up preconditions & navigation | `Given('user is in setup home page', ...)` |
-| **When** | Perform user actions | `When('the user clicks {string} button', ...)` |
-| **Then** | Assert expected outcomes | `Then('the page should display {string}', ...)` |
-| **And** | Continue the preceding keyword | Chain additional Given or When actions or Then assertions |
-
-### Step Name Guidelines
-
-- Use `{string}` placeholders for dynamic values.
-- Keep steps **reusable** — avoid module-specific hardcoding in the step name.
-
-```javascript
-// ✅ Good — reusable and descriptive
-When('the user update the {string} field value to {string}', async ({ page }, field, value) => { ... });
-
-// ❌ Bad — too specific, not reusable
-When('update ticket subject', async ({ page }) => { ... });
-```
-
-### Parameter Patterns
-
-**Single string parameter:**
-```javascript
-When('the user access the {string} contact', async ({ page, i18N }, contact) => {
-    const ticketDv = await ticketDetailViewPOM({ page, i18N });
-    await ticketDv.goToContact(contact);
-});
-```
-
-**Multiple string parameters:**
-```javascript
-Then('the {string} {string} should be updated as {string}',
-    async ({ page, i18N }, moduleName, recordName, statusName) => {
-    const listViewPom = ListView({ page, i18N });
-    const statusElem = await listViewPom.getStatusElem(recordName, statusName, moduleName);
-    await Assertions.isElementVisible(statusElem);
-});
-```
-
-**DataTable parameter:**
-```javascript
-When('the user create a contract with below details',
-    async ({ page, i18N, getMetaInfo, cacheLayer }, dataTable) => {
-    const data = dataTable.hashes();          // Array of row objects
-    const form = await FormActions({ page, i18N, getMetaInfo, cacheLayer });
-    await form.fillForm(data[0]);
-});
-```
-
-**String + DataTable combined:**
-```javascript
-When('the user create a contract for {string} department with below details',
-    async ({ page, i18N, getMetaInfo, cacheLayer }, departmentName, dataTable) => {
-    const data = dataTable.hashes();
-    // ...
-});
-```
-
-### No Branching Logic in Step Definitions
-
-**A step definition must do exactly one thing — no `if/else`, `switch`, or ternary expressions** inside a step body. If conditional logic is needed, it belongs in the POM method; steps remain thin orchestrators.
-
-```javascript
-// ❌ Bad — branching inside a step
-When('the user saves the {string} form', async ({ page }, formType) => {
-    if (formType === 'ticket') {
-        await page.getByTestId('ticketSaveBtn').click();
-    } else {
-        await page.getByTestId('contactSaveBtn').click();
-    }
-});
-
-// ✅ Good — POM handles conditional logic internally
-When('the user saves the {string} form', async ({ page, i18N }, formType) => {
-    const form = FormPOM({ page, i18N });
-    await form.save(formType);
-});
-```
-
----
-
-## 3. Context Destructuring
-
-### Available Context Objects
-
-Every step receives a context object as its first argument. Destructure **only what you need**:
-
-```javascript
-// Full set of available context properties:
-async ({ page, i18N, getMetaInfo, cacheLayer, context, executionContext, actorContext }, ...params) => {}
-```
-
-| Property | Type | Purpose |
-|----------|------|---------|
-| `page` | Playwright Page | Primary browser page interaction |
-| `i18N` | Function (async) | Translate i18N keys to localized strings |
-| `getMetaInfo` | Function (async) | Get current department, org info, actor info |
-| `cacheLayer` | Object | Share data between steps within a scenario |
-| `context` | Playwright BrowserContext | Multi-tab or multi-context operations |
-| `executionContext` | Object | Test execution info (edition, profile, actorInfo) |
-| `actorContext` | Object | Multi-actor support (switching user profiles) |
-
-### Usage Examples for Less Common Context Properties
-
-```javascript
-// executionContext — check the current edition
-When('the user checks edition-specific feature', async ({ page, executionContext }) => {
-    const { edition } = executionContext;
-    const featurePom = FeaturePOM({ page });
-    await featurePom.openEditionFeature(edition);
-});
-
-// actorContext — get the current actor's name
-Then('the comment author should be the current user', async ({ page, actorContext }) => {
-    const { name } = actorContext;
-    const authorElem = page.getByText(name);
-    await Assertions.isElementVisible(authorElem);
-});
-```
-
-### Destructure Only What You Need
-
-```javascript
-// ✅ Good — only destructure used properties
-When('user clicks save', async ({ page }) => { ... });
-
-When('user creates contract', async ({ page, i18N, getMetaInfo, cacheLayer }, dataTable) => { ... });
-
-// ❌ Bad — destructuring unused properties
-When('user clicks save', async ({ page, i18N, getMetaInfo, cacheLayer, context, executionContext }) => { ... });
-```
-
----
-
-## 4. Assertions
-
-> Assertions must never be placed inside POM files. For the full decision guide on **when to use `assertions/` vs inline in the step file**, see [POM_README.md Rule 5](./POM_README.md#rule-5-keep-assertions-outside-pom).
-
-Quick rule: keep assertions inline in the step unless the same locator-read + assertion combination appears in **2+ different spec files** — then extract to `assertions/`.
-
-### Use the Centralized `Assertions` Library
-
-Always import from `_assertions/Assertions.js`. **Do not use raw `expect()` directly** unless there is no matching assertion method.
-
-### Then Steps Are Assertions Only
-
-**`Then` steps must never perform actions.** No clicks, form fills, navigation, or any mutations. Only assertions belong in a `Then` block.
-
-```javascript
-// ❌ Bad — action inside Then
-Then('the record is saved', async ({ page }) => {
-    await page.getByTestId('saveBtn').click();        // ← action in Then!
-    await Assertions.isElementVisible(page.getByText('Saved'));
-});
-
-// ✅ Good — Then only asserts
-Then('the record should be saved', async ({ page, i18N }) => {
-    const form = FormPOM({ page, i18N });
-    const confirmation = await form.getConfirmationElement();
-    await Assertions.isElementVisible(confirmation);
-});
-```
-
-```javascript
-import Assertions from '../../_assertions/Assertions';
-```
-
-### Available Assertion Methods
-
-```javascript
-// Visibility
-await Assertions.isElementVisible(element);
-await Assertions.isElementNotVisible(element);
-
-// Text / Value
-await Assertions.isElementHaveText(element, 'Expected text');
-await Assertions.isElementContainText(element, 'substring');
-await Assertions.isElementHaveValue(element, 'value');
-
-// Attributes
-await Assertions.isElementHaveAttribute(element, { attribute: 'aria-checked', value: 'true' });
-await Assertions.isElementHaveClass(element, 'active');
-
-// State
-await Assertions.isElementDisabled(element);
-await Assertions.isElementEnabled(element);
-await Assertions.isElementChecked(element);
-
-// Equality
-await Assertions.expectedToBe(actual, expected);
-
-// URL
-await Assertions.expectedURL(page, new RegExp(urlPattern));
-
-// Array Comparisons
-Assertions.verifySameElementsInOrder(actualArray, expectedArray);
-Assertions.verifySameElementsIgnoringOrder(actualArray, expectedArray);
-```
-
-### Playwright Auto-Waiting & Assertion Stability
-
-Playwright's built-in `expect()` assertions have **built-in auto-waiting** — they retry until the condition is met or a timeout expires. This makes them inherently more stable than plain JavaScript comparison methods.
-
-**Avoid plain JavaScript assertion methods for UI validations:**
-
-```javascript
-// ❌ Bad — toEqual() is a plain JS comparison with no auto-wait or retry
-const text = await element.textContent();
-expect(text).toEqual('Open');  // Flaky if the element updates asynchronously
-
-// ✅ Good — Playwright auto-waiting wrapped in our central library
-await Assertions.isElementVisible(element);
-await Assertions.isElementHaveText(element, 'Open');
-// Use native expect ONLY if a wrapper like toHaveCount doesn't exist yet
-await expect(element).toHaveCount(3);
-```
-
-### When to Use Direct `expect()`
-
-Only when the centralized `Assertions` library doesn't cover your case:
-
-```javascript
-// Acceptable — boolean comparison not covered by Assertions
-const isListed = await initialPage.isViewNameListed(viewName);
-expect(isListed).toBe(true);
-```
-
----
-
-## 5. Test Data Management
-
-- Use **DataTable** parameters in feature files for structured test data.
-- Use `data-generator/` files for complex or reusable test data sets.
-- Never hardcode test values (record names, IDs, emails) directly in step definitions — pass them through feature file parameters or data generators.
-- Keep test data portable — do not depend on data that exists only in a specific environment.
-
----
-
-## 6. CacheLayer & Data Sharing
-
-Use `cacheLayer` to share data between steps **within the same scenario**:
-
-```javascript
-// Step 1: Store data
-When('the user creates a ticket', async ({ page, cacheLayer }) => {
-    const ticketId = await createTicket(page);
-    await cacheLayer.set('createdTicketId', ticketId);
-});
-
-// Step 2: Retrieve data
-Then('the ticket should appear in detail view', async ({ page, cacheLayer }) => {
-    const ticketId = await cacheLayer.get('createdTicketId');
-    await page.goto(`/tickets/${ticketId}`);
-});
-```
-
-### Rules
-
-- Use **descriptive keys** for cached values.
-- Cache only **primitive values or simple objects**.
-- Pass `cacheLayer` to POMs when they need access to shared data.
-
-### No Global or Environment Variables for Test Data
-
-**Never store test-specific runtime data in `process.env`, module-level variables, or any global scope.** Use `cacheLayer` for scenario-scoped sharing.
-
-```javascript
-// ❌ Bad — module-level global (leaks between scenarios)
-let createdTicketId;
-When('the user creates a ticket', async ({ page }) => {
-    createdTicketId = await createTicket(page);
-});
-
-// ❌ Bad — environment variable mutation (persists globally)
-When('the user creates a ticket', async ({ page }) => {
-    process.env.TICKET_ID = await createTicket(page);
-});
-
-// ✅ Good — cacheLayer is isolated to the current scenario
-When('the user creates a ticket', async ({ page, cacheLayer }) => {
-    const ticketId = await createTicket(page);
-    await cacheLayer.set('ticketId', ticketId);
-});
-```
-
----
-
-## 7. Internationalization (i18N)
-
-> Rule definition: all user-facing strings must use `i18N` — see [POM_README.md Rule 21](./POM_README.md#rule-21-use-i18n-for-all-user-facing-strings).
-
-This section covers `i18N` usage patterns specific to step definitions.
-
-### Usage in Steps
-
-`i18N` is an **async function** — always `await` it:
-
-```javascript
-When('user verifies the label', async ({ page, i18N }) => {
-    const labelText = await i18N('desk.tickets.status.open');
-    const element = page.getByText(labelText);
-    await Assertions.isElementVisible(element);
-});
-```
-
-### Usage via Constants
-
-```javascript
-// Define constants
-const I18N_CONSTANTS = {
-    ACTIVE_FILTER: 'desk.filter.active',
-    SAVE_BUTTON: 'desk.common.save'
-};
-
-// Use in steps
-const saveText = await i18N(I18N_CONSTANTS.SAVE_BUTTON);
-```
-
-### Rules
-
-- **Always use `i18N` for user-facing strings** — never hardcode English text.
-- Pass `i18N` to POMs that need to match labels or button text.
-- Group `i18N` keys in **constants files** for maintainability.
-
----
-
-## 8. Multi-Actor & Hooks
-
-### Switching Between Actors
-
-The following step is **already built into the framework** — do **not** create a new step definition for it. When this step appears in a feature file, it is automatically resolved from the framework side:
-
-```gherkin
-Given access the "admin" profile page
-```
-
-> **No spec.js implementation needed.** This step is pre-registered in the shared test framework (`@zohodesk/testinglibrary`) and handles actor switching internally.
-
-### Rules
-
-- **Do not re-implement framework-provided steps** — if a step like `Given('access the {string} profile page')` already exists in the framework, reuse it as-is.
-
----
-
-## 9. Helper Functions & Utilities
-
-### When to Extract a Helper### Routing "Helper" Logic
-
-Do not create arbitrary "helper" functions inside step definition files. When logic becomes repetitive or complex, extract it strictly according to the framework layers:
-
-* **UI Interaction Helpers (Waits, Clicks, Forms):** If multi-step UI logic or wait logic is reused across steps, extract it as a new action method inside the target **Page Object Model (POM)**.
-
-* **Validation Helpers:** If a complex, multi-line validation is reused across 2+ different `.spec.js` files, extract it to the module's `assertions/` folder.
-
-* **Pure Data Utilities:** Only create a standalone utility file (e.g., `utils/dateFormatter.js`) if the logic is **pure data manipulation** (e.g., math, string formatting, regex, generating random emails) and contains absolutely zero Playwright imports or DOM interactions.
-
-```javascript
-// ✅ Good — extracted to utils
-export async function switchView(page, getMetaInfo, moduleName, viewName) {
-    const { currentDepartment, actorInfo } = await getMetaInfo();
-    const { orgName } = actorInfo;
-    const sanitizedViewName = getSanitizedName(viewName);
-    const sanitizedModuleName = getSanitizedName(moduleName);
-    await page.goto(`${process.env.domain}/${orgName}/${sanitizedDeptName}/${sanitizedModuleName}/list/${sanitizedViewName}${process.env.devUrl}`);
-    const topbar = await page.getByTestId(COMMON_SELECTORS.TOP_BAND_HEADER);
-    await topbar.waitFor();
-}
-
-// Helper for text sanitization
-export const getSanitizedName = (name = '') => {
-    return name.replace(/\s/g, '-').replace(/_/g, '').toLowerCase();
-};
-```
-
-### Waiting Patterns
-
-```javascript
-// ✅ Preferred — wait for page load
-await page.waitForLoadState('load');
-await page.waitForLoadState('domcontentloaded');
-
-// ✅ Preferred — wait for a specific element (strongest validation)
-await element.waitFor();
-await element.waitFor({ state: 'hidden' });
-
-// ✅ Wait for specific API response
-await page.waitForResponse(
-    res => res.url().includes('tickets') && res.status() === 200
-);
-
-// ⚠️ Use with caution — networkidle (see warning below)
-await page.waitForLoadState('networkidle');
-
-// ❌ Never use fixed waits
-await page.waitForTimeout(1000);
-```
-
-### ⚠️ Avoid `networkidle` for Element Verification
-
-**When to use `networkidle`:**
-- It's **not** that `networkidle` should never be used — but it should **only** be applied where it is truly required (e.g., ensuring all resources are fully downloaded before taking a screenshot or exporting a PDF).
-
-- **Never** use it as a substitute for element-based validation.
-
-**What to use instead:**
-```javascript
-// ✅ Good — element-based validation (strongest and most reliable)
-await element.waitFor();
-await Assertions.isElementVisible(element);
-
-// ✅ Good — wait for page load events
-await page.waitForLoadState('load');
-await page.waitForLoadState('domcontentloaded');
-
-// ❌ Bad — using networkidle to verify element presence
-await page.waitForLoadState('networkidle');
-await Assertions.isElementVisible(element);  // flaky!
-```
-
-### DOM Readiness Validation Before Actions
-
-**Always confirm an element is present and stable before performing an action on it.** Never interact with an element immediately after navigation without waiting.
-
-```javascript
-// ❌ Bad — no DOM readiness check
-async clickStatusDropdown() {
-    await this.page.getByTestId('statusDropdown').click();   // may not exist yet
-},
-
-// ✅ Good — wait for element before acting
-async clickStatusDropdown() {
-    const dropdown = this.page.getByTestId('statusDropdown');
-    await dropdown.waitFor();      // confirms DOM is ready
-    await dropdown.click();
-},
-```
-
-### Rules
-
-- **Validate DOM readiness with `waitFor()`** before every action in POM methods — see [POM_README.md Rule 13](./POM_README.md#rule-13-validate-dom-readiness-before-any-action).
-
----
-
-## 10. Barrel Exports (index.js)
-
-Each module must have a root `index.js` that exports all public POMs, assertions, and utilities:
-
-> **Note:** This is the **module root** barrel (`modules/<ModuleName>/index.js`). There is also a **POM-internal** barrel (`page-object-model/index.js`) that re-exports only POM factory functions — see [POM_README.md Rule 20](./POM_README.md#rule-20-use-barrel-exports-for-local-module-poms). The module root barrel consumes the POM barrel and adds assertions and utilities.
-
-```javascript
-// modules/Contract/index.js
-export { default as ContractsDetailView } from './page-object-model/ContractsDetailView';
-export { default as ContractFormPOM } from './page-object-model/ContractFormPOM';
-export { default as ContractListPOM } from './page-object-model/ContractListPOM';
-
-export { default as ContractAssertions } from './assertions/ContractAssertions';
-export { getContractData } from './utils/contractUtils';
-```
-
-### Rules
-
-- **One `index.js` per module** — re-export everything needed externally.
-- **Import from `../index`** in step definitions, not from deep paths.
-- Keep internal files (selectors, helpers) out of barrel exports unless used cross-module.
-
----
-
-## 11. Anti-Patterns to Avoid
-
-
-### ❌ Business Logic in Step Definitions
-
-```javascript
-// ❌ Bad — loop logic belongs in POM
-Then('all rules should be listed', async ({ page }, dataTable) => {
-    const rules = dataTable.hashes();
-    for (const { ruleName } of rules) {
-        const elem = page.getByText(ruleName);
-        await Assertions.isElementVisible(elem);
-    }
-});
-
-// ✅ Good — delegate to POM
-Then('all rules should be listed', async ({ page }, dataTable) => {
-    const rules = dataTable.hashes();
-    const ruleList = RuleListPOM({ page });
-    await ruleList.verifyRulesListed(rules);
-});
-```
-
-### ❌ Unused Context Destructuring
-
-```javascript
-// ❌ Bad
-When('step', async ({ page, i18N, getMetaInfo, cacheLayer, context, executionContext }) => {
-    await page.click('#btn');
-});
-
-// ✅ Good
-When('step', async ({ page }) => {
-    const form = FormPOM({ page });
-    await form.clickBtn();
-});
-```
-
-### ❌ Missing Barrel Exports
-
-```javascript
-// ❌ Bad — deep path imports
-import ContractFormPOM from '../page-object-model/ContractFormPOM';
-import ContractListPOM from '../page-object-model/ContractListPOM';
-
-// ✅ Good — via index.js
-import { ContractFormPOM, ContractListPOM } from '../index';
-```
-
-### ❌ Hardcoded IDs or Locators in Step Definitions
-
-All locators must live in the selector file and be accessed through POM methods — never inline raw `data-testid` strings or CSS selectors in a step:
-
-```javascript
-// ❌ Bad — raw locator inline in step
-When('the user opens the ticket', async ({ page }) => {
-    await page.locator('[data-testid="ticketDetail-12345"]').click();
-});
-
-// ✅ Good — locators live in the selectors file, accessed via POM
-When('the user opens the ticket', async ({ page, i18N }) => {
-    const list = TicketListPOM({ page, i18N });
-    await list.openFirstTicket();
-});
-```
----
-
-## 12. Checklist for New Step Definitions
-
-Use this checklist when creating a new spec.js file:
-
-- [ ] **File placed** in `modules/<ModuleName>/steps/` directory
-- [ ] **File named** in PascalCase with `.spec.js` extension
-- [ ] **Imports** follow the standard order (framework → cross-module → local → assertions → selectors → BDD destructuring)
-- [ ] **`createBdd()`** called and destructured for only needed keywords
-- [ ] If the step already exists → reuse it instead of creating a new one. If the step does not   exist → create new steps.
-- [ ] **Given/When/Then** semantically separated (setup → action → assertion)
-- [ ] **Step names** are descriptive Gherkin English with `{string}` parameters
-- [ ] **Context destructured** with only used properties
-- [ ] **All DOM interactions** delegated to POMs — no raw selectors in steps
-- [ ] **Assertions** use the centralized `Assertions` library
-- [ ] **Test data** managed via utility functions or DataTable, not hardcoded
-- [ ] **i18N used** for all user-facing strings
-- [ ] **No hardcoded timeouts** — use explicit wait conditions
-- [ ] **Corresponding feature file** exists with matching name and proper tags
-- [ ] **Module `index.js`** updated if new POMs or exports are added
-- [ ] **Helper functions** extracted for reused logic, placed in `utils/`
-- [ ] **No branching logic** (`if/else`, `switch`, ternary) inside any step definition — move to POM
-- [ ] **`Then` steps contain only assertions** — no clicks, fills, or navigation
-- [ ] **Scenarios are independent** — can run in any order without relying on shared state
-- [ ] **No global variables or `process.env` mutations** for test data — use `cacheLayer`
-- [ ] **No hardcoded locators or IDs** in step definitions — all DOM access via POM methods
-- [ ] **DOM readiness verified** with `waitFor()` before performing actions in POM methods
-
----

package/.vscode/mcp.json

@@ -1,9 +0,0 @@
-{
-  "servers": {
-    "playwright-test": {
-      "type": "stdio",
-      "command": "npx",
-      "args": ["playwright", "run-test-mcp-server"]
-    }
-  }
-}