# Müşteri portalı ve teklif dikeyi — brainstorming / karar arşivi

*Belge tipi: **brainstorming** (heyet lifecycle 1. aşama). Kararlar, kapsam sınırı, bağımlılık haritası ve sıralama burada; sistem davranışının tam tanımı **spec**'in, migration/RLS/test/rollout **plan**'ın işidir ve ikisi de henüz yazılmadı.*

*31.07.2026 · v1.1 · Sets kararı: "müşteri tarafını eksiksiz yapalım, teklif dahil" · v1.1'de S-1…S-5 cevaplandı ve **katılımcı omurgası kapsama alındı** (Sets: "backlog oluşturmayalım")*

**Hedef:** müşteri firmanın kendi panelini uçtan uca kullanabilmesi — organizasyonunu kurar, personelini yönetir, teklif ister, teklifi okur ve onaylar, eğitimlerini ve belgelerini görür.

**Neden teklif dikeyi bu plana dahil:** çatı §10 akışı tek yönlü değil. *Satışçı teklifi hazırlar → yönetici onayına düşer → firmaya gider → firma panelden onaylar.* Müşterinin `13 Teklif` ekranı bu zincirin **alıcı ucu**; üreten uç (`31 Satisci Teklif`) olmadan ekranın gösterecek bir şeyi olmaz. "Müşteri tarafı eksiksiz" demek, teklif omurgasını da kurmak demektir.

**Stack:** Laravel 13 · PHP 8.5 · PostgreSQL (RLS) · Inertia + Vue 3 · Pest

---

## 1 · Doğrulanmış mevcut durum

⚠ Bu tablo **koddan okunarak** üretildi, bellekten değil.

| Ne | Durum | Kanıt |
|---|---|---|
| Müşteri kimliği | ✓ `customers`, `customer_users`, `customer_user_sessions`, `customer_auth_settings`, `magic_links` | `2026_07_27_000200_create_customer_identity.php` |
| Giriş akışları (şifre · magic link · davet · şifre sıfırlama) | ✓ | `routes/web.php:37–70` |
| Panel kapısı | ✓ `CustomerPanelController` — panel izni + `RequireStrongAuth`; **JSON stub döndürüyor, ekran yok** | `app/Http/Controllers/CustomerPanelController.php:38` |
| Katılımcı alanı | ✓ kapı var, ekran yok | `ParticipantAreaController` |
| Ofis tarafı müşteri yönetimi | ✓ liste, detay, kişi, portal daveti, satışçı ataması | EGT-62 |
| Fiyat matrisi | ✓ `price_groups`, `price_bands`, `price_lists`, `prices` · kuralları `docs/specs/fiyatlama-spec.md` | migration listesi |
| İndirim tavanı | ✓ `user_discount_limits` | migration listesi |
| Eğitim talebi | ⚠ **yarım** — `training_requests` var ama **tek müşteri + tek eğitim** varsayıyor; `tenant_id` NOT NULL olduğu için müşterisiz (bölge bazlı, açık) talebi **reddediyor**. Görünürlük, çoklu tanım ve davet listesi yok. Talebin **sahibi değişecek** — bkz. `planlama-talebi-brief.md` §6 | `2026_08_14_000500_create_training_requests.php` |
| Katılımcı bağı | ⚠ `training_participants` **çıplak join** — tenant + kişi + eğitim. Kayıt durumu, hangi göreve kayıtlı, yoklama, sınav, tamamlama **yok** | `create_customer_identity.php:313–324` |
| Müşteri organizasyonu (departman/grup) | ❌ yok — `groups` tablosu **ofis** kullanıcı ağacıdır | `2026_08_13_000100_create_group_tree.php` |
| Müşteri lokasyonları | ❌ yok | tablo listesi |
| Müşteri teklifi | ❌ yok — sistemdeki "teklif"ler tedarikçi fiyat teklifi (`supplier_price_quotes`) ve eğitmene giden atama teklifi (`training_instructor_offers`) | tablo listesi |
| Fatura | ❌ yok | tablo listesi |
| Portal ekranları | ❌ hiç yok — `resources/js/pages/` altında yalnız `Office` var | `ls resources/js/pages/` |

---

## 2 · Bağımlılık haritası

