# Review — Müşteri portalı ve teklif dikeyi (brainstorming, round 2) — 2026-07-31

> **Review type:** brainstorm-review (re-review)
> **Previous review:** `review-musteri-portali-brainstorm-2026-07-31.md` (REJECTED, 9 bulgu)
> **Upstream document(s) read:** N/A (top-level)
> **Other cross-referenced documents:** `cati-dokumani.md` §14–15, §64–67, §136–154, §191 · `docs/arch/mimari-kararlar.md` AD-14, AD-20, AD-21 · `docs/specs/omurga-spec.md` §3, §3.1, §3.2 · `docs/design/planlama-talebi-brief.md` · kod: `app/Http/Requests/Office/CreateCustomerRequest.php`, `app/Models/Customer.php`, `database/migrations/2026_07_27_000200_create_customer_identity.php` (consents), `2026_08_14_000500_create_training_requests.php`
> **Stage locks in effect:** None

---

## Önceki bulguların kapanış doğrulaması

| # | İddia | Bağımsız doğrulama |
|---|---|---|
| F-1 | K-20: tahsis eğitim bazlı | ✓ Kapandı. K-20 çatı §150–152 ile tutarlı — §151 zaten "sistem karar vermez, insan döngüsü çözer" diyor; kalem bazlı tahsis bunu bozmuyor. G7'ye işlenmiş (`quote_items` tahsis durumu taşır). ⚠ Artık K-25 ile yeni bir kesişim doğdu — aşağıda F-R3 |
| F-2 | Sertifika dili düzeltildi | ✓ **Kapandı, çatı §136–142 ile birebir tutarlı.** `certificate_records` yalnız numara+veriliş+geçerlilik (§138); "üretim" ve "indirme" kaldırıldı; belge tutulmaz/gösterilmez (§140); disclaimer zorunlu; kendi eğitim kaydının ayrılığı (§141) ve yenilemede müşterinin getirdiği belge (§142) doğru işlenmiş. §2 satır 53 "sertifika KAYDI zinciri" ✓ |
| F-3 | KUMS kesişmesi eklendi | ✓ Kapandı. Satır 131 çatı §154'ün üç unsurunu da taşıyor (her değişiklik bayrak üretir · "Devam Ediyor" kilidi · yedekten terfi bunu sık üretir) |
| F-4 | K-21: backend bu tur, ekran sonraki | ✓ Kapandı. Onay kuralı 4 istisnasıyla uyumlu; kapanış adresi hem K-21'de hem §2 satır 56'da hem G4 satır 127'de yazılı |
| F-5 | KVKK eklendi | ✓ Kapandı. Çatı §90 doğru aktarılmış; `consents` tablosu gerçekten mevcut (`2026_07_27_000200:42`, koruma trigger'ıyla) |
| F-6 | K-22: teklif ofiste yaşar | ✓ Kapandı — aşağıda ayrıca değerlendirildi |
| F-7 | Bulgu geçersizdi | ✓ **Kabul — round 1 bulgusu hatalıydı.** `customers.legal_type` kod genelinde mevcut (`CreateCustomerRequest:25` birebir doğrulandı: `Rule::in(['legal_entity','natural_person'])`; model, form, i18n, factory). Dahası karar **omurga-spec §3.1'de zaten yazılıydı**: *"Bağımsız katılımcı ayrı bir aktör değildir… gerçek kişi firma olarak kaydedilir"* (çatı 2. tur #14'e dayanarak). Round 1'de omurga-spec §3.1 ve kod okunmadan bulgu üretildi |
| F-8 | Harita eşitlendi | ✓ Kapandı. §2'nin "Bu planda" sütunu §4 ile satır satır karşılaştırıldı: G5/G7/G8/G9/G11 doğru, G6b satırı eklendi, açık eğitim "kapsam dışı (K-26)", `41`/`50` "sonraki tur (K-21)". Eşleşme zorunluluğu satır 101'de |
| F-9 | K-24: mail durum üretir | ⚠ Karar alındı ama **belgeye tutarlı işlenmedi** — aşağıda F-R1 |

## F-2 ve F-6 özel değerlendirmesi (istenen)

**F-2 — evet, kapandı.** Yukarıda; tek pürüz not düzeyinde bir atıf kayması (aşağıda Notlar).

