# Review — Spec 1: Platform Omurgası v1.11 (üçüncü kimlik alanı) — 26.07.2026

> **Review type:** spec-re-review
> **Previous review:** `docs/reviews/review-omurga-spec-2026-07-25-r8.md` (v1.7 APPROVED; sonraki spec-katmanı bulguları EGT-50 serisinde: `review-egt50-ofis-backoffice-2026-07-26*.md`)
> **Upstream document(s) read:** `docs/arch/mimari-kararlar.md` (tamamı — özellikle AD-09 güncel hâli, AD-23, AD-21, AD-07, AD-08, AD-06), `cati-dokumani.md`, `CLAUDE.md`
> **Other cross-referenced documents:** `docs/plans/omurga-plan.md` (index), `omurga-plan_chunk2.md` §2.5/§2.8, `omurga-plan_chunk5.md`, `omurga-plan_chunk6.md` §6 izin listesi, `omurga-plan_chunk8.md`, `config/tenancy.php` (senkron beyanının doğrulaması). Mevzuat dosyası açılmadı — v1.11 deltası mevzuat-bağımlı kural içermiyor.
> **Stage locks in effect:** None (spec aşaması; AD-09 aynı turda güncellendiği için bu turun inceleme paketine dahildir)

---

## Upstream Coverage Matrix

v1.11 deltasının upstream'i AD-09 (güncel), AD-23, AD-21 ve AD-07/AD-08'dir; matris delta kapsamındaki maddeleri ve deltanın dokunması gereken spec bölgelerini kapsar. v1.7→v1.10 arasında kapatılmış ve bu turda değişmeyen alanlar (audit zinciri, KVKK, bildirim, referans kodları) önceki turların matrisleriyle kapalıdır; bu turda değişiklik izi taranmış, dokunulmadığı doğrulanmıştır.

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| AD-09: backoffice ayrı kimlik alanı — `backoffice_users`, kendi oturum/auth ayarı/izin ailesi; `users` ile tablo paylaşımı yok | ✓ | spec §3 satır 40, §3 giriş satır 35 ("hiçbir tabloyu paylaşmazlar — özellikle yetki tablolarını") |
| AD-09: kapılı erişim — dört şart birden; ofis kimliğine genişletilemez; destek yapısı ayrı spec | ✓ (içerik) / ⚠ (tutarlılık — F-3, F-4) | spec §3.2.1 satır 49-62; şartlar AD-09 satır 105 ile birebir. Ancak T-4 ile çelişki (F-3) ve yanlış çapraz referans (F-4) var |
| AD-09: tehdit varsayımı yalnız süper admin rolü; destek görevlisi kullanıcı yönetimine erişmez | ✓ | spec §3 tablo satır 40 (süper admin / destek ayrımı), §6 Y-4'ün AD-09 atfı; ayrıntı AD-09 satır 107 |
| AD-09: "`system.access_backoffice` yalnız kapıdır" paragrafı | ⚠ | AD-09 satır 99, iki paragraf altındaki yeni kimlik-alanı hükmüyle (satır 101-103) çelişiyor — F-5 |
| AD-23 kural 1 + backoffice provisioning kalıcı istisnası, üç alanda geçerlilik | ✓ | spec §6 Y-4 satır 218 ("üç kimlik alanının hepsi", adlandırılmış tek istisna, AD-09 tehdit varsayımı atfı) |
| AD-23: "backoffice'te MFA zorunludur" (kullanıcı oluşturma bölümü, satır 307) | ❌ | spec §5.2 satır 182 MFA zorunluluğunu yalnız yetki listesine bağlıyor; backoffice alanı için zorunlu MFA spec'te yok. Kural şu an yalnız chunk5 §5.1'de (plan) yaşıyor — F-2 |
| AD-07/AD-08: yöntem matrisi kimlik alanı bazında admin-tanımlı | ⚠ | spec §5.1 satır 174 hâlâ "(ofis / müşteri)… **iki alan** bağımsız ayarlanır"; üçüncü alanın yöntem matrisi tanımsız — F-1 |
| AD-07 türevi oturum ayarları (A-6) ve §12 saat dilimi davranışının üç alana uyarlanması | ❌ | A-6 satır 203 "(ofis / müşteri)"; §12 satır 410 yalnız "ofis kimliği" — backoffice kimliğinin davranışı tanımsız — F-1 |
| AD-21 §7.5 log görünürlüğü: backoffice sütunu, L-4 tek okuma yolu | ✓ | spec §7.5 satır 262-273 üç sütunlu tablo + L-4; v1.11 değişiklik gerektirmedi |
| Spec iç bütünlüğü: §13 sınır durumları yeni modele uyarlanması | ⚠ | satır 431 "aynı e-posta" satırı yalnız `users` + `customer_users` sayıyor; üçüncü alan ve ofis+backoffice çift kaydı sınır durumu yok — F-1, F-6 |
| Spec iç bütünlüğü: v1.11 davranışları için ölçülebilir kabul kriteri (emsal: v1.5 → kriter 21-30) | ❌ | §14 kriter listesi 30'da kaldı; tablo/izin ailesi ayrılığı, üç-alan Y-4/Y-5, §3.2.1 sınırının negatif testi için kriter yok — F-7 |
| Çatı 2. tur roller: süper admin sistem rolü, ağacın dışında (AD-23 satır 289) | ✓ | spec §3 tablo — süper admin backoffice alanında, org ağacı ofis alanında |

