Project configuration

.cursor/mcp.json

@@ -0,0 +1,7 @@
+{
+  "mcpServers": {
+    "nx-mcp": {
+      "url": "http://localhost:9911/sse"
+    }
+  }
+}

.cursor/rules/angular-nebular-ui.mdc

@@ -0,0 +1,49 @@
+---
+description: This prompt will guide Cursor to provide comprehensive solutions that focus specifically on UX concerns while implementing Nebular components, addressing known issues, and ensuring proper styling with SCSS
+globs: 
+alwaysApply: false
+---
+# Role and Goal
+You are an expert Angular developer with deep knowledge of Nebular UI library, Eva Design System, and UX best practices. Your primary goal is to help me implement a modern, sleek UI for my Angular application using Nebular with SCSS, focusing entirely on user experience. You should identify optimal component architecture, suggest SCSS customizations, and solve common UX issues with Nebular.
+
+# Project Context
+I'm building an Angular application using SCSS for styling, and I want to implement Nebular as my UI framework. The UI should be tree-shakeable, minimize CSS bloat, and follow modern UX design principles.
+
+# Specific Instructions
+When helping me implement Nebular UI components, you should:
+
+1. Always focus on progressive disclosure patterns to reduce cognitive load[2]
+2. Prioritize tree-shaking efficiency by importing only needed modules
+3. Fix known UX issues like contextual menu cursors (change to pointer cursor)[1][4]
+4. Implement proper hover states and transitions for all interactive elements
+5. Suggest optimal SCSS architecture including Eva Design System tokens
+6. Avoid accessibility issues by ensuring WCAG 2.1 AA compliance
+7. Use proper Angular CDK implementations for overlay components[6]
+
+# Code Architecture Standards
+- Implement component-based architecture using standalone components
+- Create SCSS mixins and variables for systematic design tokens
+- Ensure all interactive elements have proper focus, hover, and active states
+- Properly leverage Nebular's theme system with SCSS integration
+- Implement responsive layouts using Nebular's built-in grid system
+
+# Output Format
+For each task, provide:
+1. Step-by-step implementation guidance with explanations
+2. Complete code examples (not snippets) for both component and styling
+3. Common UX pitfalls to avoid and their solutions
+4. Performance implications and optimization suggestions
+
+# Educational Component
+When providing code, explain:
+- Why certain approaches are recommended for UX
+- How the implementation affects performance
+- How to properly implement accessibility features
+- How to customize Nebular components while maintaining design consistency
+
+# Special UX Considerations
+- Address Nebular contextual menu cursor issues to ensure clickable elements use pointer cursor[1][4]
+- Implement proper keyboard navigation throughout the application
+- Ensure proper form field feedback and validation states
+- Design consistent animation patterns for state transitions
+- Implement proper loading states and skeleton screens

.cursorrules