**F-6 — evet, K-22'nin sınırı kırmızı çizgi 1'i ihlal etmeden yeterince belirli.** Üç gerekçe: (1) omurga-spec §3'ün *"hiçbir tabloyu paylaşmazlar"* cümlesi bağlamında gerçekten kimlik/yetki tablolarını anlatıyor (§3 tablosu kimlik kayıtları üzerinedir); iş verisinin çapraz görünürlüğü sistemde zaten var (eğitmen katılımcıları görür, AD-21 müşteri iş aksiyonlarını teklif ekranında gösterir). Sets'in okuması spec'in bağlamıyla çelişmiyor. (2) G7 satır 155 muafiyet olmadığını açıkça söylüyor ve alan sınırını sayıyor: yalnız kendisi için hazırlanmış teklif, yalnız gönderilmiş sürümler; iç onay + taslak + maliyet kapalı. Brainstorm düzeyi için bu yeterli belirginliktir; policy/RLS yerleşimi açıkça plana adreslenmiş. (3) Brief §6 aynı deseni satışçı talebine tutarlı uygulamış ve RLS değişikliğinin kırmızı çizgi 1'e dokunduğunu, ayrıca gözden geçirileceğini kendisi işaretlemiş.

---

## ⚠️ Findings & Risks (in-scope for this review type)

**F-R1 · K-24 belgeye çelişkili işlenmiş; AD-20 güvenlik sınırı 1 ile de çatışıyor.** G6 (satır 143) hâlâ eski kuralı taşıyor: ⛔ *"Gelen mail hiçbir iş aksiyonunu tetiklemez — yalnız yazışma kaydıdır (K-6)"*. G8 (satır 160) ise K-24'ü: *"thread'e düşmekle kalmaz, teklifi 'müşteriden yanıt var' haline getirir ve satışçıya iş çıkarır"*. Gelen mailin durum üretmesi bir tetiklemedir — iki ⛔ aynı anda doğru olamaz; G6'yı okuyan spec yazarı yanlış kuralı alır. Aynı çatışma **upstream'e** de uzanıyor: AD-20 güvenlik sınırı 1 *"mail cevabı hiçbir iş aksiyonunu otomatik tetiklemez… mail sadece yazışma kaydıdır"* diyor ve K-24 tam da bu cümleye atıfla kendini sınırlıyor — oysa K-24'ün kendisi bu cümlenin dar okumasını (yalnız sözleşmesel aksiyonlar: onay/red) seçiyor. K-24 kararının kendisi tutarlı; işlenişi tutarsız: G6'nın blanket cümlesi güncellenmeli ve AD-20 §1'e "durum/bildirim üretimi iş aksiyonu sayılmaz, sözleşmesel geçiş sayılır" ayrımı revizyon olarak işlenmeli. Karar alınmış, propagasyon eksik.

