issue: 4480494 Add Cursor rules for dev workflow

Add two Cursor AI rules to streamline development workflow:

- commit-msg.mdc: Automates generation of well-formatted
  commit messages following project conventions with proper
  Redmine issue tracking and sign-off requirements

- evaluate-bug.mdc: Provides structured approach for bug
  investigation using Redmine MCP integration, including
  ticket analysis, codebase investigation, and root cause
  analysis with visual diagrams

These rules enable AI-assisted development by encoding
project best practices and integrating with existing tools.

Signed-off-by: Tomer Cabouly <[email protected]>

Author: tomerdbz

.cursor/rules/commit-msg.mdc

@@ -0,0 +1,91 @@
+---
+description: Write a commit message
+alwaysApply: false
+---
+
+Generate a well-formatted commit message for the currently staged changes following the project's conventions.
+
+## Prerequisites
+Before writing the commit message:
+1. Review the staged changes using `git diff --staged` to understand what was modified
+2. Identify the Redmine issue ID (check branch name, recent commits, or ask user if not found)
+3. Retrieve git configuration:
+   - User name: `git config user.name`
+   - User email: `git config user.email`
+
+## Template Format
+```
+issue: <redmine_issue_id> <concise-title>
+
+<detailed-body>
+
+Signed-off-by: <user_full_name> <user_email>
+```
+
+## Writing Guidelines
+
+### Subject Line (First Line)
+- **Format**: `issue: <redmine_issue_id> <concise-title>`
+- **Maximum length**: 51 characters (for optimal git log display)
+- **Style**: Use imperative mood (e.g., "Add feature" not "Added feature")
+- **Content**: Brief, actionable description of the change
+- **Example**: `issue: 12345 Fix memory leak in buffer pool`
+
+### Body
+- **Line length**: Maximum 72 characters per line (for readability in various git tools)
+- **Content**: 
+  - Explain WHAT changed and WHY (not HOW - the code shows that)
+  - Reference any technical decisions or trade-offs
+  - Mention side effects or related changes
+  - Use bullet points for multiple changes
+- **Tone**: Clear, technical, and informative
+- Leave a blank line between subject and body
+
+### Sign-off
+- **Format**: `Signed-off-by: Full Name <[email protected]>`
+- Use values from git config (never hardcode)
+
+## Error Handling
+- If Redmine issue ID is missing: Check branch name first (e.g., "bugfix/12345-description"), then ask user
+- If staged changes are empty: Alert user and abort
+- If git config is incomplete: Ask user to configure git first
+
+## Examples
+
+### Example 1: Feature Addition
+```
+issue: 12345 Add zero-copy receive path
+
+Implement zero-copy receive mechanism using memory mapping
+to reduce CPU overhead in high-throughput scenarios.
+
+- Add new RX buffer pool with mmap allocation
+- Integrate with existing ring buffer architecture
+- Add configuration option XLIO_RX_ZERO_COPY
+
+Performance tests show 15% reduction in CPU usage for
+large packet workloads.
+
+Signed-off-by: John Doe <[email protected]>
+```
+
+### Example 2: Bug Fix
+```
+issue: 45678 Fix race condition in CQ polling
+
+Resolve race between CQ event handler and polling thread
+that caused occasional missed completions.
+
+Added mutex protection around CQ state transitions and
+ensured proper ordering of event acknowledgment.
+
+Signed-off-by: Jane Smith <[email protected]>
+```
+
+## Process
+1. Run `git diff --staged` to analyze changes
+2. Extract/confirm Redmine issue ID
+3. Generate subject line (check 51 char limit)
+4. Write body explaining the changes clearly
+5. Add sign-off with git config values
+6. Verify format compliance before presenting to user

.cursor/rules/evaluate-bug.mdc

@@ -0,0 +1,61 @@
+---
+description: Evaluate and analyze bugs
+alwaysApply: false
+---
+
+Investigate and analyze a Redmine ticket to understand the root cause of a bug.
+
+## Prerequisites
+**Stop and ask user to install Redmine MCP if unavailable.**
+
+If ticket number is not provided, request it from the user.
+
+## Phase 1: Investigation
+
+### Ticket Analysis
+1. Fetch the full ticket using `yai__get_tickets` with ticket ID
+2. Extract key information:
+   - Bug description and reproduction steps
+   - Affected versions, components, priority
+   - Attachments (logs, screenshots, stack traces)
+3. Review comments using `yai__get_comments`
+4. Search for similar issues using `yai__get_similar_issues`
+
+### Codebase Investigation
+1. Locate affected code components (use semantic search and grep)
+2. Trace execution path from entry point to bug location
+3. Review recent changes to affected files (git history)
+4. Examine error handling and edge cases
+5. Check existing tests related to the functionality
+
+### Data Gathering
+- Collect error messages, stack traces, logs
+- Document current vs. expected behavior
+- Note environmental factors (OS, versions, config)
+
+## Phase 2: Root Cause Analysis
+
+Provide a clear explanation of:
+- **What the user experiences**: Observable symptoms
+- **Technical root cause**: The actual defect in code/logic
+- **Why it exists**: Contributing factors (race condition, missing validation, incorrect assumption, etc.)
+- **Impact scope**: Which features/users are affected
+
+## Phase 3: Visual Illustration
+
+Create diagrams to illustrate:
+1. **Bug flow diagram**: Sequence/flow showing how the bug manifests
+2. **Architecture context**: Components involved and their relationships
+
+Use mermaid or ASCII diagrams for clarity.
+
+## Notes
+- If insufficient information exists, clearly state what's missing and ask user
+- Validate all assumptions by examining actual code
+
+## Next Steps
+
+After completing this evaluation:
+- **If fix is needed**: Use `@solve-bug.mdc [ticket#]` to generate solution proposals
+- **If more investigation needed**: Document questions and continue research
+- **If ticket is invalid**: Update ticket status with findings