kolaytercih/docs/gece-vardiyasi/2026-09-22/35-guvenlik-g3-denetimi.md

35 — Güvenlik & uyum denetimi: G3 · odeme/paket-vaadi (merge öncesi zorunlu denetim)

Rol: guvenlik-uyum · Gece vardiyası, 22 Eylül 2026 sabah turu Denetlenen: dal odeme/paket-vaadi, commit'ler 4acfd27 + 43b6cec, taban 9bd448b (main) Kaynaklar: 34-yazilimci-g3.md, 31-guvenlik-satici-kimligi.md §2, 28-cto-sartname.md §G3 Yöntem: yalnız okuma. Kod değiştirilmedi, dal değiştirilmedi, commit/git add yok, yıkıcı git komutu yok. Diff git show/git diff ile okundu. Proje DB'sine yalnız sqlite3 -readonly ile bakıldı. İşaret: [D] doğrulandı (komut çıktısı / dosya:satır) · [Ç] koddan çıkarım (koşturulmadı)

---

Özet (5 madde)

1. Kritik bulgu yok; üç koşulun üçü de kodda karşılanmış. İade dalları yerinde ve tutar koşullu (rapor-actions.ts:223-228, :358-363 → delta: maliyet), dönen bakiye koşullu (:254, :382), hasPaket tek yerden — getCurrentUser()'ın istek başına React-cache'lenmiş tek satır okumasından geliyor, yeni DB sorgusu eklenmemiş [D].
2. Denetimin en kritik sorusu — amount: 0 idempotency çapasını kaybettirir mi — CEVAP: HAYIR, ve bu artık [Ç] değil [D]. Projenin kendi sürücüsüyle (@libsql/client@0.17.4) izole bir scratch DB'de koşturdum: bakiyesi 0 olan kullanıcıda UPDATE … credit_balance - 0 … WHERE credit_balance >= 0 → rowsAffected = 1 (hiçbir kolon değeri değişmese bile 1; SQLite MySQL gibi "changed rows" saymıyor). delta = -0 satırı tabloya integer 0 olarak yazılıyor ve aynı (reason, ref_id) ile ikinci insert SQLITE_CONSTRAINT: UNIQUE constraint failed ile reddediliyor. Yani satır gerçekten yazılıyor, UNIQUE çapası duruyor, INSUFFICIENT yanlış alarmı yok.
3. Sızıntı yolu kapalı, paketsiz davranış bit-bit aynı. Paketlinin başarısız üretimi/revizyonu delta 0 refund satırı yazıyor, bakiye artmıyor; taze requestId ile sınırsız tekrar da kredi üretmiyor. Paketsizde maliyet = RAPOR_KREDI olduğu için harcama, iade, hata metni ve krediBittiIsaretle yolu değişmemiş [D].
4. Yeni ve gerçek olan tek risk kredi değil, maliyet: G3'ten sonra paketli kullanıcının liste üretiminde hiçbir üst sınır kalmıyor (eski tavan 60 kredi ÷ 3 ≈ 20 üretimdi). Üstelik listeOlusturKilitli reports'u revisionCount: 0 ile üzerine yazdığı için (rapor-actions.ts:247) MAX_REVIZYON=2 tavanı da "yeniden üret → 2 revizyon → yeniden üret" döngüsüyle sıfırlanabiliyor. Repoda hiçbir rate limit yok (grep -rln "rateLimit\|rate-limit\|ratelimit" src/ → 0 dosya [D]); tek fren kullanıcı başına üretim kilidinin serileştirmesi. Merge engeli değil (ücretli kullanıcı yüzeyi, CEO kararının doğal sonucu) ama kayda geçmeli — F1.
5. Uyum tarafında G3 bir açığı kapatıyor: /paket "60 Yapay Zeka danışman sorusu" diyordu (paket-satinal.tsx:39-40), gerçekte liste (3) + 2 revizyon (6) düşünce elde 51 soru kalıyordu. G3 sonrası 60 gerçekten 60. Mesafeli Sözleşmeler Yön. m.5/1-a (hizmetin temel nitelikleri) bakımından "ön bilgilendirme × fiilî ifa" uyumsuzluğu kapanıyor — G3 uyumu bozmuyor, iyileştiriyor. (Hukuki değerlendirme taslaktır: avukat teyidi gerekir.)

---

