mevzuat-etl'in doldurduğu Supabase mevzuat/mevzuat_madde tablolarından
(aynı proje) ilgili kanun maddelerini bulup analiz/taslak üretiminden önce
prompt'a ekliyor. Bulma: önce dava metnindeki açık atıfları regex ile yakala
(TCK m.141, 5237 sayılı Kanun'un 141. maddesi gibi, tur-agnostik), boşsa
precedent.controller.ts'deki AI-keyword-sıkıştırma + tam-metin arama
desenine düşer. Hiçbir zaman exception fırlatmaz, mevzuat bulunamazsa analiz
normal devam eder.
Dilekçe Taslağı (generateDraft) farklı ele alınıyor — çıktısı JSON değil düz
metin ve aynen dilekçe belgesi olarak kullanılıyor, bu yüzden referans
bloğu ayrıca işaretlenip sistem promptuna "kopyalama, sadece atıf yap"
talimatı eklendi. generateAngarya (Süre Tutum/Mazeret/Vekaletname) bilerek
dışarıda bırakıldı — hukuki tartışma içermeyen idari dilekçeler.
Tasarım: mevzuat-etl/docs/superpowers/specs/2026-08-17-laawos-mevzuat-entegrasyonu-design.md
Not: drafts.used_legislation (jsonb) sütunu Supabase Studio'dan elle eklendi.
KEEP_ALIVE '30m' -> -1: GPU'da bolca boş VRAM var, modeli sürekli bellekte
tutmanın maliyeti yok, 30dk sınırı gereksiz soğuk-başlangıç gecikmelerine
sebep oluyordu (bkz. 2026-08-14 log: 44GB boş / 17.5GB kullanılan).
Kullanıcı OCR sonuçlarının markdown formatında gelmesini istedi — test
edildi (gerçek çok sayfalı taranmış evrakta doğrulandı), tablo/başlık
yapısını doğru yakalıyor.
Mizan ve DeepSeek-OCR aynı self-hosted GPU'yu paylaşıyor; backend'de hiçbir
eşzamanlılık sınırı yoktu, yoğun anlarda istekler Ollama kuyruğunda 90sn'yi
aşıp sessizce "başarısız" görünüyordu. aiQueue.ts, GPU'ya giden istek sayısını
sınırlayıp fazlasını backend'de bekletiyor.
Yeni POST /documents/ocr-image, tek bir görseli DeepSeek-OCR ile metne
çeviriyor (Electron tarafındaki çok sayfalı TIFF/taranmış PDF işleme
adımının kullanacağı uç, ayrı bir PR'da bağlanacak).
GET /api/google-drive/backup-files: kullanıcının senkronize
edilmiş dosyalarının listesi (PRD §28 "N dosya bulundu"). GET
/download: bir dosyayı Drive'dan proxy'leyip ham baytları döner —
istenen drive_file_id'nin gerçekten bu kullanıcıya ait olduğu
önce doğrulanıyor (PRD §39, başka kullanıcının backup'ı sızmasın).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /api/google-drive/upload: Electron'un backupQueue'sunun
gönderdiği tek dosyayı alıp Google'ın resumable upload session'ıyla
Drive'a yazıyor (mevcutsa aynı drive_file_id'yi PATCH ederek yeni
sürüm olarak, PRD Test 4). Dava başlığı = Drive'daki alt klasör adı
(lokal yapı korunuyor). GET /backup-status: Ayarlar > Yedekleme
paneli için toplam dosya/boyut/son senkron özeti.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PRD "AyrisLegal Google Drive Backup & Recovery" kapsamında sadece
backend altyapısı: OAuth connect/callback/status/disconnect/refresh
uç noktaları, AES-256-GCM token şifreleme (tokenCrypto.ts), tek
kullanımlık CSRF state (oauthState.ts), drive.file scope ile
AyrisLegal/Davalar klasör oluşturma (googleDriveClient.ts). Electron
tarafı (dosya tarama/kuyruk/UI) ayrı bir aşamada.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
800 token sınırı çok düşüktü — çok bölümlü hukuki cevaplar (kira feshi,
tazminat hesabı gibi) bu sınıra çarpıp cümlenin ortasında kesiliyordu.
Varsayılan ve chatMessage/sendThreadMessage'ın kullandığı num_predict
2048'e çıkarıldı. Ayrıca Ollama done_reason:"length" döndürdüğünde
(yanıt sınıra çarpıp kesildiğinde) sunucu loglarına uyarı yazılıyor.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tüm AI çağrıları artık ortak lib/aiClient.ts üzerinden gidiyor:
- /v1/chat/completions yerine native /api/chat (think:false burada
güvenilir çalışıyor)
- keep_alive:30m ile model her istekte bellekten atılıp soğuk
başlamıyor
- num_predict ile öngörülemez uzunlukta üretime üst sınır
- İnteraktif sohbet uç noktaları (chatMessage, sendThreadMessage)
artık SSE ile token token akıtıyor
- Dosya sohbetinde varsayılan olarak belgenin tam metni değil analiz
özeti gönderiliyor; tam metin sadece kullanıcı açıkça isterse
eklenir
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- summarizeCase: if an iddianame is among the case's documents, run a
narrow first-pass analysis on it alone (isnatEdilenSuc, iddiaOzeti,
onemliTarihler), then feed that as context into the general
case-wide evaluation instead of treating every document equally.
- ANALYSIS_SYSTEM_PROMPT no longer asks the AI to guess "taraflar" -
that now comes from real UYAP data (cases.parties) instead.
- Removed the hardcoded RunPod proxy URL fallback from every call
site (document/chat/precedent controllers + lib/openai.ts) - it was
a real infra endpoint checked into source. New lib/aiConfig.ts
throws if RUNPOD_API_BASE_URL isn't set rather than silently
falling back to it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The UYAP extension now captures the davaci/davali/sanik + vekil data
from the "Taraf Bilgileri" tab and sends it once per case. This
endpoint finds/creates the matching case by title (same lookup used
by registerLocalDocument, now shared via lib/caseLookup.ts) and stores
it in a new cases.parties column - a much more reliable source for
the case detail screen's "Taraflar" info than the AI's own guess from
OCR'd document text.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mustafa Yildiz