# Review — Omurga Planı Chunk 6 (Yetki zorlama, görünürlük, referans kodları) — 2026-07-27

> **Review type:** plan-review
> **Previous review:** N/A — chunk6'nın v1.11 revizyonu ilk kez review görüyor. Plan bütününün son onayı `review-omurga-plan-2026-07-25-r5.md`; emsal chunk revizyon turu `review-omurga-plan-chunk5-2026-07-26.md`.
> **Upstream document(s) read:** `docs/specs/omurga-spec.md` v1.11 (§3, §3.0.1, §3.3, §3.4, §4.1, §4.4, §5.2, §5.3, §6, §7.1, §7.2, §7.5, §9, §9.1, kabul kriterleri 31–37) · `docs/arch/mimari-kararlar.md` AD-08, AD-09, AD-19, AD-23 · `docs/plans/omurga-plan.md` (index) · `omurga-plan_chunk2.md` §2.5, §2.7, §2.8, §2.8.1 · `omurga-plan_chunk3.md` §3.6, §3.6.1, kriterler 11b/15b/16/34 · `omurga-plan_chunk4.md` kriter 5, 8 · `omurga-plan_chunk5.md` tamamı · `omurga-plan_chunk9.md` §9.5 (S-19), §9.6
> **Other cross-referenced documents:** `CLAUDE.md` · `docs/issues.md` · teslim edilen kod: `app/Domain/Authorization/ScopeResolver.php`, `app/Support/Tenancy/SessionScopeResolver.php`, `app/Actions/Tenancy/CreateCustomer.php` (reverse-grep: caller 0), `app/Queries/Audit/OfficeAuditFeed.php` (caller 0), `config/tenancy.php:87-92`, `app/Providers/Filament/BackofficePanelProvider.php`
> **Stage locks in effect:** Spec v1.11 locked (`review-omurga-spec-2026-07-26-r2.md` APPROVED) · chunk1–5 implementasyonları locked (chunk5: `review-omurga-chunk5-impl-2026-07-27-r2.md` APPROVED)

---

## Upstream Coverage Matrix