---

## ✅ What works

- **Gerekçe zinciri sağlam ve doğru yerde.** "Karmaşıklığın adresi" gerekçesi hem spec §3'te hem AD-09'da aynı çerçeveyle duruyor; karar güvenlik iddiasına yaslanmıyor, bu da "yetki zaten var" tartışmalarını baştan kapatıyor.
- **§3.2.1'in dört şartı sınır spec'i olarak doğru kurgulanmış.** Şartların kümülatif olması ("birden"), "tüm müşteriler modu yoktur" ifadesi, "log yazılamıyorsa erişim de olmaz" (erişim logunun §7.2 yazım garantisiyle aynı sınıf) ve "bu şartları taşımayan yol eklemek spec değişikliğidir" cümlesi — destek spec'i yazılırken kaçak yol açılmasını sözleşme düzeyinde engelliyor. B-2 kapsam mekanizmasının destek spec'ine ertelenmesi doğru bir erteleme: spec sınırı koyuyor, mekanizmayı değil.
- **İstisnanın ofise genişletilememesi açıkça yazılmış** — ayrımın varlık sebebini kendi metninde koruyor.
- **Y-4/Y-5'in üç alana genişletilmesi** doğru ve AD-23'ün provisioning istisnasıyla tutarlı.
- **Tehdit varsayımının daraltılması** (süper admin ≠ destek görevlisi) AD-09'da açık; "ayrı tablo istismarı imkânsız kılmaz, görünür kılar" gerekçesi tutarlı — provisioning zaten adlandırılmış, audit'li bir muafiyet ve izin çevirmek yerine yeni `users` satırı üretmek denetim izinde niteliksel olarak daha görünür bir olaydır.
- **Revizyon geçmişi disiplini** (sürüm damgası + girdi tek adımda, R4-1 kuralı) bu turda korunmuş.

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

**F-1 — Üçüncü alan spec gövdesine yarım işlenmiş; backoffice alanının auth davranışı tanımsız.** v1.11 revizyon kaydı backoffice'in "kendi oturum, auth ayarı ve izin ailesiyle" geldiğini söylüyor; ama §5.1 hâlâ "Ayarların ekseni kimlik alanıdır **(ofis / müşteri)**… **iki alan** bağımsız ayarlanır" (satır 174), A-6 "(ofis / müşteri)" (satır 203), §12 saat dilimi satırı yalnız "ofis kimliği" (satır 410), §13 "aynı e-posta" sınır durumu yalnız iki tabloyu sayıyor (satır 431). Sonuç: backoffice alanı için hangi yöntemlerin açılabileceği, yöntem matrisinin kim tarafından ayarlanacağı, oturum/hareketsizlik süresi ve saat dilimi davranışı spec'te tanımsız — spec kendi §3'üyle çelişiyor. (Rol bazlı davranış eksikliği + çelişkili gereksinim; spec scope tablosunun ilk iki satırı.)

**F-2 — AD-23'ün "backoffice'te MFA zorunludur" hükmü spec'te karşılıksız.** §5.2 MFA zorunluluğunu dört yetkiye bağlıyor; backoffice alanına dair hüküm yok. Kural bugün yalnız chunk5 §5.1'de, üstelik "spec §5.2 deseninin backoffice karşılığı" ifadesiyle — yani plan, spec'te olmayan bir kuralı spec'e atıf verir gibi taşıyor. Upstream (AD-23 satır 307) zorunlu kıldığı için bu bir tercih sorusu değil, kapsama eksiğidir. (Sunum sorusu 5'in cevabı: evet, spec'e girmeli.)

