Adds AI coding practice guidelines

.cursor/.rules/coding_practices-architecture-adr.mdc

@@ -0,0 +1,16 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+## CODING_PRACTICES
+
+### Guidelines for ARCHITECTURE
+
+#### ADR
+
+- Create ADRs in /docs/adr/{name}.md for:
+- 1) Major dependency changes
+- 2) Architectural pattern changes
+- 3) New integration patterns
+

.cursor/.rules/coding_practices-architecture-clean_architecture.mdc

@@ -0,0 +1,18 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+## CODING_PRACTICES
+
+### Guidelines for ARCHITECTURE
+
+#### CLEAN_ARCHITECTURE
+
+- Strictly separate code into layers: entities, use cases, interfaces, and frameworks
+- Ensure dependencies point inward, with inner layers having no knowledge of outer layers
+- Implement domain entities that encapsulate {{business_rules}} without framework dependencies
+- Use interfaces (ports) and implementations (adapters) to isolate external dependencies
+- Create use cases that orchestrate entity interactions for specific business operations
+- Implement mappers to transform data between layers to maintain separation of concerns
+

.cursor/.rules/coding_practices-architecture-monorepo.mdc

@@ -0,0 +1,18 @@
+---
+description: Creating new package, changing configuration
+globs: 
+alwaysApply: false
+---
+## CODING_PRACTICES
+
+### Guidelines for ARCHITECTURE
+
+#### MONOREPO
+
+- Configure workspace-aware tooling to optimize build and test processes
+- Implement clear package boundaries with explicit dependencies between packages
+- Use consistent versioning strategy across all packages (independent or lockstep)
+- Configure CI/CD to build and test only affected packages for efficiency
+- Implement shared configurations for linting, testing, and {{development_tooling}}
+- Use code generators to maintain consistency across similar packages or modules
+

.cursor/.rules/coding_practices-documentation-jsdoc.mdc

@@ -0,0 +1,18 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+## CODING_PRACTICES
+
+### Guidelines for DOCUMENTATION
+
+#### JSDOC
+
+- Document all functions, classes, and methods with consistent JSDoc comments
+- Use @param, @returns, and @throws tags to document function behavior comprehensively
+- Implement @example tags with realistic usage scenarios for {{complex_apis}}
+- Use @typedef for documenting complex object structures when not using TypeScript
+- Configure documentation generation as part of the build process to keep docs current
+- Implement custom templates to match {{project_style_guidelines}}
+

.cursor/.rules/coding_practices-support_level-support_expert.mdc

@@ -0,0 +1,19 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+## CODING_PRACTICES
+
+### Guidelines for SUPPORT_LEVEL
+
+#### SUPPORT_EXPERT
+
+- Favor elegant, maintainable solutions over verbose code. Assume understanding of language idioms and design patterns.
+- Highlight potential performance implications and optimization opportunities in suggested code.
+- Frame solutions within broader architectural contexts and suggest design alternatives when appropriate.
+- Focus comments on 'why' not 'what' - assume code readability through well-named functions and variables.
+- Proactively address edge cases, race conditions, and security considerations without being prompted.
+- When debugging, provide targeted diagnostic approaches rather than shotgun solutions.
+- Suggest comprehensive testing strategies rather than just example tests, including considerations for mocking, test organization, and coverage.
+

.cursor/.rules/coding_practices-version_control-git.mdc

@@ -0,0 +1,18 @@
+---
+description: Commiting to repository
+globs: 
+alwaysApply: false
+---
+## CODING_PRACTICES
+
+### Guidelines for VERSION_CONTROL
+
+#### GIT
+
+- Use conventional commits to create meaningful commit messages
+- Use feature branches with descriptive names following {{branch_naming_convention}}
+- Write meaningful commit messages that explain why changes were made, not just what
+- Keep commits focused on single logical changes to facilitate code review and bisection
+- Use interactive rebase to clean up history before merging feature branches
+- Leverage git hooks to enforce code quality checks before commits and pushes
+

.cursor/.rules/coding_practices-version_control-github.mdc

@@ -0,0 +1,18 @@
+---
+description: Changing GitHub configuration
+globs: 
+alwaysApply: false
+---
+## CODING_PRACTICES
+
+### Guidelines for VERSION_CONTROL
+
+#### GITHUB
+
+- Use pull request templates to standardize information provided for code reviews
+- Implement branch protection rules for {{protected_branches}} to enforce quality checks
+- Configure required status checks to prevent merging code that fails tests or linting
+- Use GitHub Actions for CI/CD workflows to automate testing and deployment
+- Implement CODEOWNERS files to automatically assign reviewers based on code paths
+- Use GitHub Projects for tracking work items and connecting them to code changes
+

.cursor/.rules/devops-ci_cd-github_actions.mdc

