# Re-review — Eğitmen, Ücretler ve Eğitmen Ataması Spec (`docs/specs/egitmen-spec.md`) — 2026-07-28 · R2

> **Review type:** spec-review (re-review)
> **Previous review:** `docs/reviews/review-egitmen-spec-2026-07-28.md` — REJECTED, 14 bulgu
> **Upstream document(s) read:** `cati-dokumani.md` (§185 revizyonu dahil) · `docs/mevzuat-kurallari.md` · `docs/specs/fiyatlama-spec.md` · `docs/arch/mimari-kararlar.md` (**AD-09, AD-19, AD-23 revizyonları bu turda ayrıca denetlendi**; AD-20 önceki tur) · `docs/specs/ofis-onyuz-spec.md`
> **Other cross-referenced documents:** Y-2016 ve YÖN-2019 resmî PDF'leri (md.8/1 atıf düzeltmesi metinle yeniden karşılaştırıldı) · `config/reference_codes.php` · `app/Support/Business/DiscountCeiling.php` · YouTrack **EGT-58** (var: *"DiscountCeiling AD-09 genisletme kuralina uymuyor"*, Bug/Submitted — doğrulandı) · EGT-43 (AD-23:358'de kayıtlı)
> **Stage locks in effect:** None

---

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

Hepsi dokümanın kendisinden doğrulandı, cevap metninden değil.

