diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 412daee..b466e76 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -3005,6 +3005,56 @@ This section contains the **TOP 10 MOST CRITICAL** pitfalls that every AI agent
 
 📚 **Full Documentation:** `docs/COMMON_PITFALLS.md` (73 pitfalls with code examples, git commits, deployment dates)
 
+75. **CRITICAL: Wrong Year in SQL Queries - ALWAYS Use Current Year (CRITICAL - Dec 8, 2025):**
+    - **Symptom:** Query returns 247 rows spanning months when expecting 5-6 recent trades
+    - **Root Cause:** Database stores timestamps in 2024 format, AI agent queried '2024-12-07' instead of '2025-12-07'
+    - **Impact:** Reported -$1,616 total loss when actual recent loss was -$137.55 (12× inflation)
+    - **User Dispute:** "THE LOSS WAS NOT 63$ but 120,89$. where do you get those numbers from??"
+    - **Root Cause Analysis:**
+      * Database exitTime field contains dates like '2024-12-02', '2024-12-05', etc.
+      * AI agent wrote query: `WHERE "exitTime" >= '2024-12-07 00:00:00'`
+      * This matched ALL trades from Oct 2024 onwards (247 rows)
+      * Should have written: `WHERE "exitTime" >= '2025-12-07 00:00:00'`
+      * Current date is Dec 8, **2025**, not 2024
+    - **MANDATORY SQL Pattern - ALWAYS Check Year:**
+      ```sql
+      -- WRONG: Hardcoded 2024 when current year is 2025
+      SELECT * FROM "Trade" WHERE "exitTime" >= '2024-12-07 00:00:00';
+      
+      -- CORRECT: Use current year 2025
+      SELECT * FROM "Trade" WHERE "exitTime" >= '2025-12-07 00:00:00';
+      
+      -- BEST: Verify current date first
+      SELECT NOW()::date as current_date;  -- Check what year database thinks it is
+      
+      -- SAFEST: Use relative dates (past 3 days)
+      SELECT * FROM "Trade" WHERE "exitTime" >= NOW() - INTERVAL '3 days';
+      ```
+    - **Verification Before Reporting Numbers:**
+      1. Check row count - if querying "last 3 days" returns 247 rows, year is WRONG
+      2. Verify date range in results: `SELECT MIN("exitTime"), MAX("exitTime") FROM ...`
+      3. Use `TO_CHAR("exitTime", 'YYYY-MM-DD HH24:MI')` to see full dates including year
+      4. Cross-reference with context: User said "emergency today" → query should return TODAY's data only
+    - **Why This Matters:**
+      * **This is a REAL MONEY system** - wrong loss figures = incorrect financial decisions
+      * User was EXACTLY RIGHT with $120.89 figure (actual Dec 5-8 losses)
+      * AI agent gave wrong numbers due to year mismatch in query
+      * Wasted user time disputing correct figures
+      * User mandate: "drift tells the truth not you" - trust user's numbers, verify queries
+    - **Prevention Rules:**
+      1. ALWAYS use `NOW()` or `CURRENT_DATE` for relative date queries
+      2. NEVER hardcode year without verifying current year first
+      3. ALWAYS check row counts before declaring results accurate
+      4. When user disputes numbers, re-verify query year immediately
+      5. Include full YYYY-MM-DD in SELECT to catch year mismatches
+    - **Red Flags Indicating Year Mismatch:**
+      * Query for "recent trades" returns 100+ rows
+      * Date range spans months when expecting days
+      * User says "that's wrong" and provides different figure
+      * exitTime dates show 2024 but current date is 2025
+    - **Git commit:** [Document wrong year SQL query lesson - Dec 8, 2025]
+    - **Status:** ✅ Documented - Future AI agents must verify year in date queries
+
 72. **CRITICAL: MFE Data Unit Mismatch - ALWAYS Filter by Date (CRITICAL - Dec 5, 2025):**
     - **Symptom:** SQL analysis shows "20%+ average MFE" but TP1 (0.6% target) never hits
     - **Root Cause:** Old Trade records stored MFE/MAE in DOLLARS, new records store PERCENTAGES