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 --adx-rise-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 30 --end 2026-08-12T00:00:00 --rsi-oversold 25 --rsi-overbought 75
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --tp1-target-pct 0.9
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --global-vol-gate --min-global-volume 30000000
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --ema15m-fast 20 --ema15m-slow 100
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --ema1h-fast 20 --ema1h-slow 100
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 30 --end 2026-08-12T00:00:00 --scale-in --scale-in-trigger 0.3
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --no-tp1-trail
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --confirm-5m-candles 2
dotnet run -- --days 30 --end 2026-08-12T00:00:00 --no-2m-gate
dotnet run -- --days 90 --db "Server=...;Database=TradingBot;..."
dotnet run -- --days 30 --run-id manuel_test_1 --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).--start tarih — isteğe bağlı (07.09.2026 eklendi, kullanıcı talebi: "backtest e başlangıç ve bitiş tarih saat aralığını verebileceğim bir form eklermisin"). Verilirse --days'in yerini alır — aralığın başlangıcı DOĞRUDAN bu tarih/saat olur (--end'e ya da "şu an"a kadar). Verilmezse (varsayılan) hiçbir şey değişmez, --days ile eskisi gibi hesaplanır. Admin panelin "BAŞLANGIÇ TARİHİ" alanıyla aynı.--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.--p-vol-threshold N — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "P-VOL değerini canlıda değiştirebiliyor olmam, 0 yazarsam devre dışı olmasını istiyorum, aynı şekilde backtest tarafında da"). --live-vol-gate açıkken P-VOL oranının aşmak zorunda olduğu eşiği belirler (SADECE Normal modda uygulanır, Agresif her zaman muaf). Varsayılan 1.0 — canlı bottaki admin panel "Bot Kriterleri" > "P-VOL Eşiği" ayarıyla (BotConfig.PVolThreshold) AYNI, eski sabit davranışla birebir eşdeğer. 0 girilirse şart TAMAMEN DEVRE DIŞI kalır — --live-vol-gate verilmiş olsa bile. Önceden bu eşik canlı botun koduna SABİT yazılmıştı, admin panelden hiç değiştirilemiyordu.--vol-r-threshold N — isteğe bağlı (05.09.2026 eklendi, kullanıcı talebi: "backtest te p-vol var, hesap ayarlarında p-vol var ama VOL-R'ye [ayarlanabilir bir eşik] yok, kontrol eder misin? ... evet yapalım"). VOL-R'nin (en son KAPANMIŞ 5dk mumun hacim oranı, MA20'ye göre) geçmesi gereken eşik. --p-vol-threshold'dan BAĞIMSIZ, AYRI bir şart — --live-vol-gate'e bağlı DEĞİL, HER ZAMAN uygulanır, ve P-VOL'un aksine moddan bağımsızdır (Normal ve Agresif'i AYNI ŞEKİLDE etkiler, Agresif muafiyeti YOK). Varsayılan 1.0 — canlı bottaki admin panel "Bot Kriterleri" > "VOL-R Eşiği" ayarıyla (BotConfig.VolRThreshold) AYNI, eski sabit davranışla birebir eşdeğer. 0 girilirse şart TAMAMEN DEVRE DIŞI kalır. Önceden bu eşik hem canlı bot hem backtest motorunun koduna SABİT (1.0) yazılmıştı, admin panelden hiç değiştirilemiyordu.--rsi5-tolerance N — isteğe bağlı (10.09.2026 eklendi, kullanıcı sorusu: "biz zaten RSI 5dk için sonrasında N tane mum onayı bekliyoruz, bu durumda (RSI15+10)/(RSI15-10) aralık kontrolü gereksiz olmuyor mu?" + takip talebi "bunu hesap ayarlarında parametrik yapalım ve backtest e ekleyelim"). EXTREME sinyalinde ("5m Teyidi"), RSI5'in RSI15'e göre kalması gereken aralık: SHORT için RSI5 ∈ [RSI15-N, RSI15], LONG için RSI5 ∈ [RSI15, RSI15+N]. --confirm-5m-candles'dan FARKLI bir şart: o, tespitten SONRAKİ mumların RENGİNE bakan İLERİYE dönük bir teyit; bu ise tespit ANINDAKİ RSI5 DEĞERİNE bakan GERİYE dönük bir momentum-uyum kalite filtresi — aynı şeyi iki kez kontrol etmiyorlar. Hem Normal hem Agresif modu AYNI ŞEKİLDE etkiler. Varsayılan 10.0 — canlı bottaki admin panel "Bot Kriterleri" > "RSI5 Teyit Aralığı" ayarıyla (BotConfig.Rsi5RangeTolerance) AYNI, eski sabit davranışla birebir eşdeğer. 0 girilirse şart TAMAMEN DEVRE DIŞI kalır. Önceden bu aralık hem canlı bot hem backtest motorunun koduna SABİT (±10) yazılmıştı, admin panelden hiç değiştirilemiyordu.--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.--adx-rise-tolerance N — ADX yükseliş toleransını (ADX bir önceki ölçüme göre en fazla ne kadar hızlı yükselebilir) değiştirir. GÜNCELLEME (04.09.2026): önceden bu SADECE Agresif modu etkiliyordu (adı --agresif-adx-tolerance'tı, Normal modun toleransı HER ZAMAN sabit +2'ydi) — artık canlı bottaki (16.08.2026'dan beri birleştirilmiş, tek admin-tunable) davranışla hizalandı: TEK bir değer HEM Normal HEM Agresif modu AYNI şekilde etkiler. Varsayılan 2.0 (canlı bottaki admin panel "Bot Kriterleri" ayarıyla AYNI, admin panelden değiştirilebilir — bu bayrak sadece backtest'i o değerden FARKLI bir değerle test etmek için var). GÜNCELLEME (04.09.2026): bu değer artık backtest'teki (ve canlı bottaki) "kaba ADX" ön-kontrolünü de aynı anda kontrol ediyor — önceden o ayrı bir sabit +5 idi, bu ayardan bağımsızdı ve 5'in üstündeki değerleri sessizce geçersiz kılıyordu. Düşük değer (ör. 1.5) 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. 3, 4) 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 — --adx-rise-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. --adx-rise-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. GÜNCELLEME (04.09.2026): önceden bu ayarın canlı botta HİÇ karşılığı yoktu (canlı sabit +5'e kilitliydi, admin panelden değiştirilemiyordu) — artık canlı bottaki admin panel "Bot Kriterleri" > "DI Toleransı" ayarıyla (BotConfig.DiTolerance) AYNI, bu bayrak sadece backtest'i o değerden FARKLI bir değerle test etmek için var. 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.--rsi-oversold N / --rsi-overbought N — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "admin panele eklediğim hesap ayarlarında olup backtest çalıştırda olmayan kriterleri de ekler misin"). EXTREME sinyalin RSI15 tetik eşiği: RSI bu OVERSOLD değerinin ALTINDAYSA LONG, OVERBOUGHT değerinin ÜSTÜNDEYSE SHORT adayı oluşur. Varsayılanlar 20/80 — canlı bottaki admin panel "Bot Kriterleri" > "RSI15 Eşikleri" ayarıyla (BotConfig.RsiOversoldThreshold/RsiOverboughtThreshold) AYNI. Önceden bu eşikler backtest motorunda SABİT KODLUYDU — admin panelden değiştirilse bile backtest'e hiç yansımıyordu.--tp1-target-pct N — isteğe bağlı (04.09.2026 eklendi, aynı talep). TP1 hedefi yüzdesi. Varsayılan 0.7 — canlı bottaki admin panel "Bot Kriterleri" > "TP1 Hedefi %" ayarıyla (BotConfig.Tp1TargetPercent) AYNI. TP2-TP5 KASITLI OLARAK parametrik yapılmadı (canlı botta da admin panelden değiştirilemiyor, sabit %1.4/%2.1/%3.0/%3.5). Önceden backtest motorunda SABİT KODLUYDU.--min-global-volume N — isteğe bağlı (04.09.2026 eklendi, aynı talep). CoinGecko günlük global hacim eşiği (USDT). İKİ yerde kullanılır: (1) --global-vol-gate açıkken sinyal filtresinde, (2) --daily-universe KAPALIYKEN varsayılan coin evrenini oluştururken. Varsayılan 20.000.000 — canlı bottaki admin panel "Bot Kriterleri" > "Min. Global Hacim Eşiği" ayarıyla (BotConfig.MinGlobalVolumeUsdt) AYNI. Önceden backtest motorunda SABİT KODLUYDU.--ema15m-fast N / --ema15m-slow N — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "Trend 15dk / Trend 15dk (Canlı) / Trend 1h bunlarda parametrik olsun hem canlıda hem backtestte"). "Trend 15dk" ve "Trend 15dk (Canlı)" göstergelerinde VE Normal moddaki ZORUNLU trend-uyum şartında (E-15D) kullanılan hızlı/yavaş EMA periyotları. Varsayılanlar 50/200 — canlı bottaki admin panel "Bot Kriterleri" ayarıyla AYNI. Önceden SABİT KODLUYDU. Hızlı periyot yavaş periyottan küçük olmak ZORUNDADIR (aksi halde "HATA" ile reddedilir).--ema1h-fast N / --ema1h-slow N — isteğe bağlı (aynı tarih/talep). "Trend 1h" göstergesinin hızlı/yavaş EMA periyotları — bu gösterge SADECE bilgi amaçlıdır, sinyal kararını (E-15D gibi) ETKİLEMEZ. Varsayılanlar 50/200, aynı kısıt (hızlı < yavaş) geçerlidir.--require-trend-15m-agresif — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "biz agresif modda şuan bunları kriter olarak canlıda kullanmıyoruz, backtest içinde kullanılsın yada kullanılmasın gibi bir checkbox yapsan"). Bayrak, değer almaz. "Trend 15dk" (E-15D) şartı normalde SADECE Normal modda ZORUNLUDUR — Agresif mod bu şarttan hem canlı bottа hem backtestte her zaman muaftır. Bu bayrak verilirse SADECE bu backtest koşumu için aynı trend-uyum şartı Agresif moda da uygulanır (deneysel A/B karşılaştırma amaçlı — Agresif'e trend şartı eklemenin sonucu iyileştirip iyileştirmediğini ölçmek için). Varsayılan kapalı (verilmezse Agresif eski gibi muaf kalır). Canlı botu HİÇ etkilemez — canlı bu bayrağı hiç okumaz, Agresif'te her zaman muaf kalmaya devam eder.--require-p-vol-agresif — isteğe bağlı (04.09.2026 eklendi, kullanıcı talebi: "P-vol extreme agresif modda devrede mi?" sorusuna cevaben, sonra "evet yapalım" onayı) — --require-trend-15m-agresif ile BİREBİR AYNI desen. Bayrak, değer almaz. P-VOL şartı normalde SADECE Normal modda ZORUNLUDUR — Agresif mod bu şarttan hem canlı bottа hem backtestte her zaman muaftır (bu, --p-vol-threshold eşiğinden BAĞIMSIZ, ayrı bir mod kuralıdır). Bu bayrak verilirse SADECE bu backtest koşumu için aynı P-VOL şartı Agresif moda da uygulanır — --live-vol-gate açık DEĞİLSE hiçbir etkisi yoktur (P-VOL şartı zaten hiç uygulanmıyor). Varsayılan kapalı. Canlı botu HİÇ etkilemez.--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).--run-id "kimlik" — isteğe bağlı (03.09.2026 eklendi, kullanıcı talebi: "yeni bir Backtest yapmak istediğimde tüm verileri silmem gerekiyor. Bana geçmiş test sonuçlarını görüntüleyebileceğim çalıştırılmış parametre satırınında bulunduğu bir rapor gerekiyor"). Bu koşumun BacktestTradeHistory'ye yazdığı satırları etiketler — admin panelin "Kriter Analizi" → Backtest görünümündeki "Geçmiş Backtest Koşumları" bölümünde ayrı bir koşum olarak listelenip filtrelenebilir/silinebilir hâle gelir, kullanıcı artık her yeni koşumdan ÖNCE tüm tabloyu silmek ZORUNDA değildir. Verilmezse otomatik olarak yyyyMMdd_HHmmss biçiminde üretilir — admin panelden ("Backtest Çalıştır" sekmesi) başlatılan koşumlarda bu kimlik ZATEN otomatik verilir (dosya adlandırması için kullanılan aynı kimlik, bkz. --log-borderline dosya yolu), yani admin panel kullanıcısının bu bayrakla hiç uğraşması gerekmez. Koşumun TÜM CLI parametreleri (--db bağlantı dizesi MASKELENEREK, asla ham hâliyle) ayrıca run_params sütununa kaydedilir — bu özellik eklenmeden ÖNCE yazılmış satırlarda ikisi de NULL kalır, admin panelde "Etiketsiz (Eski)" TEK bir grup olarak gösterilir. GÜNCELLEME (03.09.2026, İKİNCİ DÜZELTME — kullanıcı bulgusu: "Backtest verilerini temizle dediğimde bu veriler de silindi"): koşumun özeti (parametre satırı + istatistikler) artık AYRI, KALICI bir tabloya (BacktestRuns) da yazılır — admin panelin "Backtest Verilerini Temizle" butonu SADECE ham işlem satırlarını siler, bu özet tabloya HİÇ dokunmaz, yani "Geçmiş Backtest Koşumları" raporu artık o butondan etkilenmez (sadece bir koşumun "Görüntüle" ile açılan İşlem Listesi'ndeki işlemleri, ham satırlar silindiyse boş görünür). Tek bir koşumu (hem ham satırları hem kalıcı özetini) tamamen kaldırmak için admin panelin o koşuma özel "Sil" butonu kullanılmalı.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) — --premium-order-size-usdt VERİLMEZSE her işlem bu TEK değere büyür.--premium-order-size-usdt N — EKLENDİ (18.09.2026, kullanıcı talebi: "DI-bağımlı farklılaşmayı backtest'e ekleyebilir miyiz" — RENDERUSDT/PENDLEUSDT vakası, bkz. Hesap Ayarları'ndaki Base/Premium Lot notu). İSTEĞE BAĞLI, varsayılan YOK (verilmezse canlıdaki Base/Premium ayrımı backtest'e HİÇ yansımaz — --order-size-usdt tek/sabit hedef olarak kullanılır, eski davranış). Verilirse: her sinyalin AÇILIŞ anındaki kendi DI değerleriyle canlı bottakiyle BİREBİR aynı "diOk" kontrolü yapılır (DI'nin ≥2.0 puan değişmesi VE ilgili DI<49) — sağlanırsa kademeli büyütme bu (Premium) değere, sağlanmazsa --order-size-usdt (Base) değerine büyür. Sadece --scale-in işaretliyken bir etkisi vardır.--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.--scale-in-trigger N — isteğe bağlı (03.09.2026 eklendi, kullanıcı talebi: "kademeli arttırmanın giriş seviyesini ayarlayabileceğim bir ayar olsun"). --scale-in ile birlikte kullanılır, varsayılan 0.5 (eski sabit davranışla AYNI — TP1 yolunun YARISI). 0-1 arası bir ORAN: pozisyona ekleme, fiyat girişten TP1'e giden yolun bu oranını kat ettiğinde tetiklenir — küçük değer (ör. 0.3) büyütmeyi ERKENE çeker (daha az kesinleşmiş bir harekette büyütür), büyük değer (ör. 0.8) GECİKTİRİR (fiyat TP1'e daha çok yaklaşmadan büyütmez). Admin panelin "Bot Kriterleri" > "Kademeli Pozisyon Büyüklüğü" > "Tetik Oranı" ayarıyla AYNI DB anahtarını (scale_in_trigger_ratio) paylaşır; bu bayrak verilmezse o ayarın DB değeri varsayılan alınır (diğer DB-varsayılanlı bayraklarla — --confirm-5m-candles, --no-2m-gate — AYNI desen).--scale-in-fill-slippage-pct N — isteğe bağlı (06.09.2026 eklendi, kullanıcı bulgusu — STRKUSDT vakası: "canlı ile backtest çok tutarsız... evet bulalım ve bir önlem alalım"). --scale-in ile birlikte anlamlıdır. Varsayılan 0 (eski davranış — ekleme, HER ZAMAN teorik tetik fiyatından kaymasız/gecikmesiz doluyor varsayılır). Kök neden: canlı bot kademeli büyütmede GERÇEK Binance ortalama dolum fiyatını kullanır (bkz. Program_https_v245.cs TryScaleInPosition/addFillPrice) — bu, fiyatın tetik anıyla gerçek emir dolumu arasında geçen sürede biraz girişe geri çekilmesinden dolayı backtest'in varsaydığından FARKLI çıkabiliyor (STRKUSDT'de canlı ağırlıklı giriş 0.0316050, backtest 0.0315946 çıkmıştı — bu küçük fark, yeniden hesaplanan stop seviyesini kaydırıp canlının erken durup backtest'in aynı fiyat hareketinde hayatta kalmasına yol açmıştı). 0-1 arası bir ORAN: ekleme dolum fiyatının, teorik tetik fiyatı ile orijinal giriş arasındaki mesafenin bu kadarı kadar girişe doğru geri çekilmiş varsayılmasını sağlar (yön LONG/SHORT farketmeksizin otomatik doğru tarafa uygulanır). CANLIDA KARŞILIĞI YOKTUR (canlı zaten gerçek dolum fiyatını kullandığı için bu yaklaşıklamaya ihtiyacı yoktur) — SADECE backtest'in dolum varsayımını gerçeğe yaklaştıran deneysel bir modelleme ayarıdır; TEK bir vakadan türetildiği için "kesin doğru" bir değer yoktur, farklı oranlarla deneyip canlı sonuçlarına en çok yakınsayanı bulmak kullanıcıya bırakılmıştır.--legacy-scale-in-stop — isteğe bağlı (03.09.2026 eklendi, kullanıcı bulgusu — ALGOUSDT vakası: "%0.08'lik ham fiyat hareketiyle Kademeli -0.62 USDT, Sabit tahmini -0.16 USDT gösteriyor, Sabit nasıl daha az zarar etmiş olabilir?"). --scale-in ile birlikte anlamlıdır (o kapalıyken hiçbir etkisi yoktur). Varsayılan KAPALI (düzeltilmiş davranış): pozisyona ekleme tetiklendiğinde stop, yeni (ağırlıklı ortalama) girişe göre yeniden hesaplanır ama ekleme ÖNCESİNDEKİ stoptan DAHA SIKI (fiyata daha yakın) hale GETİRİLEMEZ — çünkü ekleme kâr yönünde (TP1'e doğru) tetiklendiği için ortalama giriş lehte bir noktaya kayıyor, bu da eski (düzeltilmeden önceki) mantıkla stop'u da fiyata yaklaştırıp küçük/sıradan bir geri çekilmede bile pozisyonu erken, büyümüş miktarla orantısız büyük zararla durdurabiliyordu. Bu bayrak AÇILDIĞINDA o ESKİ (hatalı, hiç kelepçelenmemiş) davranış bilerek yeniden üretilir — SADECE eski sonuçları yeniden üretmek/karşılaştırmak içindir, gerçek raporlama koşumlarında KULLANILMAMALI. DİKKAT: aynı hata canlı botta da (kademeli büyütme fonksiyonunda) bulunup düzeltildi; GÜNCELLEME (03.09.2026, kullanıcı talebi: "canlı içinde bu eklemeleri parametrik yapalım") — canlıdaki düzeltme de artık bu bayrakla AYNI mantıkta, ayrı bir DB-backed anahtarla ("Bot Kriterleri" > "Kademeli Pozisyon Büyüklüğü" > "Eski (Hatalı): Kademeli Sonrası Stop Daralabilir") A/B edilebilir — bu backtest bayrağı ile canlıdaki checkbox birbirinden BAĞIMSIZDIR, biri diğerini etkilemez.--reverse-candle-exit N — isteğe bağlı (17.09.2026 eklendi, kullanıcı talebi: "işlem açıldıktan sonra kademeli ekleme yapıldıktan sonra üst üste n kadar ters 5dk mum kapanırsa işlem otomatik olarak kapansın"). --scale-in ile birlikte anlamlıdır — SADECE pozisyona GERÇEKTEN ekleme yapıldıktan (scale-in tetiklendikten) SONRA devreye girer, öncesinde hiçbir etkisi yoktur. "Ters mum": mumun KENDİ açılış/kapanışına göre pozisyon yönüne ters kapanması (SHORT'ta kapanış>açılış/yeşil, LONG'ta kapanış<açılış/kırmızı) — önceki mumla veya trendle kıyaslama yapılmaz. Bu koşulu üst üste (ara vermeden) sağlayan 5dk mum sayısı N'e ulaşınca işlem o mumun kapanış fiyatıyla REVERSE_CANDLE nedeniyle kapatılır; araya UYUMLU (ters olmayan) bir mum girerse sayaç sıfırlanır. Varsayılan 0 = KAPALI (kullanıcı talebi: "default değer 0 yani kapalı durumda gelsin"). --scale-in-trigger/--confirm-5m-candles/--no-2m-gate ile AYNI desen: bu bayrak CLI'dan verilmezse (kullanıcı talebi: "backtest canlıda değer ne ise otomatik alsın"), admin panelin "Bot Kriterleri" ayarını (reverse_candle_exit_count DB anahtarı) otomatik kullanır — canlı bot da AYNI DB anahtarını okur, ikisi arasında elle senkronize edilmesi gereken ayrı bir değer YOKTUR.--no-2m-gate — isteğe bağlı (02.09.2026 eklendi, kullanıcı talebi: "2dk mum onayı hala mantıklı mı karar veremiyorum, panelde aç/kapa yapalım, backtest'te test edip sonucuna göre karar veririm"). EXTREME sinyali tespit edilirken RSI5m aralık kontrolüne EK OLARAK aranan "son kapanan 2 dakikalık mumun rengi de yönle uyuşsun" şartını KAPATIR (varsayılan: bu şart aranır). DİKKAT — --confirm-5m-candles ile KARIŞTIRILMAMALI: o, tespit SONRASI ayrı bir onay aşamasıdır (N adet 5dk mum onayı); bu ise tespit ANINDA aranan tek bir 2dk'lık ön-şarttır — ikisi aynı anda, birbirinden bağımsız çalışabilir. Admin panelin "Bot Kriterleri" > "2 Dakikalık Mum Onayı Aransın" ayarıyla AYNI DB anahtarını (require_2m_candle_gate) paylaşır; bu bayrak verilmezse o ayarın DB değeri varsayılan alınır. Canlı botta da AYNI ayar kullanılır (EXTREME sinyalin "5dk Teyidi" gate'inin bir alt-şartı).--no-tp1-trail — isteğe bağlı (27.08.2026 eklendi, kullanıcı talebi: "daha dinamik bir durum yaratmak mümkün mü" → seçilen seçenek "TP1 sonrası gerçek anlamda trailing"). Varsayılan (bu bayrak VERİLMEZSE) TP1 vurulduktan sonra, TP2'ye ulaşılana kadar fiyat yeni bir zirve (LONG) / dip (SHORT) yaptıkça stop AYNI %90 formülüyle (Giriş + (Zirve-Giriş)×0.9) o yeni zirveye göre SÜREKLİ yeniden hesaplanır ve SADECE lehe yönde çekilir (asla gevşetilmez) — böylece fiyat TP1'i geçip TP2'ye doğru ilerlemeye devam ederse ekstra kâr da kilitlenir. Bu bayrak VERİLİRSE eski (tek seferlik) davranışa dönülür: TP1 vurulduğu anda stop bir kez %90 seviyesine sıçrar, sonra TP2'ye kadar SABİT kalır — fiyat ne kadar ileri gidip gelirse gelsin güncellenmez. Aynı dönemi bu bayrak açık/kapalı iki ayrı --out dosyasına koşup CSV'leri karşılaştırarak sürekli trailing'in gerçekten katkısı olup olmadığı test edilebilir. Backtest'te (TradeSimulator.cs, tp1Trail parametresi) kâr oranını artırdığı doğrulandıktan sonra CANLI BOTA da (varsayılan AÇIK olarak) uygulandı — orada zaten 500ms'de bir çalışan "hızlı pozisyon izleme" döngüsüne eklendi, sadece anlamlı bir iyileşme (≥%0.05) olduğunda gerçek borsa stop güncellemesi tetiklenir (rate-limit/gereksiz emir riskini önlemek için), ve mirror hesaplara da aynı anda senkronize edilir. Canlı botta bu davranışı kapatmak için ayrı bir anahtar YOKTUR — sadece backtest'te karşılaştırma amaçlı mevcuttur.--confirm-5m-candles N — isteğe bağlı (31.08.2026 eklendi, kullanıcı talebi: "işlem onayı aldıktan sonra 2 tane 5dk'lık mum onayı almadan işlem açmasın"). Varsayılan 0 (kapalı, eski davranış — sinyal kriterleri geçer geçmez işlem AYNI ANDA açılır). N verilirse, kriterleri geçen bir aday HEMEN işleme dönüştürülmez: sinyalin ÜZERİNE gelen N tane ARDIŞIK KAPANAN 5dk mumun kendi rengi (Close vs Open) sinyal yönüyle uyumlu OLMAK ZORUNDADIR (LONG → hepsi yeşil, SHORT → hepsi kırmızı). Hepsi uyuşursa işlem N'inci mumun kapanış fiyatından açılır — stop/TP seviyeleri bu YENİ fiyata göre aynı yüzdelerle yeniden kurulur (RSI/ADX/DI/VWAP gibi teşhis alanları orijinal sinyal anındaki değerler olarak kalır). Herhangi bir mum uyuşmazsa (veya veri N mum kadar ilerlemeden biterse) aday TAMAMEN reddedilir, işlem hiç açılmaz. Amaç: sinyal anındaki ham RSI/ADX/VWAP teyidine ek olarak, fiyatın GERÇEKTEN de birkaç mum boyunca sinyal yönünde devam ettiğini görmeden pozisyona girmemek — erken/yanlış dönüşlere karşı ek bir süzgeç. Kullanıcının istediği değer 2; farklı değerlerle (1, 2, 3) ayrı --out dosyalarına koşup CSV'leri karşılaştırarak gerçek katkısı ölçülebilir. Sadece ana backtest koşumunu etkiler — verify komutu (tek-an teşhis) bu geciktirmeyi uygulamaz.--max-concurrent-positions N — isteğe bağlı (05.09.2026 eklendi, kullanıcı talebi: "hesap ayarlarında parametrik bir ayar yapalım aynı şekilde backtest e de ekleyelim. default 10 set edelim" — admin panelin "Günlük Kırılım" tablosuna eklenen "En Fazla Eşzamanlı" sütununun ortaya çıkardığı bilgiden sonra). Varsayılan 10 — canlı bottaki admin panel "Bot Kriterleri" > "Maks. Eşzamanlı Açık İşlem (Global)" ayarıyla (BotConfig.MaxConcurrentPositions) AYNI. ÖNEMLİ MİMARİ FARK: canlı botta bu tavan GERÇEK ZAMANLI kontrol edilir (yeni sinyal, o anki açık pozisyon sayısına bakılarak anında kabul/red edilir) — backtest'in ana döngüsü ise her sembolü BAĞIMSIZ ve SIRAYLA (bir sembolün TÜM tarih aralığı bitmeden diğerine geçmeden) taradığı için gerçek zamanlı/entegre bir "şu an kaç pozisyon açık" bilgisine sahip DEĞİLDİR. Bu yüzden tavan burada, TÜM sembollerin sinyalleri toplandıktan SONRA ayrı bir KRONOLOJİK SÜPÜRME (sweep) geçişiyle uygulanır: adaylar giriş zamanına göre sıralanır, o anda zaten bu kadar pozisyon "açık" (kapanmamış) ise yeni aday REDDEDİLİR ve sonuçtan (CSV/DB/özet raporların TAMAMINDAN) tamamen çıkarılır — sanki canlı botun global tavanı o anda işlemi hiç açtırmamış gibi. Sonuç olarak GERÇEK zamanlı bir gate'ten ayırt edilemez (aynı sinyal kümesi + aynı kronolojik sıra + aynı tavan kuralıyla aynı adaylar kabul/red edilir), ama uygulanışı ayrı bir son-işleme adımıdır. DAVRANIŞ DEĞİŞİKLİĞİ: bu özellik eklenmeden önce backtest'te hiçbir eşzamanlılık tavanı YOKTU (sınırsız); bu bayrak hiç verilmese bile artık varsayılan 10 ile SESSİZCE uygulanır — eski (sınırsız) davranışı yeniden üretmek için çok yüksek bir değer (ör. 999) girilebilir.
Backtest sonucunu nasıl yorumlamalı? (canlı ile birebir eşleşme beklenmemeli)
EKLENDİ (03.09.2026, kullanıcı vakası: AKEUSDT'de canlı bir SHORT açtı ama backtest aynı dönemi taradığında bu işlemi hiç üretmedi — verify ile incelendi, RSI15/ADX/DI canlıyla neredeyse birebir çıktı, tek fark ADX toleransının backtest'in KENDİ bağımsız hesabında eşiği sadece +0,19 puan aşmasıydı — --boundary-tolerance 0.3 ile tekrar denendiğinde sinyal gerçekten tetiklendi, "SONUÇ=SİNYAL AÇILIR"). Bu vaka, backtest sonuçlarını okurken akılda tutulması gereken genel bir gerçeği gösteriyor:
Backtest, canlı botun aynı kopyası DEĞİL — aynı kuralları geçmiş veriye bağımsız olarak yeniden uygulayan ayrı bir hesaplama. RSI/ADX/DI gibi göstergeler canlıda gerçek zamanlı akıştan, backtest'te ise geçmiş mumların toplu halde yeniden işlenmesinden hesaplanıyor — ikisi neredeyse hep aynı sonucu verir, ama eşiklerin (ADX toleransı, DI toleransı, ADX tavanı vb.) TAM sınırında kalan işlemlerde binde/yüzde birkaç puanlık ondalık farklar bazen bir tarafta sinyali açtırıp diğerinde engelleyebilir. Bu bir hata değil, iki bağımsız hesaplamanın doğal, kaçınılmaz bir sonucu.
Bu yüzden bir backtest sonucunu (Kriter Analizi tablosu, CSV, ya da Geçmiş Backtest Koşumları özeti) okurken:
- Tek tek işlem eşleşmesi arama. "Canlı şu işlemi açtı, backtest de birebir aynı dakikada açmış mı" diye trade-trade karşılaştırmak yanıltıcı — sınırda kalan birkaç sinyal beklenir, tek başına bir sorun işareti değildir.
- Toplam tabloya güven — win rate, toplam PNL%, işlem sayısı, saatlik/moda göre kırılım gibi AGREGE metrikler stratejinin genel karakterinin makul bir yaklaşığıdır. Yeterince büyük bir örneklemde (haftalar/aylar, onlarca-yüzlerce işlem) bu sınır-etkisiyle kaybedilen/kazanılan birkaç işlem istatistiksel olarak birbirini büyük ölçüde götürür, sistematik bir yanlılık yaratmaz.
- Ne zaman gerçekten endişelenmeli: backtest'in bulduğu işlem sayısı canlıdan BÜYÜK farkla azsa/çoksa (birkaç işlem değil, kat kat fark), ya da win rate/toplam PNL canlıdan çok uzaksa — bu tek bir sınır vakasından değil gerçek bir mantık farkından kaynaklanıyor olabilir (yanlış mum besleniyor, parametre uyuşmazlığı, veya
verify komutuna admin panelin gösterdiği Türkiye yerel saati doğrudan UTC sanıp vermek — verify argümanı HER ZAMAN UTC'dir, admin paneldeki Açılış/Kapanış saatinden 3 saat çıkarman gerekir). O zaman verify ile derinlemesine incelemeye değer.
- Backtest'i en güvenilir kullandığın yer: farklı parametreleri BİRBİRİNE göre kıyaslamak (ör.
--adx-rise-tolerance 2 mü 3 mü daha iyi, --stop-loss-pct 1.3 mü 1.5 mi) — çünkü iki backtest koşumu AYNI yöntemle hesaplandığı için aralarındaki fark güvenilir, canlıyla birebir eşleşmesi şart değildir.
Kısacası: backtest sonucunu "stratejimin genel eğilimi bu" olarak oku, "canlının yaptığı her işlemin birebir kopyası" olarak değil.
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.