Add npx cursor-rules-deploy <my-project> cross-platform support

.cursor/mcp.json

@@ -8,6 +8,13 @@
         "-y",
         "[email protected]"
       ]
+    },
+    "api fox docs": {
+      "command": "npx",
+      "args": ["-y", "apifox-mcp-server@latest", "--project=<project-id>"],
+      "env": {
+        "APIFOX_ACCESS_TOKEN": "<access-token>"
+      }
     }
   }
 }

.cursor/rules/core-rules/dependency-version-constraints-auto.mdc

@@ -0,0 +1,73 @@
+# 📦 Dependency and Version Constraints
+
+## Critical Rules
+
+- 🔒 Lock all direct dependency versions to specific versions or exact ranges to ensure reproducible builds
+- 🚫 Never use loose version constraints (e.g., ^, ~, >=, >) in production dependencies
+- ⚡ Specify Node.js version constraints in package.json using the engines field
+- 🔄 Keep all dependencies up to date with security patches while maintaining version locks
+- 🏗️ Separate devDependencies from production dependencies in Node.js projects
+- 📝 Document any specific version requirements or compatibility issues in README.md
+- 🧪 Test the application with the exact versions specified in lock files
+- 🔍 Review all transitive dependencies for security vulnerabilities
+- 📊 Maintain compatibility with the following version constraints:
+  - Node.js: >= 18.x (LTS)
+  - Python: >= 3.8
+  - .NET Core: >= 6.0
+  - Java: >= 11
+  - Ruby: >= 3.0
+- 🚨 Flag any dependencies that require specific OS or architecture support
+
+## Examples
+
+<example>
+  # package.json
+  {
+    "name": "my-app",
+    "version": "1.0.0",
+    "engines": {
+      "node": ">=18.0.0"
+    },
+    "dependencies": {
+      "express": "4.18.2",
+      "react": "18.2.0",
+      "typescript": "5.0.4"
+    },
+    "devDependencies": {
+      "jest": "29.5.0",
+      "eslint": "8.40.0"
+    }
+  }
+
+  # requirements.txt
+  fastapi==0.95.2
+  sqlalchemy==2.0.15
+  pydantic==1.10.7
+
+  # pom.xml
+  <properties>
+    <java.version>11</java.version>
+    <spring.boot.version>2.7.11</spring.boot.version>
+  </properties>
+</example>
+
+<example type="invalid">
+  # package.json
+  {
+    "dependencies": {
+      "express": "^4.18.2",
+      "react": "~18.2.0",
+      "typescript": ">=5.0.0"
+    }
+  }
+
+  # requirements.txt
+  fastapi>=0.95.2
+  sqlalchemy
+  pydantic>=1.10.0
+
+  # pom.xml
+  <properties>
+    <spring.boot.version>LATEST</spring.boot.version>
+  </properties>
+</example> 

.cursor/rules/core-rules/lib-generating-agent-manual.mdc

@@ -0,0 +1,94 @@
+---
+description: Library and Dependency Management Guidelines.
+globs: 
+alwaysApply: false
+---
+
+
+# 📦 Library and Dependency Management Guidelines
+
+## Critical Rules
+
+- 🔍 Dependency Analysis
+  - Extract and analyze all dependencies from `package.json`
+  - Check Node.js version from `.nvmrc` first, fallback to `package.json` engines field
+  - Maintain a clear understanding of each dependency's purpose and version constraints
+  - Track peer dependencies and their compatibility
+
+- 🚀 Node.js Version Management
+  - Always respect the Node.js version specified in `.nvmrc` or `package.json`
+  - Utilize latest ECMAScript features available for the specified Node.js version
+  - Document any version-specific features or syntax being used
+  - Ensure all dependencies are compatible with the specified Node.js version
+
+- 📊 Version Compatibility
+  - Implement features based on the available dependency versions
+  - Check API compatibility before using new features from dependencies
+  - Follow semantic versioning guidelines for dependency updates
+  - Document any breaking changes or version-specific implementations
+
+## Examples
+
+<example>
+  # Valid Implementation Example
+
+  # .nvmrc
+  18.19.0
+
+  # package.json
+  {
+    "name": "my-project",
+    "engines": {
+      "node": ">=18.19.0"
+    },
+    "dependencies": {
+      "express": "^4.18.0",
+      "typescript": "^5.0.0"
+    }
+  }
+
+  # Implementation using Node.js 18 features
+  const data = await fetch('https://api.example.com/data');
+  const result = await data.json();
+
+  // Using Express 4.18 features
+  app.use(express.json({ limit: '10mb' }));
+
+  // Using TypeScript 5.0 features
+  const config = {
+    port: 3000,
+    host: 'localhost'
+  } as const;
+</example>
+
+<example type="invalid">
+  # Invalid Implementation Example
+
+  # .nvmrc
+  16.14.0
+
+  # package.json
+  {
+    "name": "my-project",
+    "engines": {
+      "node": ">=16.14.0"
+    },
+    "dependencies": {
+      "express": "^4.17.0",
+      "typescript": "^4.5.0"
+    }
+  }
+
+  # Implementation using incompatible features
+  // ❌ Using fetch without polyfill (not available in Node.js 16)
+  const data = await fetch('https://api.example.com/data');
+
+  // ❌ Using TypeScript 5.0 features with TypeScript 4.5
+  const config = {
+    port: 3000,
+    host: 'localhost'
+  } satisfies Config;
+
+  // ❌ Using Express middleware options not available in 4.17
+  app.use(express.json({ limit: '10mb', strict: false }));
+</example> 

