# Re-Review — Spec 1: Platform Omurgası (EGT-21) — Sürüm 1.1 — 25.07.2026

> **Review type:** spec-review (re-review)
> **Previous review:** `docs/reviews/review-omurga-spec-2026-07-25.md` — REJECTED, 12 bulgu (F-1…F-11 + dil notu)
> **Upstream document(s) read:** `cati-dokumani.md`, `docs/arch/mimari-kararlar.md` (AD-01…AD-28), `docs/mevzuat-kurallari.md` (tümü bu review oturumunda Read ile açıldı)
> **Other cross-referenced documents:** `mevzuat/1-egitim/IMDG_Kod_Kapsaminda_Egitim_ve_Yetkilendirme_Yonetmeligi.pdf`, `mevzuat/5-gozetim/Deniz_Ticareti_Gozetim_Hizmetleri_Uygulama_Yonergesi.pdf` (ilk review'da doğrulanan §7.4 referansları değişmedi)
> **Stage locks in effect:** None (upstream = çatı + AD'ler, tartışılmaz veri)

---

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

| Bulgu | Düzeltme iddiası | Doğrulama | Durum |
|---|---|---|---|
| F-1 — çok-tenant'lı görünürlük davet bazlı türle çelişiyordu | Yeni §4.4 + T-5 yeniden yazıldı | §4.4 görünürlük kümesini eğitim türünden türetiyor (açık / kurumsal / davet bazlı kapalı); davetli olmayan için "var değildir" + kodla erişimde "bulunamadı" (satır 102); V-1…V-5 tanımlı; §13'e sınır durumu, §14'e kriter 16 eklendi. V-3'ün davet listesinden çıkarmada sessiz gizleme yerine insan kararı istemesi doğru refleks. | ✅ KAPANDI |
| F-2 — K-2 önermesi imzalı yoklama için yanlıştı | §8.4 yeni dayanak: saklama yükümlülüğü | Yeni gerekçe paragrafı (satır 237) maskeleme argümanını yalnız maskelenebilen kayıtlara sınırlıyor; imzalı yoklama gibi maskelenemeyen belgelerde dayanak açıkça saklama yükümlülüğü. Yanlış önerme kaldırılmış. | ✅ KAPANDI |
| F-3 — silme hakkı ↔ mevzuat saklama kesişimi tanımsızdı | K-2…K-4: red + gerekçeli cevap + otomatik süre-sonu işlemi | K-2 (süre dolmadan talep reddedilir), K-3 (cevapsız bırakılmaz, dayanak + bitiş tarihi bildirilir, audit'lenir), K-4 (süre dolunca otomatik), §13 sınır durumu satırı, §14 kriter 19. Kesişim davranışı artık tanımlı. KVKK m.5/2-ç (hukuki yükümlülük) ile uyumlu, savunulabilir duruş; Sets kararı olarak kayıtlı. | ✅ KAPANDI (kalıntı: N-1) |
| F-4 — log yazım garantisi seviyeleri tanımsızdı | §7.2 sert / §7.3 gevşek | §7.2 satır 182: erişim logu yazılamıyorsa hassas veri görüntülenmez, gerekçeli. §7.3 satır 191: aktivite logu kaybı kabul edilebilir. §13'e iki sınır durumu, §14'e kriter 17. | ✅ KAPANDI |
| F-5 — erişim logu saklama süresi yoktu | Mevzuat süresinden kısa olamaz + en az 10 yıl | §7.2 satır 184; aktivite retention'ının erişim loguna uygulanmadığı açıkça yazılmış. 10 yıl tabanı §15/6 ile hukuk/operasyon teyidine bağlanmış — doğru şekilde açık nokta. | ✅ KAPANDI |
| F-6 — katılımcının firma değiştirmesi tanımsızdı | Yeni §3.2: kimlik tenant sınırını aşmaz | I-1…I-4 + gerekçe; §4.3'e negatif test, §13'e sınır durumu, §14'e kriter 15. Yenileme dayanağının yüklenen sertifika olması (I-4) çatı §2/§14 ve YÖN-2019 md.8 ile tutarlı — aşağıda "işaret edilen nokta 1" analizinde uygulanabilirliği doğrulandı. | ✅ KAPANDI |
| F-7 — bağımsız katılımcı aktör modelinde eşlenemiyordu | Yeni §3.1: gerçek kişi firma tenant'ı | Hukuki tür (tüzel/gerçek kişi) ayrımı temiz; aktör matrisi bozulmuyor; faturalama çatı #14 ile uyumlu. Ancak çözümün kendisi §13'ün "aynı e-posta aynı tenant'ta engellenir" satırıyla yeni bir çelişki doğuruyor. | ✅ KAPANDI (yeni bulgu: N-2) |
| F-8 — hassas dosyalar güvence dışıydı | §8.1'e D-1…D-4 | Şifreleme, süreli+tekil bağlantı, her erişimde yetki+tenant kontrolü ve erişim logu, bağlantı ≠ hak, bütünlük özeti + sürüm + AD-11 silinmezlik. §14 kriter 18. | ✅ KAPANDI |
| F-9 — İYS'ye bildirim yükümlülüğü eksikti | §10.2 genişletildi | Her onay ve ret İYS'ye bildirilir; bildirim başarısızsa gönderim yapılmaz (güvenli taraf); ret derhal etkili. §14 kriter 20. AD-17'nin iki bacağı tamamlandı. | ✅ KAPANDI |
| F-10 — kodla kayıt bulma tanımsızdı | Yeni §9.1 (R-7…R-10) | Koda göre arama her panelde, kapsam sınırlı; kapsam dışı kod → "bulunamadı" (T-1 ile aynı); R-9'un arama/görüntüleme log ayrımı makul. §13 + §14 kriter 21. | ✅ KAPANDI |
| F-11 — §5.3 kendi içinde çelişkiliydi | Varlık zorunlu, içerik seçilebilir | Satır 130: teyit adımının varlığı kapatılamaz, yalnız sorulan bilgi admin seçimi; gerekçe eklendi. Kapsam "katılımcı"dan "magic link ile açılan her oturum"a genişletilmiş — sıkılaştırma, tutarlı. | ✅ KAPANDI |
| Dil notu — §7.3 retention ifadesi | Netleştirildi | Satır 192: "(2 yıl veya 5 yıl) ve seçilen süreden eski kayıtlar silinir" — net. | ✅ KAPANDI |

## Upstream Coverage Matrix (güncel durum)

Önceki matrix'in ⚠/❌ satırları yeniden değerlendirildi; ✓ satırları değişmedi (sürüm 1.1'de ilgili bölümlere dokunulmamış):

| Upstream § / madde | 1.0 | 1.1 | Kanıt |
|---|---|---|---|
| AD-02 + çatı 2. tur #14 — bağımsız katılımcı tenant, fatura kesilebilir | ⚠ | ⚠ | §3.1 aktör eşlemesini çözdü; ancak §13 "aynı e-posta aynı tenant'ta engellenir" satırı §3.1'in gerektirdiği ikili kayıtla çelişiyor (N-2) |
| AD-05 — şifreleme kapsamı (alan + dosya) | ⚠ | ✓ | §8.1 + D-1…D-4 |
| AD-07 — magic link davranışı | ⚠ | ✓ | §5.3 çelişkisiz |
| AD-17 — İYS iki bacak (kapı + İYS kaydı) | ⚠ | ✓ | §10.2 |
| AD-19 — kodla kayıt bulma | ⚠ | ✓ | §9.1 |
| AD-21 — erişim logu garanti + saklama | ⚠ | ✓ | §7.2 |
| Çatı §5 — üç eğitim türü ve görünürlük | ❌ | ✓ | §4.4 (açık eğitimin çatıdaki "bölge" nitelemesi duyuru hedeflemesidir, görünürlük kısıtı değil — Spec 4/bildirim tarafında ele alınması tutarlı) |
| Çatı §2/§14 + YÖN-2019 md.8 — kişi bazlı yenileme sürekliliği | ❌ | ✓ | §3.2 / I-4: dayanak yüklenen sertifika; çatı §2 zaten yenilemede sertifika yüklemesini zorunlu kılar — model kendi içinde kapanıyor |
| AD-16 gerekçesi — silinemez kayıt ↔ KVKK silme hakkı | ❌ | ⚠ | §8.4 gerilimi hukuki dayanakla çözdü; ancak K-2/K-5 ayrımını çalıştıracak saklama-dayanağı sınıflandırmasının adresi yok (N-1) |
| Kırmızı çizgi 12 / AD-11 — kritik kayıt hard delete edilmez | ✓ | ⚠ | K-4 "silinir **veya** anonimleştirilir" — silinemez kayıt sınıflarında yalnız anonimleştirme meşru; seçimin neye bağlı olduğu tanımsız (N-1 kapsamında) |
| Mevzuat referansları (Y-2016 md.13/f, DG-2020 md.14/4, md.14/8, YÖN-2019 md.11) | ✓ | ✓ | §4.4'ün YÖN-2019 md.11 atfı ilk review'da okunan yönerge içeriğiyle tutarlı (farklı tesislerden ortak eğitim serbestisi) |

## ✅ What works

- **Revizyon disiplinli:** her bulgu için gereksinim + sınır durumu + kabul kriteri üçlüsü birlikte eklenmiş; revizyon geçmişi tablosu bulgu→değişiklik eşlemesini doğru veriyor. İddia edilen her düzeltme dokümanda gerçekten var.
- **§4.4 doğru soyutlama:** görünürlüğün serbest ayar değil türden türeyen sabit kural olması (V-1), yanlış konfigürasyonla sızıntı ihtimalini tasarım seviyesinde kapatıyor; V-5'in ticari bilgi sızıntısını AD-19'un sınıfına bağlaması tutarlı.
- **§8.4'ün yeni duruşu hukuken sağlam kurgulanmış:** "saklama yükümlülüğü varken silme yükümlülüğü doğmaz" KVKK m.5/2-ç'nin doğru uygulamasıdır; K-3'ün talebi cevapsız bırakmama ve gerekçeyi bitiş tarihiyle bildirme şartı, hakkın özünü koruyor. Proje kararı (Sets) olarak kayıtlı.
- **İşaret edilen nokta 1 — §3.2 dikey modüllerde uygulanabilir:** yenileme motoru yalnız yüklenen sertifikayla çalışabilir. "Af yok" değerlendirmesi (YÖN-2019 md.8) sertifika bitiş tarihine bakar; o tarih yüklenen belgeden gelir ve çatı §2 yenilemede sertifika yüklemesini zaten zorunlu kılar. Kademeli bildirimler (§10.5) ve satış fırsatı motoru tenant-içi kayıt üzerinden çalışır; iki işverende eşzamanlı kayıt bile sorun üretmez (her işveren kendi uyumundan sorumlu). Omurgada ek garanti **gerekmiyor**. Tenant-içi çift kayıt (aynı firmaya aynı kişinin iki kez eklenmesi) §3.2'nin konusu değildir ve Spec 4'ün dedup kuralına makul şekilde kalır.
- **İşaret edilen nokta 3 — §4.4 ↔ §9.1 arasında sızıntı boşluğu bulunamadı:** R-8 kapsam tanımı görünürlük kümesini içeriyor, §13 "davetli olmayan tenant + kod" satırı ve kriter 16/21 zinciri kapalı. T-6'nın "kapsamdan bağımsız okuma"sı sayacın *üretimi* içindir, *sunumu* V-4/V-5'e tabidir — iki kural farklı katmanlarda, çelişmiyor.
- Kabul kriterleri 15–21 ölçülebilir ve yeni davranışların her birine karşılık geliyor; §13'ün yeni satırları doğru sınır durumlarını seçmiş (özellikle "erişim logu yazılamıyor" / "aktivite logu yazılamıyor" ayrımının tabloda ayrı ayrı sınanması).

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

**N-1 — K-2/K-5 ayrımını çalıştıracak saklama-dayanağı sınıflandırması adressiz.** (İşaret edilen nokta 2'nin cevabı: ilke tutarlı, uygulanabilirlik köprüsü eksik.) K-2 ile K-5 ilkesel olarak çelişmiyor — ayrım "kanunen saklanması zorunlu mu" kriterine dayanıyor. Ancak bir kayda silme talebi geldiğinde sistemin K-2 mi K-5 mi uygulayacağını belirleyen bilginin **nerede tanımlandığı** spec'te yok. K-2'nin listesi örnekleyicidir (eğitim, yoklama, sınav, sertifika); orta kuşak sınıflandırılmamış: mali kayıtlar ve faturalar (VUK/TTK saklama süreleri — gerçek kişi tenant'ta doğrudan kişisel veridir ve eğitim mevzuatı kaydının kapsamına girmez), teklif yazışmaları, rıza kayıtlarının kendisi. K-4'ün "otomatik yürümesi" makine-okunur saklama süresi gerektirir; §8.2 bunu özel nitelikli evrak için, AD-27 eğitim mevzuatı için taşıyor ama omurga genel kuralı koymuyor (ör. *"her veri sınıfının saklama dayanağı ve süresi tanım aşamasında belirlenir [Spec 2]; dayanağı tanımsız sınıf K-5 kapsamındadır"*). Ayrıca K-4'ün "silinir **veya** anonimleştirilir" seçimi kırmızı çizgi kapsamındaki silinemez kayıtlarda (imzalı yoklama, sınav sonucu — AD-11) yalnız anonimleştirme olabilir; seçimin neye bağlı olduğu tanımsız. Cerrahi düzeltme: §8.4'e sınıflandırma-adresi kuralı + K-4'e silinmez-kayıt istisnası.

**N-2 — §3.1 ile §13 "aynı e-posta" satırı çelişiyor.** §3.1, gerçek kişi firma tenant'ında aynı gerçek kişinin hem müşteri kullanıcısı hem katılımcı olarak var olacağını ve bunların "iki ayrı kullanıcı türü olarak davrandığını" söyler — yani aynı tenant'ta, büyük olasılıkla aynı e-postayla iki kullanıcı kaydı. §13 ise "aynı e-postayla ikinci kullanıcı aynı tenant içinde engellenir" der. Bu iki kural birlikte, §3.1'in çözdüğü senaryoyu §13'ün bloklaması demektir. Çözüm iki yönden biri olmalı ve spec hangisi olduğunu söylemeli: (a) §13 satırına tür istisnası — "farklı kullanıcı türlerinde aynı e-posta aynı tenant'ta olabilir", veya (b) tek kullanıcı hesabının iki tür bağlamı taşıdığı bir model — ki bu durumda §3'ün "tür, kimlik doğrulama yöntemlerini belirler" kuralının böyle bir hesapta nasıl uygulandığı tanımlanmalı.

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

1. N-1'in çözümünde sınıflandırmanın sahibi hangi spec: saklama dayanağı/süresi Spec 2'nin tanım motoruna mı bağlanacak (AD-24 evrak türü + AD-27 mevzuat kaydı zaten kısmen taşıyor), yoksa omurga ayrı bir "saklama politikası" kavramı mı tanımlayacak?
2. KVKK veri sahibi başvurusu doğrudan 3E'ye geldiğinde (özellikle 3E'nin veri sorumlusu sıfatıyla tuttuğu kayıtlar için) I-1'in mutlak eşleme yasağı ile başvuruyu karşılama yükümlülüğü nasıl bağdaşır? Müşteri verisi için 3E veri işleyen konumundaysa talep tenant üzerinden gelir ve sorun yoktur; hukuki rol ayrımı (sorumlu/işleyen) hiçbir dokümanda yazılı değil — hukuk teyidine bağlanmalı (§15'e aday).
3. §15/6'daki "erişim logu en az 10 yıl" tabanı hukuk teyidi bekliyor — teyit gelmeden plan aşamasında bu değer sabitlenmemeli (spec zaten açık nokta olarak işaretlemiş; teyidin takibi için ticket önerilir).

## Verdict: ❌ REJECTED

12 bulgunun 12'si de gerçekten kapatılmış — düzeltmeler iddia edildiği gibi dokümanda var, kabul kriterleri ve sınır durumlarıyla desteklenmiş; özellikle sorulan üç noktadan ikisi (§3.2'nin dikeylerde uygulanabilirliği, §4.4↔§9.1 sızıntı boşluğu) temiz çıktı. Ancak revizyonun kendisi iki yeni bulgu üretti: F-7'nin çözümü §13'ün "aynı e-posta" kuralıyla iç çelişki doğuruyor (N-2) ve §8.4'ün yeni K-2/K-5 ayrımı, hangi verinin hangi kola düştüğünü belirleyecek sınıflandırma mekanizmasını adressiz bırakıyor (N-1 — sorulan 2. noktanın cevabı: ilke tutarlı, köprü eksik). İkisi de dar, cerrahi düzeltmelerdir; scope içinde bulgu varken orta yol olmadığından verdict REJECTED'dır. N-1 ve N-2 kapatılıp re-review istendiğinde başka engel görünmüyor.