**F-3 — §3.2.1'in "tek istisna" iddiası T-4 ile çelişiyor.** T-4 (satır 139) sistem yöneticisine "**tüm tenant'lara** erişebilir" diyor, koşulu yalnız erişim logu + maskeleme, amacı "**denetim ve destek**". §3.2.1 ise backoffice'in tenant verisine dokunuşunu dört şarta bağlıyor ve B-2 "tüm müşteriler diye bir mod yoktur" diyor. Sistem yöneticisi (backoffice süper admini) T-4 üzerinden gerekçesiz/kapsamsız/süresiz erişebiliyorsa §3.2.1'in sınırı süper admin için boştur ve "tek istisna" iddiası doğru değildir; erişemiyorsa T-4'ün mevcut metni yanlıştır. Hangi hükmün geçerli olduğu tanımsız. Bu, v1.9'da kapatılan F-5'in ("tek istisna iddiası tek değildi") aynı desenle üçüncü tekrar edişidir; ayrıca L-4'ün (çapraz-tenant **denetim kaydı** okuma) §3.2.1'in "tenant verisi" kapsamına girip girmediği de yazılı değil. (Sunum sorusu 1'in "kaçak bırakıyor mu" yarısının cevabı: evet — kaçak dört şartta değil, T-4'te.)

**F-4 — Gereksinim kimliği çakışması ve yanlış çapraz referans.** §3.2.1 şartları B-1…B-4 olarak numaralanmış; §4.1'in bootstrap istisnası zaten B-1…B-6 kimliklerini kullanıyor (satır 125-130). "Spec B-5" gibi downstream atıflar (chunk5 §5.5 mevcut hâliyle §4.1'i kastediyor) artık iki farklı maddeyi işaret edebilir. Ayrıca §3.2.1 B-4, erişim logunun backoffice-yalnız görünürlüğü için "**§7.5 L-3**"e atıf yapıyor — L-3 **kullanım logu** kuralıdır (satır 272); erişim logunun görünürlüğü §7.5 tablosunun ayrı satırıdır. Normatif bir hüküm yanlış kurala bağlanmış durumda.

**F-5 — AD-09'da eski modelin kapı paragrafı korunmuş; yeni hükümle çelişiyor.** AD-09 satır 99 hâlâ "`system.access_backoffice` yalnız **kapıdır**" diyor — bu, backoffice'in ofis kimliği üzerindeki bir izin olduğu eski modelin cümlesidir. İki paragraf altında (satır 101) "backoffice AYRI BİR KİMLİK ALANIDIR… `users` ile hiçbir tabloyu paylaşmaz" yazıyor. Yeni modelde kapı, ofis izni değil backoffice hesabının kendisidir; iki paragraf aynı anda doğru olamaz. AD-09 bu turun paketinde güncellendiği için bu bir stage-lock konusu değil, paketin iç çelişkisidir ve spec'in dayandığı upstream'i belirsiz bırakır. (Aynı dizge chunk6 izin listesinde "Ofis izinleri" altında da duruyor — o kısım plan revizyonunun işi, burada yalnız AD katmanı bulgudur.)

**F-6 — Aynı kişinin ofis + backoffice çift kaydı spec'te tanımsız; "bağlanmaz" kuralı yanlış katmanda yaşıyor.** "Kayıtlar birbirine bağlanmaz (bağlamak, ayrımı iptal etmenin sessiz yoludur)" kuralı yalnız chunk5 §5.1'de (plan). Bu, müşteri tarafındaki I-1…I-4 ile aynı sınıfta bir **kimlik davranış kuralıdır**: sistemin iki alanı eşleştirmeyeceği/ilişkilendirmeyeceği bir spec hükmü gerektirir; §13 sınır durumlarında da bu senaryo yok. Spec sessiz kaldığı sürece plan bu kuralı koyamaz da kaldıramaz da — davranışın sahibi belirsiz. (Sunum sorusu 2'nin tespit yarısı; kararın kendisinin değerlendirmesi Open Questions'ta.)

**F-7 — v1.11'in yeni davranışları için kabul kriteri eklenmedi.** §14 otuz kriterde kalmış. Ölçülebilir olduğu halde kriteri olmayan yeni davranışlar: üç alanın tablo ve **izin ailesi** paylaşmadığı (şema kontrolü), Y-4/Y-5'in üç alanda zorlandığı, backoffice'ten tenant verisine giden kapısız hiçbir yolun bulunmadığı (§3.2.1 sınırının negatif testi), backoffice alanının auth davranışı (F-1/F-2 kapatıldığında). Emsal bu spec'in kendi tarihinde: v1.5'in davranışları için r6 B-2 bulgusuyla kriter 21-30 eklenmişti; v1.11 aynı disipline tabi.

**Not (bulgu değil — biçim):** §3.2.1, dosyada §3.0/§3.1/§3.2'den **önce** yer alıyor ve numarası §3.2'nin alt maddesi olduğunu ima ediyor; oysa §3.2 müşteri kimliğinin tenant sınırı hakkındadır. Adres olarak çalışıyor, ancak yapı yanıltıcı. Blocker değildir.

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

