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

> **Review type:** spec-review
> **Previous review:** N/A (ilk review)
> **Upstream document(s) read:** `cati-dokumani.md` (tamamı; özellikle satır 61–67, 105–106, 172, 174, 181, 185, 187, 194, 219) · `docs/mevzuat-kurallari.md` (tamamı) · `docs/specs/fiyatlama-spec.md` · `docs/arch/mimari-kararlar.md` (AD-01…AD-28; AD-20 revizyonu dahil) · `docs/specs/ofis-onyuz-spec.md`
> **Other cross-referenced documents:** `CLAUDE.md` (kırmızı çizgiler) · `mevzuat/1-egitim/IMDG_Kod_Kapsaminda_Egitim_ve_Yetkilendirme_Yonetmeligi.pdf` (Y-2016 — md.6, 7, 8, 9, 13 metinden okundu) · `mevzuat/1-egitim/IMDG_Kod_Egitim_Seminerlerine_Iliskin_Yonerge.pdf` (YÖN-2019 — md.5, 6, 7, 8 metinden okundu) · depo doğrulamaları: `app/Support/Business/DiscountCeiling.php`, `config/authorization.php:13-15`, `app/Actions/Office/ChangeOfficeAccountStatus.php:95`, `database/migrations/` (grup/ekip tablosu yokluğu teyit edildi)
> **Stage locks in effect:** None (spec review — çatı design/brainstorm yok, upstream doğrudan çatı + AD'ler + mevzuat)

---

## Upstream Coverage Matrix

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| çatı §5 (eğitim türleri; açık eğitim = tek eğitim, N müşteri, N teklif) | ✓ | spec §8.3 — AD-20 revizyon gerekçesi bu kurala doğru dayanıyor |
| çatı §105–106 (çoklu eğitmen tespiti planlamacıda; planlama yapılmadan teklif süreci başlamaz) | ✓ | spec §6.1 (kaç eğitmen planlamacı belirler), §6.11 (atama kesinleşmeden satış yok) |
| çatı §172 (eğitmen yetkinlik kontrolü; eğitmen/ulaşım/konaklama maliyetleri eğitime işlenir) | ⚠ | maliyetler spec §7'de eksiksiz; yetkinlik kontrolünün uygunluk kapısına dahil olup olmadığı tanımsız — F-14 |
| çatı §174 (eğitmen kategorileri: sürekli / bağımsız-sözleşmeli / proje bazlı) | ✓ | spec §1.1 birebir |
| çatı §174 (roller: süper admin, genel yönetici, planlama yöneticisi, planlamacı, satış yöneticisi, satışçı, eğitmen) | ⚠ | spec §8.2 görünürlük matrisi satış yöneticisi, genel yönetici ve katılımcıyı kapsamıyor; "eğitmen direktörü" / "planlama direktörü" adları çatı §174 ve AD-23 rol adlarıyla eşleşmiyor — F-7 |
| çatı §181 (fiyat/maliyet ayrı; kâr = fark; satışçı maliyeti görür) | ✓ | spec §8.2 satışçı satırı + §7 (maliyet kalemleri) |
| çatı §185 (eğitmen ücreti üç katman; işlem bazlı override **teklif/mali ekranda**) | ⚠ | üç katman spec §4'te korunuyor; ancak üçüncü katmanın yeri değişmiş (teklif/mali ekran → planlama/atama, §4.4 + §7.1) ve çatı revizyonu kaydedilmemiş — F-13 |
| çatı §187 (masraf: onaylayan rol/limit/fiş kuralı admin'den; cari bazlı; ödendi/ödenmedi zorunlu) | ⚠ | spec §5 + §7.6–7.8 limit/fiş/onay tarafını karşılıyor; cari **ödeme kaydının** yetkisi ve audit'i tanımsız — F-11 |
| çatı §194 (planlamacı dashboard'u) | ✓ | bu spec'in kapsamı dışı (planlama turu); spec onunla çelişen bir şey kurmuyor |
| çatı §219 / Y-2016 md.13/j (kadro değişikliği 15 gün içinde bildirilir) | ✓ | spec §1.2; resmî metinle doğrulandı (Y-2016 md.13/j: "eğitici kadrosu ve benzeri her türlü değişikliği… 15 gün içinde İdareye bildirmekle"); süre admin-tanımlı (AD-27 uyumlu) |
| Y-2016 md.7/3 (eğitici belgesi 5 yıl geçerli) | ✓ | spec §2 satır 2; resmî metinle doğrulandı |
| Y-2016 md.8/1 (5 yıllık sürede eğitim faaliyetinde bulunmayanın belgesi yenilenmez) | ⚠ | kuralın **içeriği** resmî metinle örtüşüyor; spec §2 bu kuralı **md.7/3'e** atfetmiş — resmî metinde md.8/1'dedir — F-2 |
| Y-2016 md.7/5 (bir eğitici en fazla iki yetkilendirilmiş kuruluşta) | ✓ | spec §2, §3.1, §3.2; resmî metinle doğrulandı |
| YÖN-2019 md.6/3 (bildirimler KUMS üzerinden) | ✓ | spec §1.2 — sistem görev açar, bildirimi insan KUMS'tan yapar; AD-15 ile tutarlı |
| YÖN-2019 md.6/4-5 (CTU eğitmensiz görev 4/11, fumigasyon eğitmensiz görev 12 verilemez) | ⚠ | spec §2'de alan olarak var; bu kapının **uygunluk/aday listesi davranışına** etkisi tanımsız — F-14 |
| fiyatlama-spec §1 (8 saat = 1 gün satış bandı) | ✓ | spec §4.1 — bandı satış tarafına ait sayıp eğitmen ücretine çevirmeme gerekçesi doğru |
| fiyatlama-spec §4.2 + AD-09 "global parametre, dar ayar — genişletme yok" | ❌ | spec §7.4 "kişiye özel ayar globali **her iki yönde** ezer" kuralını kuruyor ve emsal olarak `DiscountCeiling`'i gösteriyor; AD-09'un yazılı kuralı ve kendi örneği (%20 → %25'e **çıkarılamaz**, "genişletme denemesi hata verir") bununla çelişiyor; AD-09 revizyonu kaydedilmemiş — F-1 |
| AD-05 (hassas veri şifreleme) + çatı §10 (eğitmen kaydında TCKN, kimlik, ehliyet, SGK sicil no) | ⚠ | spec kendini eğitmen dosyasının tek kaynağı ilan ediyor ama bu alanların şifreleme/erişim/erişim-logu gereksinimlerini tanımlamıyor — F-10 |
| AD-08 (parametrik kurallar) | ✓ | cevap süresi, tatil takvimi, tarifeler, limitler, eşikler, kalem türü sözlüğü — hepsi admin-tanımlı; §6.10'daki tek sabit (esaslı değişiklik = tarih + yer) bilinçli, gerekçesi metinde ve taahhüt bütünlüğü kuralı olduğu için kabul edilebilir |
| AD-11 / kırmızı çizgi 12 (kritik kayıt silinmez) | ✓ | spec §6.12 (kesinleşmiş atama iptal edilir), §7.8 (onaylanmış masraf iptal/düzeltme ile) |
| AD-20 (revize: yazışma kayda bağlanır) | ✓ | revizyon notu AD-20 başında; spec §8.3 gerekçesi (açık eğitim, N teklif, cevabın hangi teklife ait olduğu) tutarlı; §8.4 güvenlik sınırlarını aynen koruyor. İnbound adres sorusu açık — Open Q-1 |
| AD-21 (aksiyon log değildir; erişim logu; kırmızı çizgi 13/17) | ✓ | spec §6.9 (kabul öncesi doküman erişimi loglanır), §7.8 (masraf eki görüntüleme erişim logu); iş verisi/denetim ayrımı korunmuş |
| AD-23 (tek grup ağacı, kapsam seviyeleri, eğitmen→planlamacı havuzu, dört göz onay altyapısı) | ❌ | eğitmen→planlamacı havuz ataması spec'te hiç yok (aday listesi kapsamını doğrudan belirler) — F-8; `approve_group` için ağaca paralel "doğrudan sorumlu referansı" önerisi AD-23'le uzlaştırılmamış — F-9; planlama onayının katılımcıları ve AD-23 onay mekanizmasıyla ilişkisi tanımsız — F-5 |
| AD-25 / AD-26 | ✓ | spec seviyesinde yükümlülük doğurmuyor; ekran envanteri panel/teknoloji ayrımına (AD-09) uygun — backoffice yalnız tanım tutuyor, mali durum görüntülemiyor |
| AD-27 / kırmızı çizgi 14 (mevzuat kaydı uyarır, değerler admin-tanımlı alanlarda) | ✓ | spec §2 girişi ve alan tasarımı birebir uyumlu; "son eğitim verme tarihi" hesaplanan alan, kapı değil uyarı |
| AD-28 (sertifika sınırı) | ✓ | spec sertifika üretimine hiç girmiyor |
| ofis-onyuz-spec (eğitmen ofis kullanıcısı, ofis kimlik alanı) | ✓ | spec §1 — `instructor` rolü, kullanıcı ↔ mevzuat dosyası ayrımı, pasifleşince dosyanın durması (AD-23 pasifleştirme kuralıyla tutarlı) |
| Spec doküman tanımı — ölçülebilir kabul kriterleri | ❌ | spec'te kabul kriteri bölümü yok (karş. `ofis-onyuz-spec.md` §9, 13 kriter) — F-12 |

---

## ✅ What works

- **Atama modelinin çekirdeği sağlam.** Tek eğitmen ihtiyacının `N=1` olarak genel modele katlanması, kabulün DB seviyesinde atomik kapanması (§6.4), "bekleyen teklif bloklamaz, kabul bloklar" ayrımı (§6.5) ve cevapsızlığın asıl tehlike olarak adlandırılıp direktör seviyesine yükseltilmesi (§6.7) — `first_accepted` yolu için dörtlü tutarlı kurulmuş.
- **"İş günü" dürüstlüğü.** 3 iş günü hesabının tatil takvimi olmadan yapılamayacağının açıkça uygulama borcu ilan edilmesi ve boş takvimin sessiz kalmaması (§6.7) — tipik olarak implementasyonda patlayan bir detay spec'te yakalanmış.
- **Kabul bir bilgi kapısı (§6.9)** ve erişimin AD-21 kapsamına alınması; esaslı değişiklikte onay yenileme gerekçesi (§6.10 — "kabul etmediği işe kabul etti diyen kayıt, kaydın hiç olmamasından kötüdür") taahhüt kaydının anlamını doğru koruyor.
- **Planlanan / ek maliyet ayrımının üç-soru gerekçesi (§7.2)** ve ek maliyetin mevcut kaleme referansla girilmesi (§7.3) — raporlanabilirlik ile onay-kilidi-olmama dengesi iyi kurulmuş.
- **Masrafın iki yüzü (§7.6–7.7):** eğitim maliyeti ve eğitmen carisi ayrımı, "kârlılık masraflar kapanınca kesinleşir" dürüstlüğü, kalem türü sözlüğünün kontrollü olma gerekçesi.
- **§7.8'in dürüstlüğü:** `approve_group`'un ön koşulunun (sorumlu bağı) açıkça "bedava değil" diye işaretlenmesi ve boş küme tehlikesinin yazılması; "kimse kendi masrafını onaylayamaz" kuralı ve emsali (`ChangeOfficeAccountStatus:95`, depoda doğrulandı); yetki adlarının `config/authorization.php:13-15`'teki kayıtlı `own/group/all` uzantısına yaslanması (depoda doğrulandı).
- **AD-20 revizyonu doğru gerekçeli:** açık eğitimde tek eğitime N teklif bağlı olduğu için "eğitime bağlamak yetmez" tespiti çatı §5'ten doğru türetilmiş; §8.4 güvenlik sınırlarını (gelen mail doğrulanmamış içeriktir) aynen taşıyor.
- **Mevzuat disiplini büyük oranda yerinde:** md.13/j, md.7/5, YÖN-2019 md.6/3-5, md.7 atıfları resmî metinle örtüşüyor (PDF'lerden doğrulandı); tüm değerler AD-27 uyumlu biçimde admin-tanımlı alan olarak kurulmuş; "son eğitim verme tarihi"nin hesaplanan alan olması isabetli.

---

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

**F-1 — §7.4 onay kuralı AD-09'un "genişletme yok" kuralıyla çelişiyor ve çelişki kayıtsız.** Spec, planlamacı bazlı ayarın ofiste (operasyon direktörü) yapıldığını ve globali **her iki yönde** ezdiğini söylüyor — globalde `always` iken bir planlamacı onaysız plan kurabilir. AD-09: *"Global değer backoffice'te tanımlanır; daraltma ofiste yapılabilir… genişletme denemesi hata verir"* ve örneği aynı ailedendir (*"%20 iken %25'e çıkaramaz"*). Spec'in emsal gösterdiği `DiscountCeiling` kod olarak gerçekten çift yönlü (`app/Support/Business/DiscountCeiling.php` doc-block: *"the seller's own WINS whichever way it points"*) — yani emsalin kendisi de AD-09'un yazılı hâliyle çelişik durumda ve bu çelişki hiçbir belgede çözülmüş değil (fiyatlama-spec §4.2 ezme yönünü hiç söylemiyor; çatı §182 "override" diyor ama yön belirtmiyor). Spec AD-20'yi revize etmeyi bilirken (§8.3) AD-09'a dokunmadan üstüne ikinci bir örnek inşa ediyor. Kişi bazlı ayarın **kimin tarafından yazıldığı** (backoffice mi ofis mi) bu çelişkinin tam ortasındadır ve spec'te planlamacı ayarı açıkça ofise verilmiştir. Bu hâliyle aynı soruya iki belge iki farklı cevap veriyor — spec'in kendi §7.4'ünün karşı çıktığı şeyin ta kendisi.

**F-2 — §2 mevzuat atıfı yanlış: "5 yılda hiç eğitim vermeyenin belgesi yenilenmez" md.7/3'e atfedilmiş; resmî metinde md.8/1'dedir.** Y-2016 md.7/3 yalnız eğitici sınav eşiğini (80) ve belge süresini (5 yıl) düzenler; yenilenmeme kuralı md.8/1'dir (*"Beş yıllık belge geçerlilik süresi içerisinde eğitim faaliyetinde bulunmayanların belgelerinin yenilenebilmesi için… eğiticilerin eğitimi seminerine yeniden katılım sağlamaları gerekir"* — PDF'ten doğrulandı). Kuralın **içeriği** doğru; atıf yanlış. Ayrıca §2'nin giriş cümlesi *"aşağıdakilerin hepsi resmî metinden doğrulanmıştır"* derken tablonun iki satırının kaynağı yalnız çatı satırıdır (§11 Bakanlık eğitmen onayı, §14 CTU/CSS evrakları) — mevzuat referansı taşımıyorlar; giriş cümlesi tabloyu olduğundan güçlü gösteriyor.

**F-3 — `selection` modunun yaşam döngüsü eksik.** (a) Kabul eden ama seçilmeyen eğitmenin teklifinin terminal durumu tanımsız — `accepted` kalamaz (taahhüt gibi görünür), `withdrawn` ise §6.8'de yalnız "açık kalan" (bekleyen) teklifler için tanımlı. (b) §6.4'ün atomik kontenjan kapanışı `first_accepted` gerekçesiyle yazılmış; `selection` modunda kontenjanı kabul mü kapatır seçim mi — tanımsız. (c) Kabul ile seçim arasında zaman geçer; **seçim anında** çakışma ve uygunluk yeniden değerlendirmesi tanımlı değil (§6.3 ve §6.5 kontrolleri yalnız "kabul anına" bağlı). (d) §6.5 "kabul bloklar" diyor — `selection` modunda kabul eden ama henüz seçilmeyen eğitmenin takvimi bloke midir; seçilmezse blok nasıl düşer? Bu dörtlü `first_accepted` için eksiksiz, `selection` için yazılmamış.

**F-4 — §6.10 onay yenileme penceresinin atama ve satış durumuna etkisi tanımsız.** Tarih/yer değişince onay yeniden istenir; bu pencere boyunca atama "kesinleşmiş" sayılır mı (satılabilirlik §6.11 buna bağlı), takvim bloğu sürer mi, ve eğitmen yeni onayı **reddederse** — özellikle eğitim satılmış/müşteri onaylı iken — atamanın ve eğitimin durumu ne olur? Cevapsızlık süresi (§6.7) onay yenilemede de işler mi? Edge davranışı yok.

**F-5 — §7.4 planlama onayının katılımcıları tanımsız.** Onayın **ne zaman** gerektiği üç değerle kurulmuş; **kimin** onayladığı hiçbir yerde yazmıyor (masraf onayında yetki adları verilmişken planlama onayında ne rol ne yetki var). AD-23'ün onay altyapısıyla (onay kuralı backoffice'te `(kayıt tipi, koşul, adımlar[])`, dört göz, silsile bildirim, 1 iş günü alarmı) ilişkisi de kurulmamış — bu mekanizmanın bir örneği mi, ayrı bir mekanizma mı, belirsiz.

**F-6 — §7.6 çifte saymanın karar kuralı ve aritmetiği tanımsız.** §7.3 deseninde referanslı tutar planlananın **üstüne** eklenir (planlanan 5.000 kalır + 1.000 sapma). Aynı desen §7.6'nın çifte sayma çözümü olarak gösteriliyor; ama 3E'nin zaten ödediği konaklamanın eğitmence fişle ikinci kez girilmesi hâlinde referans vermek tutarı maliyetten düşürmez — eğitim maliyeti iki kez saymış kalır, rapor bunu yalnız "o kalemde sapma" diye **etiketler**. Gerçek mükerrer için beklenen sonuç (ret mi? mahsup mu? referanslı masraf maliyete nasıl girer?) yazılı değil; "onay ekranı planlanan kalemleri gösterir" bir görünürlük şartıdır, finansal doğruluk kuralı değil. Kâr hesabı (çatı §181) bu belirsizliğin üstüne oturuyor.

**F-7 — §8.2 görünürlük matrisi rol kümesi eksik ve §6.9 ile çelişkili.** (a) Çatı §174 rollerinden **satış yöneticisi** ve **genel yönetici** matriste yok — satış yöneticisi planlama yazışmasını görür mü, cevabı yok; **katılımcı** satırı da yok (altı panelden biri). (b) Eğitmen satırı "katılımcı listesi"ni kabul şartından **önce** sayıyor ("Eğitim, tarih, yer, katılımcı listesi; kabulden sonra otel/bilet/dokümanlar") — §6.9 "kabul edilene kadar eğitimi görür, detayını görmez" diyor ve kendi gerekçesi (kabul etmemiş eğitmenin müşteri verisini görmesi için sebep yok) katılımcı kişisel verisi için de aynen geçerli; kabul öncesi katılımcı listesi görünürlüğü iki bölüm arasında çelişkili/belirsiz. (c) "Eğitmen direktörü" (§3.1) ve "planlama direktörü" (§6.7, §7.5) rol adları çatı §174 ("planlama yöneticisi") ve AD-23 ağacındaki adlarla ("Eğitim Direktörü") eşleşmiyor — uyarıların ve yükseltmelerin hangi tanımlı role düştüğü belirsiz.

**F-8 — AD-23'ün eğitmen→planlamacı havuz ataması spec'te hiç ele alınmamış.** AD-23: *"Eğitmen → planlamacı ataması simetriktir: geçici havuz, süreli veya süresiz; süre dolunca otomatik geri çekilir; geri çekilen eğitmenin mevcut planlanmış eğitimleri korunur, yalnız yeni planlama yapılamaz."* Bu mekanizma §6.3'teki aday listesinin kapsamını doğrudan belirler: planlamacı **tüm** uygun eğitmenleri mi görür, yalnız kendi havuzundakileri mi? Spec aday listesini yalnız uygunlukla tanımlıyor; AD-23'le ne uyum ne çelişki kaydedilmiş — sessizce yok sayılmış.

**F-9 — §7.8'in "doğrudan sorumlu referansı" önerisi AD-23'ün tek grup ağacı modeliyle uzlaştırılmamış.** AD-23 tek grup ağacı + üyelik + tek kapsam çözümleyicisi kurar; ağaç "Eğitmen Kadrosu → İzmit Eğitmenleri" kırılımını ve yöneticisini zaten modeller, `own/group/all` uzantısı da buna bağlıdır. Spec, "bugün böyle bir bağ yok" tespitinden (implementasyon durumu — doğru, migration'larda grup tablosu yok) eğitmen kaydında **ağaca paralel ikinci bir "grubum" mekanizması** önerisine geçiyor ve AD-23'le ilişkisini hiç kurmuyor. Aynı soruya ("bu eğitmen kimin grubunda") iki mekanizma iki farklı cevap verebilir hâle gelir. (Ayrıca "önerim…" cümlesi spec'e veri modeli tercihi yazıyor — bu plan aşamasının işidir; buradaki bulgu tercih değil, upstream uzlaşmazlığının kayıtsızlığıdır.)

**F-10 — Eğitmen dosyasının hassas veri gereksinimleri tanımsız.** Çatı §10 eğitmen kaydına TCKN, kimlik, ehliyet, SGK sicil no koyar; spec kendini eğitmen dosyasının tek kaynağı ilan eder (§0) ama bu alanlar için şifreleme (AD-05), kimin erişebildiği ve görüntülemenin erişim loguna (AD-21 — kırmızı çizgi 13: hassas kayda dokunan her okuma loglanır) girdiği gereksinimlerini yazmaz. Erişim logu yalnız masraf eki (§7.8) ve kabul sonrası dokümanlar (§6.9) için anılmış; dosyanın kendisi için anılmamış.

**F-11 — Cari ödeme kaydının yetkisi ve denetimi tanımsız.** §7.7 "ödeme kaydı bunları kapatır" der; ödemeyi **kimin** girebildiği (yetki adı), kısmi ödemenin olup olmadığı, ödeme kaydının audit'lenmesi (kırmızı çizgi 13'ün finansal işlem ailesi) ve yanlış girilen ödemenin düzeltilme biçimi (AD-11 iptal/düzeltme deseni masraf için yazılmış, ödeme için yazılmamış) tanımsız. Eğitmene borç kapatan bir finansal işlemin davranışı spec seviyesinde eksik bırakılamaz.

**F-12 — Kabul kriterleri yok.** Spec tanımı ölçülebilir kabul kriterlerini kapsam içinde sayar ve projenin kendi pratiği bunu uygular (`ofis-onyuz-spec.md` §9 — 13 kriter). Bu spec'te kabul kriteri bölümü hiç yok; oysa metin test edilebilir iddialarla dolu (atomik kabul, çakışma reddi, cevapsızlık yükseltmesi, `withdrawn` bildirimi, kabul öncesi detay kapısı, eşik aşımında onaya düşme, kendi masrafını onaylayamama). Plan aşaması neyin kanıtlanacağını bu spec'ten okuyamaz.

**F-13 — Çatı §185 ile sapma kaydedilmemiş.** Çatı §185 işlem bazlı override'ı *"teklif/mali ekranda"* konumlandırır; spec §4.4 + §7.1 onu planlama/atama anına taşır ve satışçıya maliyeti salt-okunur verir (§8.2). Karar içerik olarak savunulabilir (maliyet planlamanın işidir, çatı §181 ayrımıyla tutarlı) ama iki belge aynı kuralın yerini farklı söylüyor ve çatı "tek kaynak" ilan edilmiş durumda. Spec AD-20 revizyonunu açıkça taşırken çatı §185 için ne revizyon notu ne üst-belge değişiklik listesi var (onay kuralı 6: örtük eksik bırakılamaz).

**F-14 — §3 uygunluk kapısının bileşen listesi belirsiz; yetkinlik eşleşmesi listede yok.** §3.1 bayrakları üç örnekle sayar (belge süresi, iki kuruluş limiti, belge iptali); §2'deki yetkinlik kapıları (YÖN-2019 md.6/4-5 — CTU eğitmensiz görev 4/11, fumigasyon eğitmensiz görev 12 **verilemez**; resmî metinden doğrulandı) uygunluk değerlendirmesine dahil mi, değil mi — yazmıyor. Açık kalanlar #2 yalnız **veri modelini** eğitim tanımı turuna erteliyor; kapı **davranışı** (yetkinliği eşleşmeyen eğitmen o eğitimin aday listesinde görünür mü) bu spec'in sorusudur ve cevapsız. Mevzuat burada "uyarı" değil "veremez" der — davranışın tanımsız kalması, uygunluk felsefesinin ("planlamacıya sorulmaz, uygulanır") en sert mevzuat kuralını dışarıda bırakması demektir.

### Notlar (blocker değil — typo/atıf biçimi)

- Başlıktaki *"mevzuat §18, §20, §21"* atıfları içerik olarak çatı dokümanının 18/20/21. satırlarına denk düşüyor (`docs/mevzuat-kurallari.md`'nin o satırları başka içeriktir); etiket yanıltıcı.
- §7.8'deki *"çatı §7'nin indirim limitindeki kararı"* atfı çatı satır 182'deki 2. tur karar #7'yi kastediyor; satır-numarası düzeninde "§7" farklı yere düşüyor.

---

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

1. **Eğitim yazışmasının inbound adresi:** AD-20 revizyonu "her kayıt türü kendi inbound adresini taşır" diyor. Eğitim yazışması `teklif.3egrp.com` catch-all'ını local-part ön ekiyle (`eg-…@`) paylaşır mı, yoksa AD-20 genişleme deseni gereği yeni subdomain (= yeni Postmark server + ayrı webhook) mı açılır? İkisi farklı altyapı maliyeti taşır ve AD/plan bunu netleştirmeden kuramaz.
2. **Aday havuzu tükenirse:** tüm adaylar reddettiğinde atama isteğinin durumu ne olur (`open` mı kalır, `escalated` mı olur) ve planlamacı açık isteğe sonradan aday ekleyebilir mi?
3. **Cevapsızlık süresi teklif başına mı:** adaylara teklifler farklı zamanlarda gönderilebiliyorsa süre her teklifin kendi gönderim anından mı işler?
4. **Kişi bazlı ayarları kim yazar:** `user_discount_limits` benzeri kişi bazlı ayarların yazıldığı yer (backoffice mi ofis mi) — F-1'in çözümünü belirleyen soru; çatı §182 "admin panelden" derken spec §7.4 planlamacı ayarını ofise veriyor.
5. **Matristeki "Ofis" satırının kapsamı:** genel yönetici ve satış yöneticisi bu satıra mı dahil (F-7'ye bağlı)?

---

## Verdict: ❌ REJECTED

Matrix'te üç ❌ (AD-09 çelişkisi, AD-23 kapsam boşluğu, kabul kriterleri) ve altı ⚠ satır var; on dört bulgu açık. Spec'in çekirdeği — genel atama modeli, maliyet ayrımı, masrafın iki yüzü, AD-20 revizyonu — sağlam kurulmuş ve mevzuat atıflarının büyük çoğunluğu resmî metinle birebir doğrulandı; ancak `selection` modunun yaşam döngüsü, planlama onayının katılımcıları, çifte saymanın karar kuralı, görünürlük matrisinin rol kapsamı ve AD-09/AD-23 uzlaşmazlıkları kapatılmadan plan aşamasına geçilemez. Bilinçli açık bırakılan üç kalem (tedarikçi kaydı, yetkinlik veri modeli, tatil takvimi) gerekçeli ve adresli olduğundan eksik sayılmamıştır — yalnız yetkinlik kapısının **davranışı** (F-14) bu ertelemenin dışındadır. Bulgular çözülüp re-review talep edildiğinde matrix sıfırdan üretilecektir.