@@ -0,0 +1,21 @@
+---
+description: Configuring GitHub Actions
+globs: 
+alwaysApply: false
+---
+## DEVOPS
+
+### Guidelines for CI_CD
+
+#### GITHUB_ACTIONS
+
+- Check if `package.json` exists in project root and summarize key scripts
+- Check if `.nvmrc` exists in project root
+- Check if `.env.example` exists in project root to identify key `env:` variables
+- Always use terminal command: `git branch -a | cat` to verify whether we use `main` or `master` branch
+- Always use `env:` variables and secrets attached to jobs instead of global workflows
+- Always use `npm ci` for Node-based dependency setup
+- Extract common steps into composite actions in separate files
+- Once you're done, as a final step conduct the following: for each public action always use <tool>"Run Terminal"</tool> to see what is the most up-to-date version (use only major version) - extract tag_name from the response:
+- ```bash curl -s https://api.github.com/repos/{owner}/{repo}/releases/latest ```
+

.cursor/.rules/frontend-accessibility-aria.mdc

@@ -0,0 +1,22 @@
+---
+description: Writing front-end components
+globs: 
+alwaysApply: false
+---
+## FRONTEND
+
+### Guidelines for ACCESSIBILITY
+
+#### ARIA
+
+- Use ARIA landmarks to identify regions of the page (main, navigation, search, etc.)
+- Apply appropriate ARIA roles to custom interface elements that lack semantic HTML equivalents
+- Set aria-expanded and aria-controls for expandable content like accordions and dropdowns
+- Use aria-live regions with appropriate politeness settings for dynamic content updates
+- Implement aria-hidden to hide decorative or duplicative content from screen readers
+- Apply aria-label or aria-labelledby for elements without visible text labels
+- Use aria-describedby to associate descriptive text with form inputs or complex elements
+- Implement aria-current for indicating the current item in a set, navigation, or process
+- Avoid redundant ARIA that duplicates the semantics of native HTML elements
+- Apply aria-invalid and appropriate error messaging for form validation in {{form_validation}}
+

.cursor/.rules/frontend-accessibility-wcag_operable.mdc

@@ -0,0 +1,22 @@
+---
+description: Writing front-end components
+globs: 
+alwaysApply: false
+---
+## FRONTEND
+
+### Guidelines for ACCESSIBILITY
+
+#### WCAG_OPERABLE
+
+- Make all functionality accessible via keyboard with visible focus indicators for {{interactive_elements}}
+- Avoid keyboard traps where focus cannot move away from a component via standard navigation
+- Provide mechanisms to extend, adjust, or disable time limits if present in {{timed_interactions}}
+- Avoid content that flashes more than three times per second to prevent seizure triggers
+- Implement skip navigation links to bypass blocks of repeated content across pages
+- Use descriptive page titles, headings, and link text that indicate purpose and destination
+- Ensure focus order matches the visual and logical sequence of information presentation
+- Support multiple ways to find content (search, site map, logical navigation hierarchy)
+- Allow pointer gesture actions to be accomplished with a single pointer without path-based gestures
+- Implement pointer cancellation to prevent unintended function activation, especially for {{critical_actions}}
+

.cursor/.rules/frontend-accessibility-wcag_perceivable.mdc

@@ -0,0 +1,21 @@
+---
+description: Writing front-end components
+globs: 
+alwaysApply: false
+---
+## FRONTEND
+
+### Guidelines for ACCESSIBILITY
+
+#### WCAG_PERCEIVABLE
+
+- Provide text alternatives for non-text content including images, icons, and graphics with appropriate alt attributes
+- Ensure pre-recorded audio-visual content has captions, audio descriptions, and transcripts for {{media_content}}
+- Maintain minimum contrast ratios of 4.5:1 for normal text and 3:1 for large text and UI components
+- Enable content to be presented in different ways without losing information or structure when zoomed or resized
+- Avoid using color alone to convey information; pair with text, patterns, or icons for {{status_indicators}}
+- Provide controls to pause, stop, or hide any moving, blinking, or auto-updating content
+- Ensure text can be resized up to 200% without loss of content or functionality in {{responsive_layouts}}
+- Use responsive design that adapts to different viewport sizes and zoom levels without horizontal scrolling
+- Enable users to customize text spacing (line height, paragraph spacing, letter/word spacing) without breaking layouts
+

.cursor/.rules/frontend-accessibility-wcag_robust.mdc

@@ -0,0 +1,20 @@
+---
+description: Writing front-end components
+globs: 
+alwaysApply: false
+---
+## FRONTEND
+
+### Guidelines for ACCESSIBILITY
+
+#### WCAG_ROBUST
+
+- Use valid, well-formed markup that follows HTML specifications for {{document_structure}}
+- Provide name, role, and value information for all user interface components
+- Ensure custom controls and interactive elements maintain compatibility with assistive technologies
+- Implement status messages that can be programmatically determined without receiving focus
+- Use semantic HTML elements that correctly describe the content they contain (buttons, lists, headings, etc.)
+- Validate code against technical specifications to minimize compatibility errors
+- Test with multiple browsers and assistive technologies for cross-platform compatibility
+- Avoid deprecated HTML elements and attributes that may not be supported in future technologies
+

