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

> **Review type:** spec-review (re-review — plan review'ından dönen upstream düzeltme)
> **Previous reviews:** spec v1.0→v1.4 zinciri (v1.4 APPROVED, `-r5.md`) · plan v1.0 REJECTED (`review-omurga-plan-2026-07-25.md`, P-1…P-9)
> **Tetikleyen:** plan P-1 (ofis çok-tenant erişimi RLS'te karşılıksız) ve P-2 (auth-öncesi bağlam bootstrap'i) — kök sebep spec'in kimlik modelinde görüldü, sahip yapısal düzeltme kararı verdi
> **Upstream document(s) read:** çatı, AD-01…AD-28, mevzuat-kurallari (bu zincirde tamamı okundu); v1.5'in yeni iddiaları upstream'e karşı kontrol edildi
> **Stage locks in effect:** ⛔ sahip kararı: veri saklama/silme politikası kapsam dışı (bu turda da uygulandı, bulgu edilmedi) · plan review bulguları veri olarak alındı, yeniden tartışılmadı

---

## Değişikliğin upstream uyumu

| Yeni içerik | Upstream | Durum |
|---|---|---|
| İki kimlik alanı (ofis `users` · müşteri `customers`+`customer_users`) | AD-02 (tenant = müşteri firma), AD-23 (süper admin ağacın dışında, backoffice) | ✓ — tenant tanımına dokunmuyor; sistem yönetiminin ofis alanına alınması AD-23'ün "sistem rolü" tanımıyla uyumlu |
| §3.0 katmanlı yetenek (katılımcılık veriden türer, panel yetkisi verilir) | Çatı §9 (firma kendi personelini ekler, grup bazında yetkilendirir), çatı 2. tur #5 | ✓ — çatı "panel kullanıcısı ve katılımcı ayrı hesaptır" demiyor; model çatıyla çelişmiyor ve teklif onayı/personel yönetimi akışlarını koruyor |
| §3.1 bağımsız katılımcı = gerçek kişi tenant + tek kayıt | Çatı 2. tur #14 | ✓ — v1.2'deki çift-kayıt çözümünden daha basit; fatura ve teklif onayı aynı kayıtta |
| Magic link panel yetkisini açmaz | AD-07 (magic link paylaşılabilir, kanıt değil) | ✓ — AD-07'nin gerekçesinin tutarlı genişletmesi; §5.2 MFA şartını güçlendiriyor |
| §12 çok dillilik, mevzuat çevrilmez | CLAUDE.md dil kuralı (UI Türkçe, çeviri dosyaları), AD-27 (mevzuat resmî metin) | ✓ — "hiçbir metin koda gömülmez" dil kuralının genelleşmiş hali; mevzuatın çevrilmemesi AD-27'nin kaynak-sadakat ilkesiyle tutarlı |
| Tablo adları İngilizce (`users`, `customers`, `customer_users`, `training_participants`) | CLAUDE.md dil kuralı (geliştirme tarafı İngilizce) | ✓ |

## ✅ What works

- **Soru 1 (P-1/P-2'nin kökü) — büyük ölçüde kesiliyor, sorun başka yere taşınmıyor.** Ofis kimliğinin `users` olarak tenant dünyasının tamamen dışına alınması iki şeyi yapısal olarak çözüyor: (a) plan P-2'nin ofis yarısı — ofis login'i artık tenant bağlamı gerektirmez, çünkü ofis kimlik tablosu tenant-kapsamlı değildir; (b) plan P-5 — `tenant_id IS NULL` istisnalı users RLS politikası ihtiyacı ortadan kalktı, istisnanın açtığı WITH CHECK genişliği diye bir şey artık yok. Ofis kullanıcısının çok-tenant **iş verisi** erişiminin RLS mekanizması (P-1'in kendisi) doğası gereği plan işidir ve plan revizyonunda hâlâ tanımlanmak zorundadır — ama spec artık buna engel bir kimlik modeli dayatmıyor; "ofis kimliği tenant'a ait değildir" ayrımı doğru zemin. Kalan tek spec-seviyesi boşluk müşteri tarafındaki login bootstrap'idir (Bulgu B-1).
- **Soru 2 (§3.0 izolasyon) — sağlam ve yeterince sert.** Katılımcılığın `training_participants` varlığından türemesi ve panel yetkisinin açıkça verilmesi, "hesap türü" kavramının taşıdığı bütün transferi/birleştirme/ikinci-kayıt sorunlarını (eski F-6/F-7/N-2 ailesinin kökünü) tek hamlede kaldırıyor. U-1'in "URL ile de erişemez" ifadesi + genişletilmiş Y-5 ("menünün boş olması güvenlik değildir; asıl kapı policy'dir") doğru sertlikte. Eksik olan davranış değil, kabul kriteri (B-2).
- **Soru 3 (§5.3 magic link kısıtı) — uygulanabilir ve tutarlı.** "Yetki arttıkça kimlik doğrulama sertleşir" ilkesiyle oturuma doğrulama seviyesi eklemek bilinen, uygulanabilir bir desendir (step-up auth); §5.2 MFA zorunluluğuyla (teklif onaylama) aynı yönde çekiyor, §13'e sınır durumu eklenmiş. Küçük tanımsız alt-durum: panel yetkili ama hiç eğitim kaydı olmayan kişi (U-2 gereği katılımcı ekranı da göremez) magic link ile girerse boş bir oturum + şifre daveti kalır — zararsız ama §13 satırındaki "katılımcı ekranlarını görür" ifadesi bu kişi için doğru değil; düzeltme tek cümlelik (nota bırakıldı, bulgu değil).
- **Soru 5 (§12 ↔ K-1) — doğru kurulmuş.** Rıza kaydının dili zorunlu alan olarak alması ve gerekçesinin "silinemez kayda sonradan alan eklenemez" olması isabetli; §12'nin "veri sahibinin dilinde sunulur (bkz. K-1)" çapraz referansı bağı kapatıyor. Fallback zinciri rıza metnine uygulansa bile hangi dilde sunulduğu kayıt altında olduğundan hukuki iz korunuyor. Mevzuatın çevrilmemesi kararı ve gerekçesi ("yanlış çeviri, çeviri yokluğundan risklidir") bu projenin risk profiline tam oturuyor.
- Revizyon geçmişi 1.5 bölümü değişiklikleri gerekçeleriyle eksiksiz belgeliyor; §13'ün "aynı e-posta" satırının yeni modelle sadeleşmesi (istisnasız tek kural + alanlar arası çakışmanın tanım gereği yokluğu) eski N-2 çözümünden daha temiz.

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

**B-1 — Müşteri tarafında auth-öncesi bağlam bootstrap'i hâlâ tanımsız; §4.1'in mutlak kuralıyla çelişiyor.** (Soru 1'in kalan yarısı — plan P-2'nin müşteri ayağı.) §4.1: "Tenant bağlamı belirlenmeden tenant-kapsamlı hiçbir veri okunamaz." `customer_users` tenant-kapsamlıdır; ama müşteri girişinde kişiyi bulmak için bu tabloya bakmak gerekir — bağlam henüz yokken (bağlam kullanıcıdan belirleniyor: tavuk-yumurta). Ofis yarısı yapısal olarak çözüldü; müşteri yarısı için spec iki yoldan birini seçip yazmalı: (a) tenant'ın giriş **öncesi** nasıl belirlendiğini davranış olarak tanımlamak (ör. firma-özel giriş adresi/tenant seçimi — magic link zaten belirli kayda üretildiği için sorun yalnız şifreli girişte), veya (b) kimlik doğrulama sorguları için dar, açıkça sınırlanmış bir bağlam-öncesi istisna sınıfı tanımlamak (hangi tablolar, hangi güvencelerle). Bu yazılmazsa plan revizyonu aynı P-2'yi müşteri tarafında yeniden üretecek.

**B-2 — v1.5'in yeni davranışları için kabul kriteri eklenmemiş.** §14 listesi v1.4'ten aynen taşınmış (20 kriter). Oysa bu spec'in kendi deseni her yeni davranışa ölçülebilir kriter eklemekti (v1.1'de 15-21 böyle eklendi). Kriteri olmayan yeni davranışlar: U-1 (panel yetkisiz kişinin URL ile firma paneline erişememesi), U-2 (eğitim kayıtsız kişinin katılımcı ekranı görmemesi), U-4/U-5 (yetki ekleme = kayda ekleme + audit), §5.3 panel kilidi (magic link oturumunda panel ekranının şifre/2FA istemesi), §12 dil fallback zinciri, K-1 dil alanının zorunluluğu, tenant bazlı saat dilimi. Bunlar omurganın en yeni ve en az olgunlaşmış davranışları — tam da kriter gerektiren yerler.

