CRITICAL BUG DISCOVERED (Dec 5, 2025):
- validateOpenTrades() returns early at line 111 when no trades found
- Service initialization (lines 59-72) happened AFTER validation
- Result: When no open trades, services NEVER started
- Impact: Stop hunt tracker, smart validation, blocked signal tracking all inactive
ROOT CAUSE:
- Line 43: await validateOpenTrades()
- Line 111: if (openTrades.length === 0) return // EXIT EARLY
- Lines 59-72: Service startup code (NEVER REACHED)
FIX:
- Moved service initialization BEFORE validation
- Services now start regardless of open trades count
- Order: Start services → Clean DB → Validate → Init Position Manager
SERVICES NOW START:
- Data cleanup (4-week retention)
- Blocked signal price tracker
- Stop hunt revenge tracker
- Smart entry validation system
This explains why:
- Line 111 log appeared (validation ran, returned early)
- Line 29 log appeared (function started)
- Lines 59-72 logs NEVER appeared (code never reached)
Git commit SHA: TBD
Deployment: Requires rebuild + restart
- Lines 68-72 had only 2 spaces indent (outside try block)
- Services were executing AFTER catch block
- Fixed to 4 spaces (inside try block)
- Now stop hunt tracker, blocked signal tracker, smart validation will initialize properly
- 1-minute data is pure market sampling, not trading signals
- signalQualityVersion now null for timeframe='1'
- Other timeframes still labeled with v9
- Prevents confusion in analytics/reporting
Add `instrumentationHook: true` to `next.config.js` experimental section.
This fixes a critical bug where the instrumentation.ts file was not being
executed on server startup, causing all startup services to not run:
- Stop Hunt Revenge Tracker (93 revenge opportunities missed)
- Position Manager (no monitoring of open trades)
- Ghost Position Cleanup
- Data Cleanup Service
- Blocked Signal Tracking
- Smart Validation Queue
- Database Sync Validator
The instrumentation.ts file existed and contained proper initialization code,
but Next.js requires explicit opt-in via the experimental.instrumentationHook
flag to enable this feature.
Co-authored-by: mindesbunister <32161838+mindesbunister@users.noreply.github.com>
- Add version dropdown selector (v9, v8, v6, v5, all) to frontend
- Update backend API to accept ?version= query parameter
- Add version filter to all 5 broken SQL queries using Prisma parameterized queries
- Update Data Collection Status to use selected version instead of hardcoded v8
- Add version context to all recommendations
- Add URL encoding for version parameter (security best practice)
- Validate version parameter against whitelist (SQL injection protection)
Co-authored-by: mindesbunister <32161838+mindesbunister@users.noreply.github.com>
- Added STEP 1: Run tests BEFORE deployment (113 tests in ~30s)
- Added STEP 2: Validate with test trade AFTER deployment
- Why mandatory: Catch bugs (tokens vs USD, false TP1, wrong SL) before real money loss
- Tests prevent Common Pitfalls #24, #43, #45, #52, #54, #67 recurrence
- DO NOT deploy if tests fail - fix issue or update tests first
Added comprehensive feature discovery section to copilot-instructions.md:
- Quick Reference Table: 9 common scenarios with existing features
- Quick Search Commands: bash commands for feature discovery
- Feature Discovery by Category: 6 categories with 30+ features
- Decision Flowchart: 5-step verification process
- Historical Examples: why each feature was built
This helps users/AI agents discover existing features before rebuilding.
Co-authored-by: mindesbunister <32161838+mindesbunister@users.noreply.github.com>
- Commented out SOLANA_LEVERAGE=5 fixed override
- Adaptive leverage now applies to all SOL trades
- Quality ≥95 LONG 90 SHORT → 10x leverageor
- Quality 90-94 LONG or 80-89 SHORT → 5x leverage
- Expected: Higher leverage on high-confidence signals
- Only 31 records from multi-timeframe alerts (not 11,429)
- 11,398 records are 1-minute data (kept as DATA_COLLECTION_ONLY)
- Total marked as OLD_V9_VERSION: 31 (15min/1H/4H/Daily only)
- Discovery: All TradingView alerts (5min/15min/1H/4H/Daily) attached to OLD v9 version
- Impact: 11,429 records from wrong indicator settings (confirmBars=0 vs current)
- Solution: Marked as DATA_COLLECTION_OLD_V9_VERSION to prevent analysis contamination
- Exception: 1-minute data (11,398) kept as DATA_COLLECTION_ONLY (unaffected)
- Fresh data from corrected alerts will use DATA_COLLECTION_ONLY going forward
- Old data preserved for historical reference, clearly marked
CRITICAL LESSON LEARNED (Dec 5, 2025):
Document the data analysis disaster caused by MFE/MAE stored in mixed units.
What Happened:
- Analyzed blocked vs executed signals to improve win rate
- SQL showed executed signals: 20.15% avg MFE (appeared excellent)
- Implemented "optimizations" based on this data:
* Tighter ATR multipliers (2.0→1.5, 4.0→3.0)
* Higher TP1 close (60%→75%)
* Increased leverage (1×→5×)
- User questioned: Why doesn't TP1 hit if it's 20% MFE?
- Investigation: Only 2/11 trades reached TP1 price target
- Root cause: Old records stored MFE in DOLLARS, new in PERCENTAGES
- TRUE MFE: 0.76% (long), 1.20% (short) - NOT 20%!
- 26× inflation due to unit mismatch
Why This Matters:
- This is a REAL MONEY system - wrong analysis = wrong trades = losses
- MFE/MAE used for critical decisions (exit timing, quality validation)
- Agent made "data-driven" optimizations on 26× inflated data
- All changes had to be reverted (commits a67a338, f65aae5)
MANDATORY SQL Pattern:
- ALWAYS filter by createdAt >= '2025-11-23' for MFE/MAE queries
- OR recalculate from prices (maxFavorablePrice - entryPrice)
- NEVER trust raw AVG(maxFavorableExcursion) without date filter
Prevention:
- Verify stored vs calculated values before ANY MFE/MAE analysis
- Check sample of recent vs old records to detect unit changes
- Document data format changes in Common Pitfalls immediately
Related:
- Common Pitfall #54: Original MFE/MAE units bug (Nov 23, 2025)
- Revert commit: a15f17f
- Incorrect optimization: a67a338, f65aae5
CRITICAL DATA BUG DISCOVERED (Dec 5, 2025):
Previous commits a67a338 and f65aae5 implemented optimizations based on
INCORRECT analysis of maxFavorableExcursion (MFE) data.
Problem: Old Trade records stored MFE in DOLLARS, not PERCENTAGES
- Appeared to show 20%+ average favorable movement
- Actually only 0.76% (long) and 1.20% (short) average movement
- 26× inflation of perceived performance due to unit mismatch
Incorrect Changes Reverted:
- ATR_MULTIPLIER_TP1: 1.5 → back to 2.0
- ATR_MULTIPLIER_TP2: 3.0 → back to 4.0
- ATR_MULTIPLIER_SL: 2.5 → back to 3.0
- TAKE_PROFIT_1_SIZE_PERCENT: 75 → back to 60
- LEVERAGE: 5 → back to 1
- Safety bounds restored to original values
- TRAILING_STOP_ATR_MULTIPLIER: back to 2.5
REAL FINDINGS (after data correction):
- TP1 orders ARE being placed (tp1OrderTx populated)
- TP1 prices NOT being reached (only 2/11 trades in sample)
- Recent trades (6 total): avg MFE 0.74%, only 2/6 reached TP1
- Problem is ENTRY QUALITY, not exit timing
- Quality 90+ signals barely move favorably before reversing
See Common Pitfall #54 - MFE data stored in mixed units
Need to filter by createdAt >= '2025-11-23' for accurate analysis
- Add back "dev": true property for typescript in package-lock.json
- Ensures typescript stays as devDependency (not bundled in production)
- Build verified successful after change
Co-authored-by: mindesbunister <32161838+mindesbunister@users.noreply.github.com>
Updated copilot-instructions.md with:
- New ATR multipliers (1.5×/3.0×/2.5× vs 2.0×/4.0×/3.0×)
- Rationale: 0% TP hit rate despite 17-24% avg MFE
- Problem: Targets hit then reversed before monitoring loop detected
- Solution: Tighter targets catch moves before reversal
- 75% close at TP1 (vs 60%) to bank profit immediately
- 25% runner (vs 40%) for extended trends with tighter trail
- Leverage 5× during testing phase
This is MANDATORY documentation update per #1 priority rule.
- Added DUAL REMOTE SETUP section with origin (Gitea) and github (GitHub) configuration
- Documented post-commit hook location and purpose (.git/hooks/post-commit)
- Explained auto-sync to github vs manual push to origin workflow
- Added verification commands for sync status checking
- Included automation setup details and testing confirmation
- Updated commit workflow to reflect hook behavior
- Added recent example (de77cfe test commit) to demonstrate automation
- Added explanation for logger mocking in tests/setup.ts
- Removed test files from coverage collection in jest.config.js
- Updated tests/README.md to clarify coverage approach and remove outdated threshold reference
Co-authored-by: mindesbunister <32161838+mindesbunister@users.noreply.github.com>
- Created docs/COMMON_PITFALLS.md with all 72 pitfalls
- Organized by severity and category for better navigation
- Added quick reference table and cross-reference index
- Reduced copilot-instructions.md from 6,575 to 3,608 lines (45%)
- Kept Top 10 critical pitfalls in main instructions
- Preserved all git commits, dates, code examples
- Updated docs/README.md with references to new doc
Benefits:
- Faster AI agent context loading
- Easier maintenance and updates
- Better searchability by category
- Clear pattern recognition for similar issues
- Maintains comprehensive knowledge base
Co-authored-by: mindesbunister <32161838+mindesbunister@users.noreply.github.com>
User mandate: Manual Telegram trades bypass quality scoring entirely.
Documentation updates:
- Added 'Manual Trade Quality Bypass' section
- Explains user requirement for instant execution
- Documents implementation details (timeframe='manual' detection)
- Clarifies that analytics check is now advisory only
- Notes --force flag no longer needed for manual trades
Context: This is part of the mandatory documentation workflow -
every code change requires corresponding documentation update.
Related commit: 0982578 (quality bypass implementation)
Date: Dec 4, 2025
