@salesforce/b2c-dx-mcp 0.4.4 → 0.4.5

package/content/pwav3/testing.md

@@ -0,0 +1,124 @@
+# Testing
+
+## Overview
+
+PWA Kit applications use Jest and React Testing Library for testing. Tests are co-located with source files using the `.test.js` or `.test.jsx` suffix.
+
+## Testing Stack
+
+- **Jest** - Test runner and assertion library
+- **React Testing Library** - Component testing utilities
+- **@testing-library/user-event** - User interaction simulation
+- **MSW (Mock Service Worker)** - API mocking at network layer
+- **jest-fetch-mock** - Fetch API mocking
+
+## Test File Organization
+
+Co-locate test files with source code:
+
+```
+app/components/product-tile/
+├── index.jsx
+└── product-tile.test.jsx
+
+app/hooks/
+├── use-current-basket.js
+└── use-current-basket.test.js
+```
+
+## Jest Configuration
+
+**Reference:** The template uses `@salesforce/pwa-kit-dev/configs/jest`. Extend it and set `moduleNameMapper` for `@salesforce/retail-react-app` if needed.
+
+## Component Testing
+
+Use `render`/`screen` from React Testing Library, `userEvent` for interactions. See `app/components/product-tile/index.test.jsx` and other `*.test.js` files in the template for patterns.
+
+### Test Utilities
+
+Use `renderWithProviders` from `app/utils/test-utils` for components that need Commerce API, routing, Chakra UI, and React Query. See template tests (e.g. `app/pages/product-detail/index.test.js`) for examples.
+
+## Mocking Commerce SDK Hooks
+
+```jsx
+import {useProduct} from '@salesforce/commerce-sdk-react';
+
+jest.mock('@salesforce/commerce-sdk-react', () => ({
+    ...jest.requireActual('@salesforce/commerce-sdk-react'),
+    useProduct: jest.fn()
+}));
+
+test('displays product when loaded', () => {
+    useProduct.mockReturnValue({
+        data: {id: 'test-123', name: 'Test Product'},
+        isLoading: false,
+        error: null
+    });
+
+    render(<ProductDetail productId="test-123" />);
+    expect(screen.getByText('Test Product')).toBeInTheDocument();
+});
+```
+
+## MSW for API Mocking
+
+```javascript
+// mocks/handlers.js
+import {rest} from 'msw';
+
+export const handlers = [
+    rest.get('*/products/:productId', (req, res, ctx) => {
+        return res(ctx.json({
+            id: req.params.productId,
+            name: 'Mock Product',
+            price: 29.99
+        }));
+    })
+];
+```
+
+## Testing User Interactions
+
+```jsx
+import userEvent from '@testing-library/user-event';
+
+test('adds item to cart when button is clicked', async () => {
+    const user = userEvent.setup();
+    render(<ProductDetail productId="test-123" />);
+
+    const addButton = screen.getByRole('button', {name: /add to cart/i});
+    await user.click(addButton);
+
+    await waitFor(() => {
+        expect(screen.getByText(/added to cart/i)).toBeInTheDocument();
+    });
+});
+```
+
+## Running Tests
+
+```bash
+# Run all tests
+npm test
+
+# Run in watch mode
+npm test -- --watch
+
+# Run with coverage
+npm test -- --coverage
+
+# Run specific test
+npm test -- product-tile.test.jsx
+```
+
+## Best Practices
+
+1. Test user behavior, not implementation
+2. Use semantic queries (getByRole, getByLabelText)
+3. Co-locate tests with source
+4. Mock external dependencies
+5. Write descriptive test names
+6. Avoid testing library internals
+7. Use MSW for API mocking
+8. Keep tests simple and focused
+9. Maintain high coverage (70%+)

package/content/site-theming/theming-accessibility.md

