# Müşteri portalı ve teklif dikeyi — spec

*31.07.2026 · v1.0 · Upstream: `docs/design/musteri-portali-brainstorm.md` (31 karar, heyet 170 **APPROVED**) · Tasarım: `11`, `12`, `13`, `15`, `16`, `31`, `34`, `24`*

Bu belge **sistemin ne yapacağını** tanımlar. Nasıl yapılacağı (servis katmanı, migration sırası, RLS policy yazımı, test dosyaları, rollout) **plan**ın işidir ve burada yoktur.

Kararların kaynağı brainstorm'dur; burada `K-n` diye anılırlar ve **yeniden tartışılmazlar**. Bu belge onları davranışa çevirir.

---

## 1. Kapsam

Müşteri firmanın kendi panelini uçtan uca kullanabilmesi, ve bunun ofis tarafındaki karşılığı: talep → planlama → teklif → onay → fatura zinciri.

**Kapsam içi:** müşteri organizasyonu ve lokasyonları · portal personeli · satıştan planlamaya talep · teklif üretimi, onayı ve revizyonu · fatura ve muhasebeye bildirim · yazışma · katılımcı omurgası (kayıt, oturum, yoklama, beyan, sınav, tamamlama, sertifika kaydı) · müşterinin eğitim ve belge ekranları.

**Kapsam dışı — §11'de gerekçeleriyle.**

---

## 2. Müşteri organizasyonu

### 2.1 Birim ağacı

Müşteri kendi departman/grup yapısını kurar ve gruplara yönetici atar (K-1, çatı §176/§182). Birim **ağaçtır**: bir birimin üstü olabilir.

⚠ Bu ağaç **ofis grup ağacından bağımsızdır**. Ofis tarafındaki `groups` personel hiyerarşisidir; müşterinin birimi kendi tenant'ının içindedir ve tenant sınırını geçmez (omurga-spec §3.2).

Birim yöneticisi kendi biriminin personelini ekler ve o birim için teklif ister (çatı §182).

### 2.2 Lokasyonlar

Müşteri kendi lokasyonlarını tanımlar (liman, terminal, şube). Lokasyon **eğitim yeri değildir** — eğitimin yerini planlamacı belirler (planlama-spec §1.1); müşterinin lokasyonu personelin nerede çalıştığını söyler ve talep/teklifte bağlam taşır.

### 2.3 İç onay akışı

Teklif isteğinde iç onay **müşterinin kendi belirlediği opsiyonel akıştır** (K-2, çatı §98/§182). Ayar iki değer taşır: **açık/kapalı**, ve açıksa **tek onaylayan** (K-15).

⛔ Kademe zinciri yoktur. Çoğu firma tek yöneticidir; zincir modellemek kullanılmayan bir mekanizmanın bakımını üstlenmek olur.

⚠ **Onaylayan pasifleşirse bekleyen istekler askıda kalmaz:** ayar bir kişiyi işaret ediyorsa ve o kişi pasifleştirilirse, iç onay ayarı **kapalı sayılır** ve bekleyen istekler doğrudan 3E'ye düşer — bir firmanın kendi personel değişikliği yüzünden eğitim talebinin kaybolması kabul edilemez. Ayarın sahibi bilgilendirilir.

---

## 3. Portal erişimi

### 3.1 Panel yetkisi veriden türemez

"Portal kullanıcısı" ve "katılımcı" ayrı hesaplar değil, **aynı kaydın iki yeteneğidir** (omurga-spec §3.0). Katılımcılık veriden türer; panel erişimi **açıkça verilir**.

Panel kapısı bugün mevcuttur (`CustomerPanelController`) ve iki şey ister: panel izni + güçlü kimlik. ⛔ Magic link oturumu katılımcı ekranlarına ulaşır, panele **ulaşmaz** — link paylaşılabilir ve paylaşmak teklif onaylama hakkını devretmemelidir (omurga-spec §5.3).

### 3.2 Müşterinin kendi yetki matrisi

Müşteri kendi kullanıcılarının panel yetkilerini yönetir: personel yönetimi, teklif isteme, teklif onaylama, belge görüntüleme, fatura görüntüleme.

⛔ **Teklif onaylama ayrı bir yetkidir.** Teklifi görmek onaylamak değildir; onay bir ödeme taahhüdüdür (K-25) ve delili tutulur (AD-14).

### 3.3 Satışçı değişince iş ne olur

⛔ **Atama değişirse iş yeni satışçıya geçer** (K-31): yeni satışçı müşterinin teklif, talep ve yazışmalarını görmeye başlar, **eskisi göremez**.

⚠ **Eskisinin yaptıklarının kaydı durur ve devralan onu görür.** Devralan kişi *"bu müşteriyle daha önce ne konuşulmuş"* sorusunu cevaplayamıyorsa devir olmamış demektir; yazışma thread'i, teklif sürümleri ve son hamle kaydı yeni satışçıya açıktır.

⚠ Bu bir **erişim** kuralıdır, bir silme kuralı değil: eski satışçının adı geçmiş kayıtlarda durur ve denetim izi değişmez (omurga-spec A-5, AD-06).

#### 3.3.1 Hangi hesap durumu neyi tetikler

⚠ Terimler icat edilmiyor; sistemin mevcut yaşam döngüsüne bağlanıyor — `AccountStatus`: `invited` · `active` · **`suspended`** · **`closed`** (Sets, 27.07.2026). İkisi de kaydı silmez (AD-11, AD-23).

