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
User requirement: Manual long/short commands via Telegram shall execute
immediately without quality checks.
Changes:
- Execute endpoint now checks for timeframe='manual' flag
- Added isManualTrade bypass alongside isValidatedEntry bypass
- Manual trades skip quality threshold validation completely
- Logs show 'MANUAL TRADE BYPASS' for transparency
Impact: Telegram commands (long sol, short eth) now execute instantly
without being blocked by low quality scores.
Commit: Dec 4, 2025
- New IRON-CLAD RULE: Always search docs before making suggestions or asking questions
- Purpose: Prevent wasting user time with already-answered questions
- Examples: TradingView rate limits, roadmap features, known bugs, configuration
- Workflow: Read request → Search docs → Check if answered → THEN respond
- Applies to: Features, bugs, config, architecture, deployment, troubleshooting
- Red flags: User says 'we already documented this' or 'check docs first'
- Why: User spent months documenting comprehensively, 'NOTHING gets lost' principle
- Impact: Respect user's documentation effort, save time = save money in financial system
Files modified:
- .github/copilot-instructions.md (line ~103-150, added Rule #5 with examples and workflow)
- Worker2 (bd-host01) now only runs 19:00-06:00 due to noise
- Added is_worker_allowed_to_run() function for time-based control
- Worker1 continues 24/7 operation
- Reset stuck chunk 14 that was blocking progress since Dec 2
- Added explicit onboarding workflow at top of file
- 4-step sequence: copilot-instructions → docs/README → README → explore
- Lists all 8 documentation subdirectories with descriptions
- Emphasizes 'NOTHING gets lost' principle
- Ensures new agents have clear entry point without manual explanation
- Create moneyline_1min_price_feed.pinescript (70% smaller payload)
- Remove ATR/ADX/RSI/VOL/POS from 1-minute alerts (not used for decisions)
- Keep only price + symbol + timeframe for market data cache
- Document rationale in docs/1MIN_SIMPLIFIED_FEED.md
- Fix: 5-minute trading signals being dropped due to 1-minute flood (60/hour)
- Impact: Preserve priority for actual trading signals
- Added validatedEntry?: boolean to ExecuteTradeRequest interface
- Added originalQualityScore?: number to interface
- Added validationDelayMinutes?: number to interface
- Fixes TypeScript compilation error at line 231
- Required for Smart Validation Queue integration to work
Bug 1 Fix - Revenge System External Closures:
- External closure handler now checks if SL stop-out with quality 85+
- Calls stopHuntTracker.recordStopHunt() after database save
- Enables revenge trading for on-chain order fills (not just Position Manager closes)
- Added null safety for trade.signalQualityScore (defaults to 0)
- Location: lib/trading/position-manager.ts line ~999
Bug 5 Fix - Execute Endpoint Validated Entry Bypass:
- Added isValidatedEntry check before quality threshold rejection
- Smart Validation Queue signals (quality 50-89) now execute successfully
- Logs show bypass reason and validation details (delay, original quality)
- Only affects signals with validatedEntry=true flag from queue
- Location: app/api/trading/execute/route.ts line ~228
User Clarification:
- TradingView price issue (4.47) was temporary glitch, not a bug
- Only Bug 1 (revenge) and Bug 5 (execute rejection) needed fixing
- Both fixes implemented and TypeScript errors resolved
- Pitfall #68: Smart Entry using webhook percentage as signal price
* Root cause: TradingView webhook price field contained percentage (70.80) instead of market price (42.50)
* Impact: 97% pullback calculations made Smart Entry impossible to trigger
* Fix: Use Pyth current price instead of webhook price
* Commit: 7d0d38a
- Pitfall #69: Direction-specific leverage thresholds not explicit
* Made LONG/SHORT leverage assignment explicit even though values same
* Improves code clarity and maintainability
* Commit: 58f812f
Both fixes deployed Dec 3, 2025, 09:02:45 CET (timestamp verified)
PROBLEM:
Smart Entry showed 'Signal Price: $70.80' when actual SOL price was ~$139.70
Calculated 'Pullback: -97.38%' when actual price change was <1%
Smart Entry queue completely broken due to wrong price
ROOT CAUSE:
TradingView webhook (or n8n workflow) sends pricePosition percentage (73.77)
as signalPrice instead of actual dollar price ($139.70)
Code used body.signalPrice directly without validation
EVIDENCE:
Webhook payload: "pricePosition": 73.7704918033, "signalPrice": 73.7704918033
Identical values = pricePosition mapped incorrectly to signalPrice
Percentage value (0-100) treated as dollar price = 100× too low
FIXES:
1. Added detection: If signalPrice < $10, log warning (likely percentage)
2. Changed signalPrice source: Use currentPrice from Pyth (NOT body.signalPrice)
3. At signal time: priceChange = 0, pullbackMagnitude = 0 (no pullback yet)
4. Queue with correct price: Smart Entry timer gets current market price
5. Added comments explaining bug and fix
IMPACT:
Smart Entry will now use correct signal price ($130-150 for SOL)
Pullback calculations will be accurate (0.15-0.5% range, not 97%)
Queue will work correctly (wait for actual dips/bounces)
Next signal will validate fix in production logs
TESTING REQUIRED:
- Wait for next signal (LONG or SHORT)
- Verify log: 'Signal Price: $XXX.XX (using current market price)'
- Verify log: 'Current Price: $XXX.XX (same as signal)'
- Verify: No more -97% pullback calculations
- Verify: Smart Entry queues correctly if no pullback yet
FILES CHANGED:
- app/api/trading/execute/route.ts lines 485-555 (rewritten Smart Entry logic)
LOCATION:
- Line 495: Added currentPrice null check
- Line 502: Added percentage detection warning
- Line 507: Changed to use currentPrice as signalPrice
- Line 509-511: Set priceChange/pullback to 0 at signal time
- Line 517: Queue with corrected signalPrice
RELATED:
- Bug #2: Leverage thresholds (FIXED separately, commit 58f812f)
- Bug #3: Missing Telegram entry notifications (pending investigation)
PROBLEM: Quality 90 LONGs getting 5x instead of expected 10x leverage
ROOT CAUSE: ENV vars QUALITY_LEVERAGE_THRESHOLD_LONG/SHORT existed but never loaded in code
IMPACT: 50% smaller position sizes on quality 90-94 signals
FIXES:
1. Added qualityLeverageThresholdLong and qualityLeverageThresholdShort to TradingConfig interface
2. Added ENV loading for both direction-specific thresholds
3. Updated getLeverageForQualityScore() to use direction-specific thresholds
4. Added proper fallback hierarchy: direction-specific → backward compat → hardcoded default
5. Added console logs showing which threshold and leverage tier is applied
RESULT: Quality 90 LONGs will now get 10x leverage (highQualityLeverage)
Position sizes will double from ~$89 to ~$178
User reported: 'last trades were very small positions. no way near a 10 or 15x leverage'
This fix addresses that complaint - user expectation was correct, code was wrong.
Files: config/trading.ts (interface lines 20-27, ENV loading lines 520-532, function lines 673-730)
CRITICAL BUG FIX: Stop loss and take profit exits were sending duplicate
Telegram notifications with compounding P&L (16 duplicates, 796x inflation).
Real Incident (Dec 2, 2025):
- Manual SOL-PERP SHORT position stopped out
- 16 duplicate Telegram notifications received
- P&L compounding: $0.23 → $12.10 → $24.21 → $183.12 (796× multiplication)
- All showed identical: entry $139.64, hold 4h 5-6m, exit reason SL
- First notification: Ghost detected (handled correctly)
- Next 15 notifications: SL exit (all duplicates with compounding P&L)
Root Cause:
- Multiple monitoring loops detect SL condition simultaneously
- All call executeExit() before any can remove position from tracking
- Race condition: check closingInProgress → both true → both proceed
- Database update happens BEFORE activeTrades.delete()
- Each execution sends Telegram notification
- P&L values compound across notifications
Solution:
Applied same atomic delete pattern as ghost detection fix (commit 93dd950):
- Move activeTrades.delete() to START of executeExit() (before any async operations)
- Check wasInMap return value (only true for first caller, false for duplicates)
- Early return if already deleted (atomic deduplication guard)
- Only first loop proceeds to close, save DB, send notification
- Removed redundant removeTrade() call (already deleted at start)
Impact:
- Prevents duplicate notifications for SL, TP1, TP2, emergency stops
- Ensures accurate P&L reporting (no compounding)
- Database receives correct single exit record
- User receives ONE notification per exit (as intended)
Code Changes:
- Line ~1520: Added atomic delete guard for full closes (percentToClose >= 100)
- Line ~1651: Removed redundant removeTrade() call
- Both changes prevent race condition at function entry
Scope:
- ✅ Stop loss exits: Fixed
- ✅ Take profit 2 exits: Fixed
- ✅ Emergency stops: Fixed
- ✅ Trailing stops: Fixed
- ℹ️ Take profit 1: Not affected (partial close keeps position in monitoring)
Related:
- Ghost detection fix: commit 93dd950 (Dec 2, 2025) - same pattern, different function
- Manual trade enhancement: commit 23277b7 (Dec 2, 2025) - unrelated feature
- P&L compounding series: Common Pitfalls #48-49, #59-61, #67 in docs
PHASE 2 ENHANCED: Manual trades now wait for next 1-minute datapoint
instead of using cached/stale data. Guarantees fresh ATR (<60s old).
User requirement: 'when i send a telegram message to enter the market,
the bot will simply wait for the next 1 minute datapoint'
Implementation:
- Add wait_for_fresh_market_data() async helper function
- Polls market data cache every 5 seconds (max 60s)
- Detects fresh data by timestamp change
- Extracts real ATR/ADX/RSI from 1-minute TradingView data
- User sees waiting message + confirmation when fresh data arrives
- Falls back to preset ATR 0.43 on timeout (fail-safe)
Benefits:
- Adaptive targets match CURRENT volatility (not historical)
- No stale data risk (guaranteed <60s old)
- Better than Phase 2 v1 (5-minute tolerance)
- Consistent with automated trades (same 1-min data source)
User Experience:
1. User: /long sol
2. Bot: ⏳ Waiting for next 1-minute datapoint...
3. [Wait 15-45 seconds typically]
4. Bot: ✅ Fresh ATR: 0.4523 | ADX: 34.2 | RSI: 56.8
5. Bot: ✅ Position opened with adaptive targets
Changes:
- Add asyncio import for async sleep
- Add wait_for_fresh_market_data() before manual_trade_handler
- Replace Phase 2 v1 (5min tolerance) with polling logic
- Add 3 user messages (waiting, confirmation, timeout)
- Extract ATR/ADX/RSI from fresh data or fallback
Files:
- telegram_command_bot.py: +70 lines polling logic
Bug: 23 duplicate Telegram notifications with P&L compounding (-7.96 to -,129.24)
Cause: Multiple monitoring loops passed has() check before any deleted from Map
Fix: Use Map.delete() atomic return value as deduplication lock
Result: First caller deletes and proceeds, subsequent callers return immediately
Related: #48-49 (TP1 P&L compound), #59-61 (external closure duplicates)
Deployed: Dec 2, 2025 17:32:52 UTC (commit 93dd950)
Bug: Multiple monitoring loops detect ghost simultaneously
- Loop 1: has(tradeId) → true → proceeds
- Loop 2: has(tradeId) → true → ALSO proceeds (race condition)
- Both send Telegram notifications with compounding P&L
Real incident (Dec 2, 2025):
- Manual SHORT at $138.84
- 23 duplicate notifications
- P&L compounded: -$47.96 → -$1,129.24 (23× accumulation)
- Database shows single trade with final compounded value
Fix: Map.delete() returns true if key existed, false if already removed
- Call delete() FIRST
- Check return value
proceeds
- All other loops get false → skip immediately
- Atomic operation prevents race condition
Pattern: This is variant of Common Pitfalls #48, #49, #59, #60, #61
- All had "check then delete" pattern
- All vulnerable to async timing issues
- Solution: "delete then check" pattern
- Map.delete() is synchronous and atomic
Files changed:
- lib/trading/position-manager.ts lines 390-410
Related: DUPLICATE PREVENTED message was working but too late
CRITICAL UPDATES to AI assistant instructions:
1. MANDATORY GIT WORKFLOW (DO NOT SKIP):
- Added explicit requirement: implement → test → verify → document → commit → push
- Made git commits NON-OPTIONAL for all significant changes
- Added to both general prompt and copilot-instructions.md
- Rationale: Agent has pattern of skipping documentation/commits
2. CHALLENGE USER IDEAS:
- Added requirement to think critically about user requests
- Instruction: "Think freely and don't hold back"
- Goal: Find BEST solution, not just A solution
- Push back on ideas that don't make sense
- Ask "is there a simpler/faster/safer way?"
3. COMPREHENSIVE DOCUMENTATION SECTION:
- Replaced brief documentation note with full workflow guide
- Added 80+ lines of detailed documentation requirements
- Includes examples, red flags, mindset principles
- Emphasizes: "Git commit + Documentation = Complete work"
Files modified:
- .github/prompts/general prompt.prompt.md (added sections 5a, 6, updated 7-8)
- .github/copilot-instructions.md (comprehensive documentation workflow)
User mandate: "I am sick and tired of reminding you" - this makes it automatic.
Impact: Future implementations will ALWAYS include documentation and git commits as part of standard workflow, not as afterthoughts.
