- 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
Implemented comprehensive price tracking for multi-timeframe signal analysis.
**Components Added:**
- lib/analysis/blocked-signal-tracker.ts - Background job tracking prices
- app/api/analytics/signal-tracking/route.ts - Status/metrics endpoint
**Features:**
- Automatic price tracking at 1min, 5min, 15min, 30min intervals
- TP1/TP2/SL hit detection using ATR-based targets
- Max favorable/adverse excursion tracking (MFE/MAE)
- Analysis completion after 30 minutes
- Background job runs every 5 minutes
- Entry price captured from signal time
**Database Changes:**
- Added entryPrice field to BlockedSignal (for price tracking baseline)
- Added maxFavorablePrice, maxAdversePrice fields
- Added maxFavorableExcursion, maxAdverseExcursion fields
**Integration:**
- Auto-starts on container startup
- Tracks all DATA_COLLECTION_ONLY signals
- Uses same TP/SL calculation as live trades (ATR-based)
- Calculates profit % based on direction (long vs short)
**API Endpoints:**
- GET /api/analytics/signal-tracking - View tracking status and metrics
- POST /api/analytics/signal-tracking - Manually trigger update (auth required)
**Purpose:**
Enables data-driven multi-timeframe comparison. After 50+ signals per
timeframe, can analyze which timeframe (5min vs 15min vs 1H vs 4H vs Daily)
has best win rate, profit potential, and signal quality.
**What It Tracks:**
- Price at 1min, 5min, 15min, 30min after signal
- Would TP1/TP2/SL have been hit?
- Maximum profit/loss during 30min window
- Complete analysis of signal profitability
**How It Works:**
1. Signal comes in (15min, 1H, 4H, Daily) → saved to BlockedSignal
2. Background job runs every 5min
3. Queries current price from Pyth
4. Calculates profit % from entry
5. Checks if TP/SL thresholds crossed
6. Updates MFE/MAE if new highs/lows
7. After 30min, marks analysisComplete=true
**Future Analysis:**
After 50+ signals per timeframe:
- Compare TP1 hit rates across timeframes
- Identify which timeframe has highest win rate
- Determine optimal signal frequency vs quality trade-off
- Switch production to best-performing timeframe
User requested: "i want all the bells and whistles. lets make the
powerhouse more powerfull. i cant see any reason why we shouldnt"
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.
Two critical bugs caused by container restart:
1. **Startup order restore failure:**
- Wrong field names: takeProfit1OrderTx → tp1OrderTx
- Caused: Prisma error, orders not restored, position unprotected
- Impact: Container restart left position with NO TP/SL backup
2. **Phantom detection killing runners:**
- Bug: Flagged runners after TP1 as phantom trades
- Logic: (currentSize / positionSize) < 0.5
- Example: $3,317 runner / $8,325 original = 40% = PHANTOM!
- Result: Set P&L to $0.00 on profitable runner exit
Fixes:
- Use correct DB field names (tp1OrderTx, tp2OrderTx, slOrderTx)
- Phantom detection only checks BEFORE TP1 hit
- Runner P&L calculated on currentSize, not originalPositionSize
- If TP1 hit, we're closing the RUNNER (currentSize)
- If TP1 not hit, we're closing FULL position (originalPositionSize)
Real Impact (Nov 19, 2025):
- SHORT $138.355 → Runner trailing at $136.72 (peak)
- Container restart → Orders failed to restore
Closed with $0.00 P&L
- Actual profit from Drift: ~$54.41 (TP1 + runner combined)
Prevention:
- Next restart will restore orders correctly
- Runners will calculate P&L properly
- No more premature closures from schema errors
The ADX-based runner SL logic was only applied in the direct price
check path (lines 1065-1086) but NOT in the on-chain fill detection
path (lines 590-650).
When TP1 fills via on-chain order (most common), the system was using
hard-coded breakeven SL instead of ADX-based positioning.
Bug Impact:
- ADX 20.0 trade got breakeven SL ($138.355) instead of -0.3% ($138.77)
- Runner has $0.42 less room to breathe than intended
- Weak trends protected correctly but moderate/strong trends not
Fix:
- Applied same ADX-based logic to on-chain fill detection
- Added detailed logging for each ADX tier
- Runner SL now correct regardless of TP1 trigger path
Current trade (cmi5zpx5s0000lo07ncba1kzh):
- Already hit TP1 via old code (breakeven SL active)
- New ADX-based SL will apply to NEXT trade
- Current position: SHORT $138.3550, runner at breakeven
Code paths with ADX logic:
1. Direct price check (lines 1050-1100) ✅
2. On-chain fill detection (lines 607-642) ✅ FIXED
Changed PROFIT_LOCK_AFTER_TP1_PERCENT from 0.3% to -0.55%
Reasoning based on user's chart analysis:
- Entry signals trigger on candle close = always entering at top
- Price naturally retraces below entry (screenshots show -1% to -1.5%)
- Old 0.3% profit lock would stop runner out on normal retracements
- New -0.55% allows breathing room while TP1 profit already banked
Risk/Reward:
- 60% already closed at TP1 profit (guaranteed)
- 40% runner can handle -0.55% pullback without stopping out
- Worst case: -0.55% on 40% = -0.22% total position loss
- Best case: Runner catches 38% MFE moves with ADX trailing stop
Example (entry at $140):
- TP1: $140.86 → 60% closed ✅
- Runner SL: $139.23 (-0.55%)
- Allows pullback to $139.30-139.50 (typical retracement)
- TP2 trigger: $141.72 → ADX trail activates
- Captures big trend moves instead of premature runner stops
Settings UI was using wrong variable name (MIN_QUALITY_SCORE) while
code reads MIN_SIGNAL_QUALITY_SCORE. This caused quality score changes
in settings UI to have no effect.
Fixed:
- Settings API now reads/writes MIN_SIGNAL_QUALITY_SCORE
- Updated .env file to use correct variable name
- User's quality score increase to 81 will now work
Related: User increased min quality from 60 to 81 to filter out
small chop trades (avoiding -$99 trade with quality score 80).
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.
Problem: When TP1 order fills on-chain and runner closes quickly,
Position Manager detects entire position gone but doesn't know TP1 filled.
Result: Marks trade as 'SL' instead of 'TP1', closes 100% instead of partial.
Root cause: Position Manager monitoring loop only knows about trade state
flags (tp1Hit), not actual Drift order fill history. When both TP1 and
runner close before next monitoring cycle, tp1Hit=false but position gone.
Fix: Use profit percentage to infer exit reason instead of trade flags
- Profit >1.2%: TP2 range
- Profit 0.3-1.2%: TP1 range
- Profit <0.3%: SL/breakeven range
Always calculate P&L on full originalPositionSize for external closures.
Exit reason logic determines what actually triggered based on P&L amount.
Example from Nov 19 08:40 CET trade:
- Entry $140.17, Exit $140.85 = 0.48% profit
- Old: Marked as 'SL' (tp1Hit=false, didn't know TP1 filled)
- New: Will mark as 'TP1' (profit in TP1 range)
Lines changed: lib/trading/position-manager.ts:760-835
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.
Root cause: trade.realizedPnL was reading from in-memory ActiveTrade object
which could have stale/mutated values from previous detection cycles.
Bug sequence:
1. External closure detected, calculates P&L including previouslyRealized
2. Updates database with totalRealizedPnL
3. Same closure detected again (due to race condition or rate limits)
4. Reads previouslyRealized from same in-memory object (now has accumulated value)
5. Adds MORE P&L to it, compounds 2x, 5x, 10x
Real impact: 9 expected P&L became 81 (10x inflation)
Fix: Remove previouslyRealized from calculation entirely for external closures.
External closures calculate ONLY the current position P&L, not cumulative.
Database will have correct cumulative value if TP1 was processed separately.
Lines changed: lib/trading/position-manager.ts:785-803
- Removed: const previouslyRealized = trade.realizedPnL
- Removed: previouslyRealized + runnerRealized
- Now: totalRealizedPnL = runnerRealized (ONLY this closure's P&L)
Tested: Build completed successfully, container deployed and monitoring positions
- 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
- Changed 'Avg MFE: +X.XX%' to 'Avg MFE: +$X.XX'
- Changed 'Avg MAE: -X.XX%' to 'Avg MAE: -$X.XX'
- Database already stores dollar values (fixed Nov 19)
- UI was incorrectly displaying dollars with % suffix
- V8 trades: Avg MFE $34.23, Avg MAE -$11.06 (correct)
- Part of MAE/MFE data corruption fix series
Also corrected existing v8 trade in database:
- Before: MFE 19.73% (account %), MAE -1.53% (account %)
- After: MFE $95.11, MAE -$7.39 (actual dollars)
- SQL: UPDATE based on maxFavorablePrice/maxAdversePrice
- TypeScript error: Cannot find name 'accountPnL'
- Removed account percentage from monitoring logs
- Now shows: MFE/MAE in dollars (not percentages)
- Part of Nov 19 MAE/MFE dollar fix
CRITICAL BUGS FIXED (Nov 19, 2025):
1. MAE/MFE Bug:
- Was storing: account percentage (profit % × leverage)
- Example: 1.31% move × 15x = 19.73% stored as MFE
- Should store: actual dollar P&L (81 not 19.73%)
- Impact: Telegram shows 'Max Gain: +19.73%' instead of '+.XX'
- Fix: Changed from accountPnL (leverage-adjusted %) to currentPnLDollars
- Lines 964-987: Removed accountPnL calculation, use currentPnLDollars
2. Duplicate Notification Bug:
- handleExternalClosure() was checking if trade removed AFTER removal
- Result: 16 duplicate Telegram notifications with compounding P&L
- Example: 6 → 2 → 11 → ... → 81 (16 notifications for 1 close)
- Fix: Check if trade already removed BEFORE processing
- Lines 382-391: Move duplicate check to START of function
- Early return prevents notification send if already processed
3. Database Compounding (NOT A BUG):
- Nov 17 fix (Common Pitfall #49) still working correctly
- Only 1 database record with 81 P&L
- Issue was notification duplication, not DB duplication
IMPACT:
- MAE/MFE data now usable for TP/SL optimization
- Telegram notifications accurate (1 per close, correct P&L)
- Database analytics will show real dollar movements
- Next trade will have correct Max Gain/Drawdown display
FILES:
- lib/trading/position-manager.ts: MAE/MFE calculation + duplicate check
- 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
- TypeScript build error: currentPrice not in interface
- Correct field name is signalPrice (already defined)
- Fixes multi-timeframe data collection compilation
- Only 5min signals execute trades (production)
- 15min/1H/4H/Daily signals saved to BlockedSignal table for analysis
- Enables cross-timeframe performance comparison
- Zero financial risk - non-5min signals just collect data
- blockReason: 'DATA_COLLECTION_ONLY' for easy filtering
- Returns HTTP 200 (not 400) since this is expected behavior
- Prepares for future timeframe optimization decisions
- Added v8 Money Line indicator status to master roadmap
- Updated signal quality roadmap with v8 deployment (Nov 18)
- Ready for live testing and v6 vs v8 comparison
- Awaiting first signals with indicatorVersion='v8' tracking
Added comprehensive section explaining:
- How the indicator works (simple terms)
- What creates the line (ATR, multiplier, HalfTrend)
- v8 improvements (flip threshold, entry buffer, stickier bands)
- Simple analogy (traffic light for trading)
- Version comparison (v6/v7/v8)
Makes it easy to explain the system to others
V8 improvements to handle small bounces in strong trends:
- Increased flip threshold: 0.5% → 0.8% (stronger move required)
- Added confirmBars: 2 bars required after threshold breach
- Momentum tracking: Counts consecutive bars in new direction
- Anti-whipsaw: Flip only after 3 consecutive bars (confirmBars+1) beyond threshold
Example: In downtrend, price must close >0.8% above line for 3 bars before flipping bullish
This filters 1-2 bar bounces that don't change the macro trend
Result: Far fewer false reversals during strong directional moves
V8 Changes (fundamental improvements, not just filter toggles):
- Increased ATR multipliers across all timeframes (stickier line)
- Minutes: 3.3→3.8
- Hours: 3.0→3.5
- Daily: 2.8→3.2
- Weekly: 2.5→3.0
- NEW flip threshold (0.5%): Requires price to move beyond line by % before color changes
- Entry buffer enabled by default (0.20 ATR vs 0.15)
- ADX minimum increased to 18 (from 14) for stronger trend requirement
- Core HalfTrend logic modified to require threshold breach before flip
Goal: Reduce flip-flops while maintaining high-quality trend signals
Test against v6 (filtered) and v7 (pure flips) for comparison
- Created moneyline_v7_line_flips.pinescript
- Signals fire on EVERY line color change (red↔green)
- All filters removed - line flip IS the signal
- confirmBars = 0 for immediate flip bar signals
- Risk management via ATR-based TP/SL (bot-side)
- Restored v6 to original filtered mode
- v6: Conservative with all filters (ADX, volume, RSI, etc)
- v7: Aggressive pure flips for maximum accuracy
Rationale: Chart analysis shows ~100% accuracy on line flips
Every green section = price up, every red section = price down
ATR-based stops handle risk, no need for entry filters
- Moved positionManager.addTrade() to AFTER database save succeeds
- Changed database error handling to return HTTP 500 (not silent fail)
- Test endpoint now enforces same pattern as execute endpoint
- Prevents untracked positions when database save fails
- Root cause of trade manual-1763391075992 compounding to -19.43
Before: Test endpoint added to Position Manager first, saved to DB after
After: Test endpoint saves to DB first, only adds to PM if DB succeeds
Impact: No more untracked positions from test trades with failed DB saves
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
- CRITICAL BUG: trade.realizedPnL was being mutated during each external closure detection
- This caused exponential compounding: $6 → $12 → $24 → $48 → $96
- Each time monitoring loop detected closure, it added previouslyRealized + runnerRealized
- But previouslyRealized was the ALREADY ACCUMULATED value from previous iteration
- Result: P&L compounded 15-20x on actual value
ROOT CAUSE (line 797):
const totalRealizedPnL = previouslyRealized + runnerRealized
trade.realizedPnL = totalRealizedPnL // ← BUG: Mutates in-memory trade object
Next detection cycle:
const previouslyRealized = trade.realizedPnL // ← Gets ACCUMULATED value
const totalRealizedPnL = previouslyRealized + runnerRealized // ← Adds AGAIN
FIX:
- Don't mutate trade.realizedPnL during external closure detection
- Calculate totalRealizedPnL locally, use for database update only
- trade.realizedPnL stays immutable after initial DB save
- Log message clarified: 'P&L calculation' not 'P&L snapshot'
IMPACT:
- Every external closure (TP/SL on-chain orders) affected
- With rate limiting, closure detected 15-20 times before removal
- Real example: $6 actual profit showed as $92.46 in database
- This is WORSE than duplicate notification bug - corrupts financial data
FILES CHANGED:
- lib/trading/position-manager.ts: Removed trade.realizedPnL mutation (line 799)
- Database manually corrected: $92.46 → $6.00 for affected trade
RELATED BUGS:
- Common Pitfall #48: closingInProgress flag prevents some duplicates
- But doesn't help if monitoring loop runs DURING external closure detection
- Need both fixes: closingInProgress + no mutation of trade.realizedPnL
- 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.
- Changed atrMultiplierForTp2 → atrMultiplierTp2 to match new interface
- Marked function as LEGACY for backward compatibility
- Resolves TypeScript build error
PROBLEM (Nov 16, 22:03):
- Ghost position closed with -$6.77 loss
- Validator cleanup removed orders
- Position existed on Drift with NO on-chain TP/SL
- Only Position Manager software protection active
- If bot crashes, position completely unprotected
FIX:
- Added restoreOrdersIfMissing() to startup validator
- Checks every verified position for orders
- Automatically places TP/SL if missing
- Updates database with order transaction IDs
BEHAVIOR:
- Runs on every container startup
- Validates all open positions
- Logs: '✅ {symbol} has X on-chain orders'
- Or: '⚠️ {symbol} has NO orders - restoring...'
- Provides dual-layer protection always
Impact: Eliminates unprotected position risk after
validator cleanups, container restarts, or order issues.
- Created /api/trading/place-exit-orders endpoint
- Created restore-orders.mjs script
- Issue: Next.js creates separate Drift instances per route
- Workaround: Use /api/trading/cancel-orders to remove orphaned orders
Current situation:
- 32 orphaned orders existed and were cancelled
- Position Manager should auto-place new orders
- Manual order placement endpoint needs refactoring
- Group trades by symbol before validation
- Keep only most recent trade per symbol
- Close older duplicates with DUPLICATE_CLEANUP reason
- Prevents reopening old closed trades when checking recent trades
Bug: Startup validator was reopening ALL closed trades for a symbol
if Drift showed one position, causing 3 trades to be tracked when
only 1 actual position existed on Drift.
Impact: Position Manager was tracking ghost positions, causing
confusion and potential missed risk management.
PROBLEM (User identified):
- Analytics showed 3 open trades when Drift UI showed only 1 position
- Database had 3 separate trade records all marked as 'open'
- Root cause: Drift has 1 POSITION + 3 ORDERS (TP/SL exit orders)
- Validator was incorrectly treating each as separate position
SOLUTION:
- Group database trades by symbol before validation
- If multiple DB trades exist for one Drift position, keep only MOST RECENT
- Close older duplicate trades with exitReason='DUPLICATE_CLEANUP'
- Properly handles: 1 Drift position → 1 DB trade (correct state)
RESULT:
- Database: 1 open trade (matches Drift reality)
- Analytics: Shows accurate position count
- Runs automatically every 10 minutes + manual trigger available
**The 4 Loss Problem:**
Multiple trades today opened opposite positions before previous closed:
- 11:15 SHORT manual close
- 11:21 LONG opened + hit SL (-.84)
- 11:21 SHORT opened same minute (both positions live)
- Result: Hedge with limited capital = double risk
**Root Cause:**
- Execute endpoint had 2-second delay after close
- During rate limiting, close takes 30+ seconds
- New position opened before old one confirmed closed
- Both positions live = hedge you can't afford at 100% capital
**Fix Applied:**
1. Block flip if close fails (don't open new position)
2. Wait for Drift confirmation (up to 15s), not just tx confirmation
3. Poll Drift every 2s to verify position actually closed
4. Only proceed with new position after verified closure
5. Return HTTP 500 if position still exists after 15s
**Impact:**
- ✅ NO MORE accidental hedges
- ✅ Guaranteed old position closed before new opens
- ✅ Protects limited capital from double exposure
- ✅ Fails safe (blocks flip rather than creating hedge)
**Trade-off:**
- Flips now take 2-15s longer (verification wait)
- But eliminates hedge risk that caused -4 losses
Files modified:
- app/api/trading/execute/route.ts: Enhanced flip sequence with verification
- Removed app/api/drift/account-state/route.ts (had TypeScript errors)
- Identified 25 trades with corrupted P&L from compounding bug
- Recalculated correct P&L for all affected trades (7 days)
- Total corrections: 63.23 in fake profits removed
- Today's actual P&L: -.97 (11 trades) - was showing -9.87 before fixes
- Last 7 days actual P&L: +7.04 (70 trades) - was showing +27.90
Bug pattern:
- P&L updated multiple times during close verification wait
- Each update added to previous value instead of replacing
- Worst case: -8.17 stored vs -.77 actual (7× compounding)
Root cause: Common Pitfall #48 - closingInProgress flag fix deployed
Nov 16 18:26 UTC but damage already done to historical data
Files modified:
- Database: 25 trades updated via SQL recalculation
- Fixed trades from Nov 10-16 with ABS(stored - calculated) > $1
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
