fix: harden drift verifier and validation flow

This commit is contained in:
mindesbunister
2025-12-10 15:05:44 +01:00
parent 0a45279c64
commit 4e286c91ef
12 changed files with 620 additions and 579 deletions

View File

@@ -1040,16 +1040,15 @@ Frequency penalties (overtrading / flip-flop / alternating) now ignore 1-minute
- Penalty for recent losing trades, bonus for winning streaks
- **Note:** Analytics check is advisory only - manual trades execute even if rejected by analytics
**Smart Validation Queue (Dec 7, 2025 - TIMEOUT EXTENDED):**
- **Purpose:** Monitor blocked signals for 30 minutes to confirm price moves
- **Timeout:** 30 minutes (extended from 10 min based on data analysis)
- **Rationale:** Analysis of 10 blocked signals showed 30% hit TP1, most moves develop after 15-30 minutes
- **Example:** Quality 70 signal (ADX 29.7) hit TP1 at 0.41% after 30+ minutes ($22 profit missed with 10-min timeout)
- **Protection:** -0.4% drawdown limit prevents holding bad signals too long
- **Configuration:** `entryWindowMinutes: 30` in smart-validation-queue.ts
- **Trade-off:** Slightly longer hold on losing signals, but data shows most profitable moves take 15-30 min to develop
**Smart Validation Queue (Dec 10, 2025 - TWO-STAGE CONFIRMATION):**
- **Purpose:** Monitor blocked signals to confirm price moves before execution (two-stage confirm)
- **Timeout:** 90 minutes (was 30 minutes) with 30-second checks; restores last 90 minutes on startup
- **Confirmation:** +0.15% move in trade direction triggers execution; abandon at -0.4% against (unchanged)
- **Rationale:** Blocked-signal analysis showed rapid +0.15% confirms capture TP1/TP2 while retaining low false positives
- **Configuration:** `entryWindowMinutes: 90`, `confirmationThreshold: 0.15`, `maxDrawdown: -0.4` in smart-validation-queue.ts
- **Trade-off:** Longer watch window aligned to two-stage approach; still bounded by drawdown guard
- **Implementation:** lib/trading/smart-validation-queue.ts line 105
- **Status:** ✅ DEPLOYED Dec 7, 2025 10:30 CET (commit c9c987a)
- **Status:** ✅ UPDATED Dec 10, 2025 15:00 CET (two-stage thresholds live)
## 🧪 Test Infrastructure (Dec 5, 2025 - PR #2)
@@ -1062,17 +1061,22 @@ tests/
├── helpers/
│ └── trade-factory.ts # Factory functions for mock trades
└── integration/
└── position-manager/
├── tp1-detection.test.ts # 16 tests - TP1 triggers for LONG/SHORT
── breakeven-sl.test.ts # 14 tests - SL moves to entry after TP1
├── adx-runner-sl.test.ts # 18 tests - ADX-based runner SL tiers
├── trailing-stop.test.ts # 16 tests - ATR-based trailing with peak tracking
├── edge-cases.test.ts # 15 tests - Token vs USD, phantom detection
├── price-verification.test.ts # 18 tests - Size AND price verification
└── decision-helpers.test.ts # 16 tests - shouldStopLoss, shouldTakeProfit1/2
├── drift-state-verifier/
├── position-verification.test.ts # Identity verification, fail-open bias, cooldown persistence (Bug #82)
── cooldown-enforcement.test.ts # Retry cooldown enforcement and logging (Bug #80)
└── position-manager/
├── tp1-detection.test.ts # 16 tests - TP1 triggers for LONG/SHORT
├── breakeven-sl.test.ts # 14 tests - SL moves to entry after TP1
├── adx-runner-sl.test.ts # 18 tests - ADX-based runner SL tiers
├── trailing-stop.test.ts # 16 tests - ATR-based trailing with peak tracking
├── edge-cases.test.ts # 15 tests - Token vs USD, phantom detection
├── price-verification.test.ts # 18 tests - Size AND price verification
├── decision-helpers.test.ts # 16 tests - shouldStopLoss, shouldTakeProfit1/2
├── monitoring-verification.test.ts # Ensures monitoring actually starts and price updates trigger checks
└── pure-runner-profit-widening.test.ts # Profit-based trailing widening after TP2
```
**Total:** 7 test files, 113 tests
**Total:** 13 test files, 162 tests (full suite green as of Dec 10, 2025 before rebuild)
**Test Configuration:**
- **Framework:** Jest + ts-jest
@@ -2293,6 +2297,7 @@ On container startup, cross-checks last 24h of "closed" trades against actual Dr
- Impact: Position completely unprotected from downside
- Detection: Health monitor checks slOrderTx/softStopOrderTx/hardStopOrderTx every 30s
- Fix required: Validate signatures.length before returning, add error handling around SL placement
- Additional guard (Dec 10, 2025): tp2SizePercent of 0 or undefined now normalizes to 100% of remaining size so TP2 orders are placed and validation counts stay aligned with expected signatures.
**CRITICAL: Transaction Confirmation Pattern**
Both `openPosition()` and `closePosition()` MUST confirm transactions on-chain: