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).
registerLocalDocument always did a plain insert, so retrying a
document whose first OCR attempt failed created a new duplicate
row each time instead of updating the existing one. Now looks up
an existing (case_id, filename) match and updates it in place.
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).
Supabase migrated from the sslip.io address to https://supa.ayris.tech;
scratch.js now reads SUPABASE_URL/SUPABASE_SERVICE_ROLE_KEY from env instead
of hardcoding the stale host and a plaintext secret.
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>
Mustafa Yildiz