introduced uv por dependency and hanlde groups for aces

Author: ADScanPro

.cursor/rules/bloodhound-mcp-usage-rule.mdc

@@ -0,0 +1,23 @@
+alwaysApply: false
+description: "Consult the BloodHound MCP documentation whenever you need BloodHound-specific details."
+examples:
+  applies:
+    - "Before implementing or debugging Cypher queries for BloodHound CE or Legacy."
+    - "When verifying API endpoints, relationship semantics, or query limitations."
+  doesNotApply:
+    - "Generic Python refactors unrelated to BloodHound features."
+---
+# BloodHound MCP Usage
+
+Follow this rule whenever a task involves BloodHound query syntax, API behaviour, or feature constraints.
+
+## Required Actions
+
+- Use the BloodHound MCP knowledge base as the first source of truth for queries, relationship types, API endpoints, and feature support.
+- When in doubt about Cypher syntax, supported constructs, or REST contract details, open the MCP resource and confirm instead of relying on memory.
+- Document relevant findings (query shapes, limitations) in the code comments or README if they influence implementation decisions.
+
+## Additional Notes
+
+- Prefer examples from MCP docs to craft or validate `MATCH`, `WHERE`, and relationship traversal clauses.
+- If information is missing from MCP, call it out explicitly in the response and request clarification or gather manual evidence (e.g. via testing).

.cursor/rules/configuration-management-rule.mdc

@@ -0,0 +1,8 @@
+---
+description: Apply when adding or modifying configuration for the CLI (environment variables, .env files, python-dotenv usage).
+alwaysApply: false
+---
+- Store secrets and environment-specific values in `.env` files kept out of version control (see `.env.example` for keys to maintain).
+- Model configuration with `pydantic-settings` so CLI options, environment variables, and `.env` files are validated automatically.
+- Centralise configuration loading in a single module (for example `core/settings.py`) and reuse those settings across commands.
+- Document any new environment variable in `README.md` and update `.env.example` accordingly.

.cursor/rules/dependencies-management-rules.mdc

@@ -0,0 +1,7 @@
+---
+description: Apply when adding or upgrading Python dependencies so environments stay consistent via uv.
+alwaysApply: false
+---
+- Use `uv` for every dependency operation: `uv pip install <pkg>`, `uv pip compile`, and `uv sync` (no plain `pip`).
+- Keep lockfiles updated by running `uv pip compile pyproject.toml --output-file requirements.lock` when dependencies change.
+- Document new dependencies in `README.md` (Dependencies section) with the command used to install them.

.cursor/rules/error-checks.mdc

@@ -0,0 +1,6 @@
+---
+description: Apply after completing Python code changes to ensure lint checks pass.
+alwaysApply: false
+---
+- After completing Python changes, run `uv run ruff check` and `uv run pylint src/bloodhound_cli` before marking the task complete.
+- Record any intentional lint suppressions inline with a comment explaining why they are safe.

.cursor/rules/error-handling-and-logging-rule.mdc

@@ -0,0 +1,8 @@
+---
+description: Apply when touching error handling or logging in the CLI to ensure consistent context-rich logs.
+alwaysApply: false
+---
+- Wrap external I/O (network, filesystem, subprocess) in explicit try/except blocks; bubble up unexpected exceptions after logging.
+- Configure and reuse `structlog` for logging (see `src/bloodhound_cli/core/logging_utils.py` once added) and log at `error` level with contextual identifiers (command, entity ids, API endpoint).
+- When recovering from an exception, include the original exception message with `exc_info=True` (or `structlog`'s `exception()` helper) to preserve the traceback.
+- Add structured context (dict-style fields) so logs can be filtered; avoid bare `print` for error paths, and only fall back to Rich console output for user-facing summaries.

.cursor/rules/general-python-development.mdc

@@ -0,0 +1,7 @@
+---
+description: Applies when editing or refactoring Python CLI modules under `src/bloodhound_cli` and related tooling.
+alwaysApply: false
+---
+- Before changing code, inspect existing modules in `src/bloodhound_cli` to understand current patterns and reuse shared helpers where possible.
+- Default to writing composable functions and classes with clear responsibilities; avoid monolithic scripts.
+- Automate repetitive CLI tasks by extending the tooling under `scripts/` rather than adding ad-hoc shell commands in docs or comments.

.cursor/rules/project-structure-rule.mdc

@@ -0,0 +1,7 @@
+---
+description: Apply when creating or reorganising files so the project keeps source, tests, docs, and config separated.
+alwaysApply: false
+---
+- Keep runtime code under `src/bloodhound_cli/`, tests under `tests/`, documentation under `docs/`, and configuration under `.cursor/` or `config/`.
+- When introducing a new module, add matching tests in `tests/` and update package `__init__.py` files to expose public APIs intentionally.
+- Avoid placing executable scripts in the project root; add them to `scripts/` with an explanatory README entry.

.cursor/rules/python-ai-friendly-coding-practices-rule.mdc

@@ -0,0 +1,9 @@
+---
+description: Apply when preparing Python code explanations or snippets so they remain clear for AI-assisted workflows.
+alwaysApply: false
+---
+- When sharing code in responses, include short context snippets plus an explanation of the intent before the snippet.
+- Use descriptive variable and function names that reflect domain concepts (e.g., `ace_result` instead of `data`).
+- Add type hints for function signatures and complex variables.
+- Comment non-trivial logic paths, focusing on the "why" rather than restating the code.
+- Raise or log errors with actionable context (input parameters, API endpoints, ids) to simplify triage.

.cursor/rules/python-architecture.mdc

@@ -0,0 +1,7 @@
+---
+description: Apply when designing or restructuring Python modules to keep architecture modular, SRP-compliant, and DRY.
+alwaysApply: false
+---
+- Modular design with distinct files for models, services, controllers, and utilities.
+- Follow Single Responsibility Principle.
+- Follow DRY (Don't Repeat Yourself) Principle.

.cursor/rules/python-code-formatting.mdc

@@ -0,0 +1,7 @@
+---
+description: Apply when formatting Python code so we stay aligned with Black, Pylint, and PEP 8 conventions.
+alwaysApply: false
+---
+- Use Black for code formatting.
+- Use Pylint for linting.
+- Follow PEP 8 and project-specific rules.