@@ -0,0 +1,126 @@
+---
+description: Accessibility guidelines and WCAG compliance rules for theming
+alwaysApply: false
+---
+# Accessibility Guidelines for Theming
+
+## 🎯 Accessibility Requirements
+
+**All theming implementations MUST comply with WCAG 2.1 Level AA standards at minimum.**
+
+### Color Contrast Requirements
+
+**WCAG 2.1 Contrast Ratios:**
+- **Normal text (16px and below)**: Minimum 4.5:1 contrast ratio
+- **Large text (18pt+ or 14pt+ bold)**: Minimum 3:1 contrast ratio
+- **AAA compliance (recommended)**: 7:1 for normal text, 4.5:1 for large text
+
+**Critical Color Combinations to Validate:**
+1. Primary text on primary background
+2. Secondary text on secondary background
+3. Button text on button background
+4. Link text on page background
+5. Accent colors on all background variations
+6. Muted text on muted backgrounds
+7. Border colors against adjacent backgrounds
+
+### Visual Hierarchy and Readability
+
+**Text Readability:**
+- Ensure sufficient contrast for all text sizes
+- Avoid using similar brightness levels for text and background
+- Test color combinations in both light and dark themes
+- Consider users with color vision deficiencies
+
+**Interactive Elements:**
+- Buttons must have clear visual distinction from backgrounds
+- Hover states must maintain or improve contrast
+- Focus indicators must be clearly visible (minimum 3:1 contrast)
+- Disabled states should still be readable (minimum 3:1 contrast)
+
+### Font Accessibility
+
+**Font Readability Requirements:**
+- Body text should use fonts optimized for screen reading
+- Minimum font size: 16px for body text (recommended)
+- Line height: Minimum 1.5 for body text
+- Letter spacing: Ensure adequate spacing for readability
+- Font weights: Ensure sufficient contrast between weights
+
+**Font Loading Performance:**
+- Web fonts should not block rendering
+- Provide appropriate fallback fonts
+- Consider font-display: swap for better performance
+- Test font loading on slow connections
+
+### Color Vision Deficiency Considerations
+
+**Design for Color Blindness:**
+- Don't rely solely on color to convey information
+- Use patterns, icons, or text labels in addition to color
+- Test color combinations with color blindness simulators
+- Ensure sufficient contrast even when colors are desaturated
+
+**Common Color Blindness Types:**
+- Protanopia (red-blind)
+- Deuteranopia (green-blind)
+- Tritanopia (blue-blind)
+- Monochromacy (total color blindness)
+
+### Focus and Keyboard Navigation
+
+**Focus Indicators:**
+- All interactive elements must have visible focus indicators
+- Focus indicators must have minimum 3:1 contrast ratio
+- Focus indicators should be at least 2px thick
+- Use outline or border to indicate focus state
+
+**Keyboard Accessibility:**
+- All interactive elements must be keyboard accessible
+- Tab order should be logical and intuitive
+- Skip links should be provided for long pages
+- Focus trap should be implemented in modals
+
+### Screen Reader Considerations
+
+**Semantic HTML:**
+- Use proper heading hierarchy (h1-h6)
+- Use semantic HTML elements (nav, main, article, etc.)
+- Provide alt text for images
+- Use ARIA labels when necessary
+
+**Color and Screen Readers:**
+- Screen readers don't convey color information
+- Ensure information is accessible without color
+- Use text labels, icons, or patterns in addition to color
+
+### Testing and Validation
+
+**Required Testing:**
+1. Automated contrast checking (WCAG AA/AAA)
+2. Manual visual inspection
+3. Color blindness simulator testing
+4. Screen reader testing
+5. Keyboard navigation testing
+
+**Tools for Validation:**
+- Color contrast analyzers (WebAIM, WAVE)
+- Color blindness simulators
+- Screen reader testing (NVDA, JAWS, VoiceOver)
+- Browser accessibility inspectors
+
+### Implementation Guidelines
+
+**When Implementing Themes:**
+1. Always validate color contrast ratios before implementation
+2. Test with multiple color combinations
+3. Provide alternative color suggestions if contrast fails
+4. Document accessibility decisions
+5. Test with assistive technologies
+
+**If Accessibility Issues Are Found:**
+- Present findings clearly to the user
+- Provide specific contrast ratios and WCAG compliance status
+- Suggest concrete alternatives with improved contrast
+- Explain the accessibility impact
+- Wait for user confirmation before proceeding