1 · Üç koşul: doğrulama

Koşul (31-… §2)	Hüküm	Kanıt
1. İade dalları yerinde + tutar koşullu	KARŞILANDI	rapor-actions.ts:223-228 ve :358-363: grantCredits({ … delta: maliyet, reason: "refund", refId }) — çağrı kaldırılmamış, refId aynı. DUPLICATE dalındaki "önceki deneme iade edilmişti" sorgusu (:179-186, :320-327) yalnız (reason='refund', ref_id) bakıyor, delta'ya bakmıyor → delta 0 satırı bu çıkarımı aynen besliyor [D]
2. Dönen bakiye koşullu	KARŞILANDI	:254 ve :382 → kredi: user.creditBalance - maliyet. grep -c "creditBalance - RAPOR_KREDI" = 0 [D]
3. hasPaket tek yerden, yeni DB okuması yok	KARŞILANDI	:158 ve :300 → const maliyet = user.hasPaket ? 0 : RAPOR_KREDI;. user nesnesi getCurrentUser()'dan geliyor: session.ts:27-35 tek SELECT *, react/cache ile istek başına bir kez. hasPaket ile creditBalance aynı satır anlık görüntüsünden okunuyor → harcama ile iade arasında yırtık okuma imkânsız. Diff'te yeni appDb.select/query yok [D]

Ek doğrulamalar:

• hasPaket şemada integer("has_paket", { mode: "boolean" }) (appdb/schema.ts:20) → drizzle gerçek boolean döndürüyor; yazılımcının === true yazmaması doğru tercih, SQLite 0/1 temsilinde de truthiness doğru çalışır [D].
• Kapsam: her iki commit toplam 3 dosya, credits.ts/liste-uretici.tsx/huni-semasi.tsx yok; çalışma ağacındaki başkalarına ait M/?? dosyalar hâlâ commit'siz duruyor [D].

---

2 · spendCredits(amount: 0) / grantCredits(delta: 0) — koşturulmuş hüküm

Şartname de yazılımcı raporu da bu noktayı [Ç] bırakmıştı. İzole scratch DB'de (proje DB'sine yazılmadı), projenin kendi sürücüsüyle koşturdum:

A) amount=0, balance=0  -> rowsAffected = 1     → INSUFFICIENT DÖNMEZ
B) hiçbir kolon değeri değişmiyor -> rowsAffected = 1   → SQLite matched-rows sayar
C) delta=-0 insert rowsAffected = 1
D) yazılan delta = {"delta":0,"t":"integer"}    → -0 değil, temiz integer 0
E) aynı (reason, ref_id) ile ikinci insert: SQLITE_CONSTRAINT: UNIQUE constraint failed
   (code SQLITE_CONSTRAINT, rawCode 2067)       → idempotency ÇAPASI YERİNDE
F) refund delta=0 sonrası bakiye = 0            → kredi üretilmiyor
G) balance=-1, amount=0 -> rowsAffected = 0     → yalnız negatif bakiyede INSUFFICIENT

Hüküm:

