# Re-Review — Spec 1: Platform Omurgası v1.11 (üçüncü kimlik alanı, heyet 141 kapanışı) — 26.07.2026

> **Review type:** spec-re-review (heyet 141'in 7 bulgusunun kapanış doğrulaması + F-3'ün yön değiştiren çözümü)
> **Previous review:** `docs/reviews/review-omurga-spec-2026-07-26.md` (v1.11 ilk hâli — ❌ REJECTED, 7 bulgu)
> **Upstream document(s) read:** `docs/arch/mimari-kararlar.md` AD-09 güncel hâli (satır 78-113 yeniden okundu) + AD-23 · `cati-dokumani.md` (önceki turda okundu, bu turda değişmedi)
> **Other cross-referenced:** `docs/specs/omurga-spec.md` tam metin yeniden okundu (641 satır) · `omurga-plan_chunk5.md` §5.1 · `docs/claude/heyet.md` kural 4-5 · kalıntı atıf taraması (`§3.2.1`, `B-1…B-4`, `system.access_backoffice` tüm .md'lerde)
> **Doğrulama yöntemi:** dosya üzerinde okuma + grep; beyan kanıt sayılmadı
> **Stage locks in effect:** ⛔ Sets kararı — F-3'ün ilk çözümü (T-4 daraltması) reddedildi; doğru eksen **yapabilirlik/kapsam ayrımı**dır. Bu turda o karar veriliyken T-4'ün genişliği bulgu konusu değildir; incelenen şey ayrımın tutarlı işlenip işlenmediğidir.

---

## Kapanış doğrulaması (heyet 141 bulguları)

| Bulgu | Doğrulama | Durum |
|---|---|---|
| **F-1** üçüncü alan gövdeye yarım işlenmişti | §5.1: "(ofis / backoffice / müşteri)… **üç alan** bağımsız ayarlanır" (satır 197) · A-6 üç alan (228) · §12 "Tenant'a bağlı olmayan kimlik alanları — **ofis ve backoffice**" (435) · §13 "aynı e-posta" satırı üç tabloya çıkarılmış (456). İki-alan dili taraması temiz — kalan "iki alan" geçişleri yalnız revizyon geçmişinde (tarihsel kayıt). | ✅ KAPANDI |
| **F-2** backoffice MFA spec'te karşılıksızdı | §5.2'ye ikinci paragraf: **alan bazlı** zorunlu MFA, AD-23 atfı, ayar olarak kapatılamaz; gerekçesi yetki tavanına bağlanmış (207). Kriter 35 test karşılığı. Plan chunk5 §5.1 notu artık "spec §5.2" diye **var olan** bir hükme atıf yapıyor (chunk5:36). | ✅ KAPANDI |
| **F-3** "tek istisna" iddiası T-4 ile yarışıyordu | **Yön değiştirilerek kapatıldı** (Sets kararı — stage lock yukarıda): çelişkinin iki bacağı iki ayrı kavrama ayrıldı. §3.3 yetki tavanının **olmadığını** ve karşılığın **denetim** olduğunu söylüyor (49-57); §3.3.1 dört şartı **dar yetkili rollerin tanımına** indiriyor ve süper admin için tavan olmadığını iki kez açıkça yazıyor (59-74); §3.4 bugünkü dar kapsamın **tercih** olduğunu ve "erişemez" diye okunamayacağını sabitliyor (76-84). T-4 geniş hâline dönmüş ve üç kavrama da atıf veriyor (162); L-4 "denetim ekranını tarif eder, yetki tavanını değil" diye kendini sınırlandırmış (298). Hiçbir yerde backoffice'in tenant verisine "tek yolu" iddiası kalmadı. AD-09'un "mali sınır" paragrafıyla (satır 97: *"yapabilirliği geniştir; kapsamı bilinçle dardır"*) artık **uyumlu**. | ✅ KAPANDI |
| **F-4** kimlik çakışması + yanlış L-3 atfı | Şartlar `G-1…G-4` (63-68); çakışmanın gerekçesi madde içinde açıkça yazılı (72: "`B-1…B-6` §4.1'in bootstrap istisnasına aittir"). Yanlış "§7.5 L-3" atfı kalktı: §3.3 görünürlük için genel "§7.5" (tablo satırı) diyor, G-4 yalnız "§7.2" diyor. Dosya setinde `B-1…B-4` kapı anlamında hiçbir yerde geçmiyor (grep; chunk3'ün kendi B-serisi ayrı bir aile ve bu addan etkilenmiyor). G-3'e üst sınır sorusunun destek spec'ine bırakıldığı Sets kararıyla işlenmiş (67 — heyet 141 açık soru 1'in cevabı). | ✅ KAPANDI |
| **F-5** AD-09'un eski "kapıdır" paragrafı | AD-09 satır 99 yeniden yazılmış: düzeltme **gerekçesiyle birlikte** ("eski modelin cümlesiydi… aynı anda doğru olamazdı; heyet 141 F-5") ve yeni tanım net: **kapı = `backoffice_users` kaydının kendisi**. Spec'te `system.access_backoffice` yalnız tarihsel notlarda (33, 627). | ✅ KAPANDI |
| **F-6** bağlamama kuralı yanlış katmandaydı | **I-5** spec'e girmiş (130): eşleştirme yok, ortak kimlik yok, yetki/oturum taşıma yok, "aynı kişi" bilgisi veri modelinde tutulmaz + gerekçe (ayrımın kurulma sebebinin sessizce geri gelmemesi). §13'e sınır satırı (457). Kriter 36 test karşılığı. I-serisine eklenmesi doğru adres — I-1…I-4 ile aynı sınıf. | ✅ KAPANDI |
| **F-7** kabul kriteri yoktu | Kriter **31-37** eklendi (500-508): 31 tablo/izin ailesi ayrılığı (şema kontrolü) · 32 Y-4/Y-5 üç alan · 33 backoffice erişim-log bağı · 34 L-4 ayrı izin + öz-loglama · 35 backoffice MFA · 36 I-5 · 37 panel kapsam taraması. Hepsi ölçülebilir; 33 ve 37'nin ⚠ notları kriterin **neyi kanıtlamadığını** açıkça söylüyor — bkz. aşağıda soru 1 değerlendirmesi. | ✅ KAPANDI |

## Upstream Coverage Matrix

Sıfırdan, güncel AD-09/AD-23 metnine karşı üretildi:

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| AD-09: backoffice ayrı kimlik alanı; `users` ile tablo paylaşımı yok | ✓ | spec §3 (35, 40); kriter 31 |
| AD-09: **yetki tavanı yoktur**; karşılık kısıt değil denetim; log yazılamazsa erişim olmaz | ✓ | spec §3.3 (49-57), T-4 (162); kriter 33. AD-09 satır 105 ile birebir aynı çerçeve |
| AD-09: "mali sınır" = kapsam tercihi, yetki sınırı değil; "şu an için" | ✓ | spec §3.4 (76-84); kriter 37; AD-09 satır 97+107 |
| AD-09: kapılı erişim = dar yetkili rollerin erişim biçimi; süper admine tavan değil; ofise genişletilemez | ✓ (⚠ R2-1: sınıf cümlesi düştü) | spec §3.3.1 (59-74); AD-09 satır 109 |
| AD-09: tehdit varsayımı yalnız süper admin; destek görevlisi kullanıcı yönetimine erişmez | ✓ | spec §3 tablo + §3.3.1 (61); AD-09 satır 111 |
| AD-09: kapı = backoffice hesabının kendisi (F-5 düzeltmesi) | ✓ | AD-09 satır 99; spec'te eski izin yalnız tarihsel kayıtta |
| AD-23 kural 1 + backoffice provisioning kalıcı istisnası | ✓ | Y-4 (243); §3.3 birinci madde (53) |
| AD-23: backoffice'te MFA zorunlu | ✓ | §5.2 (207); kriter 35 |
| AD-07/AD-08: yöntem matrisi kimlik alanı bazında admin-tanımlı | ✓ | §5.1 (197), A-6 (228); kriter 3 |
| AD-21 §7.5 görünürlük + L-4 tek okuma yolu tarifi | ✓ | §7.5 (287-298); kriter 34; L-4'ün yeni sınırlaması T-4 ile tutarlı |
| Spec iç: §13 sınır durumları üç-alan modeliyle | ✓ | 456-457 |
| Spec iç: alanlar arası eşleştirme yasağı | ✓ | I-5 (130); kriter 36 |
| Spec iç: v1.11 davranışlarına kabul kriteri | ✓ (⚠ R2-2: kriter 33'ün ölçüm adresi) | kriter 31-37 (500-508) |
| Çatı 2. tur roller / süper admin sistem rolü | ✓ | değişmedi; §3 tablo uyumlu |

## ✅ What works

- **F-3'ün yeni çözümü çelişkiyi doğru eksenden kapatıyor.** Eski metin tek bir "backoffice-tenant ilişkisi" kavramına hem "erişebilir" (T-4) hem "yalnız kapıdan" (§3.2.1) dedirtiyordu; yeni metin bunu üç ayrı, çelişmeyen önermeye ayırıyor: *ne yapabilir* (§3.3 — her şey), *bunun karşılığı ne* (denetim bağı — kriter 33), *bugün ne yapıyor* (§3.4 — tercih, kriter 37). "Her şey serbest ama biz yapmıyoruz" cümlesi denetlenemez **kalmıyor**, çünkü iki yarısı iki ayrı kritere bağlanmış.
- **AD-09 ↔ spec hizası ilk kez tam:** "yapabilirlik geniş / kapsam dar" cümlesi artık iki belgede de aynı; karışıklığın üç kez çıktığının kaydı ve heyet.md kural 5'in her iki yanlış okumayı da ("erişemez" / "en geniş ofis yetkisini taşır") bulgu konusu ilan etmesi, bu eksendeki dördüncü çıkışı yapısal olarak zorlaştırıyor.
- **G- yeniden adlandırması** yalnız çakışmayı çözmekle kalmamış, gerekçesini madde içine yazarak gelecekteki bir "sadeleştirme" düzenlemesinin kimlikleri geri çakıştırmasını engelliyor.
- **Kriter 33 ve 37'nin ⚠ notları** dürüst etiketleme: kriterin kanıtlamadığı şeyi kriterin üzerine yazmak, "test geçti = backoffice erişemez" yanlış çıkarımını test raporu seviyesinde kapatıyor.
- **Rollback kaydı** (revizyon geçmişi son paragrafı) kök sebep + Sets alıntısı + "AD-09 zaten doğru yazıyordu, spec uymadı" tespitiyle tam; r7'nin "geçmiş dosyayla çelişemez" disiplinine uygun.

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

**R2-1 (minör) — §3.3.1'in sınıf cümlesi düşmüş.** v1.11'in ilk hâlindeki *"Bu şartları taşımayan bir erişim yolu eklemek spec değişikliğidir"* cümlesi, yeniden yazımda hiçbir karşılık bırakmadan kaybolmuş. Süper admin için artık doğru olmadığından aynen kalamazdı; ama **dar yetkili roller için** eşdeğeri de yok. Mevcut metin ("G-1…G-3 … dar yetkili backoffice rollerini tarif eder") tanım olarak bağlayıcı, ancak destek spec'i yazılırken "bu yeni rol destek değil, o yüzden G-şartları uygulanmaz" biçimindeki aşınmaya karşı açık sözleşme cümlesi ilk hâlinden daha zayıf. Tek cümlelik bir eksik; model etkilenmiyor.

**R2-2 (minör) — kriter 33'ün ölçüm adresi belirsiz: yazma dokunuşları hangi log sınıfına düşer?** §3.3 "tenant verisine **her dokunuşu** sert biçimde loglanır (**erişim logu** §7.2)" diyor ve §3.3 backoffice'in **yazabildiğini** de söylüyor ("eğitim de oluşturabilir"). Oysa §7.2 tanım gereği **okuma olayları** sınıfıdır; yazma zaten §7.1 audit'ine işlemle aynı transaction'da gider. Garanti düzeyi iki yolda da aynı ("log yok → işlem yok"), yani güvence boşluğu yok; ama kriter 33'ü koşacak test, backoffice'in bir tenant kaydını **yazdığı** durumda hangi tabloda satır arayacağını spec'ten çıkaramıyor (erişim logu mu, yalnız `audit_writes` mı, ikisi birden mi). Bir cümlelik netleştirme işi; plan turuna sarkarsa kriter 33'ün test tasarımında yorum farkı üretir.

**Not (bulgu değil — biçim, önceki turdan taşınan):** §3.3/§3.3.1/§3.4, dosyada hâlâ §3.0/§3.1/§3.2'den önce duruyor; sıralama 3.3 → 3.4 → 3.0 → 3.1 → 3.2. Numaralar artık alt-madde iması taşımıyor (F-4'ün yan kazancı), yalnız fiziksel sıra tuhaf. Blocker değildir.

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

Sunumun beş sorusunun değerlendirmesi:

1. **F-3'ün yeni çözümü doğru yönden mi?** Evet. "Her şey serbest ama biz yapmıyoruz" burada denetlenemez bir beyan değil, çünkü iki yarısı iki ayrı ölçüme bağlanmış: serbestlik tarafında kriter 33 pozitif **ve** negatif test alır (erişim → log satırı; log yazımı bloklandığında → erişim reddi — §7.2 yazım garantisiyle aynı desen, emsalli); tercih tarafında kriter 37 panel kayıtlarını tarar. Kriter 33'ün "loglandığını kanıtlar, engellendiğini değil" ibaresi kriteri test edilemez yapmıyor — engellemeyi hiç vaat etmeyerek **yanlış güvence** sınıfını kapatıyor; bu bir detective-control sözleşmesidir ve negatif testi vardır. Tek pürüz R2-2'deki ölçüm adresi.
2. **§3.4 spec'e mi ait?** Bu şekliyle evet. (a) §3 tablosu §3.3'e ve §3.4'e birlikte atıf veriyor — §3.3'ü tek başına okuyup "backoffice her şeyi yapar, ekranı da vardır" sonucuna varma riski kapanmış; (b) ⚠ etiketi + kriter 37'nin "kapsam kriteridir" notu normatiflik sınıfını açıkça düşürüyor; (c) yalnız AD-09'da bırakmak spec'in kendi T-4'ünü yine bağlamsız bırakırdı. Bedeli senkron yükü: tercih değişirse §3.4 + kriter 37 + AD-09 üçü birden güncellenmeli — üçü birbirine atıflı olduğu için kabul edilebilir.
3. **§3.3.1 yeterince sert mi?** Büyük ölçüde: şartlar artık "backoffice'in sınırı" değil "dar rolün tanımı" olduğundan, "süper admin nasılsa erişiyor" argümanı dar rolün şartlarını **gevşetmez** — o argüman rol değiştirmeyi gerektirir ve AD-09 tehdit varsayımı (destek görevlisi varsayımı taşımaz, kullanıcı yönetimine erişmez) tam o kapıda duruyor. Kalan tek aşınma yüzeyi R2-1'deki eksik sözleşme cümlesi.
4. **T-4 ↔ L-4 ↔ G-4'te çelişki kaldı mı?** Kalmadı. Üçü artık farklı şeyler söylüyor ve hiçbiri "tek istisna/tek yol" iddiası taşımıyor: T-4 = yetenek + denetim karşılığı; L-4 = belirli bir okuma yolunun (denetim ekranı) tarifi ve kendi kendini sınırlaması ("yetki tavanını değil"); G-4 = herkes için log şartı, G-1…G-3 = dar rol şartları. Belge setinde kalan "tek istisna" ifadeleri farklı eksenlerde ve önceden mutabık: §4.1 (bağlamsız işlem ekseni — bootstrap), Y-4 (yetki atama ekseni — provisioning), L-1a (L-1'in görünürlük istisnası). Desen tekrarlamıyor.
5. **Rollback kaydı yeterli mi?** Evet. Kök sebep, karar sahibinin birebir gerekçesi, "upstream zaten doğruydu, spec uymadı" tespiti ve tekrarlama sayısı (üçüncü çıkış) revizyon geçmişinde; kalıcı koruma iki yerde (AD-09 kesin dil + heyet.md kural 5). "Heyet doğru tespit etti, çözüm yanlış yöne uygulandı" sınıfının izlenebilirliği için gereken her şey var; ayrıca bu kayıt, gelecek review'ların "bulgu kapatılmış = doğru kapatılmış" varsayımını kırması bakımından emsal değeri taşıyor.

