İki ayrı neden vardı:
1) window.open sunucu yanıtından SONRA çağrılıyordu; Safari, PWA ve sıkı ayarlı
Chrome bunu açılır-pencere sayıp sessizce engelliyordu — düğme "çalışmıyor"
görünüyordu. Sekme artık tıklamanın hemen içinde boş açılır, adres gelince
yönlendirilir. Engellenirse gerçek bir bağlantı (a href) gösterilir; bağlantı
tıklaması hiçbir tarayıcıda engellenmez.
2) ilan.gov.tr bazı kayıtlarda İKN'yi başta/sonda boşluk ve kesme boşluğu (nbsp)
ile veriyor (" 2026/1622878"). Bu 50 kayıtta panel "EKAP formatında değil"
deyip düğmeyi hiç göstermiyordu. İKN artık alınırken boşluksuz saklanıyor;
panel ve doküman araması da savunma amaçlı temizliyor.
Ayrıca: "EKAP'ta 0 doküman kayıtlı" yanıltıcı metni kaldırıldı (EKAP arama
kaydı sayıyı vermiyor), EKAP'ın önce güvenlik doğrulaması istediği açıklandı.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- server/ted-ceviri.mjs: TED'in kendi Türkçe alanı varsa onu kullanır; yoksa
OpenRouter ile toplu çevirir (deepseek-v4-flash → gemini 3.7 flash → glm),
sonucu server/data/ted.sqlite'ta ilan numarasına göre saklar
- İstek en fazla 12 sn bekler, kalan çeviriler arka planda sürer;
yanıt ceviriBekleniyor bayrağı taşır, ön yüz sessizce yeniden çeker
- Kartta Türkçe başlık + küçük özgün başlık, Türkçe açıklama (3 satır),
ülke kodları Türkçe ad (TUR → Türkiye, AUT → Avusturya…)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
saidsurucu/ihale-mcp deposu incelenirken EKAP arama API'sinin doküman ici
arama parametreleri oldugu goruldu: teklifCetvelindeAra, teknikSartnamedeAra,
idariSartnamedeAra, sozlesmeTasarisindaAra. EKAP dokumani kendi tarafinda
indeksliyor — yani teklif cetvelinde arama icin dokumani indirmeye (ve
CAPTCHA'ya) gerek yok.
Kullanicinin sikayetini olcen kanit:
ELDIVEN basliкta 1.135 → teklif cetvelinde 29.057
ORTOPEDIK VIDA baslikta 0 → teklif cetvelinde 3
HEMOGRAM baslikta 283 → teklif cetvelinde 2.529
"ORTOPEDIK VIDA" hicbir ihale BASLIGINDA gecmiyor; gectigi ihalelerin adi
"VETERINER ILAC ... SARF MALZEME". Basliga bakan firma bunlari bulamiyordu.
- ekap-v2.mjs: searchBody artik opts.kapsam ile daraltilabiliyor;
searchInDocuments() yalnizca teklif cetvelinde (istege bagli teknik
sartnamede) arar ve sonucu normalize eder
- GET /api/urun-ara?q=&skip=&take=&teknik= — 5 dk bellek onbellegi ile
(EKAP'a uzak cagri, ayni sorgu kaynagi yormasin)
- Header'da "URUN ARA" dugmesi + UrunAramaModal: sayfalama, "sadece teklif
verilebilir" suzgeci, havuzda acik olan ihalede detayi acma kisayolu
SINIR: EKAP hangi kalemin eslestigini dondurmuyor, yalnizca eslesen ihaleleri.
Kalem dokumu icin dokuman yuklemeye dayali ortak havuz yolu gecerli kaliyor;
arayuzde bu acikca yaziliyor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- server/cpv-classify.mjs (yeni): existing (kalem kodu) → keyword (66 kural, 45 OKAS_BOLUM kodunun tamamı kapsanıyor) → AI (analyzeSpec, sadece sözlükte gerçekten var olan kod kabul edilir) hibrit sınıflandırma
- server/index.js: cache.tenders'a eklenmeden ÖNCE her ihale için CPV sınıflandırması await'leniyor (mevcut "sektör" alanının aksine, sonradan zenginleştirilmiyor) — hem ilk yükleme hem arka plan tamamlama yolunda
- İKN bazlı kalıcı SQLite önbellek (history-store.mjs) — aynı ilan bir daha asla yeniden sınıflandırılmıyor
- /api/meta/filtreler artık cpvBolumler döndürüyor
- Frontend: Sektörler'in hemen altına CPV Kodu filtresi (arama + çoklu seçim), ihale kartında CPV rozeti, landing page'de yeni özellik: "AB uyumlu CPV sınıflandırması — Türkiye'de ilk"
Denetlenen 5 teknik borç kalemi de kapatıldı:
1) Stripe webhook + gerçek yetkilendirme (ÖNCEDEN YOKTU)
- POST /api/billing/webhook — SDK'sız HMAC-SHA256 imza doğrulaması,
tekrar saldırısına karşı ±300sn zaman penceresi, timingSafeEqual
- checkout.session.completed / subscription.created|updated|deleted işlenir
- Ödeme → kullanıcının planı sunucuda güncellenir (önce ödeme hiçbir şeyi
değiştirmiyordu)
2) Plan kotaları GERÇEKTEN uygulanıyor (önce sadece tanımlıydı)
- server/entitlements.mjs: plan hakları + kotaKontrol()
- ekip, belge adedi/boyutu, API anahtarı kotaları sunucuda zorlanır
- Kota aşımında 402 + anlaşılır Türkçe mesaj; arayüzde KotaUyarisi bandı
- /api/me/plan: plan, haklar ve gerçek kullanım
3) Kullanıcı verisi localStorage'dan sunucuya taşındı
- server/user-store.mjs: kullanici_verisi tablosu (izinli anahtar listesi)
- AppContext girişte sunucudan yükler, değişiklikleri sunucuya yazar;
localStorage yalnızca çevrimdışı önbellek
- Artık cihaz değişince veri kaybolmuyor
4) API anahtarları gerçek (önce Math.random ile tarayıcıda üretiliyordu)
- Sunucuda crypto.randomBytes ile üretilir, YALNIZCA sha256 hash'i saklanır
- Ham değer bir kez gösterilir; verifyApiKey ile doğrulanır, son kullanım
izlenir, iptal anında geçerli olur
5) Belge deposu gerçek (önce boyut Math.random'dı, dosya hiç yüklenmiyordu)
- Dosyalar kalıcı volume'e yazılır, boyut GERÇEK bayt
- Auth'lu indirme (blob), silme diskten de siler, kota sunucuda uygulanır
1) Bildirim artık KONU odaklı (il değil)
- Kullanıcı hangi konularda ihale alabildiğini seçer; varsayılan tüm Türkiye
- İl/alım türü/favori kurum 'daha da daralt' altında isteğe bağlı
- notify-store: konular kolonu + otomatik şema geçişi
- notifier: konu başlıkları ihale başlığı/sektör/branş/kalemlerde aranır
2) Gerçek firma sitesi tarama (webScraperService mock'unun yerine)
- server/site-scan.mjs: siteyi GERÇEKTEN çeker, ana sayfa + ürün/hizmet/
hakkımızda iç sayfalarını tarar, HTML'i metne çevirir, AI ile firmanın
tedarik edebildiği ihale konularını çıkarır ('uydurma' yasaklı prompt)
- /api/company/scan (auth'lu)
- ai.mjs: systemOverride desteği (farklı görevler için ayrı sistem promptu)
- Arayüz: 'Sitenizi tarayıp konuları otomatik önerelim' → tıklayarak ekleme
Not: eski webScraperService.js sabit anahtar-kelime sözlüğüydü; domain adında
'tanriverdi' geçince tıbbi ürün listesi uyduruyordu.
Bildirim turunu temel-alma adımını atlayarak çalıştırır; abonelik kriterine uyan
ihaleler hemen e-posta olarak gönderilir. Test ve talep üzerine özet için.
Sorun: önbellek süresi dolunca getTenders cache.tenders'ı ilk partiyle (120 ilan)
DEĞİŞTİRİYOR, kalanı arka planda dolduruyordu. Yani her 10 dakikada bir kullanıcı
birkaç dakika boyunca eksik liste görüyordu (canlıda 8.258 havuza karşı 5.319
yüklü olarak yakalandı).
Çözüm: yenilemede mevcut dolu liste sunulmaya devam ediyor; yeni liste ayrı
kurulup TAMAMLANINCA atomik olarak devreye alınıyor. Yalnızca ilk açılışta
(elde hiç veri yokken) ilk parti anında gösteriliyor.
Doğrulama: zorla yenileme sırasında liste 3.795'te sabit kaldı (öncesinde 120).
Sorun: /api/tenders yalnızca 1.060 kayıt döndürüyordu — üç sabit sınır yüzünden
(ilan.gov.tr 8 sayfa=160, DT 300, arşiv 600). Havuz ise 5.000+.
Çözüm:
- ilan.gov.tr sayfaları artık PARALEL çekiliyor (6 eşzamanlı), sıralı değil
- İlk yanıt için 6 sayfa yeter; kalan sayfalar ARKA PLANDA doldurulur, kullanıcı
beklemez (ölçüm: ilk yanıt 0.05s, havuz arka planda 120 → 3.059 ilana çıktı)
- Sayfa sınırı 8 → 300 (6.000 ilan), DT 300 → 5.000, arşiv 600 → 5.000
- Hepsi env ile ayarlanabilir: ILAN_MAX_PAGES, ILAN_ILK_PARTI, ILAN_ESZAMANLI,
DT_LIMIT, HISTORY_LIMIT
- totalCount artık arşivi de içeriyor; 'yüklü' sayısı 'havuz'u geçmiyor
Not: yanıt nginx tarafından gzip'leniyor (8.5x), tüm havuz ~600 KB — boyut
darboğaz değildi, sayfalama darboğazdı.
hikmettan