| Tasarım | Ne gerektiriyor | Bu planda |
|---|---|---|
| `11` Dashboard | portal kabuğu; "yaklaşan eğitimler" için `training_customers` ✓ | G1 (kısmi — aşağıya bak) |
| Satışçının eğitim planlama talebi | `TrainingRequestPolicy` ✓; `training_requests` ⚠ **yeniden kurulacak** (brief §6), ekranlar geldi (`34`) | G6b |
| `11` Organizasyon & yetkiler | müşteri birim ağacı, birim yöneticisi, iç onay akışı ayarı, yetki matrisi | G2 |
| `12` Personel + lokasyonlar | `customer_users` ✓ + birim ataması + lokasyon tablosu | G2, G3 |
| `14` Teklif isteği | `training_requests` ✓ + katılımcı grupları + iç onay kuyruğu | G5 |
| `31` Satışçı teklifi | teklif omurgası (yeni), fiyat matrisi ✓, indirim tavanı ✓ | G7 |
| `13` Teklif görüntüleme & onay | teklif omurgası + sürüm/hash delili (AD-14) | G8 |
| `16` Faturalar | fatura omurgası (yeni), provider-bağımsız (çatı §191) | G9 |
| `16` İçerik paketleri | belge motoru ✓ | G11 |
| `16` Açık eğitim duyuruları | — | ⛔ **kapsam dışı** (K-26) — ✅ tasarımcı 31.07.2026'da bloğu **kaldırdı** |
| `15` Eğitimlerim (detayda **yoklama sonucu**) | katılımcı–oturum–yoklama–tamamlama omurgası | G4 kurar, G10 çizer |
| `16` Sertifikalar | tamamlama → **sertifika KAYDI** zinciri (numara + veriliş + geçerlilik) | G4 kurar, G10 çizer |
| `11`'in "%65 uyum" ve "süresi yaklaşan personel" kartları | aynı zincir — kişinin sertifika bitiş tarihi | G1'de **boş durum**, G4'ten sonra dolar |
| Teklif ve fatura yazışması | AD-20 inbound omurgası ❌ | G6 |
| `41` eğitim günü · `50` katılımcı beyanı | G4'ün kurduğu kaydın **üretici uçları** | ⛔ **sonraki tur** (K-21) |

⛔ **v1.0'ın sınırı kaldırıldı** *(Sets, 31.07.2026: "katılımcı yapısını da bu tura al, müşteri tarafı uçtan uca tamamlanmış olsun, backlog oluşturmayalım")*. v1.0 `15` ve `16`'yı dışarıda bırakıyordu çünkü uydurulmuş bir yoklama sonucu müşteriye gösterilen yanlış bir uyum oranı demektir. Karar: omurga **uydurulmaz, kurulur** — G4 olarak bu plana girer.

⚠ **Yan kazanç, ve küçük değil:** aynı omurga `41 Egitmen Saha`yı (eğitim günü, oturum yoklaması, sınav), `40`'ta bıraktığım iki boşluğu (oturum sayısı, gerçek katılımcı sayısı) ve **hakedişi** (#49, "zincire bağlı" diye bekliyor — hakediş tamamlamadan doğar) birden açar. Katılımcı omurgası bu projenin en çok kapı açan tek parçasıdır.

---

## 3 · Kararlar (kaynak referanslı)