• Soru 2 (idempotency): bozulmadı. delta = 0 satırı gerçekten yazılıyor; uniqueIndex("ledger_reason_ref").on(reason, refId) (schema.ts:133) aynı requestId ile ikinci üretimi DUPLICATE'e düşürmeye devam ediyor. uniqueIhlaliMi bu hatayı yakalıyor (mesaj "UNIQUE" içeriyor, credits.ts:22-40) [D]. refId zinciri değişmedi (refId: requestId × 4, satır 165/227/306/362).
• Soru 4 (INSUFFICIENT): bakiyesi 0 olan paketli kullanıcı liste üretebiliyor. Paketin vaadi ayakta. Tek istisna satır G: bakiye negatifse INSUFFICIENT dönerdi — ama negatif bakiye ulaşılamaz: bakiyeyi yazan her yol gte ile korunuyor (credits.ts:69, :110), grantCredits yalnız ekliyor, dev paneli Math.max(0, …) uyguluyor (lib/dev/actions.ts:83, zaten NODE_ENV === "production"'da fırlatıyor) [D]. Lokal DB'de de min bakiye 5 ve 34 (sqlite3 -readonly data/app.db) [D].

---

3 · Bulgu tablosu

#	Dosya:satır	Sorun	Somut senaryo	Önem	Düzeltme	Kesinlik
F1	rapor-actions.ts:158 + :247 (revisionCount: 0 upsert); rate limit yok	Paketlide liste üretiminin kredi freni kalktı, yerine hiçbir sınır konmadı	299 TL ödemiş kullanıcı (ya da hesabı ele geçiren biri) /listem'de sihirbaz tercihini değiştirip "Listemi güncelle"ye basar; her basış tam bir rapor LLM çağrısı, bedeli 0 kredi. Üretim kilidi yalnız serileştirir, saymaz; bayat kilit eşiği 180 sn (uretim-kilidi.ts:13). Ayrıca her yeniden üretim revisionCount'u 0'a çekiyor → "2 revizyon hakkı" tavanı da döngüyle sıfırlanıyor. Eski tavan 60÷3 ≈ 20 üretimdi; şimdi tavan yok	orta	Bu dalda değil (kapsam dışı). Ayrı iş: report_generate ledger satırları zaten sayıyor → spendCredits'ten önce "son 24 saatte reason='report_generate' satır sayısı ≥ N ise code: "SINIR"" kapısı (N'i CEO belirler; 10 tartışma başlatır, 30 kimseyi rahatsız etmez). Alternatif ucuz fren: üretim kilidini başarıdan sonra 60 sn tutmak	DOĞRULANDI
F2	credits.ts:174-176 (krediBittiAt: null) ↔ rapor-actions.ts:223-228	delta = 0 iade de "kredi geldi" sayılıp bekleyen kredi-bitti hatırlatmasını iptal ediyor	Paketli kullanıcının 60 kredisi sohbette biter → /api/soru krediBittiIsaretle yazar (route.ts:180), 48 saat sonra top-up e-postası kuyruğa girer. Kullanıcı o arada bir liste üretir, üretim hata verir → grantCredits(delta: 0, reason:"refund") krediBittiAt'ı null'lar. Kredi gelmediği hâlde hatırlatma iptal olur; krediHatirlatmaGonderildiAt da hâlâ null olduğu için e-posta ancak kullanıcı bir kez daha sohbette duvara toslarsa yeniden kurulur. G3 öncesi bu doğruydu (iade gerçekten 3 kredi getiriyordu), G3 sonrası yanlış	düşük (gelir kaybı, güvenlik değil)	credits.ts:174 → ...(opts.delta > 0 ? { krediBittiAt: null } : {}). credits.ts bu dalın kapsamı dışında (CTO yasak listesi) → backlog	DOĞRULANDI
F3	tercih-degisti-modali.tsx:254 + :336-347 (KrediYetersiz)	Paketli için ölü dal; render edilirse "Güncelleme 0 kredi ve bakiyen yetmedi" yazar	durum = "kredi-yetersiz" yalnız code === "KREDI" | "PAKET" ile kuruluyor (:115). Paketlide KREDI artık imkânsız (bkz. §2), PAKET'i listeOlustur hiç döndürmüyor (yalnız listeRevize döndürür) → dal bugün ulaşılamaz. Ama ucretsiz bayrağı bu dala bağlanmadığı için, ileride bakiye negatife düşebilen bir yol açılırsa ekranda anlamsız cümle çıkar	düşük	Bu dalda şart değil. İstenirse tek satır: :254'teki üçlüye !ucretsiz && eklemek ya da KrediYetersiz içinde raporKredi === 0 dalını yazmak. Aynı sınıf ölü kod liste-uretici.tsx:263-285'te de var (backlog #B2, Bilal'in dosyası)	DOĞRULANDI
F4	rapor-actions.ts:104 (getCurrentUser) → :158	hasPaket okuması ile harcama arasında paket satın alma yarışı	Kullanıcı /listem'de üretimi başlatır; tam o saniyede ikinci sekmede iyzico callback'i paketi yazar. Sunucu eski anlık görüntüyü gördüğü için 3 kredi düşer — paketli olmasına rağmen. Ters yön (paketliyken ücrete düşme) imkânsız, hasPaket true→false dönmüyor	düşük	Düzeltme önermiyorum: pencere milisaniyeler, zarar 3 kredi, G3 öncesinde de aynıydı (o zaman her paketliden düşüyordu). Kayda geçsin yeter	OLASI
F5	credit_ledger (veri, kod değil)	Ölçüm serisi kırılması	report_generate satırının delta'sı paketlide −3 → 0 oldu. Satır sayısına dayanan sorgular (ör. 04-uretim-engelleri.md §5'teki deneme/iade kırılımı) etkilenmiyor; SUM(delta) ile "kaç kredi yandı/iade edildi" soran gelecekteki bir sorgu 22 Eylül'den öncesi ve sonrası için farklı şey ölçer	bilgi	Merge commit mesajında ya da docs/odeme/iyzico.md kenar notunda tek cümle	DOĞRULANDI
F6	süreç — çalışma ağacı	HEAD şu an odeme/paket-vaadi üzerinde; orkestratör beni "funnel/sonuc-ilk-ekran dalındasın" diye bilgilendirdi	G1 dalına devam eden bir sonraki ajan kendini G3 dalında sanmadan commit atarsa G1 işi G3'ün üstüne biner ve merge sırası bozulur. git reflog: HEAD@{2}: checkout: moving from funnel/sonuc-ilk-ekran to odeme/paket-vaadi — yazılımcı dönmemiş. (Aynı reflog'da HEAD@{5}: reset: moving to HEAD~1 G1 dalında, G3 dalında yıkıcı komut yok — yazılımcının bu iddiası doğru)	orta (süreç)	Bir sonraki kod ajanı işe başlamadan orkestratör dalı açıkça söylesin/doğrulasın. Ben dal değiştirmedim (kurallar gereği)	DOĞRULANDI

