# Planlama, kontenjan ve bakanlık bildirimi — spec

*29.07.2026 · Sets'in tanımı (planlama turu tasarım oturumu) · çatı §61-67, §102-110, §145-155, §172-194, §218; Y-2016 md.7/2, md.13/ç, md.13/d, md.13/f, md.13/g, md.16-17; YÖN-2019 md.6/3, md.11, md.14/1, md.14/2; TY-2019 md.17/1; DG-2020 md.14/4, md.14/8 · AD-15, AD-19, AD-20, AD-23, AD-24, AD-27*

Bu belge **planlanan eğitim kaydının** tek kaynağıdır: nasıl doğar, hangi statülerden geçer, kontenjanı nasıl tutar, Bakanlığa nasıl bildirilir, nasıl iptal edilir. Her satır ya Sets'in 29.07.2026 tarihli kararlarından ya da referansı verilen mevzuat maddesinden gelir; **varsayımla doldurulmuş satır yoktur.**

**Bu belgenin var olma sebebi:** eğitim kataloğu (`training_definitions`) *"IMDG Görev 4 eğitimi diye bir şey vardır ve şöyledir"* der. Bu spec *"3 Eylül 2026'da İzmit'te, ABC Lojistik için, Mehmet Bey'le, 18 kişilik bir IMDG Görev 4 eğitimi yapılacaktır"* kaydını tanımlar. Birincisi kural, ikincisi olgudur; eğitmen ataması, maliyet, yazışma, bakanlık bildirimi ve iptal olguya bağlanır.

