docs(core): restructure guides into technologies sections

.cursor/mcp.json

@@ -0,0 +1,22 @@
+{
+  "mcpServers": {
+    "nx-mcp": {
+      "url": "http://localhost:9593/sse"
+    },
+    "task-master-ai": {
+      "command": "npx",
+      "args": ["-y", "--package=task-master-ai", "task-master-ai"],
+      "env": {
+        "ANTHROPIC_API_KEY": "ANTHROPIC_API_KEY_HERE",
+        "PERPLEXITY_API_KEY": "PERPLEXITY_API_KEY_HERE",
+        "OPENAI_API_KEY": "OPENAI_API_KEY_HERE",
+        "GOOGLE_API_KEY": "GOOGLE_API_KEY_HERE",
+        "XAI_API_KEY": "XAI_API_KEY_HERE",
+        "OPENROUTER_API_KEY": "OPENROUTER_API_KEY_HERE",
+        "MISTRAL_API_KEY": "MISTRAL_API_KEY_HERE",
+        "AZURE_OPENAI_API_KEY": "AZURE_OPENAI_API_KEY_HERE",
+        "OLLAMA_API_KEY": "OLLAMA_API_KEY_HERE"
+      }
+    }
+  }
+}

.cursor/rules/cursor_rules.mdc

