docs: update refactoring summary and mastery plan to reflect completion of all 11 atomic skills
Some checks failed
Some checks failed
- Mark Phase 2 as completed with all 11/11 atomic skills created - Update skill counts: AITBC skills (6/6), OpenClaw skills (5/5) - Move aitbc-node-coordinator and aitbc-analytics-analyzer from remaining to completed - Update Phase 3 status from PLANNED to IN PROGRESS - Add Gitea-based node synchronization documentation (replaces SCP) - Clarify two-node architecture with same port (8006) on different I
This commit is contained in:
aitbc
136
.windsurf/skills/aitbc-analytics-analyzer.md
Normal file
136
.windsurf/skills/aitbc-analytics-analyzer.md
Normal file
@@ -0,0 +1,136 @@
|
||||
---
|
||||
description: Atomic AITBC blockchain analytics and performance metrics with deterministic outputs
|
||||
title: aitbc-analytics-analyzer
|
||||
version: 1.0
|
||||
---
|
||||
|
||||
# AITBC Analytics Analyzer
|
||||
|
||||
## Purpose
|
||||
Analyze blockchain performance metrics, generate analytics reports, and provide insights on blockchain health and efficiency.
|
||||
|
||||
## Activation
|
||||
Trigger when user requests analytics: performance metrics, blockchain health reports, transaction analysis, or system diagnostics.
|
||||
|
||||
## Input
|
||||
```json
|
||||
{
|
||||
"operation": "metrics|health|transactions|diagnostics",
|
||||
"time_range": "1h|24h|7d|30d (optional, default: 24h)",
|
||||
"node": "genesis|follower|all (optional, default: all)",
|
||||
"metric_type": "throughput|latency|block_time|mempool|all (optional)"
|
||||
}
|
||||
```
|
||||
|
||||
## Output
|
||||
```json
|
||||
{
|
||||
"summary": "Analytics analysis completed successfully",
|
||||
"operation": "metrics|health|transactions|diagnostics",
|
||||
"time_range": "string",
|
||||
"node": "genesis|follower|all",
|
||||
"metrics": {
|
||||
"block_height": "number",
|
||||
"block_time_avg": "number",
|
||||
"tx_throughput": "number",
|
||||
"mempool_size": "number",
|
||||
"p2p_connections": "number"
|
||||
},
|
||||
"health_status": "healthy|degraded|critical",
|
||||
"issues": [],
|
||||
"recommendations": [],
|
||||
"confidence": 1.0,
|
||||
"execution_time": "number",
|
||||
"validation_status": "success|partial|failed"
|
||||
}
|
||||
```
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze
|
||||
- Validate time range parameters
|
||||
- Check node accessibility
|
||||
- Verify log file availability
|
||||
- Assess analytics requirements
|
||||
|
||||
### 2. Plan
|
||||
- Select appropriate data sources
|
||||
- Define metric collection strategy
|
||||
- Prepare analysis parameters
|
||||
- Set aggregation methods
|
||||
|
||||
### 3. Execute
|
||||
- Query blockchain logs for metrics
|
||||
- Calculate performance statistics
|
||||
- Analyze transaction patterns
|
||||
- Generate health assessment
|
||||
|
||||
### 4. Validate
|
||||
- Verify metric accuracy
|
||||
- Validate health status calculation
|
||||
- Check data completeness
|
||||
- Confirm analysis consistency
|
||||
|
||||
## Constraints
|
||||
- **MUST NOT** access private keys or sensitive data
|
||||
- **MUST NOT** exceed 45 seconds execution time
|
||||
- **MUST** validate time range parameters
|
||||
- **MUST** handle missing log data gracefully
|
||||
- **MUST** aggregate metrics correctly across nodes
|
||||
|
||||
## Environment Assumptions
|
||||
- Blockchain logs available at `/var/log/aitbc/`
|
||||
- CLI accessible at `/opt/aitbc/aitbc-cli`
|
||||
- Log rotation configured for historical data
|
||||
- P2P network status queryable
|
||||
- Mempool accessible via CLI
|
||||
|
||||
## Error Handling
|
||||
- Missing log files → Return partial metrics with warning
|
||||
- Log parsing errors → Return error with affected time range
|
||||
- Node offline → Exclude from aggregate metrics
|
||||
- Timeout during analysis → Return partial results
|
||||
|
||||
## Example Usage Prompt
|
||||
|
||||
```
|
||||
Generate blockchain performance metrics for the last 24 hours on all nodes
|
||||
```
|
||||
|
||||
## Expected Output Example
|
||||
|
||||
```json
|
||||
{
|
||||
"summary": "Blockchain analytics analysis completed for 24h period",
|
||||
"operation": "metrics",
|
||||
"time_range": "24h",
|
||||
"node": "all",
|
||||
"metrics": {
|
||||
"block_height": 15234,
|
||||
"block_time_avg": 30.2,
|
||||
"tx_throughput": 15.3,
|
||||
"mempool_size": 15,
|
||||
"p2p_connections": 2
|
||||
},
|
||||
"health_status": "healthy",
|
||||
"issues": [],
|
||||
"recommendations": ["Block time within optimal range", "P2P connectivity stable"],
|
||||
"confidence": 1.0,
|
||||
"execution_time": 12.5,
|
||||
"validation_status": "success"
|
||||
}
|
||||
```
|
||||
|
||||
## Model Routing Suggestion
|
||||
|
||||
**Reasoning Model** (Claude Sonnet, GPT-4)
|
||||
- Complex metric calculations and aggregations
|
||||
- Health status assessment
|
||||
- Performance trend analysis
|
||||
- Diagnostic reasoning
|
||||
|
||||
**Performance Notes**
|
||||
- **Execution Time**: 5-20 seconds for metrics, 10-30 seconds for diagnostics
|
||||
- **Memory Usage**: <150MB for analytics operations
|
||||
- **Network Requirements**: Local log access, CLI queries
|
||||
- **Concurrency**: Safe for multiple concurrent analytics queries
|
||||
267
.windsurf/skills/aitbc-node-coordinator.md
Normal file
267
.windsurf/skills/aitbc-node-coordinator.md
Normal file
@@ -0,0 +1,267 @@
|
||||
---
|
||||
description: Atomic AITBC cross-node coordination and messaging operations with deterministic outputs
|
||||
title: aitbc-node-coordinator
|
||||
version: 1.0
|
||||
---
|
||||
|
||||
# AITBC Node Coordinator
|
||||
|
||||
## Purpose
|
||||
Coordinate cross-node operations, synchronize blockchain state, and manage inter-node messaging between genesis and follower nodes.
|
||||
|
||||
## Activation
|
||||
Trigger when user requests cross-node operations: synchronization, coordination, messaging, or multi-node status checks.
|
||||
|
||||
## Input
|
||||
```json
|
||||
{
|
||||
"operation": "sync|status|message|coordinate|health",
|
||||
"target_node": "genesis|follower|all",
|
||||
"message": "string (optional for message operation)",
|
||||
"sync_type": "blockchain|mempool|configuration|git|all (optional for sync)",
|
||||
"timeout": "number (optional, default: 60)",
|
||||
"force": "boolean (optional, default: false)",
|
||||
"verify": "boolean (optional, default: true)"
|
||||
}
|
||||
```
|
||||
|
||||
## Output
|
||||
```json
|
||||
{
|
||||
"summary": "Cross-node operation completed successfully",
|
||||
"operation": "sync|status|message|coordinate|health",
|
||||
"target_node": "genesis|follower|all",
|
||||
"nodes_status": {
|
||||
"genesis": {
|
||||
"status": "online|offline|degraded",
|
||||
"block_height": "number",
|
||||
"mempool_size": "number",
|
||||
"p2p_connections": "number",
|
||||
"service_uptime": "string",
|
||||
"last_sync": "timestamp"
|
||||
},
|
||||
"follower": {
|
||||
"status": "online|offline|degraded",
|
||||
"block_height": "number",
|
||||
"mempool_size": "number",
|
||||
"p2p_connections": "number",
|
||||
"service_uptime": "string",
|
||||
"last_sync": "timestamp"
|
||||
}
|
||||
},
|
||||
"sync_result": "success|partial|failed",
|
||||
"sync_details": {
|
||||
"blockchain_synced": "boolean",
|
||||
"mempool_synced": "boolean",
|
||||
"configuration_synced": "boolean",
|
||||
"git_synced": "boolean"
|
||||
},
|
||||
"message_delivery": {
|
||||
"sent": "number",
|
||||
"delivered": "number",
|
||||
"failed": "number"
|
||||
},
|
||||
"issues": [],
|
||||
"recommendations": [],
|
||||
"confidence": 1.0,
|
||||
"execution_time": "number",
|
||||
"validation_status": "success|partial|failed"
|
||||
}
|
||||
```
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze
|
||||
- Validate target node connectivity using `ping` and SSH test
|
||||
- Check SSH access to remote nodes with `ssh aitbc1 "echo test"`
|
||||
- Verify blockchain service status with `systemctl status aitbc-blockchain-node`
|
||||
- Assess synchronization requirements based on sync_type parameter
|
||||
- Check P2P mesh network status with `netstat -an | grep 7070`
|
||||
- Validate git synchronization status with `git status`
|
||||
|
||||
### 2. Plan
|
||||
- Select appropriate coordination strategy based on operation type
|
||||
- Prepare sync/messaging parameters for execution
|
||||
- Define validation criteria for operation success
|
||||
- Set fallback mechanisms for partial failures
|
||||
- Calculate timeout based on operation complexity
|
||||
- Determine if force flag is required for conflicting operations
|
||||
|
||||
### 3. Execute
|
||||
- **For sync operations:**
|
||||
- Execute `git pull` on both nodes for git sync
|
||||
- Use CLI commands for blockchain state sync
|
||||
- Restart services if force flag is set
|
||||
- **For status operations:**
|
||||
- Execute `ssh aitbc1 "systemctl status aitbc-blockchain-node"`
|
||||
- Check blockchain height with CLI: `./aitbc-cli chain block latest`
|
||||
- Query mempool status with CLI: `./aitbc-cli mempool status`
|
||||
- **For message operations:**
|
||||
- Use P2P mesh network for message delivery
|
||||
- Track message delivery status
|
||||
- **For coordinate operations:**
|
||||
- Execute coordinated actions across nodes
|
||||
- Monitor execution progress
|
||||
- **For health operations:**
|
||||
- Run comprehensive health checks
|
||||
- Collect service metrics
|
||||
|
||||
### 4. Validate
|
||||
- Verify node connectivity with ping and SSH
|
||||
- Check synchronization completeness by comparing block heights
|
||||
- Validate blockchain state consistency across nodes
|
||||
- Confirm messaging delivery with delivery receipts
|
||||
- Verify git synchronization with `git log --oneline -1`
|
||||
- Check service status after operations
|
||||
- Validate no service degradation occurred
|
||||
|
||||
## Constraints
|
||||
- **MUST NOT** restart blockchain services without explicit request or force flag
|
||||
- **MUST NOT** modify node configurations without explicit approval
|
||||
- **MUST NOT** exceed 60 seconds execution time for sync operations
|
||||
- **MUST NOT** execute more than 5 parallel cross-node operations simultaneously
|
||||
- **MUST** validate SSH connectivity before remote operations
|
||||
- **MUST** handle partial failures gracefully with fallback mechanisms
|
||||
- **MUST** preserve service state during coordination operations
|
||||
- **MUST** verify git synchronization before force operations
|
||||
- **MUST** check service health before critical operations
|
||||
- **MUST** respect timeout limits (default 60s, max 120s for complex ops)
|
||||
- **MUST** validate target node existence before operations
|
||||
- **MUST** return detailed error information for all failures
|
||||
|
||||
## Environment Assumptions
|
||||
- SSH access configured between genesis (aitbc) and follower (aitbc1) with key-based authentication
|
||||
- SSH keys located at `/root/.ssh/` for passwordless access
|
||||
- Blockchain nodes operational on both nodes via systemd services
|
||||
- P2P mesh network active on port 7070 with peer configuration
|
||||
- Git synchronization configured between nodes at `/opt/aitbc/.git`
|
||||
- CLI accessible on both nodes at `/opt/aitbc/aitbc-cli`
|
||||
- Python venv activated at `/opt/aitbc/venv/bin/python` for CLI operations
|
||||
- Systemd services: `aitbc-blockchain-node.service` on both nodes
|
||||
- Node addresses: genesis (localhost/aitbc), follower (aitbc1)
|
||||
- Git remote: `origin` at `http://gitea.bubuit.net:3000/oib/aitbc.git`
|
||||
- Log directory: `/var/log/aitbc/` for service logs
|
||||
- Data directory: `/var/lib/aitbc/` for blockchain data
|
||||
|
||||
## Error Handling
|
||||
- SSH connectivity failures → Return connection error with affected node, attempt fallback node
|
||||
- SSH authentication failures → Return authentication error, check SSH key permissions
|
||||
- Blockchain service offline → Mark node as offline in status, attempt service restart if force flag set
|
||||
- Sync failures → Return partial sync with details, identify which sync type failed
|
||||
- Timeout during operations → Return timeout error with operation details, suggest increasing timeout
|
||||
- Git synchronization conflicts → Return conflict error, suggest manual resolution
|
||||
- P2P network disconnection → Return network error, check mesh network status
|
||||
- Service restart failures → Return service error, check systemd logs
|
||||
- Node unreachable → Return unreachable error, verify network connectivity
|
||||
- Invalid target node → Return validation error, suggest valid node names
|
||||
- Permission denied → Return permission error, check user privileges
|
||||
- CLI command failures → Return command error with stderr output
|
||||
- Partial operation success → Return partial success with completed and failed components
|
||||
|
||||
## Example Usage Prompt
|
||||
|
||||
```
|
||||
Sync blockchain state between genesis and follower nodes
|
||||
```
|
||||
|
||||
```
|
||||
Check status of all nodes in the network
|
||||
```
|
||||
|
||||
```
|
||||
Sync git repository across all nodes with force flag
|
||||
```
|
||||
|
||||
```
|
||||
Perform health check on follower node
|
||||
```
|
||||
|
||||
```
|
||||
Coordinate blockchain service restart on genesis node
|
||||
```
|
||||
|
||||
## Expected Output Example
|
||||
|
||||
```json
|
||||
{
|
||||
"summary": "Blockchain state synchronized between genesis and follower nodes",
|
||||
"operation": "sync",
|
||||
"target_node": "all",
|
||||
"nodes_status": {
|
||||
"genesis": {
|
||||
"status": "online",
|
||||
"block_height": 15234,
|
||||
"mempool_size": 15,
|
||||
"p2p_connections": 2,
|
||||
"service_uptime": "5d 12h 34m",
|
||||
"last_sync": 1775811500
|
||||
},
|
||||
"follower": {
|
||||
"status": "online",
|
||||
"block_height": 15234,
|
||||
"mempool_size": 15,
|
||||
"p2p_connections": 2,
|
||||
"service_uptime": "5d 12h 31m",
|
||||
"last_sync": 1775811498
|
||||
}
|
||||
},
|
||||
"sync_result": "success",
|
||||
"sync_details": {
|
||||
"blockchain_synced": true,
|
||||
"mempool_synced": true,
|
||||
"configuration_synced": true,
|
||||
"git_synced": true
|
||||
},
|
||||
"message_delivery": {
|
||||
"sent": 0,
|
||||
"delivered": 0,
|
||||
"failed": 0
|
||||
},
|
||||
"issues": [],
|
||||
"recommendations": ["Nodes are fully synchronized, P2P mesh operating normally"],
|
||||
"confidence": 1.0,
|
||||
"execution_time": 8.5,
|
||||
"validation_status": "success"
|
||||
}
|
||||
```
|
||||
|
||||
## Model Routing Suggestion
|
||||
|
||||
**Fast Model** (Claude Haiku, GPT-3.5-turbo)
|
||||
- Simple status checks on individual nodes
|
||||
- Basic connectivity verification
|
||||
- Quick health checks
|
||||
- Single-node operations
|
||||
|
||||
**Reasoning Model** (Claude Sonnet, GPT-4)
|
||||
- Cross-node synchronization operations
|
||||
- Status validation and error diagnosis
|
||||
- Coordination strategy selection
|
||||
- Multi-node state analysis
|
||||
- Complex error recovery
|
||||
- Force operations with validation
|
||||
|
||||
**Performance Notes**
|
||||
- **Execution Time**:
|
||||
- Sync operations: 5-30 seconds (blockchain), 2-15 seconds (git), 3-20 seconds (mempool)
|
||||
- Status checks: 2-10 seconds per node
|
||||
- Health checks: 5-15 seconds per node
|
||||
- Coordinate operations: 10-45 seconds depending on complexity
|
||||
- Message operations: 1-5 seconds per message
|
||||
- **Memory Usage**:
|
||||
- Status checks: <50MB
|
||||
- Sync operations: <100MB
|
||||
- Complex coordination: <150MB
|
||||
- **Network Requirements**:
|
||||
- SSH connectivity (port 22)
|
||||
- P2P mesh network (port 7070)
|
||||
- Git remote access (HTTP/SSH)
|
||||
- **Concurrency**:
|
||||
- Safe for sequential operations on different nodes
|
||||
- Max 5 parallel operations across nodes
|
||||
- Coordinate parallel ops carefully to avoid service overload
|
||||
- **Optimization Tips**:
|
||||
- Use status checks before sync operations to validate node health
|
||||
- Batch multiple sync operations when possible
|
||||
- Use verify=false for non-critical operations to speed up execution
|
||||
- Cache node status for repeated checks within 30-second window
|
||||
357
.windsurf/skills/blockchain-troubleshoot-recovery.md
Normal file
357
.windsurf/skills/blockchain-troubleshoot-recovery.md
Normal file
@@ -0,0 +1,357 @@
|
||||
---
|
||||
description: Autonomous AI skill for blockchain troubleshooting and recovery across multi-node AITBC setup
|
||||
title: Blockchain Troubleshoot & Recovery
|
||||
version: 1.0
|
||||
---
|
||||
|
||||
# Blockchain Troubleshoot & Recovery Skill
|
||||
|
||||
## Purpose
|
||||
Autonomous AI skill for diagnosing and resolving blockchain communication issues between aitbc (genesis) and aitbc1 (follower) nodes running on port 8006 across different physical machines.
|
||||
|
||||
## Activation
|
||||
Activate this skill when:
|
||||
- Blockchain communication tests fail
|
||||
- Nodes become unreachable
|
||||
- Block synchronization lags (>10 blocks)
|
||||
- Transaction propagation times exceed thresholds
|
||||
- Git synchronization fails
|
||||
- Network latency issues detected
|
||||
- Service health checks fail
|
||||
|
||||
## Input Schema
|
||||
```json
|
||||
{
|
||||
"issue_type": {
|
||||
"type": "string",
|
||||
"enum": ["connectivity", "sync_lag", "transaction_timeout", "service_failure", "git_sync_failure", "network_latency", "unknown"],
|
||||
"description": "Type of blockchain communication issue"
|
||||
},
|
||||
"affected_nodes": {
|
||||
"type": "array",
|
||||
"items": {"type": "string", "enum": ["aitbc", "aitbc1", "both"]},
|
||||
"description": "Nodes affected by the issue"
|
||||
},
|
||||
"severity": {
|
||||
"type": "string",
|
||||
"enum": ["low", "medium", "high", "critical"],
|
||||
"description": "Severity level of the issue"
|
||||
},
|
||||
"diagnostic_data": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"error_logs": {"type": "string"},
|
||||
"test_results": {"type": "object"},
|
||||
"metrics": {"type": "object"}
|
||||
},
|
||||
"description": "Diagnostic data from failed tests"
|
||||
},
|
||||
"auto_recovery": {
|
||||
"type": "boolean",
|
||||
"default": true,
|
||||
"description": "Enable autonomous recovery actions"
|
||||
},
|
||||
"recovery_timeout": {
|
||||
"type": "integer",
|
||||
"default": 300,
|
||||
"description": "Maximum time (seconds) for recovery attempts"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Output Schema
|
||||
```json
|
||||
{
|
||||
"diagnosis": {
|
||||
"root_cause": {"type": "string"},
|
||||
"affected_components": {"type": "array", "items": {"type": "string"}},
|
||||
"confidence": {"type": "number", "minimum": 0, "maximum": 1}
|
||||
},
|
||||
"recovery_actions": {
|
||||
"type": "array",
|
||||
"items": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"action": {"type": "string"},
|
||||
"command": {"type": "string"},
|
||||
"target_node": {"type": "string"},
|
||||
"status": {"type": "string", "enum": ["pending", "in_progress", "completed", "failed"]},
|
||||
"result": {"type": "string"}
|
||||
}
|
||||
}
|
||||
},
|
||||
"recovery_status": {
|
||||
"type": "string",
|
||||
"enum": ["successful", "partial", "failed", "manual_intervention_required"]
|
||||
},
|
||||
"post_recovery_validation": {
|
||||
"tests_passed": {"type": "integer"},
|
||||
"tests_failed": {"type": "integer"},
|
||||
"metrics_restored": {"type": "boolean"}
|
||||
},
|
||||
"recommendations": {
|
||||
"type": "array",
|
||||
"items": {"type": "string"}
|
||||
},
|
||||
"escalation_required": {
|
||||
"type": "boolean"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Diagnose Issue
|
||||
```bash
|
||||
# Collect diagnostic information
|
||||
tail -100 /var/log/aitbc/blockchain-communication-test.log > /tmp/diagnostic_logs.txt
|
||||
tail -50 /var/log/aitbc/blockchain-test-errors.txt >> /tmp/diagnostic_logs.txt
|
||||
|
||||
# Check service status
|
||||
systemctl status aitbc-blockchain-rpc --no-pager >> /tmp/diagnostic_logs.txt
|
||||
ssh aitbc1 'systemctl status aitbc-blockchain-rpc --no-pager' >> /tmp/diagnostic_logs.txt
|
||||
|
||||
# Check network connectivity
|
||||
ping -c 5 10.1.223.40 >> /tmp/diagnostic_logs.txt
|
||||
ping -c 5 <aitbc1-ip> >> /tmp/diagnostic_logs.txt
|
||||
|
||||
# Check port accessibility
|
||||
netstat -tlnp | grep 8006 >> /tmp/diagnostic_logs.txt
|
||||
|
||||
# Check blockchain status
|
||||
NODE_URL=http://10.1.223.40:8006 ./aitbc-cli blockchain info --verbose >> /tmp/diagnostic_logs.txt
|
||||
NODE_URL=http://<aitbc1-ip>:8006 ./aitbc-cli blockchain info --verbose >> /tmp/diagnostic_logs.txt
|
||||
```
|
||||
|
||||
### 2. Analyze Root Cause
|
||||
Based on diagnostic data, identify:
|
||||
- Network connectivity issues (firewall, routing)
|
||||
- Service failures (crashes, hangs)
|
||||
- Synchronization problems (git, blockchain)
|
||||
- Resource exhaustion (CPU, memory, disk)
|
||||
- Configuration errors
|
||||
|
||||
### 3. Execute Recovery Actions
|
||||
|
||||
#### Connectivity Recovery
|
||||
```bash
|
||||
# Restart network services
|
||||
systemctl restart aitbc-blockchain-p2p
|
||||
ssh aitbc1 'systemctl restart aitbc-blockchain-p2p'
|
||||
|
||||
# Check and fix firewall rules
|
||||
iptables -L -n | grep 8006
|
||||
if [ $? -ne 0 ]; then
|
||||
iptables -A INPUT -p tcp --dport 8006 -j ACCEPT
|
||||
iptables -A OUTPUT -p tcp --sport 8006 -j ACCEPT
|
||||
fi
|
||||
|
||||
# Test connectivity
|
||||
curl -f -s http://10.1.223.40:8006/health
|
||||
curl -f -s http://<aitbc1-ip>:8006/health
|
||||
```
|
||||
|
||||
#### Service Recovery
|
||||
```bash
|
||||
# Restart blockchain services
|
||||
systemctl restart aitbc-blockchain-rpc
|
||||
ssh aitbc1 'systemctl restart aitbc-blockchain-rpc'
|
||||
|
||||
# Restart coordinator if needed
|
||||
systemctl restart aitbc-coordinator
|
||||
ssh aitbc1 'systemctl restart aitbc-coordinator'
|
||||
|
||||
# Check service logs
|
||||
journalctl -u aitbc-blockchain-rpc -n 50 --no-pager
|
||||
```
|
||||
|
||||
#### Synchronization Recovery
|
||||
```bash
|
||||
# Force blockchain sync
|
||||
./aitbc-cli cluster sync --all --yes
|
||||
|
||||
# Git sync recovery
|
||||
cd /opt/aitbc
|
||||
git fetch origin main
|
||||
git reset --hard origin/main
|
||||
ssh aitbc1 'cd /opt/aitbc && git fetch origin main && git reset --hard origin/main'
|
||||
|
||||
# Verify sync
|
||||
git log --oneline -5
|
||||
ssh aitbc1 'cd /opt/aitbc && git log --oneline -5'
|
||||
```
|
||||
|
||||
#### Resource Recovery
|
||||
```bash
|
||||
# Clear system caches
|
||||
sync && echo 3 > /proc/sys/vm/drop_caches
|
||||
|
||||
# Restart if resource exhausted
|
||||
systemctl restart aitbc-*
|
||||
ssh aitbc1 'systemctl restart aitbc-*'
|
||||
```
|
||||
|
||||
### 4. Validate Recovery
|
||||
```bash
|
||||
# Run full communication test
|
||||
./scripts/blockchain-communication-test.sh --full --debug
|
||||
|
||||
# Verify all services are healthy
|
||||
curl http://10.1.223.40:8006/health
|
||||
curl http://<aitbc1-ip>:8006/health
|
||||
curl http://10.1.223.40:8001/health
|
||||
curl http://10.1.223.40:8000/health
|
||||
|
||||
# Check blockchain sync
|
||||
NODE_URL=http://10.1.223.40:8006 ./aitbc-cli blockchain height
|
||||
NODE_URL=http://<aitbc1-ip>:8006 ./aitbc-cli blockchain height
|
||||
```
|
||||
|
||||
### 5. Report and Escalate
|
||||
- Document recovery actions taken
|
||||
- Provide metrics before/after recovery
|
||||
- Recommend preventive measures
|
||||
- Escalate if recovery fails or manual intervention needed
|
||||
|
||||
## Constraints
|
||||
- Maximum recovery attempts: 3 per issue type
|
||||
- Recovery timeout: 300 seconds per action
|
||||
- Cannot restart services during peak hours (9AM-5PM local time) without confirmation
|
||||
- Must preserve blockchain data integrity
|
||||
- Cannot modify wallet keys or cryptographic material
|
||||
- Must log all recovery actions
|
||||
- Escalate to human if recovery fails after 3 attempts
|
||||
|
||||
## Environment Assumptions
|
||||
- Genesis node IP: 10.1.223.40
|
||||
- Follower node IP: <aitbc1-ip> (replace with actual IP)
|
||||
- Both nodes use port 8006 for blockchain RPC
|
||||
- SSH access to aitbc1 configured and working
|
||||
- AITBC CLI accessible at /opt/aitbc/aitbc-cli
|
||||
- Git repository: http://gitea.bubuit.net:3000/oib/aitbc.git
|
||||
- Log directory: /var/log/aitbc/
|
||||
- Test script: /opt/aitbc/scripts/blockchain-communication-test.sh
|
||||
- Systemd services: aitbc-blockchain-rpc, aitbc-coordinator, aitbc-blockchain-p2p
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Recovery Action Failure
|
||||
- Log specific failure reason
|
||||
- Attempt alternative recovery method
|
||||
- Increment failure counter
|
||||
- Escalate after 3 failures
|
||||
|
||||
### Service Restart Failure
|
||||
- Check service logs for errors
|
||||
- Verify configuration files
|
||||
- Check system resources
|
||||
- Escalate if service cannot be restarted
|
||||
|
||||
### Network Unreachable
|
||||
- Check physical network connectivity
|
||||
- Verify firewall rules
|
||||
- Check routing tables
|
||||
- Escalate if network issue persists
|
||||
|
||||
### Data Integrity Concerns
|
||||
- Stop all recovery actions
|
||||
- Preserve current state
|
||||
- Escalate immediately for manual review
|
||||
- Do not attempt automated recovery
|
||||
|
||||
### Timeout Exceeded
|
||||
- Stop current recovery action
|
||||
- Log timeout event
|
||||
- Attempt next recovery method
|
||||
- Escalate if all methods timeout
|
||||
|
||||
## Example Usage Prompts
|
||||
|
||||
### Basic Troubleshooting
|
||||
"Blockchain communication test failed on aitbc1 node. Diagnose and recover."
|
||||
|
||||
### Specific Issue Type
|
||||
"Block synchronization lag detected (>15 blocks). Perform autonomous recovery."
|
||||
|
||||
### Service Failure
|
||||
"aitbc-blockchain-rpc service crashed on genesis node. Restart and validate."
|
||||
|
||||
### Network Issue
|
||||
"Cannot reach aitbc1 node on port 8006. Troubleshoot network connectivity."
|
||||
|
||||
### Full Recovery
|
||||
"Complete blockchain communication test failed with multiple issues. Perform full autonomous recovery."
|
||||
|
||||
### Escalation Scenario
|
||||
"Recovery actions failed after 3 attempts. Prepare escalation report with diagnostic data."
|
||||
|
||||
## Expected Output Example
|
||||
```json
|
||||
{
|
||||
"diagnosis": {
|
||||
"root_cause": "Network firewall blocking port 8006 on follower node",
|
||||
"affected_components": ["network", "firewall", "aitbc1"],
|
||||
"confidence": 0.95
|
||||
},
|
||||
"recovery_actions": [
|
||||
{
|
||||
"action": "Check firewall rules",
|
||||
"command": "iptables -L -n | grep 8006",
|
||||
"target_node": "aitbc1",
|
||||
"status": "completed",
|
||||
"result": "Port 8006 not in allowed rules"
|
||||
},
|
||||
{
|
||||
"action": "Add firewall rule",
|
||||
"command": "iptables -A INPUT -p tcp --dport 8006 -j ACCEPT",
|
||||
"target_node": "aitbc1",
|
||||
"status": "completed",
|
||||
"result": "Rule added successfully"
|
||||
},
|
||||
{
|
||||
"action": "Test connectivity",
|
||||
"command": "curl -f -s http://<aitbc1-ip>:8006/health",
|
||||
"target_node": "aitbc1",
|
||||
"status": "completed",
|
||||
"result": "Node reachable"
|
||||
}
|
||||
],
|
||||
"recovery_status": "successful",
|
||||
"post_recovery_validation": {
|
||||
"tests_passed": 5,
|
||||
"tests_failed": 0,
|
||||
"metrics_restored": true
|
||||
},
|
||||
"recommendations": [
|
||||
"Add persistent firewall rules to /etc/iptables/rules.v4",
|
||||
"Monitor firewall changes for future prevention",
|
||||
"Consider implementing network monitoring alerts"
|
||||
],
|
||||
"escalation_required": false
|
||||
}
|
||||
```
|
||||
|
||||
## Model Routing
|
||||
- **Fast Model**: Use for simple, routine recoveries (service restarts, basic connectivity)
|
||||
- **Reasoning Model**: Use for complex diagnostics, root cause analysis, multi-step recovery
|
||||
- **Reasoning Model**: Use when recovery fails and escalation planning is needed
|
||||
|
||||
## Performance Notes
|
||||
- **Diagnosis Time**: 10-30 seconds depending on issue complexity
|
||||
- **Recovery Time**: 30-120 seconds per recovery action
|
||||
- **Validation Time**: 60-180 seconds for full test suite
|
||||
- **Memory Usage**: <500MB during recovery operations
|
||||
- **Network Impact**: Minimal during diagnostics, moderate during git sync
|
||||
- **Concurrency**: Can handle single issue recovery; multiple issues should be queued
|
||||
- **Optimization**: Cache diagnostic data to avoid repeated collection
|
||||
- **Rate Limiting**: Limit service restarts to prevent thrashing
|
||||
- **Logging**: All actions logged with timestamps for audit trail
|
||||
|
||||
## Related Skills
|
||||
- [aitbc-node-coordinator](/aitbc-node-coordinator.md) - For cross-node coordination during recovery
|
||||
- [openclaw-error-handler](/openclaw-error-handler.md) - For error handling and escalation
|
||||
- [openclaw-coordination-orchestrator](/openclaw-coordination-orchestrator.md) - For multi-node recovery coordination
|
||||
|
||||
## Related Workflows
|
||||
- [Blockchain Communication Test](/workflows/blockchain-communication-test.md) - Testing workflow that triggers this skill
|
||||
- [Multi-Node Operations](/workflows/multi-node-blockchain-operations.md) - General node operations
|
||||
134
.windsurf/skills/openclaw-coordination-orchestrator.md
Normal file
134
.windsurf/skills/openclaw-coordination-orchestrator.md
Normal file
@@ -0,0 +1,134 @@
|
||||
---
|
||||
description: Atomic OpenClaw multi-agent workflow coordination with deterministic outputs
|
||||
title: openclaw-coordination-orchestrator
|
||||
version: 1.0
|
||||
---
|
||||
|
||||
# OpenClaw Coordination Orchestrator
|
||||
|
||||
## Purpose
|
||||
Coordinate multi-agent workflows, manage agent task distribution, and orchestrate complex operations across multiple OpenClaw agents.
|
||||
|
||||
## Activation
|
||||
Trigger when user requests multi-agent coordination: task distribution, workflow orchestration, agent collaboration, or parallel execution management.
|
||||
|
||||
## Input
|
||||
```json
|
||||
{
|
||||
"operation": "distribute|orchestrate|collaborate|monitor",
|
||||
"agents": ["agent1", "agent2", "..."],
|
||||
"task_type": "analysis|execution|validation|testing",
|
||||
"workflow": "string (optional for orchestrate)",
|
||||
"parallel": "boolean (optional, default: true)"
|
||||
}
|
||||
```
|
||||
|
||||
## Output
|
||||
```json
|
||||
{
|
||||
"summary": "Multi-agent coordination completed successfully",
|
||||
"operation": "distribute|orchestrate|collaborate|monitor",
|
||||
"agents_assigned": ["agent1", "agent2", "..."],
|
||||
"task_distribution": {
|
||||
"agent1": "task_description",
|
||||
"agent2": "task_description"
|
||||
},
|
||||
"workflow_status": "active|completed|failed",
|
||||
"collaboration_results": {},
|
||||
"issues": [],
|
||||
"recommendations": [],
|
||||
"confidence": 1.0,
|
||||
"execution_time": "number",
|
||||
"validation_status": "success|partial|failed"
|
||||
}
|
||||
```
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze
|
||||
- Validate agent availability
|
||||
- Check agent connectivity
|
||||
- Assess task complexity
|
||||
- Determine optimal distribution strategy
|
||||
|
||||
### 2. Plan
|
||||
- Select coordination approach
|
||||
- Define task allocation
|
||||
- Set execution order
|
||||
- Plan fallback mechanisms
|
||||
|
||||
### 3. Execute
|
||||
- Distribute tasks to agents
|
||||
- Monitor agent progress
|
||||
- Coordinate inter-agent communication
|
||||
- Aggregate results
|
||||
|
||||
### 4. Validate
|
||||
- Verify task completion
|
||||
- Check result consistency
|
||||
- Validate workflow integrity
|
||||
- Confirm agent satisfaction
|
||||
|
||||
## Constraints
|
||||
- **MUST NOT** modify agent configurations without approval
|
||||
- **MUST NOT** exceed 120 seconds for complex workflows
|
||||
- **MUST** validate agent availability before distribution
|
||||
- **MUST** handle agent failures gracefully
|
||||
- **MUST** respect agent capacity limits
|
||||
|
||||
## Environment Assumptions
|
||||
- OpenClaw agents operational and accessible
|
||||
- Agent communication channels available
|
||||
- Task queue system functional
|
||||
- Agent status monitoring active
|
||||
- Collaboration protocol established
|
||||
|
||||
## Error Handling
|
||||
- Agent offline → Reassign task to available agent
|
||||
- Task timeout → Retry with different agent
|
||||
- Communication failure → Use fallback coordination
|
||||
- Agent capacity exceeded → Queue task for later execution
|
||||
|
||||
## Example Usage Prompt
|
||||
|
||||
```
|
||||
Orchestrate parallel analysis workflow across main and trading agents
|
||||
```
|
||||
|
||||
## Expected Output Example
|
||||
|
||||
```json
|
||||
{
|
||||
"summary": "Multi-agent workflow orchestrated successfully across 2 agents",
|
||||
"operation": "orchestrate",
|
||||
"agents_assigned": ["main", "trading"],
|
||||
"task_distribution": {
|
||||
"main": "Analyze blockchain state and transaction patterns",
|
||||
"trading": "Analyze marketplace pricing and order flow"
|
||||
},
|
||||
"workflow_status": "completed",
|
||||
"collaboration_results": {
|
||||
"main": {"status": "completed", "result": "analysis_complete"},
|
||||
"trading": {"status": "completed", "result": "analysis_complete"}
|
||||
},
|
||||
"issues": [],
|
||||
"recommendations": ["Consider adding GPU agent for compute-intensive analysis"],
|
||||
"confidence": 1.0,
|
||||
"execution_time": 45.2,
|
||||
"validation_status": "success"
|
||||
}
|
||||
```
|
||||
|
||||
## Model Routing Suggestion
|
||||
|
||||
**Reasoning Model** (Claude Sonnet, GPT-4)
|
||||
- Complex workflow orchestration
|
||||
- Task distribution strategy
|
||||
- Agent capacity planning
|
||||
- Collaboration protocol management
|
||||
|
||||
**Performance Notes**
|
||||
- **Execution Time**: 10-60 seconds for distribution, 30-120 seconds for complex workflows
|
||||
- **Memory Usage**: <200MB for coordination operations
|
||||
- **Network Requirements**: Agent communication channels
|
||||
- **Concurrency**: Safe for multiple parallel workflows
|
||||
151
.windsurf/skills/openclaw-error-handler.md
Normal file
151
.windsurf/skills/openclaw-error-handler.md
Normal file
@@ -0,0 +1,151 @@
|
||||
---
|
||||
description: Atomic OpenClaw error detection and recovery procedures with deterministic outputs
|
||||
title: openclaw-error-handler
|
||||
version: 1.0
|
||||
---
|
||||
|
||||
# OpenClaw Error Handler
|
||||
|
||||
## Purpose
|
||||
Detect, diagnose, and recover from errors in OpenClaw agent operations with systematic error handling and recovery procedures.
|
||||
|
||||
## Activation
|
||||
Trigger when user requests error handling: error diagnosis, recovery procedures, error analysis, or system health checks.
|
||||
|
||||
## Input
|
||||
```json
|
||||
{
|
||||
"operation": "detect|diagnose|recover|analyze",
|
||||
"agent": "agent_name",
|
||||
"error_type": "execution|communication|configuration|timeout|unknown",
|
||||
"error_context": "string (optional)",
|
||||
"recovery_strategy": "auto|manual|rollback|retry"
|
||||
}
|
||||
```
|
||||
|
||||
## Output
|
||||
```json
|
||||
{
|
||||
"summary": "Error handling operation completed successfully",
|
||||
"operation": "detect|diagnose|recover|analyze",
|
||||
"agent": "agent_name",
|
||||
"error_detected": {
|
||||
"type": "string",
|
||||
"severity": "critical|high|medium|low",
|
||||
"timestamp": "number",
|
||||
"context": "string"
|
||||
},
|
||||
"diagnosis": {
|
||||
"root_cause": "string",
|
||||
"affected_components": ["component1", "component2"],
|
||||
"impact_assessment": "string"
|
||||
},
|
||||
"recovery_applied": {
|
||||
"strategy": "string",
|
||||
"actions_taken": ["action1", "action2"],
|
||||
"success": "boolean"
|
||||
},
|
||||
"issues": [],
|
||||
"recommendations": [],
|
||||
"confidence": 1.0,
|
||||
"execution_time": "number",
|
||||
"validation_status": "success|partial|failed"
|
||||
}
|
||||
```
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze
|
||||
- Scan agent logs for errors
|
||||
- Identify error patterns
|
||||
- Assess error severity
|
||||
- Determine error scope
|
||||
|
||||
### 2. Diagnose
|
||||
- Analyze root cause
|
||||
- Trace error propagation
|
||||
- Identify affected components
|
||||
- Assess impact
|
||||
|
||||
### 3. Execute Recovery
|
||||
- Select recovery strategy
|
||||
- Apply recovery actions
|
||||
- Monitor recovery progress
|
||||
- Validate recovery success
|
||||
|
||||
### 4. Validate
|
||||
- Verify error resolution
|
||||
- Check system stability
|
||||
- Validate agent functionality
|
||||
- Confirm no side effects
|
||||
|
||||
## Constraints
|
||||
- **MUST NOT** modify critical system files
|
||||
- **MUST NOT** exceed 60 seconds for error diagnosis
|
||||
- **MUST** preserve error logs for analysis
|
||||
- **MUST** validate recovery before applying
|
||||
- **MUST** rollback on recovery failure
|
||||
|
||||
## Environment Assumptions
|
||||
- Agent logs accessible at `/var/log/aitbc/`
|
||||
- Error tracking system functional
|
||||
- Recovery procedures documented
|
||||
- Agent state persistence available
|
||||
- System monitoring active
|
||||
|
||||
## Error Handling
|
||||
- Recovery failure → Attempt alternative recovery strategy
|
||||
- Multiple errors → Prioritize by severity
|
||||
- Unknown error type → Apply generic recovery procedure
|
||||
- System instability → Emergency rollback
|
||||
|
||||
## Example Usage Prompt
|
||||
|
||||
```
|
||||
Diagnose and recover from execution errors in main agent
|
||||
```
|
||||
|
||||
## Expected Output Example
|
||||
|
||||
```json
|
||||
{
|
||||
"summary": "Error diagnosed and recovered successfully in main agent",
|
||||
"operation": "recover",
|
||||
"agent": "main",
|
||||
"error_detected": {
|
||||
"type": "execution",
|
||||
"severity": "high",
|
||||
"timestamp": 1775811500,
|
||||
"context": "Transaction processing timeout during blockchain sync"
|
||||
},
|
||||
"diagnosis": {
|
||||
"root_cause": "Network latency causing P2P sync timeout",
|
||||
"affected_components": ["p2p_network", "transaction_processor"],
|
||||
"impact_assessment": "Delayed transaction processing, no data loss"
|
||||
},
|
||||
"recovery_applied": {
|
||||
"strategy": "retry",
|
||||
"actions_taken": ["Increased timeout threshold", "Retried transaction processing"],
|
||||
"success": true
|
||||
},
|
||||
"issues": [],
|
||||
"recommendations": ["Monitor network latency for future occurrences", "Consider implementing adaptive timeout"],
|
||||
"confidence": 1.0,
|
||||
"execution_time": 18.3,
|
||||
"validation_status": "success"
|
||||
}
|
||||
```
|
||||
|
||||
## Model Routing Suggestion
|
||||
|
||||
**Reasoning Model** (Claude Sonnet, GPT-4)
|
||||
- Complex error diagnosis
|
||||
- Root cause analysis
|
||||
- Recovery strategy selection
|
||||
- Impact assessment
|
||||
|
||||
**Performance Notes**
|
||||
- **Execution Time**: 5-30 seconds for detection, 15-45 seconds for diagnosis, 10-60 seconds for recovery
|
||||
- **Memory Usage**: <150MB for error handling operations
|
||||
- **Network Requirements**: Agent communication for error context
|
||||
- **Concurrency**: Safe for sequential error handling on different agents
|
||||
160
.windsurf/skills/openclaw-performance-optimizer.md
Normal file
160
.windsurf/skills/openclaw-performance-optimizer.md
Normal file
@@ -0,0 +1,160 @@
|
||||
---
|
||||
description: Atomic OpenClaw agent performance tuning and optimization with deterministic outputs
|
||||
title: openclaw-performance-optimizer
|
||||
version: 1.0
|
||||
---
|
||||
|
||||
# OpenClaw Performance Optimizer
|
||||
|
||||
## Purpose
|
||||
Optimize agent performance, tune execution parameters, and improve efficiency for OpenClaw agents through systematic analysis and adjustment.
|
||||
|
||||
## Activation
|
||||
Trigger when user requests performance optimization: agent tuning, parameter adjustment, efficiency improvements, or performance benchmarking.
|
||||
|
||||
## Input
|
||||
```json
|
||||
{
|
||||
"operation": "tune|benchmark|optimize|profile",
|
||||
"agent": "agent_name",
|
||||
"target": "speed|memory|throughput|latency|all",
|
||||
"parameters": {
|
||||
"max_tokens": "number (optional)",
|
||||
"temperature": "number (optional)",
|
||||
"timeout": "number (optional)"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Output
|
||||
```json
|
||||
{
|
||||
"summary": "Agent performance optimization completed successfully",
|
||||
"operation": "tune|benchmark|optimize|profile",
|
||||
"agent": "agent_name",
|
||||
"target": "speed|memory|throughput|latency|all",
|
||||
"before_metrics": {
|
||||
"execution_time": "number",
|
||||
"memory_usage": "number",
|
||||
"throughput": "number",
|
||||
"latency": "number"
|
||||
},
|
||||
"after_metrics": {
|
||||
"execution_time": "number",
|
||||
"memory_usage": "number",
|
||||
"throughput": "number",
|
||||
"latency": "number"
|
||||
},
|
||||
"improvement": {
|
||||
"speed": "percentage",
|
||||
"memory": "percentage",
|
||||
"throughput": "percentage",
|
||||
"latency": "percentage"
|
||||
},
|
||||
"issues": [],
|
||||
"recommendations": [],
|
||||
"confidence": 1.0,
|
||||
"execution_time": "number",
|
||||
"validation_status": "success|partial|failed"
|
||||
}
|
||||
```
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze
|
||||
- Profile current agent performance
|
||||
- Identify bottlenecks
|
||||
- Assess optimization opportunities
|
||||
- Validate agent state
|
||||
|
||||
### 2. Plan
|
||||
- Select optimization strategy
|
||||
- Define parameter adjustments
|
||||
- Set performance targets
|
||||
- Plan validation approach
|
||||
|
||||
### 3. Execute
|
||||
- Apply parameter adjustments
|
||||
- Run performance benchmarks
|
||||
- Measure improvements
|
||||
- Validate stability
|
||||
|
||||
### 4. Validate
|
||||
- Verify performance gains
|
||||
- Check for regressions
|
||||
- Validate parameter stability
|
||||
- Confirm agent functionality
|
||||
|
||||
## Constraints
|
||||
- **MUST NOT** modify agent core functionality
|
||||
- **MUST NOT** exceed 90 seconds for optimization
|
||||
- **MUST** validate parameter ranges
|
||||
- **MUST** preserve agent behavior
|
||||
- **MUST** rollback on critical failures
|
||||
|
||||
## Environment Assumptions
|
||||
- Agent operational and accessible
|
||||
- Performance monitoring available
|
||||
- Parameter configuration accessible
|
||||
- Benchmarking tools available
|
||||
- Agent state persistence functional
|
||||
|
||||
## Error Handling
|
||||
- Parameter validation failure → Revert to previous parameters
|
||||
- Performance regression → Rollback optimization
|
||||
- Agent instability → Restore baseline configuration
|
||||
- Timeout during optimization → Return partial results
|
||||
|
||||
## Example Usage Prompt
|
||||
|
||||
```
|
||||
Optimize main agent for speed and memory efficiency
|
||||
```
|
||||
|
||||
## Expected Output Example
|
||||
|
||||
```json
|
||||
{
|
||||
"summary": "Main agent optimized for speed and memory efficiency",
|
||||
"operation": "optimize",
|
||||
"agent": "main",
|
||||
"target": "all",
|
||||
"before_metrics": {
|
||||
"execution_time": 15.2,
|
||||
"memory_usage": 250,
|
||||
"throughput": 8.5,
|
||||
"latency": 2.1
|
||||
},
|
||||
"after_metrics": {
|
||||
"execution_time": 11.8,
|
||||
"memory_usage": 180,
|
||||
"throughput": 12.3,
|
||||
"latency": 1.5
|
||||
},
|
||||
"improvement": {
|
||||
"speed": "22%",
|
||||
"memory": "28%",
|
||||
"throughput": "45%",
|
||||
"latency": "29%"
|
||||
},
|
||||
"issues": [],
|
||||
"recommendations": ["Consider further optimization for memory-intensive tasks"],
|
||||
"confidence": 1.0,
|
||||
"execution_time": 35.7,
|
||||
"validation_status": "success"
|
||||
}
|
||||
```
|
||||
|
||||
## Model Routing Suggestion
|
||||
|
||||
**Reasoning Model** (Claude Sonnet, GPT-4)
|
||||
- Complex parameter optimization
|
||||
- Performance analysis and tuning
|
||||
- Benchmark interpretation
|
||||
- Regression detection
|
||||
|
||||
**Performance Notes**
|
||||
- **Execution Time**: 20-60 seconds for optimization, 5-15 seconds for benchmarking
|
||||
- **Memory Usage**: <200MB for optimization operations
|
||||
- **Network Requirements**: Agent communication for profiling
|
||||
- **Concurrency**: Safe for sequential optimization of different agents
|
||||
Reference in New Issue
Block a user