**B-3 — "Kullanıcı türü" ekseni askıda kaldı.** §3 artık kullanıcı türü tanımlamıyor (iki kimlik alanı + yetenek katmanları); ama §5.1 yöntem matrisi ("hangi kullanıcı türünün hangi yöntemleri"), A-6 (oturum süreleri "kullanıcı türü bazında") ve §14/3 hâlâ "kullanıcı türü" üzerinden konuşuyor. Yeni modelde bu ayarların ekseni nedir — kimlik alanı mı (ofis/müşteri), müşteri tarafında yetenek mi (panel yetkili / yalnız katılımcı)? §5.3'ün "magic link panel yetkisini açmaz" kuralı fiilen yetenek-bazlı bir ayrım ima ediyor; matris ekseni tanımlanmadan admin ekranı da plan da kurulamaz. Terim ya yeniden tanımlanmalı ya da ayarların yeni bağlanma noktası açıkça yazılmalı.

**B-4 — §13'ün "birden fazla tenant'a bağlı kullanıcı" satırı eski modelin kalıntısı.** "Ofis kullanıcısı dışındaki türlerde bu duruma izin verilmez" — yeni modelde ofis kullanıcısı tenant'a hiç **bağlanmaz** (alan tanımı gereği) ve müşteri tarafındaki kayıt tanım gereği tam olarak bir tenant'ın içindedir; "birden fazla tenant'a bağlı kullanıcı" durumu yapısal olarak imkânsızlaşmıştır. Satır bu haliyle var olmayan bir tür kavramına referans veriyor; ya kaldırılmalı ya "bu durum yeni modelde yapısal olarak oluşamaz" diye yeniden yazılmalı.