Sızıntı yolları — tek tek (denetim sorusu 3)

Yol	Sonuç
Paketli, başarısız üretim	refund satırı delta 0 → bakiye değişmez. Kredi eklenmiyor [D: kod + scratch DB]
Paketli, başarısız revizyon, N kez tekrar	Her denemede taze requestId → her denemede yeni (report_revision, id) + (refund, id) çifti, hepsi 0. Sınırsız tekrar sınırsız kredi üretmiyor. revisionCount yalnız başarıda artıyor (:374-380) — bu da yalnız LLM maliyeti bırakıyor (F1)
Paketli, bakiyesi 0, liste üretimi	Çalışır (INSUFFICIENT dönmez) — paketin vaadi ayakta
Paketsiz	maliyet = 3: harcama, KREDI hatası + krediBittiIsaretle, iade, dönen bakiye, modal metinleri — hiçbiri değişmedi. Diff'te paketsiz yolu etkileyen tek satır yok [D]
Başkasının kredisiyle LLM	G3 yeni bir yetkilendirme deliği açmıyor: listeOlustur/listeRevize oturumu doğruluyor, refId tahmini başkasının raporunu okutmuyor (DUPLICATE dalı kullanicininRaporu(user.id) ile kendi raporuna bakıyor). Maliyet riski yalnız kullanıcının kendi hesabında ve F1'de anlatıldığı gibi

---

4 · Muhasebe / mutabakat (denetim sorusu 5)

Bu gece verdiğim "bozmaz" hükmü kod yazıldıktan sonra hâlâ geçerli [D]:

• Bakiyenin tek kaynağı user.credit_balance kolonu; defteri toplayan hiçbir okuyucu yok (grep -rn "creditLedger\|credit_ledger" src scripts → tüm okumalar findFirst/select id, SUM yok).
• iyzico mutabakat sorgusu yalnız l.reason IN ('purchase','topup') AND l.ref_id = o.id (docs/odeme/iyzico.md:84). report_generate/report_revision/refund satırlarının ref_id'si istemcinin ürettiği requestId, orders.id değil → bu sorguya hiç girmiyor. 0 TL'lik hareket iyzico tarafında görünmüyor.
• krediKaydiVarMi de reason'ı şart koşuyor (credits.ts:205-211) → delta 0 refund satırı bir siparişi "kredisi yazılmış" göstermiyor.
• Tek kenar etkisi F2 (kredi-bitti işaretinin silinmesi) ve F5 (ölçüm serisi).

---

5 · Arayüz ↔ kod uyumu (denetim sorusu 6)