**Kapsam dışı** (adresi §18'de): teklif ve katılımcı **tabloları** · açık eğitim duyuru sistemi · tedarikçi portalı · müşterinin kendi organizasyonu.

---

## 1. Eğitim katalogdan doğar

Planlanan eğitim, katalogdaki bir tanımın bir kez gerçekleşmesidir. Kayıt `training_definition_id` taşır ve **zorunludur** — tanımsız eğitim, hangi mevzuata tabi olduğu, kaç saat sürdüğü, sınavı olup olmadığı ve Bakanlığa nasıl bildirileceği bilinmeyen eğitimdir.

Tanımdan gelen ve planlamada **okunan** değerler: azami/asgari katılımcı, süre, sınav şartı ve eşiği, bildirim tipi ve süresi, yenileme periyodu, eğitmen şartları.

⛔ **Tanımdan kopyalanmaz, okunur.** Tek istisna §5'teki kapasitedir ve gerekçesi oradadır. Bir eğitimin saatini geçmişe dönük değiştirmemek için müfredat zaten versiyonlanmıştır (`training_curricula`); ikinci bir dondurma katmanı aynı işi iki kez yapardı.

### 1.1 Yer

Kayıt iki alan taşır: **il** (yönetilen listeden) ve **adres** (serbest metin).

İl ayrı bir alandır çünkü planlamacı kokpiti il bazında sorgular (çatı §194: *"il ve firma bazında eğitim süresi dolan kişi adetleri"*) ve serbest metin üzerinde il kırılımı üretilemez.

⚠ **İl listesi bugün yok.** `option_lists` altyapısı hazır (`OptionList::EDUCATION_FIELD`, `DENIZCILIK-YETERLILIK` gibi listeler seed'li) ama il listesi tanımlı değil. Bu spec onu bir kalem olarak ekler: liste backoffice'te yönetilir (AD-08), koda gömülmez.

### 1.2 Hangi mevzuat sürümüyle verildiği saklanır

Çatı §16: *"mevzuat sürümlüdür; verilen her eğitim hangi sürümle verildiğini saklar."*

Kayıt, tanımın bağlı olduğu mevzuatın **o günkü sürümünü** (`regulation_versions`) ve uygulanan **müfredat sürümünü** (`training_curricula`) tutar.

⛔ Okuma anında hesaplanamaz. Bir genelge yayımlandığında tanım güncellenir; geçen yılki eğitimin hangi kurala göre verildiği sorusu o güncellemeden sonra da cevaplanabilir olmalıdır. Yayımlanmış müfredat geriye dönük değişmez (çatı §16) — bu kayıt o kuralın planlama tarafındaki karşılığıdır.

⚠ **Çoklu mevzuat bağı.** Çatı §165 bir eğitimin birden fazla mevzuata bağlanabileceğini söyler. Bugünkü veri modeli bunu **tek `regulation_id` + `regulation_parents` zinciriyle** kuruyor (`training_definitions.regulation_id`, `regulations.parent_id`): eğitim bir metne bağlanır, o metin bir üst metne. Dolayısıyla saklanan sürüm de tektir — bağlı metnin sürümü. Zincirin üst halkalarının ayrı ayrı sürümlenmesi gerekirse bu, mevzuat kaydının kararıdır (AD-27), planlamanın değil.

### 1.3 Eğitimin kendi evrakları

Çatı §16 son paragrafı ve AD-24: eğitim başına zorunlu evraklar (eğitim dokümanı, sınav dokümanı, yoklama dokümanı) **aynı gereklilik motorundan** yönetilir — `document_types` + `document_type_scopes`, kapsam değeri eğitimdir.

Eksik evrak operasyon yöneticisine **görev** olarak düşer (mekanizma T4'te kuruldu: `OpenDocumentTasks`).

⚠ Bu, §9.4'ün donmuş kanıt setinden **farklı bir şeydir**: orası eğitmenin yetkinlik belgelerinin nüshası, burası eğitimin kendi evrakı.

### 1.4 Yapılış biçimi

`in_person` (yüz yüze) · `online` (çevrimiçi) · `hybrid` (hibrit).

**Karar (Sets, 29.07.2026):** biçim şimdilik **yalnız bilgi alanıdır** — kaydedilir, raporlanır, başka hiçbir davranışı değiştirmez.

⚠ Biçime bağlı kural yazmadan önce mevzuat taraması gerekir: çevrimiçi eğitimin izinli olup olmadığı ve şartları `mevzuat/` içindeki metinden doğrulanmalıdır. Doğrulanmadan kural yazılmaz (CLAUDE.md, varsayımla kod yazmak yasağı §4).

---

## 2. Görünürlük ve müşteri bağı

**Karar (Sets, 29.07.2026).** Eğitim kaydı bir **görünürlük** taşır:

| Değer | Kod | Ne demek |
|---|---|---|
| Kapalı | `closed` | Yalnız listelenen firmalara aittir |
| Açık | `open` | Bölgedeki tüm firmalara açıktır (YÖN-2019 md.11) |

Kapalı eğitimin firmaları ayrı bir tabloda listelenir: **bir satır** = çatı §63'ün kurumsal eğitimi, **N satır** = çatı §65'in çoklu kurumsal eğitimi. Üç eğitim türü için tek mekanizma; ayrı bir "tür" alanı yoktur.

⚠ Görünürlük alanı, firma listesi boş olsa da **ayrıca durur**. Boş listeyi tek başına yorumlamak iki farklı durumu ayırt edemez: açık eğitim mi, yoksa henüz firması seçilmemiş kapalı eğitim mi?

### 2.1 Firmayı planlamacı atar

**Karar (Sets, 29.07.2026):** müşteriye özel eğitim, planlama aşamasında firmasıyla birlikte açılır — *"planlamadan direkt olarak müşteriye özel eğitim diye açılması gerekir ki tüm satışçılara düşmesin."*

⚠ **Bu, tasarımdan bilinçli sapmadır.** `design/HANDOFF.md` §5 *"planlamacı müşteri seçmez — müşteri bağlamı satıştan salt-okunur gelir"* der. O kural **açık eğitim için doğrudur** ve kapalı eğitimi düşünmemiştir: bir firmaya özel eğitimi "sahibi belirsiz" bırakmak, onu tüm satış havuzuna açmak demektir. İki kural yan yana yaşar — kapalıda firmayı planlamacı belirler, açıkta müşteri tekliften gelir.

### 2.2 Görünürlük ne zaman değişir

Taslak aşamasında serbestçe. `planned` ve sonrasında **yalnız §4.3'ün geri çekme yolundan** — yani geri çekmenin şartları burada da geçerlidir.

### 2.3 Kim görür

Bu spec üç yeni kayıt türü doğuruyor ve üçü de **firma verisi taşıyor**: kapalı eğitimin firma listesi, yedek liste, talep kuyruğu. Görünürlükleri burada tanımlanır; tanımsız bırakmak, tenant izolasyonunu (AD-02, AD-03, kırmızı çizgi 1) bu kayıtlar için açık bırakmak olurdu.

#### Ofis tarafı

| Kayıt | Kim görür |
|---|---|
| **Kapalı eğitim** | Listelenen firmalara **atanmış satışçılar** (`office_user_customers`) + AD-23 kapsamı yeten yöneticiler + planlamacı *(Sets, 29.07.2026)* |
| **Açık eğitim** | `training.view` taşıyan herkes, kapsamı dâhilinde |
| **Yedek liste** | Kontenjan sayılarıyla aynı rejim: satışçı sırayı ve toplamı görür, **hangi firmanın sırada olduğunu görmez**. Tam liste planlamacı ve yöneticilerdedir (çatı §148 ve `HANDOFF.md` §15'in teklif sahipliği kuralının aynısı) |
| **Talep kuyruğu** | `training_request.view` + AD-23 kapsamı; satışçı yalnız **atandığı firmaların** taleplerini görür |

⚠ Kapalı eğitimin görünürlük kuralı §2.1'in **gerekçesinin kendisidir** — *"tüm satışçılara düşmesin"* cümlesi ancak bu kuralla bir karşılık bulur.

#### Müşteri tarafı

⛔ **Çoklu kurumsal eğitimde her firma yalnız kendini görür** *(Sets, 29.07.2026)*. Firma A, listede firma B'nin adını göremez.

Gerekçe: grup şirketi senaryosunda zararsız görünen bu liste, birbiriyle rakip iki firma aynı seminere girdiğinde **müşteriden müşteriye ifşadır** — ve hangi senaryonun yaşandığını sistem bilemez. Kırmızı çizgi 1 tam olarak budur.

⚠ Katılımcı listesi de aynı kuraldadır: bir firmanın kullanıcısı yalnız kendi firmasının katılımcılarını görür. Bu, `training_participants`'ın zaten tenant-kapsamlı olmasının doğal sonucudur; burada yazılmasının sebebi eğitimin **paylaşılan** bir kayıt olmasıdır — paylaşılan kaydın altındaki satırların paylaşılmadığı açıkça söylenmelidir.

---

## 3. Referans kodu: PL → EG

AD-19'un tek istisnası buradadır. Planlama aşaması kendi kodunu taşır (`PL-2026-7K4F`); eğitim oluştuğunda **rastgele son ek korunur, ön ek `EG` olur** (`EG-2026-7K4F`).

Geçiş anı: **`draft` → `planned`**. Gerekçe AD-19'un kendi cümlesidir — *"planlama onaylanmadan eğitim oluşmuyor"*; satışa açılan şey artık bir plan değil bir eğitimdir.

⛔ **Eski kod ölmez, yönlendirir.** `pl-2026-7k4f@` adresine geçişten sonra gelen bir acente cevabı aynı kayda düşer (AD-19, AD-20).

⚠ Benzersizlik `(yıl, son ek)` uzayındadır, `(ön ek, yıl, son ek)` uzayında değil — mekanizma `reference_codes` tablosunda kurulu, bu spec yalnız `PL` ön ekini kullanır.

---

## 4. Statü makinesi

```
draft ──► planned ──► [ministry_notified | ministry_approved] ──► in_progress ──► completed
  │  ▲       │                      │                             │
  │  └───────┘                      │                             │
  │   geri çekme (§4.3)             │                             │
  │                                 ▼                             ▼
  │        planned ─┬──────► cancellation_requested ──onay──► cancelled
  │                 │                    │
  │      (bildirilmiş de dahil)          └──ret──► geldiği statüye döner
  ▼
abandoned  (taslaktan vazgeçme — onaysız, §4.4)
```

| Statü | Kod | Nereden gelinir | Nereye gidilir |
|---|---|---|---|
| Taslak | `draft` | Doğuş · `planned`'dan geri çekme | `planned` · `abandoned` |
| Vazgeçildi | `abandoned` | `draft` | — (son) |
| Planlandı | `planned` | `draft` | Bakanlık adımı · `draft` · `cancellation_requested` |
| Bakanlığa Bildirildi | `ministry_notified` | `planned` | `in_progress` · `cancellation_requested` |
| Bakanlık Onaylı | `ministry_approved` | `planned` | `in_progress` · `cancellation_requested` |
| Devam Ediyor | `in_progress` | Bakanlık adımı | `completed` · `cancellation_requested` |
| Tamamlandı | `completed` | `in_progress` | — (son) |
| İptal Talebi | `cancellation_requested` | `planned` · bakanlık adımı · `in_progress` | `cancelled` · geldiği statü (ret) |
| İptal Edildi | `cancelled` | `cancellation_requested` | — (son) |

⛔ **`completed` iptal edilemez.** Verilmiş bir eğitim geri alınamaz; yanlışlık varsa düzeltme yolu revizyondur, iptal değil (AD-11).

⚠ **İptal talebi reddedilirse kayıt geldiği statüye döner** ve ret gerekçesi audit'te kalır. Ret, eğitimi ilerletmez ve geriletmez.

⚠ **Bakanlık adımı tek statü değildir** (AD-15, `mevzuat-kurallari.md` §10). Hangisinin uygulanacağı eğitim tanımının `notification_type` alanından gelir — §10.

### 4.1 `draft` → `planned`

Şartlar:
- Zorunlu alanlar dolu: eğitim tanımı, tarih aralığı, il, kapasite, görünürlük (kapalıysa en az bir firma)
- Maliyet eşiği onay gerektiriyorsa (`egitmen-spec.md` §7.4) **onay alınmış** olmalı

⚠ Eğitmen ataması bu geçişin şartı **değildir**. Bir eğitim eğitmeni kesinleşmeden satışa açılabilir; `egitmen-spec.md` §6.11 satılabilirliği kendi kuralına bağlar.

### 4.2 Onay geçişin içindedir

Onay ayrı bir statü değildir. `egitmen-spec.md` §7.4'ün kuralı işler: global ayar + planlamacı bazında ayar, daraltma doğrudan, genişletme onaya. Onay bekleyen eğitim `draft` olarak kalır ve *Bekleyen planlama onayları* ekranında görünür.

### 4.3 Geri çekme: `planned` → `draft`

**Karar (Sets, 29.07.2026):** *"eğer herhangi bir satışçı işlem yapmadı ise değişiklik yapılabilir ama önce taslağa geri çekmesi gereksin. Çünkü onay gerektiren bir durum varsa tekrar onaya gitmesi gerekir."*

| Şart | Değer |
|---|---|
| Geri çekilebilir mi | O eğitim için **hiçbir teklif kaydı açılmamışsa** evet |
| Alınmış planlama onayı | **Düşer** — değişiklik sonrası yeniden onaya gider |
| Kesinleşmiş eğitmen ataması | Korunur; esaslı değişiklikte `reconfirming` olur (`egitmen-spec.md` §6.10) |
| Bakanlığa bildirilmişse | Geri çekilemez — §10.5 |

⚠ **Eşik teklifin *oluşturulmasıdır*, gönderilmesi değil** *(Sets, 29.07.2026)*. Satışçının henüz kimseye göndermediği taslak teklif bile geri çekmeyi kapatır. Gerekçe: emeğin boşa gitmemesi ve akışın tek bir kuralla anlaşılır kalması.

⛔ Teklif açılmışsa tek yol **iptal + yeniden planlama**. Sets'in gerekçesi: *"yoksa karışıklık çıkar."*

### 4.4 Taslaktan vazgeçme

**Karar (Sets, 29.07.2026):** taslak **onaysız** sonlandırılır — oluşturan vazgeçer, kayıt `abandoned` olarak durur.

Gerekçe: taslak hiçbir taahhüt taşımaz. Satışa açılmamıştır, Bakanlığa bildirilmemiştir, müşteri onayı yoktur. İptal onayının koruduğu şey verilmiş bir sözün geri alınmasıdır (§11.1); ortada söz yokken onay beklemek, kimsenin görmediği bir kaydı silmek için imza toplamaktır.

⛔ **Silinmez, `abandoned` olarak durur** (AD-11). `PL` kodu üretilmişse o kod ölü kalır ve yeniden kullanılmaz.

### 4.5 Devam eden ve tamamlanan

`in_progress`: eğitim başlangıç tarihine gelinmiştir. `completed`: `egitmen-spec.md` ve yoklama/sınav turunun kilitleri sağlanmıştır (imzalı yoklama, sınav notları, çelişki çözümü — `HANDOFF.md` §2, §9).

⚠ **Katılımcı listesi bildirimden sonra değiştiyse** *"KUMS güncellemesi gerekli"* bayrağı çıkar ve güncelleme kaydedilmeden `in_progress`'e geçilemez (`HANDOFF.md` §1). Yedek listeden çağırma bunu sık üretir.

---

## 5. Kontenjan

Kayıt **dört** sayı taşır. Çatı §15 üçünü sayar; dördüncüsü Sets'in 29.07.2026 kararıdır (§5.2).

| Alan | Ne | Kim artırır |
|---|---|---|
| `capacity` | Toplam kontenjan | Planlamacı belirler, tanımdaki azamiyi aşamaz |
| `confirmed_seats` | **Kesinleşen** koltuk | Onaylanan teklif |
| `pending_seats` | **Teklif cevabı bekleyen** koltuk | Gönderilmiş, henüz onaylanmamış teklif |
| `named_seats` | Adı girilmiş katılımcı | Katılımcı kaydı |

Gösterge çatı §15'in dilidir: *"8 kesinleşen · 10 teklif bekliyor / 25"*.

⛔ **Bekleyen teklif kontenjanı bloklamaz, onay bloklar.** Sert sınır yalnız `confirmed_seats ≤ capacity`'dir; `pending_seats` bilgi amaçlıdır ve toplamı aşabilir. Aynı ayrım eğitmen tarafında da kuruludur (`egitmen-spec.md` §6.5: *"bekleyen teklif takvimi bloklamaz, kabul bloklar"*) — iki yerde aynı kuralın iki farklı çalışması, ikisinden birinin yanlış olması demektir.

⛔ **Temel kural: kimin teklifi önce onaylanırsa slot onundur** (çatı §15).

⚠ **Satışçı hangi satışçının teklifi olduğunu görmez** (çatı §15). Sayılar görünür, sahipleri görünmez; o bilgi direktör ve operasyondadır.

### 5.1 Tavan serttir

**Karar (Sets, 29.07.2026):** `capacity` eğitim tanımındaki `max_participants` değerini **aşamaz**. Planlamacı aşağı çekebilir (salon küçükse, tek eğitmen varsa), yukarı çekemez.

⛔ **Bu, indirim tavanı gibi ticari bir tercih değildir.** 30 kişiyi geçen IMDG semineri Y-2016 md.13/ç'ye, 25 kişiyi geçen TY deniz gözetim semineri TY-2019 md.17/1'e aykırıdır; onaya götürmek işe yaramaz çünkü onaylayan taraf İdare değildir. AD-09'un *"genişletme onaya gider"* revizyonu **iş parametreleri** içindir; bu bir mevzuat sınırıdır.

⚠ Sayı yine de **kodda değildir** (kırmızı çizgi 14). Tavan eğitim tanımından okunur, tanım backoffice'te yönetilir.

#### Mevzuatın tavan koymadığı eğitimler

Bazı ailelerde azami katılımcı sayısı mevzuatta yoktur (DGY — `mevzuat-kurallari.md` §2). O durumda tanımın `max_participants` alanı boş kalır.

**Karar (Sets, 29.07.2026):** boşsa **3E'nin kendi genel tavanı** uygulanır — backoffice'te tanımlı bir varsayılan ayar (`settings`).

⚠ Bu tavan mevzuat sınırı değildir, 3E'nin kendi kuralıdır; dolayısıyla §8.1'in genel ilkesine tabidir — aşılması engellenmez, uyarı üretir ve onay birimi karar verir. §5.1'in sert kuralı yalnız **mevzuattan gelen** sayı için geçerlidir.

### 5.2 İsim sayısı ayrıca tutulur

**Karar (Sets, 29.07.2026):** rezerve koltuk ve adı girilmiş katılımcı **ayrı ayrı** tutulur ve gösterilir.

Gerekçe gerçek akıştır: müşteri *"5 kişi göndereceğim"* der, teklifi onaylar, isimleri bir hafta sonra verir. Yalnız isme bakan bir sayaç o hafta boyunca kontenjanı boş gösterir ve aynı koltuklar ikinci kez satılır. Yalnız koltuğa bakan bir sayaç ise Bakanlığa bildirilecek isimlerin eksikliğini hiç söylemez.

`named_seats < confirmed_seats` olduğu sürece **uyarı** üretilir. Bu uyarının gerçek karşılığı vardır: bildirim kursiyer bilgisi ister (YÖN-2019 md.6/3).

### 5.3 Kilit veritabanındadır

⛔ `confirmed_seats ≤ capacity` kısıtı **veritabanı seviyesinde** durur ve tahsisi artıran işlem satırı kilitler.

Gerekçe `egitmen-spec.md` §6.4'ün aynısıdır: aynı saniyede onaylanan iki teklif, uygulama katmanındaki bir *"doldu mu"* kontrolünü ikisi de geçer. Kontenjan aşımı burada yalnız bir hata değil, mevzuata aykırı bir eğitimdir.

⚠ Sayaç **kayıt üzerinde denormalize tutulur**, katılımcı satırlarından sayılarak değil. Çatı §15 gerekçesini yazar: satışçı yalnız kendi katılımcılarını gördüğü için (RLS) satır bazlı sorgudan okunan sayı yanlış çıkar.

### 5.4 Kontenjan yetmiyorsa sistem karar vermez

Çatı §15: müşterinin onayı **kaydedilir** — iradesi geçerlidir — ama tahsis *"kontenjan teyidi"* durumuna düşer ve satışçı + direktör + operasyon kuyruğuna girer. Firmayla konuşulup hangi kişilerin gireceği elle seçilir.

⛔ Sistem kimin gireceğini seçmez. Müşteri onay ekranında bu **onaydan önce** yazılır: *"Bu eğitimde N yer kalmıştır; onayınız kontenjan teyidine tabidir."* Onaylanan metin hash'lendiği için (AD-14) sonradan itiraz doğmaz.

⚠ Bu spec'in kurduğu, eğitim tarafındaki **durum ve görev**dir; müşteri onay ekranının metni ve teklif tarafı EGT-26'nın işidir (§16).

### 5.5 Asgari katılımcı uyarıdır

**Karar (Sets, 29.07.2026):** tanımdaki asgari sayının altındaysa planlamacıya işaret edilir, **hiçbir geçiş engellenmez**.

⚠ Gerekçe mevzuattadır: `mevzuat-kurallari.md` §2 asgari katılımcı sayısının **hiçbir metinde geçmediğini** kaydeder. Çatıdaki *"en az 3 kişi"* 3E'nin kendi kuralıdır ve dayanağı olmayan bir sayının işi durdurması için sebep yoktur.

---

## 6. Yedek liste

**Karar (Sets, 29.07.2026):** kapasite dolduktan sonra gelen talepler yedek listesine girer. *"25 kişilik eğitim ama 25 kişi dolduktan sonra yedekler olarak kayıt almak isteyebilirler; gelmeyen olur, iptal eden olur, yedekler ile ilerlenir."*

| Alan | Ne |
|---|---|
| Firma | Hangi müşteri sıraya girdi |
| Koltuk sayısı | Kaç kişi için |
| Sıra | Giriş sırası |
| Durum | `waiting` · `promoted` · `withdrawn` |

⛔ **Yedek kontenjanı işgal etmez.** 25 kesinleşen + 5 yedek, mevzuata aykırı değildir; 30 kesinleşen aykırıdır. Ayrım budur.

⛔ **Otomatik terfi yoktur** (çatı §15, `HANDOFF.md` §15). Sıra numarası **öneridir**; çağrılacak tarafı insan seçer ve **seçim gerekçesiyle audit'e yazılır**. İki koltuk boşaldığında beş kişilik bir talebin kısmen çağrılıp çağrılamayacağı bir insan kararıdır.

⚠ Birim **talep**tir (firma + kişi sayısı), isimli kişi değil *(Sets, 29.07.2026)*. Yedeğe girmek isteyen taraf, tam da henüz kimseyi kesinleştirmemiş olan taraftır.

### 6.1 İki farklı boşalma karıştırılmaz

Çatı §15'in ayrımı:

| Ne oldu | Sonuç |
|---|---|
| **Eğitim öncesi iptal** | Koltuk boşalır, yedekten çağrılabilir |
| **Eğitim günü gelmeyen (no-show)** | Devamsızlık kaydıdır; yedek terfi akışını **tetiklemez** |

⚠ İkisini aynı saymak, eğitim günü boş kalan koltuğa yedek çağırmak demektir — çağrılan kişinin katılamayacağı bir eğitime.

⚠ Yedek listedeki bir talep için hazırlanan teklifin metninde *"yedek liste"* ibaresi bulunur (çatı §15). Metnin kendisi EGT-26'nın işidir; bu spec yalnız kaydın yedek olduğunu bilinir kılar.

---

## 7. Talep kuyruğu

**Karar (Sets, 29.07.2026):** planlamacının önüne düşen istek kendi kaydıdır.

| Alan | Ne |
|---|---|
| Firma | Kim istiyor |
| Eğitim tanımı | Hangi eğitim |
| Kişi sayısı | Kaç kişi |
| Tercih dönemi | Hangi tarih aralığı |
| Yer notu | Nerede olması isteniyor |
| Not | Serbest metin |
| Açan | Kim açtı (polimorfik — bugün ofis kullanıcısı, yarın müşteri kullanıcısı) |
| Durum | `open` · `planned` · `declined` |
| Karşılayan eğitim | Hangi eğitim bu talebi karşıladı |

⛔ **Teklife dair hiçbir alan burada yoktur** — fiyat, indirim, teklif metni. Talep planlamacının girdisidir; teklif satışın çıktısıdır ve kendi tablosunu EGT-26 kurar, buraya bağlanır. Aksi hâlde bu spec satış spec'ini önden yazmış olurdu.

⚠ Çatı §106 esastır: *"planlama yapılmadan teklif süreci başlamaz."* Talep bir eğitim değildir; eğitimi her zaman planlamacı açar.

---

## 8. Eğitmen ataması ve maliyet

Bu iki konunun kuralları `egitmen-spec.md`'de yazılıdır ve burada **tekrarlanmaz**. Bu spec yalnız bağlarını kurar:

| Konu | Kaynak | Bu spec'in kurduğu |
|---|---|---|
| İhtiyaç → teklif → kabul → kesinleşmiş atama | `egitmen-spec.md` §6 | Zincirin bağlandığı eğitim kaydı ve tabloları |
| Aday listesi: kapsam + uygunluk | §6.3, §3.1 | Yetkinlik kapısının veri modeli (§9) |
| Kabul atomiktir, kontenjan DB'de kapanır | §6.4 | Aynı kilit deseni §5.3'te kontenjan için |
| Çakışma yalnız kesinleşmiş atamalardan | §6.5, K-4 | §8.2 |
| Maliyet kalemleri: planlanan + gerçekleşen | §7.1–7.3 | Kalemlerin bağlandığı eğitim kaydı |
| Planlama onayı | §7.4 | Statü geçişindeki yeri (§4.1, §4.2) |
| Masraf onayı, cari | §7.6–7.8 | — (kendi turunda) |

### 8.1 Planlama ekranında gösterilen mevzuat uyarıları

**İlke (Sets, 29.07.2026):** sistemin işi limit alanını sunmak, bildirimi yapmak ve **uyarmaktır**; kararı onay birimi verir. Mevzuat metni zaman içinde sahadaki uygulamayla ayrışabilir — İdare *"beş kişinin altına eğitim açılmaz"* der, pratikte tek kişilik eğitime izin verilir hâle gelir, metin öylece kalır.

⛔ **Uyarıya rağmen verilen onay engellenmez ve audit'e yazılır.** Bir denetimde sistemin uyardığı ve buna rağmen onaylandığı okunabilir olmalıdır — sorumluluk o zaman onaylayanda durur, sistemde değil.

⛔ **Tek istisna azami katılımcı sayısıdır** (§5.1): aşılamaz, çünkü onaylayan taraf İdare değildir.

Planlama ekranında gösterilen iki mevzuat uyarısı — ikisi de **uyarıdır, kısıt değil** (AD-27):

| Uyarı | Kaynak | Neden zorlanamaz |
|---|---|---|
| *"Gece vardiyasının ardındaki sabah eğitimine personel katılamaz"* | YÖN-2019 md.14/1, çatı §218 | Katılımcının vardiya verisi **toplanmaz** — çatı §218'in kendi kararı. Veri olmadan kural zorlanamaz |
| *"Kıyı tesisindeki eğitim planlaması, varsa tesiste görevli TMGD ile koordineli yapılır"* | YÖN-2019 md.14/2 | Koordinasyonun yapılıp yapılmadığı sistemin göremeyeceği bir şeydir |

⚠ Metinler mevzuat kaydının **uyarı** katmanından gelir (AD-27, `mevzuat-kurallari.md` §11), koda gömülmez.

### 8.2 Çakışma yalnız eğitmene bakar

**Karar (Sets, 29.07.2026):** mekâna kısıt konmaz. *"İskenderun Limanı'nda aynı gün 2 eğitim, birisi bir toplantı salonunda, diğeri diğer toplantı salonunda."*

Yer serbest metin olduğu için çakışma kontrolü yapılamaz; yapılabilseydi bile yanlış olurdu — sistem bir tesisin kaç salonu olduğunu bilmez. Tek çakışma kaynağı kesinleşmiş eğitmen atamasıdır (`egitmen-spec.md` §6.5).

---

## 9. Yetkinlik kapısı

`egitmen-spec.md` §11/2 bu konuyu *"şeması eğitim tanımı turunda çözülür"* diye ertelemişti. **Yarısı çözülmüş durumda:** `instructor_requirements` (şart kaydı, mevzuat maddesiyle) ve `training_definition_instructor_requirement` (hangi eğitim hangi şartları ister) chunk 10'da doğdu.

Eksik olan iki bağı bu spec kurar.

### 9.1 Eğitmen × verebileceği eğitim

**Karar (Sets, 29.07.2026):** *"bir eğitmen sisteme kaydedilirken 'hangi eğitimleri verebilir' ekranı açılacak, seçtiği eğitimlere göre eğitmen ön şartları istenecek."*

```
Eğitmen kaydı → verebileceği eğitimler seçilir
              → o eğitimlerin şartları toplanır
              → her şart için belge görevi açılır (mekanizma T4'te kuruldu)
              → belge geçerli olduğu sürece şart karşılanır
```

⚠ Şart ayrıca işaretlenmez — **eğitim seçilir, şart oradan türer.** İki kez veri girmek, iki kaynağın birbirinden sapması demektir.

### 9.2 Şart × kabul edilen belge türleri

**Karar (Sets, 29.07.2026):** bir şart **N belge türünden biriyle** kanıtlanabilir.

Gerekçe mevzuatın kendi kurgusudur. Y-2016 md.7/2 lisans düzeyinde eğitimi ön şart koyar ve üstüne **şunlardan birini** ister:

| Alternatif | Madde |
|---|---|
| En az **uzakyol birinci zabiti** veya **uzakyol birinci mühendisi** ehliyeti | md.7/2-a |
| Tehlikeli madde taşıma/depolama kuruluşlarının yük ve emniyet operasyonlarında **en az 5 yıl** çalışmış olmak | md.7/2-b |
| Tehlikeli maddeler konusunda kamu kurum/kuruluşlarında **en az 5 yıl** çalışmış olmak | md.7/2-c |

Tek bir şart, üç farklı evrakla kanıtlanır — model bunu ifade edebilmelidir.

⛔ **"Uzakyol" nitelemesi düşürülemez.** Uzakyol olmayan bir birinci zabit ehliyeti md.7/2-a'yı **karşılamaz**. Doğrulanmış kural seti `docs/mevzuat-kurallari.md` §7.1'dedir ve belge türü tanımlarını backoffice'te yapacak kişi oradan okur.

⚠ `instructor_requirements.requires_document` alanı zaten var; eksik olan hangi belge türlerinin kabul edildiğidir.

### 9.3 Kapı serttir

**Karar (Sets, 29.07.2026):** şartı taşımayan eğitmen aday listesinde **görünmez** — `egitmen-spec.md` K-1 aynen korunur.

⛔ Gerekçe Y-2016 md.13/d'dir: eğitimler yalnız İdare tarafından yetkilendirilmiş eğiticilere verdirilir. Yanlış eğitmen yalnızca kötü bir seçim değil, yükümlülük ihlalidir ve md.16-17 idari para cezası + yetki askıya alma öngörür.

### 9.4 Donmuş kanıt seti

**Karar (Sets, 29.07.2026):** *"her eğitimde full set olarak koyalım, o tarihte geçerli olan evrakları; böylece verilen eğitim dosya olarak bizde kenarda dursun. Yarın eğitmen evrağı silinmiş, referans evrak gitmiş gibi bir sıkıntımız olmaz."*

Atama kesinleştiği an eğitmenin ilgili belgelerinin **dosyaları eğitimin kendi alanına kopyalanır**, künyeleriyle birlikte: belge adı ve türü, seri, veriliş ve geçerlilik tarihi, içerik hash'i, hangi şartı karşıladığı, kopyalanma zamanı.

⛔ **Denetimde sorulacak soru bugünkü veriden hesaplanamaz.** *"Bu eğitimi veren kişi o tarihte yetkili miydi"* sorusunun cevabı, o gün dondurulmuş olmak zorundadır. Aynı gerekçe sistemde zaten yazılıdır: `instructor_documents` migration'ı belgenin kritiklik ve özel kategori bayraklarını şablondan **filme çeker**, okuma anında join etmez — *"bir evrağın ne olduğu, şablon değişti diye değişmez."* Bu, o ilkenin bir üst basamağıdır.

⚠ **Referans değil kopya, ve bunun bir bedeli var.** Sets fiziksel kopyayı seçti; alternatif, belge versiyonuna referans verip o versiyonu kritik işaretlemekti (AD-11 tetikleyicisi silmeyi zaten engelliyor). Kopyanın bedeli kayda geçirilir: **aynı kişisel belge onlarca eğitimde çoğalır** ve KVKK açısından *"aynı veriyi kaç yerde tutuyorsun"* sorusunun cevabını büyütür. Saklama süresi kuralı bu nüshalar için ayrıca belirlenmelidir; tabanı §9.5'tedir.

### 9.5 Kanıt setinin saklama süresi eğitim ailesine göre değişir

⛔ **Tek bir sayı yoktur.** Y-2016 md.13/f kayıtların en az **3 yıl**, DG-2020 md.14/4 en az **5 yıl** saklanmasını ister (`docs/mevzuat-kurallari.md` §9). Tek "3 yıl" tabanı, DGY ailesinden bir eğitimin kanıt setini mevzuat altı bir süreye mahkûm ederdi.

Taban, eğitim tanımının **`record_retention_years`** alanından okunur — kolon zaten var (`training_definitions`), sayı backoffice'te girilir, kodda yer almaz (AD-08, kırmızı çizgi 14).

⚠ Üst sınır 3E'nin kararıdır ve KVKK açısından belirlenmelidir (§17/2) — kopyalar kişisel veridir ve çoğalırlar.

### 9.6 Kanıt setine kim erişir

Kopya, orijinal belgeyle **aynı erişim rejimine tabidir** (`egitmen-spec.md` §2.1, AD-05, AD-21): hassas alanlar maskeli gelir, açık görüntüleme ayrı bir eylemdir ve erişim loguna yazılır.

⛔ **Eğitimi görebilmek kanıt setini görebilmek değildir.** Satışçı §8'e göre maliyeti görür; eğitmenin ehliyet belgesini görmesi için hiçbir sebep yoktur. Kanıt seti ayrı bir izin ister ve o izin eğitim görme izninden türemez.

⚠ Kopyanın orijinalden **daha gevşek** bir rejime tabi olması, erişim kontrolünü kopyalayarak aşmanın yolu olurdu.

⚠ Kopyalar **eğitimin kaydına aittir**, eğitmenin dosyasına değil. Eğitmen ayrıldığında, belgesi güncellendiğinde veya kaydı pasifleştiğinde kopya yerinde kalır.

---

## 10. Bakanlık bildirimi

### 10.1 İki model

`mevzuat-kurallari.md` §10 ve AD-15:

| Model | Kod | Kural | Kaynak |
|---|---|---|---|
| Bildirim | `notification` | Başlama tarihinden en az **3 gün önce**; onay beklenmez | Y-2016 md.13/g, YÖN-2019 md.6/3 |
| Onay | `approval` | En az **15 gün önce**; **İdare onaylamadan eğitim verilemez**, onaysız eğitim geçersizdir | DG-2020 md.14/8 |

Hangisinin uygulanacağı eğitim tanımının `notification_type` alanından gelir. Süre de tanımdan gelir (`notification_days`) — **gün sayısı koda yazılmaz** (kırmızı çizgi 14).

### 10.2 Ayrı yetkidir

**Karar (Sets, 29.07.2026):** *"Bakanlığa bildir"* kendi iznidir; planlamacıda olması şart değildir.

Gerekçe: bildirim dış bir sisteme (KUMS) elle giriş + dönen kimliğin sisteme yazılmasıdır. Bunu operasyon personeli veya bir uyum sorumlusu da yapabilir; o kişiye planlama yetkisi vermek zorunda kalmak, yetki modelini işin şekline göre bükmek olurdu. Aynı desen T4'te eğitmen kadro bildirimi için kurulmuştur.

### 10.3 Bildirimin son tarihi görev üretir

Bildirim süresi eğitim tanımından okunur (§10.1) ve **son tarih hesaplanabilir**: eğitim başlangıcından `notification_days` kadar geriye gidilir.

| An | Ne olur | Kime |
|---|---|---|
| Son tarih yaklaşırken | Görev açılır: *"Bakanlığa bildirim yapılmalı"* | `training.notify_ministry` taşıyanlar, AD-23 kapsamında |
| Son tarih geçtiğinde | Görev **yükselir** ve alert üretir | Yukarıdakiler + Eğitim ve Operasyon Direktörü |

⛔ **Uyarı değil görev.** Gerekçe §11.2'nin kendi cümlesidir: *"unutulan bir bildirimi hatırlatan tek şey bir uyarı metniyse, o bildirim unutulur."* Yaptırım aynıdır — Y-2016 md.16-17 idari para cezası ve yetki askıya alma; onay modelinde ise 15 günün kaçırılması eğitimi **fiilen geçersiz** kılar (DG-2020 md.14/8).

⚠ Kaç gün önceden görev açılacağı **ayardır**, koda yazılmaz (AD-08). ⛔ Süre **takvim günü** sayılır *(Sets, 18.08.2026 — EGT-43 kapatıldı: resmî tatil listesi diye bir ihtiyaç yok, sektör 7/24/365 çalışıyor)*. Takvim günü saymak son tarihi gerçeğinden **erken** getirir, geç değil — cezası olan bir kuralda doğru yön budur.

### 10.4 Bildirim kaydı

Her bildirim bir satırdır: ilk bildirim, güncelleme, iptal bildirimi. Kayıt tutar: türü, gönderim zamanı, gönderen, KUMS kimliği, onay zamanı (onay modelinde), belge/ekran görüntüsü referansı.

⚠ **KUMS kimliği bizim ürettiğimiz bir kod değildir** (`HANDOFF.md` §7) — Bakanlığın kimliğidir, referans kodu mekanizmasından ayrı bir alandır.

### 10.5 Bildirimden sonra

- **Kilit:** bildirilmiş eğitim `draft`'a geri çekilemez. Dışarıya verilmiş bir beyan vardır.
- **Değişiklik bayrağı:** katılımcı listesi, eğitmen, tarih veya yer değişirse *"KUMS güncellemesi gerekli"* bayrağı çıkar; güncelleme kaydedilmeden `in_progress`'e geçilemez (`HANDOFF.md` §1).
- **Onay modelinde** `ministry_approved` statüsüne geçmek onay kanıtı ister; onaysız eğitim başlatılamaz.

---

## 11. İptal

### 11.1 Onaya tabidir

**Karar (Sets, 29.07.2026):** iptal talep edilir, onaylanır, sonra gerçekleşir. Ara statü `cancellation_requested`.

Yetki **ayrıdır** (`training.cancel_approve`) ve kimin hangi eğitimi onaylayabileceği AD-23 kapsam çözümleyicisinden gelir. Maliyet eşiği onayından ayrı tutulmasının sebebi farklı bir karar olmasıdır: biri para, diğeri verilmiş bir taahhüdün geri alınması.

⚠ Gerekçe her iki adımda da zorunludur — talepte ve retde (`HANDOFF.md` §4).

### 11.2 İptalin sonuçları

Çatı §110:

| Ne olur | Kime |
|---|---|
| ALERT | Planlama ve yönetim |
| Bilgi | Katılımcılar ve eğitmen |
| **Bildirim görevi** | Bakanlık bildirimi yetkisini taşıyanlara |

**Karar (Sets, 29.07.2026):** bildirilmiş bir eğitim iptal edilirse **bildirim görevi açılır** ve o görev kapanmadan iptal tamamlanmış sayılmaz.

⚠ Uyarı yerine görev olmasının sebebi yaptırımdır: Y-2016 md.16-17 yükümlülük ihlalinde idari para cezası, düzeltilmezse yetki askıya alma öngörür. Unutulan bir bildirimi hatırlatan tek şey bir uyarı metniyse, o bildirim unutulur.

### 11.3 İptal edilen kayıt silinmez

AD-11 ve kırmızı çizgi 12. İptal edilen eğitim `cancelled` statüsünde durur; kodu, kayıtları, yazışması ve bildirimi yerinde kalır.

---

## 12. Tedarikçiler

**Karar (Sets, 29.07.2026):** otel, acente ve araç kiralama firmaları **yönetilen kayıttır**. `egitmen-spec.md` §11/1'in açık kalanı böylece kapanır.

| Kayıt | Ne tutar |
|---|---|
| Tedarikçi | Ad, tür (otel/acente/araç — yönetilen liste), il, iletişim, aktiflik |
| Fiyat teklifi | Tedarikçi, hizmet, tutar, geçerlilik, alındığı tarih |

Bölgesel fiyat tarihçesi buradan **kendiliğinden** oluşur: tedarikçinin ili bilindiği için *"İzmit'te otel geçen yıl kaçtı"* sorusu cevaplanabilir hâle gelir (çatı §11, §186).

⚠ **Tedarikçi portalı kapsam dışıdır** — tasarımın kendi notu: *"tedarikçi portalı sonraki faz"* (`design/23 Planlamaci Takvim`). Fiyatları planlamacı elle girer; çatı §186'nın *"MVP: manuel giriş"* notu tam olarak budur ve tedarikçi kaydıyla çelişmez.

---

## 13. Yetki vokabüleri

Ofis kimlik ailesine eklenen izinler, hepsi AD-23 kapsamlı (`.own` / `.group` / `.all`):

| İzin | Ne |
|---|---|
| `training.view` | Eğitimi görmek |
| `training.create` | Eğitim planlamak |
| `training.update` | Planı değiştirmek |
| `training.approve` | Maliyet eşiği onayı (`egitmen-spec.md` §7.4) |
| `training.cancel` | İptal talep etmek |
| `training.cancel_approve` | İptali onaylamak |
| `training.assign_instructor` | Eğitmen ihtiyacı açmak, teklif göndermek, seçim yapmak |
| `training.notify_ministry` | Bakanlığa bildirmek, KUMS kimliğini yazmak |
| `training_request.view` | Talep kuyruğunu görmek |
| `supplier.view` / `.create` / `.update` | Tedarikçi kaydı |

⚠ **Ad düzeltmesi upstream'e işlendi (29.07.2026):** `egitmen-spec.md` §7.4 ve §9 ile AD-23'ün onay omurgası tablosu `planning.approve` yazıyordu, `training.approve` oldu. Kayıt `trainings` olduğuna göre izin ailesi de odur — aynı kayda iki farklı isimle atıfta bulunmak, izin matrisini okuyan kişiye iki ayrı şey varmış izlenimi verir.

⚠ `training.create`'in `.own` değeri **yoktur**: kendisi için eğitim planlamak diye bir şey yoktur (aynı gerekçe `user.create` için T4'te kaydedildi).

---

## 14. Ekranlar

| Ekran | Tasarım | Kim |
|---|---|---|
| Planlamacı kokpiti | `Stil Yonu.dc.html#3a` | Planlamacı |
| Sorgulama + talep kuyruğu | `20 Planlamaci Sorgulama` | Planlamacı |
| Planlama ekranı (tek sayfa, çok eğitim) | `21 Planlamaci Sihirbaz` — **adım yapısı kullanılmaz**, §20 | Planlamacı |
| Paket detayı (mali tablo, eğitmen matrisi) | — (yeni), §15 | Planlamacı |
| Eğitim detayı (tek sayfa, KUMS kilidi) | `22 Planlamaci Egitim Detay` | Planlamacı, operasyon |
| Takvim + tedarikçiler | `23 Planlamaci Takvim` | Planlamacı |
| Bekleyen planlama onayları | — (`egitmen-spec.md` §7.4) | `training.approve` taşıyanlar |
| Bekleyen iptal onayları | — (yeni) | `training.cancel_approve` taşıyanlar |

### 14.1 Takvim

Takvim, planlamacının kapsamındaki eğitimleri tarih ekseninde gösterir: statü rozeti, il, eğitim tanımı, kontenjan doluluğu ve eğitmen durumu.

⚠ Takvim bir **görünüm**dür, ayrı bir kayıt değil — çakışma kontrolü §8.2'nin kuralına dayanır ve takvimin kendi mantığı yoktur. Eğitmen müsaitliği `egitmen-spec.md` §3'ten, kesinleşmiş atamalar §6'dan okunur.

⚠ Son iki ekranın tasarımı yoktur; `HANDOFF.md` §4'ün "Onaylar kuyruğu" deseni ve `63 Yonetici Kullanici Log`'daki Onaylar sayfası kullanılır.

---

## 15. Planlama paketi

### 15.0 Paket iki yoldan doğar

**Karar (Sets, 29.07.2026):** paket ne yalnız talebin karşılığıdır, ne yalnız 3E'nin kurgusu. İkisi de gerçek yoldur ve ikisi de aynı kaydı üretir.

| Yol | Nasıl başlar | Görünürlük | Kim satar |
|---|---|---|---|
| **Talep üzerine** | Bir firma ister (§7 talep kuyruğu) | Genellikle **kapalı** — talep eden firmaya özel | Atanmış satışçı |
| **İhtiyaçtan kurgulanan** | 3E kendi verisine bakar: *"Antalya'daki müşterilerde 10 farklı eğitimden şu kadar kişinin belgesi bitmek üzere"* → oraya bir program kurar | Genellikle **açık** | Kapsamı yeten tüm satışçılar |

⛔ **Görünürlük paketin değil, eğitimin özelliğidir** (§2). Paket görünürlük taşımaz; formdaki görünürlük seçimi altındaki eğitimlere yazılır. Bir pakette hem açık hem kapalı eğitim bulunabilir — sahada bir program hem talep eden firmayı hem bölgedeki diğer firmaları taşıyabilir.

⚠ **İhtiyaç analizi bu spec'in kapsamı değildir ve bugün mümkün değildir.** *"X kişinin belgesi bitmek üzere"* sorusu katılımcı geçmişi ve sertifika kaydı ister; ikisi de henüz yazılmadı (katılımcı modülü, EGT-38 hattı). Sets'in cümlesi bunu doğruluyor: *"altyapı olmadığı için bunu yapamıyorlardı."* Bu delta paketin **kaydını** kurar; onu besleyecek analiz ekranı kendi turunda gelir ve o tur geldiğinde paket zaten hazırdır.

### 15.1 Paket bir kayıttır

Paket kendi kodunu taşıyan bir kayıttır (`PR-2026-7K4F`, AD-19'un rastgele son ek kuralı aynen geçerli). Altındaki eğitimlerin **her biri kendi kodunu, kendi kontenjanını, kendi bakanlık bildirimini ve kendi statüsünü taşımaya devam eder.**

⛔ **Ön ek `PR`, `PK` değil, ve programdaki eğitim programın son ekini taşır** *(Sets, 31.07.2026 — AD-19 revizyonu, kod: `ReferencePrefix::Package`)*. Bu bölüm önce `PK-2026-XXXX` ve bağımsız `EG` kodları yazıyordu; ikisi de değişti. Gerekçe: herkesin kullandığı kelime "program"dır, ve eskiden `PK-2026-7K4F` ile `EG-2026-9M2X` arasında **görünür hiçbir bağ yoktu** — kodu eline alan "bu hangi haftanın eğitimi" diyemiyordu. Programa bağlı olmayan eğitim düz biçimi korur (`EG-2026-9M2X`).

```
PR-2026-7K4F  İskenderun Limanı · 03–07 Eylül
├─ EG-2026-7K4F-01  IMDG Görev 8      5 kişi
├─ EG-2026-7K4F-02  TMGD Yenileme    10 kişi
└─ EG-2026-7K4F-03  Gözetim Temel    15 kişi
```

⛔ **Paket bir eğitim değildir.** Satılmaz, bakanlığa bildirilmez, sertifika doğurmaz, katılımcı taşımaz. Bunların hepsi eğitimin işidir. Paketin taşıdığı tek şey, üç eğitimin **aynı iş olduğu** bilgisidir — ve o bilgi olmadan cevaplanamayan iki soru vardır: ortak masraf kime yazılacak, ve "bunlar aynı iş miydi" sorusu altı ay sonra nasıl cevaplanacak.

⚠ **Paketsiz planlama tam yetkili yoldur.** Tek eğitim planlayan biri paket görmez; paket, ikinci eğitim eklendiğinde doğar. Zorunlu bir sarmalayıcı değildir.

### 15.2 Paketin taşıdığı alanlar

| Alan | Neden pakette |
|---|---|
| Yer (il + adres) | Üç eğitim aynı salonda; ayrı ayrı girmek üç kez aynı şeyi yazmaktır |
| ~~Tarih aralığı~~ | **Sorulmaz, türetilir** — en erken başlangıç, en geç bitiş (aşağıdaki not) |
| Ortak masraf kalemleri | Uçak, otel, ulaşım — **tek işin masrafı**, bir eğitime yazılamaz |
| Not | Planlamacının kendi notu |

⛔ **Pencere sorulmaz, hesaplanır** *(Sets, 30.07.2026 — düzeltme)*. Paketin tarihi altındaki eğitimlerin **en erken başlangıcı ve en geç bitişi**dir: 03–04 IMDG, 05 TMGD, 06–07 Gözetim → pencere 03–07.

İlk yazımda pencere bir **alandı** ve bu iki yönden yanlıştı: (a) sistemin zaten elinde olan bir bilgiyi kullanıcıya yazdırıyordu, (b) *"bu eğitim pencerenin dışında"* diye bir ret icat ediyordu — ve o ret yalnızca soru sorulduğu için vardı. Türetilmiş pencere tanımı gereği hepsini kapsar; kural da hata mesajı da ortadan kalkar.

⚠ Pencere yine de **pakette saklanır**. Liste ekranları ve satış tarafı onu eğitimlere dokunmadan okur; her sorguda yeniden hesaplamak ucuz soruyu pahalı yapardı. Bu yüzden onu oynatabilen iki olayda yenilenir: planlama, ve bir eğitimin tarihinin değişmesi (`UpdateTrainingPlan`).

### 15.3 Ortak masraf ve iki mali tablo

Ortak masraf kalemi pakete yazılır, eğitime değil.

**Karar (Sets, 29.07.2026):** mali tablo **iki düzeyde birden** görülebilmelidir.

| Görünüm | Ne toplar | Nerede |
|---|---|---|
| **Paket mali tablosu** | Ortak masraf + altındaki her eğitimin kendi kalemleri | Paket detayı |
| **Eğitim mali tablosu** | Eğitimin kendi kalemleri + paket masrafından **payı** | Eğitim detayı (§8) |

Eğitim düzeyinde paket masrafı **kontenjan oranında** dağıtılır ve dağıtıldığı **ekranda yazar** — türetilmiş bir sayının türetilmiş olduğu gizlenmez.

```
Paket PR-2026-7K4F                     Eğitim EG-2026-7K4F-01 (5/30 koltuk)
  Ortak:  uçak 4.200 · otel 6.800        Kendi:   eğitmen ücreti  9.500
          ────────── 11.000              Paket payı (5/30)        1.833  ← türetilmiş
  EG-0311 eğitmen        9.500                    ──────────────────────
  EG-0312 eğitmen        9.500                    toplam          11.333
  EG-0313 eğitmen       11.000
          ──────────────────────
          toplam        41.000
```

⛔ **Dağıtım bir gösterim kuralıdır, kayıt değil.** Kalem pakette durur; hiçbir eğitim onun sahibi değildir. Payı bir kalem olarak eğitime yazmak, aynı masrafı iki yerde saymaya ve paket iptal edildiğinde öksüz satır bırakmaya açılırdı.

⚠ Oran **kontenjandır, kesinleşen koltuk değil.** Kesinleşen sayı satış boyunca değişir; her satışta geçmiş maliyet tablosunun değişmesi, aynı ekrana iki gün arayla bakan birine sistemin yalan söylediğini düşündürür.

### 15.4 Paket iptali

Paketin kendi iptali yoktur. İptal her zaman eğitim düzeyindedir (§11). Paketteki son eğitim de iptal edildiğinde paket **kendiliğinden kapanır** — ayrı bir onay istemez, çünkü iptal edilecek bir şey kalmamıştır.

⚠ Paketten bir eğitimi çıkarmak, o eğitimi iptal etmek demek değildir. Çıkan eğitim bağımsız olarak yaşamaya devam eder; yalnız ortak masraftaki payı düşer.

### 15.5 Eğitmen: paket düzeyinde sorulur, eğitim düzeyinde atanır

⛔ **Atama eğitim düzeyinde kalır** (`training_instructor_assignments` değişmez). Paketin eklediği şey aday listesinin sorusudur.

Aday listesi, paketteki her eğitim için **o eğitmenin o eğitimi verip veremediğini** ayrı ayrı gösterir:

```
A. Yılmaz      ✓ IMDG G8   ✓ TMGD Yen.   ✓ Gözetim   → üçü de
M. Demir       ✓ IMDG G8   —  TMGD Yen.  ✓ Gözetim   → ikisi
K. Aydın       —  IMDG G8   —  TMGD Yen.  ✓ Gözetim   → biri
```

**Gerekçe (Sets, 29.07.2026):** *"4'lü eğitim veriyoruz, 3'ünü bir eğitmen verebiliyor, bir eğitim için kaptan istiyor bu yüzden onu başkası veriyor."* Çoğunlukla tek eğitmen tümünü verir, ama bu da gerçek senaryo. "Hepsini verebilen kim" sorusunu tek satırda cevaplayan bir liste, dördüncü eğitim için başkasını seçmeyi de engellememelidir.

Bir teklif birden fazla eğitimi kapsayabilir: `training_instructor_offers` bir **eğitim kümesine** gider, kabul edildiğinde kümedeki her eğitim için ayrı atama satırı doğar. Kabul hâlâ atomiktir (§8, `egitmen-spec.md` §6.4) — kümenin tamamı ya kabul edilir ya hiçbiri.

⚠ Bir eğitim şartı taşımayan eğitmene teklif edilemez. Küme, kesişimdir: teklif yalnız eğitmenin **verebildiği** eğitimleri içerir.

### 15.6 Bakanlık bildirimi pakete rağmen eğitim başınadır

**Karar (Sets, 29.07.2026):** *"paket de olsa eğitim bakanlığa bildirilecek ve sonrasında bakanlık id'si sisteme girilecek."*

⛔ **Bildirim paketlenmez.** KUMS kaydı eğitimin kendisine açılır, dönen referans o eğitime yazılır. Bir pakette üç eğitim varsa üç ayrı bildirim ve üç ayrı referans vardır.

⛔ **Bildirim planlama formunun parçası değildir.** Ayrı bir süreçtir ve **her noktada yapılabilir** — planlamacı eğitimi kurar, sonra KUMS'a girer, dönen kaydı eğitim detayından işler. Formu bildirim beklemek üzere kilitlemek, planlamayı planlamacının kontrolünde olmayan bir dış sisteme bağlardı.

⚠ **Son tarih eğitim tanımından gelir, koda yazılmaz** (AD-27, kırmızı çizgi 14). Sets'in cümlesindeki *"3 gün öncesine kadar"* bir örnektir; gerçek değer o eğitimin `notification_days` alanıdır ve eğitim başına değişir. Bildirim görevi bu değere göre açılır (§10.3).

⚠ Bildirimden sonra planı değiştirmek KUMS güncellemesi doğurur (§10). Bir eğitimin tarihi değişince yalnız **o eğitim** için doğar — pencere türetilmiş olduğu için kendiliğinden kayar ve kimseye ayrıca bildirilmez; bildirilen şey eğitimin tarihidir, paketin değil.

---

## 16. Planlama ekranı

### 16.1 Tek sayfa, adım yok

⛔ **Sihirbaz kaldırıldı.** Yerine tek sayfalık bir form: her şey aynı anda görünür, hiçbir şey bir sonraki adımın arkasında saklanmaz.

**Gerekçe (Sets, 29.07.2026):** planlamacının işi kesintili. Beş adımlı formda birinci adımda ne seçtiğini beşincide hatırlamaz; telefondan dönen biri ekranı olduğu gibi bulur.

⚠ Tasarımdaki stepper bileşeni **silinmez** — `01 Form Elemanlari`'nde tanımlı ve başka akışlarda (katılımcı kaydı, teklif) kullanılacak. Kaldırılan, onun bu ekrandaki kullanımıdır.

### 16.2 Ekranın omurgası

```
┌─ 1. Mevzuat ────────────────────────────────────────────┐
│  Mevzuat: [ Tehlikeli Madde Güvenlik Danışmanlığı  ▾ ]  │  ← kapsamı daraltır
├─ 2. Eğitimler ──────────────────────────────────────────┤
│  [ 🔍 eğitim ara…                                    ]  │  ← searchable, mevzuatla süzülü
│  ✓ IMDG Görev 8       kontenjan [  5 ]  tarih [03–04]   │
│  ✓ TMGD Yenileme      kontenjan [ 10 ]  tarih [  05  ]  │
│  ✓ Gözetim Temel      kontenjan [ 15 ]  tarih [06–07]   │
│  + eğitim ekle                                          │
├─ 3. Yer ────────────────────────────────────────────────┤
│  İl [ Hatay ▾ ]  Adres [ İskenderun Limanı Eğt. Salonu ]│
│  Program penceresi: 03–07 Eylül · 5 gün  ← hesaplanıyor  │
├─ 4. Görünürlük ─────────────────────────────────────────┤
│  ( ) Açık   (•) Kapalı → firmalar [ ✓ ARKAS ] [ + ]     │
├─ 5. Eğitmen (opsiyonel) ────────────────────────────────┤
│  Aday listesi — kim hangisini verebilir                 │
├─ 6. Ortak masraf (opsiyonel) ───────────────────────────┤
│  Uçak 4.200 · Otel 6.800                                │
└─────────────────────────────────────────────────────────┘
              [ Taslak olarak kaydet ]  [ Satışa aç ]
```

⚠ Numaralar **bölüm başlığıdır, adım değildir**. Hepsi aynı anda açıktır, sırasız doldurulabilir, hiçbiri bir sonrakini kilitlemez.

### 16.3 Mevzuat önce sorulur

Katalog büyür; mevzuat seçimi listeyi kullanılabilir tutar. **Gerekçe (Sets):** *"ilk soru hangi mevzuat olmalı, bu kapsamı daraltıyor."*

⚠ Mevzuat **süzgeçtir, kilit değildir.** Farklı mevzuatlardan eğitim aynı pakete girebilir — sahada bir haftalık programın iki ayrı yönetmelikten eğitim taşıması olağandır. Mevzuat değiştirildiğinde seçilmiş eğitimler listeden düşmez.

### 16.4 Eğitim seçimi aranabilir olmalıdır

`SearchableSelect` kullanılır (mevcut bileşen). Düz açılır liste, elli kalemlik bir katalogda kullanılamaz.

### 16.5 Mevzuat uyarıları alan kenarında

§8.1'in kuralı değişmez: azami katılımcı sert, gerisi uyarıdır. Tek sayfada uyarı **kendi eğitiminin satırında** gösterilir — hangi eğitim hakkında olduğu belirsiz kalmaz.

---

---

## 17. Kabul kriterleri

Plan aşaması neyin kanıtlanacağını buradan okur. Her satır gözlemlenebilir bir davranıştır.

| # | Kriter |
|---|---|
| P-1 | Eğitim tanımı olmadan eğitim kaydı oluşturulamaz (§1) |
| P-2 | Kapalı eğitim yalnız listelenen firmalara görünür; açık eğitim görünürlük alanıyla ayırt edilir, boş firma listesiyle değil (§2) |
| P-3 | `draft` → `planned` geçişinde referans kodu `PL-`'den `EG-`'ye döner, **rastgele son ek korunur**; eski kod aynı kayda yönlendirir (§3, AD-19) |
| P-4 | Maliyet eşiği onay gerektiren eğitim onaysız `planned` olamaz (§4.1, `egitmen-spec.md` §7.4) |
| P-5 | O eğitim için **teklif kaydı açılmışsa** geri çekme reddedilir; açılmamışsa geri çekme alınmış onayı düşürür (§4.3) |
| P-6 | `capacity`, eğitim tanımındaki azamiyi aşacak şekilde kaydedilemez; aşağı çekilebilir (§5.1) |
| P-7 | `confirmed_seats > capacity` **veritabanı seviyesinde** reddedilir; eşzamanlı iki rezervasyondan yalnız biri geçer (§5.3) |
| P-8 | `named_seats < confirmed_seats` olduğunda uyarı üretilir ve bakanlık bildirimi ekranında görünür (§5.2) |
| P-9 | Kapasite dolu eğitime yapılan talep yedek listesine girer, kontenjanı **işgal etmez**; terfi yalnız insan kararıyla olur (§6) |
| P-10 | Asgari katılımcı altındaki eğitim uyarı üretir, hiçbir geçişi engellemez (§5.5) |
| P-11 | Talep kaydı teklife dair hiçbir alan taşımaz; karşılandığında `planned` olur ve karşılayan eğitime bağlanır (§7) |
| P-12 | Şartı eksik eğitmen aday listesinde **görünmez**; şart eğitmenin seçtiği eğitimlerden türer, ayrıca işaretlenmez (§9) |
| P-13 | Bir şart, kabul edilen belge türlerinden **herhangi biriyle** karşılanır (§9.2) |
| P-14 | Atama kesinleştiğinde eğitmenin ilgili belgelerinin **dosyaları** eğitime kopyalanır; eğitmen tarafındaki değişiklik kopyayı etkilemez (§9.4) |
| P-15 | Bildirim tipi ve süresi eğitim tanımından okunur; kodda gün sayısı yoktur (§10.1) |
| P-16 | `approval` tipinde onay kanıtı olmadan eğitim başlatılamaz (§10.4, DG-2020 md.14/8) |
| P-17 | Bildirilmiş eğitim `draft`'a geri çekilemez (§10.5) |
| P-18 | Katılımcı listesi bildirimden sonra değişirse *"KUMS güncellemesi gerekli"* bayrağı çıkar ve güncelleme kaydedilmeden `in_progress`'e geçilemez (§10.5) |
| P-19 | İptal gerekçesiz talep edilemez ve onaysız gerçekleşmez; onay yetkisi kapsamı AD-23'ten gelir (§11.1) |
| P-20 | Bildirilmiş eğitimin iptalinde bildirim görevi açılır; görev kapanmadan iptal tamamlanmaz (§11.2) |
| P-21 | İptal edilen eğitim silinmez, `cancelled` statüsünde durur (§11.3, AD-11) |
| P-22 | Çakışma yalnız kesinleşmiş eğitmen atamasına bakar; aynı yer + aynı tarih engellenmez (§8.2) |
| P-23 | Tedarikçi fiyat teklifleri il bazında sorgulanabilir (§12) |
| P-24 | Planlamacı, kapsamı dışındaki eğitimi göremez ve değiştiremez (§13, AD-23) |
| P-25 | Yapılış biçimi kaydedilir ve hiçbir davranışı değiştirmez (§1.4) |
| P-26 | `pending_seats` toplamı aşabilir ve hiçbir geçişi engellemez; sert sınır yalnız `confirmed_seats`'tedir (§5) |
| P-27 | Kalan yerden fazla onay geldiğinde müşteri onayı **kaydedilir** ve tahsis "kontenjan teyidi" durumuna düşerek kuyruğa girer; sistem kimin gireceğini seçmez (§5.4) |
| P-28 | Eğitim, verildiği mevzuat sürümünü ve müfredat sürümünü saklar; tanım sonradan güncellenince bu kayıt değişmez (§1.2) |
| P-29 | Eğitimin zorunlu evrakı eksikse operasyon yöneticisine görev düşer (§1.3, AD-24) |
| P-30 | Eğitim günü gelmeyen katılımcı devamsızlık kaydı üretir, yedek terfi akışını tetiklemez (§6.1) |
| P-31 | Yedek listeden çağırma gerekçesiyle birlikte audit'e yazılır (§6) |
| P-32 | Kontenjan sayıları satışçıya görünür, hangi teklifin kime ait olduğu görünmez (§5) |
| P-33 | Gece vardiyası ve TMGD koordinasyon uyarıları planlama ekranında görünür, hiçbir şeyi engellemez; metinleri mevzuat kaydından gelir (§8.1) |
| P-34 | Uyarıya rağmen verilen onay engellenmez ve audit satırında **uyarının gösterildiği** okunabilir (§8.1) |
| P-35 | Kapalı eğitimi yalnız listelenen firmalara atanmış satışçılar, kapsamı yeten yöneticiler ve planlamacı görür (§2.3) |
| P-36 | Çoklu kurumsal eğitimde bir firmanın kullanıcısı listedeki diğer firmaları **göremez** (§2.3) |
| P-37 | Satışçı yedek listenin sıra ve toplamını görür, hangi firmanın sırada olduğunu göremez; talep kuyruğunda yalnız atandığı firmaların taleplerini görür (§2.3) |
| P-38 | Taslak onaysız `abandoned` yapılabilir; `planned` ve sonrası yalnız onaylı iptalle sonlanır; `completed` hiç iptal edilemez (§4.4, §4) |
| P-39 | İptal talebi reddedilirse kayıt geldiği statüye döner ve ret gerekçesi audit'te kalır (§4) |
| P-40 | Bildirim son tarihi yaklaşırken `training.notify_ministry` taşıyanlara **görev** açılır; tarih geçtiğinde görev yükselir ve alert üretir (§10.3) |
| P-41 | Kanıt seti kopyaları orijinalle aynı erişim rejimine tabidir; eğitimi görme yetkisi kanıt setini açmaya yetmez, erişim loglanır (§9.6) |
| P-42 | Kanıt setinin saklama tabanı eğitim tanımının `record_retention_years` alanından okunur; kodda sabit yıl yoktur (§9.5) |
| P-43 | Tanımda azami sayı boşsa 3E'nin genel tavanı uygulanır; bu tavan aşılabilir ve onaya gider — mevzuattan gelen tavan aşılamaz (§5.1) |
| P-44 | Tek sayfalık planlama formu; adım yok, hiçbir bölüm bir diğerini kilitlemez |
| P-45 | İlk alan mevzuat; eğitim listesi ona göre süzülür ama süzgeç değiştirilince seçilmişler düşmez |
| P-46 | Eğitim seçimi aranabilir |
| P-47 | Bir formda birden fazla eğitim planlanabilir; ikinci eğitim eklendiğinde paket doğar |
| P-48 | Paket `PR-YYYY-XXXX` taşır *(AD-19, 31.07.2026 revizyonu — `PK` değil)*; altındaki her eğitim **programın son ekini + sırasını** taşır (`EG-YYYY-XXXX-NN`), programsız eğitim düz `EG` kodunu korur |
| P-49 | Paket penceresi eğitim tarihlerinden türetilir; ayrı bir alan olarak sorulmaz *(30.07.2026 revizyonu)* |
| P-50 | Ortak masraf pakete yazılır; eğitim başına maliyet **türetilmiş** olduğu yazılarak gösterilir |
| P-51 | Aday listesi her eğitim için ayrı ayrı "verebilir/veremez" gösterir |
| P-52 | Bir teklif birden fazla eğitimi kapsar; kabul atomiktir, kümedeki her eğitim için atama doğar |
| P-53 | Paket görünürlük taşımaz; aynı pakette açık ve kapalı eğitim bulunabilir |
| P-54 | Mali tablo iki düzeyde okunur: paket toplamı, ve eğitim başına (payı türetilmiş olarak işaretli) |
| P-55 | Bakanlık bildirimi eğitim başınadır, formun dışındadır, tanımın kendi süresine kadar her an yapılabilir |
| P-56 | Bir eğitimin tarihi değişince o eğitim için KUMS güncellemesi doğar; paket penceresi kendiliğinden kayar |

---

## 18. Kapsam dışı — adresi yazılı

| Ne | Nerede yapılacak |
|---|---|
| Teklif kaydı ve satış akışı | EGT-26 (Spec 6) — bu spec kontenjan sözleşmesini tanımlar, teklif tablosunu değil |
| Katılımcı listesi yönetimi, yoklama, sınav | EGT-27 (Spec 7) — `training_participants` var, `training_id` FK'sı bu turda kapanır |
| Masraf onayı, eğitmen carisi | `egitmen-spec.md` §7.6–7.8, mali tur |
| Açık eğitim duyuru sistemi | Çatı §67 — satış turu |
| Tedarikçi portalı | Tasarımın kendi notu: "sonraki faz" |
| Müşterinin kendi organizasyonu, lokasyonları | Müşteri portalı turu |
| Ofis tarafı müşteri yönetimi | Spec turu yok — doğrudan plana *(Sets, 29.07.2026)*; planlamanın kapalı eğitimi firmaya bağlaması buna dayanır |

---

## 19. Açık kalanlar

| # | Ne | Not |
|---|---|---|
| 1 | **İl listesi** | `option_lists`'te tanımlı değil; bu turda eklenir, içeriği backoffice'te yönetilir (§1.1) |
| 2 | **Donmuş kanıt setinin saklama ÜST sınırı** | Taban çözüldü — eğitim tanımının `record_retention_years` alanından okunur, aile bazlı (§9.5). Açık kalan yalnız üst sınır: kopyalar kişisel veridir ve çoğalırlar, KVKK açısından bir tavan belirlenmelidir |
| 3 | **Çevrimiçi eğitimin mevzuat durumu** | Biçim bugün yalnız bilgi alanı; kural yazılmadan önce `mevzuat/` taranmalı (§1.4) |
| 4 | ~~**Resmî tatil takvimi**~~ | ⛔ **Kapandı, yapılmayacak** *(Sets, 18.08.2026, EGT-43 Won't fix)*. Süreler takvim günü sayılır; "iş günü" diye ayrı bir hesap yoktur. `egitmen-spec.md` §11/3 aynı kararla kapandı |
| 5 | **Katalogdaki `instructor_requirement` serbest metin alanı** | §9'un yapılandırılmış bağı geldikten sonra gereksiz kalabilir; temizliği implementasyon turunda değerlendirilir |

---

## 20. Revizyon geçmişi

| Sürüm | Tarih | Değişiklik |
|---|---|---|
| v1.0 | 29.07.2026 | İlk sürüm. Sets'in planlama turu kararları, 34 kabul kriteri, 5 açık kalan. |
| v1.1 | 29.07.2026 | Heyet review 165 **APPROVED**. Review 164 (REJECTED) bulgularının kapanışı. **F-1:** Y-2016 md.7/2 alıntısı düzeltildi — "uzakyol" nitelemesi zorunludur, üç alternatif şart tablosu eklendi (§9.2). **F-2:** saklama tabanı tek mevzuata bağlıydı, eğitim tanımının alanına taşındı (§9.5). **F-3/F-4:** kapalı eğitim, yedek liste, talep kuyruğu ve çoklu kurumsal firma listesinin görünürlüğü tanımlandı (§2.3). **F-5:** statü makinesi tamamlandı — `abandoned`, ret dönüşü, `completed` kilidi (§4, §4.4). **F-6:** ilk bildirim için son tarih görevi (§10.3). **F-8:** kanıt setine erişim rejimi (§9.6). Ayrıca tavansız eğitimlerde varsayılan kapasite (§5.1). P-35…P-43 eklendi. |
| v1.2 | 29.07.2026 | Sets'in üç itirazı. **Sihirbaz kaldırıldı** — planlamacının işi kesintili, beş adımlı formda birinci adımda ne yaptığını beşincide hatırlamıyor; yerine tek sayfa (§16). **Mevzuat ilk soru**, eğitim seçimi aranabilir (§16.3–20.4). **Planlama paketi** eklendi (§15): kendi kodlu kayıt (`PK`), talep üzerine veya ihtiyaçtan kurgulanan iki yol, ortak masraf ve iki düzeyli mali tablo, eğitmen paket düzeyinde sorulur eğitim düzeyinde atanır, bakanlık bildirimi pakete rağmen eğitim başına kalır. P-44…P-56. |
| v1.3 | 30.07.2026 | Sets'in iki düzeltmesi. **Paket penceresi artık sorulmuyor, türetiliyor** (§15.2, P-49, P-56): alan olarak sorulması sistemin elindeki bilgiyi kullanıcıya yazdırıyordu ve *"pencere dışında"* diye yalnızca soru sorulduğu için var olan bir ret icat ediyordu. Ekrandan ikinci takvim kalktı (§16.2). Ayrıca **native `<input type="date">` kullanımı yasak** — kendi takvim bileşenimiz varken tarayıcının takvimini getirmek bileşen dilinde ikinci bir dil açar; klavye erişimi grid'e roving tabindex ile verildi. |