# GÖREV: Iddia Hafızası (Claim Memory) — fiko-ai

Bu dosyayı `docs/GOREV-HAFIZA.md` olarak proje klasörüne koy ve ajana "bu görevi uygula" de.

## Amaç
fiko-ai, dağınık bir ortamda **iş yönetimi** yapan bir düzen takipçisi olur. Kullanıcı (Fikri) tüm bilgileri toplu olarak sisteme sayar, sistem bunları ayıklar, düzenler, embedding ile mühürler ve sonraki sorularda (başka kullanıcıların sorularında da) bunlara göre cevap verir. Amaç kimseyi ifşa etmek değil, işi yönetmek ve bilgiyi eksiksiz, güncel tutmaktır. Her kayıtta kimin girdiği sadece izlenebilirlik için saklanır.

## Kurallar (önemli)
1. **Eski sistemler (şirket bölümü, tool executor, ilgili endpoint ve UI) SİLİNMEZ.** Bir özellik bayrağıyla (`FIKO_LEGACY_COMPANY=false`, `FIKO_LEGACY_TOOLS=false`) **deaktif** edilir. Kod yerinde kalır, route'lar kaydedilmez, UI menüsü gizlenir. Bayrak `true` yapılınca eskisi gibi çalışır.
2. **Kayıt silme AKTIF.** Yetkili kullanıcı (yazar veya patron) bir kaydı silebilir. Her silme/değişiklik `audit` koleksiyonuna yazılır (kim, ne zaman, önceki değer).
3. Kimlik gerçek auth'tan gelir (JWT/oturum). `X-Fiko-User` header'ı güvenilir sayılmaz. Auth bitmeden bu özelliği yazma kısmı açılmaz.
4. Gerçek çalışan dosyalar, placeholder yok. Faz faz ilerle, her fazı `docs/ILERLEME.md` dosyasına en üste yaz.

## Veri modeli (MongoDB `claims`)
`_id`, `text`, `embedding` ([]float32), `kind` (firma, kisi, urun, gorev, genel...), `key` (normalize edilmiş ad; liste türleri için), `authorId`, `authorName`, `createdAt`, `updatedAt`, `status` (`aktif | guncellendi | celiskili | gecersiz`), `supersedes` (id).
`audit`: `claimId`, `action`, `by`, `at`, `before`, `after`.
Roller: `patron` (admin) ve `uye`. Çelişkili kayıtları netleştirmek (hangisi geçerli) ve `gecersiz` işaretlemek patronun işidir.

## Yazma akışı
1. Mesajda hatırlatma niyeti var mı? Küçük bir LLM çağrısı (JSON çıktı): `{remember: [{text, kind, key}]}`. Tek mesajda 140 firma gelirse tek tek kayda bölünür.
2. Embedding toplu (batch) üretilir. Model: Ollama `bge-m3` (Türkçe için).
3. Çakışma kontrolü:
   - `kind` listelik türdeyse (firma, kisi, urun) birleştirme **sadece `key` birebir eşleşmesine** göre yapılır. Benzer ama farklı ad ikisi de tutulur, "benzer kayıt var" diye işaretlenir.
   - Diğer türlerde benzerlik ~0.9 üstü ise LLM karar verir: aynı / çelişkili / alakasız.
   - Çelişki: eski kayıt silinmez, ikisi de `celiskili` olur.
   - Güncelleme (zamanla değişen bilgi): eskisi `guncellendi`, yenisi `aktif`.
4. Yazma yanıtı beklemeden arka planda yapılır.

## Okuma akışı
Mesaj önce iki türden birine ayrılır:
- **Bilgi sorusu** → soru embedding'i, `status` yanlis olmayan kayıtlarda top-k (5-8) arama. Kayıtlar yazar adı, tarih ve durumla birlikte sistem prompt'una "bilinen bilgiler" olarak girer. Doğrulanmış kayıt önce gelir. Çelişki varsa model iki tarafı da yazar adıyla belirtir.
- **Liste sorusu** ("firmaların listesini ver") → vektör araması YOK. `kind` ve `status` filtresiyle DB'den sayfalanarak hepsi çekilir. Liste **sunucuda** üretilir (model satır uydurmasın/atlamasın). Model sadece kısa giriş cümlesi yazar. Sonda toplam sayı yazılır ("140 firma").

## Toplu giriş ve iş yönetimi
- Kullanıcı uzun bir bilgi dökümü yapıştırınca sistem hepsini tek tek kayda böler, türlere ayırır ve sonda kısa bir özet verir: "X kayıt eklendi, Y çelişki var, Z kayıtta eksik bilgi var".
- Çelişkiler suçlama olmadan, nötr dille sunulur: "İki farklı bilgi var, hangisi geçerli?" Karar patrondadır.
- Zamanla değişen bilgi (stok, tarih, vardiya) hata sayılmaz, sadece `guncellendi` olur.
- "Bunu kim girdi?" diye sorulursa yazar ve tarih söylenir. Kullanıcı başına güvenilirlik puanı, sayaç ya da kendiliğinden suçlama YOKTUR.

