Added 'Mission & Financial Goals' section at the top to provide critical
context for AI agents making decisions:
**Current Phase Context:**
- Starting capital: $106 (+ $1K deposit in 2 weeks)
- Target: $2,500 by Month 2.5
- Strategy: Aggressive compounding, 0 withdrawals
- Position sizing: 100% of account at 20x leverage
- Win target: 20-30% monthly returns
**Why This Matters:**
- Every dollar counts - optimize for profitability
- User needs $300-500/month withdrawals starting Month 3
- No changes that reduce win rate unless they improve profit factor
- System must prove itself before scaling
**Key Constraints:**
- Can't afford extended drawdowns (limited capital)
- Must maintain 60%+ win rate to compound effectively
- Quality > quantity (70+ signal scores only)
- Stop after 3 consecutive losses
Also added 'Financial Roadmap Integration' subsection linking technical
improvements to phase objectives (Phase 1: prove system, Phase 2-3:
sustainable growth + withdrawals, Phase 4+: scale + reduce risk).
This ensures future AI agents understand the YOLO/recovery context and
prioritize profitability over conservative safety during Phase 1.
Added SQL Analysis Queries section with:
- Phase 1 monitoring queries (count, score distribution, recent signals)
- Phase 2 comparison queries (blocked vs executed trades)
- Pattern analysis queries (range extremes, ADX distribution)
Benefits:
- AI agents have immediate access to standard queries
- Consistent analysis approach each time
- No need to context-switch to separate docs
- Quick reference for common investigations
Includes usage pattern guidance and reference to full docs.
- Added BlockedSignal to database models list
- Updated signalQualityVersion to v4 (current)
- Added blocked signals tracking functions to database section
- Updated check-risk endpoint description
- Added Signal Quality Optimization Roadmap reference
- Documented blocked signals analysis workflow
- Added reference to BLOCKED_SIGNALS_TRACKING.md
This ensures AI agents understand the new data collection system.
BUG FOUND:
Line 558: tp2SizePercent: config.takeProfit2SizePercent || 100
When config.takeProfit2SizePercent = 0 (TP2-as-runner system), JavaScript's ||
operator treats 0 as falsy and falls back to 100, causing TP2 to close 100%
of remaining position instead of activating trailing stop.
IMPACT:
- On-chain orders placed correctly (line 481 uses ?? correctly)
- Position Manager reads from DB and expects TP2 to close position
- Result: User sees TWO take-profit orders instead of runner system
FIX:
Changed both tp1SizePercent and tp2SizePercent to use ?? operator:
- tp1SizePercent: config.takeProfit1SizePercent ?? 75
- tp2SizePercent: config.takeProfit2SizePercent ?? 0
This allows 0 value to be saved correctly for TP2-as-runner system.
VERIFICATION NEEDED:
Current open SHORT position in database has tp2SizePercent=100 from before
this fix. Next trade will use correct runner system.
- New /api/trading/sync-positions endpoint (no auth)
- Fetches actual Drift positions and compares with Position Manager
- Removes stale tracking, adds missing positions with calculated TP/SL
- Settings UI: Orange 'Sync Positions' button added
- CLI script: scripts/sync-positions.sh for terminal access
- Full documentation in docs/guides/POSITION_SYNC_GUIDE.md
- Quick reference: POSITION_SYNC_QUICK_REF.md
- Updated AI instructions with pitfall #23
Problem solved: Manual Telegram trades with partial fills can cause
Position Manager to lose tracking, leaving positions without software-
based stop loss protection. This feature restores dual-layer protection.
Note: Docker build not picking up route yet (cache issue), needs investigation
- Updated Signal Quality System to reflect MIN_SIGNAL_QUALITY_SCORE is configurable (default: 65)
- Added critical pitfall #7: Never use hardcoded config values in endpoints
- Emphasized settings page can modify minSignalQualityScore dynamically
- Renumbered remaining pitfalls for clarity
- Add market data cache service (5min expiry) for storing TradingView metrics
- Create /api/trading/market-data webhook endpoint for continuous data updates
- Add /api/analytics/reentry-check endpoint for validating manual trades
- Update execute endpoint to auto-cache metrics from incoming signals
- Enhance Telegram bot with pre-execution analytics validation
- Support --force flag to override analytics blocks
- Use fresh ADX/ATR/RSI data when available, fallback to historical
- Apply performance modifiers: -20 for losing streaks, +10 for winning
- Minimum re-entry score 55 (vs 60 for new signals)
- Fail-open design: proceeds if analytics unavailable
- Show data freshness and source in Telegram responses
- Add comprehensive setup guide in docs/guides/REENTRY_ANALYTICS_QUICKSTART.md
Phase 1 implementation for smart manual trade validation.
- Fix P&L calculation in Position Manager to use actual entry vs exit price instead of SDK's potentially incorrect realizedPnL
- Calculate actual profit percentage and apply to closed position size for accurate dollar amounts
- Update database record for last trade from incorrect 6.58 to actual .66 P&L
- Update .github/copilot-instructions.md to reflect TP2-as-runner system changes
- Document 25% runner system (5x larger than old 5%) with ATR-based trailing
- Add critical P&L calculation pattern to common pitfalls section
- Mark Phase 5 complete in development roadmap
- Added signalQualityVersion field documentation (v1/v2/v3 tracking)
- Documented /api/analytics/version-comparison endpoint
- Added Prisma Decimal type handling pitfall (#18)
- Added signal quality version tracking section to Development Roadmap
- References SQL analysis file for version comparison queries
Enables AI agents to understand the version tracking system for
data-driven algorithm optimization.
- Added signalQualityVersion field to Trade model
- Tracks which scoring logic version was used for each trade
- v1: Original logic (price position < 5% threshold)
- v2: Added volume compensation for low ADX
- v3: CURRENT - Stricter logic requiring ADX > 18 for extreme positions (< 15%)
This enables future analysis to:
- Compare performance between logic versions
- Filter trades by scoring algorithm
- Data-driven improvements based on clean datasets
All new trades will be marked as v3. Old trades remain null/v1 for comparison.
Added documentation for recent improvements:
- MAE/MFE tracking for trade optimization
- On-chain order synchronization after TP1 hits
- Exit reason detection using trade state flags (not current price)
- Per-symbol cooldown to avoid missing opportunities
- Quality score integration in analytics dashboard
Updated workflows and pitfalls sections with lessons learned from debugging session
- Add qualityScore to ExecuteTradeResponse interface and response object
- Update analytics page to always show Signal Quality card (N/A if unavailable)
- Fix n8n workflow to pass context metrics and qualityScore to execute endpoint
- Fix timezone in Telegram notifications (Europe/Berlin)
- Fix symbol normalization in /api/trading/close endpoint
- Update Drift ETH-PERP minimum order size (0.002 ETH not 0.01)
- Add transaction confirmation to closePosition() to prevent phantom closes
- Add 30-second grace period for new trades in Position Manager
- Fix execution order: database save before Position Manager.addTrade()
- Update copilot instructions with transaction confirmation pattern
- Added telegram_command_bot.py with slash commands (/buySOL, /sellBTC, etc)
- Docker compose setup with DNS configuration
- Sends trades as plain text to n8n webhook (same format as TradingView)
- Improved Telegram success message formatting
- Only responds to authorized chat ID (579304651)
- Commands: /buySOL, /sellSOL, /buyBTC, /sellBTC, /buyETH, /sellETH