| # | Karar | Kaynak |
|---|---|---|
| K-1 | Müşteri kendi departman/grup yapısını kurar, gruplara yönetici atar | çatı §176, §182 |
| K-2 | Teklif isteğinde iç onay **müşterinin kendi belirlediği opsiyonel akış**; kapalıysa istek tek tıkla 3E'ye gider | çatı §98, §182 |
| K-3 | Planlamacının oluşturmadığı eğitim için satışçı işlem yapamaz — teklif **planlanmış eğitim üzerinden** kesilir | çatı §10.1 |
| K-4 | Teklif satışçıdan çıkar → 3E yöneticisinin onayına düşer → firmaya gider | çatı §10.4 |
| K-5 | Müşteri onayı **yalnız panelden**; onay anında metin sürümü + hash + zaman damgası + kullanıcı kaydedilir | AD-14, çatı §186 |
| K-6 | Maildeki "onaylıyorum" teklif onayı **değildir** | AD-20 |
| K-7 | Fiyat sürenin fonksiyonudur (bant × müşteri grubu); günlük ve kişi başı **iki ayrı liste** | `fiyatlama-spec.md` §1, §2.1 |
| K-8 | Satışçı maliyeti **görür, değiştiremez**; yalnız indirim tanımlar. Revizyon planlamacınındır | çatı §187 (Sets, 28.07.2026) |
| K-9 | Kontenjan göstergesi üç sayı: kesinleşen · teklif bekleyen · toplam. Satışçı **hangi satışçının teklifi olduğunu görmez** | çatı §148 |
| K-10 | Kimin teklifi önce onaylanırsa slot onundur; kontenjan dolunca yedek liste, otomatik terfi yok | çatı §150, §152 |
| K-11 | Müşteri silinmez, pasifleştirilir; kişisel alanlar tenant anahtarıyla şifreli, arama HMAC üzerinden | AD-05, AD-23 |
| K-12 | Fatura provider-bağımsız; hem serbest kalemle hem "teklifi faturalandır" ile kesilir, bağımsız katılımcıya da firmaya da | çatı §191 |
| **K-13** | **Bir teklifte iki fiyat tipi KARIŞABİLİR.** Teklif kalem kalem kurulur: kişi başı katılımcı fiyatı ayrı kalem, günlük fiyat ayrı kalem. Her kalem hangi listeden beslendiğini kendi taşır | Sets, 31.07.2026 (S-1) |
| **K-14** | **Teklif toplu olabilir** — müşteri önümüzdeki 6 ayın eğitimleri için tek teklif isteyebilir. Yani bir teklif **N eğitime** yayılır; "bir eğitim = bir teklif" varsayımı yanlıştır | Sets, 31.07.2026 (S-1) |
| **K-15** | Müşterinin iç onay akışı **tek yöneticidir**. Kademe zinciri yok — açık/kapalı ve bir onaylayan | Sets, 31.07.2026 (S-3) |
| **K-16** | Fatura bu turda **kayıt + PDF**. Üstüne **"muhasebeye bildir" / "bildirildi"** durumu: fatura sayfasından mail gider, muhasebe adresi backoffice'ten tanımlanır, **cevap aynı yere düşer** (Postmark inbound, AD-20). Kim, ne zaman, hangi kanaldan bildirmiş — kayıtlı | Sets, 31.07.2026 (S-4) |
| **K-17** | **Teklif revizyonu vardır ve gidip gelen bir süreçtir.** Müşteri revizyon isteyebilir (panelden ya da maile cevap yazarak); satışçı revize teklifi gönderir; her tur sürüm üretir ve hepsi kayıtlıdır | Sets, 31.07.2026 (S-5) |
| **K-18** | **Satışçı ASLA eğitim oluşturamaz.** Teklif hazırlarken bir eğitimi görebilmesi için planlamacının onu planlamış olması gerekir. Toplu teklif de bunu bozmaz: müşteri toplu ister → planlamacı planlar → satışçı planlanmış N eğitimi tek teklifte toplar | Sets, 31.07.2026 (S-6), çatı §10.1 |
| **K-20** | **Kontenjan tahsisi EĞİTİM BAZLIDIR.** Çok eğitimli teklifte onay tektir ama tahsis kalem kalem işler: bir eğitim dolmuşsa o kalem tutmaz, diğerleri tutar. Çatı §150–152'nin *"kimin teklifi önce onaylanırsa slot onundur"* kuralı **eğitim düzeyinde** okunur, teklif düzeyinde değil | Sets, 31.07.2026 (F-1) |
| **K-21** | **Üretici uçların backend'i bu turda, ekranı sonraki turda.** `41` (eğitim günü) ve `50` (katılımcı beyanı) yazılmaz; G4 onların dayandığı kaydı kurar. Backbone'un caller'ı henüz yoktur ve bu bulgu değildir (onay kuralı 4 istisnası) — kapanış adresi: `41` ve `50` bir sonraki tur | Sets, 31.07.2026 (F-4) |
| **K-22** | **Teklif OFİS tarafında yaşar, müşteriye AÇILIR.** Satışçı teklifi müşteri için hazırlar; müşteri okur, cevaplar, onaylar. ⛔ *"İki kimlik dünyası hiçbir tabloyu paylaşmaz"* kuralı **kimlik tablolarınadır** (omurga-spec §3), iş verisine değil — eğitmen müşterinin katılımcılarını görür, müşteri satışçının teklifini görür. Ortak yüzey **kaçınılmazdır**; doğru cevap ayırmak değil, **kapsam kontrolü + izolasyonla** kurmaktır | Sets, 31.07.2026 (F-6) |
| **K-22b** | **Aynı desen `invoices` ve `correspondence_threads` için de geçerlidir** *(heyet 168 F-R4)*: kayıt ofis tarafında yaşar, müşteriye kendi kaydı kadar açılır. Fatura 3E'nin kestiği belgedir; yazışma AD-20 gereği bir **kayda** bağlıdır ve o kaydın tarafını izler. Satışçının planlama talebi de aynı desendedir (brief §6) | K-22'nin genellemesi, 31.07.2026 |
| **K-23** | **Bağımsız katılımcı ayrı bir model gerektirmez** — müşteri olarak eklenir. Türk mevzuatında taraf **tüzel kişi** ya da **gerçek kişi** olabilir; `customers.legal_type` bunu zaten taşıyor (`legal_entity` / `natural_person`, `CreateCustomerRequest:25`'te doğrulanıyor). Tek başına kişi de müşteridir, teklifi ona da veririz. ⚠ **Yeni karar değil, mevcut kararın teyidi** — omurga-spec §3.1 bunu zaten yazmış: *"Bağımsız katılımcı ayrı bir aktör değildir… gerçek kişi firma olarak kaydedilir"* | omurga-spec §3.1, çatı 2. tur #14 · Sets, 31.07.2026 (F-7) |
| **K-24** | **Maille gelen cevap GÖRÜNÜR olur ve bildirim üretir** — kaydın durumunu değiştirmez. Yazışma thread'ine düşer, satır üstünde *"son hamle"* olarak okunur, sahibine bildirim gider; **aksiyonu satışçı alır**. ⛔ Sistem cevaba bakıp teklifi ilerletmez: onay, ret, revizyona geçiş — hiçbiri mailden doğmaz (AD-20 §1 **olduğu gibi geçerli**, revizyon gerekmiyor — Sets, 31.07.2026). Cevabın türü satışçının ne yapacağını belirler; kabul geldiyse işi müşteriyi panele yönlendirmektir | Sets, 31.07.2026 (F-9, F-R1) |
| **K-26** | **"Açık eğitim" SATIŞÇILARA görünürlüktür, müşterilere değil.** Açık = tüm satışçılara görünür, herhangi bir müşteriye satılabilir; kapalı = belirli firmaya özel. ⛔ Müşterinin önüne bizim plan/eğitim listemiz **asla düşmez**; panelden kendi kendine kayıt yoktur, tanıtım en fazla mailing'dir. Açık eğitim de teklif → onay → fatura zincirinden geçer | Sets, 31.07.2026 |
| **K-28** | **Bekleyen işte SON HAMLE görünür**, yalnız süre değil: kim, ne zaman, ne dedi. Hem talep kuyruğunda hem teklifte. Gerekçe: dokuz gündür bekleyen bir kayıt, topu bizde olan da olabilir karşı taraftan haber beklenen de — ikisi aynı görünürse yanlış olan kovalanır. Satırdan **hatırlatma görevi** açılabilmeli | Sets, 31.07.2026 |
| **K-27** | **Satışçının talep ekranı ve talep kuyruğu tasarlanacak** — talep çoğul eğitim, il, tarih aralığı, açık/kapalı ve (kapalıysa) davet edilecek firmaları taşır; planlamacı *"bunu plana çevir"* deyince `24` bu bilgilerle dolu açılır. Brief: `docs/design/planlama-talebi-brief.md` | Sets, 31.07.2026 |
| **K-25** | **Fatura, teklif ONAYLANDIĞINDA kesilebilir hale gelir.** "Eğitim gerçekleştikçe kısmi faturalama" diye bir şey yoktur — toplu teklifte de kadans budur. Gerekçe Sets'in kendi cümlesi: *"teklifin amacı zaten bir ödeme taahhüdünü kesinleştirmek."* Yani faturayı doğuran olay **onaydır**, eğitimin gerçekleşmesi değil | Sets, 31.07.2026 |
| **K-29** | **Teklif BÜTÜN olarak faturalanır**; bir kalemi kontenjan teyidinde asılı olsa da beklenmez. ⛔ Buna karşılık **fatura iptali ve revize fatura** zorunlu yetenektir: teklif onaylanır, fatura kesilir, müşteri bir şey değiştirir → teklif revize edilir, fatura **iptal edilir**, yeni fatura kesilir. Sets'in ifadesi: *"saha gerçekleri."* ⚠ İptal, silme değildir (AD-11, kırmızı çizgi 12) — iptal bir statü ve gerekçedir, yeni fatura öncekiyle bağını taşır | Sets, 31.07.2026 (F-R3) |
| **K-30** | **Talep/programın SATIŞÇI görünürlüğü kapsamlıdır**, ikili değil: *"tüm satışçılar görsün"* ya da *"şu grup / seçili satışçılar görsün"*. Gerekçe: yalnız İzmit grubunu ilgilendiren bir program diğer satışçıları meşgul etmemeli. ⚠ Grup, ofis kullanıcı ağacıdır (`groups` ✓) — yeni kapsam kavramı icat edilmez, AD-23'ün üstüne oturur. ✅ Tasarıma işlendi (`34` revizesi, 31.07.2026) | Sets, 31.07.2026 (F-R2 açık sorusu) |
| **K-31** | **Satışçı ataması değişirse iş yeni satışçıya geçer.** Yeni satışçı görmeye başlar, **eskisi göremez**. ⚠ Eskisinin yaptıklarına dair **loglar durur** ve yeni satışçı onları görebilir — devralan kişinin geçmişi okuyabilmesi işin devri demektir | Sets, 31.07.2026 |
| **K-32** | **Hesap kapatılırsa** üzerine atanmış işler **devredilir ya da havuza aktarılır** (satışçı ataması silinir). **Pasifleştirilirse** hiçbir şey yapılmaz: iş atanmış kalır. ⚠ Pasifleştirme anında *"üzerine atanmış şu işler var"* **uyarısı verilir**; yine de yapılıyorsa bilerek yapılmıştır — bu **yönetimsel bir karardır**, sistem üstlenmez | Sets, 31.07.2026 |
| **K-33** | **Teklifin resmî geçerlilik süresi vardır** ve **gönderirken kayıt altına alınır** — fiyatlar değişiyor ve o süre boyunca yer tutuluyor. ⛔ Ama süre dolunca sistem **kilitlemez, UYARIR**: *"teklif geçerlilik süresi dolmuştur."* Statüyü **insan** değiştirir — satışçı isterse iptal/ret der. ⚠ Tasarım `31` bunu zaten çizmiş: geçerlilik alanı + *"geçerliliğe 3 gün kala nazik hatırlatma (kapatılabilir)"* | Sets, 31.07.2026 (heyet 174 F-P4) |
| **K-19** | Satışçı **eğitim planlama talebi açar** — müşteriyle temas noktası odur. Talep planlamacının kuyruğuna düşer, planlamacı planlar. Kaydın **iskeleti** var (`training_requests.opened_by` polimorfik, izin `training_request.view`, P-37 kapsamı) ama şekli yetmiyor — satışçı talebi çoğul eğitim, il ve müşterisiz açık hâli taşımalı; tablo yeniden kurulacak | `planlama-spec.md` §2.3, §7, P-37 · Sets, 31.07.2026 |

---

## 4 · İş kalemleri ve sıralama

⚠ **§2'deki "Bu planda" sütunu ile buradaki G numaraları birebir eşleşir** — v1.1'de eşleşmiyordu, katılımcı omurgası araya girince harita eski numaralarda kalmıştı *(heyet 167 F-8)*.

⚠ Bunlar **plan görevleri değildir** — kapsamın parçalara bölünmüş hâli ve önerilen sıra. Her kalemin migration sırası, RLS planı, yetki yerleşimi ve test planı **plan dokümanında** yazılacak.

Her görev **ekranıyla birlikte** teslim edilir (backbone tek başına teslim edilmez). Her görev başında ilgili `design/*.dc.html` açılır ve envanteri çıkarılır; teslimden önce kapsama matrisi üretilir (Tasarım Uygulama Protokolü).

### G1 · Portal kabuğu + dashboard — `11` sol yarısı
Portal layout (rail, kimlik şeridi, dil), `/portal`. Dashboard kartları: yaklaşan eğitimler (`training_customers` ✓), iç onay kuyruğum (G5'ten sonra dolar), uyum kartları **boş durumla** (G4'ten sonra dolar).
Yeni tablo yok.

### G2 · Organizasyon, birimler, lokasyonlar — `11` sağ yarısı + `12` lokasyonlar
Yeni: `customer_units` (ağaç), `customer_unit_memberships` (kişi → birim, rol), `customer_locations`, `customer_approval_settings` (iç onay açık/kapalı + **tek onaylayan**, K-15).
Yetki matrisi ekranı — müşterinin kendi kullanıcılarının panel yetkileri.

### G3 · Personel — `12`
Liste + ekleme drawer + portal daveti + birim ataması. `customer_users` üstüne; yeni tablo yok.

### G4 · ⭐ Katılımcı omurgası — kayıt · oturum · yoklama · sınav · tamamlama
Bu planın en çok kapı açan parçası (`15`, `16` sertifikalar, `41`, hakediş, `40`'ın kalan boşlukları).

Yeni: `training_sessions` (eğitimin oturumları), `training_enrolments` (`training_participants`'ın genişlemesi: hangi göreve kayıtlı, statü, yedek listeden mi geldi), `session_attendances` (oturum × katılımcı, zaman damgalı, kim işaretledi), `participant_declarations` (katılımcının kendi beyanı — **ikincil kanıt**), `exam_results`, `training_completions`, `certificate_records` (**numara + veriliş tarihi + geçerlilik tarihi**).

⛔ **Sertifikayı BAKANLIK üretir; 3E üretmez, şablonlamaz, saklamaz** (çatı §136). v1.1'de "sertifika üretimi" yazılmıştı — çatıyla çelişiyordu, düzeltildi *(heyet 167 F-2)*. Sistemde yalnız **kayıt** tutulur: numara, veriliş, geçerlilik. **Belgenin kendisi tutulmaz ve gösterilmez** (§140). Kod gösterilirken zorunlu disclaimer: *"Karar verici Bakanlıktır; güncel geçerlilik durumu Bakanlık sisteminden kontrol edilmelidir"* (§139) — Bakanlık bir sertifikayı iptal ederse bizim kaydımız bunu bilemez.

⚠ **Kendi eğitim kaydımız ayrı şeydir ve kalır** (§141): hangi katılımcı, hangi eğitimi, ne zaman aldı, sınavdan kaç aldı, ne zamana kadar geçerli. Yenileme takibi, süresi dolan personel kartı ve `11`'in uyum oranı buna dayanır — sertifika belgesine değil.

⛔ **Bu tur backend'i kurar, ekranı kurmaz** (K-21). `41` (eğitim günü — yoklamayı işleyen uç) ve `50` (katılımcı beyanı — beyanı giren uç) **bir sonraki turda** yazılır. G10 tüketici uçtur ve bu turda teslim edilir; üretici uçların kapanış adresi budur.

⛔ İkili yoklama sistemi (tasarım `41`): sistemden üretilen liste yazdırılır, **imzalı hali yüklenir** — asıl kanıt odur; katılımcı beyanı ikincil kanıttır. Belge motoru üstünden bağlanır.

⛔ **Bakanlık bildirimiyle kesişme** *(çatı §154, heyet 167 F-3)*: katılımcı listesi bildirildikten sonra yapılan **her değişiklik** "KUMS güncellemesi gerekli" bayrağı üretir ve güncelleme kaydedilmeden eğitim **"Devam Ediyor"a geçemez**. Yedek listeden terfi bu durumu sık üretecek. `training_enrolments` tam bu değişiklikleri doğuran kayıttır — bayrak onun üstünde yaşar. Aksi halde Bakanlığa bildirilmemiş kişi eğitime girer ve sertifikası sakat doğar.

⛔ **KVKK** *(çatı §90, heyet 167 F-5)*: katılımcı görüntüsü/sesi kayıtta olduğundan **katılımcı onboarding'inde aydınlatma + açık rıza adımı zorunludur**; rıza kaydı sistemde tutulur (`consents` ✓ mevcut). G4 katılımcı kaydını kuruyorsa rıza adımını da kurar.

⚠ **Mevzuat kapısı:** sınav eşiği, asgari devam ve yoklama saklama süresi koda gömülmez — eğitim tanımının admin alanlarıdır, mevzuat kaydı **uyarı** olarak hatırlatır (AD-27). Görev başında `mevzuat/` metinlerinden doğrulanır; `docs/mevzuat-kurallari.md`'de "MEVZUATTA YOK" çıkarsa Sets'e sorulur.

### G5 · Teklif isteği ve iç onay — `14`
`training_requests` ✓ üstüne katılımcı grupları (`training_request_groups`: birim, eğitim, katılımcı listesi — kişiler G4'ün kayıt tablosuna bağlanır). 3 adımlı istek akışı, istek özeti, tek yöneticili iç onay kuyruğu (K-2, K-15).

### G6 · Yazışma omurgası — AD-20
Yeni: `correspondence_threads` (kayda bağlı: eğitim · teklif · fatura), `correspondence_messages`, ek dosyaları S3'te hash'li (AD-11).
Giden mail Reply-To'da referans kodu taşır; Postmark inbound webhook `To` local-part'ından kaydı bulur (fallback `In-Reply-To`), imzayla doğrular, eşleşmeyeni triyaj kuyruğuna atar, auto-reply/OOO filtreler.
⛔ Gelen mail **hiçbir iş aksiyonunu tetiklemez** — yalnız yazışma kaydıdır (K-6, AD-20 §1). ⚠ Ama **görünür** olur: thread'e düşer, ilgili satırda *"son hamle"* olarak okunur ve sahibine bildirim gider (K-24). Aksiyonu **insan** alır.

⛔ **AD-20 §1 revizyonu GEREKMİYOR** *(Sets, 31.07.2026 — heyet 168 F-R1'e cevap)*: *"e tamam zaten bir şey yaratmıyor ki, satışçının kendi aksiyon alması gerekir; biz bir şey yapıyoruz sistemsel olarak yazmadım. Kural doğru."* Sınır burada: mail **görünürlük ve bildirim** üretir, **kayıt durumu** üretmez.

### G6b · Satışçının planlama talebi — `34 Planlama Talebi`
✅ **Tasarım geldi** (31.07.2026): Ekran A `/satis/planlama-talepleri/yeni`, Ekran B `/planlama/talepler`. Brief: `docs/design/planlama-talebi-brief.md`.

⚠ **Referans kodu öneki:** tasarım `TLP-2026-0094` yazıyor — **iki yönden** AD-19'a aykırı: (1) **üç harf** — YouTrack anahtarıyla görsel çakışır (`66`'nın `GRV`'si için verilen kararın aynısı: kod iki harfe iner, `TL`); (2) **ardışık görünümlü numara** — AD-19 rastgele son ek ister, sıra numarası iş hacmi sızdırır. Mockup metni **her iki yönüyle** geçersizdir (`HANDOFF` kuralı); üretilecek kod `TL-2026-XXXX` şeklindedir.

⚠ **Tasarımcının brief'te olmayan eklemesi:** talep, kendisini doğuran **sorgulama sonucuna bağlanıyor** ("Sorgulama sonucundan geldi · 34 kişi / 9 firma · planlamacı aynı sorguyu açabilir"). Kabul — planlamacının önceliklendirmesi tam da bu sayıya bakıyor, ve kaynağı açabilmek talebi gerekçesiyle birlikte okunur kılıyor.
`TrainingRequestPolicy` ✓ hazır; `training_requests` ⚠ **yeniden kurulacak** (brief §6 — bugünkü şekli müşterisiz talebi reddediyor), ekranların ikisi de yok. Satışçı talep açar (müşteri + tanım + kişi sayısı + tercih tarih aralığı + not), talep planlamacının kuyruğuna düşer, planlanınca `training_id` bağlanır ve talep `planned` olur (K-19).
⛔ Bu görev K-18'in ekran karşılığıdır: satışçının eğitim yaratma kapısı yoktur, **talep açma** kapısı vardır.

### G7 · Teklif omurgası + satışçı ekranı — `31`
Yeni: `quotes` (N eğitime yayılabilir — K-14), `quote_items` (kalem: eğitim, **fiyat tipi (gün / kişi başı)**, bant, birim fiyat, adet, indirim — K-13), `quote_versions` (metin + hash, AD-14 + K-17), `quote_approvals` (3E iç onayı, K-4).
Fiyat matrisinden beslenir (K-7), indirim tavanı `user_discount_limits` ile sınırlanır, maliyet salt okunur (K-8), kontenjan üç sayıyla gösterilir (K-9).

⛔ **Tahsis eğitim bazlıdır** (K-20): teklif onayı tek, rezervasyon kalem kalem. Üç eğitimli bir teklifte biri dolmuşsa o kalem tutmaz — teklifin tamamı düşmez. `quote_items` bu yüzden kendi tahsis durumunu taşır.

⛔ **Kayıt ofis tarafında, görünürlük müşteriye açılır** (K-22). Bu, kırmızı çizgi 1'in (tenant data leak) muafiyeti **değildir**: müşteri yalnız kendisi için hazırlanmış teklifi ve yalnız **gönderilmiş** sürümleri görür — 3E iç onayı (`quote_approvals`), taslak sürümler ve maliyet ona kapalıdır. Policy + RLS'in nereye yazılacağı **plan**ın işi; hangi alanın kime açık olduğu bu belgenin.

### G8 · Müşteri teklif onayı ve revizyon — `13`
Teklif listesi + görüntüleme, **scroll-to-accept**, sürüm geçmişi, onay delili (K-5). **Revizyon isteği** (K-17): müşteri panelden ister ya da maile cevap yazar.

⛔ **Maille gelen cevap GÖRÜNÜR olur ve bildirim üretir** (K-24) — teklifin **durumunu değiştirmez**. Thread'e düşer, satırda *"son hamle"* olarak okunur (K-28), sahibine bildirim gider; **aksiyonu satışçı alır**. Cevabın türü satışçının ne yapacağını belirler — kabul ayrı, soru/düzeltme talebi ayrı. ⚠ **Kabul onay değildir** (AD-20 §1): maildeki "onaylıyorum" teklifi onaylamaz; satışçının işi müşteriyi panele yönlendirmektir. Onayın delili yalnız panelde doğar (K-5).
Onayda: satışçıya bildirim, planlamacıya düşme, yöneticiye bilgi (çatı §10.5).

### G9 · Faturalar + muhasebeye bildirim — `16` faturalar
Yeni: `invoices`, `invoice_items`, `invoice_notifications` (kim, ne zaman, hangi kanal, durum).
"Teklifi faturalandır" ve serbest kalem (K-12), PDF çıktısı.

⛔ **Faturayı doğuran olay ONAYDIR** (K-25), eğitimin gerçekleşmesi değil. Toplu teklif de **bütün olarak** faturalanır — kısmi/eğitim-gerçekleştikçe faturalama **yoktur**, ve bir kalem kontenjan teyidinde asılı olsa da fatura beklemez (K-29). Tahsis eğitim bazlıdır (hangi kalem slot tuttu), faturalanabilirlik teklif bazlıdır (taahhüt kesinleşti mi).

⛔ **İptal ve revize fatura** (K-29): `invoices` iptal edilebilir olmalı ve yeni fatura öncekiyle bağını taşımalı. ⚠ İptal **silme değildir** (AD-11, kırmızı çizgi 12) — kesilmiş fatura kritik kayıttır; iptal bir statü ve gerekçedir. **Muhasebeye bildir** (K-16): fatura sayfasından mail, muhasebe adresi backoffice ayarı, cevap G6 thread'ine düşer — bakan kişi hangi tarihte ne şekilde bildirildiğini görür.

### G10 · Eğitimlerim + sertifikalar — `15`, `16`
G4'ün üstünde: eğitim listesi, detayda katılımcılar ve **yoklama sonucu**, süreç şeridi.

⛔ Sertifika tarafı **liste + kod + disclaimer**'dır; "indirme" yoktur — belge bizde yok (çatı §140, heyet 167 F-2). Yenileme başvurusunda **mevcut sertifikanın yüklenmesi** ise zorunludur (§142, YÖN-2019 md.8) — bu, bizim ürettiğimiz değil müşterinin getirdiği belgedir.

### G11 · İçerik paketleri — `16`
Belge motoru üstüne doküman görüntüleyici.

⛔ **`16`'daki "Açık eğitim duyuruları · `/portal/acik-egitimler`" bloğu KAPSAM DIŞI** (K-26, onaylı sapma — Sets, 31.07.2026). Açık/kapalı satışçı görünürlüğüdür; müşteri panelinde eğitim listesi yoktur. `16`'nın geri kalanı aynen geçerli.

## 4b · Ertelenen geliştirme — müşteriye açık eğitim listesi

⏸ **Bu turda YAPILMAZ** *(Sets, 31.07.2026: "şimdilik erteleyelim… önce yapı düzgün çalışsın, sonra bunu ekleriz")*. Kayda geçiyor ki kaybolmasın.

Fikir: planlama eğitimi planlarken — ya da satışçı talebi açarken — **"müşterilere de görünsün"** diye bir seçenek olsun. Açık eğitimde bu seçilirse, müşterinin panelinde *"planlanmış ve yer olan açık eğitimler"* diye bir liste görünür ve yanında **"bu eğitim(ler) için teklif al"** eylemi durur; müşteri doğrudan listeden teklif isteyebilir.

⚠ Bu, K-26'yı **iptal etmez, kapsamını genişletir**: bugün açık/kapalı yalnız satışçı görünürlüğüdür ve müşteri paneline eğitim listesi düşmez. O seçenek geldiğinde görünürlük **üç değerli** olur (kapalı · satışçıya açık · müşteriye de açık) ve müşteriden gelen teklif isteği `14`'ün akışına bağlanır. Kontenjan sayacına etkisi o gün ayrıca kararlaştırılır — bugünün üç sayısı (K-9) bu yola göre kurulmadı.

## 5 · Açık sorular

| # | Soru | Durum |
|---|---|---|
| S-1 | Aynı teklifte günlük ve kişi başı fiyat karışabilir mi? | ✓ **Karışabilir** → K-13, K-14 |
| S-2 | `15`/`16` kapsam dışı mı? | ✓ **Hayır — katılımcı omurgası bu tura alındı** → G4, G10 |
| S-3 | İç onay kaç kademe? | ✓ **Tek yönetici** → K-15 |
| S-4 | Fatura kapsamı? | ✓ **Kayıt + PDF + muhasebeye bildirim** → K-16, G9 |
| S-5 | Müşteri revizyon isteyebilir mi? | ✓ **Evet, gidip gelen süreç** → K-17, G8 |
| S-6 | K-14 ile K-3 gerilimi: toplu teklif planlanmamış eğitimi kapsar mı? | ✓ **Hayır.** Okuma doğrulandı → K-18, K-19 |

## 6 · Sıra ve büyüklük

**G1 → G2 → G3 → G4 → G5 → G6 → G7 → G8 → G9 → G10 → G11.**

Üç doğal tur:

| Tur | Görevler | Neden birlikte |
|---|---|---|
| **1 · Portal ayakta** | G1, G2, G3 | Kabuk, organizasyon ve personel birbirini besliyor; sonunda müşteri paneline girip kendi yapısını kurabiliyor |
| **2 · Katılımcı omurgası** | G4, G10 | En çok kapı açan parça. Bittiğinde `41`, hakediş ve `40`'ın kalan boşlukları da açılır |
| **3 · Teklif dikeyi** | G6, G6b, G7, G8, G9, G11 | Yazışma omurgası (G6) teklif ve faturanın ikisine birden hizmet ediyor, o yüzden önce gelir. G6b (talep kuyruğu) teklifin **girdisidir**: planlanmamış eğitime teklif kesilmez (K-18) |

⚠ G5 (teklif isteği) 2. turda da gidebilir — `training_requests` hazır olduğu için G7'yi beklemez; sırası pratikte G4'ün yanına düşer.