fix: update documentation links to use the new general path structure

Author: Lasim

check-links.js

@@ -10,7 +10,12 @@ const __dirname = path.dirname(fileURLToPath(import.meta.url));
 const IGNORED_URLS = [
     'https://deploystack.io',
     'https://deploystack.io/*',
-    'https://cloud.deploystack.io'
+    'https://cloud.deploystack.io',
+    'https://docs.deploystack.io',
+    'https://mintlify.com',
+    'https://mintlify.com/*',
+    'https://discord.gg/',
+    'https://discord.gg/*'
 ];
 
 // Check if a URL should be ignored
@@ -55,19 +60,19 @@ const checkLocalFile = (linkPath, filePath) => {
     if (linkPath.startsWith('/') && !linkPath.startsWith('//') && !linkPath.startsWith('http')) {
         // Remove hash fragment before checking file existence
         const [baseUrl] = linkPath.split('#');
-        
+
         // Map the URL to the actual file location
-        // Since our URLs are now root-level but files are in docs/
-        const actualFilePath = path.join(process.cwd(), 'docs', baseUrl.substring(1));
-        
+        // Files are in the root directory structure
+        const actualFilePath = path.join(process.cwd(), baseUrl.substring(1));
+
         // Try both .mdx and .md extensions
         const possiblePaths = [
             actualFilePath + '.mdx',
             actualFilePath + '.md',
             path.join(actualFilePath, 'index.mdx'),
             path.join(actualFilePath, 'index.md')
         ];
-        
+
         for (const possiblePath of possiblePaths) {
             try {
                 fs.accessSync(possiblePath, fs.constants.F_OK);
@@ -77,7 +82,7 @@ const checkLocalFile = (linkPath, filePath) => {
                 // Continue to next possible path
             }
         }
-        
+
         console.log(`  ❌ ${linkPath} → File not found (checked: ${possiblePaths.map(p => path.relative(process.cwd(), p)).join(', ')})`);
         return false;
     }
@@ -189,9 +194,41 @@ const processDirectory = async (dir) => {
     return allValid;
 };
 
-// Start processing
+// Directories to skip during scanning
+const SKIP_DIRS = ['node_modules', '.git', '.next', 'out', '.github', '.source'];
+
+// Modified processDirectory to skip certain directories
+const shouldSkipDirectory = (dirName) => {
+    return SKIP_DIRS.includes(dirName);
+};
+
+// Start processing from current directory
 console.log('📝 Checking markdown links...\n');
-processDirectory('docs').then(allValid => {
+
+const scanDirectory = async (dir) => {
+    let allValid = true;
+    const files = fs.readdirSync(dir);
+
+    for (const file of files) {
+        const filePath = path.join(dir, file);
+        const stat = fs.statSync(filePath);
+
+        if (stat.isDirectory()) {
+            // Skip certain directories
+            if (!shouldSkipDirectory(file)) {
+                const isValid = await processDirectory(filePath);
+                if (!isValid) allValid = false;
+            }
+        } else if (file.endsWith('.md') || file.endsWith('.mdx')) {
+            const isValid = await processFile(filePath);
+            if (!isValid) allValid = false;
+        }
+    }
+
+    return allValid;
+};
+
+scanDirectory(process.cwd()).then(allValid => {
     if (!allValid) {
         console.log('❌ Some links are invalid!');
         process.exit(1);

development/backend/auth.mdx

@@ -4,7 +4,7 @@ description: Technical documentation for the DeployStack backend authentication
 ---
 
 
-This document provides technical details about the DeployStack backend authentication system implementation. For user-facing authentication configuration, see [Authentication Methods](/auth). For OAuth provider implementation details, see [OAuth Provider Implementation](/development/backend/oauth-providers) and [OAuth2 Server Implementation](/development/backend/oauth2-server).
+This document provides technical details about the DeployStack backend authentication system implementation. For user-facing authentication configuration, see [Authentication Methods](/general/auth). For OAuth provider implementation details, see [OAuth Provider Implementation](/development/backend/oauth-providers) and [OAuth2 Server Implementation](/development/backend/oauth2-server).
 
 ## Architecture Overview
 

development/backend/mcp-configuration-architecture.mdx

@@ -416,9 +416,9 @@ For specific implementation details:
 - [Backend API](/development/backend/api/) - Complete API endpoint documentation
 - [Database Schema](/development/backend/database/) - Database structure and relationships
 - [Job Queue System](/development/backend/job-queue) - Background job processing for registry sync
-- [Teams](/teams) - Team management and structure
-- [MCP Configuration System](/mcp-configuration) - User-facing configuration guide
-- [MCP Installation](/mcp-installation) - Installation and team setup
-- [MCP Catalog](/mcp-catalog) - Official registry integration details
+- [Teams](/general/teams) - Team management and structure
+- [MCP Configuration System](/general/mcp-configuration) - User-facing configuration guide
+- [MCP Installation](/general/mcp-installation) - Installation and team setup
+- [MCP Catalog](/general/mcp-catalog) - Official registry integration details
 
 The three-tier configuration architecture provides a robust foundation for managing complex MCP server configurations in multi-user team environments while maintaining security, flexibility, and ease of use. The system seamlessly handles both manually created custom servers and automatically synced official registry servers.

development/backend/oauth-providers.mdx

@@ -282,4 +282,4 @@ Frontend checks provider status to show login buttons:
 - [OAuth2 Server Implementation](/development/backend/oauth2-server) - OAuth2 server for API access
 - [Security Policy](/development/backend/security) - Security implementation details
 - [Global Settings](/development/backend/global-settings) - Configuration management
-- [GitHub OAuth Setup](/github-oauth-setup) - User-facing GitHub OAuth setup guide
+- [GitHub OAuth Setup](/general/github-oauth-setup) - User-facing GitHub OAuth setup guide

development/frontend/architecture.mdx

@@ -580,7 +580,7 @@ export function createColumns(): ColumnDef[] {
 
 ### Table Components
 
-For table implementations, use the shadcn-vue Table components as documented in the [Table Design System](/development/frontend/ui/-table). Never use raw HTML table elements.
+For table implementations, use the shadcn-vue Table components as documented in the [Table Design System](/development/frontend/ui/design-system-table). Never use raw HTML table elements.
 
 ## Component Communication Patterns
 

development/frontend/index.mdx

@@ -67,15 +67,15 @@ The frontend follows a feature-based modular architecture with clear separation
 
 For comprehensive component development guidelines, including Vue SFC best practices, component structure patterns, and implementation standards, see the [Frontend Architecture - Component Implementation Standards](/development/frontend/architecture#component-implementation-standards) section.
 
-For table-specific implementations, refer to the [Table Design System](/development/frontend/ui/-table) guide.
+For table-specific implementations, refer to the [Table Design System](/development/frontend/ui/design-system-table) guide.
 
 ## UI Components and Styling
 
 The frontend uses **TailwindCSS** for styling with **shadcn-vue** component library for consistent UI elements. For comprehensive styling guidelines, component patterns, and design standards, see the [UI Design System](/development/frontend/ui/) documentation.
 
 ### ⚠️ **Mandatory Design Patterns**
 
-All structured information displays must follow the **[Structured Data Display Pattern](/development/frontend/ui/-structured-data)**. This includes:
+All structured information displays must follow the **[Structured Data Display Pattern](/development/frontend/ui/design-system-structured-data)**. This includes:
 - User profiles and settings
 - Form layouts 
 - Configuration displays
@@ -125,7 +125,7 @@ Continue reading the detailed guides:
 
 - [Frontend Architecture](/development/frontend/architecture) - Application architecture, patterns, and development principles
 - [UI Design System](/development/frontend/ui/) - Component patterns, styling guidelines, and design standards
-- **[Structured Data Display Pattern](/development/frontend/ui/-structured-data)** - **Mandatory pattern** for consistent information display
+- **[Structured Data Display Pattern](/development/frontend/ui/design-system-structured-data)** - **Mandatory pattern** for consistent information display
 - [Environment Variables](/development/frontend/environment-variables) - Complete environment configuration guide
 - [Global Event Bus](/development/frontend/event-bus) - Cross-component communication system
 - [Internationalization (i18n)](/development/frontend/internationalization) - Multi-language support

development/frontend/ui/index.mdx

@@ -167,9 +167,9 @@ This hierarchy is a **design system requirement** and must be followed consisten
 
 ## Data Tables
 
-For data table implementation, see the dedicated [Table Design System](/development/frontend/ui/-table) guide.
+For data table implementation, see the dedicated [Table Design System](/development/frontend/ui/design-system-table) guide.
 
-For pagination implementation, see the [Pagination Implementation Guide](/development/frontend/ui/-pagination).
+For pagination implementation, see the [Pagination Implementation Guide](/development/frontend/ui/design-system-pagination).
 
 ## Badge Design Patterns
 

development/satellite/backend-communication.mdx

@@ -293,7 +293,7 @@ See `services/backend/src/db/schema.ts` for complete schema definitions.
 4. Backend consumes single-use token and issues permanent API key
 5. Satellite stores API key securely for ongoing communication
 
-For detailed token validation process, see [Registration Security](/development/backend/satellite-communication#satellite-pairing-process).
+For detailed token validation process, see [Registration Security](/development/backend/satellite/communication#satellite-pairing-process).
 
 **Ongoing Operations:**
 1. All requests include `Authorization: Bearer {api_key}`

development/satellite/mcp-server-token-injection.mdx

@@ -227,7 +227,7 @@ private isCacheValid(cachedAt: number, expiresAt: string | null): boolean {
 
 ### Tool Execution Injection
 
-**File**: [services/satellite/src/core/mcp-server-wrapper.ts](https://github.com/deploystackio/deploystack/blob/main/services/satellite/src/core/mcp-server-wrapper.ts:711-760)
+**File**: [services/satellite/src/core/mcp-server-wrapper.ts](https://github.com/deploystackio/deploystack/blob/main/services/satellite/src/core/mcp-server-wrapper.ts)
 
 **Purpose**: Injects OAuth tokens when executing tools on HTTP/SSE MCP servers.
 
@@ -438,7 +438,7 @@ async handleHttpToolCall(serverName: string, originalToolName: string, args: unk
 
 ### Tool Discovery Injection
 
-**File**: [services/satellite/src/services/remote-tool-discovery-manager.ts](https://github.com/deploystackio/deploystack/blob/main/services/satellite/src/services/remote-tool-discovery-manager.ts:376-440)
+**File**: [services/satellite/src/services/remote-tool-discovery-manager.ts](https://github.com/deploystackio/deploystack/blob/main/services/satellite/src/services/remote-tool-discovery-manager.ts)
 
 **Purpose**: Injects OAuth tokens when discovering available tools from HTTP/SSE MCP servers.
 

development/satellite/registration.mdx

@@ -187,7 +187,7 @@ Satellites require registration tokens generated by administrators:
 - Scope: Can register team satellites for specific team only
 - Expiration: 24 hours (configurable)
 
-For token generation APIs, see [Satellite Communication - Registration Tokens](/development/backend/satellite-communication#satellite-pairing-process).
+For token generation APIs, see [Satellite Communication - Registration Tokens](/development/backend/satellite/communication#satellite-pairing-process).
 
 ### Security Model