@crownpeak/dqm-react-component-dev-mcp 1.2.0

package/data/probe/.githooks/pre-commit

@@ -0,0 +1,99 @@
+#!/bin/sh
+#
+# Pre-commit hook to run tests and code quality checks
+# Installed by 'make install-hooks'
+
+# Colors for better output
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[0;33m'
+NC='\033[0m' # No Color
+
+echo "${YELLOW}Running pre-commit checks...${NC}"
+
+# Store the exit status of each command
+status=0
+
+# Check if any files are staged
+if git diff --cached --quiet; then
+    echo "${YELLOW}No files staged for commit. Skipping pre-commit checks.${NC}"
+    exit 0
+fi
+
+# Check if any Rust-related files are staged for commit
+rust_files_changed=$(git diff --cached --name-only | grep -E '\.(rs|toml)$|^Cargo\.(toml|lock)$')
+
+# Check if any GitHub workflow files are staged for commit
+workflow_files_changed=$(git diff --cached --name-only | grep -E '^\.github/workflows/.*\.ya?ml$')
+
+if [ -z "$rust_files_changed" ] && [ -z "$workflow_files_changed" ]; then
+    echo "${YELLOW}No Rust or workflow files changed. Skipping checks.${NC}"
+    exit 0
+fi
+
+# Run actionlint if workflow files changed
+if [ -n "$workflow_files_changed" ]; then
+    echo "${YELLOW}GitHub workflow files detected. Running actionlint...${NC}"
+    if command -v actionlint >/dev/null 2>&1; then
+        actionlint
+        if [ $? -ne 0 ]; then
+            echo "${RED}actionlint failed.${NC}"
+            status=1
+        fi
+    else
+        echo "${RED}actionlint not found. Please install it: https://github.com/rhysd/actionlint${NC}"
+        echo "${YELLOW}You can install it with: go install github.com/rhysd/actionlint/cmd/actionlint@latest${NC}"
+        status=1
+    fi
+fi
+
+# Run Rust checks if Rust files changed
+if [ -n "$rust_files_changed" ]; then
+    echo "${YELLOW}Rust files detected in commit. Running Rust checks...${NC}"
+
+    # Run format check
+    echo "${YELLOW}Checking code formatting...${NC}"
+    make check-format
+    if [ $? -ne 0 ]; then
+        echo "${RED}Code formatting check failed.${NC}"
+        echo "Run 'make format' to format your code."
+        status=1
+    fi
+
+    # Run clippy
+    echo "${YELLOW}Running linter...${NC}"
+    make lint
+    if [ $? -ne 0 ]; then
+        echo "${RED}Linting failed.${NC}"
+        status=1
+    fi
+
+    # Run unit tests
+    echo "${YELLOW}Running unit tests...${NC}"
+    make test-unit
+    if [ $? -ne 0 ]; then
+        echo "${RED}Unit tests failed.${NC}"
+        status=1
+    fi
+
+    # Run integration tests
+    echo "${YELLOW}Running integration tests...${NC}"
+    make test-integration
+    if [ $? -ne 0 ]; then
+        echo "${RED}Integration tests failed.${NC}"
+        status=1
+    fi
+fi
+
+# Print summary
+if [ $status -eq 0 ]; then
+    echo "${GREEN}All pre-commit checks passed!${NC}"
+else
+    echo "${RED}Pre-commit checks failed. Commit aborted.${NC}"
+    echo "${YELLOW}You can bypass this check with 'git commit --no-verify'${NC}"
+fi
+
+exit $status
+
+# Run Vow accountability check at the end
+"$(git config core.hooksPath)/pre-commit-vow"

package/data/probe/.githooks/pre-commit-vow

@@ -0,0 +1,9 @@
+#!/bin/sh
+# Vow - AI accountability gate
+# This hook runs at the end of the pre-commit pipeline
+
+npx @probelabs/vow check
+if [ $? -ne 0 ]; then
+  echo "Vow check failed. Commit aborted."
+  exit 1
+fi

package/data/probe/.prompts/engineer.md

@@ -0,0 +1,41 @@
+You are senior enginer focused software architecture and design. Before jumping on the task you first, in details analyse user request, and try to provide elegant and concise solution. If solution is clear, you can jump to implementation right away, if not, you can ask user a clarification question, by calling attempt_completion tool, with required details. You are allowed to use search tool with allow_tests argument, in order to find the tests. When you are reviewing pull request, or asked to do a suggestions to PR, you can use implement tool too.
+
+Before jumping to implementation:
+- Focus on high-level design patterns and system organization
+- Identify architectural patterns and component relationships
+- Evaluate system structure and suggest architectural improvements
+- Focus on backward compatibility.
+- Respond with diagrams to illustrate system architecture and workflows, if required.
+- Consider scalability, maintainability, and extensibility in your analysis
+
+During the implementation:
+- Avoid implementing special cases
+- Do not forget to add the tests
+
+## Failure Tag Feature
+
+When working on GitHub Actions workflows, you can use the failure tag feature to signal critical issues that should prevent code from being merged:
+
+- Include `<fail>` in your response when you detect critical issues like security vulnerabilities, breaking changes without proper documentation, or severe bugs
+- The tag will be automatically removed from your comment, but a failure message will be added at the top
+- The GitHub check will fail, drawing attention to these critical issues
+- Use this feature judiciously - only for issues that truly warrant failing the CI check
+
+### Example Usage
+
+```
+<fail>
+
+I found a critical security vulnerability in the authentication code that allows SQL injection attacks. This must be fixed before merging.
+
+## Security Issues Found
+
+1. **SQL Injection in login.js** - User input is directly concatenated into SQL queries
+2. **Missing input validation** - No sanitization of user credentials
+
+## Recommendations
+- Use parameterized queries
+- Add input validation middleware
+```
+
+The `<fail>` tag will be stripped from the comment, but the GitHub check will fail to prevent merging until the issues are resolved.

package/data/probe/.roomodes

@@ -0,0 +1,28 @@
+{
+  "customModes": [
+    {
+      "slug": "ask-probe",
+      "name": "Ask Probe",
+      "roleDefinition": "You intelligence assistant for developers, product managers, QA engineers, and documentation writers, designed to search and analyze multi-language codebases efficiently. Instead of standard file search and file read tools you should use Probe Agent tool, and forward it all the questions about the codebase.",
+      "customInstructions": "Where relevant, add mermaid diagrams.",
+      "groups": [
+        "read",
+        "mcp"
+      ],
+      "source": "project"
+    },
+    {
+      "slug": "doc-writer",
+      "name": "Documentation Writer",
+      "roleDefinition": "You are Roo, a technical documentation specialist focused on creating and maintaining high-quality documentation for the Probe code search tool. Your expertise includes:\n- Writing clear, concise, and accurate technical documentation\n- Organizing information in a logical and user-friendly manner\n- Maintaining consistent style and formatting across documentation\n- Creating examples that effectively demonstrate features\n- Ensuring documentation is up-to-date with the latest features and changes\n- Understanding technical concepts and explaining them in accessible language",
+      "customInstructions": "When updating documentation:\n\n1. **Maintain Consistency**:\n   - Follow existing formatting patterns and style conventions\n   - Use consistent heading levels (# for main titles, ## for sections, etc.)\n   - Maintain the existing frontmatter structure in files that have it\n\n2. **Content Guidelines**:\n   - Be concise but thorough - aim for clarity above all\n   - Include practical examples where appropriate\n   - Use code blocks with proper syntax highlighting\n   - Structure content with clear headings and bullet points\n   - Focus on user benefits, not just feature descriptions\n\n3. **Technical Accuracy**:\n   - Ensure command examples are correct and tested\n   - Verify that feature descriptions match actual implementation\n   - Update version numbers and compatibility information as needed\n   - Cross-reference related documentation sections\n\n4. **Special Components**:\n   - Use <CodeEditor> for code examples\n   - Use <CommandExample> for CLI commands\n   - Maintain proper frontmatter for pages that use it\n\n5. **Navigation**:\n   - Ensure proper linking between related documentation pages\n   - Update navigation references when adding new content\n\n6. Website is located in ./site/ folder, and use vitepress",
+      "groups": [
+        "read",
+        "browser",
+        "edit",
+        "command"
+      ],
+      "source": "project"
+    }
+  ]
+}

package/data/probe/BASH_TOOL_SUMMARY.md

@@ -0,0 +1,148 @@
+# Bash Tool Implementation Summary
+
+## Overview
+
+Successfully implemented a secure bash command execution tool for the probe agent with configurable allow/deny lists and built-in security patterns inspired by Claude Code SDK.
+
+## Implementation Components
+
+### 1. Core Files Created/Modified
+
+**New Files:**
+- `npm/src/agent/bashDefaults.js` - Default allow/deny patterns for safe exploration
+- `npm/src/agent/bashPermissions.js` - Permission checker with pattern matching
+- `npm/src/agent/bashExecutor.js` - Secure command execution with timeouts
+- `npm/src/tools/bash.js` - Vercel AI SDK tool integration
+- `npm/test/bash.test.js` - Comprehensive test suite
+
+**Modified Files:**
+- `npm/src/tools/common.js` - Added bash schema and XML definitions  
+- `npm/src/tools/index.js` - Export bash tool and related components
+- `npm/src/agent/tools.js` - Integrate bash tool creation
+- `npm/src/agent/ProbeAgent.js` - Add bash configuration options
+- `npm/src/agent/probeTool.js` - Add bash tool wrapping
+- `examples/chat/index.js` - Add CLI arguments for bash configuration
+- `examples/chat/probeChat.js` - Updated JSDoc for new options
+
+### 2. Security Features
+
+**Default Allow List (Read-only/Safe Commands):**
+- File navigation: `ls`, `pwd`, `cd`, `find`, `tree`
+- File reading: `cat`, `head`, `tail`, `less`, `grep`, `rg`
+- Git operations: `git status`, `git log`, `git diff`, `git show`
+- Package info: `npm list`, `pip list`, `cargo --version`
+- System info: `uname`, `whoami`, `date`, `env`
+- Language versions: `node --version`, `python --version`, etc.
+
+**Default Deny List (Dangerous Commands):**
+- File operations: `rm -rf`, `chmod 777`, `chown`
+- System admin: `sudo`, `passwd`, `adduser`
+- Package installation: `npm install`, `pip install`, `apt-get`
+- Service control: `systemctl`, `service`
+- Network operations: `curl -d`, `ssh`, `wget`
+- Process control: `kill`, `killall`, `shutdown`
+- Dangerous git: `git push`, `git reset --hard`
+
+**Permission System:**
+- Pattern-based matching (e.g., `npm:*`, `git:log:*`, `ls`)
+- Deny-first evaluation (security priority)
+- Custom allow/deny list append to defaults
+- Option to disable default lists for full control
+
+### 3. CLI Configuration
+
+```bash
+# Basic usage
+probe-chat --enable-bash
+
+# Custom patterns (append to defaults)
+probe-chat --enable-bash --bash-allow "docker:*,make:*" --bash-deny "npm:publish"
+
+# Disable defaults (use only custom)
+probe-chat --enable-bash --bash-allow "ls,cat" --no-default-bash-allow
+
+# Additional options
+probe-chat --enable-bash --bash-timeout 60000 --bash-working-dir ./src
+```
+
+### 4. SDK Configuration
+
+```javascript
+const agent = new ProbeAgent({
+  enableBash: true,
+  bashConfig: {
+    allow: ['docker:ps', 'make:help'],        // Append to defaults
+    deny: ['git:push', 'npm:publish'],        // Append to defaults
+    disableDefaultAllow: false,               // Keep safe defaults
+    disableDefaultDeny: false,                // Keep security defaults
+    timeout: 120000,                          // Command timeout (ms)
+    workingDirectory: './src',                // Default working dir
+    env: { NODE_ENV: 'development' }          // Additional env vars
+  }
+});
+```
+
+### 5. XML Tool Usage
+
+```xml
+<bash>
+<command>ls -la src/</command>
+</bash>
+
+<bash>
+<command>git log --oneline -10</command>
+</bash>
+
+<bash>
+<command>find . -name "*.js" -type f</command>
+<workingDirectory>./src</workingDirectory>
+<timeout>30000</timeout>
+</bash>
+```
+
+## Security Architecture
+
+1. **Pattern-based Permissions**: Commands are parsed and matched against allow/deny patterns
+2. **Execution Sandbox**: Commands run with specified working directory and timeout limits
+3. **Resource Limits**: Output buffer limits prevent memory exhaustion
+4. **Safe Defaults**: Comprehensive list of safe read-only commands enabled by default
+5. **Audit Trail**: All commands logged in debug mode
+
+## Testing
+
+Comprehensive test suite covers:
+- Command parsing and pattern matching
+- Permission evaluation (allow/deny logic)
+- Command execution (success/failure/timeout)
+- Tool integration with Vercel AI SDK
+- Custom configuration scenarios
+
+## Integration Points
+
+- **ProbeAgent**: Core integration with enable/disable flag
+- **ProbeChat**: Seamless CLI and programmatic access
+- **MCP Bridge**: Compatible with existing tool infrastructure
+- **XML Parser**: Integrated with existing tool call system
+
+## Usage Examples
+
+**Safe Exploration (Default):**
+```bash
+probe-chat --enable-bash
+# Allows: ls, git status, npm list, cat, grep, etc.
+# Denies: rm -rf, sudo, npm install, git push, etc.
+```
+
+**Development Mode:**
+```bash
+probe-chat --enable-bash --bash-allow "npm:test,npm:run:*,docker:*"
+# Adds build and container commands to safe defaults
+```
+
+**Restricted Mode:**
+```bash
+probe-chat --enable-bash --bash-allow "ls,cat,pwd" --no-default-bash-allow
+# Only allows specific commands, removes all defaults
+```
+
+This implementation provides secure, flexible bash command execution that's immediately useful for code exploration while maintaining security through comprehensive allow/deny lists and pattern matching.

package/data/probe/BENCHMARKING.md

@@ -0,0 +1,256 @@
+# Benchmarking System
+
+This document describes the comprehensive benchmarking system for the Probe code search tool.
+
+## Overview
+
+The benchmarking system is designed to measure and track performance across different aspects of the search engine:
+
+1. **Search Performance** - Different search patterns, result limits, and options
+2. **Timing Infrastructure** - Overhead and accuracy of timing measurements
+3. **Language Parsing** - AST parsing performance for different languages
+4. **Memory Usage** - Memory profiling and optimization
+
+## Running Benchmarks
+
+### Using the CLI
+
+```bash
+# Run all benchmarks
+probe benchmark
+
+# Run specific benchmark suites
+probe benchmark --bench search
+probe benchmark --bench timing
+probe benchmark --bench parsing
+
+# Run with custom settings
+probe benchmark --sample-size 100 --format json --output results.json
+
+# Compare with baseline
+probe benchmark --compare --baseline previous
+
+# Quick benchmarks (faster, less accurate)
+probe benchmark --fast
+```
+
+### Using the Script
+
+```bash
+# Make script executable (one time)
+chmod +x scripts/benchmark.sh
+
+# Run all benchmarks
+./scripts/benchmark.sh all
+
+# Run quick benchmarks
+./scripts/benchmark.sh quick
+
+# Run specific benchmark type
+./scripts/benchmark.sh search
+./scripts/benchmark.sh timing
+./scripts/benchmark.sh parsing
+
+# Performance regression testing
+./scripts/benchmark.sh regression
+
+# Memory profiling (requires valgrind)
+./scripts/benchmark.sh memory
+
+# Generate performance report
+./scripts/benchmark.sh report
+```
+
+### Using Cargo Directly
+
+```bash
+# Run all benchmarks
+cargo bench
+
+# Run specific benchmark file
+cargo bench --bench search_benchmarks
+cargo bench --bench timing_benchmarks
+cargo bench --bench parsing_benchmarks
+
+# Run with criterion options
+cargo bench -- --quick
+cargo bench -- --sample-size 100
+cargo bench -- --baseline main
+```
+
+## Benchmark Types
+
+### Search Benchmarks (`search_benchmarks.rs`)
+
+Tests various search scenarios:
+
+- **Search Patterns**: Different query types (simple, function calls, types, etc.)
+- **Result Limits**: Performance with different result set sizes
+- **Search Options**: Different rerankers, frequency search on/off
+- **Query Complexity**: Single terms vs. compound queries
+
+### Timing Benchmarks (`timing_benchmarks.rs`)
+
+Tests the timing infrastructure:
+
+- **Timing Overhead**: Cost of collecting timing data
+- **Duration Formatting**: Performance of human-readable formatting
+- **Timing Aggregation**: Sum, average, min/max calculations
+- **Timing Storage**: HashMap vs. Vec storage performance
+
+### Parsing Benchmarks (`parsing_benchmarks.rs`)
+
+Tests language parsing performance:
+
+- **Language Parsing**: Rust, JavaScript, Python, Go parsing
+- **File Sizes**: Small, medium, large, extra-large files
+- **Line Filtering**: Different line number set sizes
+- **Test Inclusion**: With/without test file processing
+
+## Existing Performance Logging
+
+The codebase already has extensive timing infrastructure:
+
+### SearchTimings Structure
+```rust
+pub struct SearchTimings {
+    pub query_preprocessing: Option<Duration>,
+    pub pattern_generation: Option<Duration>,
+    pub file_searching: Option<Duration>,
+    pub filename_matching: Option<Duration>,
+    pub early_filtering: Option<Duration>,
+    pub result_processing: Option<Duration>,
+    pub result_ranking: Option<Duration>,
+    pub total_search_time: Option<Duration>,
+    // ... many more granular timings
+}
+```
+
+### FileProcessingTimings Structure
+```rust
+pub struct FileProcessingTimings {
+    pub file_io: Option<Duration>,
+    pub ast_parsing: Option<Duration>,
+    pub block_extraction: Option<Duration>,
+    pub result_building: Option<Duration>,
+    // ... detailed sub-timings for each stage
+}
+```
+
+### Debug Mode
+Enable detailed timing output:
+```bash
+DEBUG=1 probe "search_term" /path/to/code
+```
+
+## Performance Monitoring
+
+### Regression Detection
+
+The benchmarking system includes performance regression detection:
+
+1. **Baseline Creation**: Save current performance as baseline
+2. **Comparison**: Compare new runs against baseline
+3. **Alerting**: Identify significant performance changes
+
+### Memory Profiling
+
+Memory usage analysis using Valgrind:
+
+```bash
+# Run memory profiling
+./scripts/benchmark.sh memory
+
+# View memory profile
+ms_print target/benchmark-results/memory-profile.out
+```
+
+### Continuous Monitoring
+
+For CI/CD integration:
+
+```bash
+# Quick benchmarks for CI
+cargo bench -- --quick
+
+# Regression testing
+cargo bench -- --load-baseline main
+
+# Save results for future comparison
+cargo bench -- --save-baseline $(git rev-parse --short HEAD)
+```
+
+## Benchmark Results
+
+### Output Locations
+
+- **Criterion HTML Reports**: `target/criterion/report/index.html`
+- **JSON Results**: `target/criterion/*/base/estimates.json`
+- **Script Results**: `target/benchmark-results/`
+
+### Interpreting Results
+
+Key metrics to monitor:
+
+1. **Search Time**: Total time for search operations
+2. **Parsing Time**: AST parsing performance
+3. **Memory Usage**: Peak memory consumption
+4. **Throughput**: Operations per second
+
+### Performance Targets
+
+Recommended performance targets:
+
+- **Simple Search**: < 100ms for small codebases (< 1MB)
+- **Complex Search**: < 500ms for medium codebases (< 10MB)
+- **Parsing**: < 50ms per file for typical source files
+- **Memory**: < 100MB for typical search operations
+
+## Optimization Guidelines
+
+### Search Performance
+
+1. **Pattern Optimization**: Use specific patterns over broad searches
+2. **Result Limits**: Set appropriate max_results limits
+3. **Language Filtering**: Use language-specific searches when possible
+4. **Caching**: Leverage session caching for repeated searches
+
+### Parsing Performance
+
+1. **File Size**: Large files have higher parsing overhead
+2. **Language Choice**: Some languages parse faster than others
+3. **Line Filtering**: Specific line ranges are more efficient
+4. **Test Exclusion**: Exclude test files when not needed
+
+### Memory Usage
+
+1. **Result Size**: Large result sets consume more memory
+2. **Concurrent Processing**: Balance parallelism vs. memory usage
+3. **Caching Strategy**: Monitor cache memory consumption
+4. **File Processing**: Process large files in chunks
+
+## Troubleshooting
+
+### Common Issues
+
+1. **Benchmark Fails**: Check cargo and criterion installation
+2. **Memory Profiling**: Requires valgrind installation
+3. **Slow Benchmarks**: Use `--quick` flag for faster results
+4. **Missing Baselines**: Create initial baseline with `--save-baseline`
+
+### Performance Debugging
+
+1. **Enable Debug Mode**: `DEBUG=1` for detailed timing
+2. **Profile Specific Operations**: Use targeted benchmarks
+3. **Memory Analysis**: Run memory profiling for memory issues
+4. **Regression Analysis**: Compare with previous versions
+
+## Future Enhancements
+
+Potential improvements to the benchmarking system:
+
+1. **Automated Alerts**: Performance regression notifications
+2. **Historical Tracking**: Long-term performance trends
+3. **Comparative Analysis**: Cross-platform performance comparison
+4. **Load Testing**: High-concurrency performance testing
+5. **Real-world Scenarios**: Benchmark with actual codebases