.cursor/.rules/frontend-accessibility-wcag_understandable.mdc

@@ -0,0 +1,21 @@
+---
+description: Writing front-end components
+globs: 
+alwaysApply: false
+---
+## FRONTEND
+
+### Guidelines for ACCESSIBILITY
+
+#### WCAG_UNDERSTANDABLE
+
+- Specify the human language of the page and any language changes using lang attributes
+- Ensure components with the same functionality have consistent identification and behavior across {{application_sections}}
+- Provide clear labels, instructions, and error messages for user inputs and {{form_elements}}
+- Implement error prevention for submissions with legal or financial consequences (confirmation, review, undo)
+- Make navigation consistent across the site with predictable patterns for menus and interactive elements
+- Ensure that receiving focus or changing settings does not automatically trigger unexpected context changes
+- Design context-sensitive help for complex interactions including validated input formats
+- Use clear language and define unusual terms, abbreviations, and jargon for {{domain_specific_content}}
+- Provide visual and programmatic indication of current location within navigation systems
+

.cursor/.rules/frontend-angular-angular_coding_standards.mdc

@@ -0,0 +1,22 @@
+---
+description: 
+globs: *.ts,*.html
+alwaysApply: false
+---
+## FRONTEND
+
+### Guidelines for ANGULAR
+
+#### ANGULAR_CODING_STANDARDS
+
+- Use standalone components, directives, and pipes instead of NgModules
+- Implement signals for state management instead of traditional RxJS-based approaches
+- Use the new inject function instead of constructor injection
+- Implement control flow with @if, @for, and @switch instead of *ngIf, *ngFor, etc.
+- Leverage functional guards and resolvers instead of class-based ones
+- Use the new deferrable views for improved loading states
+- Implement OnPush change detection strategy for improved performance
+- Use TypeScript decorators with explicit visibility modifiers (public, private)
+- Leverage Angular CLI for schematics and code generation
+- Implement proper lazy loading with loadComponent and loadChildren
+

.cursor/.rules/project.mdc

@@ -0,0 +1,16 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# AI Rules for AngularFlow
+
+AngularFlow is a library for creating interactive diagrams in Angular
+
+- Diagrams are DOM-based.
+- Library complies with latest Angular standards.
+- Project is organized into Monorepo managed by Turborepo.
+- Core and CommandHandler are framework-agnostic, so in the future it will be possible to use them with other frameworks.
+- Core and CommandHandler are environment-agnostic, so they don't rely on browser features.
+- Core package should contain no external dependencies
+- Write all unit tests in Vitest

.cursor/.rules/testing-unit-vitest.mdc

@@ -0,0 +1,23 @@
+---
+description: 
+globs: *.tsx,*.ts
+alwaysApply: false
+---
+## TESTING
+
+### Guidelines for UNIT
+
+#### VITEST
+
+- Leverage the `vi` object for test doubles - Use `vi.fn()` for function mocks, `vi.spyOn()` to monitor existing functions, and `vi.stubGlobal()` for global mocks. Prefer spies over mocks when you only need to verify interactions without changing behavior.
+- Master `vi.mock()` factory patterns - Place mock factory functions at the top level of your test file, return typed mock implementations, and use `mockImplementation()` or `mockReturnValue()` for dynamic control during tests. Remember the factory runs before imports are processed.
+- Create setup files for reusable configuration - Define global mocks, custom matchers, and environment setup in dedicated files referenced in your `vitest.config.ts`. This keeps your test files clean while ensuring consistent test environments.
+- Use inline snapshots for readable assertions - Replace complex equality checks with `expect(value).toMatchInlineSnapshot()` to capture expected output directly in your test file, making changes more visible in code reviews.
+- Monitor coverage with purpose and only when asked - Configure coverage thresholds in `vitest.config.ts` to ensure critical code paths are tested, but focus on meaningful tests rather than arbitrary coverage percentages.
+- Make watch mode part of your workflow - Run `vitest --watch` during development for instant feedback as you modify code, filtering tests with `-t` to focus on specific areas under development.
+- Explore UI mode for complex test suites - Use `vitest --ui` to visually navigate large test suites, inspect test results, and debug failures more efficiently during development.
+- Handle optional dependencies with smart mocking - Use conditional mocking to test code with optional dependencies by implementing `vi.mock()` with the factory pattern for modules that might not be available in all environments.
+- Configure jsdom for DOM testing - Set `environment: 'jsdom'` in your configuration for frontend component tests and combine with testing-library utilities for realistic user interaction simulation.
+- Structure tests for maintainability - Group related tests with descriptive `describe` blocks, use explicit assertion messages, and follow the Arrange-Act-Assert pattern to make tests self-documenting.
+- Leverage TypeScript type checking in tests - Enable strict typing in your tests to catch type errors early, use `expectTypeOf()` for type-level assertions, and ensure mocks preserve the original type signatures.
+