Matris sıfırdan, dosyalar açılarak üretildi; developer'ın sunduğu matris kopyalanmadı.

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| Spec kriter 31'in **izin yarısı** — üç alan izin tablosu paylaşmaz (spec:519) | ✓ | chunk6:20-26 üç aile; kriter 2 (chunk6:162); `config/tenancy.php:87-92` ve chunk2 §2.8 senkron doğrulandı |
| Spec kriter 32 — **Y-4** üç alanda (spec:520, 255) | ✓ | kriter 2b atama reddi (chunk6:164), kriter 2c aile ayrımı (chunk6:165), 7b müşteri (chunk6:171) |
| Spec kriter 32 — **Y-5** üç alanda (spec:520, 256) | ⚠ | Müşteri: kriter 7b ✓. Backoffice: kriter 2b ✓. **Ofis: kriter yok.** Kriter 2b'nin kendi cümlesi *"kanıt üç alanda ayrı ayrı istenir"* diyor (chunk6:164); ofis bacağının kriteri de devir kaydı da yok → **F-9** |
| Spec §6 Y-1, Y-2, Y-3 | ✓ | §6.3 (chunk6:64-69); kriterler 4, 5, 6 (chunk6:167-169) |
| Spec §6 Y-6 / §9 R-5 — kod yetki değildir | ✓ | §6.7 R-5 satırı (chunk6:143); kriter 13 |
| Spec §5.2 **yetki bazlı** MFA (spec:216) | ✓ | §6.4(a) (chunk6:75-79); kriter 7 (chunk6:170) — P-4 kapanışı |
| Spec §5.2 **alan bazlı** backoffice MFA (spec:218) | ✓ (chunk5'te) | chunk5 §5.7(b) (chunk5:194-199) ve kriter 24 (chunk5:255) dosyadan doğrulandı; §6.4(b)'nin tekrarlamaması doğru (F-13 emsali) |
| Spec §4.4 V-1, V-2, V-4, V-5 | ✓ | §6.6 tablo + config stratejisi (chunk6:118-124); kriterler 10, 11 |
| Spec §4.4 **V-3** (spec:198) | ⚠ | İlk yarı (görünmezlik) VisibilityRule ile ✓; **çatışma yarısı** (davetten çıkarılan firmada kayıtlı katılımcı → sessiz gizleme yok, kullanıcıya bildir + karar iste) ne chunk6'da ne index devir tablosunda → **F-13** |
| Spec §9 R-1…R-10 / AD-19 | ⚠ | R-2…R-10 ✓ (chunk6:139-148). **R-1 alfabesi kendi kuralıyla çelişiyor: dizge L harfini içeriyor** (chunk6:139) → **F-10**. R-7'nin "her panelde koda göre arama" yüzeyi adressiz → **F-13** |
| Spec §7.1 audit kapsamı — "kullanıcı oluşturma/pasifleştirme/**yetki değişikliği**" (spec:272), kırmızı çizgi 13 | ⚠ | §6.8 yalnız `CustomerUserPermissionsChanged` + `UserPermissionsChanged` (chunk6:156); **backoffice izin/rol atamasının** (kriter 2b'nin sınadığı yol) olayı/audit'i planda yok → **F-8** |
| Spec §7.5 — erişim logu **ofiste görünmez** (spec:302) | ❌ | §6.2 **ofis** ailesinde `audit.view_access_log` (chunk6:38) → **F-11** |
| AD-09 — backoffice'e giriş ofis izni değil, `backoffice_users` kaydı | ✓ | §6.2 `system.access_backoffice` kaldırıldı (chunk6:43); kriter 2a tek yer (chunk6:163); chunk5 kriter 19'un atfı doğrulandı (chunk5:247) |
| AD-09 — backoffice'in kendi izin hiyerarşisi, dar başlangıç | ✓ | §6.1 ⚠ notu (chunk6:28); §3.3.1 kapılı erişim destek spec'ine bırakılmış — spec §3.3.1:127 ile uyumlu |
| AD-23 kural 1 + backoffice provisioning istisnası | ✓ | §6.2 `user.provision`/`user.assign_permissions` backoffice ailesinde (chunk6:49, 53); kriter 2c aynı adın iki ailede karışmadığını sınıyor |
| chunk2 §2.5.1 / §6.5 — ScopeResolver arayüzü | ⚠ | Plan iki metot tanımlıyor (`accessibleTenantIds` + `scopeLevel`, chunk6:91-94); teslim edilen arayüzde yalnız `accessibleTenantIds` var (`ScopeResolver.php:27`). `scopeLevel`'ın bu chunk'ta mı ekleneceği ve `SessionScopeResolver`'ın onu nasıl cevaplayacağı yazılı değil → **F-5** |
| chunk2 §2.8.1 düzeltme notu — ofis kimliği **boş kapsam** | ✓ / ⚠ | §6.5 ana metin kodla ve chunk2 §2.8.1 ile uyumlu (chunk6:96-100, `SessionScopeResolver.php:18-22`); **ama P-7 gerekçe bloğu hâlâ eski "tüm tenant'ları verir" metnini taşıyor** (chunk6:108) → **F-1**; `docs/issues.md:45` hâlâ "Chunk6 `TreeScopeResolver` ile kapanır" diyor → **F-2** |
| chunk2 §2.8 — `customers` INSERT istisnasının yetki ayağı: *"`customer.create` izni, chunk6"* | ❌ | §6.2'nin **hiçbir ailesinde** müşteri oluşturma izni yok (chunk6:34-60); kriter 15a "bir izin kontrolüyle" diyor ama izni adlandırmıyor → **F-4** |
| chunk2 §2.8 — backoffice izin ailesi bağlamsız, müşteri ailesi RLS'li | ✓ / ⚠ | Liste senkron (`config/tenancy.php:90-92`, chunk2 §2.8). **Ama müşteri ailesinin işletme mekaniği yok**: Gate bağlaması, cache, TenantContext etkileşimi, tenant-başına tanım tohumlama → **F-6** |
| chunk3 §3.6 N-2 devri | ✓ | kriter 7d tek yer (chunk6:173); chunk3 11b'nin düşürüldüğü doğrulandı (chunk3:300) |
| chunk3 kriter 34 — `OfficeAuditFeed` orphan kapanışı | ✓ | kriter 16 (chunk6:183); chunk3:333 ve `docs/issues.md:84` bağı doğrulandı. İşletilebilirlik açık sorusu aşağıda (Açık soru 1) |
| chunk4 kriter 5 devri — özel nitelikli belge izni | ✓ | kriter 17 (chunk6:184); chunk4:115 doğrulandı |
| chunk4 kriter 8 / D-3 devri — bağlantı üretimi izni | ✓ | kriter 18 (chunk6:185); chunk4:118 doğrulandı |
| chunk5 kriter 7 devri — U-1 + step-up | ✓ | kriterler 7b, 7c (chunk6:171-172) |
| chunk5 kriter 8 devri — U-5 yetki değişikliği | ✓ / ⚠ | kriter 15 (chunk6:181); ama atama **yüzeyinin** (hangi panel, hangi rota) tarifi yok → **F-7** |
| chunk5 §5.1.0 — `CreateCustomer` orphan kapanışı | ⚠ | kriter 15a var (chunk6:182) ama izin tanımsız, panel adlandırılmamış, audit bağı yok → **F-4**; index istisna listesi güncellenmemiş → **F-3** |
| Index "Kapsam dışı" istisna listesi ↔ kriter 15a beyanı | ❌ | Kriter 15a *"istisna listesine eklenir"* diyor (chunk6:182); index:86 hâlâ yalnız "panel iskeleti, giriş akışı ve backoffice'in omurga ekranları" → **F-3** |
| Index sürüm damgası ve upstream pin | ❌ | index:3 "Sürüm 2.5" (revizyon geçmişi 2.7'ye kadar gidiyor, bu turun girdisi de yok — R4-1 kuralı); index:5 "Upstream (kilitli): v1.10" oysa chunk5/6 v1.11'e dayanıyor ve v1.11 onaylı → **F-12** |
| Kriter sıralaması 2a/2b/2c | ✓ | chunk6:163-165 — düzeltme doğrulandı |

---

## ✅ What works

- **§6.5'in ana düzeltmesi doğru ve doğru yönde.** Teslim edilen `SessionScopeResolver` (ofis → boş liste, yüksek sesle düşme) chunk2 §2.8.1'in **zaten onaylanmış** düzeltme notuyla birebir; plan artık kodla ve kendi upstream'iyle aynı şeyi söylüyor. "Tüm tenant'ları veren vekil" alternatifi chunk2 turunda gerekçesiyle reddedilmişti; onu diriltmek doğru olmazdı. Sonucun (ofis bugün hiçbir tenant verisine erişemez; ilk dikey Spec 3'ü bekler) gizlenmeyip açıkça yazılması da doğru — bu bedel yeni değil, chunk2 §2.8.1'de kabul edilmişti.
- **MFA'nın ikiye ayrılması spec'in yapısını birebir izliyor.** §5.2'nin iki hükmü iki ayrı katmanda; alan bazlı olanın chunk5'te kapandığı iddiası dosyadan doğrulandı (chunk5 §5.7(b), kriter 24). Tek kuralı iki kapanışa bölmeme disiplini (F-13 emsali) doğru uygulanmış.
- **Üç izin ailesinin şema ayrımı ve bağlam sınıflandırması tutarlı:** chunk2 §2.8 kesin listesi, `config/tenancy.php` ve §6.1 üçü aynı şeyi söylüyor; müşteri ailesinin RLS'li olması "firma kendi yetki yapısını kurar" (çatı §9, spec §3.0) hedefiyle uyumlu.
- **Aynı adlı izinlerin iki ailede iki anlam taşıması** (`user.assign_permissions`) açıkça yazılmış ve kriter 2c ile sınanıyor — sessiz karışma riski adreslenmiş.
- **Devir zincirleri sağlam:** 7d (N-2), 16 (OfficeAuditFeed), 17/18 (chunk4), 7b/7c/15 (chunk5) — hepsinin upstream ucu dosyadan doğrulandı, çift kayıt yok, "tek yer" işaretleri doğru.
- **`system.access_backoffice`'in tamamen sökülmesi** ve dizge kontrolünün tek yerde (2a) toplanması AD-09 v1.11 ile tam uyumlu.

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

**F-1 — §6.5 hâlâ kendi içinde çelişiyor: P-7 gerekçe bloğu düzeltilmemiş.** chunk6:98-100 "ofis kimliği boş liste alır, kod haklı, plan düzeltildi" diyor; dört satır aşağıda P-7 kısıtının gerekçesi hâlâ *"geçici çözüm ofis kimliğine **tüm tenant'ları** verir. Spec 3 gelmeden prod'a çıkılırsa her satışçı her müşteriyi görür"* (chunk6:108). Bu, bu turun düzelttiğini iddia ettiği çelişkinin ta kendisinin bölüm içinde yaşamaya devam etmesidir. Kriter 9 bu kısıtı `docs/issues.md`'ye ve chunk9 rollout listesine yazdıracak — bugünkü metinle **yanlış gerekçeyle** yazılır.

**F-2 — `docs/issues.md:45` plana aykırı: "Chunk6 `TreeScopeResolver` ile kapanır".** Chunk6'ya göre `TreeScopeResolver` **Spec 3'ün** ürünüdür (chunk6:106, 110); chunk6 onu üretmez. Kriter 8 "geçici implementasyon `docs/issues.md`'de açık kalem" diye bu dosyaya dayanıyor; dayanılan kalem, implementer'a chunk6'nın TreeScopeResolver teslim etmesi gerektiğini söylüyor.

**F-3 — Index "Kapsam dışı" istisna listesi güncellenmemiş.** Kriter 15a *"kapsam sınırındaki 'bu plan iş ekranı üretmez' istisnalarına eklenir"* diyor (chunk6:182) ve bu turun beyanı "index'e eklendi" idi; index:86'daki liste müşteri açmayı **içermiyor**. "Plan kanundur — burada yazmıyorsa yapılmaz" (index:12) ilkesinde, index'i okuyan implementer müşteri açma ekranını üretemez; kriter 15a ile index birbirini yalanlıyor.

**F-4 — Kriter 15a'nın izin, panel ve audit zemini tanımsız.** (a) **İzin yok:** kriter "bir izin kontrolüyle birlikte çağrılıyor" der ama izni adlandırmaz; chunk2 §2.8 `customers` INSERT istisnasının yetki ayağını açıkça *"`customer.create` izni, chunk6"* diye bu chunk'a adresler; §6.2'nin üç listesinin hiçbirinde müşteri oluşturma izni yoktur. (b) **Panel adlandırılmamış:** "müşteri açma ekranı"nın backoffice mi ofis mi olduğu hiçbir yerde yazmıyor (chunk5:66 "backoffice/ofis işidir" diye açık bırakmıştı). İki ihtimal de bugünkü planla çatışıyor: ekran **backoffice** ise chunk9 S-19 allowlist'i ("müşteri tablosu kaynağı kaydedilirse build kırılır") ve spec kriter 37 ile çelişir, ayrıca index devir tablosundaki kriter 33 yükümlülüğü tetiklenir — *"backoffice'ten tenant verisine yol açan belge, log bağını kendi kabul kriterine yazar"* (index:78) — ve kriter 15a'da log bağı yoktur; ekran **ofis** ise ofis ailesinde izin karşılığı yok ve boş ofis kapsamıyla (§6.5) ekranın oluşturma sonrası davranışı (yazılan müşteri hiçbir sorguda görünmez) tanımsız. (c) **Audit bağı yok:** müşteri (tenant) oluşturma spec §7.1 kapsamında kritik işlemdir; kriter yalnız reverse-grep istiyor.

**F-5 — `ScopeResolver` arayüz belirsizliği.** §6.5 arayüzü iki metotla tanımlıyor (`accessibleTenantIds` + `scopeLevel`, chunk6:91-94); teslim edilen arayüzde yalnız birincisi var (`app/Domain/Authorization/ScopeResolver.php:27`) ve plan "bugünkü implementasyon `SessionScopeResolver`'dır" diyor. `scopeLevel`'ın bu chunk'ta mı ekleneceği, eklenecekse `SessionScopeResolver`'ın (müşteri/ofis/backoffice kimlikleri için) ne döndüreceği, kimin tüketeceği yazılı değil. "Plan kanundur" ilkesinde implementer bu kararı kendisi veremez.

**F-6 — Üç izin ailesinin zorlanma mekaniği planda yok.** §6.1 spatie'yi yalnız ofis ailesi için bağlıyor (`model_type = App\Models\User`); backoffice ve müşteri aileleri "ayrı tablolar" olarak tanımlanıyor ama **nasıl işledikleri** tanımsız: (a) bu iki ailenin `Gate`/`can()` zincirine nasıl bağlandığı (spatie tek tablo seti yapılandırır; iki aile için hangi bileşen izin sorusunu cevaplıyor?) yazılı değil — kriter 2c'nin ("bir ailenin izni diğer ailenin Gate kontrolünde sonuç üretmiyor") sınayacağı mekanizma ortada yok; (b) müşteri ailesi tenant-kapsamlı + RLS'li: izin sorgusunun hangi iş birimi içinde koşacağı (RLS'li tabloya SELECT, transaction içi `SET LOCAL` bağlam ister — AD-04) yazılı değil; (c) izin **cache** stratejisi yazılı değil — spatie'nin global tek anahtarlı izin cache'i tenant-kapsamlı tabloyla ya çapraz-tenant sızıntı ya sürekli yanlış küme üretir; müşteri ailesi spatie dışıysa da cache kararı yine yazılmalıdır; (d) müşteri izin **tanımlarının** tenant-kapsamlı tabloda nasıl doğduğu yazılı değil — kriter 3 "izinler seed ile" diyor ama global seed, RLS'li tabloda **sonradan açılan tenant'ları** kapsayamaz; yeni tenant açılışında o firmanın izin/rol tanımlarının nereden geleceği plansız.

**F-7 — Kriterlerin şart koştuğu yüzeylerin plan gövdesinde karşılığı yok.** Kriter 15a bir müşteri açma **ekranı**, kriter 16 `audit.view` ile kapılı bir **ofis uç noktası**, kriter 2b en az bir yetki-kapılı **backoffice menü/rota** (bugünkü panelde kayıtlı resource yok — `BackofficePanelProvider` discover yolu boş), kriter 15 müşteri tarafında bir **yetki atama yolu** gerektiriyor. §6.1–§6.8'in hiçbiri bu yüzeyleri tarif etmiyor: dosya/rota/component/izin eşlemesi yok. Component/file breakdown'u olmayan kriter, "plan kanundur" rejiminde implementer'ı plan dışına çıkmaya zorlar.

**F-8 — Backoffice yetki/rol değişikliğinin audit'i planlanmamış.** Spec §7.1 kapsam listesi "yetki değişikliği"ni sayar (spec:272; kırmızı çizgi 13); kriter 2b backoffice içi atama yolunun **varlığını** sınıyor; ama §6.8 yalnız `CustomerUserPermissionsChanged` ve `UserPermissionsChanged` olaylarını tanımlıyor (chunk6:156). Backoffice kullanıcısına izin/rol verme-kaldırma için ne olay ne audit yazımı planda var.

**F-9 — Spec kriter 32'nin ofis bacağı (Y-5) kanıtsız.** Kriter 2b'nin kendi parantezi *"kanıt üç alanda ayrı ayrı istenir"* der (chunk6:164); müşteri kanıtı 7b, backoffice kanıtı 2b — **ofis kanıtı yok**. Bu turun sunumundaki "ofis arch testi" atfı §6.3(2)'nin Action-authorize taramasıdır; Y-5'in konusu olan menü render'ı ve rota erişimini kapsamaz. Kriter 16 bir ofis rotası doğurduğu için ölçülecek yüzey bu chunk'ta var; buna rağmen ne kriter ne devir kaydı yazılmış.

**F-10 — R-1 alfabesi kendi kuralını ihlal ediyor.** chunk6:139 alfabeyi `23456789BCDFGHJKLMNPQRSTVWXYZ` olarak veriyor — dizge **L içeriyor**; aynı satır "harf O/I/L … hariç" diyor ve spec R-1 ile AD-19 L'yi açıkça yasaklıyor. Kriter 12'nin "alfabede yasak karakter yok" testi bu dizgeden yazılırsa hata testle birlikte kalıcılaşır.

**F-11 — Ofis ailesindeki `audit.view_access_log` spec §7.5 ile çelişiyor.** §7.5 tablosu erişim logunu ofis için "Görünmez" olarak sabitler (spec:302); L-1 müşteri kimliklerinin denetim izinin ofiste hiçbir ekranda yer almadığını söyler. §6.2 bu izni **ofis** ailesinde tanımlıyor (chunk6:38). Bu, `system.access_backoffice` ile aynı sınıftan bir iki-alan-modeli kalıntısı görünümündedir: erişim logu okuma yetkisinin yaşayabileceği tek alan backoffice'tir.

**F-12 — Index'in kilit beyanı ve sürüm damgası gerçeği yansıtmıyor.** index:3 "Sürüm 2.5 · 26.07.2026" — revizyon geçmişi 2.6 ve 2.7'yi içeriyor ve bu turun chunk6 düzeltmesinin (27.07.2026) girdisi hiç yok; R4-1 kuralı ("sürüm damgası ile revizyon girdisi tek adımda atılır") üçüncü kez deliniyor. Daha önemlisi index:5 upstream'i **v1.10** olarak kilitli gösteriyor; chunk5/6'nın fiilen dayandığı ve onaylı olan sürüm **v1.11**. "Plan kanundur" belgesinin kilit beyanı yanlış spec sürümünü gösteriyor.

**F-13 — Yüzeyi olmayan spec kuralları ve yeni orphan'lar adressiz.** Index devir kuralı açık: *"ölçülecek yüzey doğmadığı için kriter olamayan kural ertelenmiş sayılır ve adresi burada yazılır; adressiz erteleme chunk9 meta-kuralına takılır"* (index:74). Buna rağmen: (a) **V-3'ün çatışma yarısı** (davetten çıkarılan firmada kayıtlı katılımcı → kullanıcıya bildir, karar iste) hiçbir chunk'ta ve devir tablosunda yok; (b) **R-7'nin "her panelde koda göre arama"** yüzeyi kayıtsız — e-posta araması için aynı sınıftan devir kaydı açılmışken (index:80); (c) chunk6'nın üreteceği `VisibilityRule`, `ReferenceCode`, `FindByReferenceCode` **omurga kapsamında production caller'sız** doğacak (eğitim/teklif entity'si ve arama ekranı yok) ve plan bunları bilinçli orphan olarak adlandırmıyor — oysa emsalleri (`OfficeAuditFeed`, `CreateCustomer`) Sets kararı + `docs/issues.md` kaydı + kapanış kriteri üçlüsüyle kabul edilmişti.

**Not (blocker değil — typo/format sınıfı):** kriter 15a'da "…müşteri açma).Bir izin" boşluk hatası (chunk6:182); index:68 P-7 satırı kısıtın adresini "chunk6 §6.4" gösteriyor, kısıt §6.5'te.

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

1. **Kriter 16'nın ofis uç noktası bugünkü boş ofis kapsamıyla işletilebilir mi?** `OfficeAuditFeed` "ortam kapsamıyla normal `TenantContext::run()` içinde koşar" (chunk3 B-7) ve ofis kimliğinin ortam kapsamı bugün **boş liste**. Boş listeyle iş birimi açılabiliyor mu, `audit_*_select` politikaları NULL-tenant satırlarını kapsamsız bir ofise hangi dalla veriyor — planda yazılı değil. Yazılmadan kriter 16'nın bu chunk'ta karşılanabilirliği belirsiz.
2. **Müşteri açma ekranının turu ve paneli Sets kararı gerektiriyor** (developer sorusu 2). Hangi turda olacağı reviewer'ın kararı değil; ancak bugünkü yazımıyla kriter 15a uygulanabilir değil (F-3, F-4) — karar hangi yönde çıkarsa çıksın, kriterin dayandığı izin/panel/audit/index dörtlüsü o kararla tutarlı hale gelmek zorunda.
3. **Tüketicisi olmayan izinler** (developer sorusu 3): seed'lenen izin bir **tanım verisidir**, kod sembolü değil — wire/orphan kuralının konusu değildir ve tek başına bulgu değildir. Gerilim yalnız şurada gerçek: chunk6'nın kendi ürettiği yüzeyleri kapılayan izinlerin tüketicisi bu chunk'ta doğmak zorunda (F-7) ve müşteri ailesinin tanımları tenant-kapsamlı tabloda "seed" kavramını zorluyor (F-6d).
4. **Kriter 2b'nin yüzeyi** (developer sorusu 4): kriter, en az bir yetki-kapılı backoffice yüzeyi olmadan sınanamaz; bugünkü panelde kayıtlı resource yok. Yüzey bu chunk'ta mı doğar, kriter mi ertelenir — karar developer/Sets'in; bugünkü plan ikisini de yazmıyor (F-7). Ertelenirse index devir kuralı gereği adres yazılmak zorunda.
5. **§6.5 yönü** (developer sorusu 1): yön doğru — chunk2 §2.8.1'in onaylı düzeltmesiyle ve teslim edilen kodla tutarlı; alternatif zaten o turda gerekçesiyle reddedilmişti. "Dikey geliştirmenin önünü açan ara çözüm" sorusu Spec 3'ün zamanlama kararıdır, bu planın değil. Kalıntılar (F-1, F-2) temizlenmeli.
6. **Spatie cache / müşteri ailesi** (developer sorusu 5): evet, eksik — F-6'nın (a)–(d) bacakları.

## ⚠️ Upstream Findings

Yok. F-11 spec ihlali görünümündedir ama spec'te değil plandadır; spec §7.5 nettir ve plan ona çekilmelidir. Spec'e dönüş gerektiren bulgu çıkmadı.

## Verdict: ❌ REJECTED

Matrix'te üç ❌ (F-3/F-4 zemini, F-11, F-12) ve altı ⚠ satır var; on üç bulgu açık. Revizyonun kalbi olan §6.5 düzeltmesi doğru yönde ve upstream'le tutarlı — ama düzeltmenin yarım kaldığı iki yer (P-7 gerekçe bloğu, issues.md kalemi) tam olarak bu turun kapatmayı iddia ettiği çelişkiyi yaşatıyor; kriter 15a'nın beyan ettiği index güncellemesi yapılmamış; müşteri açma işinin izin/panel/audit zemini tanımsız; üç izin ailesinin işletme mekaniği (özellikle tenant-kapsamlı müşteri ailesi) plansız; ve ofis ailesindeki erişim logu izni spec §7.5'in açık hükmüyle çelişiyor. Bunlar çözülmeden implementasyona başlanamaz.