@@ -0,0 +1,333 @@
+// ANGULAR EDUCATIONAL MONOREPO CURSOR RULES
+// Last updated: 2024-03-10
+// Applies to: All files in monorepo
+
+### CORE PRINCIPLES ###
+1. Prioritize educational clarity over code brevity
+2. Maintain strict Nx module boundaries via tags
+3. Enforce example isolation patterns
+4. Link code to markdown documentation
+5. Use standalone components for demos
+6. Follow Angular API evolution roadmap
+7. Use SCSS for all styling needs
+8. Follow BEM methodology strictly
+9. Use Nebular UI components exclusively
+
+### COMPONENT FILE STRUCTURE ###
+# File Organization
+- Every component MUST have separate files for:
+  * Component class (.ts)
+  * Template (.html)
+  * Styles (.scss)
+- NO inline templates allowed
+- NO inline styles allowed
+- Follow Angular style guide naming conventions
+
+# File Naming
+- Use kebab-case for filenames
+- Use the following suffixes:
+  * .component.ts
+  * .component.html
+  * .component.scss
+  * .component.spec.ts
+
+### STYLING RULES ###
+# SCSS Usage
+- Use SCSS for all stylesheets
+- Follow BEM methodology strictly:
+  * Block: Component name
+  * Element: Block__element
+  * Modifier: Block__element--modifier
+- Maximum nesting depth: 3 levels
+- Use Nebular theme variables
+- Keep styles scoped to component
+
+### COMPONENT RULES ###
+# Metadata
+- Use standalone: true
+- Use changeDetection: ChangeDetectionStrategy.OnPush
+- Use templateUrl and styleUrls
+- Follow selector prefix rules:
+  * Libraries: prefix with 'lib-{library-name}-' (e.g., 'lib-ui-button' for shared/ui)
+  * Applications: prefix with 'app-' (e.g., 'app-home')
+  * Examples: prefix with 'lib-' (e.g., 'lib-content-projection')
+- Include @Example metadata header
+
+# Selector Prefix Rules
+- Shared UI Library: 'lib-ui-'
+- Core Library: 'lib-core-'
+- Feature Libraries: 'lib-{feature}-'
+- Demo Components: 'lib-{topic}-demo'
+- Application Components: 'app-'
+- Never use bare 'lib-' prefix without library identifier
+- Keep prefix consistent within library boundaries
+
+# Examples:
+- shared/ui: 'lib-ui-button', 'lib-ui-card'
+- shared/core: 'lib-core-logger', 'lib-core-config'
+- topics: 'lib-content-projection', 'lib-content-projection-demo'
+- showcase app: 'app-home', 'app-sidebar'
+
+# Template Rules
+- Use semantic HTML elements
+- Follow accessibility guidelines
+- Use Nebular components
+- Keep templates focused and simple
+
+### TESTING STANDARDS ###
+# File Structure
+- Every component must have a .spec.ts file
+- Keep test files adjacent to component files
+- Follow AAA pattern in tests
+- Use Angular Testing Library
+
+### DOCUMENTATION ###
+# Component Documentation
+- Include JSDoc comments for:
+  * Component description
+  * Input/Output properties
+  * Public methods
+- Link examples in markdown
+- Document Nebular usage
+
+### MAINTENANCE ###
+# Version Control
+- Keep files small and focused
+- Document breaking changes
+- Follow semantic versioning
+- Update documentation with code
+
+### AUTOMATION ###
+# Generators
+- Use nx generators for new components
+- Follow established patterns
+- Generate all required files
+- Include test files by default
+
+### DEPENDENCY MANAGEMENT ###
+# Nebular Integration
+- NO direct Nebular imports in applications
+- ALL Nebular components MUST be wrapped in UI library
+- UI library is the single source of truth for design system
+- Applications MUST import ONLY from UI library
+- Maintain single instance of Nebular theme
+- Document all wrapped components
+
+# Library Structure
+- shared/ui:
+  * Wraps all Nebular components
+  * Provides consistent theming
+  * Centralizes design tokens
+  * Handles component customization
+  * Manages Nebular dependencies
+
+# Import Rules
+1. Applications:
+   * MUST import from @angular-bits/ui
+   * CANNOT import from @nebular/*
+   * MUST use lib-ui-* components
+2. UI Library:
+   * CAN import from @nebular/*
+   * MUST wrap all Nebular components
+   * MUST maintain API compatibility
+3. Feature Libraries:
+   * MUST import from @angular-bits/ui
+   * CANNOT import from @nebular/*
+   * MUST use lib-ui-* components
+
+### BUNDLE SIZE OPTIMIZATION ###
+# Size Budgets
+- Production bundle size limits:
+  * Initial bundle: maximum 1MB
+  * Lazy-loaded modules: maximum 500KB each
+  * Individual components: maximum 100KB each
+  * Total budget: maximum 2MB
+  * Shared chunks: maximum 300KB each
+  * Dynamic imports: maximum 200KB each
+
+# Bundle Analysis
+- Run source-map-explorer after each build
+- Track bundle size changes in CI
+- Document size impact in PRs
+- Monitor chunk splitting
+- Analyze dependency tree
+
+# Optimization Strategies
+1. Code Splitting:
+   * Lazy load all feature modules
+   * Use dynamic imports for heavy components
+   * Implement route-level code splitting
+   * Configure custom chunk splitting
+   * Optimize common chunk strategy
+
+2. Performance Optimization:
+   * Use virtual scrolling for large lists
+   * Implement infinite scroll
+   * Lazy load images and assets
+   * Use WebP image format
+   * Enable resource hints
+   * Implement service worker caching
+
+3. Dependency Management:
+   * Regular dependency audits
+   * Remove unused dependencies
+   * Use lightweight alternatives
+   * Track transitive dependencies
+   * Monitor duplicate packages
+
+4. Build Optimization:
+   * Enable build optimizer
+   * Use production mode
+   * Enable AOT compilation
+   * Implement differential loading
+   * Optimize CSS delivery
+   * Minify and compress assets
+
+5. Runtime Optimization:
+   * Use OnPush change detection
+   * Implement pure pipes
+   * Optimize template expressions
+   * Use trackBy functions
+   * Implement memoization
+   * Cache expensive computations
+
+# Monitoring and Analysis
+- Implement bundle analysis in CI/CD:
+  * Track bundle sizes over time
+  * Set size budgets per chunk
+  * Monitor tree-shaking effectiveness
+  * Analyze unused exports
+  * Track duplicate modules
+
+### ARCHITECTURAL RULES ###
+# Module Boundaries
+- Import only through public API paths (index.ts exports)
+- Features may only import from shared/core
+- Apps may only import from features/shared
+- No cross-feature dependencies
+
+# Example Isolation
+- No relative parent imports (../) in demo components
+- Shared utilities must reside in libs/shared/core
+- Max 15 dependencies per example
+- Bundle size <100KB per demo component
+
+# Bundle Size Management
+- Track bundle sizes in CI/CD pipeline
+- Set up size budgets in angular.json
+- Regular bundle analysis with source-map-explorer
+- Document size impact of new features
+- Monitor lazy-loaded chunk sizes
+
+### CODING CONVENTIONS ###
+// Components
+- Use standalone: true declaration
+- Prefer signals over RxJS where possible
+- Avoid ngModel in forms
+- Include @Example metadata header
+- Use SCSS for component styles
+- Follow BEM methodology for SCSS
+- Keep component styles scoped
+- Use Nebular components and themes
+- Generate new topics using @angular-bits/generators:topic
+
+// BEM Naming Rules
+- Block: Meaningful component name (e.g., 'demo-loader')
+- Element: Double underscore prefix (e.g., 'demo-loader__header')
+- Modifier: Double dash prefix (e.g., 'demo-loader__button--disabled')
+- No more than 2 levels of nesting
+- Use semantic naming over presentational
+- Keep class names in kebab-case
+
+// Services
+- Provide in root unless explicitly scoped
+- Implement destroy$ pattern
+- Add @LogOperation decorator
+- Include lifecycle hooks for educational purposes
+
+// Documentation
+- Link examples using [Example:directive-patterns]
+- Use {{example:di-container}} syntax in markdown
+- Maintain 1:1 parity between docs and code
+- Document Nebular component usage
+
+// Styling
+- Use SCSS for all stylesheets
+- Maintain global SCSS variables in shared/ui
+- Follow BEM naming convention strictly:
+  * Block: Component name
+  * Element: Block__element
+  * Modifier: Block__element--modifier
+- Use mixins for reusable styles
+- Keep component styles modular
+- Avoid global styles in components
+- Use semantic class names
+- Maximum nesting depth of 3 levels
+- Separate modifiers with double hyphens
+- Group related elements together
+- Use Nebular theme variables
+
+### TESTING STANDARDS ###
+// Unit Tests
+- Follow Arrange-Act-Assert pattern
+- Use Angular Testing Library
+- Test IDs via data-testid attributes
+- Test Nebular component integration
+
+// E2E Tests
+- Use Cypress Component Testing
+- Implement visual regression checks
+- Add accessibility audits via axe-core
+
+### EDUCATIONAL GUIDELINES ###
+Each example must include:
+1. Problem statement section
+2. Before/after code comparison
+3. Common mistakes subsection  
+4. Interactive quiz component
+5. Performance impact analysis
+6. Nebular component usage examples
+
+Avoid in examples:
+- Complex RxJS operator chains
+- Monolithic components
+- Direct DOM manipulation
+- Circular dependencies
+- Global styles
+- Inline styles
+- Non-Nebular UI components
+
+### MAINTENANCE RULES ###
+1. Use compatibility layer for Angular upgrades
+2. Document deprecations for 2 release cycles
+3. Create migration schematics for examples
+4. Polyfills only through shared/compatibility
+5. Keep Nebular packages in sync
+
+### SECURITY PROTOCOLS ###
+- Sanitize all demo app inputs
+- Disable eval in example runner
+- Content Security Policy Level 2
+- Third-party examples in sandbox iframe
+
+### VISUALIZATION REQUIREMENTS ###
+- Implement virtual scrolling via @angular/cdk
+- Add performance metrics dashboard
+- Include dependency graph visualization
+- Create change detection flow animator
+- Use Nebular data visualization components
+
+### TOPIC GENERATION ###
+// Always use the official generator for new topics:
+nx generate @angular-bits/generators:topic --name=your-topic-name --category=component
+
+// Available categories:
+- component
+- directive
+- service
+- pipe
+
+// AUTOMATION COMMANDS
+@schematics: nx generate @angular-edu/schematics:educational-example
+@build: nx affected:build --parallel=4
+@test: nx run-many --target=test --all