| # | Durum | Kanıt |
|---|---|---|
| F-1 (AD-09 çelişkisi) | **Kapandı** | AD-09 revize: `mimari-kararlar.md:95-101` — daraltma doğrudan, genişletme onaya; kapsam sınırı (tenant/AD-02 ve "backoffice üretir ofis tüketir" değişmedi) yazılı; `DiscountCeiling` uyumsuzluğu hem AD-09:101 hem spec §7.4'te **EGT-58**'e adreslendi (ticket YouTrack'te doğrulandı). Spec §7.4 "Daraltma serbest, genişletme onaya gider" tablosu AD ile birebir. ⚠ Kalan küçük ifade kayması → R2-5 |
| F-2 (md.7/3 → md.8/1) | **Kısmen kapandı** | Atıf düzeltildi: spec:45 **Y-2016 md.8/1** — resmî metinle yeniden karşılaştırıldı, örtüşüyor; belge süresi satırı md.7/3'te kaldı, doğru. ⚠ §2 **giriş cümlesi** (spec:37) hâlâ *"aşağıdakilerin hepsi resmî metinden doğrulanmıştır"* diyor — düzeltildiği belirtilmişti, metin v1 ile birebir aynı → R2-1 |
| F-3 (`selection` yaşam döngüsü) | **Kapandı** | spec:155-168 dört-soru tablosu: kontenjanı seçim kapatır, `not_selected` terminal (§6.12'ye eklendi, spec:269), takvim bloğu seçimde, çakışma+uygunluk kabulde **ve** seçimde, seçilmeyene bildirim. ⚠ §6.5 ile yeni tablo arasında çakışma-kaynağı belirsizliği doğdu → R2-2 |
| F-4 (yenileme penceresi) | **Kapandı** | spec:247-258 — `reconfirming` (durum sözlüğüne eklendi, spec:270), satılabilirlik düşer, blok sürer, cevapsızlık işler, ret → düşer + eskalasyon; satılmış eğitimde satış dahil üç tarafa ALERT |
| F-5 (onayın katılımcıları) | **Kapandı** | spec:352-358 "Onay nereden yürür": AD-23 motorunun kayıt tipi, `planning.approve`, ekran §9:548. AD-23 revizyonu (`mimari-kararlar.md:339-358`) ortak omurga / ayrı havuz tablosuyla tutarlı |
| F-6 (çifte sayma) | **Kapandı — kök çözümle** | spec:383-398 `paid_by_company` / `paid_by_instructor`; mükerrerde onaylayan reddeder, otomatik mahsup yok, gerekçesi yazılı; §7.8 ekranı planlanan kalemleri ödeme sorumlusuyla + o ana kadar onaylanmış masrafları gösteriyor (spec:454-463). ⚠ K-17 ile §7.6 gövdesi arasında nitelik farkı → R2-3 |
| F-7 (görünürlük matrisi) | **Kapandı** | spec:485-500 — 8 rol, AD-23 ağacının adları (spec:485); §3.2, §6.7, §7.5 rol adları hizalandı; kabul öncesi katılımcı **sayısı** / kabul sonrası **listesi** ayrımı §6.9 tablosuyla (spec:229-237) ve K-10 ile tutarlı |
| F-8 (AD-23 havuzu) | **Kapandı** | spec:170-180 — aday listesi iki filtrenin kesişimi; AD-23 alıntısı doğru; planlamacı başına "havuzum/tümü" ayarı; İzmit örneği |
| F-9 (paralel sorumlu alanı) | **Kapandı — geri çekildi** | spec:178 ve spec:442-446 — ağaca paralel ikinci alan **açılmaz**, tek cevap AD-23 kapsam çözümleyicisi; ağacın bugün kodda olmadığı ve kullanıcı oluşturma turunun işi olduğu ön koşul olarak yazılı (migrations kontrolü hâlâ doğru) |
| F-10 (hassas veri) | **Kapandı** | spec §2.1 (50-59): AD-05 şifreleme, AD-21 erişim logu, maskeli gösterim, "kaydı görme ≠ hassas alanı görme"; K-24; ekran satırı "hassas veri (maskeli, §2.1)" (spec:541) |
| F-11 (cari ödeme) | **Kapandı** | spec §7.7 (402-425): cari türetilir, elle borç açılmaz; ödeme kaydı kalem seçimli (30.000/3.000/6.000 örneği), yetkiye bağlı, audit'li (AD-06), silinmez — iptal/düzeltme (AD-11); K-21, K-22, K-25 |
| F-12 (kabul kriterleri) | **Kapandı** | spec §10 — K-1…K-25, hepsi gözlemlenebilir davranış; §6, §7, §8'in test edilebilir iddialarını kapsıyor. ⚠ K-17'nin ifadesi → R2-3 |
| F-13 (çatı §185) | **Kapandı** | `cati-dokumani.md:185` revizyon notu (Sets, 28.07.2026): üçüncü katmanın yeri planlama; spec §4.4 revizyonu ve gerekçeyi taşıyor; matris "maliyeti değiştiremez" (spec:493); K-23 |
| F-14 (yetkinlik kapısı) | **Kapandı** | spec §3.1 (69-80): yetkinlik kapısı uygunluk bayrağı, *"veremez"* gerekçesiyle kapı olarak tanımlı; veri modeli §11/2'ye adresli; "model gelene kadar kapı çalışmaz — sıralama" dürüstlüğü yerinde; K-1 |
| Notlar (atıflar) | **Kapandı** | Başlık satırı gerçek referanslarla (spec:3); "çatı 2. tur karar #7" (spec:461) |

**Open question cevapları:** 1 (PL→EG, aşağıda ayrıca denetlendi), 2 (`escalated` + alert, spec:215-219), 3 (süre teklif başına, spec:211), 4 (AD-09 revizyonuyla çelişki kalktı), 5 (matris rol rol) — beşi de dokümanda karşılığını buldu.

---

## Upstream Coverage Matrix (yeniden üretildi)

| Upstream § / madde | Durum | Kanıt |
|---|---|---|
| çatı §5 (açık eğitim, N teklif) | ✓ | spec §8.3 |
| çatı §105–106 (planlamasız teklif yok; çoklu eğitmen planlamacıda) | ✓ | spec §6.1, §6.11; §8.3'ün "planlama onaylanmadan eğitim oluşmaz" okuması çatı §105'in draft/planlanmış ifadesine bağlanmış |
| çatı §172 (yetkinlik kontrolü; maliyetler eğitime işlenir) | ✓ | spec §3.1 (kapı) + §7 |
| çatı §174 (kategoriler + roller) | ✓ | spec §1.1; §8.2 matrisi 8 rol, AD-23 adlarıyla |
| çatı §181 (fiyat/maliyet ayrımı) | ✓ | spec §4.4 gerekçesi + §8.2 |
| çatı §185 (üç katman — **revize edildi**) | ✓ | `cati-dokumani.md:185` revizyon notu ↔ spec §4.4 birebir. Nit: spec §4 girişindeki alıntı (spec:94) çatının revize **öncesi** metnini taşıyor |
| çatı §187 (masraf kuralları, cari, ödendi takibi) | ✓ | spec §5, §7.6–7.8; ödeme kaydı artık tanımlı (§7.7) |
| çatı §219 / Y-2016 md.13/j | ✓ | spec §1.2 (önceki turda doğrulanmıştı, değişmedi) |
| Y-2016 md.7/3 · md.7/5 · **md.8/1** | ✓ | spec §2 — md.8/1 atfı resmî metinle örtüşüyor (PDF'ten yeniden karşılaştırıldı). ⚠ §2 giriş cümlesi iki çatı-kaynaklı satırı hâlâ "resmî metinden doğrulanmış" sayıyor — R2-1 |
| YÖN-2019 md.6/3-5 | ✓ | spec §1.2, §2, §3.1 — "veremez" kapı olarak kuruldu |
| fiyatlama-spec §1 · §4.2 | ✓ | spec §4.1; §7.5 kalem/toplam çift kontrol gerekçesi |
| **AD-09 (revize: genişletme → onay)** | ⚠ | Revizyon tutarlı ve sınırları çizilmiş (`mimari-kararlar.md:95-101`); spec §7.4 birebir uyumlu; EGT-58 açık ve iki yerde adresli. Kalan: "yalnız **sayısal** parametreler" ifadesi kuralın kendi uygulamalarından dar — R2-5 |
| AD-11 / kırmızı çizgi 12 | ✓ | spec §6.12, §7.7 (ödeme silinmez), §7.8; K-25 |
| AD-14 (onay yalnız panelden) | ✓ | spec §6.13 — in-app kabul, mail yalnız çağırır; AD-20 sınır 1 ile aynı çizgi |
| **AD-19 (revize: PL→EG istisnası)** | ⚠ | İstisnanın amacı korunmuş (aşağıda değerlendirme); `PL` rezerve. Kalan: `training` için config'de kayıtlı **bağımsız** kod üretimiyle bir arada yaşama kuralı ve dönüşüm anı çakışması tanımsız — R2-4 |
| AD-20 (kayda bağlı yazışma) | ✓ | spec §8.3 "Kanal referans koduyla çözülür": aynı catch-all, ön ek ayrımı, yeni subdomain/Postmark server yok — AD-20'nin kurgusu ve kısıtıyla uyumlu; önceki open question kapandı |
| AD-21 / kırmızı çizgi 13 | ✓ | spec §2.1, §6.9, §7.8 |
| **AD-23 (revize: onay omurgası + havuzlar)** | ✓ | `mimari-kararlar.md:339-358` ortak/ayrı tablosu ↔ spec §7.4 "Onay nereden yürür" tutarlı; havuz §6.3; `approve_group` çözümleyicisi §7.8; dört göz/silsile/1 iş günü omurgadan |
| AD-05 | ✓ | spec §2.1 |
| AD-08 / AD-27 / kırmızı çizgi 14 | ✓ | değişmedi; §6.10 sabiti bilinçli, gerekçeli |
| AD-25 / AD-26 / AD-28 | ✓ | spec seviyesinde yükümlülük doğurmuyor |
| ofis-onyuz-spec | ✓ | spec §1 değişmedi |
| Spec tanımı — ölçülebilir kabul kriterleri | ⚠ | §10 var, 25 kriter, ölçülebilir; K-17'nin ifadesi çifte sayan bir implementasyonu geçirir — R2-3 |

---

## ✅ What works (bu turda eklenenler)

- **Kapanışların hiçbiri yüzeysel değil.** F-6 semptomu yamamak yerine kök çözüme gitti (`paid_by_instructor` ayrımı carinin doğruluğunu da beraberinde kuruyor); F-9 geri çekildi ve tek-çözümleyici kuralı ⛔ ile sabitlendi; F-11 "cari türetilir, girilmez" ilkesiyle elle-borç sınıfı hatayı yapısal olarak kapattı.
- **Üç AD revizyonu da gerekçeli, sınırlı ve çapraz-tutarlı:** AD-09 revizyonu neyi değiştirmediğini açıkça sayıyor ve bugünkü kodun uyumsuzluğunu saklamak yerine EGT-58'e bağlıyor (ticket gerçekten açılmış — doğrulandı); AD-23'ün ortak-omurga/ayrı-havuz tablosu sapma riskini doğru yerinden tutuyor; AD-19 istisnası "tek istisna" olarak adlandırılmış ve `PL` rezerve edilmiş.
- **§6.13 (in-app kabul) doğru eklenmiş:** AD-14 ve AD-20 sınır 1'in mevcut çizgisine oturuyor; kabulün delil değeri gerekçesi yerinde; K-12 ile ölçülebilir.
- **§10 kabul kriterleri** plan aşamasının okuyacağı biçimde: her satır gözlemlenebilir, kriterler spec'in ⛔ satırlarını bire bir yakalıyor (K-3 atomiklik, K-14 genişletme-onaya, K-20 kendi masrafı, K-25 silinmezlik).
- **PL→EG kurgusu** open question'ı zarif kapatıyor: sıfır yeni altyapı, eski adres ölmüyor, planlama geçmişi kod üzerinden taşınıyor.

---

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

**R2-1 — §2 giriş cümlesi düzeltilmemiş (F-2'nin ikinci yarısı).** `spec:37` hâlâ *"Aşağıdakilerin hepsi `mevzuat/` içindeki resmî metinden doğrulanmıştır"* diyor — v1 ile birebir aynı cümle. Tablonun iki satırının kaynağı yalnız çatıdır (§11 Bakanlık eğitmen onayı, §14 CTU/CSS evrakları) ve mevzuat maddesi taşımaz; cümle tabloyu olduğundan güçlü gösteriyor. Re-review talebi bu cümlenin düzeltildiğini söylüyor; dokümanda düzeltme yok.

**R2-2 — Çakışma kontrolünün kaynağı iki bölümde farklı: seçim bekleyen kabul çakışma üretir mi?** §6.2 tablosu (`spec:164`) `selection` modunda takvim bloğunun **seçimde** başladığını söylüyor; §6.5 (`spec:192`) ise kabul anındaki çakışma kontrolünü *"eğitmen çakışan tarihli başka bir eğitimi **kabul etmişse**, ikinci kabul reddedilir"* diye kuruyor — koşulu blok değil, kabul. Eğitmen A eğitimini `selection` modunda kabul etmiş ve seçim bekliyorken çakışan B eğitimini kabul etmek isterse: §6.5'in lafzına göre reddedilir (o zaman seçim bekleyen kabul fiilen takvim bloklar — §6.2 tablosuyla çelişir), §6.2'nin ruhuna göre kabul edilir (o zaman K-4'ün "çakışan tarihli ikinci kabul reddedilir" kriteri mod ayrımı olmadan yanlışlanır). Hangisinin doğru olduğu yazılmadan iki kriter (K-4, K-6) birlikte test edilemez.

**R2-3 — K-17 ile §7.6'nın çifte sayma kuralı çelişiyor.** §7.6 girişi (`spec:374-377`) onaylanan masrafın **koşulsuz** iki kayda düştüğünü söylüyor (*"1. Eğitimin maliyetine… 2. Eğitmenin carisine"*); çifte sayma alt bölümü (`spec:394`) ise `paid_by_instructor` kalemine karşılık gelen masrafın **eğitimin maliyetini artırmadığını** söylüyor — planlanan kalemin karşılığıdır. İki cümle karşılık durumunda aynı anda doğru olamaz ve K-17 (`spec:576`) niteliksiz olanı kriterleştiriyor: *"onaylanan masraf eğitim maliyetine ve eğitmen carisine birlikte yazılır."* K-17'ye harfiyen uyan bir implementasyon, spec'in çözmek için kurulduğu çifte saymayı aynen üretir ve kriteri geçer. Cariye her zaman / maliyete yalnız karşılıksızsa ayrımının hem §7.6 girişinde hem K-17'de nitelenmesi gerekir.

**R2-4 — AD-19 istisnası, `training`'in mevcut bağımsız kod üretimiyle bir arada yaşama kuralını tanımlamıyor.** `config/reference_codes.php:32` bugün `'training' => 'EG'` kaydıyla bağımsız bir EG üreticisi tanımlıyor; AD-19 istisnası (`mimari-kararlar.md:200`) ise eğitim kodunun PL'den **dönüşümle** geldiğini kuruyor. İki yol birlikte yaşarsa: bağımsız üretilmiş bir `EG-2026-7K4F` ile `PL-2026-7K4F`'ten dönüşen kod çakışabilir — üretimde çakışma "unique index + yeniden üretim" ile çözülüyor ama dönüşümde son ek **korunmak zorunda**, yeniden üretilemez; çakışan dönüşümün ne olacağı yazılmamış. Eğitim kayıtları yalnız plandan doğuyorsa bağımsız üreticinin emekliye ayrıldığı, doğmuyorsa çakışma kuralı — ikisinden biri AD'de söylenmeli. (İstisnanın **amaca** zararı yok: dış tarafın elindeki kod redirect ile geçerli kalıyor, rastgelelik korunuyor — o iddia doğru.)

**R2-5 — AD-09 revizyonunun kapsam cümlesi kendi uygulamalarından dar.** `mimari-kararlar.md:99`: *"Bu revizyon yalnız **sayısal** parametrelerin genişletilmesinin sonucunu değiştirir."* Oysa AD-23:353 aynı revizyonu *"planlamacının global onay kuralını gevşetmesi"*ne uyguluyor ve spec §7.4'ün genişletme örneği `always` → `never` — sayısal değil, seçenekli bir politika değeri. Kuralın gerçek sınırı "iş parametresi ↔ yetki/tenant sınırı" (AD-09:99'un ikinci yarısı bunu doğru söylüyor); "sayısal" kelimesi eşiği kapsayıp modu dışarıda bırakıyor ve iki AD aynı kuralın kapsamını farklı anlatıyor — bu projenin tam da kaçındığı belge kayması sınıfı.

### Nit'ler (blocker değil)

- `spec:94` çatı §185'i revize **öncesi** metniyle alıntılıyor (*"teklif/mali ekranda…"*); çatı satır 185 artık öyle demiyor. §4.4 düzeltiyor ama alıntı güncel metinle eşleşmiyor.
- §6.3'teki planlamacı başına "havuzum/tümü" ayarının yaşadığı ekran §9'da yok (Planlamacı ayarları satırı yalnız onay kuralı + eşiği sayıyor).
- `PL` prefix'i `config/reference_codes.php`'de henüz kayıtlı değil — implementasyon işi, spec engeli değil; plan aşamasında kapanış adresi verilmeli.

---

## ❓ Open Questions (to be answered before next stage)

1. R2-2'nin cevabı: çakışma kaynağı **kesinleşmiş atama + `first_accepted` kabulü** mü, yoksa seçim bekleyen `selection` kabulü de mi? (Hangisi seçilirse §6.2/§6.5/K-4/K-6 aynı dille yazılmalı.)
2. R2-4'ün cevabı: eğitim kaydı **her zaman** plandan mı doğar (bağımsız EG üretimi kalkar), yoksa dönüşüm çakışması için bir kural mı tanımlanır?

---

## Verdict: ❌ REJECTED

14 bulgunun tamamı ele alınmış ve 12'si dokümanda eksiksiz kapanmış durumda; üç upstream revizyonu (AD-09, AD-19, AD-23) gerekçeli, sınırlı ve büyük oranda çapraz-tutarlı — EGT-58 dahil verilen adreslerin hepsi gerçek. Kalan beş bulgu küçük ama üçü içerikli: R2-1 iddia edilen düzeltmenin yapılmamış olması, R2-2 atama akışının en kritik bölgesinde (çakışma) iki bölümün farklı kural söylemesi, R2-3 ise kabul kriterinin çifte sayan bir implementasyonu geçirecek olması — kriterlerin varlık sebebi tam olarak bunu engellemekti. R2-4 ve R2-5 AD revizyonlarının kapsam/eşzamanlılık cümleleri. Beşi de dar, hızla kapatılabilir düzeltmelerdir; kapatıldığında re-review'da matrix yeniden üretilecektir.