1. **(Sunum sorusu 1)** B-2'nin "kapsam nasıl belirlenir" sorusunun destek spec'ine ertelenmesi **doğru bir erteleme** — sınır spec'i mekanizma tanımlamaz ve dört şart, gelecekteki her tasarımın taşımak zorunda olduğu kısıtlar olarak yeterince serttir. Kaçak, şartlarda değil T-4'tedir (F-3). Ayrıca destek spec'ine devredilmesi gereken bir alt soru açık kalmalı: B-3'ün "süreli" hükmünün, gerekçe hiç kapanmazsa da bir üst sınırı olacak mı?
2. **(Sunum sorusu 2)** Bağlamama kararı değerlendirme olarak savunulabilir: denetlenebilir bir bağ, tam da "istisna `users`'a taşınmasın" diye kurulan ayrımın veri modelinde geri gelmesidir ve iki alanın izin/oturum dünyalarını birleştirme baskısı üretir; bir direktörün iki kaydının ilişkisi organizasyonel bir bilgidir ve sistem verisi olmak zorunda değildir. Ancak kararın **adresi** spec olmalıdır (F-6) — plan'daki bir ⚠ paragrafı, gelecekteki bir "SSO kolaylığı" talebine karşı sözleşme gücü taşımaz.
3. **(Sunum sorusu 3)** "İmkânsız değil, görünür" gerekçesi sağlam: provisioning adlandırılmış, audit'li, MFA'lı bir muafiyettir ve tehdit varsayımı (süper admin = şirket sahibi) AD-09'da açıkça sahiplidir. Bu gerekçenin bütünlüğü F-3'ün çözümüne bağlıdır — süper adminin T-4 erişimi aynı netlikle konumlanmadan "backoffice'in tenant verisiyle ilişkisi görünürdür" iddiası eksik kalır.
4. **(Sunum sorusu 4)** Downstream senkron durumu (bilgi — bu turda verdict'i etkilemez, plan revizyon turunun matrisine girer): chunk5 §5.8 ve kriter 19 hâlâ eski model ("Filament'e yalnız `users` tablosundan, `system.access_backoffice` izniyle"); chunk6 `system.access_backoffice`'i **ofis izni** olarak listeliyor ve "İki ayrı yetki dünyası" başlığı iki-alan dilinde; chunk2 §2.8'in `permissions/roles/model_has_*` satırı tek izin ailesi varsayıyor — spec §3'ün "özellikle yetki tablolarını paylaşmazlar" hükmüyle gerilimde; backoffice şifre sıfırlama tablosunun (§2.8'de ofis için `password_reset_tokens` var) karşılığı tanımsız. chunk8 ve chunk2 §2.8 backoffice satırı + `config/tenancy.php` senkronu doğrulandı.
5. **(Sunum sorusu 5)** F-2'de cevaplandı: backoffice MFA zorunluluğu spec seviyesine girmelidir; plan seviyesi yeterli değildir çünkü upstream (AD-23) hükmü zaten spec'ten önce koymuştur ve plan spec'siz kural taşıyamaz.

## Previous Findings Status (re-review only)

Önceki spec turlarının (r1-r8 + EGT-50 spec-katmanı bulguları) tamamı kapalıydı ve bu turda gerileme yok: §7.5 L-1…L-4, L-1a/L-1b, Y-4 provisioning istisnası, kriter 8 "kullanım logu" düzeltmesi ve v1.10 AD-06 yeniden yazımı dosyada duruyor. Bu turun yedi bulgusu v1.11 deltasının kendi ürünüdür. Not: F-3, v1.9'da kapatılan EGT-50 F-5'in ("tek istisna iddiası belge setinde tek değildi") aynı eksende yeniden açılmasıdır — çözüm o turda T-4'e sınır cümlesi eklemişti; v1.11'in §3.2.1'i aynı eksene üçüncü bir "tek istisna" iddiası ekleyip T-4 ile yeniden yarıştırıyor.

## Verdict: ❌ REJECTED

Matris temiz değil (2 ❌, 4 ⚠) ve yedi bulgu açık. Kararın kendisi — üçüncü kimlik alanı, gerekçesi ve §3.2.1 sınır kurgusu — sağlamdır ve hiçbir bulgu kararın geri alınmasını gerektirmez; bulguların tamamı deltanın spec gövdesine **eksik ve çelişkili işlenmesinden** geliyor: backoffice alanının auth/MFA/oturum davranışı tanımsız (F-1, F-2), "tek istisna" iddiası T-4 ile yarışıyor (F-3), gereksinim kimlikleri çakışıyor ve yanlış kurala atıf var (F-4), AD-09 eski modelin kapı paragrafını taşıyor (F-5), ofis+backoffice çift kayıt kuralı yanlış katmanda (F-6), yeni davranışların kabul kriteri yok (F-7). Red-line ihlali yoktur. Bulgular kapatılıp re-review talep edildiğinde spec, chunk5 revizyonunun upstream'i olmaya hazır hale gelir. Son karar kullanıcınındır.