Updated Indicator Version Tracking section:
- Changed v8 from PRODUCTION to ARCHIVED (Nov 18-26)
- Added v9 as new PRODUCTION SYSTEM (Nov 26+)
- Documented v9 momentum-based SHORT filter (ADX + Price Position)
- Removed RSI filter rationale (RSI 50+ has best 68.2% WR)
- Added data evidence from 95 SHORT trade analysis
- Documented first day results: 2 losses, both blocked by momentum filter
Updated Stop Hunt Revenge System section:
- Added 'Revenge Timing Enhancement - 90s Confirmation' subsection
- Documented Nov 26 retest problem (would stop at $137.50 before $144.50 move)
- Explained Option 2 approach (90s = 1.5 minutes confirmation)
- Added implementation code snippets from stop-hunt-tracker.ts
- User insight: ATR not suitable (measures volatility, not S/R)
- Status: DEPLOYED Nov 26, 20:52:55 CET, VERIFIED
Related commits:
- 2017cba: v9 SHORT quality improvements - momentum-based filtering
- 40ddac5: Revenge timing Option 2 - 90s confirmation (DEPLOYED)
- Multi-Timeframe section: Added Nov 26 implementation note
- Quality scoring now calculated for ALL timeframes (not just 5min)
- Data collection signals get real quality scores (not hardcoded 0)
- BlockedSignal records include full quality metadata
- Enables SQL: WHERE signalQualityScore >= minScoreRequired
- Execute Trade workflow: Added timeframe routing logic
- When Making Changes: Added item #19 for multi-timeframe updates
- Reflects implementation in commit dbada47
- Complete architecture overview with ASCII diagram
- Database replication configuration and verification
- DNS failover monitor details (systemd service)
- Automatic failover sequence explanation
- Live test results from Nov 25, 2025 (90s detection, 0s downtime)
- Critical operational notes (firewall, ports, health checks)
- Manual failover and secondary update procedures
- Documentation references (DEPLOY_SECONDARY_MANUAL.md, HA_SETUP_ROADMAP.md)
- When making changes guidance for HA environment
Status: PRODUCTION READY ✅
All phases tested and validated with zero-downtime failover/failback
Created comprehensive agent prompt emphasizing:
- Mandatory reading of full copilot-instructions.md (4,400+ lines)
- VERIFICATION MANDATE must be understood before any work
- This is a real money system - every bug costs money
- Never declare 'done/fixed/working' without 100% verification
- Proper workflow: read → code → deploy → verify → document
Key Requirements:
- Check container timestamp > commit timestamp before declaring deployed
- Add logging to confirm changes execute
- Test in production with real data
- Check Common Pitfalls (60+ documented bugs) before coding
- Show verification results as proof, not just code appearance
Financial Stakes:
- User building from $901 → $100,000+ with this system
- Manual restarts = system failure
- Unverified changes = financial risk
- Every change affects real money positions
Prompt ensures agents understand the verification ethos and financial responsibility before starting any work.
REAL MONEY SYSTEM - NO EXCEPTIONS ON VERIFICATION
Changes:
- Moved VERIFICATION MANDATE to very top of copilot-instructions.md
- Added clear visual separators with ⚠️ and 🚨 emojis
- Made it unmissable: Must be read before any other instructions
- Added explicit definition of what 'working' means vs does NOT mean
- Emphasized: Deployment ≠ Working without verification
Added concrete example (Nov 25, 2025 Health Monitor Bug):
- What went wrong: Declared 'working' without testing
- What should have been done: Add logging, test API, verify errors recorded
- Lesson: Never trust code appearance, always verify with real data
Why this matters:
- User building from $901 → $100,000+ with this system
- Every unverified change is financial risk
- This is not a hobby project - it's user's financial future
- Declaring something working without proof = causing financial loss
Development Ethos:
- NEVER say done/finished without testing
- NEVER skip verification for 'simple' changes
- ALWAYS double-check new development for 100% functionality
- Code appearance ≠ Code correctness
- Deployment ≠ Feature working
This is mandatory for all AI agents working on this codebase.
User Request: Distinguish between SL and Trailing SL in analytics overview
Changes:
1. Position Manager:
- Updated ExitResult interface to include 'TRAILING_SL' exit reason
- Modified trailing stop exit (line 1457) to use 'TRAILING_SL' instead of 'SL'
- Enhanced external closure detection (line 937) to identify trailing stops
- Updated handleManualClosure to detect trailing SL at price target
2. Database:
- Updated UpdateTradeExitParams interface to accept 'TRAILING_SL'
3. Frontend Analytics:
- Updated last trade display to show 'Trailing SL' with special formatting
- Purple background/border for TRAILING_SL vs blue for regular SL
- Runner emoji (🏃) prefix for trailing stops
Impact:
- Users can now see when trades exit via trailing stop vs regular SL
- Better understanding of runner system performance
- Trailing stops visually distinct in analytics dashboard
Files Modified:
- lib/trading/position-manager.ts (4 locations)
- lib/database/trades.ts (UpdateTradeExitParams interface)
- app/analytics/page.tsx (exit reason display)
- .github/copilot-instructions.md (Common Pitfalls #61, #62)
- Added Adaptive Leverage System section in Architecture Overview
- Documented quality-based leverage tiers (95+ = 15x, 90-94 = 10x)
- Added configuration details and helper function usage
- Updated Configuration System with adaptive leverage integration
- Modified Execute Trade workflow to show early quality calculation
- Added critical execution order note (quality MUST be calculated before sizing)
- Added item #13 in When Making Changes section for adaptive leverage modifications
- Fixed numbering sequence (was duplicate 11s, now sequential 1-18)
- Cross-referenced ADAPTIVE_LEVERAGE_SYSTEM.md for complete details
Documented Nov 23, 2025 bug where monitoring loop created array snapshot
before async processing, causing removed trades to be processed twice.
Real incident:
- Trade cmibdii4k0004pe07nzfmturo (manual closure)
- 97% size reduction detected
- First iteration removed trade from Map
- Second iteration processed stale reference
- Result: Duplicate Telegram notifications
Fix: Added activeTrades.has() guard at start of checkTradeConditions()
Prevents duplicate processing when trade removed during loop iteration
Also documented:
- Quality threshold .env discrepancy (81 vs 91)
- Settings UI restart requirement
- Why Next.js modules need container restart for env changes
Related to Common Pitfall #59 (Layer 2 ghost detection duplicates)
but different trigger - normal monitoring vs rate limit storm detection
Updates to copilot-instructions.md:
- Multi-Timeframe Price Tracking System section enhanced
- BlockedSignalTracker purpose clarified: validates quality 91 threshold
- Current Status updated with Nov 22 enhancement details
- First false negative result documented (quality 80, +0.52% missed profit)
Signal Quality Scoring section:
- Added 'Threshold Validation In Progress' subsection
- User observation documented: 'green dots shot up'
- Data collection criteria defined (20-30 blocked signals)
- Decision framework added: Keep 91 vs lower to 85 vs adjust weights
- Possible outcomes listed for data-driven optimization
Next Steps:
- Continue collecting quality-blocked signal data (2-4 weeks)
- Target: 20-30 signals with complete price tracking
- SQL analysis: Compare blocked signal win rate vs executed trades
- Decision: Validate quality 91 threshold or adjust based on data
Purpose: Complete documentation of missed opportunity discovery and
validation plan for quality threshold optimization.
Enhanced Multi-Timeframe Price Tracking System documentation:
- Clarified that quality-blocked signals get tracked (not just timeframes)
- Added QUALITY_SCORE_TOO_LOW to blockReason types (Nov 21: threshold 91+)
- Included SQL query example for analyzing missed winners
- Decision Making section now covers threshold optimization
Context: User asked about 80-quality bounce play that shot up
- System correctly blocked it (ADX 16.6, quality 80 < 91 threshold)
- BlockedSignalTracker captures all price movement for 30 minutes
- Enables data-driven analysis: are we filtering too many winners?
- Stick with trend-following for now, let data accumulate for future optimization
Current tracker status: 8 tracked, 6 complete (75%), 50% TP1 hit rate
- Updated .github/copilot-instructions.md key constraints and signal quality system description
- Updated config/trading.ts minimum score from 60 to 81 with v8 performance rationale
- Updated SIGNAL_QUALITY_SETUP_GUIDE.md intro to reflect 81 threshold
- Updated SIGNAL_QUALITY_OPTIMIZATION_ROADMAP.md current system section
- Updated BLOCKED_SIGNALS_TRACKING.md quality score requirements
Context: After v8 Money Line indicator deployed with 0.6% flip threshold,
system achieving 66.7% win rate with average quality score 94.2. Raised
minimum threshold from 60 to 81 to maintain exceptional selectivity.
Current v8 stats: 6 trades, 4 wins, $649.32 profit, 94.2 avg quality
Account growth: $540 → $1,134.92 (110% gain in 2-3 days)
**ISSUE:** User operates at 100% capital allocation - no room for 1.2x sizing
- 1.2x would require 120% of capital (mathematically impossible)
- User: 'thats not gonna work. we are already using 100% of our portfolio'
**FIX:** Changed from 1.2x to 1.0x (same size as original trade)
- Focus on capturing reversal, not sizing bigger
- Maintains aggressive 15x leverage
- Example: Original ,350 → Revenge ,350 (not 0,020)
**FILES CHANGED:**
- lib/trading/stop-hunt-tracker.ts: sizingMultiplier 1.2 → 1.0
- Telegram notification: Updated to show 'same as original'
- Documentation: Updated all references to 1.0x strategy
**DEPLOYED:** Nov 20, 2025 ~20:30 CET
**BUILD TIME:** 71.8s, compiled successfully
**STATUS:** Container running stable, stop hunt tracker operational
- Updated section header: Nov 16, 2025 → Nov 16, 2025 - Enhanced Nov 20, 2025
- Added TP1 partial close notification to implemented features list
- Enhanced notification format example with runner split
- Added Key Features section explaining immediate TP1 feedback
- Updated commits list: b1ca454 (Nov 16) + 79e7ffe (Nov 20)
- Clarified separate notifications for TP1 and runner closures
**CRITICAL: Documentation is now a NON-NEGOTIABLE requirement**
- Added ironclad rule: Every git commit MUST update copilot-instructions.md
- NO EXCEPTIONS - this is a real money trading system
- Undocumented fixes = forgotten fixes = financial losses
- Future AI agents need complete context for data integrity
**What must be documented:**
- Bug fixes → Common Pitfalls (symptom, root cause, fix, lesson)
- New features → Architecture Overview, Critical Components
- Database changes → Important fields, filtering requirements
- Config changes → Configuration System section
- Breaking changes → When Making Changes section
**Examples of proper documentation:**
- Common Pitfall #56: Ghost orders (a3a6222)
- Common Pitfall #57: P&L inaccuracy (8e600c8)
- Common Pitfall #55: BlockedSignalTracker (6b00303)
**This is not optional - documentation is part of 'done'**
- Documented Nov 20, 2025 fix for 36% P&L calculation errors
- External closure handler was using monitoring loop's stale currentPrice
- Real incident: Database -$101.68 vs Drift -$138.35 actual
- Fix: Query Drift's userAccount.perpPositions[].settledPnl directly
- Fallback to calculation if Drift query fails
- Updated #56 commit reference from [pending] to a3a6222
- Both fixes deployed Nov 20, 2025 15:25 CET
- Added order cancellation to Position Manager's external closure handler
- When on-chain SL/TP orders close position, remaining orders now cancelled automatically
- Prevents ghost orders from triggering unintended positions
- Real incident: Nov 20 SHORT stop-out left 32 ghost orders on Drift
- Risk: Ghost TP1 at $140.66 could fill later, creating unwanted LONG position
- Fix: Import cancelAllOrders() and call after trade removed from monitoring
- Non-blocking: Logs errors but doesn't fail trade closure if cancellation fails
- Files: lib/trading/position-manager.ts (external closure handler ~line 920)
- Documented as Common Pitfall #56
- Documented Nov 20, 2025 fix for multi-timeframe data collection
- Tracker was using Pyth cache (empty) instead of Drift oracle prices
- Result: 30+ hours with no price tracking, all priceAfter* fields NULL
- Fix: Changed to initializeDriftService() + getOraclePrice()
- Now working: Price tracking every 5min, analysisComplete transitions, TP/SL detection
- Impact: Multi-timeframe data collection now operational for Phase 1 analysis
Documented critical bug where runner trailing stop never activated after TP1:
- Symptom: Runner exposed to full reversal with static SL
- Real incident: 24 profit at risk, user forced manual close
- Root cause: External closure detected before TP2 price check
- Fix: Three-part solution with TP2 pre-check, diagnostics, exit reason detection
- Impact: Runner now fully autonomous with trailing protection
Also renumbered subsequent pitfalls 43→45, 44→46, etc. for consistency.
Commit: 55582a4 "critical: Fix runner trailing stop protection after TP1"
Documented the stats API bug where recalculating P&L from entry/exit
prices doesn't work for TP1+runner partial closes.
Issue:
- Stats showed -$26.10 when actual was +$46.97
- Recalculation used average exit price × full size
- Doesn't account for different TP1 vs runner exit prices
Fix:
- Use database realizedPnL field directly
- Database values corrected to match Drift UI TP1+runner sums
- Each trade shows as 2 lines in Drift (TP1 + runner)
Commits referenced:
- cd6f590: Corrected database P&L values
- d8b0307: Fixed stats API calculation
Lesson: Partial closes require storing combined P&L, can't
recalculate from average exit price.
Corrected misleading statement that implied 5.1x trading gains.
Reality: 46 total invested (06 + 40 deposits), 40 current = - trading P&L
Changes:
- Removed '5.1x in 8 days!' claim (was deposit-driven, not trading)
- Added 'Total Invested' line showing 46 actual capital input
- Added 'Trading P&L: -' to show early testing results
- Clarified losses from v6/v7 indicator testing before v8 optimization
Honesty matters - deposits ≠ profits. System is in proof phase.
- Multi-Timeframe Price Tracking System section (Nov 19, 2025)
- Purpose and architecture overview
- BlockedSignalTracker background job details
- Database schema with price tracking fields
- API endpoints and integration points
- How it works (step-by-step flow)
- Analysis queries for cross-timeframe comparison
- Decision-making criteria for timeframe optimization
- Current status: 2 signals tracked, pending 4H/Daily alerts
- Docker Maintenance section (Item #13 in When Making Changes)
- Cleanup commands: image prune, builder prune, volume prune
- When to run: After builds, weekly, on disk warnings
- Space savings: 2-5GB images, 40-50GB cache, 0.5-1GB volumes
- Safety guidelines: What to delete vs keep
- Why critical: Prevent disk full from build cache accumulation
User requested: 'document in the copilot instructions with the latest updates'
Both sections provide complete reference for future AI agents
Two P&L corrections for v8 trades:
1. First losing trade: Updated from -7.88 to -9.93 (matches Drift UI)
2. Phantom trade bug: Updated from /bin/bash.00 to 4.19 (TP1 + runner combined)
Corrected v8 stats:
- 5 trades, 80% win rate
- Total P&L: 1.06 (was 6.87 before corrections)
- Average: 4.21 per trade
- System recovered all previous losses and turned profitable
Related: Common Pitfall #49 (P&L compounding) and #53 (phantom detection)
caused the /bin/bash.00 entry. Database now reflects actual Drift results.
Documents the TP1 detection bug where on-chain limit orders fill faster
than Position Manager monitoring loop can detect. When both TP1 (75%)
and runner (25%) close before next monitoring cycle, PM doesn't know
TP1 filled first, marks entire closure as 'SL' instead of 'TP1'.
Fix uses profit percentage thresholds instead of state flags:
- >1.2%: TP2 range
- 0.3-1.2%: TP1 range
- <0.3%: SL range
Simpler and more reliable than tracking order fill state.
Common Pitfall #50 updated with resolution details:
- Bug fixed: Removed previouslyRealized from external closure calculations
- Database corrected: 3 v8 trades updated with accurate P&L values
- System operational: New trade executed successfully at 08:40 CET
- Analytics baseline established: -$8.74 total P&L, 66.7% WR, 3 trades
Historical data gap (~3 trades) explains difference between
analytics (-$8.74) and Drift UI (~-$52). All future trades
will track accurately with fixed calculation.
Ready for Phase 1: Collect 50+ v8 trades for statistical validation.
- Database shows only 3 v8 trades when Drift UI shows 6 trades
- One trade has 10x inflated P&L (81 vs 9 expected)
- Bot receiving ZERO API requests after 06:51 restart despite n8n executions succeeding
- Real v8 performance: ~2 LOSS (from Drift), database shows 20 profit (WRONG)
- Two issues: P&L compounding bug still active + n8n→bot connection broken
- Need to verify n8n workflow endpoints and fix external closure P&L calculation
- Common Pitfall #50 added to copilot-instructions.md
- Updated copilot instructions with data collection system overview
- Documents 5min execute vs 15min/1H/4H/Daily collect pattern
- Explains zero-risk parallel data collection approach
- Notes SQL analysis capability for timeframe optimization
- References implementation location in execute endpoint
- Part of v8 indicator testing and optimization strategy
Documents the critical P&L compounding bug fixed in commit 6156c0f where
trade.realizedPnL mutation during external closure detection caused 15-20x
inflation of actual profit/loss values.
Includes:
- Root cause: Mutating trade.realizedPnL in monitoring loop
- Real incident: $6 actual profit → $92.46 in database
- Bug mechanism with code examples
- Why previous fixes (Common Pitfalls #27, #48) didn't prevent this
- Fix: Don't mutate shared state during calculations
- Related to other P&L compounding variants for cross-reference
- Document ATR × multiplier system (2.0/4.0/3.0 for TP1/TP2/SL)
- Add calculation formula and example with SOL at $140
- Document safety bounds (MIN/MAX percentages)
- Include data-driven ATR values (SOL median 0.43 from 162 trades)
- Document ENV configuration variables
- Add regime-agnostic benefits explanation
- Update Exit Strategy section with ATR-based details
- Update Telegram manual trade presets with accurate ATR
- Add TradingView integration requirements
- Update 'When Making Changes' with ATR modification guidance
- Explain performance analysis and expected improvements
Why: Major system upgrade (Nov 17, 2025) requires complete documentation
for future AI agents and developers. ATR-based targets solve bull/bear
optimization bias by adapting to actual market volatility.
Problem:
- Close transaction confirmed but Drift state takes 5-10s to propagate
- Position Manager returned needsVerification=true to keep monitoring
- BUT: Monitoring loop detected position as 'externally closed' EVERY 2 seconds
- Each detection called handleExternalClosure() and added P&L to database
- Result: .66 actual profit → 73.36 in database (20x compounding)
- Logs showed: $112.96 → $117.62 → $122.28 → ... → $173.36 (14+ updates)
Root Cause:
- Common Pitfall #47 fix introduced needsVerification flag to wait for propagation
- But NO flag to prevent external closure detection during wait period
- Monitoring loop thought position was 'closed externally' on every cycle
- Rate limiting (429 errors) made it worse by extending wait time
Fix (closingInProgress flag):
1. Added closingInProgress boolean to ActiveTrade interface
2. Set flag=true when needsVerification returned (close confirmed, waiting)
3. Skip external closure detection entirely while flag=true
4. Timeout after 60s if stuck (abnormal case - allows cleanup)
Impact:
- Every close with verification delay (most closes) had 10-20x P&L inflation
- This is variant of Common Pitfall #27 but during verification, not external closure
- Rate limited closes were hit hardest (longer wait = more compounding cycles)
Files:
- lib/trading/position-manager.ts: Added closingInProgress flag + skip logic
Incident: Nov 16, 11:50 CET - SHORT 41.64→40.08 showed 73.36 vs .66 real
Documented: Common Pitfall #48
- Extended verification checklist for sessions with multiple related fixes
- Added requirement to verify container newer than ALL commits
- Included example from Nov 16 session (3 fixes deployed together)
- Added bash commands for complete deployment verification
- Emphasized that ALL fixes must be deployed, not just latest commit
- Updated Common Pitfall #47 with deployment verification commands
- Prevents declaring fixes 'working' when only some are deployed
- Added comprehensive documentation for close verification gap bug
- Real incident: 6 hours unmonitored exposure after close confirmation
- Root cause: Transaction confirmed ≠ Drift state propagated (5-10s delay)
- Fix: 5s wait + verification + needsVerification flag for Position Manager
- Prevents premature database 'closed' marking while position still open
- TypeScript interface updated: ClosePositionResult.needsVerification
- Deployed: Nov 16, 2025 09:28:20 CET
- Commits: c607a66 (logic), b23dde0 (interface)
