Bu ekran, kapanan işlemlerin giriş anındaki kriter değerleri (RSI/ADX/Trend/Hacim/Extreme Mod) ile gerçek sonuç arasındaki ilişkiyi gösterir — hangi kombinasyonun daha çok kazandırdığını anlamak için kullanılır.
Canlı
Botun gerçek Binance hesaplarında açıp kapattığı işlemleri gösterir. PNL değerleri gerçek USDT tutarlarıdır (gerçek kaldıraç ve pozisyon büyüklüğüyle). Sadece bu kriter-analizi özelliği eklendikten sonra açılan işlemler dahildir — eski kayıtlar giriş anı kriter verisi içermediği için burada görünmez. Manuel (/join) ve harici (is_external=1) işlemler dahil değildir.
Backtest
Botla aynı sinyal mantığını geçmiş Binance verisiyle geriye dönük simüle eden, ScalpEngineBacktest adlı BAĞIMSIZ bir konsol aracının sonuçlarını gösterir. Bu araç admin panelin veya botun bir parçası DEĞİLDİR — ayrı bir sunucuda/ortamda elle çalıştırılır, sonuçlarını --db parametresiyle botun veritabanındaki AYRI bir tabloya (BacktestTradeHistory — canlı işlemlerin bulunduğu tablodan tamamen farklı, birbirine karışmaz) yazar; bu ekran o sonuçları okur. Yani "Backtest" sekmesine geçmek yeni bir test BAŞLATMAZ, sadece daha önce çalıştırılmış test sonuçlarını gösterir.
Backtest PNL değerleri gerçek USDT değil, kaldıraçsız fiyat hareketi yüzdesidir (ör. "1.80" = %1.80 fiyat hareketi). Gerçek pozisyon büyüklüğü/kaldıraç simüle edilmez — bu yüzden ekranda ayrıca bir "Kaldıraçlı Simülasyon" paneli çıkar (aşağıya bak).
Üstteki filtreler
- Canlı / Backtest — veri kaynağını seçer (yukarı bak).
- Tarih aralığı — Son 1/7/30/90 gün, Son 1 yıl, ya da "Özel Aralık" seçip iki tarih girerek istediğin herhangi bir aralığı raporla.
- Hesap — belirli bir hesabın (ör. bir üyenin mirror hesabının) işlemlerine daralt.
- Coin — belirli bir sembole (ör. sadece BTCUSDT) daralt.
- Yenile — aynı filtrelerle veriyi tekrar çeker.
- Backtest Verilerini Temizle — sadece
BacktestTradeHistory tablosundan siler, CANLI işlemlerin bulunduğu tabloya hiç dokunmaz (farklı tablo). Butonun yanındaki başlangıç/bitiş tarih kutuları doldurulursa sadece o aralıktaki sonuçlar silinir (kapanış tarihine göre); boş bırakılırsa tüm backtest sonuçları silinir. Yeni bir backtest koşumundan önce eski sonuçları (tamamen ya da sadece belirli bir dönemi) temizlemek için kullanılır.
Backtest aracını çalıştırma parametreleri
ScalpEngineBacktest klasöründe, sunucuda şu komutlarla çalıştırılır:
dotnet run -- --days 30
dotnet run -- --days 30 --symbols BTCUSDT,ETHUSDT
dotnet run -- --days 30 --end 2026-08-12T00:00:00
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --daily-universe
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --live-vol-gate
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --global-vol-gate
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --mode Normal
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --mode Agresif --agresif-adx-tolerance 2
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --adx-max 70
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --adx-di-block 40
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --stop-loss-pct 1.5
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --di-tolerance 3
dotnet run -- --days 1 --end 2026-08-15T23:59:00 --no-cache
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --cooldown-min 30
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --fee-pct 0.1
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --boundary-tolerance 1
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --log-borderline borderline.csv
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --scale-in --min-order-usdt 5 --order-size-usdt 20 --leverage 10
dotnet run -- --days 90 --db "Server=...;Database=TradingBot;..."
dotnet run -- verify PROMUSDT 2026-08-12T01:32:00
dotnet run -- verify VELVETUSDT 2026-08-17T16:46:00 --testnet
dotnet run -- verify XRPUSDT 2026-08-19T16:05:00 --testnet --boundary-tolerance 1.5
--days N — kaç gün geriye test edileceği (varsayılan 90).--symbols X,Y,Z — sadece belirli coinlerle test et (hızlı deneme için).--end tarih — test aralığını "şu ana göre kayan" değil, SABİT bir tarihe göre hesaplar, böylece aynı komut her koşumda birebir aynı sonucu verir (tekrarlanabilir).--daily-universe — coin evrenini "çalıştırıldığı anki" listeyle sabit uygulamak yerine, botun her gün kaydettiği GERÇEK günlük coin listesini kullanır (survivorship bias azaltılmış, daha gerçekçi sonuç).--live-vol-gate — VOL-R'ye (kapanan 5dk mumun hacim oranı) ek olarak, o an oluşmakta olan mumun GERÇEK canlı-projeksiyonlu hacim oranını (P-VOL) da zorunlu şart yapar. Verilmezse (varsayılan) sadece VOL-R aranır — aynı dönemi iki şekilde çalıştırıp P-VOL'un gerçekten katkısı olup olmadığını karşılaştırmak için kullanılır.--global-vol-gate — canlı bottaki CoinGecko global hacim filtresinin (bir coinin o günkü global hacmi 20M USDT'nin altındaysa sinyal engellenir) backtest karşılığını uygular. Verilmezse (varsayılan) bu filtre hiç uygulanmaz. CoinGecko'nun geçmiş veri servisine sembol×gün başına ayrı istek attığı için (sonuçlar diske önbelleklenir) İLK koşumda ciddi şekilde yavaşlatabilir; sonraki koşumlarda önbellek sayesinde hızlanır. Coin bazında geçmiş veri bulunamazsa (ör. yeni/az bilinen coin) o sembol için filtre uygulanmaz — canlı bottaki "veri yoksa engelleme yok" davranışıyla tutarlıdır.--mode Normal|Agresif — isteğe bağlı: verilmezse (varsayılan) her sembol hem Normal hem Agresif modda taranır. Verilirse SADECE o mod taranır, koşum süresi de kısalır (Normal'de E-15D/15dk EMA trend uyumu ZORUNLU, Agresif'te bu şart aranmaz). "Sadece Agresif modu test etmek istiyorum" gibi durumlarda kullanışlıdır.--agresif-adx-tolerance N — Agresif moddaki ADX yükseliş toleransını (ADX bir önceki ölçüme göre en fazla ne kadar hızlı yükselebilir) değiştirir. Normal modun toleransı HER ZAMAN sabit +2'dir, değiştirilemez — bu sadece Agresif'i etkiler. Varsayılan 3 (canlı bottaki değerle aynı). Düşük değer (ör. 2) daha SIKI — "hâlâ ivmelenen" (henüz tükenmemiş) harekete karşı mean-reversion işlem açılmasını daha çok engeller; yüksek değer (ör. 4, 5) daha GEVŞEK — daha çok sinyal ama daha riskli. Aynı dönemi farklı değerlerle koşup CSV'leri karşılaştırarak en dengeli değeri bulmak için kullanılır.--adx-max N — isteğe bağlı, varsayılan kapalı (üst sınır yok, eski davranış). ADX bu değerin ÜSTÜNDEYSE sinyal engellenir — --agresif-adx-tolerance'dan FARKLI olarak bu bir hız/yükseliş şartı değil, MUTLAK seviye şartı, ve hem Normal hem Agresif modu aynı şekilde etkiler. Çok yüksek ADX (ör. 70+, "Aşırı Güçlü") genelde trendin hâlâ çok güçlü/olgunlaşmamış olduğunu gösterir — mean-reversion (karşı yön) bahis için riskli bir rejim olabilir. Doğru eşiği bulmak için farklı değerlerle (60, 70, 80) koşup CSV'leri karşılaştırmak amacıyla eklendi.--adx-di-block N — isteğe bağlı, varsayılan kapalı. ADX bu değerin ÜSTÜNDE VE DI+/DI- o anki galip tarafı gösteriyorsa, galip tarafın TERSİNE (mean-reversion) sinyal engellenir: SHORT için DI+ > DI- iken (güçlü, teyitli YÜKSELİŞ trendine karşı kısa açılmasın), LONG için DI- > DI+ iken (güçlü, teyitli DÜŞÜŞ trendine karşı uzun açılmasın). --adx-max'ten farkı: bu şart YÖN bilgisini de kullanır, sadece mutlak ADX seviyesine değil hangi tarafın DI üstünlüğüne de bakar. Mevcut "DI toleransı" şartı sadece DI'nin ne kadar HIZLI değiştiğine bakar, hangi tarafın üstün olduğuna bakmaz — bu parametre o boşluğu kapatır. Hem Normal hem Agresif modu etkiler. Doğru eşiği (35, 40, 45...) bulmak için farklı değerlerle koşup CSV'leri karşılaştırmak amacıyla eklendi.--di-tolerance N — isteğe bağlı (18.08.2026 eklendi), varsayılan 5.0 (eski sabit değerle AYNI, geriye dönük uyumlu). "DI toleransı" şartının eşiği: SHORT sinyalinde DI+'nin, LONG sinyalinde DI-'nin bir önceki mumdan bu yana en fazla ne kadar YÜKSELEBİLECEĞİ — hâlâ ivmelenen/tükenmemiş harekete karşı mean-reversion işlem açılmasını engellemek için. --agresif-adx-tolerance'ın DI karşılığı: o ADX'in yükseliş hızını sınırlarken, bu DI'nin yükseliş hızını sınırlar. --adx-di-block'tan farkı: o ADX+DI'nin MUTLAK galip yönüne bakar, bu ise DI'nin ne kadar HIZLI değiştiğine bakar (yön farketmeksizin). Düşük değer (ör. 3) daha SIKI (daha az sinyal, daha korumalı), yüksek değer (ör. 7, 10) daha GEVŞEK. Hem Normal hem Agresif modu aynı şekilde etkiler. Doğru eşiği bulmak için farklı değerlerle (3, 5, 7) ayrı --out dosyalarına koşup CSV'leri karşılaştırmak gerekir.--stop-loss-pct N — isteğe bağlı (18.08.2026 eklendi), varsayılan kapalı. 19.08.2026 GÜNCELLEMESİ: canlı bot artık ATR bazlı %2.0-%2.5 kelepçeli stop kullanmıyor — stop mesafesi SABİT %1.3'e çevrildi (kullanıcı talebi: "anki volatiliteye göre değişen mantığı iptal edelim"). Backtest aracı da bu bayrak VERİLMEDİĞİNDE artık aynı sabit %1.3'ü varsayılan olarak kullanıyor (eski ATR mantığı tamamen kaldırıldı, artık hiçbir modda çalışmıyor). Bu parametre verilirse stop mesafesi HER sinyalde belirtilen FARKLI sabit yüzdeye ayarlanır (ör. --stop-loss-pct 1.5 → giriş fiyatının %1.5 uzağı) — yani artık "ATR yerine sabit kullan" değil, "varsayılan %1.3 yerine BAŞKA bir sabit yüzde dene" parametresi. TP1-5 seviyeleri bu parametreden ETKİLENMEZ, hep sabit kalır (%0.9/%1.8/%2.5/%3.0/%3.5) — sadece stop mesafesi değişir. Doğru değeri bulmak için aynı dönemi farklı yüzdelerle (ör. 1.0, 1.3, 1.5, 2.0) ayrı --out dosyalarına koşup CSV'leri karşılaştırmak gerekir.--no-cache — backtest aracı her sembol+interval+tarih aralığı için indirdiği veriyi diskte (cache/ klasöründe) saklar, aynı aralık tekrar istenirse ağa hiç gitmeden o dosyayı kullanır. Bu parametre verilirse cache OKUNMAZ, Binance'ten HER ZAMAN taze veri çekilir (cache yine de güncellenir). Normal koşumlarda gerekmez — sadece YAKIN TARİHLİ/GÜNCEL bir olayı doğrularken kullan (ör. "bugün olan bir işlem neden böyle sonuçlandı"): verinin ilk indirildiği anda henüz tam kesinleşmemiş olma ihtimaline karşı, diskte bayat bir kopyayla sonsuza kadar çalışılmasını önler.--cooldown-min N — canlı bottaki "bir işlem kapandıktan sonra aynı coinde bir süre yeni sinyal aranmaz" cooldown kuralının (AccountContext.SaveCooldown) backtest karşılığı. Varsayılan 60 (canlı bottaki en yaygın süreyle aynı) — bir pozisyon (SL/TP/zaman aşımı fark etmeksizin) kapandığında o sembolde N dakika boyunca yeni sinyal aranmaz. 0 verirsen kapanır (kapanışın hemen ardından yeni sinyal aranabilir, eski davranış).--fee-pct N — isteğe bağlı (19.08.2026 eklendi, komisyon/kayma/fonlama hiç hesaba katılmıyordu — her sinyal tam olarak hesaplanan fiyattan açılmış/kapanmış varsayılıyordu). Verilirse HER işlemin ham kâr/zarar yüzdesinden bu sabit yüzde düşülür — gerçek Binance Futures işlemindeki komisyon (maker/taker, VIP/BNB indirimine göre değişir), kayma (bottun hedeflediği tetik fiyatı ile piyasa emrinin gerçek dolum fiyatı arasındaki fark) ve fonlama ücretinin (8 saatte bir, pozisyon o ana denk gelirse) TEK bir sabit gidiş-dönüş tahminidir; üçünü ayrı ayrı modellemek gerçekçi olmayan bir hassasiyet iddiası olur. Varsayılan 0 (kapalı, eski davranış). Örnek: --fee-pct 0.1 → her işlemden %0.1 düşülür. Gerçek maliyetini tahmin etmek için: taker komisyonu (VIP seviyene göre genelde %0.02-%0.05 arası, giriş+çıkış için x2), tahmini kayma ve olası fonlama ücretini toplayıp gir. Bu parametre pnl/pnl_usdt kolonuna yazılmadan ÖNCE uygulanır, yani admin panelindeki kaldıraç simülatörü dahil bu değeri okuyan HER görünüm otomatik olarak maliyet-düşülmüş sonucu gösterir.--out dosya.csv — sonuç CSV'sinin dosya adını belirler (verilmezse otomatik zaman damgalı bir isim kullanılır, ör. backtest_results_20260812_180000.csv). Aynı dönemi farklı parametrelerle (ör. --live-vol-gate açık/kapalı) iki ayrı dosyaya yazıp elle karşılaştırmak için kullanışlıdır.--db "..." — sonuçların yazılacağı veritabanı bağlantısı (verilmezse appsettings.json'dan otomatik okunur).verify SEMBOL tarih — tek bir sembol + tek bir an için tüm kriter değerlerini ekrana döker, gerçek bir Telegram sinyaliyle manuel karşılaştırmak için kullanılır.--testnet — isteğe bağlı (17.08.2026 eklendi). Veriyi Binance Futures MAINNET (varsayılan, fapi.binance.com) yerine TESTNET'ten (testnet.binancefuture.com) çeker — canlı bot şu an testnet'e bağlı olduğu için (Ayarlar > Binance ortamı), bu bayrak olmadan backtest MAİNNET verisiyle, canlı ise TESTNET verisiyle karşılaştırılmış olur; bu iki ortamın fiyat/mum verisi (donuk mum olmasa bile) belirgin şekilde FARKLI olabilir (VELVETUSDT 17.08.2026 vakası: aynı 15dk mum, iki ortamda tamamen farklı OHLC, RSI15 18,6 vs 35,2 çıkmıştı — --testnet ile eklenince canlıyla virgülüne kadar eşleşti). Cache mainnet'ten ayrı bir klasörde (cache/testnet/) tutulur, birbirine karışmaz. Sadece "sinyal mantığı canlıyla tutarlı mı" sorusunu doğrulamak için kullanılmalı — testnet fiyat hareketi gerçek piyasayı temsil etmediği için gerçek strateji/kârlılık değerlendirmesinde KULLANILMAMALI. Bot mainnet'e geçtiğinde bu bayrağa gerek kalmaz.--boundary-tolerance N — isteğe bağlı (20.08.2026 eklendi, XRPUSDT vakası: canlıda ADX tam sınırda (60.0) tetiklenen bir sinyal, backtest'in kendi bağımsız yeniden hesapladığı ADX sınırın az üstüne çıktığı için backtest'te hiç görünmedi). ADX tavanı (--adx-max), ADX yükseliş toleransı ve DI toleransı kontrollerine EK bir pay tanır — ör. --boundary-tolerance 1 verilirse bu üç eşiğin hepsi 1.0 puan daha gevşek uygulanır. Varsayılan 0 (kapalı, eski davranış birebir korunur). DİKKAT: bu parametre TÜM sembolleri aynı anda gevşetir, sadece "bilinen tek bir kaçırılan aday"ı değil — deneylerde bu, başka sembollerde daha önce haklı olarak elenen zayıf adayların da işleme girmesine (ve genelde net PNL'i kötüleştirmesine) yol açabiliyor. Gerçek raporlama koşumlarında KULLANILMAMALI, sadece "belirli bir sembolün kaçırılma marjı ne kadar" sorusunu nokta atışı test etmek için (verify ile birlikte) kullanılmalı.--log-borderline dosya.csv — isteğe bağlı (20.08.2026 eklendi, aynı XRPUSDT vakası). RSI eşiği tetiklenip ADX tavanı/toleransı ya da DI toleransı gibi bir eşikten ÇOK KÜÇÜK bir farkla (≤1.0 puan) reddedilen adayları ayrı bir CSV'ye kaydeder — bu satırlar SİNYAL DEĞİLDİR, PNL simülasyonuna hiç girmezler, ana sonucu (--out) hiçbir şekilde etkilemezler; sadece "az kalsın yakalanıyordu" teşhis bilgisidir. DB bağlantısı varsa aynı satırlar BacktestBorderlineCandidates tablosuna da otomatik yazılır ve bu ekranda ("Kriter Analizi" → Backtest görünümü) "Sınırda Kaçırılanlar" bölümünde görünür. --boundary-tolerance'tan farkı: bu sadece TEŞHİS amaçlıdır, hiçbir sinyal kararını değiştirmez (--boundary-tolerance ise gerçekten daha çok sinyal ürettirir).--scale-in — isteğe bağlı (22.08.2026 eklendi, kullanıcı talebi: "işlem onayı geldiğinde minimum USDT ile aç, tutuyorsa kademeli arttır"). Varsayılan KAPALI (eski davranış, hiçbir etkisi yok). Açıldığında, SADECE Agresif moddaki işlemler minimum işlem büyüklüğüyle (--min-order-usdt) açılır; fiyat TP1 hedefinin YARISI kadar lehe giderse pozisyon TEK seferde normal büyüklüğe (--order-size-usdt) tamamlanır — çoklu kademe değil, tek adım. Eklendiğinde TP1-TP5 ve stop seviyeleri YENİ ağırlıklı ortalama girişe göre yeniden hesaplanır (orijinal % mesafeler korunur). Normal moddaki işlemler bu bayraktan HİÇ etkilenmez. DİKKAT: gerçek sembol-bazlı Binance minimumu (MIN_NOTIONAL/LOT_SIZE) modellenmez — --min-order-usdt ile verilen sabit tahmin kullanılır, canlı botta gerçek minimum sembolden sembole değişir. DÜZELTME (23.08.2026): backtest'te tutarlı biçimde sabit boyuttan daha iyi sonuç verdiği doğrulandıktan sonra bu özellik CANLI BOTA da taşındı — orada aç/kapat ve minimum USDT ayarı "Hesap Ayarları" → "Bot Kriterleri" kartındaki "🔺 Kademeli Pozisyon Büyüklüğü" bölümünden yönetilir (bu backtest bayrağıyla AYNI mantık, ama ayrı bir ayar seti: GET/POST /api/admin/trading-criteria üzerindeki scaleInEnabled/scaleInMinOrderUsdt, BotConfig.ScaleInEnabled/ScaleInMinOrderUsdt). Canlıdaki sürüm, buradaki gibi sabit bir tahmin yerine borsanın GERÇEK sembol-bazlı MIN_NOTIONAL'ını kontrol eder ve gerekirse otomatik olarak buna yükseltir. DÜZELTME (23.08.2026, kullanıcı talebi: "mirror hesaplarda farklı kademeli tutarlar vermek istemiyorum, ana hesabın ayarlarını kullansınlar. Önemli olan ana hesap ne yapıyorsa mirror hesaplarda eskisi gibi aynısı yapsın"): ilk versiyon SADECE ana hesapla sınırlıydı, artık DEĞİL — karar (uygulanıp uygulanmayacağı) yine SADECE ana hesabın Agresif/EXTREME durumuna göre veriliyor, ama karar "evet" ise TÜM hesaplar (ana + mirror) aynı anda minimum boyutla açılıp KENDİ normal boyutlarına (kendi OrderSizeUsdt/PremiumOrderSizeUsdt'lerine) büyütülüyor; her hesabın büyütme tetiği kendi pozisyon takip döngüsünde bağımsız çalışır (TP/stop takibinin zaten hep çalıştığı gibi), merkezi bir senkronizasyona ihtiyaç duymaz. Sonuçlar hem CSV'ye (scaled_in/effective_entry/pnl_usdt_scaled kolonları) hem DB'ye yazılır — bu ekranda ("Kriter Analizi" → Backtest görünümü) İşlem Listesi'nde her işlemin GERÇEK kademeli-boyut sonucu, sabit-boyut Kaldıraçlı Simülasyon tahmininin yanında ayrıca gösterilir. Koşum sonunda konsola kademeli strateji ile sabit-boyut stratejisinin toplam USDT karşılaştırması da yazdırılır.--min-order-usdt N — --scale-in ile birlikte kullanılır, varsayılan 5. Pozisyonun İLK açıldığı marj (USDT) — Binance Futures'ın tipik minimum işlem büyüklüğü tahminiyle uyumlu bir varsayılan, gerçek sembol-bazlı minimum değil.--order-size-usdt N — --scale-in ile birlikte kullanılır, varsayılan 20 (admin panelin Kaldıraçlı Simülasyon panelindeki varsayılan işlem büyüklüğüyle aynı). Pozisyona ekleme tetiklendiğinde TAMAMLANACAK normal/hedef marj (USDT).--leverage N — --scale-in ile birlikte kullanılır, varsayılan 10 (admin panelin Kaldıraçlı Simülasyon panelindeki varsayılan kaldıraçla aynı). Miktar hesaplaması (marj × kaldıraç ÷ fiyat) bu değeri kullanır.
P-VOL katkısını ölçme (VOL-R tek başına mı, +P-VOL mü daha iyi?)
Aynı dönemi iki kez, sadece --live-vol-gate açık/kapalı olacak şekilde ayrı dosyalara koşup CSV'leri karşılaştır:
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --out sadece_volr.csv
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --live-vol-gate --out volr_pvol.csv
Birincisi sadece VOL-R şartıyla, ikincisi VOL-R + gerçek P-VOL şartıyla AYNI dönemi test eder. İki CSV'nin işlem sayısı ve kazanma oranı farklıysa, P-VOL'un sinyal kalitesine gerçekten katkısı var demektir.
Kaldıraçlı Simülasyon paneli
Sadece Backtest görünümünde çıkar. Backtest PNL'i (kaldıraçsız % hareket) üstteki Kaldıraç ve İşlem Büyüklüğü alanlarına göre TAHMİNİ bir USDT kazanç/kayba çevirir — komisyon, fonlama ücreti ve likidasyon riski hesaba katılmaz, gerçek sonuçtan farklı olabilir. Farklı kaldıraç/büyüklük varsayımlarını hızlıca denemek için kullanılır.
Örnek senaryo
"Son 30 günde Agresif mod gerçekten Normal moddan daha mı iyi kazandırıyor?" sorusunu test etmek istersen: sunucuda dotnet run -- --days 30 --end 2026-08-12T00:00:00 --daily-universe --db "..." çalıştır, bitince buraya dönüp üstten Backtest + Son 30 gün seçip Yenile'ye bas — alttaki özet ve tablo Normal/Agresif kırılımını gösterir.