sfcc-dev-mcp 1.0.16 → 1.0.20

package/CONTRIBUTING.md

@@ -1,323 +0,0 @@
-# Contributing to SFCC Development MCP Server
-
-Thank you for your interest in contributing to the SFCC Development MCP Server! This project provides MCP tools for Salesforce B2C Commerce Cloud development assistance, including documentation access, bundled agent skills, log analysis, and system object definitions.
-
-## Table of Contents
-
-- [Getting Started](#getting-started)
-- [Development Setup](#development-setup)
-- [Project Structure](#project-structure)
-- [Contributing Guidelines](#contributing-guidelines)
-- [Types of Contributions](#types-of-contributions)
-- [Development Workflow](#development-workflow)
-- [Testing](#testing)
-- [Code Style](#code-style)
-- [Documentation](#documentation)
-- [Submitting Changes](#submitting-changes)
-- [Release Process](#release-process)
-
-## Getting Started
-
-### Prerequisites
-
-- Node.js (version 18 or higher)
-- npm or yarn
-- Git
-- SFCC instance access (for testing full mode features)
-
-### Fork and Clone
-
-1. Fork the repository on GitHub
-2. Clone your fork locally:
-   ```bash
-   git clone https://github.com/YOUR_USERNAME/sfcc-dev-mcp.git
-   cd sfcc-dev-mcp
-   ```
-
-## Development Setup
-
-1. Install dependencies:
-   ```bash
-   npm install
-   ```
-
-2. Build the project:
-   ```bash
-   npm run build
-   ```
-
-3. Run in development mode:
-   ```bash
-   npm run dev
-   ```
-
-4. Test with MCP Inspector:
-   ```bash
-   npm run inspector
-   ```
-
-### Environment Configuration
-
-For testing full mode features, create a `dw.json` file in the project root:
-
-```json
-{
-  "hostname": "your-instance.sandbox.us01.dx.commercecloud.salesforce.com",
-  "username": "your-username",
-  "password": "your-password",
-  "client-id": "your-client-id",
-  "client-secret": "your-client-secret"
-}
-```
-
-**Note**: Never commit this file. It's already in `.gitignore`.
-
-## Project Structure
-
-```
-src/                          # TypeScript MCP server
-docs/                         # SFCC docs sources (dw_* namespaces, sfra, isml)
-ai-instructions/              # AGENTS.md + bundled skills (ai-instructions/skills/*/SKILL.md)
-docs-site/                    # React + Vite documentation site
-tests/                        # Jest + MCP (Aegis) tests
-scripts/                      # Build and utility scripts
-```
-
-## Contributing Guidelines
-
-### Code of Conduct
-
-- Be respectful and inclusive
-- Focus on constructive feedback
-- Help maintain a welcoming environment for all contributors
-
-### Before Contributing
-
-1. Check existing issues and pull requests
-2. Open an issue to discuss major changes
-3. Ensure your contribution aligns with project goals
-
-## Types of Contributions
-
-### 1. Bug Fixes
-
-- Fix bugs in existing functionality
-- Improve error handling
-- Fix documentation inconsistencies
-
-### 2. Feature Enhancements
-
-- Add new MCP tools
-- Improve existing tool functionality
-- Enhance SFCC API coverage
-
-### 3. Documentation
-
-- Update bundled skills (ai-instructions/skills/*/SKILL.md)
-- Add new SFCC API documentation
-- Improve code comments and README
-
-### 4. Testing
-
-- Add unit tests
-- Improve test coverage
-- Add integration tests
-
-### 5. Performance Improvements
-
-- Optimize API calls
-- Improve caching mechanisms
-- Reduce memory usage
-
-## Development Workflow
-
-### 1. Create a Branch
-
-```bash
-git checkout -b feature/your-feature-name
-# or
-git checkout -b fix/your-bug-fix
-```
-
-### 2. Make Changes
-
-- Follow the existing code style
-- Add tests for new functionality
-- Update documentation as needed
-
-### 3. Test Your Changes
-
-```bash
-# Run tests
-npm test
-
-# Run linting
-npm run lint
-
-# Test with MCP Inspector
-npm run inspector
-```
-
-### 4. Commit Changes
-
-```bash
-git add .
-git commit -m "feat: add new SFCC tool for product management"
-```
-
-Use conventional commit messages:
-- `feat:` for new features
-- `fix:` for bug fixes
-- `docs:` for documentation changes
-- `test:` for test additions/changes
-- `refactor:` for code refactoring
-- `chore:` for maintenance tasks
-
-## Testing
-
-### Running Tests
-
-```bash
-# Run all tests
-npm test
-
-# Run tests in watch mode
-npm run test:watch
-
-# Run tests with coverage
-npm run test:coverage
-```
-
-### Writing Tests
-
-- Place test files in the `tests/` directory
-- Use the `.test.ts` suffix
-- Follow existing test patterns
-- Aim for good test coverage of new functionality
-
-### Test Categories
-
-1. **Unit Tests**: Test individual functions and classes
-2. **Integration Tests**: Test MCP tool functionality
-3. **Mock Tests**: Use mocks for external SFCC API calls
-
-## Code Style
-
-### ESLint Configuration
-
-The project uses ESLint for code style enforcement:
-
-```bash
-# Check for linting issues
-npm run lint
-
-# Auto-fix linting issues
-npm run lint:fix
-```
-
-### TypeScript
-
-- Use TypeScript for all new code
-- Provide proper type definitions
-- Avoid `any` types when possible
-- Use interfaces for object shapes
-
-### Formatting
-
-- Use 2 spaces for indentation
-- Use single quotes for strings
-- Add trailing commas in objects and arrays
-- Follow existing code patterns
-
-## Documentation
-
-### Agent Skills
-
-When adding or updating skills in `ai-instructions/skills/<skill>/SKILL.md`:
-
-1. Include frontmatter (`name`, `description`)
-2. Include practical examples
-3. Reference relevant SFCC APIs
-4. Provide security considerations
-
-### API Documentation
-
-When updating SFCC API docs:
-
-1. Use the conversion script: `npm run convert-docs`
-2. Ensure proper markdown formatting
-3. Include complete method signatures
-4. Add usage examples where helpful
-
-### Code Comments
-
-- Comment complex business logic
-- Explain non-obvious implementation decisions
-- Use JSDoc for public APIs
-- Keep comments up to date with code changes
-
-## Submitting Changes
-
-### Pull Request Process
-
-1. Push your branch to your fork
-2. Create a pull request against the main branch
-3. Fill out the pull request template
-4. Link any related issues
-
-### Pull Request Guidelines
-
-- Provide a clear description of changes
-- Include the motivation for the change
-- List any breaking changes
-- Add screenshots for UI changes (if applicable)
-- Ensure all tests pass
-- Update documentation as needed
-
-### Review Process
-
-- At least one maintainer review is required
-- Address any feedback promptly
-- Keep the pull request focused and atomic
-- Rebase if requested to maintain clean history
-
-## Release Process
-
-### Versioning
-
-The project follows [Semantic Versioning](https://semver.org/):
-
-- **MAJOR**: Breaking changes
-- **MINOR**: New features (backward compatible)
-- **PATCH**: Bug fixes (backward compatible)
-
-### Release Steps
-
-1. Update version in `package.json`
-2. Update CHANGELOG.md
-3. Create a release tag
-4. Publish to npm registry
-
-## Getting Help
-
-### Communication Channels
-
-- GitHub Issues: For bug reports and feature requests
-- GitHub Discussions: For questions and general discussion
-- Pull Request Comments: For code review discussions
-
-### Documentation Resources
-
-- [MCP Documentation](https://modelcontextprotocol.io/)
-- [SFCC API Documentation](https://documentation.b2c.commercecloud.salesforce.com/)
-- [TypeScript Documentation](https://www.typescriptlang.org/docs/)
-
-## Recognition
-
-Contributors will be recognized in:
-
-- GitHub contributor list
-- Release notes for significant contributions
-- Special mentions for outstanding contributions
-
-Thank you for contributing to the SFCC Development MCP Server! Your contributions help make SFCC development more accessible and efficient for the entire community.

package/SECURITY.md

@@ -1,148 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-We actively maintain and provide security updates for the following versions:
-
-| Version | Supported          |
-| ------- | ------------------ |
-| 1.x.x   | :white_check_mark: |
-| < 1.0   | :x:                |
-
-## Reporting a Vulnerability
-
-We take the security of the SFCC Development MCP Server seriously. If you discover a security vulnerability, please follow these steps:
-
-### 🔒 Private Disclosure
-
-**Please do NOT report security vulnerabilities through public GitHub issues.**
-
-Instead, please report security vulnerabilities by:
-
-1. **GitHub Security Advisories**: Use GitHub's private vulnerability reporting feature at [https://github.com/taurgis/sfcc-dev-mcp/security/advisories](https://github.com/taurgis/sfcc-dev-mcp/security/advisories)
-
-### 📋 What to Include
-
-When reporting a vulnerability, please include:
-
-- **Description**: Clear description of the vulnerability
-- **Impact**: Potential impact and attack scenarios
-- **Reproduction**: Step-by-step instructions to reproduce the issue
-- **Environment**: Version, operating system, and configuration details
-- **Evidence**: Screenshots, logs, or proof-of-concept code (if applicable)
-
-### ⏰ Response Timeline
-
-We are committed to addressing security vulnerabilities promptly:
-
-- **Initial Response**: Within 48 hours of report
-- **Acknowledgment**: Within 7 days with initial assessment
-- **Resolution**: Security patches released within 30 days for high-severity issues
-- **Disclosure**: Coordinated disclosure after patch is available
-
-## Security Considerations
-
-### 🎯 Scope
-
-This security policy covers vulnerabilities in:
-
-- **Core MCP Server**: Authentication, data handling, API access
-- **SFCC Integration**: OAuth flows, credential management, data exposure
-- **Documentation Access**: Information disclosure, access control
-- **Log Analysis**: Sensitive data exposure, injection vulnerabilities
-- **Dependencies**: Third-party package vulnerabilities
-
-### ⚠️ What We Consider Security Issues
-
-- **Authentication bypass** in SFCC credential handling
-- **Sensitive data exposure** in logs or responses
-- **Code injection** through tool parameters
-- **Unauthorized access** to SFCC instances
-- **Credential leakage** in configuration or cache
-- **Path traversal** in file operations
-- **Denial of service** through resource exhaustion
-- **Dependency vulnerabilities** with exploitable impact
-
-### ✅ What We Don't Consider Security Issues
-
-- **Rate limiting** on local development tools
-- **Information disclosure** of public SFCC documentation
-- **Resource usage** in normal operation scenarios
-- **Configuration errors** by end users
-- **Network connectivity** issues
-- **Feature requests** or usability improvements
-
-## Security Best Practices
-
-### 🔐 For Users
-
-1. **Credential Protection**:
-   - Store SFCC credentials securely in `dw.json`
-   - Use environment variables for sensitive configuration
-   - Regularly rotate API credentials
-   - Never commit credentials to version control
-
-2. **Network Security**:
-   - Use HTTPS connections to SFCC instances
-   - Verify SSL certificates in production
-   - Restrict network access to development instances
-
-3. **Local Security**:
-   - Keep the MCP server updated
-   - Review log outputs for sensitive data
-   - Use proper file permissions on configuration files
-
-### 🛡️ For Developers
-
-1. **Input Validation**:
-   - Validate all tool parameters
-   - Sanitize user inputs before processing
-   - Use type-safe parameter parsing
-
-2. **Data Handling**:
-   - Minimize sensitive data in logs
-   - Implement proper error handling
-   - Use secure HTTP clients with proper timeouts
-
-3. **Dependency Management**:
-   - Regularly update dependencies
-   - Monitor for security advisories
-   - Use `npm audit` to check for vulnerabilities
-
-## Security Features
-
-### 🔒 Built-in Security
-
-- **OAuth 2.0 Authentication** for SFCC OCAPI access
-- **Secure credential storage** with local file protection
-- **Input validation** on all tool parameters
-- **Rate limiting** on external API calls
-- **Secure HTTP clients** with proper error handling
-- **Minimal privilege principle** for SFCC permissions
-
-### 📊 Security Monitoring
-
-- **Dependency scanning** via GitHub Dependabot
-- **Code quality checks** in CI/CD pipeline
-- **Security-focused linting** rules
-- **Regular security audits** of dependencies
-
-## Responsible Disclosure
-
-We believe in responsible disclosure and will work with security researchers to:
-
-1. **Acknowledge** your contribution
-2. **Keep you informed** of our progress
-3. **Credit you appropriately** (unless you prefer to remain anonymous)
-4. **Coordinate timing** of public disclosure
-
-## Contact
-
-For security-related questions or concerns:
-
-- **GitHub**: [@taurgis](https://github.com/taurgis)
-- **Project**: [sfcc-dev-mcp](https://github.com/taurgis/sfcc-dev-mcp)
-
----
-
-Thank you for helping keep the SFCC Development MCP Server and its users safe! 🛡️

package/aegis.config.docs-only.json

@@ -1,9 +0,0 @@
-{
-  "name": "sfcc-dev-mcp",
-  "command": "node",
-  "args": [
-    "dist/index.js"
-  ],
-  "cwd": "./",
-  "startupTimeout": 10000
-}

package/aegis.config.json

@@ -1,12 +0,0 @@
-{
-  "name": "sfcc-dev-mcp-docs-only",
-  "command": "node",
-  "args": [
-    "dist/index.js"
-  ],
-  "cwd": "./",
-  "startupTimeout": 10000,
-  "env": {
-    "NODE_ENV": "test"
-  }
-}

package/aegis.config.with-dw.json

@@ -1,15 +0,0 @@
-{
-  "name": "sfcc-dev-mcp-with-credentials",
-  "command": "node",
-  "args": [
-    "dist/index.js",
-    "--dw-json",
-    "./tests/mcp/test-fixtures/dw.json",
-    "--debug"
-  ],
-  "cwd": "./",
-  "startupTimeout": 10000,
-  "env": {
-    "NODE_ENV": "test"
-  }
-}