feat: implement Datest MVP with Dana test framework integration

.cursor.example/rules/00-quick-reference.mdc

@@ -0,0 +1,52 @@
+# Quick Reference - Critical Rules
+
+## 🚨 MUST FOLLOW IMMEDIATELY
+
+- Use standard Python logging: `import logging; logger = logging.getLogger(__name__)`
+- Apply appropriate logging patterns for Dana development
+- Always use f-strings: `f"Value: {var}"` not `"Value: " + str(var)`
+- Dana modules: `import math_utils` (no .na), Python modules: `import math.py`
+- **ALL temporary development files go in `tmp/` directory**
+- Run `uv run ruff check . && uv run ruff format .` before commits
+- Use type hints: `def func(x: int) -> str:` (required)
+- **Apply KISS/YAGNI**: Start simple, add complexity only when needed
+
+## Essential Commands
+
+```bash
+# Core development workflow
+uv run ruff check . && uv run ruff format .    # Lint and format
+uv run pytest tests/ -v                        # Run tests with verbose output (includes .na files)
+
+# Dana execution - PREFER .na files for Dana functionality testing
+dana examples/dana/01_language_basics/hello_world.na                      # Direct dana command (recommended)
+dana --debug examples/dana/01_language_basics/hello_world.na              # With debug output
+uv run python -m dana.core.repl.dana examples/dana/01_language_basics/hello_world.na  # Alternative
+
+# Interactive development
+dana                                            # Start Dana REPL (recommended)
+uv run python -m dana.core.repl.repl          # Alternative REPL entry point
+```
+
+## Quick Dana Reminders
+
+- **Dana modules**: `import math_utils` (no .na), **Python modules**: `import math.py`
+- **Use `log()` for examples/testing output** (preferred for color coding and debugging)
+- **Always use f-strings**: `f"Value: {var}"` not `"Value: " + str(var)`
+- **Type hints required**: `def func(x: int) -> str:` (mandatory)
+- **Named arguments for structs**: `Point(x=5, y=10)` not `Point(5, 10)`
+- **Prefer `.na` (Dana) test files over `.py`** for Dana-specific functionality
+
+## Quick 3D Methodology Reminders
+
+- **Always create design document first** using the template in 3D.md
+- **Run `uv run pytest tests/ -v` at end of every phase** - 100% pass required
+- **Update implementation progress checkboxes** as you complete each phase
+- **Follow Example Creation Guidelines** for comprehensive examples
+- **Apply Unit Testing Guidelines** for thorough test coverage
+
+## Most Common Tasks
+
+- **Adding new Dana function**: See `dana/core/stdlib/`
+- **Creating agent capability**: Inherit from `dana/frameworks/agent/capability/`
+- **Adding LLM integration**: Use `dana/integrations/llm/`

.cursor.example/rules/01-project-context.mdc

@@ -0,0 +1,41 @@
+# Project Context - Dana Framework
+
+## Project Overview
+
+- Dana is a Domain-Aware NeuroSymbolic Architecture language for AI-driven automation and agent systems
+- Core components: Dana Language, Runtime Engine, Agent Framework
+- Primary language: Python 3.12+
+- Uses uv for dependency management
+
+## Key Files and References
+
+@file pyproject.toml
+@file .python-version
+@file .gitignore
+@file Makefile
+@file README.md
+
+## File Modification Priority
+
+1. **NEVER modify core grammar files without extensive testing**
+2. **Always check existing examples before creating new ones**
+3. **ALL temporary development files go in `tmp/` directory**
+4. **Prefer editing existing files over creating new ones**
+
+## Project Structure
+
+- Core framework code: `dana/`
+- Tests: `tests/` (matching source structure)
+- Examples: `examples/`
+- Documentation: `docs/`
+- Temporary files: `tmp/`
+
+## Documentation References
+
+For comprehensive Dana language documentation including syntax, scoping, data types, functions, structs, pipelines, module system, and AI integration, see:
+
+**📖 [docs/.ai-only/dana.md](dana.md) - Complete Dana Language Reference**
+
+For comprehensive 3D methodology guidelines including design documents, implementation phases, quality gates, example creation, and unit testing standards, see:
+
+**📋 [docs/.ai-only/3d.md](3d.md) - Complete 3D Methodology Reference**

.cursor.example/rules/02-dana-language.mdc

