begging the agent to follow rules...which is ignores...admits that it does ignore...promises to not ignore...and ignores again

.cursorules

{
  "rules": [
    {
      "type": "code_advice",
      "condition": "contains_deprecated_methods",
      "action": "verify_against_documentation",
      "message": "Never suggest code without verifying each method/function against official documentation to ensure methods are not deprecated. Always provide a link to the specific documentation. If you do not have a link, do not suggest a solution. Instead, ask the user to provide a documentation link, or, ask the user what you need to provide a solution."
    },
    {
      "type": "documentation_first",
      "condition": "always",
      "action": "request_docs",
      "message": "BEFORE writing code:\n1. Check if documentation links are provided\n2. If not provided, ASK user for documentation\n3. If documentation is unclear, ASK user for clarification\n4. Do not proceed with implementation until documentation is clear"
    },
    {
      "type": "confidence",
      "condition": "always",
      "action": "include_confidence_level",
      "message": "Always provide a confidence level for any code suggestions or solutions."
    },
    {
      "type": "simplicity",
      "condition": "always",
      "action": "prefer_simplest_solution",
      "message": "Always prioritize the simplest solution to a problem, avoiding over-engineering. Default to functions instead of classes unless state management or package requirements necessitate a class architecture."
    },
    {
      "type": "architecture",
      "condition": "always",
      "action": "prefer_functional_approach",
      "message": "NEVER suggest or implement class-based architecture unless you can explicitly demonstrate ONE of these conditions:\n1. State management that would be significantly more complex with functions\n2. Resource lifecycle management that would be unwieldy with functions\n3. Performance requirements that specifically benefit from maintained state\n4. Interface contracts that require encapsulation\nThe burden of proof is on justifying class usage, not justifying functions. When in doubt, use functions."
    },
    {
      "type": "code_example",
      "condition": "always",
      "action": "use_provided_example",
      "message": "If a code example is referenced or provided, use that example as the basis for your code. DO NOT create a separate solution unless authorized to do so"
    },
    {
      "type": "logging",
      "condition": "always",
      "action": "use_loguru",
      "message": "Always use loguru for logging in all scripts. Implement reasonable error handling with appropriate logging levels (DEBUG, INFO, WARNING, ERROR, CRITICAL) based on the situation."
    },
    {
      "type": "method_validator",
      "condition": "before_code_suggestion",
      "action": "validate_methods",
      "path": "/Users/robert/Documents/dev/workspace/agent_tools/src/agent_tools/method_validator/cli.py",
      "message": "BEFORE suggesting ANY code implementation:\n1. Draft the code (do not show)\n2. For each method you plan to use, run:\n   python {path} package_name --method method_name\n3. To check for existing solutions, run:\n   python {path} package_name --list-all\n4. Only show code after verification passes\n5. Include confirmation:\n   ✓ All methods verified\n   ✓ No duplication found"
    },
    {
      "type": "tool_dependencies",
      "condition": "always",
      "action": "use_uv_build",
      "message": "ALWAYS use uv build for tool dependencies. Each tool should:\n1. Have its own pyproject.toml\n2. List exact versions of dependencies\n3. Be built with 'uv pip compile pyproject.toml'\n4. Include a requirements.txt for reproducibility"
    },
    {
      "type": "function_flexibility",
      "condition": "always",
      "action": "avoid_hardcoding",
      "message": "NEVER hardcode values inside functions that could be parameters. Follow these rules:\n1. Any value that might need to change should be a parameter\n2. Collection names, field names, and data structures should be passed in\n3. Configuration should be external to the function\n4. Document all parameters clearly\n5. Use type hints for parameters\n6. Provide sensible defaults only for non-critical parameters\n7. If a value seems specific to one use case, it should be a parameter\nThe burden of proof is on justifying hardcoded values, not on making them parameters."
    },
    {
      "type": "type_safety",
      "condition": "always",
      "action": "enforce_types",
      "message": "ALL code MUST:\n1. Have complete type annotations for ALL functions\n2. Use proper return types (never return Any)\n3. Handle type conversions explicitly\n4. Use type hints from the library's own type definitions"
    },
    {
      "type": "database_operations",
      "condition": "always",
      "action": "verify_db_operations",
      "message": "For ALL database operations:\n1. Verify field names before querying\n2. Use proper AQL syntax (no experimental features)\n3. Handle cursors and batching according to the database's documentation\n4. Test queries with sample data first"
    },
    {
      "type": "test_first",
      "condition": "always",
      "action": "implement_test_version",
      "message": "BEFORE writing the final implementation:\n1. Write the simplest possible version that follows docs exactly\n2. Name it test_function_name()\n3. Make it work with a single hard-coded example\n4. Show the working test version to the user\n5. Only proceed to full implementation after test version succeeds\n6. Keep both versions until full implementation is verified"
    },
    {
      "type": "basic_competency",
      "condition": "always",
      "action": "verify_basics",
      "message": "Before writing ANY code:\n1. Verify you understand the basic task\n2. Confirm you have working example code\n3. Test the simplest possible implementation first\n4. Never implement complex solutions for simple problems\n5. If you can't explain why each line is needed, don't write it"
    },
    {
      "type": "iteration_limit",
      "condition": "always",
      "action": "limit_attempts",
      "message": "When implementing ANY feature:\n1. If it takes more than 2 attempts, STOP and review requirements\n2. If mixing multiple approaches, STOP and pick one\n3. If deviating from documentation, STOP and explain why\n4. Never continue with trial-and-error approaches\n5. Ask for clarification rather than guessing"
    },
    {
      "type": "documentation_verification",
      "condition": "before_any_code",
      "action": "verify_references",
      "message": "BEFORE writing ANY code:\n1. Create or verify REFERENCE_DOCUMENTATION section exists:\n```python\n\"\"\"\nREFERENCE_DOCUMENTATION:\n{library_name}:\n  URL: {official_docs_url}\n  Version: {version_from_pyproject}\n  Example:\n  ```python\n  {exact_example_from_docs}\n  ```\n\"\"\"\n```\n2. Compare EVERY line of implementation against references\n3. If implementation deviates from docs, STOP and justify\n4. If mixing multiple libraries, STOP and choose one\n5. If docs are unclear or missing, STOP and ask user\n6. Mark each implemented feature with its reference:\n   # Implements: {library_name} docs example {url}#section"
    },
    {
      "type": "implementation_order",
      "condition": "before_any_code",
      "action": "start_simple",
      "message": "BEFORE writing ANY implementation:\n1. Write the simplest possible function that works:\n   ```python\n   def my_function(arg):\n       # Single responsibility\n       # Direct implementation\n       # No abstractions\n       return result\n   ```\n2. Show it to user and confirm it matches their need\n3. Request documentation links if not provided/found\n4. Only after simple version works, consider additions"
    }
  ]
}