.cursor/rules/core-rules/rule-generating-agent.mdc

@@ -5,7 +5,7 @@ alwaysApply: true
 ---
 # Cursor Rules Format
 
-## Template Structure for Rules Files
+## Template Structure for Rules Files (FrontMatter must include in new generated rules)
 
 ```mdc
 ---

.cursor/rules/global-rules/emoji-communication-always.mdc

@@ -8,26 +8,67 @@ alwaysApply: true
 
 ## Critical Rules
 
-  - Use emojis purposefully to enhance meaning, but feel free to be creative and fun
-  - Place emojis at the end of statements or sections
-  - Maintain professional tone while surprising users with clever choices
-  - Limit emoji usage to 1-2 per major section
-  - Choose emojis that are both fun and contextually appropriate
-  - Place emojis at the end of statements, not at the beginning or middle
-  - Don't be afraid to tell a mini-story with your emoji choice 
+- Use emojis sparingly and purposefully to enhance readability and engagement
+- Place emojis at the beginning of sections, headings, or key points for visual hierarchy
+- Choose emojis that are universally recognizable and relevant to the technical context
+- Maintain consistency in emoji usage throughout the documentation
+- Never use emojis to replace critical technical terms or important information
+- Limit to one emoji per heading/point to avoid visual clutter
+- Use emojis primarily for:
+  - 📚 Documentation sections and categories
+  - ⚠️ Important warnings or notices
+  - 💡 Tips and best practices
+  - 🎯 Goals and objectives
+  - ✨ New features or highlights
+  - 🔧 Configuration and setup
+  - 🐛 Bug fixes and known issues
+  - 🔒 Security-related information
+  - 🚀 Performance improvements
+  - 📝 Examples and code snippets
 
 ## Examples
 
 <example>
-  "I've optimized your database queries 🏃‍♂️"
-  "Your bug has been squashed 🥾🐛"
-  "I've cleaned up the legacy code 🧹✨"
-  "Fixed the performance issue 🐌➡️🐆"
+# 📘 Project Documentation
+
+## 🎯 Project Goals
+- Build a scalable microservice architecture
+- Implement robust security measures
+- Optimize application performance
+
+## ⚠️ Prerequisites
+- Node.js 18.x or higher
+- Docker Desktop
+- MongoDB
+
+## 💡 Quick Start
+1. Clone the repository
+2. Install dependencies
+3. Run setup script
+
+## 🔧 Configuration
+Detailed steps for configuring your development environment...
+
+## 🔒 Security Guidelines
+Important security measures and best practices...
 </example>
 
 <example type="invalid">
-  "Multiple 🎉 emojis 🎊 in 🌟 one message"
-  "Using irrelevant emojis 🥑"
-  "Placing the emoji in the middle ⭐️ of a sentence"
-  "Great Job!!!" - lack of obvious use of an emoji
+# 📘 🚀 ✨ Project Documentation 
+
+## Project Goals 🎯 💪 💯
+- Build a scalable microservice architecture 🏗️
+- Implement robust security measures 🔒 
+- Optimize application performance 🚀 
+
+## Prerequisites ⚠️ ❗ ❕
+- Node.js 18.x or higher 💻
+- Docker Desktop 🐳
+- MongoDB 🗄️
+
+## Quick Start 🏃 💨 
+1. Clone the repository 📥
+2. Install dependencies ⚡
+3. Run setup script 🔄
 </example>
+