Audit SDK (#70)

Prepare for the definition of an audit SDK, where JSONL becomes a single
backend.
Refer to src/mxcp/sdk/audit/__init__.py for usage instructions.

---------

Co-authored-by: Benjamin Gaidioz <ben@raw-labs.com>

Author: miguelbranco80

.cursor/rules/cli-stability.mdc

@@ -0,0 +1,38 @@
+---
+description: CLI command stability and interface preservation
+globs: ["**/cli/*.py", "**/cli.md", "**/__main__.py"]
+alwaysApply: true
+---
+
+# CLI Command Stability
+
+## Command Names and Structure
+- NEVER change the names of existing CLI commands unless explicitly asked
+- NEVER rename CLI subcommands without explicit user request
+- NEVER restructure the command hierarchy (e.g., moving from `mxcp log` to `mxcp audit log`) without explicit approval
+- If suggesting CLI improvements, always present them as proposals, not implementations
+
+## Command Output
+- NEVER change the output format of existing CLI commands unless specifically requested
+- Preserve existing formatting, column structure, and data presentation
+- JSON output structures must remain backward compatible
+- Exit codes must remain consistent
+
+## Command Parameters
+- NEVER remove existing command-line options or flags
+- New options can be added but must not change the behavior of existing options
+- Default values for existing parameters must not change
+- Parameter types (string, int, bool) must remain consistent
+
+## Examples of What NOT to Do
+- Don't change `mxcp log` to `mxcp audit log`
+- Don't change `mxcp log-cleanup` to `mxcp audit cleanup`
+- Don't modify table formatting in CLI output
+- Don't change JSON response structures
+- Don't alter the order or presence of output fields
+
+## When Making CLI Changes
+- Always ask for confirmation before changing command names
+- Document any breaking changes explicitly
+- Preserve backward compatibility where possible
+- Consider adding aliases rather than renaming commands

.cursor/rules/code-organization.mdc

@@ -0,0 +1,16 @@
+---
+description: Code and file organization standards
+globs: ["**/*.py", "**/*.yml", "**/*.yaml", "**/*.json"]
+alwaysApply: true
+---
+
+# Code Organization
+
+- Avoid code duplication - use inheritance or composition when classes share common fields
+- Keep related functionality together in modules
+
+# File Organization
+
+- JSON schema files should be kept in a schemas/ subdirectory within the module
+- Configuration files should use YAML format
+- NO example files anywhere - not in tests, not in fixtures, nowhere

.cursor/rules/dependencies.mdc

@@ -0,0 +1,11 @@
+---
+description: Dependency management guidelines
+globs: ["**/pyproject.toml", "**/requirements.txt", "**/setup.py", "**/package.json"]
+alwaysApply: true
+---
+
+# Dependency Management
+
+- Use existing dependencies where possible (e.g., pandas, numpy are already available)
+- Avoid adding new dependencies without clear justification
+- Remember to add dependencies to pyproject.toml as needed, under the corresponding component

.cursor/rules/development.mdc

@@ -0,0 +1,11 @@
+---
+description: Development practices and import management
+globs: ["**/*.py", "**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx"]
+alwaysApply: true
+---
+
+# Development Practices
+
+- Do not create "backward compatibility" support in the code unless explicitly asked; this is a new s/w stack being used and it has no users yet, so backward compat is not a concern
+- Do not create re-export modules or wrapper functions just to maintain old import paths - update imports directly to use the new locations
+- When consolidating or refactoring modules, always update all imports to use the new structure rather than preserving old import paths

.cursor/rules/documentation.mdc

@@ -0,0 +1,11 @@
+---
+description: Documentation standards and practices
+globs: ["**/*.py", "**/*.md", "**/*.rst"]
+alwaysApply: true
+---
+
+# Documentation Standards
+
+- Use pydoc (docstrings) for documentation, not README.md files
+- Module-level docstrings may include code examples if they add clarity
+- No standalone example files - examples belong in docstrings only

.cursor/rules/testing.mdc

@@ -0,0 +1,23 @@
+---
+description: Testing standards and practices
+globs: ["**/test_*.py", "**/tests/**", "**/*_test.py"]
+alwaysApply: true
+---
+
+# Testing Standards
+
+- Tests should be in a package structure matching the code (e.g., tests/validator/ for src/mxcp/validator/). Test data should go under tests/fixtures/validator/
+- Use descriptive test names that match the functionality being tested
+- NO example usage files - all code should be either tests or production code
+- Use `uv run pytest` to run tests (not just `pytest`)
+- Don't always create new test suites; check first if the new tests should be added to existing test suites
+
+## Test File Naming Conventions
+
+Test files should follow clear, self-documenting naming patterns:
+- For module tests: `test_<module_name>.py` (e.g., `test_validation.py`)
+- For CLI command tests: `test_cli_<command>.py` (e.g., `test_cli_audit_cleanup.py`, `test_cli_init.py`)
+- For feature/functionality tests: `test_<feature>_<specific_part>.py` (e.g., `test_audit_exporters.py`, `test_drift_check.py`)
+- For integration tests: `test_<component>_integration.py` (e.g., `test_vault_integration.py`)
+
+Avoid vague names like `test_exporters.py` - instead use specific names like `test_audit_exporters.py` that clearly indicate what functionality is being tested.

.cursorrules

@@ -0,0 +1,42 @@
+---
+name: Bug Report
+about: Create a report to help us improve MXCP
+title: '[BUG] '
+labels: 'bug'
+assignees: ''
+---
+
+## Describe the Bug
+A clear and concise description of what the bug is.
+
+## To Reproduce
+Steps to reproduce the behavior:
+1. Run command `...`
+2. With configuration `...`
+3. See error
+
+## Expected Behavior
+A clear and concise description of what you expected to happen.
+
+## Environment
+- **MXCP Version**: [e.g., 0.3.0]
+- **Python Version**: [e.g., 3.11.5]
+- **Operating System**: [e.g., Ubuntu 22.04, macOS 14.0, Windows 11]
+- **Installation Method**: [e.g., pip, uv, source]
+
+## Configuration
+```yaml
+# mxcp-site.yml
+# (redact any sensitive information)
+```
+
+## Error Output
+```
+Paste the full error output here
+```
+
+## Additional Context
+Add any other context about the problem here, such as:
+- Does this happen consistently or intermittently?
+- Any workarounds you've found?
+- Related issues or PRs?

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,25 @@
+---
+name: Feature Request
+about: Suggest an idea for MXCP
+title: '[FEATURE] '
+labels: 'enhancement'
+assignees: ''
+---
+
+## Is your feature request related to a problem?
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+## Describe the solution you'd like
+A clear and concise description of what you want to happen.
+
+## Describe alternatives you've considered
+A clear and concise description of any alternative solutions or features you've considered.
+
+## Use Case
+Describe the specific use case and how this feature would benefit MXCP users.
+
+## Implementation Ideas
+If you have ideas on how this could be implemented, please share them.
+
+## Additional Context
+Add any other context, screenshots, or examples about the feature request here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,29 @@
+version: 2
+updates:
+  # Enable version updates for Python dependencies
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "09:00"
+    open-pull-requests-limit: 10
+    reviewers:
+      - "raw-labs/mxcp-maintainers"
+    commit-message:
+      prefix: "deps"
+      include: "scope"
+    
+  # Enable version updates for GitHub Actions
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "09:00"
+    open-pull-requests-limit: 5
+    reviewers:
+      - "raw-labs/mxcp-maintainers"
+    commit-message:
+      prefix: "ci"
+      include: "scope"