## Firma yönetimi modülleri (aynı sistemin içinde, ayrı uygulama değil)
Proje takibi, PDKS ve diğer firma ihtiyaçları ayrı sistemler olarak değil, `kind` değerleri ve yapılandırılmış alanlar olarak aynı `claims` yapısına eklenir. Kullanıcı doğal dille yazar, sistem bunu tipli kayda çevirir.

| kind | Yapılandırılmış alanlar | Örnek giriş |
|---|---|---|
| `proje` | ad, sorumlu, durum, başlangıç, bitiş, öncelik | "Kalıp B-12 projesi Mehmet'te, ay sonu bitecek" |
| `gorev` | proje, atanan, son tarih, durum | "Ahmet cuma'ya kadar B-12 işleme programını hazırlasın" |
| `personel` | ad, bölüm, unvan, vardiya | "Ali işleme bölümünde, gündüz vardiyası" |
| `pdks` | personel, tarih, giriş, çıkış, kaynak | "Ali bugün 08:10'da geldi, 17:45'te çıktı" |
| `firma` | ad, tür (müşteri/tedarikçi), iletişim | mevcut firma listesi |

Yeni ihtiyaç çıktıkça (izin, stok, sevkiyat, bakım...) yeni bir `kind` ve alan şeması eklenir, kod yapısı değişmez. Şemalar `internal/memory/kinds/` altında tanımlanır.

Kritik kurallar:
1. **Hesaplamalar kodda yapılır, LLM yapmaz.** PDKS çalışma saati, geç kalma, fazla mesai, devamsızlık toplamları, proje ilerleme yüzdesi, geciken görev sayısı sunucuda sorguyla/aggregation ile hesaplanır. Model sadece sonucu sözle anlatır.
2. **Rapor ve liste sunucuda üretilir** (firma listesindeki gibi). "Bu ay kim kaç gün geç kaldı", "gecikmiş görevler", "B-12 durumu" soruları hazır sorgulara bağlanır, eksiksiz ve sayılı döner.
3. **Tür bazlı görünürlük.** Her `kind` için kimin göreceği tanımlanır. `pdks` ve `personel` kayıtlarını sadece patron ve ilgili kişinin kendisi görebilir. `proje`, `gorev`, `firma` ekip içinde paylaşılır. Sistem, görme yetkisi olmayan birinin sorusuna cevap verirken bu kayıtları prompt'a hiç koymaz (cevap sadece prompt'taki bilgiye göre üretildiği için yetki filtresi aramadan ÖNCE uygulanır).
4. **Kişisel veri (KVKK).** PDKS ve personel bilgileri kişisel veridir. Erişimler `audit`'e yazılır, dışa aktarma sadece patrona açıktır.
5. **Giriş kaynağı:** elle/doğal dille girilebilir, ayrıca kart okuyucu veya turnike cihazından alınan CSV/Excel dışa aktarımı toplu içe aktarılır (import). İçe aktarma kayıt tekrarını (aynı personel + aynı saat) engeller.
6. Eylem gerektiren işler (hatırlatma, geciken göreve uyarı, haftalık özet) ayrı bir zamanlayıcı fazında eklenir.

## Fazlar
1. Özellik bayrakları: şirket ve tool sistemini deaktif et, UI'dan gizle.
2. `claims` + `audit` koleksiyonları, repository, indeksler (`kind`, `key`, `status`, `authorId`, vektör).
3. Yazma servisi (niyet, bölme, batch embedding, çakışma).
4. Okuma servisi (soru/liste ayrımı, sunucu tarafı liste).
5. Silme/değiştirme endpoint'leri + audit.
6. Patron rolü, çelişki netleştirme, `gecersiz` işaretleme, toplu giriş özeti.
7. Test: 140 firma ekle, listele, sayı tutuyor mu; iki kullanıcıdan çelişkili bilgi; silme ve audit.
8. Tipli kayıt altyapısı: `kind` şemaları, alan çıkarma, tür bazlı görünürlük (yetki filtresi aramadan önce).
9. Proje + görev modülü ve hazır raporlar (gecikmiş görev, proje durumu).
10. Personel + PDKS modülü: doğal dil girişi, CSV içe aktarma, sunucu tarafı hesaplamalar (çalışma saati, geç kalma, fazla mesai).
11. Zamanlayıcı: hatırlatma, haftalık özet, geciken iş uyarısı.