@@ -0,0 +1,53 @@
+---
+description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
+globs: .cursor/rules/*.mdc
+alwaysApply: true
+---
+
+- **Required Rule Structure:**
+  ```markdown
+  ---
+  description: Clear, one-line description of what the rule enforces
+  globs: path/to/files/*.ext, other/path/**/*
+  alwaysApply: boolean
+  ---
+
+  - **Main Points in Bold**
+    - Sub-points with details
+    - Examples and explanations
+  ```
+
+- **File References:**
+  - Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files
+  - Example: [prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
+  - Example: [schema.prisma](mdc:prisma/schema.prisma) for code references
+
+- **Code Examples:**
+  - Use language-specific code blocks
+  ```typescript
+  // ✅ DO: Show good examples
+  const goodExample = true;
+
+  // ❌ DON'T: Show anti-patterns
+  const badExample = false;
+  ```
+
+- **Rule Content Guidelines:**
+  - Start with high-level overview
+  - Include specific, actionable requirements
+  - Show examples of correct implementation
+  - Reference existing code when possible
+  - Keep rules DRY by referencing other rules
+
+- **Rule Maintenance:**
+  - Update rules when new patterns emerge
+  - Add examples from actual codebase
+  - Remove outdated patterns
+  - Cross-reference related rules
+
+- **Best Practices:**
+  - Use bullet points for clarity
+  - Keep descriptions concise
+  - Include both DO and DON'T examples
+  - Reference actual code over theoretical examples
+  - Use consistent formatting across rules 

.cursor/rules/nx-docs-structure.mdc

@@ -0,0 +1,101 @@
+---
+description: 
+globs: docs/**,nx-dev/**,docs/map.json
+alwaysApply: false
+---
+- **Nx Documentation Structure**
+  - The main navigation for Nx docs is defined in [map.json](mdc:docs/map.json).
+  - The top-level sections under the `nx-documentation` id are:
+    - Getting Started
+    - Features
+    - Concepts
+    - Recipes
+    - Enterprise
+    - Showcase
+    - Reference
+    - Troubleshooting
+    - Deprecated
+    - See Also
+  - Each section can contain nested `itemList` arrays for sub-navigation.
+
+- **Technology Documentation Structure Pattern**
+  - The Technologies section follows a consistent nested structure:
+    - Technology (e.g., React, Angular) → Framework (Core/Next/etc.) → Section (Introduction/Recipes/API)
+  - Each technology maintains this three-level pattern consistently
+  - Technologies section organization:
+    ```
+    Technologies/
+    ├── Technology Name (React, Angular, etc.)
+    │   ├── Framework Variant (Core, Next, Remix, etc.)
+    │   │   ├── Introduction
+    │   │   ├── Recipes
+    │   │   └── API
+    │   └── ...
+    └── ...
+    ```
+  - All technology subsections maintain Introduction → Recipes → API structure
+  - Empty sections (like `"itemList": []`) are placeholders for future content
+
+- **Recipe Organization Hierarchy**
+  - Recipes can exist in two places:
+    - Main Recipes section (top-level categorization by technology)
+    - Within each technology's dedicated section (more contextual placement)
+  - The main Recipes section is organized by technology and general categories
+  - Technology-specific recipes in the Technologies section provide more context-specific organization
+
+- **API References and Packages**
+  - The `additional-api-references` section lists main Nx-related packages, each as a top-level entry:
+    - nx, workspace, plugin, devkit, js, web, esbuild, vite, vue, nuxt, webpack, angular, angular-rspack, angular-rsbuild, react, jest, cypress, playwright, storybook, eslint, eslint-plugin, node, express, nest, next, remix, rspack, detox, react native, expo, owners, conformance, azure-cache, gcs-cache, s3-cache, shared-fs-cache, gradle, Module Federation
+  - Each package can have its own nested documentation structure.
+
+- **File Path Patterns**
+  - Content files follow consistent path patterns:
+    - `shared/guides/*` - General guides and how-tos
+    - `shared/packages/*` - Package-specific documentation
+    - `shared/recipes/*` - Specific task-oriented recipes
+  - The same content file can be referenced from multiple places in the navigation
+  - This allows for strategic content placement without duplication
+
+- **Restructuring Guidance**
+  - When restructuring ensure all navigation changes in [map.json](mdc:docs/map.json) are reflected in the Next.js app and related files as per [workspace-architecture](mdc:.cursor/rules/workspace-architecture.mdc).
+
+- **Best Practices**
+  - Keep the documentation structure DRY and consistent.
+  - Reference actual files and navigation structure in rules and documentation.
+  - Update this rule when new top-level sections or packages are added or restructured.
+
+- **File Movement Policy**
+  - When updating the navigation structure (e.g., moving a doc to a new section), only update the references in [map.json](mdc:docs/map.json).
+  - Do not move or rename the actual markdown files on the filesystem as part of navigation restructuring.
+  - Physical file moves should be performed as a separate, explicit task to minimize risk and keep changes isolated.
+
+- **Documentation Generation Workflow**
+  - All documentation content is generated by [`scripts/documentation/generators/main.ts`](mdc:scripts/documentation/generators/main.ts).
+  - This script is triggered by the `documentation` target in [`project.json`](mdc:project.json).
+  - The script orchestrates the generation of:
+    - CLI documentation
+    - CNW documentation
+    - Devkit documentation
+    - Local and external package schemas
+    - Documentation manifests
+  - The output is written to `docs/generated` and related folders.
+  - The script is run automatically:
+    - Before pushes (as part of the `prepush` target)
+    - As part of CI/CD and documentation workflows
+  - After generation, the script checks for uncommitted changes in `docs/` and prompts the user to commit them if needed.
+  - For more details, see the implementation in [`main.ts`](mdc:scripts/documentation/generators/main.ts) and the configuration in [`project.json`](mdc:project.json).
+
+- **Updating the Menu Structure**
+  - When you update the navigation or menu structure (for example, by editing [`docs/map.json`](mdc:docs/map.json)), you must run the documentation generation script to regenerate `menu.json` and related manifest files.
+  - **Step-by-step process:**
+    1. Edit [`docs/map.json`](mdc:docs/map.json) to update the navigation/menu structure.
+    2. Run the documentation generation script via the Nx target:
+       ```sh
+       nx run @nx/nx-source:documentation
+       ```
+       or directly:
+       ```sh
+       ts-node -P scripts/tsconfig.scripts.json ./scripts/documentation/generators/main.ts
+       ```
+    3. Commit both your changes to `map.json` and the newly generated files in `docs/generated`.
+  - This ensures the menu and navigation artifacts (such as `menu.json`) are always in sync with your changes and the documentation site navigation is up to date.

.cursor/rules/self_improve.mdc

@@ -0,0 +1,72 @@
+---
+description: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
+globs: **/*
+alwaysApply: true
+---
+
+- **Rule Improvement Triggers:**
+  - New code patterns not covered by existing rules
+  - Repeated similar implementations across files
+  - Common error patterns that could be prevented
+  - New libraries or tools being used consistently
+  - Emerging best practices in the codebase
+
+- **Analysis Process:**
+  - Compare new code with existing rules
+  - Identify patterns that should be standardized
+  - Look for references to external documentation
+  - Check for consistent error handling patterns
+  - Monitor test patterns and coverage
+
+- **Rule Updates:**
+  - **Add New Rules When:**
+    - A new technology/pattern is used in 3+ files
+    - Common bugs could be prevented by a rule
+    - Code reviews repeatedly mention the same feedback
+    - New security or performance patterns emerge
+
+  - **Modify Existing Rules When:**
+    - Better examples exist in the codebase
+    - Additional edge cases are discovered
+    - Related rules have been updated
+    - Implementation details have changed
+
+- **Example Pattern Recognition:**
+  ```typescript
+  // If you see repeated patterns like:
+  const data = await prisma.user.findMany({
+    select: { id: true, email: true },
+    where: { status: 'ACTIVE' }
+  });
+
+  // Consider adding to [prisma.mdc](mdc:.cursor/rules/prisma.mdc):
+  // - Standard select fields
+  // - Common where conditions
+  // - Performance optimization patterns
+  ```
+
+- **Rule Quality Checks:**
+  - Rules should be actionable and specific
+  - Examples should come from actual code
+  - References should be up to date
+  - Patterns should be consistently enforced
+
+- **Continuous Improvement:**
+  - Monitor code review comments
+  - Track common development questions
+  - Update rules after major refactors
+  - Add links to relevant documentation
+  - Cross-reference related rules
+
+- **Rule Deprecation:**
+  - Mark outdated patterns as deprecated
+  - Remove rules that no longer apply
+  - Update references to deprecated rules
+  - Document migration paths for old patterns
+
+- **Documentation Updates:**
+  - Keep examples synchronized with code
+  - Update references to external docs
+  - Maintain links between related rules
+  - Document breaking changes
+Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure.

