From 5419b3f48f9f874507a59f962474528ed38710db Mon Sep 17 00:00:00 2001 From: mindesbunister Date: Fri, 21 Nov 2025 19:02:25 +0100 Subject: [PATCH] docs: Add quality-blocked signal tracking to copilot instructions 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 --- .github/copilot-instructions.md | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 2e086cc..5d05ac5 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -462,13 +462,14 @@ docker system df ## Multi-Timeframe Price Tracking System (Nov 19, 2025) -**Purpose:** Automated data collection and analysis for signals across multiple timeframes (5min, 15min, 1H, 4H, Daily) to determine which timeframe produces the best trading results. +**Purpose:** Automated data collection and analysis for signals across multiple timeframes (5min, 15min, 1H, 4H, Daily) to determine which timeframe produces the best trading results. **Also tracks quality-blocked signals** to analyze if threshold adjustments are filtering too many winners. **Architecture:** - **5min signals:** Execute trades (production) - **15min/1H/4H/Daily signals:** Save to BlockedSignal table with `blockReason='DATA_COLLECTION_ONLY'` +- **Quality-blocked signals:** Save with `blockReason='QUALITY_SCORE_TOO_LOW'` (Nov 21: threshold raised to 91+) - **Background tracker:** Runs every 5 minutes, monitors price movements for 30 minutes -- **Analysis:** After 50+ signals per timeframe, compare win rates and profit potential +- **Analysis:** After 50+ signals per category, compare win rates and profit potential **Components:** @@ -537,10 +538,22 @@ ORDER BY win_rate DESC; **Decision Making:** After sufficient data collected: -- Compare: 5min vs 15min vs 1H vs 4H vs Daily win rates -- Evaluate: Signal frequency (trades/day) vs win rate trade-off -- Identify: Which timeframe has best TP1 hit rate with acceptable MAE -- Action: Switch production timeframe if higher timeframe shows significantly better results +- **Multi-timeframe:** Compare 5min vs 15min vs 1H vs 4H vs Daily win rates +- **Quality threshold:** Analyze if blocked signals (quality <91) would've been winners +- **Evaluation:** Signal frequency vs win rate trade-off, threshold optimization +- **Query example:** +```sql +-- Would quality-blocked signals have been winners? +SELECT + COUNT(*) as blocked_count, + SUM(CASE WHEN "wouldHitTP1" THEN 1 ELSE 0 END) as would_be_winners, + SUM(CASE WHEN "wouldHitSL" THEN 1 ELSE 0 END) as would_be_losers, + ROUND(100.0 * SUM(CASE WHEN "wouldHitTP1" THEN 1 ELSE 0 END) / COUNT(*), 1) as missed_win_rate +FROM "BlockedSignal" +WHERE "blockReason" = 'QUALITY_SCORE_TOO_LOW' + AND "analysisComplete" = true; +``` +- **Action:** Adjust thresholds or switch production timeframe based on data **Key Features:** - **Autonomous:** No manual work needed, runs in background