**F-R2 · "Kayıt zaten var / ✓ hazır" iddiası brief §6 ile çelişiyor.** K-19 *"Kayıt zaten var: `training_requests.opened_by` polimorfiktir"*, G6b *"`training_requests` ✓ ve `TrainingRequestPolicy` ✓ hazır, ekranı yok"*, §1 tablosu *"Eğitim talebi ✓"*. Brief §6 ise aynı tabloyu **taşımaz** ilan ediyor: tek müşteri + tek eğitim varsayımı, `tenant_id` NOT NULL açık (müşterisiz, bölge bazlı) talebi reddediyor, *"tablo bu brief'e göre yeniden kurulacak… talebin sahibi değişiyor"*. İkisi aynı anda doğru olamaz: talep ekranının veri tarafı "hazır" değil, "yarım ve yeniden şekillenecek"tir (brief'in kendi ifadesi). Spec yazarken brainstorm okunursa farklı kapsam, brief okunursa farklı kapsam çıkar — K-19/G6b/§1 satırı brief'in tespitiyle hizalanmalı. (Bağlantılı küçük boşluk: müşterisiz **açık** talebi hangi satışçıların gördüğü — P-37 "atandığı firmaların taleplerini görür" kuralı firmasız talebe cevap vermiyor; brief yalnız "kendi açtığını takip eder" diyor. Spec'te cevaplanacaksa açık soruya yazılmalı.)

**F-R3 · K-25 × K-20 × çatı §151: kontenjan teyidi açıkken faturalanabilirlik kararsız.** K-25 faturayı doğuran olayı **onay** yapıyor; K-20 + çatı §151 ise onaylanmış bir teklifin bir kaleminin "kontenjan teyidi"nde asılı kalabilmesine izin veriyor (onay kaydedilir, tahsis insan döngüsünde çözülür). Belge *"K-20 ile çelişmez: tahsis eğitim bazlı, faturalanabilirlik teklif bazlı"* diyor ama asıl soruyu cevaplamıyor: bir kalemi teyitte bekleyen teklif **bütün olarak** faturalanabilir mi, teyit kapanana kadar bekler mi, teyit olumsuz kapanırsa kesilmiş faturanın yolu nedir (AD-11 iptal/revizyon)? Toplu teklifte (K-14) bu istisna değil olağan durumdur. Spec bu kararı üretmek zorunda kalacak.

**F-R4 · `invoices` ve `correspondence_threads` için sahiplik cümlesi hâlâ yok** *(düşük)*. Round 1 F-6 üç kayıt türünü sayıyordu; K-22 yalnız `quotes`'u kararladı, brief aynı deseni satışçı talebine genelledi. Faturanın ve yazışma thread'inin ofis tarafında yaşayıp müşteriye açıldığı muhtemelen aynı desendir — ama yazılı değil; K-22'nin "aynı desen şunlara da uygulanır" diye bir cümleyle kapsaması yeterli olurdu. Yazılmazsa spec'te yeniden sorulur.

## ❓ Open Questions

1. Müşterisiz (bölge bazlı, açık) talebin satışçı tarafı görünürlüğü (F-R2 içinde — P-37 firmasız talebe cevap vermiyor).

## ⚠️ Upstream Findings

- **AD-20 güvenlik sınırı 1** K-24 ile revizyon gerektiriyor (F-R1'in upstream ayağı): "hiçbir iş aksiyonunu otomatik tetiklemez" cümlesi, K-24'ün "durum üretir + iş çıkarır" kararıyla mevcut haliyle çelişiyor.
- *(Not düzeyi)* omurga-spec §3'ün *"hiçbir tabloyu paylaşmazlar"* cümlesine K-22'nin netleştirmesi (kural kimlik/yetki tablolarınadır, iş verisine değil) işlenirse gelecekteki okuyucu katı okumayı yeniden türetmez.

## Notlar (blocker değil)

- G4 satır 123 disclaimer'ı "(§138)" diye anıyor; disclaimer çatının **§139**'undadır (§138 numara+tarih satırı).
- K-23'ün kaynak sütununa **omurga-spec §3.1** eklenmeli — karar orada zaten yazılıydı (çatı 2. tur #14 dayanaklı); K-23 yeni karar değil, mevcut kararın teyididir ve kaynağı onu göstermeli.
- K-26, çatı §64'ün "tüm firmalara açık" tanımını ticari anlamda koruyor (herhangi bir müşteriye satılabilir), §67'nin duyuru mekanizması mailing olarak duruyor — çatıyla çelişki yok; `16` bloğunun kapsam dışılığı onaylı sapma olarak iki yerde de (brainstorm + brief) kayıtlı ✓. K-28 ve §4b brief ile tutarlı ✓.

## Verdict: ❌ REJECTED (dar kapsamlı — dokuz bulgunun dokuzu da kapandı, üç yeni bulgu propagasyon/etkileşim kaynaklı)

F-2 çatı §136–142 ile tam tutarlı; K-22'nin sınırı kırmızı çizgi 1'i ihlal etmeden yeterince belirli; F-7 reddi haklı ve round 1'in hatasıydı (omurga-spec §3.1 + kod zaten karşılıyordu). Kalan üç şey verdict'i düşürüyor: **F-R1** — K-24 alınmış ama G6'nın ve AD-20 §1'in eski blanket cümleleri düz çelişki olarak duruyor (spec yazarı hangisini okursa onu uygular); **F-R2** — "kayıt hazır" iddiası brief'in "yeniden kurulacak" tespitiyle çelişiyor; **F-R3** — K-25'in "onay = faturalanabilir" kuralı, K-20'nin izin verdiği "teyitte asılı kalem" durumuyla kesişiminde cevapsız. Üçü de metin düzeltmesi + tek karar büyüklüğünde; kapanınca belge spec'e hazırdır.