package/content/site-theming/theming-questions.md

@@ -0,0 +1,208 @@
+---
+description: Theming questions and information gathering guidelines
+alwaysApply: false
+---
+# Theming Questions and Information Gathering
+
+## ⚠️ CRITICAL: Layout Preservation Rules
+
+**NEVER modify positioning, layout, or structural CSS properties when applying theming changes. Only change colors, typography, and visual styling.**
+
+### What NOT to Change:
+- `position` properties (fixed, absolute, relative)
+- `top`, `left`, `right`, `bottom` positioning
+- `margin` and `padding` values
+- `width`, `height`, `min-height`, `max-height`
+- `display` properties (flex, grid, block)
+- `z-index` values (unless specifically requested)
+- `transform` properties
+- Grid/flexbox layout properties
+
+### What TO Change:
+- `color`, `background-color`, `border-color`
+- `text-decoration`, `font-weight`, `font-size`
+- `opacity`, `box-shadow`, `border-radius`
+- CSS custom properties (CSS variables)
+- Hover states and transitions
+- Theme-specific styling
+
+### Example of CORRECT theming:
+```css
+/* ✅ CORRECT - Only changing colors and visual styling */
+.navigation-item {
+  color: var(--foreground);
+  background-color: var(--background);
+  border-color: var(--border);
+  transition: color 0.2s ease;
+}
+
+.navigation-item:hover {
+  color: var(--accent);
+  background-color: var(--accent/10);
+}
+```
+
+### Example of INCORRECT theming:
+```css
+/* ❌ INCORRECT - Changing layout/positioning */
+.navigation-item {
+  margin-left: 20px; /* DON'T change margins */
+  position: relative; /* DON'T change positioning */
+  z-index: 100; /* DON'T change z-index */
+  width: 200px; /* DON'T change dimensions */
+}
+```
+
+### When Layout Changes Are Needed:
+If layout modifications are required, they should be:
+1. Explicitly requested by the user
+2. Clearly separated from theming changes
+3. Documented as layout fixes, not theming
+4. Tested thoroughly for responsive behavior
+
+## 📋 Specification Compliance Rules
+
+**ALWAYS follow user specifications exactly. Never make assumptions or interpretations.**
+
+### ⚠️ **CRITICAL: WAIT FOR USER RESPONSE RULE**
+
+**NEVER implement changes after asking clarifying questions without waiting for the user's response.**
+
+**Required Process:**
+1. Ask clarifying questions
+2. **WAIT for user response** ⚠️ **CRITICAL STEP**
+3. Only implement after receiving explicit guidance
+4. Never proceed with assumptions
+
+**Violations:**
+- ❌ Ask questions then immediately implement
+- ❌ Make assumptions about color/font mapping
+- ❌ Proceed without explicit user guidance
+- ❌ Implement "best guess" solutions
+
+### ✅ **Color Specification Rules:**
+1. **Use exact hex values** provided by the user
+2. **Ask for clarification** on color type mapping (e.g., "brand" vs "accent")
+3. **Propose color combinations** before implementing:
+   - Which color should be primary vs secondary?
+   - How should "brand" colors be used vs "accent" colors?
+   - Should "dark" colors be used for text or backgrounds?
+   - What should be the hover state colors?
+4. **Never assume** color usage without explicit user guidance
+
+### ✅ **Font Specification Rules:**
+1. **Use exact font names** as provided by the user
+2. **Ask for clarification** if font names are unclear or unfamiliar
+3. **Verify font availability** before implementing
+4. **Never substitute** similar fonts without user permission
+
+### ✅ **General Specification Rules:**
+1. **Follow exact specifications** without interpretation
+2. **Ask clarifying questions** when specifications are ambiguous
+3. **Propose implementation approaches** before making changes
+4. **Confirm understanding** of requirements before proceeding
+
+### Example of CORRECT specification handling:
+```
+User: "Use these colors: #635BFF (accent), #0A2540 (dark), #F6F9FC (brand), #FFFFFF (light)"
+
+AI Response: "I see you've provided 4 colors. Before implementing, I'd like to clarify:
+- Should #635BFF be used for primary actions and hover states?
+- Should #0A2540 be used for text color or background?
+- Should #F6F9FC be used for secondary elements or primary branding?
+- What should be the light theme vs dark theme color mapping?"
+
+[WAITS for user response before implementing]
+```
+
+### Example of INCORRECT specification handling:
+```
+❌ DON'T: Assume "sohne-var" means "Sohne" font
+❌ DON'T: Guess color usage without asking
+❌ DON'T: Make assumptions about font weights or styles
+❌ DON'T: Implement without confirming understanding
+❌ DON'T: Ask clarifying questions then immediately implement
+```
+
+## 🔄 WORKFLOW - PHASE 1: INFORMATION GATHERING
+
+**YOU MUST FOLLOW THIS WORKFLOW - NO EXCEPTIONS:**
+
+1. **DO NOT implement any changes yet**
+2. **Ask the questions below ONE AT A TIME**
+3. **WAIT for the user's response** before asking the next question
+4. **Only proceed after ALL required questions are answered**
+5. **Even if the user provided colors/fonts upfront, you MUST still ask ALL these clarifying questions**
+   - Colors provided? Still ask about color mapping, usage, hover states, etc.
+   - Fonts provided? Still ask about font usage, availability, headings vs body, etc.
+6. **You MUST ask questions from ALL categories (colors, fonts, general) - do not skip any**
+
+**VIOLATION OF THIS WORKFLOW IS A CRITICAL ERROR.**
+
+### 📝 EXTRACTION
+
+**BEFORE generating questions, you MUST extract and provide the theming information from the user's input.**
+
+1. **Review the user's input** carefully for any theming information:
+   - Colors (hex values like "#635BFF", color types like "accent", "primary", "dark", "light")
+   - Fonts (font names like "Sohne Var", font types like "title", "body", "heading")
+   - Any other theming preferences (spacing, sizes, etc.)
+
+2. **Extract and structure the information** in the following format:
+   - Colors: Array of objects with `hex` (string) and `type` (string, optional) properties
+   - Fonts: Array of objects with `name` (string) and `type` (string, optional) properties
+   - Other info: Key-value pairs as needed
+
+3. **Call this tool again** with the extracted information in `conversationContext.collectedAnswers`:
+   ```
+   {
+     conversationContext: {
+       collectedAnswers: {
+         colors: [{ hex: "#635BFF", type: "accent" }, { hex: "#0A2540", type: "dark" }, ...],
+         fonts: [{ name: "Sohne Var", type: "title" }, ...],
+         // ... other info
+       }
+     }
+   }
+   ```
+
+4. **Only after providing this information** will the tool generate the appropriate questions.
+
+**IMPORTANT:**
+- If the user did NOT mention colors or fonts, you can still call the tool with empty arrays or skip this step
+- But if the user DID mention colors/fonts, you MUST extract them before proceeding
+- **DO NOT proceed with questions until you have extracted and provided the theming information.**
+
+### 🔄 UPDATING INFORMATION (MANDATORY)
+
+**⚠️ CRITICAL: Whenever the user provides NEW or UPDATED theming information, you MUST call the tool again with the updated information.**
+
+**This applies to:** New/updated colors, fonts, color mappings, or any theming preferences.
+
+**Required Process:**
+1. Extract the new/updated information from the user's message
+2. Merge with ALL previously collected information (include everything, not just new data)
+3. Call the `site_theming` tool IMMEDIATELY with complete updated information
+4. If `colorMapping` is provided, validation will trigger automatically (see validation phase)
+
+**Tool call structure:**
+```
+{
+  conversationContext: {
+    currentStep: "updating-information" | "validation",
+    collectedAnswers: {
+      colors: [...all colors, including previous and new...],
+      fonts: [...all fonts, including previous and new...],
+      colorMapping: {...all mappings, including previous and updated...},
+      // ... all other collected information
+    },
+    questionsAsked: [...previous questions...]
+  }
+}
+```
+
+**⚠️ CRITICAL RULES:**
+- Every update requires a new tool call (not optional)
+- Include ALL previously collected information in each call
+- If user provides `colorMapping`, it triggers automatic validation
+- DO NOT implement without calling the tool with updated information first