| Durum | İş ne olur | Neden |
|---|---|---|
| **`suspended`** — askıya alma | ⛔ **Hiçbir şey yapılmaz.** Müşteri listesi, taşıdığı teklifler ve atanmış işler **oldukları yerde bekler** | Geri dönülebilir ve kişinin dönmesi beklenir: izin, uzun hastalık, soruşturma. Üzerinden bir şey almak, dönen kişiye boş bir masa bırakmaktır |
| **`closed`** — kapatma | ⛔ Üzerine atanmış işler **kapatmadan ÖNCE** devredilir ya da havuza aktarılır (satışçı ataması silinir) | Kişi ayrılmıştır ve geri alınmaz; kapatmadan sonra **devredecek kimse kalmaz**. Dönen kişi yeni hesap alır, denetim izi hangi istihdamın ne yaptığını söylemeye devam eder |

⚠ **Askıya alma anında uyarı verilir:** *"üzerine atanmış şu işler var"*. Uyarıya rağmen devam ediliyorsa bilerek yapılmıştır — bu **yönetimsel bir karardır** ve sistem onu üstlenmez. Kendiliğinden havuza atmak, yöneticinin bilinçli kararını sessizce bozmak olurdu (K-32).

⛔ Kapatma **geri alınamaz** ve şifreyle doğrulanır; sürtünme bilinçlidir. Bu yüzden devir kapatmanın **ön koşuludur**, sonrası değil.

---

## 4. Talep — satıştan planlamaya

### 4.1 Satışçı eğitim yaratamaz

⛔ Planlamacının oluşturmadığı eğitim için satışçı işlem yapamaz (K-18, çatı §102). Satışçının kapısı **talep açmaktır** (K-19): talep planlamacının kuyruğuna düşer, planlamacı planlar, satışçı sonra o planlanmış eğitim üzerinden teklif keser.

### 4.2 Talebin taşıdıkları

Talebin iki ekranı tasarlandı (K-27, `34 Planlama Talebi`). Bir talep şunları taşır: **çoğul eğitim tanımı**, **il**, **tercih edilen tarih aralığı**, **görünürlük**, tahmini katılımcı sayısı, gerekçe, ve kendi **referans kodu** (`TL-YYYY-XXXX`, AD-19).