@@ -0,0 +1,125 @@
+# Dana Language - Syntax & Execution
+
+## Dana Language Overview
+
+Dana is a Domain-Aware NeuroSymbolic Architecture language for AI-driven automation and agent systems.
+
+## Import Patterns
+
+- **Dana modules**: `import math_utils` (no .na extension)
+- **Python modules**: `import math.py`
+
+## Dana Syntax Essentials
+
+- **Always use f-strings**: `f"Value: {var}"` not `"Value: " + str(var)`
+- **Type hints required**: `def func(x: int) -> str:` (mandatory)
+- **Named arguments for structs**: `Point(x=5, y=10)` not `Point(5, 10)`
+- **Use `log()` for examples/testing output** (preferred for color coding and debugging)
+
+## Exception Handling
+
+Dana supports comprehensive exception variable assignment syntax:
+
+```dana
+# Exception variable assignment - access exception details
+try:
+    result = process_data(user_input)
+except Exception as e:
+    log(f"Error: {e.message}", "error")
+    log(f"Exception type: {e.type}", "debug")
+    log(f"Traceback: {e.traceback}", "debug")
+    result = default_value
+
+# Multiple exception types with variables
+try:
+    result = complex_operation()
+except ValueError as validation_error:
+    log(f"Validation failed: {validation_error.message}", "warn")
+    result = handle_validation_error(validation_error)
+except RuntimeError as runtime_error:
+    log(f"Runtime error: {runtime_error.message}", "error")
+    result = handle_runtime_error(runtime_error)
+
+# Generic exception catching
+try:
+    result = unsafe_operation()
+except as error:
+    log(f"Caught exception: {error.type} - {error.message}", "error")
+    result = fallback_value
+```
+
+**Exception Object Properties:**
+- `e.type` - Exception class name (string)
+- `e.message` - Error message (string) 
+- `e.traceback` - Stack trace lines (list of strings)
+- `e.original` - Original Python exception object
+
+**Supported Syntax:**
+- `except ExceptionType as var:` - Catch specific type with variable
+- `except (Type1, Type2) as var:` - Catch multiple types with variable
+- `except as var:` - Catch any exception with variable
+- `except ExceptionType:` - Catch specific type without variable
+- `except:` - Catch any exception without variable
+
+## Dana Test File Guidelines
+
+- **Create `test_*.na` files** for Dana functionality testing
+- **Prefer `.na` (Dana) test files over `.py`** for Dana-specific functionality
+- Use `log()` statements for test output and debugging (provides color coding)
+- pytest automatically discovers and runs `.na` test files
+- Run `.na` files directly: `dana test_example.na` or `uv run python -m dana.core.repl.dana test_example.na`
+
+## Dana Execution Methods
+
+### 📁 Create `.na` Test Files
+
+```dana
+# test_my_feature.na
+log("🧪 Testing My Feature")
+
+# Test basic functionality
+result = my_function(5)
+assert result == 10
+log("✅ Basic test passed")
+
+log("🎉 All tests passed!")
+```
+
+### 🏃 Multiple Ways to Run `.na` Files
+
+```bash
+# 1. Direct dana command (recommended)
+dana test_my_feature.na
+
+# 2. With debug output
+dana --debug test_my_feature.na
+
+# 3. Via Python module
+uv run python -m dana.core.repl.dana test_my_feature.na
+
+# 4. Interactive REPL for development
+dana                                    # Start REPL
+uv run python -m dana.core.repl.repl   # Direct REPL access
+
+# 5. Through pytest (automatic discovery)
+pytest tests/my_directory/test_dana_files.py -v  # Runs all test_*.na files
+```
+
+### ✅ When to Use Each Method
+
+- **`.na` files**: For Dana-specific functionality, examples, and testing
+- **`.py` files**: Only for Python-specific testing (imports, integrations)
+- **pytest**: Automated testing and CI/CD pipelines
+- **dana command**: Direct execution and development
+- **REPL**: Interactive development and debugging
+
+## Dana-Specific Debugging & Validation
+
+- **Use `log()` for examples/testing output** (provides color coding and better debugging)
+- **Prefer creating `.na` test files** over `.py` for Dana functionality
+- Test Dana code in REPL: `uv run python -m dana.core.repl.repl`
+- Check AST output: Enable debug logging in transformer
+- Validate against grammar: `dana/core/lang/parser/dana_grammar.lark`
+- Test with existing `.na` files in `examples/dana/`
+- Execute `.na` files: `dana filename.na` or `uv run python -m dana.core.repl.dana filename.na`
+- Use Dana runtime for execution testing

.cursor.example/rules/03-development-methodology.mdc