package/content/site-theming/theming-validation.md

@@ -0,0 +1,174 @@
+---
+description: Theming validation rules and validation gate workflow
+alwaysApply: false
+---
+# Theming Validation Rules
+
+## 🔄 WORKFLOW - PHASE 2: VALIDATION GATE (MANDATORY - CANNOT SKIP)
+
+**⚠️ CRITICAL: YOU CANNOT PROCEED TO IMPLEMENTATION WITHOUT COMPLETING THIS PHASE**
+
+**STEP 7: CONSTRUCT COLOR MAPPING (MANDATORY IF COLORS PROVIDED)**
+- **After collecting all user answers, you MUST construct a `colorMapping` object**
+- **Map each color to its specific usage based on user answers:**
+  - Text colors (foreground on background)
+  - Button colors (button text on button background)
+  - Link colors (link text on page background)
+  - Accent colors (accent elements on various backgrounds)
+  - All other color combinations that will be used
+- **This mapping is REQUIRED - you cannot skip this step**
+
+**STEP 8: MANDATORY VALIDATION TOOL CALL**
+- **YOU MUST call the `site_theming` tool AGAIN with `colorMapping` in `conversationContext.collectedAnswers`**
+- **This is a SEPARATE tool call - do NOT implement after collecting answers**
+- **This triggers automatic validation that you CANNOT skip**
+- **See "HOW TO TRIGGER VALIDATION" section below for details**
+- **⚠️ CRITICAL: If you skip this tool call and proceed to implementation, you are making a CRITICAL ERROR**
+
+**STEP 9: PRESENT VALIDATION FINDINGS**
+- **After the tool returns validation results, you MUST present ALL validation results to the user**
+- **Show the complete validation output from the tool, including:**
+  - All contrast ratios for each color combination
+  - WCAG compliance status (AA/AAA/FAIL)
+  - Visual assessment (excellent/good/acceptable/poor)
+  - Any recommendations provided by the tool
+- **If ANY issues found:**
+  - Show contrast ratios and WCAG compliance status
+  - Explain accessibility problems clearly
+  - Provide concrete alternative suggestions
+  - **WAIT for user confirmation before proceeding**
+- **Even if all validations pass, you MUST still present the results to the user**
+
+**STEP 10: USER CONFIRMATION**
+- **You MUST wait for explicit user confirmation to proceed**
+- **User must acknowledge validation findings (even if they choose to proceed with issues)**
+- **Do NOT implement until user explicitly confirms they want to proceed**
+
+### PHASE 3: IMPLEMENTATION (ONLY AFTER PHASE 2 COMPLETE)
+
+**STEP 11: Implementation**
+- **ONLY after completing ALL steps above may you implement the theme**
+- **Specifically, you MUST have:**
+  1. Collected all user answers
+  2. Constructed colorMapping object
+  3. Called the tool with colorMapping (STEP 8)
+  4. Received validation results from the tool
+  5. Presented validation results to user (STEP 9)
+  6. Received user confirmation (STEP 10)
+- **If you implement before completing Phase 2, you are making a CRITICAL ERROR**
+- **If you implement without calling the tool with colorMapping, you are making a CRITICAL ERROR**
+
+**Where to apply theme changes:**
+- **For StorefrontNext/Odyssey projects:** Apply theme changes to `app.css`
+  - Standalone project: `src/app.css`
+  - Monorepo: `packages/template-retail-rsc-app/src/app.css`
+- Update CSS custom properties in the `:root` block (light theme) and `.dark` / `[data-theme='dark']` blocks (dark theme) as needed
+- **If the project uses a different theme file structure** (e.g., multiple CSS files, custom theme location): Ask the user to specify the destination file before implementing
+
+### ✅ PRE-IMPLEMENTATION CHECKLIST (BLOCKING GATE)
+
+**🛑 YOU CANNOT IMPLEMENT UNTIL ALL ITEMS BELOW ARE COMPLETE**
+
+**This checklist is a MANDATORY BLOCKING GATE - you MUST verify each item before proceeding:**
+
+- [ ] **Item 1:** All required questions answered
+- [ ] **Item 2:** Constructed `colorMapping` object mapping all colors to their usage (text, buttons, links, accents, etc.)
+- [ ] **Item 3:** Called `site_theming` tool AGAIN with `colorMapping` in `conversationContext.collectedAnswers` (this is a separate tool call, not the same call where you collected answers)
+- [ ] **Item 4:** Received validation results from the tool (the tool automatically validates when colorMapping is provided)
+- [ ] **Item 5:** Presented ALL validation findings to user (even if all pass) - show contrast ratios, WCAG status, visual assessment
+- [ ] **Item 6:** If issues found, provided specific contrast ratios, WCAG status, and alternative suggestions
+- [ ] **Item 7:** Received explicit user confirmation to proceed (user acknowledged findings)
+- [ ] **Item 8:** Font validation completed (if fonts provided)
+- [ ] **Item 9:** All validation concerns addressed or user explicitly chose to proceed despite issues
+
+**ONLY when ALL items above are checked may you proceed to implementation.**
+
+**⚠️ IF YOU IMPLEMENT WITHOUT COMPLETING THIS CHECKLIST, YOU ARE MAKING A CRITICAL ERROR.**
+
+## ✅ VALIDATION
+
+**⚠️ MANDATORY: Input Validation** - BEFORE implementing, you MUST validate ALL user-provided inputs:
+
+### A. Color Combination Validation (MANDATORY if colors provided):
+
+- Calculate contrast ratios for ALL color combinations (text on background, accent on backgrounds, etc.)
+- Check WCAG AA/AAA compliance (4.5:1 for normal text, 3:1 for large text)
+- Identify ANY accessibility issues or poor contrast combinations
+- Visual/UX impact explanation - whether the combinations look good, are readable, and maintain visual hierarchy
+- If issues are found, present them to the user with:
+  * Specific contrast ratios and WCAG compliance status
+  * Clear explanation of the accessibility problem
+  * Concrete alternative suggestions with improved contrast ratios
+
+### B. Font Validation (MANDATORY if fonts provided):
+
+- Verify font availability and accessibility (can it be loaded? Is it a real font?)
+- Check if font is available on Google Fonts, Adobe Fonts, or needs custom hosting
+- Validate font weights availability (does the font support the weights needed?)
+- Assess font readability/legibility (especially for body text)
+- Check font loading performance implications (web fonts vs system fonts)
+- Evaluate font pairing (if multiple fonts provided, do they work well together?)
+- Verify fallback fonts are appropriate
+- If issues are found, present them to the user with:
+  * Specific concerns (availability, readability, performance, etc.)
+  * Clear explanation of the problem
+  * Concrete alternative suggestions (e.g., Google Fonts equivalents, better pairings)
+  * Performance/UX impact explanation
+
+### C. General Input Validation:
+
+- Validate any other user-provided inputs (spacing, sizes, etc.) if applicable
+- Check for potential conflicts or issues
+
+### IMPORTANT:
+
+- **Validation is MANDATORY even if inputs seem fine**
+- **DO NOT skip validation or implement without validating ALL provided inputs**
+- **Call the tool with `colorMapping` to trigger automatic validation (see "HOW TO TRIGGER VALIDATION" above)**
+- **Always respect the user's final decision** - if they insist on their choices after your suggestions, use them as specified
+
+### 🚨 HOW TO TRIGGER VALIDATION:
+
+**⚠️ CRITICAL: This is a SEPARATE tool call that you MUST make AFTER collecting all user answers OR when user provides/updates colorMapping.**
+
+**Process:**
+1. Construct `colorMapping` object mapping colors to usage (text, buttons, links, accents, hover states, etc.)
+2. Call the `site_theming` tool with `colorMapping` (include ALL previously collected information):
+
+```javascript
+{
+  conversationContext: {
+    currentStep: "validation",
+    collectedAnswers: {
+      colors: [...all colors...],
+      fonts: [...all fonts...],
+      colorMapping: {
+        textColor: "#635BFF",
+        background: "#FFFFFF",
+        buttonBackground: "#0A2540",
+        buttonText: "#FFFFFF",
+        linkColor: "#0A2540",
+        accent: "#0A2540",
+        // ... all combinations
+      },
+      // ... all other collected information
+    },
+    questionsAsked: [...]
+  }
+}
+```
+
+**The tool automatically:**
+- Calculates contrast ratios for all color combinations
+- Checks WCAG AA/AAA compliance
+- Provides visual assessment
+- Returns validation results
+
+**You MUST then:**
+- Present ALL validation results to the user
+- Wait for user confirmation
+- Only then proceed to implementation
+
+**⚠️ IF YOU SKIP THIS TOOL CALL AND PROCEED TO IMPLEMENTATION, YOU ARE MAKING A CRITICAL ERROR.**
+
+**Note:** If user provides updated colorMapping at any time, call the tool with updated information (see information gathering phase for update process). Validation will trigger automatically when colorMapping is provided.

