# v0.3.14 kaynak keşif regresyon raporu

Referanslar: v0.1.9 (eski çalışan varyant bazlı keşif) ve v0.3.13 (güncel aile bazlı keşif).

## 1. Tam varyant sorgusu aile sorgusuna dönüşmüş

v0.1.9 `worker/discover.py` `run_known_merchants()`:

- her `products × merchants` satırı için ayrı arama yapıyordu;
- `make_search_url(row)` → `product_query()` kullanıyordu;
- sorgu model + kapasite + renk içeriyordu;
- arama HTML'inden o varyanta uyan en fazla 8 ürün sayfası deneniyordu.

Örnek: `Apple iPhone 16 Pro 256 GB Siyah Titanyum`.

v0.3.13:

- ürünleri `product_family_key` ile grupladı;
- `make_search_url(base,family=True)` → `product_family_query()` kullandı;
- kapasite ve renk arama sorgusundan çıkarıldı;
- aynı geniş aile arama sonucu bütün GB/renk varyantlarında tekrar kullanıldı.

Örnek sorgu: `Apple iPhone 16 Pro`.

Bu değişiklik HTTP isteğini azalttı ancak özellikle mağaza aramalarında doğru varyantın ilk sonuçlara düşme olasılığını ciddi azalttı.

## 2. Cooldown mağaza deneme bütçesini tüketiyordu

v0.3.13 `run_known_merchants()` akışı:

```python
if processed >= limit: break
processed += 1
...
if not merchant_available(...):
    ...
    continue
```

Dolayısıyla cooldown mağazaya hiç HTTP isteği yapılmadığı halde `processed` artıyordu.
Bootstrap tarafında `discover_limit=2` olduğundan ilk iki mağaza cooldown ise üçüncü sağlıklı mağazaya ulaşılmıyordu.

Sunucu logundaki `mağaza-içi: (2,0,0,2)` bu kod yoluyla birebir uyumludur.

v0.3.14:

- cooldown mağaza `attempted` sayacını artırmaz;
- yalnız gerçek HTTP/Chromium arama isteği bütçeyi tüketir;
- sağlıklı mağazalar SQL sıralamasında öne alınır;
- bootstrap gerçek mağaza deneme bütçesi 6'dır.

## 3. Kaynak bulma ile kaynak kabul etme aynı yerde fazla daralmıştı

v0.3.14 eski geniş kaynak bulma davranışını geri getirir fakat eski güvenlik seviyesine dönmez.

Kaynak arama:

1. tam varyant mağaza sorgusu,
2. aile kardeş kaynak tohumu,
3. indeks köprüsü,
4. harici web araması (varsa).

Kaynak kabulü ise her zaman güncel `consider_page()` filtresinden geçer:

- kardeş model kontrolü,
- RAM/depolama ayrımı,
- tam kapasite,
- renk,
- ürün durumu,
- fiyat çıkarımı ve güven skoru.

## 4. Eski sürüm dolaylı indeks fiyatını kullanıcıya gösteriyordu

v0.1.9 katalog SQL'i `indirect_offers` için `min_indirect_price` hesaplıyor ve direct fiyat yoksa `~fiyat` + `Arama indeksi` etiketi gösteriyordu.

Aile mimarisine geçildikten sonra `family_rollups` yalnız direct fiyatı olan varyantları `eligible` yaptı. Sonuç: worker bir indeks fiyat kanıtı bulsa bile kullanıcı ekranında ürün hâlâ fiyat yokmuş gibi görünüyordu.

v0.3.14:

- direct fiyat her zaman birinci önceliktir;
- direct yoksa condition-verified aktif `indirect_offers` katalog fallback'i olabilir;
- fiyat `~` ile gösterilir;
- açıkça `İndeks fiyatı · mağazada doğrulama bekliyor` yazılır;
- direct mağaza linki yerine `Fiyat kaynağını aç` sunulur.

## 5. Epey köprüsü fiyatı okumuyordu

v0.3.13 Epey sayfasını yalnız dış mağaza URL'si bulmak için kullanıyordu. Çıkış linkleri JavaScript/form/data attribute yapısında olduğunda `bridge_outbound_links()` sıfır aday verebiliyordu; sayfadaki açık TL fiyatı ise kaydedilmiyordu.

v0.3.14 Epey'deki **tekil teklif bloğunu** ayrı ayrı inceler:

- tam model,
- gerçek storage (RAM değil),
- hedef renk,
- condition etiketi,
- açık TL fiyatı

eşleşirse yalnız `indirect_offers` kaydı oluşturur. Epey hiçbir zaman doğrudan mağaza fiyatı sayılmaz.

Sıfır ürün için `Yenilenmiş`, `Açık kutu`, `2.El/İkinci el` sinyalli tekil kartlar reddedilir.

## Sonuç

Regresyonun ana nedeni worker servislerinin çalışmaması değil, **kaynak keşif sorgusunun aile bazında fazla genişletilmesi + deneme bütçesinin cooldown satırlarında harcanması** idi. Dış arama API'lerinin 402/403'e düşmesi bu regresyonu görünür hale getirdi.