⚠ Talep **tek müşteriye bağlı olmak zorunda değildir** (tasarım `34`): bir bölge ve zaman aralığı için de açılır. Müşteriden gelen talep tenant-kapsamlıdır; satıştan gelen talep ofis tarafında yaşar (K-22'nin deseni).

⚠ Talep, kendisini doğuran **sorgulamaya bağlanabilir** ("34 kişi / 9 firma"). Planlamacı aynı sorguyu açabilir — talep gerekçesiyle birlikte okunur.

### 4.3 Görünürlük ve kapsam

Görünürlük iki değerlidir: **açık** (satışçılara görünür) ve **kapalı** (belirli firmalara özel) — K-26.

⛔ **"Açık" müşteriye görünür demek değildir.** Müşterinin önüne 3E'nin plan ya da eğitim listesi düşmez; tanıtım mailingdir.

Açık seçildiğinde **kapsam** sorulur (K-30): *tüm satışçılar* · *seçili grup(lar)* · *seçili satışçılar*. Kapalı seçildiğinde kapsam sorulmaz; karşılığı davet edilecek firma listesidir.

⚠ **Çelişki kaydedilmeden önce engellenir:** kapalı seçilip firma seçilmemesi, ya da açık seçilip firma seçilmesi.

### 4.4 Kuyruk ve kim görür

Planlamacı kuyruğun tamamını görür. Satışçı **üç kümenin birleşimini** görür: atandığı firmaların talepleri (P-37), kendi açtıkları, ve **kapsamına dahil olduğu açık talepler**.

⚠ `planlama-spec` P-37 kapsamı yalnız firma üzerinden tanımlıyor; K-30 ile üçüncü küme eklenir ve o madde bu spec'e göre revize edilir.

### 4.5 Bekleyen iş görünür olur

Kuyruk satırı **iki ayrı bilgi** taşır (K-28): ne kadardır beklediği, ve **son hamleyi kimin yaptığı** (kim, ne zaman, ne dedi).

⛔ Yalnız süre gösteren satır yanıltıcıdır: dokuz gün bekleyen bir kayıt, topu bizde olan da olabilir karşı taraftan haber beklenen de. İkisi aynı görünürse yanlış olan kovalanır.

Satırdan **hatırlatma görevi** açılabilir. Aynı ilke teklif tarafında da geçerlidir (§5).

### 4.6 Statüler

`açık` → `planlandı` (bir eğitime/pakete bağlandı) → ya da `reddedildi`.

⛔ Ret **gerekçesiz olamaz**; gerekçe talep sahibine aynen görünür. Reddedilen talep kapanır ama kaybolmaz — satışçı yeni bilgiyle yeniden açabilir.

### 4.7 Plana çevirme

Planlamacı talebi plana çevirdiğinde planlama ekranı **talebin değerleriyle dolu** açılır: eğitimler seçili, il seçili, tarih aralığı önerilmiş, görünürlük ve **kapsam** taşınmış, kapalıysa firmalar bağlı.

⛔ **Kapsam eğitime yazılır.** Aksi halde "İzmit grubu" kapsamıyla açılan talep plana çevrildiğinde kapsam kaybolur ve eğitim yine tüm satışçılara görünür.

⛔ **Kapsam yazılmakla kalmaz, OKUNUR:** eğitim satışçının gördüğü her listede — teklif ekranı (`31`), takvim, sorgulama — kapsama göre **süzülür**. Kapsamı yazıp hiç okumayan bir uygulama K-30'un gerekçesini boşa çıkarır: İzmit'i ilgilendirmeyen satışçı yine meşgul olur.

⚠ Aynı alanı iki geliş yolu farklı doldurur: **tekliften** gelen eğitim kapalı doğar (teklif kapalı eğitim içindir); **talepten** gelen açık + kapsam doğar. İkisi de meşrudur.

---

## 5. Teklif

### 5.1 Ne üzerine kesilir

Teklif **planlanmış eğitimler** üzerine kesilir (K-3, K-18). Bir teklif **N eğitime** yayılabilir (K-14) — müşteri önümüzdeki altı ayın eğitimleri için tek teklif isteyebilir.

⛔ "Bir eğitim = bir teklif" varsayımı yanlıştır ve şema baştan çoğul kurulur.

### 5.2 Kalemler

Teklif kalem kalem kurulur. Bir kalem şunları taşır: eğitim, **fiyat tipi**, bant, birim fiyat, adet, indirim.

⛔ **Bir teklifte iki fiyat tipi karışabilir** (K-13): kişi başı katılımcı fiyatı ayrı kalem, günlük fiyat ayrı kalem. Her kalem hangi listeden beslendiğini kendi taşır (`fiyatlama-spec` §2.1'in iki ayrı listesi).

Fiyat matristen gelir (bant × müşteri grubu — K-7, `fiyatlama-spec` §2); günlük ve kişi başı **iki ayrı listedir**. Fiyat KDV hariçtir; KDV teklifte hesaplanır (`fiyatlama-spec` §2.3).

⛔ **Kalem fiyatı DONDURULUR** (`fiyatlama-spec` §5): fiyat listeden kaleme **kopyalanır** ve kalem hangi liste sürümünden geldiğini kaydeder. Liste sürümlenir. Sürüm-hash delili (§5.5) teklif **metnini** korur; fiyatın sonradan değişmemesini sağlayan şey budur. ⚠ Fiyat canlı listeden okunmaz.

### 5.2.1 İndirim — limit engellemez, ESKALE EDER

İndirim yüzde ya da tutar olarak girilir (`fiyatlama-spec` §4.1). İki limit vardır: **global azami indirim** ve **satışçı başına özel limit** (`user_discount_limits`).

⛔ **Limit aşımı ENGELLENMEZ; aşan teklif ONAYA GİDER** (`fiyatlama-spec` §4.2, çatı §184). Bloklamak, satışçının yöneticiden onay alarak istisna verme yolunu kapatır — pazarlıkta gerçekten olan şey budur. ⚠ v1.0 bunu *"tavanı aşamaz"* diye yazmıştı; yanlıştı, düzeltildi (heyet 171 S-F1).

⛔ **Limit İKİ SEVİYEDE kontrol edilir: hem kalemde hem teklif toplamında** (`fiyatlama-spec` §4.2). Gerekçesi orada yazılı: yalnız toplam kontrol edilirse bir kalemde uçuk indirim verip başkasından dengelemek mümkün olur; yalnız kalem kontrol edilirse her kalem limitin dibinden geçirilir. **Hangisi aşılırsa** teklif onaya gider.

⛔ **Tavanın yönü: daraltma serbest, GENİŞLETME ENGELLENMEZ — ONAYA DÜŞER** (AD-09, revize Sets 28.07.2026). Global backoffice'te tanımlanır; ofis onu **daraltabilir**. Genişletme denemesi **hata vermez**, onay akışına girer.

⚠ Gerekçe AD-09'da Sets'in kendi cümlesiyle yazılı: *"patronla konuştu, patron dedi ki tamam bizim maks. indirim %25 ama siz bu müşteriye %30 yapın — yapamayacaklar mı?"* Sistem bu istisnayı yasaklamaz, **kayıt altına alır ve onaya gönderir**.

⚠ v1.0 bunu *"daraltılır, genişletilemez"* diye yazmıştı ve kaynağını bulamadığını söylemişti; ikisi de yanlıştı — AD-09 kuralı 95–101 satırlarında **yazıyor** ve eski "hata verir" hâlinin kaldırıldığını da söylüyor (heyet 174 F-P2).

⛔ **Etkin tavan satışçının kendi limitidir; onay o tavan AŞILDIĞINDA doğar** *(Sets, 31.07.2026)*. Satışçıya global üstünde bir limit tanımlanmışsa istisna **tanım anında** verilmiştir — o limitin içinde kalan teklif normal akıştan gider, her teklifte yeniden onaylatılmaz.

⛔ **Onay iki anda doğar ve ikisi bir arada tek kuraldır:**
1. **Tanım anı** — satışçıya global üstünde limit *tanımlanırken*. Onaylanana kadar etkin tavan **eski değerdir**.
2. **Teklif anı** — etkin tavanı *aşan* teklif gönderilirken.

⚠ Biri olmadan diğeri işlemez: tanım anında onay yoksa *"istisna verilmiştir"* dayanaksız kalır ve tavan yükseldiği için teklif anı da tetiklenmez.

⛔ **Aşım onay ekranında BELİRGİN gösterilir:** *"limit aşımı"*. Onaylayan görerek onaylar; sistem engellemez. Sets'in ifadesi: *"buna rağmen onaylanıyorsa onaylanır, yoksa ret gerekçesini biz zaten göstermiş durumdayız."*

⛔ Satışçı **maliyeti görür, değiştiremez** (K-8, çatı §187). Revizyon planlamacınındır.

### 5.3 Kontenjan ve tahsis

Kontenjan üç sayı gösterir: kesinleşen · teklif bekleyen · toplam (K-9, çatı §148). ⛔ Satışçı **hangi satışçının teklifi olduğunu görmez**.

⛔ **Sayaçlar KAPSAM DIŞI okunur** (çatı §149): "teklif bekleyen", satışçının kendi müşterilerini değil **tüm satışçıların tekliflerini** kapsar. Satır bazlı kapsamlı sorgudan sayan bir uygulama yanlış sayı gösterir — satışçı yalnız kendi müşterilerini gördüğü için kalan yeri olduğundan fazla sanır.

⛔ **Tahsis eğitim bazlıdır** (K-20): teklif onayı tektir, rezervasyon kalem kalem işler. Üç eğitimli bir teklifte biri dolmuşsa **o kalem tutmaz, teklifin tamamı düşmez**. Çatı §150'nin *"kimin teklifi önce onaylanırsa slot onundur"* kuralı **eğitim düzeyinde** okunur.

Kontenjan yetmiyorsa sistem karar vermez; kalem "kontenjan teyidi"nde bekler ve insan çözer (çatı §151, planlama-spec §5.4).

⛔ **Yedek liste** (K-10, çatı §152): kontenjan dolduktan sonra gelen talepler sıralı yedek listesine girer ve **kontenjanı işgal etmez**. Sıra numarası bir **öneridir** — ⛔ **otomatik terfi yoktur**; çağrılacak kişiyi insan seçer ve seçim gerekçesiyle audit'e yazılır. Yedek listedeki bir talep için hazırlanan teklifin metninde *"yedek liste"* ibaresi bulunur (çatı §15).

⛔ **İki farklı boşalma karıştırılmaz** (çatı §153): eğitim **öncesi iptal** slotu boşaltır ve yedekten çağırmayı açar; eğitim günü **gelmeme (no-show)** bir **devamsızlık kaydıdır** ve yedek terfi akışını **tetiklemez**. Aksi halde eğitim başlamışken yedekten çağırılan kişi derse yetişemez ve koltuk iki kez sayılır.

⚠ Yedekten terfi §8.3'ün KUMS bayrağını üretir — bildirilmiş bir listeye kişi eklemek bildirim güncellemesi gerektirir.

### 5.4 İç onay ve gönderim

Teklif satışçıdan çıkar → **3E yöneticisinin onayına** düşer → firmaya gider (K-4, çatı §10.4).

⚠ Müşteri **yalnız gönderilmiş sürümleri** görür. 3E iç onayı, taslak sürümler ve maliyet ona kapalıdır (K-22).

### 5.5 Müşteri onayı ve delili

Onay **yalnız panelden** verilir (K-5, AD-14). Onay anında kaydedilenler: **metin sürümü, sürümün hash'i, zaman damgası, onaylayan kullanıcı**.

⛔ Maildeki *"onaylıyorum"* teklif onayı **değildir** (K-6, AD-20 §1). Müşteri maile kabul yazarsa satışçının işi onu panele yönlendirmektir.

⛔ **Kontenjan yetmiyorsa onaydan ÖNCE uyarı metne girer** (çatı §151): *"Bu eğitimde N yer kalmıştır; onayınız kontenjan teyidine tabidir."* ⚠ Uyarı **hash'lenen metnin parçasıdır** — sonradan *"bana böyle bir şey söylenmedi"* itirazı doğmasın diye. Çok eğitimli teklifte (K-14) uyarı **kalem bazında** verilir: hangi eğitimde yer kaldığı ayrı ayrı yazılır, çünkü tahsis de kalem bazlıdır (§5.3).

⚠ Müşterinin onayladığı sürüm ile ekranda duran sürüm **aynı olmalıdır**: onay isteği taşıdığı sürümle birlikte gelir, arada yeni sürüm yayınlandıysa onay **reddedilir** ve müşteriye yeni sürüm gösterilir. Aksi halde delil, görülmemiş bir metni işaret eder.

Onaydan sonra: satışçıya bildirim, planlamacının önüne düşme, yöneticiye bilgi (çatı §10.5).

### 5.6 Revizyon

Revizyon **gidip gelen bir süreçtir** (K-17). Müşteri panelden revizyon ister ya da maile cevap yazar; satışçı revize sürüm üretir. Her tur **yeni bir sürüm** doğurur ve sürümlerin hepsi kayıtlıdır.

⛔ Sürümler **silinmez** (AD-11). Onaylanmış bir sürüm, sonraki sürüm yayınlansa da kaydı korur — neyin onaylandığı sorusunun cevabı odur.

### 5.7 Geçerlilik süresi

⛔ **Teklifin resmî bir geçerlilik süresi vardır ve gönderilirken kaydedilir** (K-33). Gerekçe: fiyatlar değişir ve teklif süresince **kontenjanda yer tutulur**; tarihsiz bir teklif, ne fiyatın ne de koltuğun ne zamana kadar bağlı olduğunu söylemez.

⚠ Varsayılan süre **admin ayarıdır** (AD-08); satışçı gönderirken teklife özel tarih verebilir.

⛔ **Süre dolunca sistem kilitlemez, UYARIR:** *"teklif geçerlilik süresi dolmuştur."* Statüyü **insan** değiştirir — satışçı isterse iptal eder ya da reddedilmiş sayar. Sistem kendiliğinden statü değiştirmez.

⚠ Bu, §5.3'ün *"kontenjan yetmiyorsa sistem karar vermez, insan çözer"* ve K-10'un *"otomatik terfi yok"* çizgisinin aynısıdır: **süre geçmesi bir olgudur, karar değildir.**

⚠ **Tuttuğu yer düşmez** — süresi geçmiş teklifin kalemleri `held` kalır ve kontenjan sayacında *"teklif bekleyen"* olarak görünmeye devam eder, **süresi geçmiş işaretiyle**. Boşaltmak bir karardır ve satışçınındır.

⚠ **Geçerliliğe yaklaşırken hatırlatma** gider (tasarım `31`: üç gün kala, kapatılabilir). Süre de hatırlatma penceresi de admin ayarıdır.

---

## 6. Fatura

### 6.1 Faturayı doğuran olay

⛔ Faturayı doğuran olay **onaydır**, eğitimin gerçekleşmesi değil (K-25). Teklifin amacı ödeme taahhüdünü kesinleştirmektir.

Teklif **bütün olarak** faturalanır; bir kalemi kontenjan teyidinde asılı olsa da beklenmez (K-29). Kısmi/eğitim-gerçekleştikçe faturalama **yoktur**.

### 6.2 İki üretim yolu

Fatura hem **"teklifi faturalandır"** ile hem **serbest kalemle** oluşturulur; firmaya da bağımsız katılımcıya da kesilir (K-12, çatı §191).

⚠ Bağımsız katılımcı ayrı bir aktör değildir — gerçek kişi firma olarak kaydedilir (K-23, omurga-spec §3.1).

### 6.3 İptal ve revize fatura

⛔ Zorunlu yetenek (K-29): teklif onaylanır → fatura kesilir → müşteri bir şey değiştirir → teklif revize edilir → **fatura iptal edilir** → yeni fatura kesilir.

⛔ **İptal silme değildir** (AD-11, kırmızı çizgi 12). Kesilmiş fatura kritik kayıttır: iptal bir **statü ve gerekçedir**, ve yeni fatura öncekiyle bağını taşır.

### 6.4 Muhasebeye bildirim

Fatura sayfasından muhasebeye mail gider (K-16). Muhasebe adresi **backoffice ayarıdır** (AD-08). Fatura **bildirim durumu** taşır: bildirilmedi · bildirildi (kim, ne zaman, hangi kanal).

Muhasebenin cevabı **aynı yere düşer** (§7). Bakan kişi hangi tarihte ne şekilde bildirildiğini ve cevap gelip gelmediğini görür.

⚠ e-Fatura entegratörü bu turda **yoktur**; altyapı provider-bağımsız kurulur (çatı §191). Bu turda fatura kaydı + PDF + bildirim vardır.

---

## 7. Yazışma

### 7.1 Yazışma bir kayda bağlanır

Yazışma bir **kayda** bağlanır ve kayıt türü eğitim, teklif ya da faturadır (AD-20 revizyonu, 28.07.2026). Her kayıt türü kendi referans kodu önekini ve kendi inbound adresini taşır.

Giden mail Reply-To'da referans kodunu taşır; gelen webhook `To` local-part'ından kaydı bulur, bulamazsa **triyaj kuyruğuna** düşer. Auto-reply/OOO filtrelenir; spam eşiği üstü karantinaya alınır.

### 7.2 Gelen mailin sınırı

⛔ Gelen mail **hiçbir iş aksiyonunu tetiklemez** — yalnız yazışma kaydıdır (AD-20 §1).

⚠ Ama **görünür olur ve bildirim üretir** (K-24): thread'e düşer, ilgili satırda *"son hamle"* olarak okunur, sahibine bildirim gider. **Aksiyonu insan alır.** Sistem cevaba bakıp teklifi ilerletmez.

### 7.3 Ekler ve erişim

Ekler hash'li saklanır (AD-11). Mail gövdesi ve ekleri kişisel veri içerebilir; erişim **loglanır** (AD-06, AD-21).

---

## 8. Katılımcı omurgası

### 8.1 Kayıt

Katılımcı bir eğitime **kayıtla** bağlanır. Kayıt şunları taşır: kişi, eğitim, **hangi göreve/kapsama kayıtlı olduğu**, statü, ve yedek listeden gelip gelmediği.

⚠ Bugünkü `training_participants` çıplak bir bağdır; bu spec onun yerine kayıt kavramını tanımlar.

### 8.2 Oturumlar ve yoklama

Eğitim **oturumlara** bölünür. Yoklama **oturum bazlıdır** ve işaretler **zaman damgalıdır**: kim, ne zaman işaretledi.

⛔ **İkili yoklama sistemi** (çatı §190, tasarım `41`): sistemden üretilen liste yazdırılır, **imzalı hâli yüklenir** — asıl kanıt odur. Katılımcının kendi beyanı **ikincil kanıttır** ve imzalı listenin yerine geçmez.

### 8.3 Bakanlık bildirimiyle kesişme

⛔ Bildirilen katılımcı listesinde yapılan **her değişiklik** *"KUMS güncellemesi gerekli"* bayrağı üretir; güncelleme kaydedilmeden eğitim **"Devam Ediyor"a geçemez** (çatı §154). Yedek listeden terfi bunu sık üretecektir.

Aksi halde Bakanlığa bildirilmemiş kişi eğitime girer ve sertifikası sakat doğar.

### 8.4 Sınav ve tamamlama

Sınav sonucu kayda yazılır. Tamamlama kapısı **dört unsurludur** (çatı §143): **imzalı yoklama** · **sınav sonuçları** · **beyan/imza çelişkisinin çözülmüş olması** · **KUMS işlem kanıtı**. Dördü tamam değilse eğitim "tamamlandı" olmaz.

⛔ **Beyan-imza çelişkisi uyarı üretir ve çözülmeden kapı açılmaz** (çatı §190): katılımcı *"katıldım"* beyan etmiş ama imzalı listede yok — ya da tersi. ⚠ Çelişki hâli, ikincil kanıtın (§8.2) tek işe yaradığı andır: beyan imzayı geçersiz kılmaz, ama **eksik imzayı görünür kılar**. Çözüm bir insan kararıdır ve gerekçesiyle kaydedilir.

⛔ **Sınav eşiği, asgari devam ve saklama süresi koda gömülmez** — eğitim tanımının admin-tanımlı alanlarıdır; mevzuat kaydı bunları madde referanslı **uyarı** olarak hatırlatır (AD-27, kırmızı çizgi 14).

### 8.5 Sertifika — Bakanlık üretir

⛔ **Sertifikayı Bakanlık üretir; 3E sertifika belgesi üretmez, şablonlamaz, saklamaz** (çatı §136).

Sistemde tutulan: sertifikanın **numarası + veriliş tarihi + geçerlilik tarihi** (§138). Kod müşteriye ve katılımcıya gösterilir, ancak **her gösterimde 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.

⛔ **Belgenin kendisi tutulmaz ve gösterilmez** (§140). "İndirme" yoktur.

⚠ **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 uyum oranı **buna** dayanır.

⚠ Yenileme başvurusunda **mevcut sertifikanın yüklenmesi zorunludur** (§142, YÖN-2019 md.8) — bu, bizim ürettiğimiz değil müşterinin getirdiği belgedir.

### 8.6 KVKK

⛔ 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 (çatı §90). Rıza olmadan katılımcı kaydı tamamlanmaz.

---

## 9. Müşteri portalı ekranları

### 9.1 Dashboard

Yaklaşan eğitimler · iç onay kuyruğum · uyum kartları (süresi yaklaşan personel, uyum oranı). ⚠ Uyum kartları §8'in kaydına dayanır; o kayıt yokken **boş durum** gösterir, sıfır göstermez.

### 9.2 Personel

Liste, ekleme, portal daveti, birim ataması. Kişisel alanlar tenant anahtarıyla şifreli; arama HMAC hash üzerinden (K-11, AD-05).

⛔ **Müşteri ve müşteri kullanıcısı silinmez, pasifleştirilir** (K-11, AD-23, kırmızı çizgi 12). Pasif kayıt geçmişini taşımaya devam eder: onayladığı teklif, katıldığı eğitim ve sertifika kaydı yerinde kalır — silme, verilmiş bir eğitimin kanıtını yok etmek olurdu.

### 9.3 Teklif isteği

Üç adımlı akış: eğitimler → katılımcı grupları → özet. İç onay açıksa istek onaya düşer (K-2/K-15), kapalıysa doğrudan 3E'ye gider.

### 9.4 Eğitimlerim

Eğitim listesi; detayda katılımcılar ve **yoklama sonucu**, süreç şeridi.

### 9.5 Belgeler

Sertifika kayıtları (kod + tarihler + disclaimer, §8.5), içerik paketleri, faturalar.

---

## 10. Kesişen kurallar

### 10.1 Tenant izolasyonu

| Kayıt | Yaşadığı taraf | Görünürlük |
|---|---|---|
| Müşteri birimi, lokasyon, personel | **Tenant** | Kendi tenant'ı |
| Müşteriden gelen teklif isteği | **Tenant** | Kendi tenant'ı + kapsamındaki ofis kullanıcıları |
| Satıştan gelen talep | **Ofis** | Kapsam kuralı §4.4 |
| Teklif, fatura, yazışma thread'i | **Ofis** | Müşteriye **kendi kaydı kadar** açılır (K-22, K-22b) |
| Katılımcı kaydı, yoklama, sınav, tamamlama | **Tenant** | Kendi tenant'ı + eğitimin eğitmeni ve ofis |

⛔ *"İ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 ve **kapsam kontrolüyle** kurulur, ayırmayla değil.

⛔ Bu bir muafiyet değildir: her ortak yüzeyde **hangi alanın kime açık olduğu** yazılıdır — teklif için §5.4, fatura ve yazışma için aşağıdaki tablo.

| Kayıt | Müşteri görür | Müşteri **görmez** |
|---|---|---|
| **Fatura** | kalemler, tutar, KDV, PDF, iptal/revizyon durumu ve gerekçesi | **muhasebeye bildirim durumu** (bildirildi/bildirilmedi, kim, ne zaman) — 3E'nin iç iş akışıdır |
| **Yazışma thread'i** | kendisiyle yapılan yazışma (satışçı ↔ müşteri) | **3E ↔ muhasebe yazışması**, triyaj kuyruğundaki eşleşmemiş mailler, iç notlar |

⛔ Thread'ler müşteri-satışçı ve 3E-muhasebe konuşmalarını **aynı kayda** bağlar; bu yüzden görünürlük **thread düzeyinde değil, taraf düzeyinde** çözülür. Her mesaj hangi tarafa ait olduğunu taşır. 3E'nin iç yazışmasının müşteriye sızması tenant leak değildir ama **ticari zarardır** ve aynı ciddiyetle ele alınır.

### 10.2 Referans kodları

Talep `TL`, teklif `TK`, fatura `FT` (AD-19; `TK` ve `FT` mevcut). ⛔ **İki harf**, ve son ek **rastgeledir** — sıra numarası iş hacmi sızdırır.

### 10.3 Silinmezlik

Teklif sürümü, onay delili, kesilmiş fatura, imzalı yoklama, sınav sonucu ve tamamlama kaydı **silinmez** (AD-11, kırmızı çizgi 12). İptal ve revizyon vardır.

### 10.4 Audit

Teklif, onay, fatura, iptal, katılımcı kaydı ve tamamlama **append-only loglanır** (AD-06); yazım işlemle aynı transaction'dadır. Hassas kayda dokunan **okumalar** da loglanır (AD-21), değerler maskelidir (AD-16).

---

## 11. Kapsam dışı — gerekçeleriyle

| Ne | Neden |
|---|---|
| `41 Egitmen Saha` (eğitim günü ekranı) ve `50 Katılımcı Paneli` | Bu tur **backend'i** kurar; ekranlar sonraki turda (K-21). Backbone'un caller'ı olmaması bulgu değildir (onay kuralı 4) |
| Müşteri panelinde açık eğitim listesi ve panelden kayıt | K-26 — açık/kapalı satışçı görünürlüğüdür. ⏸ *"Müşterilere de görünsün"* üçüncü değeri **ertelendi**; geldiğinde kontenjan sayacına etkisi ayrıca kararlaştırılacak |
| e-Fatura entegratörü | Entegratör belli değil; altyapı provider-bağımsız kurulur (çatı §191) |
| Müşterinin iç onay zinciri (çok kademe) | K-15 — tek yönetici yeterli |
| Bakanlık doğrulama API'si | Yoktur (AD-15); sertifika kaydı ileride bir provider'a bağlanmaya hazır tutulur (çatı §137) |

---

## 12. Upstream'de kapatılması gerekenler

Bu spec'in kendi işi değil; kaynak belgelerde bulunan ve **bu spec yazılırken ortaya çıkan** boşluklar.

| # | Ne | Neden önemli |
|---|---|---|
| ~~U-1~~ | ✅ **Kapandı** (Sets, 31.07.2026): mevzuat kuralı **dayatılmaz, uyarı olarak konur** — *"saha gerçekleri ile mevzuat Türkiye'de birçok konuda örtüşmüyor; esnetip uygulayamıyorlarsa iş yapamazlar, yapabiliyorlarsa esnetilmiş demektir. Biz dayatamayız."* Çatı §129'un eski cümlesi düzeltildi | — |
| ~~U-2~~ | ❌ **Kayıt YANLIŞTI, geri alındı.** AD-09 kuralı 95–101 satırlarında yazıyor ve 28.07.2026'da revize edilmiş: *"Genişletme engellenmez, onay akışına düşer."* v1.0 AD-09'un yalnız 78–86 arasını okumuştu. ⚠ Türev belgeler (`docs/issues.md`:41, heyet prompt kural 2) hâlâ **eski** "genişletme yasak" hâlini taşıyor — **onlar** düzeltilmeli | — |
| U-3 | `planlama-spec` P-37 satışçı kapsamını yalnız firma üzerinden tanımlıyor; K-30 üçüncü kümeyi (kapsamındaki açık talepler) ekledi (§4.4) | Talep tablosu yeniden kurulurken P-37 revize edilmeli |

---

## 13. Kabul kriterleri

| # | Kriter |
|---|---|
| M-1 | Müşteri birim ağacı kendi tenant'ındadır ve ofis grup ağacıyla hiçbir kayıt paylaşmaz (§2.1) |
| M-2 | İç onay ayarı açık/kapalı + tek onaylayandır; onaylayan pasifleşirse bekleyen istekler askıda kalmaz, doğrudan 3E'ye düşer (§2.3) |
| M-3 | Magic link oturumu panele ulaşmaz; teklif onaylama ayrı yetkidir (§3) |
| M-4 | Satışçı eğitim kaydı oluşturamaz; yalnız talep açar (§4.1) |
| M-5 | Talep çoğul eğitim, il ve tarih aralığı taşır; kendi referans kodu vardır (§4.2) |
| M-6 | Açık talepte kapsam sorulur (tümü/grup/kişi), kapalıda sorulmaz; çelişkili kombinasyon kaydedilemez (§4.3) |
| M-7 | Satışçı üç kümenin birleşimini görür: atandığı firmalar + kendi açtıkları + kapsamındaki açık talepler (§4.4) |
| M-8 | Kuyruk satırı hem bekleme süresini hem son hamleyi gösterir; satırdan hatırlatma görevi açılabilir (§4.5) |
| M-9 | Talep reddi gerekçesizdir olamaz; gerekçe talep sahibine görünür (§4.6) |
| M-10 | Plana çevirmede kapsam **eğitime yazılır**; tekliften gelen kapalı, talepten gelen açık + kapsam doğar (§4.7) |
| M-11 | Bir teklif N eğitim taşır; kalemler farklı fiyat tipleri karıştırabilir ve her kalem kaynağını söyler (§5.1, §5.2) |
| M-12 | İndirim limiti **engellemez, eskale eder**: aşan teklif onaya gider; limit **hem kalemde hem toplamda** kontrol edilir (§5.2.1) |
| M-48 | Onay **iki anda** doğar: global üstü limit **tanımlanırken**, ve etkin tavan **aşılırken**. Onaysız geniş limit etkin değildir; onaylanmış limitin içindeki teklif yeniden onaya düşmez (§5.2.1, AD-09) |
| M-35 | Kalem fiyatı listeden **kopyalanır** ve geldiği liste sürümünü kaydeder; fiyat canlı listeden okunmaz (§5.2) |
| M-36 | Satışçı maliyeti görür, değiştiremez (§5.2) |
| M-13 | Tahsis eğitim bazlıdır: bir kalem dolu eğitim yüzünden tutmazsa diğer kalemler tutar (§5.3) |
| M-14 | Müşteri yalnız gönderilmiş sürümleri görür; iç onay, taslak ve maliyet kapalıdır (§5.4) |
| M-15 | Onay panelden verilir ve sürüm + hash + zaman damgası + kullanıcı kaydedilir; arada yeni sürüm yayınlandıysa onay reddedilir (§5.5) |
| M-16 | Maildeki kabul teklifi onaylamaz (§5.5, §7.2) |
| M-17 | Her revizyon turu yeni sürüm doğurur; sürümler silinmez (§5.6) |
| M-18 | Fatura onayla kesilebilir hale gelir; teklif bütün olarak faturalanır (§6.1) |
| M-19 | Fatura iptal edilebilir ve yeni fatura öncekiyle bağını taşır; iptal silme değildir (§6.3) |
| M-20 | Fatura bildirim durumu taşır (kim, ne zaman, hangi kanal); muhasebe cevabı aynı thread'e düşer (§6.4) |
| M-21 | Gelen mail hiçbir iş aksiyonunu tetiklemez; görünür olur ve bildirim üretir (§7.2) |
| M-22 | Kod eşleşmeyen gelen mail triyaj kuyruğuna düşer, sessizce kaybolmaz (§7.1) |
| M-23 | Yoklama oturum bazlı ve zaman damgalıdır; imzalı liste asıl, beyan ikincil kanıttır (§8.2) |
| M-24 | Bildirilen listedeki değişiklik "KUMS güncellemesi gerekli" bayrağı üretir; bayrak açıkken eğitim "Devam Ediyor"a geçemez (§8.3) |
| M-25 | Sınav eşiği, asgari devam ve saklama süresi admin-tanımlıdır; kodda sabit sayı yoktur (§8.4) |
| M-26 | Sertifika **kaydı** tutulur (numara + veriliş + geçerlilik); belge tutulmaz, gösterilmez, indirilemez; her gösterimde disclaimer çıkar (§8.5) |
| M-27 | Katılımcı kaydı KVKK aydınlatma + açık rıza olmadan tamamlanmaz (§8.6) |
| M-28 | Uyum kartları veri yokken boş durum gösterir, sıfır göstermez (§9.1) |
| M-29 | Teklif, fatura ve yazışma ofis tarafında yaşar; müşteri kendi kaydını görür ve her ortak yüzeyde hangi alanın kime açık olduğu yazılıdır (§10.1) |
| M-30 | Talep/teklif/fatura kodları iki harflidir ve son ekleri rastgeledir (§10.2) |
| M-33 | Kontenjan dolduktan sonraki talepler yedek listesine girer, kontenjanı işgal etmez ve **otomatik terfi olmaz**; terfi insan kararıdır ve gerekçesiyle audit'lenir (§5.3) |
| M-34 | Müşteri ve müşteri kullanıcısı silinmez, pasifleştirilir; pasif kayıt onay, katılım ve sertifika geçmişini taşımaya devam eder (§9.2) |
| M-37 | Kontenjan yetmiyorsa onay ekranında **onaydan önce** uyarı çıkar ve uyarı **hash'lenen metne dahildir**; çok eğitimli teklifte kalem bazında verilir (§5.5) |
| M-38 | Eğitim öncesi iptal slot boşaltır ve yedekten çağırmayı açar; eğitim günü no-show devamsızlık kaydıdır ve terfi akışını tetiklemez (§5.3) |
| M-39 | Kontenjan sayaçları kapsam dışı okunur — "teklif bekleyen" tüm satışçıların tekliflerini kapsar (§5.3) |
| M-40 | Tamamlama kapısı dört unsurludur: imzalı yoklama, sınav sonuçları, beyan-imza çelişkisinin çözümü, KUMS işlem kanıtı (§8.4) |
| M-41 | Beyan-imza çelişkisi uyarı üretir; çözülmeden tamamlama kapısı açılmaz, çözüm gerekçesiyle kaydedilir (§8.4) |
| M-42 | Müşteri faturasının muhasebe bildirim durumunu ve 3E'nin iç yazışmasını görmez; görünürlük thread düzeyinde değil taraf düzeyinde çözülür (§10.1) |
| M-43 | Eğitim, satışçının gördüğü her listede kapsama göre süzülür — kapsam yazılmakla kalmaz, okunur (§4.7) |
| M-44 | Satışçı ataması değişince yeni satışçı geçmişi (thread, sürümler, son hamle) görür; eski satışçı göremez (§3.3) |
| M-46 | Teklif gönderilirken geçerlilik tarihi kaydedilir; varsayılan admin ayarından gelir ve teklife özel verilebilir (§5.7) |
| M-47 | Süresi geçen teklif **uyarı üretir, statü değiştirmez**; kalemleri `held` kalır ve sayaçta "süresi geçmiş" işaretiyle görünür. İptal/ret bir **insan** kararıdır (§5.7) |
| M-45 | `closed`'a geçmeden **önce** atanmış işler devredilir ya da havuza aktarılır; `suspended`'da iş atanmış kalır ve askıya alma öncesi uyarı verilir (§3.3.1) |
| M-31 | Teklif sürümü, onay delili, fatura, imzalı yoklama, sınav sonucu ve tamamlama silinmez (§10.3) |
| M-32 | Teklif, onay, fatura, iptal, katılımcı kaydı ve tamamlama audit'lenir; hassas okumalar erişim loguna yazılır (§10.4) |