.cursor/rules/task-list.mdc

@@ -0,0 +1,105 @@
+---
+description: whenever you are asked to process tasks, use these instructions
+globs: 
+alwaysApply: false
+---
+# Task List Management
+
+Guidelines for creating and managing task lists in markdown files to track project progress
+
+## Task List Creation
+
+1. Create task lists in a markdown file (in the project root):
+   - Use `TASKS.md` or a descriptive name relevant to the feature (e.g., `ASSISTANT_CHAT.md`)
+   - Include a clear title and description of the feature being implemented
+
+2. Structure the file with these sections:
+   ```markdown
+   # Feature Name Implementation
+
+   Brief description of the feature and its purpose.
+
+   ## Completed Tasks
+
+   - [x] Task 1 that has been completed
+   - [x] Task 2 that has been completed
+
+   ## In Progress Tasks
+
+   - [ ] Task 3 currently being worked on
+   - [ ] Task 4 to be completed soon
+
+   ## Future Tasks
+
+   - [ ] Task 5 planned for future implementation
+   - [ ] Task 6 planned for future implementation
+
+   ## Implementation Plan
+
+   Detailed description of how the feature will be implemented.
+
+   ### Relevant Files
+
+   - path/to/file1.ts - Description of purpose
+   - path/to/file2.ts - Description of purpose
+   ```
+
+## Task List Maintenance
+
+1. Update the task list as you progress:
+   - Mark tasks as completed by changing `[ ]` to `[x]`
+   - Add new tasks as they are identified
+   - Move tasks between sections as appropriate
+
+2. Keep "Relevant Files" section updated with:
+   - File paths that have been created or modified
+   - Brief descriptions of each file's purpose
+   - Status indicators (e.g., ✅) for completed components
+
+3. Add implementation details:
+   - Architecture decisions
+   - Data flow descriptions
+   - Technical components needed
+   - Environment configuration
+
+## AI Instructions
+
+When working with task lists, the AI should:
+
+1. Regularly update the task list file after implementing significant components
+2. Mark completed tasks with [x] when finished
+3. Add new tasks discovered during implementation
+4. Maintain the "Relevant Files" section with accurate file paths and descriptions
+5. Document implementation details, especially for complex features
+6. When implementing tasks one by one, first check which task to implement next
+7. After implementing a task, update the file to reflect progress
+
+## Example Task Update
+
+When updating a task from "In Progress" to "Completed":
+
+```markdown
+## In Progress Tasks
+
+- [ ] Implement database schema
+- [ ] Create API endpoints for data access
+
+## Completed Tasks
+
+- [x] Set up project structure
+- [x] Configure environment variables
+```
+
+Should become:
+
+```markdown
+## In Progress Tasks
+
+- [ ] Create API endpoints for data access
+
+## Completed Tasks
+
+- [x] Set up project structure
+- [x] Configure environment variables
+- [x] Implement database schema
+```