# Review — Müşteri portalı ve teklif dikeyi (brainstorming v1.1) — 2026-07-31 > **Review type:** brainstorm-review > **Previous review:** N/A (review #166 oturumu düştü, bulgu üretmedi — bu review onun yerine geçer) > **Upstream document(s) read:** N/A (top-level) > **Other cross-referenced documents:** `CLAUDE.md` · `cati-dokumani.md` (özellikle §10, §14, §15, §148–154, §176–191) · `docs/arch/mimari-kararlar.md` (AD-05, AD-14, AD-15, AD-20, AD-23, AD-27) · `docs/specs/fiyatlama-spec.md` · `docs/specs/planlama-spec.md` (§2.3, §7, P-37) · `docs/specs/omurga-spec.md` §3 · `database/migrations/2026_08_14_000500_create_training_requests.php` · `design/` envanteri > **Stage locks in effect:** None --- ## Upstream Coverage Matrix N/A — top-level document. Yerine iç tutarlılık + kaynak doğrulaması yapıldı (aşağıda). --- ## ✅ What works - **Mevcut durum tablosu (§1) gerçekten koddan üretilmiş.** Örneklem doğrulandı: `training_requests.opened_by` migration'da polimorfik (`opened_by_type`/`opened_by_id`, `2026_08_14_000500:50–51`); K-19'un planlama-spec kaynakları birebir tutuyor (`planlama-spec.md:91` satışçının yalnız atandığı firmaların taleplerini görmesi, `:531` `training_request.view`, `:770` P-37). - **S-6 gerilimi (K-14 × K-3) doğru çözülmüş:** toplu teklif planlanmamış eğitimi kapsamaz; K-18 çatı §102/§106 ile, K-19 planlama-spec ile uyumlu. K-13/K-14/K-18 üçlüsü **kendi içinde** çelişmiyor. - K-5/K-6/K-8/K-9/K-10/K-12 kaynak referansları çatı ve AD metinleriyle birebir doğrulandı. - Katılımcı omurgasını kapsama alma kararı (v1.1) bağımlılık kazancıyla (41, 40 boşlukları, hakediş #49) gerekçelendirilmiş; "omurga uydurulmaz, kurulur" ilkesi çatı §143'ün ruhuyla uyumlu. - G4'teki mevzuat kapısı AD-27'nin güncel (27.07.2026 revizyonlu) haliyle uyumlu: limitler eğitim tanımının admin alanı, mevzuat kaydı uyarı. - İkili yoklama (imzalı liste asıl, beyan ikincil) çatı §190 ile birebir. - G6'nın inbound tasarımı AD-20'nin 28.07.2026 revizyonuyla (yazışma kayda bağlanır) uyumlu. ## ⚠️ Findings & Risks (in-scope for this review type) **F-1 · K-14 × K-10 (çatı §150–152) etkileşimi kararsız — çok-eğitimli teklifte tahsis davranışı yok.** Çatı §151'in kurgusu tek-eğitim varsayımlıdır: onay öncesi uyarı metni *"**Bu eğitimde** N yer kalmıştır"*, yetmezlikte tahsis "kontenjan teyidi"ne düşer. K-14 onay birimini eğitimden teklife taşıyor: bir teklif 3 eğitimin kontenjanını aynı anda bekletirken müşteri tek onay veriyor. Eğitimlerden biri dolu, ikisi boşsa onayın ve "önce onaylanan slotu alır" kuralının teklif bütününe mi kalem bazına mı işlediği; "teklif bekleyen" rezervasyonun N eğitim üzerinde ne zaman başlayıp ne zaman düştüğü (K-17'nin gidip gelen revizyon turları boyunca dahil) hiçbir kararda yok. Spec bu kararı üretmek zorunda kalacak — belgenin kendi başarı kriterinin ("spec yazılırken kaybolacak karar kalmasın") tam ihlali. **F-2 · G4 "sertifika üretimi" ve G10 "sertifika listesi ve indirme" çatı §14 ile çelişiyor.** Çatı §136: *"Sertifikayı Bakanlık üretir; 3E sertifika belgesi üretmez, şablonlamaz, saklamaz"*; §140: *"Belgenin kendisi tutulmaz ve gösterilmez"*; bizde yalnız numara + tarihler + zorunlu disclaimer (§138–139). G4'ün "training_completions + sertifika üretimi" ve G10'un "sertifika listesi ve **indirme**" ifadeleri (satır 107, 138; §2 satır 51 "tamamlama → sertifika zinciri" aynı dili taşıyor) bu kararla kaynak uyuşmazlığıdır. **F-3 · Bakanlık bildirimi / KUMS kesişmesi bağımlılık haritasında yok.** Çatı §154: bildirilen katılımcı listesindeki her değişiklik "KUMS güncellemesi gerekli" bayrağı üretir, güncelleme kaydedilmeden eğitim "Devam Ediyor"a geçemez; çatı §143: "tamamlandı" kapısının bir ayağı KUMS işlem kanıtıdır. G4'ün kurduğu `training_enrolments` ve yedekten terfi tam bu değişiklikleri üretecek kayıtlardır; §2 haritası ve G4 bu akışı hiç anmıyor. Gözden kaçan akış — bildirim-sonrası liste değişikliğinin katılımcı omurgasına dokunduğu yer kayıt dışı. **F-4 · Yoklama/beyan verisinin üretici uçları haritada yok.** G10, `15`'in detayında **yoklama sonucu** çizer; yoklamayı işleyen uç `41 Egitmen Saha`dır ve bu planda teslim edilmiyor ("açar" deniyor, teslim edilmiyor). `participant_declarations`'ın giriş ucu katılımcı ekranıdır (`50 Katilimci Paneli.dc.html` mevcut; §1 tablosu katılımcı alanını "kapı var, ekran yok" diye kendisi tespit ediyor) ve hiçbir G onu kapsamıyor. Sets'in v1.1 kararı "müşteri tarafı uçtan uca tamamlanmış olsun, backlog oluşturmayalım" iken tüketici uçlar (G10) kuruluyor, veriyi üretecek uçların bu tura mı sonraki tura mı ait olduğu kararı kayıt dışı. **F-5 · KVKK implikasyonu ele alınmamış.** G4 katılımcı omurgasını (kayıt, beyan, sınav sonucu — kişisel veri) kuruyor; katılımcı onboarding'indeki KVKK aydınlatma + açık rıza zorunluluğu (çatı §90 — rıza kaydı sistemde tutulur) belgede hiç geçmiyor. Brainstorm scope'unda "Audit/KVKK implikasyonları ele alınmış mı?" sorusunun cevabı hayır. **F-6 · `quotes` sahiplik ve görünürlük kararı yok.** Teklif, iki kimlik dünyasını köprüleyen tek kayıt türüdür: satışçı (`users`, tenant'sız) üretir, `customer_users` (tenant-kapsamlı) okur ve onaylar; omurga-spec §3 kimlik alanlarının hiçbir tabloyu paylaşmadığını, §3.2 kimliğin tenant sınırını aşmadığını pazarlıksız kural sayar. Teklifin hangi dünyanın kayıt alanında yaşadığı, müşterinin hangi sürüm ve durumları görebildiği (3E iç onayı `quote_approvals`, henüz gönderilmemiş taslak sürümler, K-17 revizyon turlarının ara halleri) karar düzeyinde boş. RLS policy'nin yazımı planın işidir; ama **kaydın tarafı ve görünürlük sınırı** bir tasarım kararıdır ve bu belge yeni kayıt türlerinin hiçbiri için (customer_units/locations dolaylı olarak açık; quotes/invoices/correspondence için tek kelime yok) tenant kapsam implikasyonunu ele almıyor. Cevap: **eksiklik** — spec'e ertelenmiş değil, hiç konuşulmamış. **F-7 · Bağımsız katılımcı, tenant-kapsamlı kimlik modeline oturmuyor.** K-12 çatı §191'den "fatura bağımsız katılımcıya da kesilebilir"i aktarıyor; ama firması olmayan kişinin `customers` + `customer_users` + `training_participants` (hepsi tenant-kapsamlı) modelinde nasıl temsil edileceği hiçbir kayıt türünde ve akışta yok. G9 (fatura) ve G11 (açık eğitim "kayıt") bunu gerektirir. Kimlik implikasyonu ele alınmamış. **F-8 · §2 haritasının "Bu planda" sütunu eski (v1.0) numaralandırmayla kalmış.** Satır 45–49: `14`→G4, `31`→G5, `13`→G6, `16` Faturalar→G7, içerik→G8; §4'te bunların karşılığı G5, G7, G8, G9, G11. Satır 53 yazışmayı da G6'ya bağlıyor — satır 47 ile aynı G'ye iki farklı iş düşüyor. Bu bir yazım hatası değil iç tutarsızlıktır: kararların adres defteri ekranları yanlış iş kalemine gösteriyor ve spec/plan yazımında yanlış kapsam eşlemesi üretir. **F-9 · K-17 × K-6/G6 gerilimi çözümsüz.** G6: ⛔ *"Gelen mail hiçbir iş aksiyonunu tetiklemez — yalnız yazışma kaydıdır (K-6)"*. K-17/G8: müşteri revizyonu *"panelden ya da maile cevap yazarak"* ister — mail, panel ile eşdeğer bir istek kanalı gibi sunuluyor. Mailden gelen revizyon talebinin sistemde bir durum üretip üretmediği (teklif "revizyon istendi"ye düşer mi, yoksa yalnız thread'e mi düşer ve insan mı taşır) iki karardan hangisinin okunduğuna göre değişiyor. Çelişen iki okuma mümkün; karar kayıtlı değil. ## ❓ Open Questions (to be answered before next stage) 1. **Toplu teklifin faturalama kadansı** (K-14 × K-16/K-12): 6 aya yayılan teklif tek seferde mi, eğitim gerçekleştikçe kısmi mi faturalanır? "Teklifi faturalandır" çok-eğitimli teklifte neyi kapsar? 2. **Açık eğitim duyurusundan kayıt** (G11): panelden yapılan kayıt kontenjan sayacında hangi sınıfa düşer — "teklif bekleyen" mi, "kesinleşen" mi? Teklifsiz kayıt yolu §148'in üç sayısına nasıl oturur? 3. **G6b'nin talep kuyruğu ekranı** `20 Planlamaci Sorgulama` kapsamında mı, ayrı bir tasarım mı gerektiriyor? (`design/` envanterinde talep kuyruğuna ayrılmış dosya yok.) ## ⚠️ Upstream Findings Yok. (F-2 çatıyla çelişkidir ama çatı doğru; düzeltme bu belgededir.) ## Notlar (blocker değil) - K-1'in kaynak sütunundaki "§176" rol listesidir; kararın asıl dayanağı çatı §96–97 ve §182. İkinci referans (§182) kararı zaten taşıdığı için not düzeyinde. ## Verdict: ❌ REJECTED K-13/K-14/K-18 üçlüsü kendi içinde tutarlı ve S-6 çözümü doğrulandı — talep edilen üç sorunun ilkinde asıl boşluk üçlünün kendisinde değil, K-14'ün çatı §150–152 tahsis kurallarıyla kesişiminde (F-1). İkinci soruda iki kaynak çelişkisi/kapsam kaçağı var (F-2 sertifika, F-3 KUMS; F-4 üretici uçlar). Üçüncü soruda `quotes` sahipliği spec'e bilinçli bırakılmış değil, hiç ele alınmamış (F-6) ve bağımsız katılımcı kimlik modeli dışında kalıyor (F-7). Dokuz bulgu da brainstorm scope'unun içindedir (çelişen/eksik karar, kaynak uyuşmazlığı, ele alınmamış izolasyon/KVKK implikasyonu, iç tutarsızlık); bulgular kapanmadan spec yazımı bu kararsızlıkları varsayımla dolduracaktır.