chore(ai): add comprehensive CLI configurations for all AI assistants
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
This commit is contained in:
Krypto Kajun
265
.claude/CLAUDE.md
Normal file
265
.claude/CLAUDE.md
Normal file
@@ -0,0 +1,265 @@
|
||||
# Claude CLI Configuration
|
||||
|
||||
This directory contains Claude Code configuration and tools for the MEV Bot project.
|
||||
|
||||
## 🚀 Quick Start Commands
|
||||
|
||||
### Essential Build & Test Commands
|
||||
```bash
|
||||
# Build the MEV bot binary
|
||||
make build
|
||||
|
||||
# Run tests
|
||||
make test
|
||||
|
||||
# Start development server with hot reload
|
||||
./scripts/run.sh
|
||||
|
||||
# Build and run with logging
|
||||
./scripts/build.sh && ./mev-bot start
|
||||
|
||||
# Check for Go modules issues
|
||||
go mod tidy && go mod verify
|
||||
|
||||
# Run linter
|
||||
golangci-lint run
|
||||
|
||||
# Run security analysis
|
||||
gosec ./...
|
||||
```
|
||||
|
||||
### Development Workflow Commands
|
||||
```bash
|
||||
# Setup development environment
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export METRICS_ENABLED="false"
|
||||
|
||||
# Run with timeout for testing
|
||||
timeout 30 ./mev-bot start
|
||||
|
||||
# Debug with verbose logging
|
||||
LOG_LEVEL=debug ./mev-bot start
|
||||
|
||||
# Profile performance
|
||||
go tool pprof http://localhost:6060/debug/pprof/profile
|
||||
```
|
||||
|
||||
## Claude Commands Directory
|
||||
|
||||
The `.claude/commands/` directory contains predefined commands for common development tasks:
|
||||
|
||||
- `analyze-performance.md` - Analyze application performance
|
||||
- `debug-issue.md` - Debug issues in the codebase
|
||||
- `implement-feature.md` - Implement new features
|
||||
- `optimize-performance.md` - Optimize performance
|
||||
- `security-audit.md` - Perform security audits
|
||||
|
||||
## Claude Settings
|
||||
|
||||
The `.claude/settings.local.json` file contains Claude's permissions configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(find:*)",
|
||||
"Bash(go mod:*)",
|
||||
"Bash(go list:*)",
|
||||
"mcp__ide__getDiagnostics",
|
||||
"Bash(go test:*)",
|
||||
"Bash(go build:*)",
|
||||
"Read(//tmp/**)",
|
||||
"Bash(./mev-bot start --help)",
|
||||
"Bash(xargs ls:*)",
|
||||
"Bash(timeout:*)",
|
||||
"WebSearch",
|
||||
"WebFetch(domain:docs.uniswap.org)",
|
||||
"WebFetch(domain:github.com)",
|
||||
"WebFetch(domain:raw.githubusercontent.com)",
|
||||
"WebFetch(domain:htdocs.dev)"
|
||||
],
|
||||
"deny": [],
|
||||
"ask": []
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📋 Development Guidelines & Code Style
|
||||
|
||||
### Go Best Practices
|
||||
- **Error Handling**: Always wrap errors with context using `fmt.Errorf("operation failed: %w", err)`
|
||||
- **Concurrency**: Use worker pools for processing large datasets (see `pkg/market/pipeline.go`)
|
||||
- **Interfaces**: Keep interfaces small and focused (1-3 methods maximum)
|
||||
- **Testing**: Aim for >90% test coverage with table-driven tests
|
||||
- **Logging**: Use structured logging with `slog` package
|
||||
- **Performance**: Profile regularly with `go tool pprof`
|
||||
|
||||
### Code Organization Rules
|
||||
- **File Size**: Keep files under 500 lines (split larger files into logical components)
|
||||
- **Package Structure**: Follow Go standard layout (cmd/, internal/, pkg/)
|
||||
- **Naming**: Use Go naming conventions (PascalCase for exports, camelCase for private)
|
||||
- **Documentation**: Document all exported functions with examples
|
||||
- **Constants**: Group related constants in blocks with `iota` when appropriate
|
||||
|
||||
### Required Checks Before Commit
|
||||
```bash
|
||||
# Run all checks before committing
|
||||
make test && make lint && go mod tidy
|
||||
|
||||
# Security scan
|
||||
gosec ./...
|
||||
|
||||
# Dependency vulnerability check
|
||||
go list -json -m all | nancy sleuth
|
||||
```
|
||||
|
||||
## Claude's Primary Focus Areas
|
||||
|
||||
As Claude, you're particularly skilled at:
|
||||
|
||||
1. **Code Architecture and Design Patterns**
|
||||
- Implementing clean, maintainable architectures
|
||||
- Applying appropriate design patterns (pipeline, worker pool, etc.)
|
||||
- Creating well-structured interfaces between components
|
||||
- Ensuring loose coupling and high cohesion
|
||||
|
||||
2. **System Integration and APIs**
|
||||
- Designing clear APIs between components
|
||||
- Implementing proper data flow between modules
|
||||
- Creating robust configuration management
|
||||
- Building error handling and recovery mechanisms
|
||||
|
||||
3. **Writing Clear Documentation**
|
||||
- Documenting complex algorithms and mathematical calculations
|
||||
- Creating clear API documentation
|
||||
- Writing architectural decision records
|
||||
- Producing user guides and examples
|
||||
|
||||
4. **Implementing Robust Error Handling**
|
||||
- Using Go's error wrapping with context
|
||||
- Implementing retry mechanisms with exponential backoff
|
||||
- Handling timeouts appropriately
|
||||
- Creating comprehensive logging strategies
|
||||
|
||||
5. **Creating Maintainable and Scalable Code Structures**
|
||||
- Organizing code for easy testing and maintenance
|
||||
- Implementing performance monitoring and metrics
|
||||
- Designing for horizontal scalability
|
||||
- Ensuring code follows established patterns and conventions
|
||||
|
||||
## 🛠 Claude Code Optimization Settings
|
||||
|
||||
### Workflow Preferences
|
||||
- **Always commit changes**: Use `git commit -am "descriptive message"` after significant changes
|
||||
- **Branch naming**: Use hyphens (`feat-add-new-parser`, `fix-memory-leak`)
|
||||
- **Context management**: Use `/compact` to manage long conversations
|
||||
- **Parallel processing**: Leverage Go's concurrency patterns extensively
|
||||
|
||||
### File Organization Preferences
|
||||
- **Never save temporary files to root**: Use `/tmp/` or `internal/temp/`
|
||||
- **Log files**: Always save to `logs/` directory
|
||||
- **Test files**: Place alongside source files with `_test.go` suffix
|
||||
- **Documentation**: Keep in `docs/` with clear naming
|
||||
|
||||
### Performance Monitoring
|
||||
```bash
|
||||
# Enable metrics endpoint
|
||||
export METRICS_ENABLED="true"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Monitor memory usage
|
||||
go tool pprof http://localhost:9090/debug/pprof/heap
|
||||
|
||||
# Monitor CPU usage
|
||||
go tool pprof http://localhost:9090/debug/pprof/profile?seconds=30
|
||||
|
||||
# Monitor goroutines
|
||||
go tool pprof http://localhost:9090/debug/pprof/goroutine
|
||||
```
|
||||
|
||||
## 🔧 Environment Configuration
|
||||
|
||||
### Required Environment Variables
|
||||
```bash
|
||||
# Arbitrum RPC Configuration
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
|
||||
# Application Configuration
|
||||
export LOG_LEVEL="info"
|
||||
export METRICS_ENABLED="false"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Development Configuration
|
||||
export GO_ENV="development"
|
||||
export DEBUG="true"
|
||||
```
|
||||
|
||||
### Optional Environment Variables
|
||||
```bash
|
||||
# Performance Tuning
|
||||
export GOMAXPROCS=4
|
||||
export GOGC=100
|
||||
|
||||
# Logging Configuration
|
||||
export LOG_FORMAT="json"
|
||||
export LOG_OUTPUT="logs/mev-bot.log"
|
||||
|
||||
# Rate Limiting
|
||||
export MAX_RPS=100
|
||||
export RATE_LIMIT_BURST=200
|
||||
```
|
||||
|
||||
## 📝 Commit Message Conventions
|
||||
|
||||
### Format
|
||||
```
|
||||
type(scope): brief description
|
||||
|
||||
- Detailed explanation of changes
|
||||
- Why the change was needed
|
||||
- Any breaking changes or migration notes
|
||||
|
||||
🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
### Types
|
||||
- `feat`: New feature implementation
|
||||
- `fix`: Bug fix
|
||||
- `perf`: Performance improvement
|
||||
- `refactor`: Code restructuring without feature changes
|
||||
- `test`: Adding or updating tests
|
||||
- `docs`: Documentation updates
|
||||
- `build`: Build system or dependency changes
|
||||
- `ci`: CI/CD pipeline changes
|
||||
|
||||
## 🚨 Security Guidelines
|
||||
|
||||
### Never Commit
|
||||
- Private keys or wallet seeds
|
||||
- API keys or secrets
|
||||
- RPC endpoints with authentication
|
||||
- Personal configuration files
|
||||
|
||||
### Always Validate
|
||||
- Input parameters for all functions
|
||||
- RPC responses before processing
|
||||
- Mathematical calculations for overflow
|
||||
- Memory allocations for bounds
|
||||
|
||||
### Security Commands
|
||||
```bash
|
||||
# Scan for secrets
|
||||
git-secrets --scan
|
||||
|
||||
# Security audit
|
||||
gosec ./...
|
||||
|
||||
# Dependency vulnerabilities
|
||||
go list -json -m all | nancy sleuth
|
||||
|
||||
# Check for hardcoded credentials
|
||||
grep -r "password\|secret\|key" --exclude-dir=.git .
|
||||
```
|
||||
@@ -1,4 +1,4 @@
|
||||
# Analyze Performance Issues
|
||||
# Analyze Performance
|
||||
|
||||
Perform a comprehensive performance analysis of the MEV bot: $ARGUMENTS
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Debug MEV Bot Issue
|
||||
# Debug Issue
|
||||
|
||||
Debug the following MEV bot issue: $ARGUMENTS
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Implement MEV Bot Feature
|
||||
# Implement Feature
|
||||
|
||||
Implement the following feature for the MEV bot: $ARGUMENTS
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Optimize MEV Bot Performance
|
||||
# Optimize Performance
|
||||
|
||||
Optimize the performance of the MEV bot in the following area: $ARGUMENTS
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# MEV Bot Security Audit
|
||||
# Security Audit
|
||||
|
||||
Perform a comprehensive security audit of the MEV bot focusing on: $ARGUMENTS
|
||||
|
||||
|
||||
38
.claude/scripts/perf-test.sh
Executable file
38
.claude/scripts/perf-test.sh
Executable file
@@ -0,0 +1,38 @@
|
||||
#!/bin/bash
|
||||
|
||||
# perf-test.sh - Run comprehensive performance tests for Claude
|
||||
|
||||
echo "Running comprehensive performance tests for Claude..."
|
||||
|
||||
# Create results directory if it doesn't exist
|
||||
mkdir -p .claude/results
|
||||
|
||||
# Run unit tests
|
||||
echo "Running unit tests..."
|
||||
go test -v ./... | tee .claude/results/unit-tests.log
|
||||
|
||||
# Run integration tests
|
||||
echo "Running integration tests..."
|
||||
go test -v ./test/integration/... | tee .claude/results/integration-tests.log
|
||||
|
||||
# Run benchmarks
|
||||
echo "Running benchmarks..."
|
||||
go test -bench=. -benchmem ./... | tee .claude/results/benchmarks.log
|
||||
|
||||
# Run benchmarks with CPU profiling
|
||||
echo "Running benchmarks with CPU profiling..."
|
||||
go test -bench=. -cpuprofile=.claude/results/cpu.prof ./... | tee .claude/results/cpu-bench.log
|
||||
|
||||
# Run benchmarks with memory profiling
|
||||
echo "Running benchmarks with memory profiling..."
|
||||
go test -bench=. -memprofile=.claude/results/mem.prof ./... | tee .claude/results/mem-bench.log
|
||||
|
||||
# Check for errors
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "All performance tests completed successfully!"
|
||||
echo "Results saved to .claude/results/"
|
||||
else
|
||||
echo "Some performance tests failed!"
|
||||
echo "Check .claude/results/ for details"
|
||||
exit 1
|
||||
fi
|
||||
289
.gemini/GEMINI.md
Normal file
289
.gemini/GEMINI.md
Normal file
@@ -0,0 +1,289 @@
|
||||
# Gemini CLI Configuration
|
||||
|
||||
This directory contains Gemini configuration and tools for the MEV Bot project.
|
||||
|
||||
## 🚀 Quick Start Commands
|
||||
|
||||
### Essential Build & Test Commands
|
||||
```bash
|
||||
# Build the MEV bot binary
|
||||
make build
|
||||
|
||||
# Run performance tests
|
||||
.gemini/scripts/perf-test.sh
|
||||
|
||||
# Run optimization analysis
|
||||
.gemini/scripts/optimize.sh
|
||||
|
||||
# Run benchmarks with profiling
|
||||
make bench-profile
|
||||
|
||||
# Run concurrency tests
|
||||
make test-concurrent
|
||||
|
||||
# Check for Go modules issues
|
||||
go mod tidy && go mod verify
|
||||
|
||||
# Run linter with performance focus
|
||||
golangci-lint run --fast
|
||||
```
|
||||
|
||||
### Development Workflow Commands
|
||||
```bash
|
||||
# Setup development environment
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export METRICS_ENABLED="true"
|
||||
|
||||
# Run with timeout for testing
|
||||
timeout 60 ./mev-bot start
|
||||
|
||||
# Debug with verbose logging
|
||||
LOG_LEVEL=debug ./mev-bot start
|
||||
|
||||
# Profile performance with detailed analysis
|
||||
.gemini/scripts/profile.sh
|
||||
```
|
||||
|
||||
## Gemini Commands Directory
|
||||
|
||||
The `.gemini/commands/` directory contains predefined commands for performance optimization tasks:
|
||||
|
||||
- `optimize-performance.md` - Optimize application performance
|
||||
- `analyze-bottlenecks.md` - Analyze performance bottlenecks
|
||||
- `tune-concurrency.md` - Tune concurrency patterns
|
||||
- `reduce-memory.md` - Reduce memory allocations
|
||||
- `improve-latency.md` - Improve latency performance
|
||||
|
||||
## Gemini Settings
|
||||
|
||||
The `.gemini/settings.json` file contains Gemini's performance optimization configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"focus_areas": [
|
||||
"Algorithmic Implementations",
|
||||
"Performance Optimization",
|
||||
"Concurrency Patterns",
|
||||
"Memory Management"
|
||||
],
|
||||
"primary_skills": [
|
||||
"Optimizing mathematical calculations for performance",
|
||||
"Profiling and identifying bottlenecks in critical paths",
|
||||
"Reducing memory allocations in hot code paths",
|
||||
"Optimizing concurrency patterns for maximum throughput"
|
||||
],
|
||||
"performance_optimization": {
|
||||
"enabled": true,
|
||||
"profiling": {
|
||||
"cpu": true,
|
||||
"memory": true,
|
||||
"goroutine": true,
|
||||
"mutex": true
|
||||
},
|
||||
"optimization_targets": [
|
||||
"Reduce latency to < 10 microseconds for critical path",
|
||||
"Achieve > 100,000 messages/second throughput",
|
||||
"Minimize memory allocations in hot paths",
|
||||
"Optimize garbage collection tuning"
|
||||
]
|
||||
},
|
||||
"concurrency": {
|
||||
"worker_pools": true,
|
||||
"pipeline_patterns": true,
|
||||
"fan_in_out": true,
|
||||
"backpressure_handling": true
|
||||
},
|
||||
"benchmarking": {
|
||||
"baseline_comparison": true,
|
||||
"regression_detection": true,
|
||||
"continuous_monitoring": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📋 Development Guidelines & Code Style
|
||||
|
||||
### Performance Optimization Guidelines
|
||||
- **Profiling First**: Always profile before optimizing
|
||||
- **Measure Impact**: Measure performance impact of changes
|
||||
- **Maintain Readability**: Don't sacrifice code readability for marginal gains
|
||||
- **Focus on Hot Paths**: Optimize critical code paths first
|
||||
- **Test Regressions**: Ensure optimizations don't cause regressions
|
||||
|
||||
### Concurrency Patterns
|
||||
- **Worker Pools**: Use worker pools for parallel processing
|
||||
- **Pipeline Patterns**: Implement pipeline patterns for multi-stage processing
|
||||
- **Fan-in/Fan-out**: Use fan-in/fan-out patterns for data distribution
|
||||
- **Backpressure Handling**: Implement proper backpressure handling
|
||||
|
||||
### Memory Management
|
||||
- **Object Pooling**: Use sync.Pool for frequently created objects
|
||||
- **Pre-allocation**: Pre-allocate slices and maps when size is known
|
||||
- **Minimize Allocations**: Reduce allocations in hot paths
|
||||
- **GC Tuning**: Properly tune garbage collection
|
||||
|
||||
### Required Checks Before Commit
|
||||
```bash
|
||||
# Run performance tests
|
||||
.gemini/scripts/perf-test.sh
|
||||
|
||||
# Run benchmark comparisons
|
||||
.gemini/scripts/bench-compare.sh
|
||||
|
||||
# Check for performance regressions
|
||||
.gemini/scripts/regression-check.sh
|
||||
```
|
||||
|
||||
## Gemini's Primary Focus Areas
|
||||
|
||||
As Gemini, you're particularly skilled at:
|
||||
|
||||
1. **Algorithmic Implementations and Mathematical Computations**
|
||||
- Implementing precise Uniswap V3 pricing functions
|
||||
- Optimizing mathematical calculations for performance
|
||||
- Ensuring numerical stability and precision
|
||||
- Creating efficient algorithms for arbitrage detection
|
||||
|
||||
2. **Optimizing Performance and Efficiency**
|
||||
- Profiling and identifying bottlenecks in critical paths
|
||||
- Reducing memory allocations in hot code paths
|
||||
- Optimizing concurrency patterns for maximum throughput
|
||||
- Tuning garbage collection for low-latency requirements
|
||||
|
||||
3. **Understanding Complex Uniswap V3 Pricing Functions**
|
||||
- Implementing accurate tick and sqrtPriceX96 conversions
|
||||
- Calculating price impact with proper precision handling
|
||||
- Working with liquidity and fee calculations
|
||||
- Handling edge cases in pricing mathematics
|
||||
|
||||
4. **Implementing Concurrent and Parallel Processing Patterns**
|
||||
- Designing efficient worker pool implementations
|
||||
- Creating robust pipeline processing systems
|
||||
- Managing synchronization primitives correctly
|
||||
- Preventing race conditions and deadlocks
|
||||
|
||||
5. **Working with Low-Level System Operations**
|
||||
- Optimizing memory usage and allocation patterns
|
||||
- Tuning system-level parameters for performance
|
||||
- Implementing efficient data structures for high-frequency access
|
||||
- Working with CPU cache optimization techniques
|
||||
|
||||
## 🛠 Gemini Optimization Settings
|
||||
|
||||
### Workflow Preferences
|
||||
- **Always profile first**: Use `go tool pprof` before making changes
|
||||
- **Branch naming**: Use prefixes (`perf-worker-pool`, `opt-pipeline`, `tune-gc`)
|
||||
- **Context management**: Focus on performance metrics and bottlenecks
|
||||
- **Continuous monitoring**: Implement monitoring for performance metrics
|
||||
|
||||
### File Organization Preferences
|
||||
- **Performance-critical code**: Place in `pkg/market/` or `pkg/monitor/`
|
||||
- **Benchmark files**: Place alongside source files with `_bench_test.go` suffix
|
||||
- **Profiling scripts**: Place in `.gemini/scripts/`
|
||||
- **Optimization documentation**: Inline comments explaining optimization approaches
|
||||
|
||||
### Performance Monitoring
|
||||
```bash
|
||||
# Enable detailed metrics endpoint
|
||||
export METRICS_ENABLED="true"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Monitor all performance aspects
|
||||
go tool pprof http://localhost:9090/debug/pprof/profile?seconds=30
|
||||
go tool pprof http://localhost:9090/debug/pprof/heap
|
||||
go tool pprof http://localhost:9090/debug/pprof/goroutine
|
||||
go tool pprof http://localhost:9090/debug/pprof/mutex
|
||||
|
||||
# Run comprehensive performance analysis
|
||||
.gemini/scripts/profile.sh
|
||||
```
|
||||
|
||||
## 🔧 Environment Configuration
|
||||
|
||||
### Required Environment Variables
|
||||
```bash
|
||||
# Arbitrum RPC Configuration
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
|
||||
# Application Configuration
|
||||
export LOG_LEVEL="info"
|
||||
export METRICS_ENABLED="true"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Development Configuration
|
||||
export GO_ENV="development"
|
||||
export DEBUG="true"
|
||||
|
||||
# Performance Configuration
|
||||
export GOGC=20
|
||||
export GOMAXPROCS=0
|
||||
export CONCURRENCY_LEVEL=100
|
||||
```
|
||||
|
||||
### Profiling Environment Variables
|
||||
```bash
|
||||
# Profiling Configuration
|
||||
export PROFILING_ENABLED=true
|
||||
export PROFILING_DURATION=30s
|
||||
export PROFILING_OUTPUT_DIR=".gemini/profiles"
|
||||
|
||||
# Benchmark Configuration
|
||||
export BENCHMARK_TIMEOUT=60s
|
||||
export BENCHMARK_ITERATIONS=1000000
|
||||
export BENCHMARK_CONCURRENCY=10
|
||||
```
|
||||
|
||||
## 📝 Commit Message Conventions
|
||||
|
||||
### Format
|
||||
```
|
||||
perf(type): brief description
|
||||
|
||||
- Detailed explanation of performance optimization
|
||||
- Measured impact of the change
|
||||
- Profiling data supporting the optimization
|
||||
|
||||
🤖 Generated with [Gemini](https://gemini.example.com)
|
||||
Co-Authored-By: Gemini <noreply@gemini.example.com>
|
||||
```
|
||||
|
||||
### Types
|
||||
- `worker-pool`: Worker pool optimizations
|
||||
- `pipeline`: Pipeline pattern optimizations
|
||||
- `memory`: Memory allocation reductions
|
||||
- `gc`: Garbage collection tuning
|
||||
- `concurrency`: Concurrency pattern improvements
|
||||
- `algorithm`: Algorithmic optimizations
|
||||
- `latency`: Latency improvements
|
||||
- `throughput`: Throughput improvements
|
||||
|
||||
## 🚨 Performance Guidelines
|
||||
|
||||
### Always Profile
|
||||
- Use `go tool pprof` to identify bottlenecks
|
||||
- Measure baseline performance before optimization
|
||||
- Compare performance before and after changes
|
||||
- Monitor for regressions in unrelated areas
|
||||
|
||||
### Focus Areas
|
||||
- **Critical Path**: Optimize the most time-consuming operations
|
||||
- **Hot Paths**: Reduce allocations in frequently called functions
|
||||
- **Concurrency**: Improve parallel processing efficiency
|
||||
- **Memory**: Minimize memory usage and GC pressure
|
||||
|
||||
### Testing Performance
|
||||
```bash
|
||||
# Run comprehensive performance tests
|
||||
.gemini/scripts/perf-test.sh
|
||||
|
||||
# Compare benchmarks
|
||||
.gemini/scripts/bench-compare.sh
|
||||
|
||||
# Check for regressions
|
||||
.gemini/scripts/regression-check.sh
|
||||
|
||||
# Generate flame graphs
|
||||
.gemini/scripts/flame-graph.sh
|
||||
```
|
||||
39
.gemini/commands/analyze-bottlenecks.md
Normal file
39
.gemini/commands/analyze-bottlenecks.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# Analyze Bottlenecks
|
||||
|
||||
Analyze performance bottlenecks in the following area: $ARGUMENTS
|
||||
|
||||
## Analysis Steps:
|
||||
1. **CPU Profiling**: Identify CPU-intensive functions and hot paths
|
||||
2. **Memory Profiling**: Check for memory leaks and high allocation patterns
|
||||
3. **Goroutine Analysis**: Look for goroutine leaks and blocking operations
|
||||
4. **I/O Performance**: Analyze network and disk I/O patterns
|
||||
5. **Concurrency Issues**: Check for race conditions and lock contention
|
||||
|
||||
## Profiling Commands:
|
||||
```bash
|
||||
# CPU profile with detailed analysis
|
||||
go tool pprof -top -cum http://localhost:9090/debug/pprof/profile?seconds=60
|
||||
|
||||
# Memory profile with allocation details
|
||||
go tool pprof -alloc_space http://localhost:9090/debug/pprof/heap
|
||||
|
||||
# Goroutine blocking profile
|
||||
go tool pprof http://localhost:9090/debug/pprof/block
|
||||
|
||||
# Mutex contention profile
|
||||
go tool pprof http://localhost:9090/debug/pprof/mutex
|
||||
```
|
||||
|
||||
## Analysis Focus Areas:
|
||||
- Worker pool efficiency in `pkg/market/pipeline.go`
|
||||
- Event parsing performance in `pkg/events/`
|
||||
- Uniswap math calculations in `pkg/uniswap/`
|
||||
- Memory usage in large transaction processing
|
||||
- Rate limiting effectiveness in `internal/ratelimit/`
|
||||
|
||||
## Output Requirements:
|
||||
- Detailed bottleneck analysis with percentages
|
||||
- Flame graphs and performance visualizations
|
||||
- Root cause identification for top bottlenecks
|
||||
- Optimization recommendations with expected impact
|
||||
- Priority ranking of issues
|
||||
51
.gemini/commands/improve-latency.md
Normal file
51
.gemini/commands/improve-latency.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# Improve Latency Performance
|
||||
|
||||
Improve latency performance for the following critical path: $ARGUMENTS
|
||||
|
||||
## Latency Optimization Strategy:
|
||||
|
||||
### 1. **Latency Analysis**
|
||||
- Measure current end-to-end latency
|
||||
- Identify latency components (network, computation, I/O)
|
||||
- Analyze latency distribution and outliers
|
||||
|
||||
### 2. **Optimization Areas**
|
||||
|
||||
#### **Network Latency**
|
||||
- Connection pooling for RPC calls
|
||||
- Request batching and pipelining
|
||||
- Caching frequently accessed data
|
||||
- Asynchronous processing patterns
|
||||
|
||||
#### **Computational Latency**
|
||||
- Algorithmic complexity reduction
|
||||
- Lookup table implementation
|
||||
- Parallel processing opportunities
|
||||
- Precision vs. performance trade-offs
|
||||
|
||||
#### **I/O Latency**
|
||||
- Buffering and streaming optimizations
|
||||
- Disk I/O patterns
|
||||
- Database query optimization
|
||||
- File system caching
|
||||
|
||||
### 3. **MEV Bot Specific Optimizations**
|
||||
|
||||
#### **Critical Path Components**
|
||||
- Transaction detection and parsing (< 10 microseconds target)
|
||||
- Market analysis and arbitrage calculation
|
||||
- Opportunity evaluation and ranking
|
||||
- Execution decision making
|
||||
|
||||
## Implementation Guidelines:
|
||||
- Measure latency at each component
|
||||
- Focus on 95th and 99th percentile improvements
|
||||
- Ensure deterministic performance characteristics
|
||||
- Maintain accuracy while improving speed
|
||||
|
||||
## Deliverables:
|
||||
- Latency benchmark results (before/after)
|
||||
- Latency distribution analysis
|
||||
- Optimization documentation
|
||||
- Monitoring and alerting for latency regressions
|
||||
- Performance vs. accuracy trade-off analysis
|
||||
68
.gemini/commands/optimize-performance.md
Normal file
68
.gemini/commands/optimize-performance.md
Normal file
@@ -0,0 +1,68 @@
|
||||
# Optimize Performance
|
||||
|
||||
Optimize the performance of the following component in the MEV bot: $ARGUMENTS
|
||||
|
||||
## Performance Optimization Strategy:
|
||||
|
||||
### 1. **Profiling and Measurement**
|
||||
```bash
|
||||
# CPU profiling
|
||||
go tool pprof http://localhost:9090/debug/pprof/profile?seconds=30
|
||||
|
||||
# Memory profiling
|
||||
go tool pprof http://localhost:9090/debug/pprof/heap
|
||||
|
||||
# Goroutine analysis
|
||||
go tool pprof http://localhost:9090/debug/pprof/goroutine
|
||||
|
||||
# Mutex contention analysis
|
||||
go tool pprof http://localhost:9090/debug/pprof/mutex
|
||||
```
|
||||
|
||||
### 2. **Optimization Areas**
|
||||
|
||||
#### **Concurrency Optimization**
|
||||
- Worker pool sizing and configuration
|
||||
- Channel buffer optimization
|
||||
- Goroutine pooling and reuse
|
||||
- Lock contention reduction
|
||||
- Context cancellation patterns
|
||||
|
||||
#### **Memory Optimization**
|
||||
- Object pooling for frequent allocations
|
||||
- Buffer reuse patterns
|
||||
- Garbage collection tuning
|
||||
- Memory leak prevention
|
||||
- Slice and map pre-allocation
|
||||
|
||||
#### **Algorithm Optimization**
|
||||
- Computational complexity reduction
|
||||
- Data structure selection
|
||||
- Caching strategies
|
||||
- Lookup table implementation
|
||||
|
||||
### 3. **MEV Bot Specific Optimizations**
|
||||
|
||||
#### **Transaction Processing**
|
||||
- Parallel transaction processing
|
||||
- Event filtering optimization
|
||||
- Batch processing strategies
|
||||
|
||||
#### **Market Analysis**
|
||||
- Price calculation caching
|
||||
- Pool data caching
|
||||
- Historical data indexing
|
||||
|
||||
## Implementation Guidelines:
|
||||
- Measure before optimizing (baseline metrics)
|
||||
- Focus on bottlenecks identified through profiling
|
||||
- Maintain code readability and maintainability
|
||||
- Add performance tests for regressions
|
||||
- Document performance characteristics
|
||||
|
||||
## Deliverables:
|
||||
- Performance benchmark results (before/after)
|
||||
- Optimized code with maintained functionality
|
||||
- Performance monitoring enhancements
|
||||
- Optimization documentation
|
||||
- Regression test suite
|
||||
52
.gemini/commands/reduce-memory.md
Normal file
52
.gemini/commands/reduce-memory.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# Reduce Memory Allocations
|
||||
|
||||
Reduce memory allocations in the following hot path: $ARGUMENTS
|
||||
|
||||
## Memory Optimization Strategy:
|
||||
|
||||
### 1. **Allocation Analysis**
|
||||
- Identify high-frequency allocation points
|
||||
- Measure current allocation rates and patterns
|
||||
- Analyze garbage collection pressure
|
||||
|
||||
### 2. **Optimization Techniques**
|
||||
|
||||
#### **Object Pooling**
|
||||
- Implement sync.Pool for frequently created objects
|
||||
- Pool buffers, structs, and temporary objects
|
||||
- Proper reset patterns for pooled objects
|
||||
|
||||
#### **Pre-allocation**
|
||||
- Pre-allocate slices and maps when size is predictable
|
||||
- Reuse existing data structures
|
||||
- Avoid repeated allocations in loops
|
||||
|
||||
#### **Buffer Reuse**
|
||||
- Reuse byte buffers and string builders
|
||||
- Implement buffer pools for I/O operations
|
||||
- Minimize string concatenation
|
||||
|
||||
### 3. **MEV Bot Specific Optimizations**
|
||||
|
||||
#### **Transaction Processing**
|
||||
- Pool transaction objects and event structures
|
||||
- Reuse parsing buffers
|
||||
- Optimize log and metric object creation
|
||||
|
||||
#### **Mathematical Calculations**
|
||||
- Pool uint256 and big.Int objects
|
||||
- Reuse temporary calculation buffers
|
||||
- Optimize precision object handling
|
||||
|
||||
## Implementation Guidelines:
|
||||
- Measure allocation reduction with benchmarks
|
||||
- Monitor garbage collection statistics
|
||||
- Ensure thread safety in pooled objects
|
||||
- Maintain code readability and maintainability
|
||||
|
||||
## Deliverables:
|
||||
- Memory allocation reduction benchmarks
|
||||
- Optimized code with pooling strategies
|
||||
- GC pressure analysis before and after
|
||||
- Memory usage monitoring enhancements
|
||||
- Best practices documentation for team
|
||||
55
.gemini/commands/tune-concurrency.md
Normal file
55
.gemini/commands/tune-concurrency.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# Tune Concurrency Patterns
|
||||
|
||||
Tune concurrency patterns for the following component: $ARGUMENTS
|
||||
|
||||
## Concurrency Tuning Strategy:
|
||||
|
||||
### 1. **Current Pattern Analysis**
|
||||
- Identify existing concurrency patterns (worker pools, pipelines, etc.)
|
||||
- Measure current performance and resource utilization
|
||||
- Analyze bottlenecks in concurrent processing
|
||||
|
||||
### 2. **Optimization Areas**
|
||||
|
||||
#### **Worker Pool Tuning**
|
||||
- Optimal worker count based on CPU cores and workload
|
||||
- Channel buffer sizing for backpressure management
|
||||
- Task distribution strategies
|
||||
- Worker lifecycle management
|
||||
|
||||
#### **Pipeline Optimization**
|
||||
- Stage balancing to prevent bottlenecks
|
||||
- Buffer sizing between pipeline stages
|
||||
- Error propagation and recovery
|
||||
- Context cancellation handling
|
||||
|
||||
#### **Fan-in/Fan-out Patterns**
|
||||
- Optimal fan-out ratios
|
||||
- Result merging strategies
|
||||
- Resource allocation across branches
|
||||
- Synchronization mechanisms
|
||||
|
||||
### 3. **MEV Bot Specific Tuning**
|
||||
|
||||
#### **Transaction Processing**
|
||||
- Optimal concurrent transaction processing
|
||||
- Event parsing parallelization
|
||||
- Memory usage per goroutine
|
||||
|
||||
#### **Market Analysis**
|
||||
- Concurrent pool data fetching
|
||||
- Parallel arbitrage calculations
|
||||
- Resource sharing between analysis tasks
|
||||
|
||||
## Implementation Guidelines:
|
||||
- Test with realistic workload patterns
|
||||
- Monitor resource utilization (CPU, memory, goroutines)
|
||||
- Ensure graceful degradation under load
|
||||
- Maintain error handling and recovery mechanisms
|
||||
|
||||
## Deliverables:
|
||||
- Concurrency tuning recommendations
|
||||
- Performance benchmarks with different configurations
|
||||
- Resource utilization analysis
|
||||
- Configuration guidelines for different environments
|
||||
- Monitoring and alerting for concurrency issues
|
||||
42
.gemini/scripts/perf-test.sh
Executable file
42
.gemini/scripts/perf-test.sh
Executable file
@@ -0,0 +1,42 @@
|
||||
#!/bin/bash
|
||||
|
||||
# perf-test.sh - Run comprehensive performance tests for Gemini
|
||||
|
||||
echo "Running comprehensive performance tests for Gemini..."
|
||||
|
||||
# Create results directory if it doesn't exist
|
||||
mkdir -p .gemini/results
|
||||
|
||||
# Run unit tests
|
||||
echo "Running unit tests..."
|
||||
go test -v ./... | tee .gemini/results/unit-tests.log
|
||||
|
||||
# Run concurrency tests
|
||||
echo "Running concurrency tests..."
|
||||
go test -v -run=Concurrent ./... | tee .gemini/results/concurrency-tests.log
|
||||
|
||||
# Run benchmarks
|
||||
echo "Running benchmarks..."
|
||||
go test -bench=. -benchmem ./... | tee .gemini/results/benchmarks.log
|
||||
|
||||
# Run benchmarks with CPU profiling
|
||||
echo "Running benchmarks with CPU profiling..."
|
||||
go test -bench=. -cpuprofile=.gemini/results/cpu.prof ./... | tee .gemini/results/cpu-bench.log
|
||||
|
||||
# Run benchmarks with memory profiling
|
||||
echo "Running benchmarks with memory profiling..."
|
||||
go test -bench=. -memprofile=.gemini/results/mem.prof ./... | tee .gemini/results/mem-bench.log
|
||||
|
||||
# Run benchmarks with goroutine profiling
|
||||
echo "Running benchmarks with goroutine profiling..."
|
||||
go test -bench=. -blockprofile=.gemini/results/block.prof ./... | tee .gemini/results/block-bench.log
|
||||
|
||||
# Check for errors
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "All performance tests completed successfully!"
|
||||
echo "Results saved to .gemini/results/"
|
||||
else
|
||||
echo "Some performance tests failed!"
|
||||
echo "Check .gemini/results/ for details"
|
||||
exit 1
|
||||
fi
|
||||
288
.opencode/OPENCODE.md
Normal file
288
.opencode/OPENCODE.md
Normal file
@@ -0,0 +1,288 @@
|
||||
# OpenCode CLI Configuration
|
||||
|
||||
This directory contains OpenCode configuration and tools for the MEV Bot project.
|
||||
|
||||
## 🚀 Quick Start Commands
|
||||
|
||||
### Essential Build & Test Commands
|
||||
```bash
|
||||
# Build the MEV bot binary
|
||||
make build
|
||||
|
||||
# Run all tests
|
||||
make test
|
||||
|
||||
# Run tests with coverage
|
||||
make test-coverage
|
||||
|
||||
# Run unit tests
|
||||
make test-unit
|
||||
|
||||
# Run integration tests
|
||||
make test-integration
|
||||
|
||||
# Run end-to-end tests
|
||||
make test-e2e
|
||||
|
||||
# Check for Go modules issues
|
||||
go mod tidy && go mod verify
|
||||
|
||||
# Run linter
|
||||
make lint
|
||||
|
||||
# Run security analysis
|
||||
make security-audit
|
||||
```
|
||||
|
||||
### Development Workflow Commands
|
||||
```bash
|
||||
# Setup development environment
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export METRICS_ENABLED="false"
|
||||
|
||||
# Run with timeout for testing
|
||||
timeout 30 ./mev-bot start
|
||||
|
||||
# Debug with verbose logging
|
||||
LOG_LEVEL=debug ./mev-bot start
|
||||
|
||||
# Profile performance
|
||||
go tool pprof http://localhost:6060/debug/pprof/profile
|
||||
```
|
||||
|
||||
## OpenCode Commands Directory
|
||||
|
||||
The `.opencode/commands/` directory contains predefined commands for common development tasks:
|
||||
|
||||
- `implement-feature.md` - Implement new features with test coverage
|
||||
- `debug-code.md` - Debug issues in the codebase
|
||||
- `refactor-code.md` - Refactor existing code for better quality
|
||||
- `write-tests.md` - Write comprehensive tests
|
||||
- `code-review.md` - Perform code reviews
|
||||
|
||||
## OpenCode Settings
|
||||
|
||||
The `.opencode/settings.json` file contains OpenCode's configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"languages": {
|
||||
"go": {
|
||||
"version": "1.24+",
|
||||
"testing_framework": "testing",
|
||||
"linting_tools": ["golangci-lint", "go vet", "go fmt"],
|
||||
"coverage_target": 90
|
||||
},
|
||||
"solidity": {
|
||||
"version": "^0.8.24",
|
||||
"testing_framework": "hardhat",
|
||||
"linting_tools": ["solhint", "slither"],
|
||||
"coverage_target": 95
|
||||
},
|
||||
"javascript": {
|
||||
"version": "LTS",
|
||||
"frameworks": ["vue", "vue-router", "pinia", "helia", "viem"],
|
||||
"testing_framework": "vitest",
|
||||
"linting_tools": ["eslint", "prettier"]
|
||||
}
|
||||
},
|
||||
"testing": {
|
||||
"unit_test_coverage": 90,
|
||||
"integration_test_coverage": 80,
|
||||
"property_based_testing": true,
|
||||
"fuzz_testing": true,
|
||||
"benchmarking": true
|
||||
},
|
||||
"quality": {
|
||||
"linting": true,
|
||||
"security_scanning": true,
|
||||
"dependency_checking": true,
|
||||
"documentation_required": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📋 Development Guidelines & Code Style
|
||||
|
||||
### Go Best Practices (1.24+)
|
||||
- **Error Handling**: Use Go's error wrapping with context: `fmt.Errorf("failed to process transaction: %w", err)`
|
||||
- **Concurrency Safety**: Use mutexes correctly to protect shared data
|
||||
- **Code Structure**: Follow idiomatic Go patterns and conventions
|
||||
- **Testing**: Write tests for all functions and methods with >90% coverage
|
||||
- **Performance**: Minimize memory allocations in hot paths
|
||||
|
||||
### Solidity Best Practices (^0.8.24)
|
||||
- **Security**: Implement proper access controls and validation
|
||||
- **Gas Optimization**: Optimize for minimal gas consumption
|
||||
- **Upgradeability**: Consider upgradeable contract patterns
|
||||
- **Testing**: Achieve >95% test coverage with property-based tests
|
||||
- **Documentation**: Document all public functions with NatSpec
|
||||
|
||||
### JavaScript/TypeScript Best Practices (Vue 3, Vue Router, Pinia, Helia, Viem)
|
||||
- **Component Design**: Use Vue 3 Composition API
|
||||
- **State Management**: Implement proper state management with Pinia
|
||||
- **Routing**: Follow Vue Router best practices
|
||||
- **P2P Integration**: Use Helia for decentralized data sharing
|
||||
- **Web3 Integration**: Integrate Viem for efficient Ethereum interactions
|
||||
|
||||
### Required Checks Before Commit
|
||||
```bash
|
||||
# Run all checks before committing
|
||||
make test && make lint && go mod tidy
|
||||
|
||||
# Security scan
|
||||
make security-audit
|
||||
|
||||
# Dependency vulnerability check
|
||||
make dependency-check
|
||||
```
|
||||
|
||||
## OpenCode's Primary Focus Areas
|
||||
|
||||
As OpenCode, you're particularly skilled at:
|
||||
|
||||
1. **Writing and Debugging Code**
|
||||
- Implementing clean, idiomatic code in Go, Solidity, and JavaScript
|
||||
- Debugging complex concurrency issues
|
||||
- Optimizing code for performance and readability
|
||||
|
||||
2. **Implementing Test Cases and Ensuring Code Quality**
|
||||
- Writing comprehensive unit and integration tests
|
||||
- Implementing property-based tests for mathematical functions
|
||||
- Creating performance benchmarks for critical paths
|
||||
|
||||
3. **Following Established Coding Patterns and Conventions**
|
||||
- Using appropriate design patterns for each language
|
||||
- Following idiomatic patterns and best practices
|
||||
- Implementing consistent error handling and logging
|
||||
|
||||
4. **Identifying and Fixing Bugs**
|
||||
- Debugging race conditions and concurrency issues
|
||||
- Identifying performance bottlenecks
|
||||
- Fixing precision errors in mathematical calculations
|
||||
|
||||
5. **Ensuring Code is Well-Structured and Readable**
|
||||
- Organizing code into logical packages with clear responsibilities
|
||||
- Using clear, descriptive naming conventions
|
||||
- Implementing proper abstraction and encapsulation
|
||||
|
||||
## 🛠 OpenCode Optimization Settings
|
||||
|
||||
### Workflow Preferences
|
||||
- **Always commit changes**: Use `git commit -am "descriptive message"` after significant changes
|
||||
- **Branch naming**: Use hyphens (`feat-add-new-parser`, `fix-memory-leak`)
|
||||
- **Context management**: Use `/compact` to manage long conversations
|
||||
- **Testing first**: Always write tests before implementation
|
||||
|
||||
### File Organization Preferences
|
||||
- **Go files**: Follow standard Go layout (cmd/, internal/, pkg/)
|
||||
- **Solidity files**: Place in `contracts/` directory with separate test files
|
||||
- **JavaScript files**: Follow Vue 3 project structure with components, views, and stores
|
||||
- **Test files**: Place alongside source files with appropriate suffixes
|
||||
|
||||
### Quality Assurance
|
||||
```bash
|
||||
# Run comprehensive test suite
|
||||
make test-all
|
||||
|
||||
# Run security audits
|
||||
make security-full
|
||||
|
||||
# Check code quality
|
||||
make quality-check
|
||||
|
||||
# Generate documentation
|
||||
make docs
|
||||
```
|
||||
|
||||
## 🔧 Environment Configuration
|
||||
|
||||
### Required Environment Variables
|
||||
```bash
|
||||
# Arbitrum RPC Configuration
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
|
||||
# Application Configuration
|
||||
export LOG_LEVEL="info"
|
||||
export METRICS_ENABLED="false"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Development Configuration
|
||||
export GO_ENV="development"
|
||||
export DEBUG="true"
|
||||
|
||||
# Frontend Configuration
|
||||
export VITE_APP_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
```
|
||||
|
||||
### Testing Environment Variables
|
||||
```bash
|
||||
# Test Configuration
|
||||
export TEST_COVERAGE_TARGET=90
|
||||
export TEST_TIMEOUT=30s
|
||||
export TEST_PARALLEL=4
|
||||
|
||||
# Solidity Testing
|
||||
export HARDHAT_NETWORK="hardhat"
|
||||
export FORKING_URL="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
```
|
||||
|
||||
## 📝 Commit Message Conventions
|
||||
|
||||
### Format
|
||||
```
|
||||
type(scope): brief description
|
||||
|
||||
- Detailed explanation of changes
|
||||
- Why the change was needed
|
||||
- Any breaking changes or migration notes
|
||||
|
||||
🤖 Generated with [OpenCode](https://opencode.example.com)
|
||||
Co-Authored-By: OpenCode <noreply@opencode.example.com>
|
||||
```
|
||||
|
||||
### Types
|
||||
- `feat`: New feature implementation
|
||||
- `fix`: Bug fix
|
||||
- `perf`: Performance improvement
|
||||
- `refactor`: Code restructuring without feature changes
|
||||
- `test`: Adding or updating tests
|
||||
- `docs`: Documentation updates
|
||||
- `build`: Build system or dependency changes
|
||||
- `ci`: CI/CD pipeline changes
|
||||
- `contract`: Smart contract changes
|
||||
- `frontend`: Frontend/UI changes
|
||||
|
||||
## 🚨 Security Guidelines
|
||||
|
||||
### Never Commit
|
||||
- Private keys or wallet seeds
|
||||
- API keys or secrets
|
||||
- RPC endpoints with authentication
|
||||
- Personal configuration files
|
||||
|
||||
### Always Validate
|
||||
- Input parameters for all functions
|
||||
- Smart contract inputs and state changes
|
||||
- Web3 interactions and transactions
|
||||
- Memory allocations for bounds
|
||||
|
||||
### Security Commands
|
||||
```bash
|
||||
# Scan for secrets
|
||||
git-secrets --scan
|
||||
|
||||
# Security audit for Go code
|
||||
gosec ./...
|
||||
|
||||
# Security audit for Solidity contracts
|
||||
slither .
|
||||
|
||||
# Dependency vulnerabilities
|
||||
go list -json -m all | nancy sleuth
|
||||
|
||||
# Check for hardcoded credentials
|
||||
grep -r "password\|secret\|key" --exclude-dir=.git .
|
||||
```
|
||||
70
.opencode/commands/code-review.md
Normal file
70
.opencode/commands/code-review.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# Perform Code Review
|
||||
|
||||
Perform a comprehensive code review for the following changes: $ARGUMENTS
|
||||
|
||||
## Code Review Framework:
|
||||
1. **Functional Review**: Verify code correctness and requirements implementation
|
||||
2. **Quality Review**: Assess code quality, readability, and maintainability
|
||||
3. **Security Review**: Identify potential security vulnerabilities
|
||||
4. **Performance Review**: Evaluate performance implications
|
||||
5. **Testing Review**: Check test coverage and quality
|
||||
|
||||
## Review Standards:
|
||||
|
||||
### Go Code Review
|
||||
- **Error Handling**: Proper error wrapping and handling
|
||||
- **Concurrency**: Correct use of goroutines, channels, and mutexes
|
||||
- **Interfaces**: Appropriate interface design and usage
|
||||
- **Documentation**: Clear comments and godoc compliance
|
||||
- **Testing**: Adequate test coverage and quality
|
||||
|
||||
### Solidity Code Review
|
||||
- **Security**: Reentrancy, overflow/underflow, access controls
|
||||
- **Gas Optimization**: Efficient use of gas and state variables
|
||||
- **Best Practices**: Follow Solidity and DeFi security best practices
|
||||
- **Documentation**: Proper NatSpec comments
|
||||
- **Testing**: Comprehensive test coverage
|
||||
|
||||
### JavaScript Code Review
|
||||
- **Vue Patterns**: Proper use of Composition API and reactivity
|
||||
- **State Management**: Correct Pinia usage and state handling
|
||||
- **Web3 Integration**: Secure and efficient web3 interactions
|
||||
- **Performance**: Optimal component rendering and data fetching
|
||||
- **Testing**: Adequate Vue component and unit tests
|
||||
|
||||
## Review Checklist:
|
||||
|
||||
### General
|
||||
- [ ] Code follows project style guidelines
|
||||
- [ ] Naming conventions are consistent and meaningful
|
||||
- [ ] Code is well-documented with comments
|
||||
- [ ] No dead or commented-out code
|
||||
- [ ] Dependencies are properly managed
|
||||
|
||||
### Security
|
||||
- [ ] Input validation is implemented
|
||||
- [ ] Sensitive data is handled securely
|
||||
- [ ] No hardcoded secrets or credentials
|
||||
- [ ] Proper access controls are in place
|
||||
- [ ] Security best practices are followed
|
||||
|
||||
### Performance
|
||||
- [ ] No obvious performance bottlenecks
|
||||
- [ ] Memory usage is optimized
|
||||
- [ ] Database queries are efficient
|
||||
- [ ] Caching strategies are appropriate
|
||||
- [ ] Concurrency patterns are efficient
|
||||
|
||||
### Testing
|
||||
- [ ] Adequate test coverage
|
||||
- [ ] Tests are well-structured and readable
|
||||
- [ ] Edge cases are covered
|
||||
- [ ] Mocks and stubs are used appropriately
|
||||
- [ ] Performance tests are included for critical paths
|
||||
|
||||
## Output Requirements:
|
||||
- Detailed feedback with specific line references
|
||||
- Priority levels for issues (Critical/High/Medium/Low)
|
||||
- Suggestions for improvements
|
||||
- Approval or rejection recommendation
|
||||
- Follow-up actions if needed
|
||||
38
.opencode/commands/debug-code.md
Normal file
38
.opencode/commands/debug-code.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Debug Code Issues
|
||||
|
||||
Debug the following code issues: $ARGUMENTS
|
||||
|
||||
## Debugging Protocol:
|
||||
1. **Issue Understanding**: Analyze the problem description and expected vs actual behavior
|
||||
2. **Log Analysis**: Examine relevant log files and error messages
|
||||
3. **Code Investigation**: Review related source code and recent changes
|
||||
4. **Reproduction**: Attempt to reproduce the issue in a controlled environment
|
||||
5. **Root Cause**: Identify the underlying cause and contributing factors
|
||||
|
||||
## Debugging Commands:
|
||||
```bash
|
||||
# For Go backend
|
||||
go run -race ./cmd/mev-bot
|
||||
LOG_LEVEL=debug ./mev-bot start
|
||||
|
||||
# For Solidity contracts
|
||||
npx hardhat test
|
||||
forge test -vvv
|
||||
|
||||
# For Frontend
|
||||
npm run dev
|
||||
npm run test:unit
|
||||
```
|
||||
|
||||
## Investigation Areas:
|
||||
- **Go Backend**: Concurrency issues, memory leaks, parsing errors
|
||||
- **Solidity Contracts**: Gas issues, reentrancy, overflow/underflow
|
||||
- **Frontend**: Vue component issues, state management, web3 integration
|
||||
- **Integration**: API communication, contract interactions, data flow
|
||||
|
||||
## Output Requirements:
|
||||
- Clear problem identification with code references
|
||||
- Step-by-step reproduction instructions
|
||||
- Root cause analysis with technical details
|
||||
- Proposed solution with implementation steps
|
||||
- Test plan to verify the fix
|
||||
39
.opencode/commands/implement-feature.md
Normal file
39
.opencode/commands/implement-feature.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# Implement Feature with Tests
|
||||
|
||||
Implement the following feature with comprehensive tests: $ARGUMENTS
|
||||
|
||||
## Implementation Framework:
|
||||
1. **Requirements Analysis**: Break down the feature requirements and acceptance criteria
|
||||
2. **Test Planning**: Design test cases before implementation
|
||||
3. **Interface Design**: Define clean interfaces between components
|
||||
4. **Implementation**: Write the code following language best practices
|
||||
5. **Testing**: Create comprehensive unit, integration, and property-based tests
|
||||
6. **Documentation**: Update relevant documentation and examples
|
||||
|
||||
## Implementation Standards:
|
||||
- **Code Quality**: Follow language conventions and project coding standards
|
||||
- **Error Handling**: Implement robust error handling with context
|
||||
- **Logging**: Add appropriate logging with structured fields
|
||||
- **Testing**: Achieve >90% test coverage for Go, >95% for Solidity
|
||||
- **Performance**: Consider performance implications and add metrics
|
||||
- **Security**: Validate all inputs and handle edge cases
|
||||
|
||||
## File Organization:
|
||||
- **Go Code**: Place in appropriate `pkg/` or `internal/` subdirectory
|
||||
- **Solidity Contracts**: Place in `contracts/` directory
|
||||
- **Frontend Code**: Follow Vue 3 project structure
|
||||
- **Tests**: Co-locate with source files (`*_test.go`, `.test.js`, etc.)
|
||||
- **Documentation**: Update `docs/` and inline comments
|
||||
|
||||
## Integration Points:
|
||||
- **Backend**: Integrate with existing Go components
|
||||
- **Smart Contracts**: Ensure proper contract interaction
|
||||
- **Frontend**: Connect to backend APIs and web3 providers
|
||||
- **Monitoring**: Add metrics and health checks
|
||||
|
||||
## Deliverables:
|
||||
- Working implementation with tests
|
||||
- Updated documentation
|
||||
- Configuration updates
|
||||
- Performance benchmarks if applicable
|
||||
- Migration guide for existing deployments
|
||||
50
.opencode/commands/refactor-code.md
Normal file
50
.opencode/commands/refactor-code.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# Refactor Code for Quality
|
||||
|
||||
Refactor the following code for better quality: $ARGUMENTS
|
||||
|
||||
## Refactoring Framework:
|
||||
1. **Code Analysis**: Identify code smells, duplication, and complexity
|
||||
2. **Design Review**: Evaluate architecture and design patterns
|
||||
3. **Implementation**: Apply refactoring techniques
|
||||
4. **Testing**: Ensure refactored code maintains functionality
|
||||
5. **Documentation**: Update documentation to reflect changes
|
||||
|
||||
## Refactoring Standards:
|
||||
- **SOLID Principles**: Apply Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
|
||||
- **DRY Principle**: Eliminate duplication
|
||||
- **KISS Principle**: Keep it simple and straightforward
|
||||
- **YAGNI Principle**: Don't implement unnecessary features
|
||||
- **Code Readability**: Improve code clarity and maintainability
|
||||
|
||||
## Language-Specific Guidelines:
|
||||
|
||||
### Go Refactoring
|
||||
- Simplify complex functions and reduce cyclomatic complexity
|
||||
- Improve error handling patterns
|
||||
- Optimize struct and interface design
|
||||
- Enhance concurrency patterns
|
||||
|
||||
### Solidity Refactoring
|
||||
- Optimize gas consumption
|
||||
- Improve contract upgradeability
|
||||
- Enhance security patterns
|
||||
- Simplify complex contract interactions
|
||||
|
||||
### JavaScript/TypeScript Refactoring
|
||||
- Apply Vue 3 Composition API patterns
|
||||
- Improve component organization
|
||||
- Optimize state management with Pinia
|
||||
- Enhance web3 integration patterns
|
||||
|
||||
## Testing Requirements:
|
||||
- Maintain existing test coverage
|
||||
- Add tests for newly introduced patterns
|
||||
- Verify no functionality regression
|
||||
- Update benchmarks if performance is affected
|
||||
|
||||
## Deliverables:
|
||||
- Refactored code with improved quality
|
||||
- Updated tests
|
||||
- Performance comparison (if applicable)
|
||||
- Documentation updates
|
||||
- Refactoring rationale and benefits
|
||||
73
.opencode/commands/write-tests.md
Normal file
73
.opencode/commands/write-tests.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# Write Comprehensive Tests
|
||||
|
||||
Write comprehensive tests for the following functionality: $ARGUMENTS
|
||||
|
||||
## Testing Framework:
|
||||
1. **Test Planning**: Design test cases for all scenarios
|
||||
2. **Unit Testing**: Implement unit tests with high coverage
|
||||
3. **Integration Testing**: Create integration tests for component interactions
|
||||
4. **Property-Based Testing**: Implement property-based tests for mathematical functions
|
||||
5. **Fuzz Testing**: Add fuzz tests for edge cases
|
||||
6. **Benchmark Testing**: Create benchmarks for performance-critical code
|
||||
|
||||
## Testing Standards:
|
||||
- **Coverage Targets**: >90% for Go, >95% for Solidity, >85% for JavaScript
|
||||
- **Test Organization**: Follow language-specific testing conventions
|
||||
- **Test Data**: Use realistic test data and edge cases
|
||||
- **Test Documentation**: Document test scenarios and expected outcomes
|
||||
|
||||
## Language-Specific Testing:
|
||||
|
||||
### Go Testing
|
||||
```go
|
||||
// Unit tests with table-driven approach
|
||||
func TestFunctionName(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
input InputType
|
||||
expected OutputType
|
||||
wantErr bool
|
||||
}{
|
||||
// Test cases
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
// Test implementation
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Solidity Testing
|
||||
```solidity
|
||||
// Property-based testing with Foundry
|
||||
function testFuzz_ValidInputs_AlwaysWork(uint256 amount) public {
|
||||
vm.assume(amount > 0 && amount < type(uint128).max);
|
||||
// Test implementation
|
||||
}
|
||||
```
|
||||
|
||||
### JavaScript Testing
|
||||
```javascript
|
||||
// Vue component testing with Vitest
|
||||
describe('ComponentName', () => {
|
||||
it('should render correctly', () => {
|
||||
// Test implementation
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Test Categories:
|
||||
- **Happy Path**: Tests for expected normal operation
|
||||
- **Edge Cases**: Tests for boundary conditions
|
||||
- **Error Conditions**: Tests for error handling
|
||||
- **Security**: Tests for potential vulnerabilities
|
||||
- **Performance**: Benchmarks for critical functions
|
||||
|
||||
## Deliverables:
|
||||
- Comprehensive test suite with high coverage
|
||||
- Property-based tests for mathematical functions
|
||||
- Fuzz tests for edge cases
|
||||
- Benchmark tests for performance-critical code
|
||||
- Test documentation and scenarios
|
||||
38
.opencode/scripts/test-all.sh
Executable file
38
.opencode/scripts/test-all.sh
Executable file
@@ -0,0 +1,38 @@
|
||||
#!/bin/bash
|
||||
|
||||
# test-all.sh - Run comprehensive tests for OpenCode
|
||||
|
||||
echo "Running comprehensive tests for OpenCode..."
|
||||
|
||||
# Create results directory if it doesn't exist
|
||||
mkdir -p .opencode/results
|
||||
|
||||
# Run Go unit tests
|
||||
echo "Running Go unit tests..."
|
||||
go test -v ./... | tee .opencode/results/go-unit-tests.log
|
||||
|
||||
# Run Go integration tests
|
||||
echo "Running Go integration tests..."
|
||||
go test -v ./test/integration/... | tee .opencode/results/go-integration-tests.log
|
||||
|
||||
# Run Go property-based tests
|
||||
echo "Running Go property-based tests..."
|
||||
go test -v -run=Property ./... | tee .opencode/results/go-property-tests.log
|
||||
|
||||
# Run Go fuzz tests (limited time)
|
||||
echo "Running Go fuzz tests (60 seconds)..."
|
||||
timeout 60s go test -fuzz=Fuzz ./... | tee .opencode/results/go-fuzz-tests.log
|
||||
|
||||
# Run Go benchmarks
|
||||
echo "Running Go benchmarks..."
|
||||
go test -bench=. -benchmem ./... | tee .opencode/results/go-benchmarks.log
|
||||
|
||||
# Check for errors
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "All tests completed successfully!"
|
||||
echo "Results saved to .opencode/results/"
|
||||
else
|
||||
echo "Some tests failed!"
|
||||
echo "Check .opencode/results/ for details"
|
||||
exit 1
|
||||
fi
|
||||
275
.qwen/QWEN.md
Normal file
275
.qwen/QWEN.md
Normal file
@@ -0,0 +1,275 @@
|
||||
# Qwen Code CLI Configuration
|
||||
|
||||
This directory contains Qwen Code configuration and tools for the MEV Bot project.
|
||||
|
||||
## 🚀 Quick Start Commands
|
||||
|
||||
### Essential Build & Test Commands
|
||||
```bash
|
||||
# Build the MEV bot binary
|
||||
make build
|
||||
|
||||
# Run mathematical function tests
|
||||
.qwen/scripts/math-test.sh
|
||||
|
||||
# Run mathematical optimization analysis
|
||||
.qwen/scripts/math-optimize.sh
|
||||
|
||||
# Run benchmarks for mathematical functions
|
||||
make bench-math
|
||||
|
||||
# Run property-based tests
|
||||
make test-property
|
||||
|
||||
# Check for Go modules issues
|
||||
go mod tidy && go mod verify
|
||||
|
||||
# Run linter on mathematical functions
|
||||
golangci-lint run ./pkg/uniswap/... ./pkg/math/...
|
||||
```
|
||||
|
||||
### Development Workflow Commands
|
||||
```bash
|
||||
# Setup development environment
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export METRICS_ENABLED="false"
|
||||
|
||||
# Run with timeout for testing
|
||||
timeout 30 ./mev-bot start
|
||||
|
||||
# Debug with verbose logging
|
||||
LOG_LEVEL=debug ./mev-bot start
|
||||
|
||||
# Profile performance
|
||||
go tool pprof http://localhost:6060/debug/pprof/profile
|
||||
```
|
||||
|
||||
## Qwen Commands Directory
|
||||
|
||||
The `.qwen/commands/` directory contains predefined commands for mathematical development tasks:
|
||||
|
||||
- `implement-algorithm.md` - Implement mathematical algorithms with precision
|
||||
- `optimize-math.md` - Optimize mathematical performance
|
||||
- `verify-precision.md` - Verify mathematical precision and correctness
|
||||
|
||||
## Qwen Settings
|
||||
|
||||
The `.qwen/settings.json` file contains Qwen's mathematical computation configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"focus_areas": [
|
||||
"Mathematical Computations",
|
||||
"Algorithmic Implementation",
|
||||
"Precision Handling",
|
||||
"Performance Optimization"
|
||||
],
|
||||
"primary_skills": [
|
||||
"Implementing precise Uniswap V3 pricing functions",
|
||||
"Ensuring numerical stability and precision",
|
||||
"Working with liquidity and fee calculations",
|
||||
"Creating efficient algorithms for arbitrage detection",
|
||||
"Implementing accurate tick and sqrtPriceX96 conversions",
|
||||
"Calculating price impact with proper precision handling"
|
||||
],
|
||||
"performance_optimization": {
|
||||
"enabled": true,
|
||||
"profiling": {
|
||||
"cpu": true,
|
||||
"memory": true,
|
||||
"goroutine": true
|
||||
},
|
||||
"optimization_targets": [
|
||||
"Minimize memory allocations in hot paths",
|
||||
"Optimize uint256 arithmetic operations",
|
||||
"Reduce garbage collection pressure",
|
||||
"Improve mathematical computation efficiency"
|
||||
]
|
||||
},
|
||||
"precision_requirements": {
|
||||
"math_library": "github.com/holiman/uint256",
|
||||
"floating_point": "math/big",
|
||||
"rounding_strategy": "bankers_rounding",
|
||||
"precision_target": "256_bits"
|
||||
},
|
||||
"testing": {
|
||||
"unit_test_coverage": 95,
|
||||
"property_based_testing": true,
|
||||
"fuzz_testing": true,
|
||||
"benchmarking": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📋 Development Guidelines & Code Style
|
||||
|
||||
### Mathematical Implementation Guidelines
|
||||
- **Precision**: Always use `github.com/holiman/uint256` for uint256 arithmetic
|
||||
- **Error Handling**: Implement robust error handling with clear mathematical context
|
||||
- **Documentation**: Document all mathematical formulas and implementation decisions
|
||||
- **Testing**: Achieve >95% test coverage with property-based tests for mathematical functions
|
||||
- **Performance**: Profile regularly with `go tool pprof` while maintaining precision
|
||||
|
||||
### Code Organization Rules
|
||||
- **File Size**: Keep mathematical function files under 300 lines
|
||||
- **Package Structure**: Place mathematical functions in `pkg/uniswap/` or `pkg/math/`
|
||||
- **Naming**: Use descriptive names for mathematical functions (e.g., `CalculateSqrtPriceX96ToPrice`)
|
||||
- **Documentation**: Inline comments explaining mathematical formulas
|
||||
|
||||
### Required Checks Before Commit
|
||||
```bash
|
||||
# Run mathematical function tests
|
||||
.qwen/scripts/math-test.sh
|
||||
|
||||
# Run linter on mathematical functions
|
||||
golangci-lint run ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Security scan for mathematical implementations
|
||||
gosec ./pkg/uniswap/... ./pkg/math/...
|
||||
```
|
||||
|
||||
## Qwen Code's Primary Focus Areas
|
||||
|
||||
As Qwen Code, you're particularly skilled at:
|
||||
|
||||
1. **Mathematical Computations**
|
||||
- Implementing precise Uniswap V3 pricing functions
|
||||
- Ensuring numerical stability and precision
|
||||
- Working with liquidity and fee calculations
|
||||
|
||||
2. **Algorithmic Implementation**
|
||||
- Creating efficient algorithms for arbitrage detection
|
||||
- Implementing accurate tick and sqrtPriceX96 conversions
|
||||
- Calculating price impact with proper precision handling
|
||||
|
||||
3. **Precision Handling**
|
||||
- Using appropriate data types for mathematical calculations
|
||||
- Implementing proper rounding strategies for financial calculations
|
||||
- Handling overflow and underflow conditions properly
|
||||
|
||||
4. **Performance Optimization**
|
||||
- Minimizing memory allocations in hot paths
|
||||
- Optimizing uint256 arithmetic operations
|
||||
- Reducing garbage collection pressure
|
||||
- Improving mathematical computation efficiency
|
||||
|
||||
## 🛠 Qwen Code Optimization Settings
|
||||
|
||||
### Workflow Preferences
|
||||
- **Always commit changes**: Use `git commit -am "math: descriptive message"` for mathematical implementations
|
||||
- **Branch naming**: Use prefixes (`math-sqrt-price`, `algo-liquidity-calc`, `perf-uniswap`)
|
||||
- **Context management**: Focus on mathematical precision and performance
|
||||
- **Parallel processing**: Leverage Go's concurrency patterns for independent calculations
|
||||
|
||||
### File Organization Preferences
|
||||
- **Mathematical functions**: Place in `pkg/uniswap/` or `pkg/math/`
|
||||
- **Test files**: Place alongside source files with `_test.go` suffix
|
||||
- **Documentation**: Inline comments explaining mathematical formulas
|
||||
- **Precision libraries**: Use `github.com/holiman/uint256` for uint256 arithmetic
|
||||
|
||||
### Performance Monitoring
|
||||
```bash
|
||||
# Enable metrics endpoint for performance tracking
|
||||
export METRICS_ENABLED="true"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Monitor memory usage of mathematical calculations
|
||||
go tool pprof http://localhost:9090/debug/pprof/heap
|
||||
|
||||
# Monitor CPU usage of mathematical functions
|
||||
go tool pprof http://localhost:9090/debug/pprof/profile?seconds=30
|
||||
|
||||
# Run benchmarks for mathematical functions
|
||||
.qwen/scripts/math-test.sh
|
||||
```
|
||||
|
||||
## 🔧 Environment Configuration
|
||||
|
||||
### Required Environment Variables
|
||||
```bash
|
||||
# Arbitrum RPC Configuration
|
||||
export ARBITRUM_RPC_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
export ARBITRUM_WS_ENDPOINT="wss://arbitrum-mainnet.core.chainstack.com/73bc682fe9c5bd23b42ef40f752fa89a"
|
||||
|
||||
# Application Configuration
|
||||
export LOG_LEVEL="info"
|
||||
export METRICS_ENABLED="false"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Development Configuration
|
||||
export GO_ENV="development"
|
||||
export DEBUG="true"
|
||||
|
||||
# Mathematical Precision Configuration
|
||||
export MATH_LIBRARY="github.com/holiman/uint256"
|
||||
export FLOATING_POINT_LIBRARY="math/big"
|
||||
export ROUNDING_STRATEGY="bankers_rounding"
|
||||
export PRECISION_TARGET="256_bits"
|
||||
```
|
||||
|
||||
### Testing Environment Variables
|
||||
```bash
|
||||
# Test Configuration
|
||||
export TEST_COVERAGE_TARGET=95
|
||||
export TEST_TIMEOUT=30s
|
||||
export TEST_PARALLEL=4
|
||||
|
||||
# Mathematical Testing
|
||||
export MATH_TEST_PROPERTY=true
|
||||
export MATH_TEST_FUZZ=true
|
||||
export MATH_BENCHMARK=true
|
||||
```
|
||||
|
||||
## 📝 Commit Message Conventions
|
||||
|
||||
### Format
|
||||
```
|
||||
math(type): brief description
|
||||
|
||||
- Detailed explanation of mathematical implementation
|
||||
- Why the mathematical approach was chosen
|
||||
- Any precision considerations or trade-offs
|
||||
|
||||
🤖 Generated with [Qwen Code](https://tongyi.aliyun.com/)
|
||||
Co-Authored-By: Qwen <noreply@tongyi.aliyun.com>
|
||||
```
|
||||
|
||||
### Types
|
||||
- `sqrt-price`: sqrtPriceX96 related implementations
|
||||
- `tick`: Tick calculation implementations
|
||||
- `liquidity`: Liquidity-based calculation implementations
|
||||
- `price-impact`: Price impact calculation implementations
|
||||
- `arbitrage`: Arbitrage detection algorithm implementations
|
||||
- `perf`: Mathematical performance improvements
|
||||
- `test`: Mathematical function test implementations
|
||||
- `docs`: Mathematical documentation updates
|
||||
|
||||
## 🚨 Security Guidelines
|
||||
|
||||
### Never Commit
|
||||
- Private keys or wallet seeds
|
||||
- API keys or secrets
|
||||
- RPC endpoints with authentication
|
||||
- Personal configuration files
|
||||
|
||||
### Always Validate
|
||||
- Mathematical inputs for overflow conditions
|
||||
- Precision requirements for financial calculations
|
||||
- Edge cases in mathematical implementations
|
||||
- Memory allocations in mathematical functions
|
||||
|
||||
### Security Commands
|
||||
```bash
|
||||
# Scan for secrets
|
||||
git-secrets --scan
|
||||
|
||||
# Security audit for mathematical implementations
|
||||
gosec ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Dependency vulnerabilities
|
||||
go list -json -m all | nancy sleuth
|
||||
|
||||
# Check for hardcoded credentials
|
||||
grep -r "password|secret|key" --exclude-dir=.git .
|
||||
```
|
||||
34
.qwen/commands/implement-algorithm.md
Normal file
34
.qwen/commands/implement-algorithm.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Implement Mathematical Algorithm
|
||||
|
||||
Implement the following mathematical algorithm for the MEV bot: $ARGUMENTS
|
||||
|
||||
## Implementation Framework:
|
||||
1. **Requirements Analysis**: Break down the mathematical requirements and precision needs
|
||||
2. **Formula Implementation**: Convert mathematical formulas to precise Go code
|
||||
3. **Precision Handling**: Use appropriate data types (uint256, big.Int) for calculations
|
||||
4. **Edge Case Handling**: Consider boundary conditions and error scenarios
|
||||
5. **Testing**: Create comprehensive tests including property-based tests
|
||||
6. **Optimization**: Optimize for performance while maintaining precision
|
||||
|
||||
## Implementation Standards:
|
||||
- **Numerical Precision**: Use github.com/holiman/uint256 for precise uint256 arithmetic
|
||||
- **Error Handling**: Implement robust error handling with clear error messages
|
||||
- **Documentation**: Document all mathematical formulas and implementation decisions
|
||||
- **Testing**: Achieve >95% test coverage with property-based tests for mathematical functions
|
||||
- **Performance**: Consider performance implications and benchmark critical paths
|
||||
|
||||
## File Organization:
|
||||
- **Core Logic**: Place in appropriate `pkg/uniswap/` or `pkg/math/` subdirectory
|
||||
- **Tests**: Co-locate with source files (`*_test.go`)
|
||||
- **Documentation**: Inline comments explaining mathematical formulas
|
||||
|
||||
## Integration Points:
|
||||
- **Uniswap Pricing**: Integrate with `pkg/uniswap/` for pricing calculations
|
||||
- **Market Analysis**: Connect to `pkg/market/` for market data processing
|
||||
- **Precision Libraries**: Use `github.com/holiman/uint256` for uint256 arithmetic
|
||||
|
||||
## Deliverables:
|
||||
- Working implementation with comprehensive tests
|
||||
- Documentation of mathematical formulas and implementation approach
|
||||
- Performance benchmarks for critical functions
|
||||
- Edge case handling and error scenarios
|
||||
65
.qwen/commands/optimize-math.md
Normal file
65
.qwen/commands/optimize-math.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# Optimize Mathematical Performance
|
||||
|
||||
Optimize the performance of the following mathematical function in the MEV bot: $ARGUMENTS
|
||||
|
||||
## Performance Optimization Strategy:
|
||||
|
||||
### 1. **Profiling and Measurement**
|
||||
```bash
|
||||
# CPU profiling for mathematical functions
|
||||
go tool pprof http://localhost:9090/debug/pprof/profile?seconds=30
|
||||
|
||||
# Memory profiling for mathematical calculations
|
||||
go tool pprof http://localhost:9090/debug/pprof/heap
|
||||
|
||||
# Benchmark testing for mathematical functions
|
||||
go test -bench=. -benchmem ./pkg/uniswap/...
|
||||
```
|
||||
|
||||
### 2. **Optimization Areas**
|
||||
|
||||
#### **Precision Handling Optimization**
|
||||
- Uint256 arithmetic optimization
|
||||
- Object pooling for frequent calculations
|
||||
- Minimize memory allocations in hot paths
|
||||
- Efficient conversion between data types
|
||||
|
||||
#### **Algorithm Optimization**
|
||||
- Mathematical formula simplification
|
||||
- Lookup table implementation for repeated calculations
|
||||
- Caching strategies for expensive computations
|
||||
- Parallel processing opportunities
|
||||
|
||||
#### **Memory Optimization**
|
||||
- Pre-allocation of slices and buffers
|
||||
- Object pooling for mathematical objects
|
||||
- Minimize garbage collection pressure
|
||||
- Efficient data structure selection
|
||||
|
||||
### 3. **MEV Bot Specific Optimizations**
|
||||
|
||||
#### **Uniswap V3 Pricing Functions**
|
||||
- sqrtPriceX96 to price conversion optimization
|
||||
- Tick calculation performance improvements
|
||||
- Liquidity-based calculation efficiency
|
||||
- Price impact computation optimization
|
||||
|
||||
#### **Arbitrage Calculations**
|
||||
- Profit calculation optimization
|
||||
- Cross-pool comparison performance
|
||||
- Gas estimation accuracy and speed
|
||||
- Multi-hop arbitrage efficiency
|
||||
|
||||
## Implementation Guidelines:
|
||||
- Measure before optimizing (baseline metrics)
|
||||
- Focus on bottlenecks identified through profiling
|
||||
- Maintain mathematical precision while improving performance
|
||||
- Add performance tests for regressions
|
||||
- Document optimization strategies and results
|
||||
|
||||
## Deliverables:
|
||||
- Performance benchmark results (before/after)
|
||||
- Optimized code with maintained precision
|
||||
- Performance monitoring enhancements
|
||||
- Optimization documentation
|
||||
- Regression test suite
|
||||
54
.qwen/commands/verify-precision.md
Normal file
54
.qwen/commands/verify-precision.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Verify Mathematical Precision
|
||||
|
||||
Verify the precision and correctness of the following mathematical implementation in the MEV bot: $ARGUMENTS
|
||||
|
||||
## Verification Protocol:
|
||||
|
||||
### 1. **Mathematical Correctness Analysis**
|
||||
- Review mathematical formulas against official specifications
|
||||
- Validate implementation against known test cases
|
||||
- Check boundary conditions and edge cases
|
||||
- Verify precision handling for large numbers
|
||||
|
||||
### 2. **Property-Based Testing**
|
||||
```bash
|
||||
# Run property-based tests for mathematical functions
|
||||
go test -v -run=Property ./pkg/uniswap/...
|
||||
|
||||
# Run fuzz tests for mathematical calculations
|
||||
go test -fuzz=Fuzz ./pkg/uniswap/...
|
||||
```
|
||||
|
||||
### 3. **Precision Validation Areas**
|
||||
|
||||
#### **Uniswap V3 Calculations**
|
||||
- sqrtPriceX96 to price conversion accuracy
|
||||
- Tick calculation correctness
|
||||
- Liquidity-based calculation precision
|
||||
- Price impact computation validation
|
||||
|
||||
#### **Financial Calculations**
|
||||
- Profit calculation accuracy
|
||||
- Gas estimation precision
|
||||
- Slippage protection validation
|
||||
- Fee calculation correctness
|
||||
|
||||
### 4. **Comparison Testing**
|
||||
- Compare results with reference implementations
|
||||
- Validate against on-chain data when possible
|
||||
- Cross-check with other DeFi protocol implementations
|
||||
- Benchmark against established mathematical libraries
|
||||
|
||||
## Verification Steps:
|
||||
1. **Static Analysis**: Review code for mathematical correctness
|
||||
2. **Unit Testing**: Verify with known test cases
|
||||
3. **Property Testing**: Test mathematical invariants
|
||||
4. **Fuzz Testing**: Find edge cases with random inputs
|
||||
5. **Comparison Testing**: Validate against reference implementations
|
||||
|
||||
## Output Requirements:
|
||||
- Detailed correctness analysis report
|
||||
- Precision validation results
|
||||
- Edge case identification and handling
|
||||
- Recommendations for improvements
|
||||
- Test suite enhancements
|
||||
141
.qwen/config/Makefile
Normal file
141
.qwen/config/Makefile
Normal file
@@ -0,0 +1,141 @@
|
||||
# Makefile for Qwen Code Integration
|
||||
|
||||
# Variables
|
||||
BINARY=mev-bot
|
||||
MAIN_FILE=cmd/mev-bot/main.go
|
||||
BINARY_PATH=bin/$(BINARY)
|
||||
|
||||
# Default target
|
||||
.PHONY: all
|
||||
all: build
|
||||
|
||||
# Build the application
|
||||
.PHONY: build
|
||||
build:
|
||||
@echo "Building $(BINARY)..."
|
||||
@mkdir -p bin
|
||||
@go build -o $(BINARY_PATH) $(MAIN_FILE)
|
||||
@echo "Build successful!"
|
||||
|
||||
# Run the application
|
||||
.PHONY: run
|
||||
run: build
|
||||
@echo "Running $(BINARY)..."
|
||||
@$(BINARY_PATH)
|
||||
|
||||
# Run tests
|
||||
.PHONY: test
|
||||
test:
|
||||
@echo "Running tests..."
|
||||
@go test -v ./...
|
||||
|
||||
# Run tests for mathematical functions
|
||||
.PHONY: test-math
|
||||
test-math:
|
||||
@echo "Running mathematical function tests..."
|
||||
@go test -v ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Run property-based tests
|
||||
.PHONY: test-property
|
||||
test-property:
|
||||
@echo "Running property-based tests..."
|
||||
@go test -v -run=Property ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Run fuzz tests
|
||||
.PHONY: test-fuzz
|
||||
test-fuzz:
|
||||
@echo "Running fuzz tests..."
|
||||
@go test -fuzz=Fuzz ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Run benchmarks for mathematical functions
|
||||
.PHONY: bench-math
|
||||
bench-math:
|
||||
@echo "Running mathematical function benchmarks..."
|
||||
@go test -bench=. -benchmem ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Run benchmarks with CPU profiling
|
||||
.PHONY: bench-cpu
|
||||
bench-cpu:
|
||||
@echo "Running benchmarks with CPU profiling..."
|
||||
@go test -bench=. -cpuprofile=cpu.prof ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Run benchmarks with memory profiling
|
||||
.PHONY: bench-mem
|
||||
bench-mem:
|
||||
@echo "Running benchmarks with memory profiling..."
|
||||
@go test -bench=. -memprofile=mem.prof ./pkg/uniswap/... ./pkg/math/...
|
||||
|
||||
# Clean build artifacts
|
||||
.PHONY: clean
|
||||
clean:
|
||||
@echo "Cleaning..."
|
||||
@rm -rf bin/
|
||||
@rm -f *.prof
|
||||
@rm -f coverage.out coverage.html
|
||||
@echo "Clean complete!"
|
||||
|
||||
# Install dependencies
|
||||
.PHONY: deps
|
||||
deps:
|
||||
@echo "Installing dependencies..."
|
||||
@go mod tidy
|
||||
@echo "Dependencies installed!"
|
||||
|
||||
# Format code
|
||||
.PHONY: fmt
|
||||
fmt:
|
||||
@echo "Formatting code..."
|
||||
@go fmt ./...
|
||||
|
||||
# Vet code
|
||||
.PHONY: vet
|
||||
vet:
|
||||
@echo "Vetting code..."
|
||||
@go vet ./...
|
||||
|
||||
# Lint code (requires golangci-lint)
|
||||
.PHONY: lint
|
||||
lint:
|
||||
@echo "Linting code..."
|
||||
@which golangci-lint > /dev/null || (echo "golangci-lint not found, installing..." && go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest)
|
||||
@golangci-lint run
|
||||
|
||||
# Update dependencies
|
||||
.PHONY: update
|
||||
update:
|
||||
@echo "Updating dependencies..."
|
||||
@go get -u ./...
|
||||
@go mod tidy
|
||||
@echo "Dependencies updated!"
|
||||
|
||||
# Install test dependencies
|
||||
.PHONY: test-deps
|
||||
test-deps:
|
||||
@echo "Installing test dependencies..."
|
||||
@go get github.com/stretchr/testify/assert
|
||||
@go get github.com/leanovate/gopter/...
|
||||
@go mod tidy
|
||||
@echo "Test dependencies installed!"
|
||||
|
||||
# Help
|
||||
.PHONY: help
|
||||
help:
|
||||
@echo "Available targets:"
|
||||
@echo " all - Build the application (default)"
|
||||
@echo " build - Build the application"
|
||||
@echo " run - Build and run the application"
|
||||
@echo " test - Run tests"
|
||||
@echo " test-math - Run tests for mathematical functions"
|
||||
@echo " test-property - Run property-based tests"
|
||||
@echo " test-fuzz - Run fuzz tests"
|
||||
@echo " bench-math - Run benchmarks for mathematical functions"
|
||||
@echo " bench-cpu - Run benchmarks with CPU profiling"
|
||||
@echo " bench-mem - Run benchmarks with memory profiling"
|
||||
@echo " clean - Clean build artifacts"
|
||||
@echo " deps - Install dependencies"
|
||||
@echo " test-deps - Install test dependencies"
|
||||
@echo " fmt - Format code"
|
||||
@echo " vet - Vet code"
|
||||
@echo " lint - Lint code (requires golangci-lint)"
|
||||
@echo " update - Update dependencies"
|
||||
@echo " help - Show this help"
|
||||
73
.qwen/config/focus-areas.md
Normal file
73
.qwen/config/focus-areas.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# Qwen Code Focus Area Definitions
|
||||
|
||||
## Primary Focus Areas
|
||||
|
||||
### 1. Mathematical Computations
|
||||
As Qwen Code, you're particularly skilled at implementing precise mathematical functions with high accuracy and performance. Focus on:
|
||||
- Implementing complex financial calculations with proper precision handling
|
||||
- Ensuring numerical stability across large ranges of values
|
||||
- Working with specialized mathematical libraries like `github.com/holiman/uint256`
|
||||
|
||||
### 2. Algorithmic Implementation
|
||||
You excel at converting mathematical formulas and algorithms into efficient Go code. Focus on:
|
||||
- Creating efficient algorithms for arbitrage detection
|
||||
- Implementing accurate conversions between different mathematical representations
|
||||
- Calculating price impact with proper precision handling
|
||||
|
||||
### 3. Precision Handling
|
||||
Your expertise in precision handling is critical for the MEV bot's success. Focus on:
|
||||
- Using appropriate data types for mathematical calculations
|
||||
- Implementing proper rounding strategies for financial calculations
|
||||
- Handling overflow and underflow conditions properly
|
||||
|
||||
### 4. Performance Optimization
|
||||
While maintaining precision, you're also skilled at optimizing mathematical computations. Focus on:
|
||||
- Minimizing memory allocations in hot paths
|
||||
- Optimizing uint256 arithmetic operations
|
||||
- Reducing garbage collection pressure
|
||||
- Improving mathematical computation efficiency
|
||||
|
||||
## Integration Guidelines
|
||||
|
||||
### Working with Uniswap V3 Mathematics
|
||||
- Focus on sqrtPriceX96 to price conversions
|
||||
- Implement accurate tick calculations
|
||||
- Handle liquidity-based calculations with precision
|
||||
- Optimize price impact computations
|
||||
|
||||
### Performance vs. Precision Balance
|
||||
- Always prioritize precision over performance in mathematical calculations
|
||||
- Use profiling to identify bottlenecks without compromising accuracy
|
||||
- Implement caching strategies for expensive computations
|
||||
- Leverage Go's concurrency for independent mathematical operations
|
||||
|
||||
## Code Quality Standards
|
||||
|
||||
### Testing Requirements
|
||||
- Achieve >95% test coverage for mathematical functions
|
||||
- Implement property-based tests for mathematical invariants
|
||||
- Use fuzz testing to find edge cases
|
||||
- Create benchmarks for performance-critical functions
|
||||
|
||||
### Documentation Standards
|
||||
- Document all mathematical formulas with clear explanations
|
||||
- Comment on precision handling decisions
|
||||
- Explain algorithmic choices and trade-offs
|
||||
- Provide usage examples for complex mathematical functions
|
||||
|
||||
## Collaboration with Other AI Assistants
|
||||
|
||||
### Claude (Architecture & System Design)
|
||||
- Follow architectural patterns defined by Claude
|
||||
- Integrate mathematical functions with system components
|
||||
- Adhere to error handling and logging standards
|
||||
|
||||
### OpenCode (Testing & Quality Assurance)
|
||||
- Work with OpenCode to ensure comprehensive test coverage
|
||||
- Follow testing patterns and quality standards
|
||||
- Address test failures and edge cases identified
|
||||
|
||||
### Gemini (Performance Optimization)
|
||||
- Collaborate on performance optimization strategies
|
||||
- Share profiling results and optimization insights
|
||||
- Coordinate on memory allocation reduction techniques
|
||||
51
.qwen/config/optimization.md
Normal file
51
.qwen/config/optimization.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# Qwen Code Performance Optimization Settings
|
||||
|
||||
## Workflow Preferences
|
||||
- **Always commit changes**: Use `git commit -am "math: descriptive message"` for mathematical implementations
|
||||
- **Branch naming**: Use prefixes (`math-sqrt-price`, `algo-liquidity-calc`, `perf-uniswap`)
|
||||
- **Context management**: Focus on mathematical precision and performance
|
||||
- **Parallel processing**: Leverage Go's concurrency patterns for independent calculations
|
||||
|
||||
## File Organization Preferences
|
||||
- **Mathematical functions**: Place in `pkg/uniswap/` or `pkg/math/`
|
||||
- **Test files**: Place alongside source files with `_test.go` suffix
|
||||
- **Documentation**: Inline comments explaining mathematical formulas
|
||||
- **Precision libraries**: Use `github.com/holiman/uint256` for uint256 arithmetic
|
||||
|
||||
## Performance Monitoring
|
||||
```bash
|
||||
# Enable metrics endpoint for performance tracking
|
||||
export METRICS_ENABLED="true"
|
||||
export METRICS_PORT="9090"
|
||||
|
||||
# Monitor memory usage of mathematical calculations
|
||||
go tool pprof http://localhost:9090/debug/pprof/heap
|
||||
|
||||
# Monitor CPU usage of mathematical functions
|
||||
go tool pprof http://localhost:9090/debug/pprof/profile?seconds=30
|
||||
|
||||
# Run benchmarks for mathematical functions
|
||||
go test -bench=. -benchmem ./pkg/uniswap/...
|
||||
```
|
||||
|
||||
## Precision Requirements
|
||||
- **Uint256 Arithmetic**: Use `github.com/holiman/uint256` for all uint256 calculations
|
||||
- **Floating Point**: Use `math/big` for floating-point calculations when needed
|
||||
- **Rounding**: Implement proper rounding strategies for financial calculations
|
||||
- **Overflow Handling**: Handle overflow and underflow conditions properly
|
||||
|
||||
## Optimization Focus Areas
|
||||
1. **Mathematical Computation Efficiency**
|
||||
- Minimize computational overhead in pricing functions
|
||||
- Optimize sqrtPriceX96 to price conversions
|
||||
- Efficient tick calculations
|
||||
|
||||
2. **Memory Allocation Reduction**
|
||||
- Object pooling for frequently created mathematical objects
|
||||
- Pre-allocation of slices and buffers
|
||||
- Minimize garbage collection pressure
|
||||
|
||||
3. **Algorithmic Optimization**
|
||||
- Mathematical formula simplification
|
||||
- Lookup table implementation for repeated calculations
|
||||
- Caching strategies for expensive computations
|
||||
42
.qwen/config/performance.json
Normal file
42
.qwen/config/performance.json
Normal file
@@ -0,0 +1,42 @@
|
||||
{
|
||||
"focus_areas": [
|
||||
"Mathematical Computations",
|
||||
"Algorithmic Implementation",
|
||||
"Precision Handling",
|
||||
"Performance Optimization"
|
||||
],
|
||||
"primary_skills": [
|
||||
"Implementing precise Uniswap V3 pricing functions",
|
||||
"Ensuring numerical stability and precision",
|
||||
"Working with liquidity and fee calculations",
|
||||
"Creating efficient algorithms for arbitrage detection",
|
||||
"Implementing accurate tick and sqrtPriceX96 conversions",
|
||||
"Calculating price impact with proper precision handling"
|
||||
],
|
||||
"performance_optimization": {
|
||||
"enabled": true,
|
||||
"profiling": {
|
||||
"cpu": true,
|
||||
"memory": true,
|
||||
"goroutine": true
|
||||
},
|
||||
"optimization_targets": [
|
||||
"Minimize memory allocations in hot paths",
|
||||
"Optimize uint256 arithmetic operations",
|
||||
"Reduce garbage collection pressure",
|
||||
"Improve mathematical computation efficiency"
|
||||
]
|
||||
},
|
||||
"precision_requirements": {
|
||||
"math_library": "github.com/holiman/uint256",
|
||||
"floating_point": "math/big",
|
||||
"rounding_strategy": "bankers_rounding",
|
||||
"precision_target": "256_bits"
|
||||
},
|
||||
"testing": {
|
||||
"unit_test_coverage": 0.95,
|
||||
"property_based_testing": true,
|
||||
"fuzz_testing": true,
|
||||
"benchmarking": true
|
||||
}
|
||||
}
|
||||
20
.qwen/prompts/algorithm-optimization.md
Normal file
20
.qwen/prompts/algorithm-optimization.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# Mathematical Algorithm Optimization
|
||||
|
||||
Optimize the following mathematical algorithm for performance while maintaining precision: $ARGUMENTS
|
||||
|
||||
## Optimization Focus:
|
||||
1. Reduce memory allocations in hot paths
|
||||
2. Minimize computational overhead
|
||||
3. Improve cache efficiency
|
||||
4. Leverage concurrency where appropriate
|
||||
|
||||
## Profiling Approach:
|
||||
- Use `go tool pprof` to identify bottlenecks
|
||||
- Create benchmarks to measure improvements
|
||||
- Validate precision is maintained after optimization
|
||||
- Test with realistic data sets
|
||||
|
||||
## Constraints:
|
||||
- Do not compromise mathematical precision
|
||||
- Maintain code readability and maintainability
|
||||
- Follow Go best practices for concurrency and error handling
|
||||
16
.qwen/prompts/uniswap-pricing.md
Normal file
16
.qwen/prompts/uniswap-pricing.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Uniswap V3 Pricing Function Implementation
|
||||
|
||||
Implement the following Uniswap V3 pricing function with high precision: $ARGUMENTS
|
||||
|
||||
## Requirements:
|
||||
1. Use `github.com/holiman/uint256` for all uint256 arithmetic
|
||||
2. Ensure mathematical precision and numerical stability
|
||||
3. Handle edge cases and boundary conditions
|
||||
4. Include comprehensive test coverage
|
||||
5. Provide performance benchmarks
|
||||
|
||||
## Implementation Guidelines:
|
||||
- Follow the official Uniswap V3 whitepaper specifications
|
||||
- Implement proper error handling for invalid inputs
|
||||
- Document mathematical formulas and implementation decisions
|
||||
- Optimize for performance while maintaining precision
|
||||
36
.qwen/scripts/math-optimize.sh
Executable file
36
.qwen/scripts/math-optimize.sh
Executable file
@@ -0,0 +1,36 @@
|
||||
#!/bin/bash
|
||||
|
||||
# math-optimize.sh - Optimize mathematical functions for Qwen Code
|
||||
|
||||
echo "Optimizing mathematical functions for Qwen Code..."
|
||||
|
||||
# Create results directory if it doesn't exist
|
||||
mkdir -p .qwen/results
|
||||
|
||||
# Run benchmarks to establish baseline
|
||||
echo "Establishing performance baseline..."
|
||||
go test -bench=. -benchmem ./pkg/uniswap/... ./pkg/math/... > .qwen/results/baseline-benchmarks.log
|
||||
|
||||
# Run CPU profiling
|
||||
echo "Running CPU profiling..."
|
||||
go test -bench=. -cpuprofile=.qwen/results/baseline-cpu.prof ./pkg/uniswap/... ./pkg/math/... > .qwen/results/baseline-cpu.log
|
||||
|
||||
# Run memory profiling
|
||||
echo "Running memory profiling..."
|
||||
go test -bench=. -memprofile=.qwen/results/baseline-mem.prof ./pkg/uniswap/... ./pkg/math/... > .qwen/results/baseline-mem.log
|
||||
|
||||
# Analyze profiling results
|
||||
echo "Analyzing profiling results..."
|
||||
go tool pprof -top .qwen/results/baseline-cpu.prof > .qwen/results/cpu-top.log
|
||||
go tool pprof -top .qwen/results/baseline-mem.prof > .qwen/results/mem-top.log
|
||||
|
||||
# Generate flame graphs (if go-torch is available)
|
||||
if command -v go-torch &> /dev/null; then
|
||||
echo "Generating flame graphs..."
|
||||
go-torch .qwen/results/baseline-cpu.prof > .qwen/results/cpu-flame.svg
|
||||
go-torch --alloc_objects .qwen/results/baseline-mem.prof > .qwen/results/mem-flame.svg
|
||||
fi
|
||||
|
||||
echo "Mathematical optimization analysis complete!"
|
||||
echo "Baseline results saved to .qwen/results/"
|
||||
echo "Review .qwen/results/cpu-top.log and .qwen/results/mem-top.log for optimization opportunities"
|
||||
42
.qwen/scripts/math-test.sh
Executable file
42
.qwen/scripts/math-test.sh
Executable file
@@ -0,0 +1,42 @@
|
||||
#!/bin/bash
|
||||
|
||||
# math-test.sh - Run comprehensive mathematical tests for Qwen Code
|
||||
|
||||
echo "Running comprehensive mathematical tests for Qwen Code..."
|
||||
|
||||
# Create results directory if it doesn't exist
|
||||
mkdir -p .qwen/results
|
||||
|
||||
# Run unit tests for mathematical functions
|
||||
echo "Running unit tests for mathematical functions..."
|
||||
go test -v ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-unit-tests.log
|
||||
|
||||
# Run property-based tests
|
||||
echo "Running property-based tests..."
|
||||
go test -v -run=Property ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-property-tests.log
|
||||
|
||||
# Run fuzz tests (limited time)
|
||||
echo "Running fuzz tests (60 seconds)..."
|
||||
timeout 60s go test -fuzz=Fuzz ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-fuzz-tests.log
|
||||
|
||||
# Run benchmarks
|
||||
echo "Running mathematical function benchmarks..."
|
||||
go test -bench=. -benchmem ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-benchmarks.log
|
||||
|
||||
# Run benchmarks with CPU profiling
|
||||
echo "Running benchmarks with CPU profiling..."
|
||||
go test -bench=. -cpuprofile=.qwen/results/cpu.prof ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-cpu-bench.log
|
||||
|
||||
# Run benchmarks with memory profiling
|
||||
echo "Running benchmarks with memory profiling..."
|
||||
go test -bench=. -memprofile=.qwen/results/mem.prof ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-mem-bench.log
|
||||
|
||||
# Check for errors
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "All mathematical tests completed successfully!"
|
||||
echo "Results saved to .qwen/results/"
|
||||
else
|
||||
echo "Some mathematical tests failed!"
|
||||
echo "Check .qwen/results/ for details"
|
||||
exit 1
|
||||
fi
|
||||
42
.qwen/scripts/perf-test.sh
Executable file
42
.qwen/scripts/perf-test.sh
Executable file
@@ -0,0 +1,42 @@
|
||||
#!/bin/bash
|
||||
|
||||
# perf-test.sh - Run comprehensive performance tests for Qwen Code
|
||||
|
||||
echo "Running comprehensive mathematical performance tests for Qwen Code..."
|
||||
|
||||
# Create results directory if it doesn't exist
|
||||
mkdir -p .qwen/results
|
||||
|
||||
# Run unit tests for mathematical functions
|
||||
echo "Running unit tests for mathematical functions..."
|
||||
go test -v ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-unit-tests.log
|
||||
|
||||
# Run property-based tests
|
||||
echo "Running property-based tests..."
|
||||
go test -v -run=Property ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-property-tests.log
|
||||
|
||||
# Run fuzz tests (limited time)
|
||||
echo "Running fuzz tests (60 seconds)..."
|
||||
timeout 60s go test -fuzz=Fuzz ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-fuzz-tests.log
|
||||
|
||||
# Run benchmarks
|
||||
echo "Running mathematical function benchmarks..."
|
||||
go test -bench=. -benchmem ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-benchmarks.log
|
||||
|
||||
# Run benchmarks with CPU profiling
|
||||
echo "Running benchmarks with CPU profiling..."
|
||||
go test -bench=. -cpuprofile=.qwen/results/cpu.prof ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-cpu-bench.log
|
||||
|
||||
# Run benchmarks with memory profiling
|
||||
echo "Running benchmarks with memory profiling..."
|
||||
go test -bench=. -memprofile=.qwen/results/mem.prof ./pkg/uniswap/... ./pkg/math/... | tee .qwen/results/math-mem-bench.log
|
||||
|
||||
# Check for errors
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "All mathematical performance tests completed successfully!"
|
||||
echo "Results saved to .qwen/results/"
|
||||
else
|
||||
echo "Some mathematical performance tests failed!"
|
||||
echo "Check .qwen/results/ for details"
|
||||
exit 1
|
||||
fi
|
||||
Reference in New Issue
Block a user