Yüzey	Gösterilen	Sunucuda olan	Uyum
Modal açıklaması (tercih-degisti-modali.tsx:193-197, paketli)	"…yeni liste bunun yerine geçer; güncelleme paketine dâhil, kredi düşmez."	maliyet = 0, bakiye sabit	✔ birebir
Modal buton (:290-292, paketli)	"Listemi güncelle" (bedelsiz), ok ikonu metnin sonunda	0 kredi	✔ (AGENTS.md CTA deseni korunmuş)
Modal bakiye satırı (:263-267)	!ucretsiz && !krediYeter → paketliye hiç çıkmaz	—	✔
Modal, paketsiz (:198-202, :292, :265)	"…3 kredi düşer", "Listemi güncelle — 3 kredi", "Güncelleme 3 kredi; bakiyen N kredi"	3 kredi düşer	✔ değişmedi
listem-icerik.tsx:167-172	raporKredi = user.hasPaket ? 0 : RAPOR_KREDI — modalın tek kredi kaynağı, raporKredi'yi başka tüketen yok (listem-govde.tsx:399 sadece geçiriyor)	aynı ifade sunucuda :158/:300	✔ tek kaynak
Başlıktaki kredi pill'i (user-nav.tsx:69)	creditBalance	paketlide düşmüyor	✔ artık tutarlı (G3 öncesi düşüyordu)
KrediYetersiz (:336-347)	paketliye "Güncelleme 0 kredi ve bakiyen yetmedi" derdi	dal ulaşılamaz	F3 — bugün görünmez
liste-uretici.tsx:274 "Liste üretimi 3 kredi… +30 kredi yükle"	paketli dalı	dal ulaşılamaz	Bilinen ölü kod (backlog #B2), G3'ün değil
paket-satinal.tsx:141-144 "liste 3 kredi"	yalnız girişsiz ziyaretçiye gösteriliyor	paketsiz için doğru	✔

Metin × kod uyumsuzluğu (yasal/pazarlama): G3'ten sonra /paket'teki "60 Yapay Zeka danışman sorusu (her mesaj 1 kredi)" ilk kez doğru. Kalan tek uyumsuzluk kod değil e-posta: kredi-hatirlatma.ts:36 paketliyi de credit_balance < 3 filtresiyle yakalıyor ve eposta.ts:175-190'daki metin "listenin tamamını açmak… için kredi yükleyebilirsin" diyor — paketlinin listesi zaten tam açık. G3 öncesinden var (backlog #B3), G3 onu büyütmüyor ama F2 ile aynı dosyada çözülmeli.

---

6 · HÜKÜM

Merge edilebilir. Üç koşulun üçü de kodda karşılanmış, idempotency çapası (UNIQUE(reason, ref_id)) amount/delta = 0 ile fiilen ayakta (koşturarak doğrulandı), paketliye kredi sızıntısı yok, bakiyesi 0 olan paketli liste üretebiliyor, paketsiz davranış bit-bit aynı, iyzico mutabakatı ve bakiye hesabı etkilenmiyor, arayüz sunucunun yaptığını söylüyor. Bu dalda düzeltilmesi gereken bir satır bulamadım.

Merge'e engel olmayan, ayrı iş olarak kuyruğa girmesi gereken üç şey (yazılımcıya şartname netliğinde):

1. F1 — üretim tavanı (yeni dal, credits.ts + rapor-actions.ts): rapor-actions.ts'te spendCredits çağrısından önce, credit_ledger'da reason = 'report_generate' AND user_id = ? AND created_at > now-24h sayısı ≥ N ise { ok:false, code:"SINIR", error:"Bugünlük liste üretim hakkın doldu; yarın devam edebilirsin." } dön. N değeri CEO'nun; kilit/bayat-kilit mantığına dokunma, revisionCount upsert'ünü (:247) değiştirme.
2. F2 — credits.ts:174: krediBittiAt: null yalnız opts.delta > 0 iken yazılsın (...(opts.delta > 0 ? { krediBittiAt: null } : {})). Aynı commit'te kredi-hatirlatma.ts:36'ya eq(user.hasPaket, false) eklenirse backlog #B3 de kapanır.
3. F6 — süreç: sabah entegrasyonuna geçmeden HEAD'in odeme/paket-vaadi'de durduğu bilinsin; G1'e devam eden ajan dalını açıkça doğrulasın.

---

Bilal'den istenen

1. Yok — G3 denetimden temiz çıktı; merge kararı zaten senin kuyruğunda, bu rapor onun için ek bir soru üretmiyor. (F1'in tavan sayısı CEO'ya sorulacak bir ürün kararı, sana değil.)