**Notlar (bulgu değil):** (1) §13 "panel yetkili kişi magic link ile girdi → katılımcı ekranlarını görür" — eğitim kaydı olmayan panel yetkilisi için U-2 gereği görülecek ekran yoktur; satıra "varsa" eklenmeli. (2) Saat dilimi tenant bazlı tanımlandı; tenant'a ait olmayan ofis kullanıcısının saat dilimi kaynağı yazılmamış (muhtemel cevap: uygulama varsayılanı Europe/Istanbul — bir cümleyle netleşir). (3) T-2/RT-6 "katılımcı/müşteri kullanıcısı" ifadeleri eski tür adlarıyla ama anlamları yeni modelde de nettir; isteğe bağlı dil temizliği.

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

1. B-1'in yönü: firma-özel giriş adresi mi (tenant önce belirlenir), bağlam-öncesi dar istisna sınıfı mı? Karar plan'daki RLS/muafiyet desenini doğrudan şekillendirir.
2. B-3'ün ekseni: yöntem matrisi ve oturum ayarları kimlik alanı bazında mı, müşteri tarafında yetenek bazında mı tanımlanacak?

## Verdict: ❌ REJECTED

Yapısal düzeltmenin yönü doğru ve plan bulgularının köküne gerçekten iniyor: ofis kimliğinin tenant dünyasından tamamen ayrılması P-2'nin ofis yarısını ve eski users-RLS istisnası sorununu yapısal olarak yok ediyor; katmanlı yetenek modeli hesap-türü ailesinin bütün geçmiş sorunlarını (transfer, birleştirme, çift kayıt) kaldırıyor; magic link kilidi ve çok dillilik/K-1 bağı sağlam. Ancak dört bulgu spec'i bu haliyle plan revizyonuna zemin yapmaya engel: müşteri login bootstrap'i hâlâ tanımsız ve P-2'yi müşteri tarafında yeniden üretir (B-1), yeni davranışların hiçbirinin kabul kriteri yok (B-2), "kullanıcı türü" ekseni askıda (B-3), §13'te eski modelden kalma bir satır duruyor (B-4). Dördü de dar ve hızla kapatılabilir; kapatıldığında model plan revizyonunu taşıyacak olgunlukta görünüyor.