# Re-Review — Plan: Platform Omurgası v2.3 (EGT-21) — 25.07.2026

> **Review type:** plan-review (re-review, M1/M2 kapanış doğrulaması)
> **Reviewed:** `git diff 21647ed..97c1bc5` (index, chunk2, chunk3) — başka dosyaya dokunulmadığı diff'ten teyitli; diğer chunk'lar için v2.0-v2.2 okumaları geçerli
> **Upstream (kilitli):** spec v1.7 APPROVED · AD-01…AD-28
> **Previous review:** `review-omurga-plan-2026-07-25-r4.md` (v2.2 REJECTED, M1/M2)
> **Stage locks in effect:** ⛔ sahip kararı: otomatik silme/anonimleştirme yok (uygulanmış)

---

## M1/M2 kapanış doğrulaması

| Bulgu | Doğrulama | Durum |
|---|---|---|
| M1 — `LogActivity` muafiyet dışıydı, yazım bağlamı tanımsızdı | (a) §2.5 muafiyet listesine `ActivityLogger` eklendi; "middleware yazımı doğrudan yapmaz, `ActivityLogger`'ı çağırır" cümlesi muafiyeti **bileşene** tanıyor, tabloya değil — N2'nin dar-muafiyet desenine sadık. (b) chunk3 §3.5'e kesin yazım bağlamı tablosu: müşteri isteğinde `forWrite($tenantId)` ile **kısa iş birimi** (middleware Action/Query transaction'ının dışında olduğu için kendi iş birimini açması doğru gerekçelendirilmiş — F5 semantiğinde dışta bağlam yokken yeni transaction açılır, tutarlı); ofis isteğinde NULL + §3.6 disiplini + §2.5 muafiyeti. Kriter 9b, r4'teki "gevşek garanti ≠ hiç yazılmıyor" tespitini iki kimlik alanında da ölçülebilir kritere çevirmiş. | ✅ KAPANDI |
| M2 — kriter 6 kendi istisnalarıyla çelişiyordu | Kriter 6'ya istisna tablosu eklendi; üç sapma da doğru tarif edilmiş ve her biri kendi kriterine bağlanmış (`customers` → kriter 7; `audit_writes`/`audit_access` → chunk3 kriter 2; `audit_activity` → §3.6). İstisna listesinin kendisi de denetleniyor: "listede olmayan sapma testi kırar" + **"istisna eklemek plan değişikliği gerektirir, kod incelemesiyle geçilemez"** — istisnanın sessizce büyümesi süreç düzeyinde de kapatılmış. Sapma gösteren başka tablo olmadığı kontrol edildi (magic_links ve diğer tenant-kapsamlı tablolar standart desende; bağlamsız tablolar kriter 6'nın kapsamı dışında). | ✅ KAPANDI |

## Etkileşim kontrolü

- `ActivityLogger`'ın müşteri isteğindeki `forWrite` yazımı, `audit_activity` INSERT politikasının `or_null` varyantıyla uyumlu (tek-tenant bağlam → tek değer döner → geçer); ofis isteğindeki NULL yazımı muafiyet + NULL-veya-eşleşme şıkkından geçer. Yeni çelişki üretmiyor.
- Kriter 9 ("yazılamıyorsa sayfa engellenmez") ile 9b ("gerçekten yazılıyor") çelişmez — tamamlayıcıdır; 9b tam da gevşek garantinin gizleyebileceği "hiç çalışmıyor" durumunu yakalar.
- Kriter 6 istisna tablosu, v2.2'de eklenen tüm bilinçli sapmaları eksiksiz kapsıyor; şema doğrulama testinin istisna listesini bilmesi kriter 6'yı yeniden kanıtlanabilir kılıyor.

## ⚠️ Findings & Risks

Yok.

## ❓ Open Questions

Yok.

## Verdict: ✅ APPROVED

M1 ve M2, r4'te önerilen yönde ve dar kapsamda kapatıldı; düzeltmeler yeni tutarsızlık üretmedi ve diff başka hiçbir bölüme dokunmadığını doğruluyor. Plan zincirinin bütünü: v1.0'da 9, v2.0'da 8, v2.1'de 4, v2.2'de 2 — toplam **23 bulgu** açıldı ve tamamı, çoğu canlı PostgreSQL deneyleriyle (deney 1-12) kanıtlanarak kapatıldı. Plan v2.3; iki bağımsız kimlik alanı, komut-bazlı RLS politikaları, açık iş-birimi bağlam modeli, üç sınıflı audit ve istisnaları bilinen şema doğrulamasıyla **implementasyona hazırdır**. Kalan bilinçli borçlar (SimpleScopeResolver + `app.all_customer_ids()` geçiciliği, prod çıkış kısıtı, null adaptörlerin gerçek API doğrulamaları) `docs/issues.md` ve S-9 envanteri üzerinden takipte. Son karar kullanıcınındır.