Plan turuna devreden liste (bu turda bilinçli ertelendi, plan matrisinde kapanacak): chunk5 §5.8 + kriter 19 (eski model: `users` + `system.access_backoffice`) · chunk6 izin listesi (`system.access_backoffice` ofis izni olarak duruyor) ve "İki ayrı yetki dünyası" başlığının iki-alan dili · chunk2 §2.8 `permissions/roles/model_has_*` satırının tek izin ailesi varsayımı (kriter 31 ile gerilimde) · chunk3:176 izin atfı · `docs/issues.md:23` eski model cümlesi · backoffice şifre sıfırlama tablosunun karşılığı.

## Verdict: ✅ APPROVED

Heyet 141'in yedi bulgusunun yedisi de dosya üzerinde doğrulanarak kapandı; F-3'ün yön değiştiren çözümü çelişkiyi üretildiği eksende (yapabilirlik/kapsam karışması) kapatıyor ve AD-09 ile spec ilk kez aynı dili konuşuyor. Matris temiz; kalan iki bulgu minördür, modeli etkilemez ve tek cümlelik düzeltmelerdir — emsal (heyet 133) uyarınca yeni tur gerektirmeden kapatılabilirler: R2-1 dar roller için sözleşme cümlesinin geri konması, R2-2 backoffice yazma dokunuşlarının log sınıfının netleştirilmesi. Bunlar işlendikten sonra spec v1.11, chunk5 plan revizyonunun upstream'i olmaya hazırdır; plan turu yukarıdaki devir listesini matrisine almalıdır. Son karar kullanıcınındır.