ISSUE: Quality 95 trade stopped out today (ID: cmiueo2qv01coml07y9kjzugf)
but stop hunt was NOT recorded in database for revenge system.
ROOT CAUSE: logger.log() calls for revenge recording were silenced in production
(NODE_ENV=production suppresses logger.log output)
FIX: Changed 2 logger.log() calls to console.log() in position-manager.ts:
- Line ~1006: External closure revenge eligibility check
- Line ~1742: Software-based SL revenge activation
Now revenge system will properly record quality 85+ stop-outs with visible logs.
Trade details:
- Symbol: SOL-PERP LONG
- Entry: $133.74, Exit: $132.69
- Quality: 95, ADX: 28.9, ATR: 0.22
- Loss: -$26.94
- Exit time: 2025-12-06 15:16:18
This stop-out already expired (4-hour window ended at 19:16).
Next quality 85+ SL will be recorded correctly.
Added to copilot-instructions.md Common Pitfalls section:
PITFALL #73: Service Initialization Never Ran (Dec 5, 2025)
- Duration: 16 days (Nov 19 - Dec 5)
- Financial impact: 00-1,400 (k user estimate)
- Root cause: Services after validation with early return
- Affected: Stop hunt revenge, smart validation, blocked signal tracker, data cleanup
- Fix: Move services BEFORE validation (commits 51b63f4, f6c9a7b, 35c2d7f)
- Prevention: Test suite, CI/CD, startup health checks, console.log for critical logs
- Full docs: docs/CRITICAL_SERVICE_INITIALIZATION_BUG_DEC5_2025.md
DISCOVERY (Dec 5, 2025):
- 4 critical services never started since Nov 19 (16 days)
- Services placed AFTER validation with early return
- Silent failure: no errors, just never initialized
AFFECTED SERVICES:
- Stop Hunt Revenge Tracker (Nov 20) - No revenge attempts
- Smart Entry Validation (Nov 30) - Manual trades used stale data
- Blocked Signal Tracker (Nov 19) - No threshold optimization data
- Data Cleanup (Dec 2) - Database bloat
FINANCIAL IMPACT:
- Stop hunt revenge: 00-600 lost (missed reversals)
- Smart validation: 00-400 lost (stale data entries)
- Blocked signals: 00-400 lost (suboptimal thresholds)
- TOTAL: 00-1,400 (user estimate: ,000)
ROOT CAUSE:
Line 43: validateOpenTrades() with early return at line 111
Lines 59-72: Service initialization AFTER validation
Result: When no open trades → services never reached
FIX COMMITS:
- 51b63f4: Move services BEFORE validation
- f6c9a7b: Use console.log for production visibility
- 35c2d7f: Fix stop hunt tracker logs
PREVENTION:
- Test suite (PR #2): 113 tests
- CI/CD pipeline (PR #5): Automated quality gates
- Service startup validation in future CI
- Production logging standard: console.log for critical operations
STATUS: ✅ ALL SERVICES NOW ACTIVE AND VERIFIED
- logger.log is silenced in production (NODE_ENV=production)
- Service initialization logs were hidden even though services were starting
- Changed to console.log for visibility in production logs
- Affects: data cleanup, blocked signal tracker, stop hunt tracker, smart validation
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>
