Faz 1-4 (yerel-öncelikli veri mimarisi) her dava dosyası için OCR,
register-local, tekil evrak yedeği, case.sqlite/master-index yedeği ve
register-case-path gibi çok sayıda ek istek üretiyor. Eski 5000/gün
limiti gerçek kullanımda kolayca doluyor ve Drive yedeğini sessizce
"pending" bırakıyordu.
Yeni GET /api/mobile-relay/case/:caseId/summary — kullanıcının Drive'ındaki
case.sqlite'ı anlık olarak açıp sadece belge metadata'sı (extracted_text
HARİÇ) ve AI analiz özetlerini döner, hiçbir şey kalıcı olarak saklanmaz
(geçici dosya işlem sonunda silinir). google_drive_files'ı reuse eden
yeni /google-drive/register-case-path endpoint'i, case_id ↔ Drive'daki
local_path eşleşmesini tutan yeni case_drive_files tablosuna yazıyor
(migration: laawos/sql/21_case_drive_files.sql, Supabase'de elle
çalıştırılması gerekiyor).
better-sqlite3 + @types/better-sqlite3 eklendi; node:22-alpine (musl)
için gerekli prebuild paketle geliyor, ek derleme adımı gerekmiyor
(doğrulandı).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Yerel-öncelikli veri mimarisi (Faz 3) — registerLocalDocument, case.
controller.ts'in 6 fonksiyonu (5 analiz + Dijital Stajyer) ve drafting.
controller.ts'in generateDraft/generateAngarya'sı artık PERSIST_TO_
POSTGRES ortam değişkenine göre davranıyor.
Bayrak varsayılan olarak true (mevcut davranış birebir korunuyor) —
kod deploy'u gerçek davranışı DEĞİŞTİRMİYOR. Kullanıcı gerçek veriyle
Faz 1/2'yi (yerel SQLite'a çift yazma + istekten metin kabul etme) test
edip güvendiğinde, PERSIST_TO_POSTGRES=false ayarıyla (kod değişikliği
gerekmeden) yazmalar durur; geri dönüş de aynı şekilde anlık.
case_events ve chat_messages kapsam dışı, dokunulmadı. Angarya taslakları
için bilinen bir sınırlama var: Faz 1'de yerel dual-write eklenmediğinden,
bayrak kapatıldığında bu taslaklar hiçbir yerde kalıcı olmayacak.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Yerel-öncelikli veri mimarisi (Faz 2) — case.controller.ts'in 5 analiz
fonksiyonu ve analyzeDigitalIntern artık req.body.documents'ı öncelikli
kaynak olarak kullanıyor (Electron'un yerel SQLite'tan gönderdiği),
yoksa mevcut Postgres sorgusuna düşüyor. buildCaseChatContext ve
generateDraft da aynı şekilde caseDocuments/latestAnalysisSummaryJson
opsiyonel alanlarını kabul ediyor. WhatsApp entegrasyonu (whatsapp.
controller.ts) bilinçli olarak dokunulmadı — yerel dosya erişimi
olmadığından mevcut Postgres yedek yoluna düşmeye devam edecek.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kapsam genişletildi: ilk yükleme analizi, iddianame ön-analizi (sadece ceza),
Çelişki Avcısı'na hukuk referansı, Uzlaşma/Arabuluculuk analizi ve Dilekçe
Taslağı promptlarına da ceza muhakemesi ve/veya hukuk mahkemeleri referansı
eklendi. Angarya (Süre Tutum/Mazeret/Vekaletname) kasıtlı olarak dışarıda
bırakıldı — o araç tanımı gereği hiçbir hukuki tartışmaya girmiyor.
CEZA_MUHAKEMESI_REFERANSI ve HUKUK_MAHKEMELERI_REFERANSI export edildi ki
drafting.controller.ts document.controller.ts'den import edebilsin.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dava Özeti, Dava İlerlemesi ve Strateji Analizi promptlarına mahkeme türü
(Asliye Hukuk, Sulh Hukuk, Aile, Asliye Ticaret, İş, Tüketici, İcra Hukuk,
Fikri ve Sınai Haklar, Kadastro), yargılama usulü ve zorunlu arabuluculuk
şartlarını özetleyen bir referans bloğu eklendi. Çelişki Avcısı'na
eklenmedi — o araç ceza usulüne özgü kolluk/savcılık/mahkeme aşamaları
arası ifade çelişkilerine odaklı, hukuk davalarında karşılığı yok.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dava Özeti, Dava İlerlemesi, Çelişki Avcısı ve Strateji Analizi promptlarına
soruşturma/kovuşturma sırası, evrak türleri ve CMK m.223 hüküm türlerini
özetleyen ortak bir referans bloğu eklendi; AI dosyanın ceza davası olup
olmadığına kendi karar veriyor, rijit bir dava-türü sınıflandırması yok.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
chat.controller.ts'teki dosya-bağlamı toplama mantığı (belgeler + analiz
özeti + geçmiş mesajlar) buildCaseChatContext() olarak paylaşılan hale
getirildi — mevcut SSE sohbeti (chatMessage) davranış değişmeden bunu
kullanıyor, yeni POST /api/whatsapp/message uç noktası da aynı motoru
tek-seferlik (non-streaming) çağırıyor.
Kimlik doğrulama farklı: bu uç nokta bir Supabase oturumu taşımıyor
(n8n'den gelen anonim WhatsApp mesajı), X-Webhook-Secret ile korunuyor.
Telefon → hesap eşleştirmesi profiles.phone üzerinden, hangi dava
dosyasıyla konuşulduğu whatsapp_sessions'ta tutuluyor (bkz. laawos
sql/20_whatsapp_integration.sql).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Profil bulunamadığında otomatik açılan trial süresi Postgres trigger'ıyla
(handle_new_user, 3 gün) tutarsızdı. İkisi de artık aynı app_settings
tablosundan okuyor (bkz. laawos/sql/19_configurable_trial_and_status_gate.sql).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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).