package/dist/registry.js

@@ -205,7 +205,7 @@ async function registerTools(tools, server, allowNonGaTools) {
             continue;
         }
         // Register the tool
-        // TODO: Telemetry - Tool registration includes timing/error tracking
+        // Register the tool (invocations are tracked by B2CDxMcpServer)
         server.addTool(tool.name, tool.description, tool.inputSchema, async (args) => tool.handler(args));
     }
 }

package/dist/services.d.ts

@@ -184,16 +184,6 @@ export declare class Services {
      * @returns WebDAV client instance
      */
     getWebDavClient(): WebDavClient;
-    /**
-     * Get the project project directory.
-     * Falls back to process.cwd() if not explicitly set.
-     *
-     * This is the directory where the project is located, which may differ from process.cwd()
-     * when MCP clients spawn servers from a different location (e.g., home directory).
-     *
-     * @returns Project project directory path
-     */
-    getWorkingDirectory(): string;
     /**
      * Join path segments.
      *
@@ -223,6 +213,16 @@ export declare class Services {
      * @returns Absolute path
      */
     resolvePath(...segments: string[]): string;
+    /**
+     * Resolve a path relative to the project directory.
+     * If path is not supplied, returns the project directory.
+     * If path is absolute, returns it as-is.
+     * If path is relative, resolves it relative to the project directory.
+     *
+     * @param pathArg - Optional path to resolve
+     * @returns Resolved absolute path
+     */
+    resolveWithProjectDirectory(pathArg?: string): string;
     /**
      * Get file or directory stats.
      *