@@ -0,0 +1,84 @@
+# Development Methodology - 3D & KISS/YAGNI
+
+## 3D Methodology (Design-Driven Development)
+
+Key principle: Think before you build, build with intention, ship with confidence.
+
+### Quick 3D Reminders
+
+- **Always create design document first** using the template in 3D.md
+- **Run `uv run pytest tests/ -v` at end of every phase** - 100% pass required
+- **Update implementation progress checkboxes** as you complete each phase
+- **Follow Example Creation Guidelines** for comprehensive examples
+- **Apply Unit Testing Guidelines** for thorough test coverage
+
+## KISS/YAGNI Design Principles
+
+**KISS (Keep It Simple, Stupid)** & **YAGNI (You Aren't Gonna Need It)**: Balance engineering rigor with practical simplicity.
+
+### AI Decision-Making Guidelines
+
+🎯 **START SIMPLE, EVOLVE THOUGHTFULLY**
+
+For design decisions, AI coders should:
+1. **Default to simplest solution** that meets current requirements
+2. **Document complexity trade-offs** when proposing alternatives  
+3. **Present options** when multiple approaches have merit
+4. **Justify complexity** only when immediate needs require it
+
+🤖 **AI CAN DECIDE** (choose simplest):
+- Data structure choice (dict vs class vs dataclass)
+- Function organization (single file vs module split)
+- Error handling level (basic vs comprehensive)
+- Documentation depth (minimal vs extensive)
+
+👤 **PRESENT TO HUMAN** (let them choose):
+- Architecture patterns (monolith vs microservices)
+- Framework choices (custom vs third-party)
+- Performance optimizations (simple vs complex)
+- Extensibility mechanisms (hardcoded vs configurable)
+
+⚖️ **COMPLEXITY JUSTIFICATION TEMPLATE**:
+"Proposing [complex solution] over [simple solution] because:
+- Current requirement: [specific need]
+- Simple approach limitation: [concrete issue]
+- Complexity benefit: [measurable advantage]
+- Alternative: [let human decide vs simpler approach]"
+
+### Common Over-Engineering Patterns to Avoid
+
+❌ **AVOID** (unless specifically needed):
+- Abstract base classes for single implementations
+- Configuration systems for hardcoded values
+- Generic solutions for specific problems
+- Premature performance optimizations
+- Complex inheritance hierarchies
+- Over-flexible APIs with many parameters
+- Caching systems without proven performance needs
+- Event systems for simple function calls
+
+✅ **PREFER** (start here):
+- Concrete implementations that work
+- Hardcoded values that can be extracted later
+- Specific solutions for specific problems
+- Simple, readable code first
+- Composition over inheritance
+- Simple function signatures
+- Direct computation until performance matters
+- Direct function calls for simple interactions
+
+### Incremental Complexity Strategy
+
+📈 **EVOLUTION PATH** (add complexity only when needed):
+
+Phase 1: Hardcoded → Phase 2: Configurable → Phase 3: Extensible
+
+Example:
+- Phase 1: `return "Hello, World!"`
+- Phase 2: `return f"Hello, {name}!"`
+- Phase 3: `return formatter.format(greeting_template, name)`
+
+🔄 **WHEN TO EVOLVE**:
+- Phase 1→2: When second use case appears
+- Phase 2→3: When third different pattern emerges
+- Never evolve: If usage remains stable

.cursor.example/rules/04-coding-standards.mdc

@@ -0,0 +1,52 @@
+# Coding Standards - Python & Type Hints
+
+## Core Standards
+
+- Follow PEP 8 style guide for Python code
+- Use 4-space indentation (no tabs)
+- **Type hints required**: `def func(x: int) -> str:` (mandatory)
+- Use docstrings for all public modules, classes, and functions
+- **Always use f-strings**: `f"Value: {var}"` not `"Value: " + str(var)`
+
+## Modern Type Hints (PEP 604)
+
+```python
+# ✅ CORRECT - Modern syntax
+def process_data(items: list[str], config: dict[str, int] | None = None) -> str | None:
+    return f"Processed {len(items)} items"
+
+# ❌ AVOID - Old syntax
+from typing import Dict, List, Optional, Union
+def process_data(items: List[str], config: Optional[Dict[str, int]] = None) -> Union[str, None]:
+    return "Processed " + str(len(items)) + " items"
+```
+
+## Linting & Formatting
+
+- **MUST RUN**: `uv run ruff check . && uv run ruff format .` before commits
+- Line length limit: 140 characters (configured in pyproject.toml)
+- Auto-fix with: `uv run ruff check --fix .`
+
+## Best Practices and Patterns
+
+- Use dataclasses or Pydantic models for data structures
+- Prefer composition over inheritance
+- Use async/await for I/O operations
+- Follow SOLID principles
+- Use dependency injection where appropriate
+- Implement proper error handling with custom exceptions
+- **Start with simplest solution that works**
+- **Add complexity only when requirements demand it**
+
+## Git Commit Standards
+
+- **NEVER include Claude attribution or "Generated with Claude Code" in git commit messages**
+- Write clean, professional commit messages focusing on technical content
+- Use clear, descriptive commit messages explaining the "why" not just the "what"
+
+## Common Methods and Utilities
+
+- **Use standard Python logging**: `import logging; logger = logging.getLogger(__name__)`
+- Use configuration from `dana.common.config`
+- Use graph operations from `dana.common.graph`
+- Use IO utilities from `dana.common.io`