# Review — Müşteri portalı ve teklif dikeyi (brainstorming, round 3) — 2026-07-31

> **Review type:** brainstorm-review (re-review)
> **Previous review:** `review-musteri-portali-brainstorm-2026-07-31-r2.md` (REJECTED, 4 bulgu)
> **Upstream document(s) read:** N/A (top-level)
> **Other cross-referenced documents:** `docs/arch/mimari-kararlar.md` AD-11, AD-19, AD-20, AD-23 · `docs/specs/planlama-spec.md` P-37 · `docs/design/planlama-talebi-brief.md` · `docs/design/34-ek-not-gorunurluk-kapsami.md` · `proje-haritasi.md` §EGT-74 · `design/34 Planlama Talebi.dc.html` (varlık)
> **Stage locks in effect:** None

---

## Önceki bulguların kapanış doğrulaması

| # | İddia | Bağımsız doğrulama |
|---|---|---|
| F-R1 | K-24 daraltıldı, AD-20 revizyonu düştü | ⚠ **Yarım kapandı.** K-24'ün yeni hali (satır 91) ve G6 (satır 140–142) tutarlı ve AD-20 §1 ile uyumlu — üstelik "sahibine bildirim" AD-20'nin kendi karar metninde zaten var (*"satışçıya bildirim düşer"*, AD-20 satır 216), yani upstream ayağının düşmesi doğru. **Ama G8 satır 164 eski metni aynen taşıyor** → F3-1 |
| F-R2 | "✓ hazır" üç yerde hizalandı | ⚠ §1 (satır 28), K-19 (satır 92) ve G6b (satır 150) düzeltildi ✓ — ama **§2 harita satırı 43 atlandı** → F3-3 |
| F-R3 | K-29 kararı alındı | ✓ Kapandı (içerik olarak) — aşağıda soru 2 değerlendirmesi. ⚠ K-29'un karar tablosunda satırı yok → F3-2 |
| F-R4 | K-22b yazıldı | ✓ Kapandı. Satır 89: desen `invoices` + `correspondence_threads` + satışçı talebine genellenmiş, AD-20'nin "yazışma kayda bağlanır" kuralıyla tutarlı |
| Açık soru | K-30 | ✓ İçerik olarak kapandı — aşağıda soru 3. ⚠ K-30 brainstorm'da hiç geçmiyor → F3-2 |
| Notlar | §139 atfı · K-23 kaynağı | ✓ İkisi de düzeltildi (satır 120, satır 90) |

## İstenen dört kontrol

**1 · F-R1 gerçekten kapandı mı — HAYIR, bir yerde eski okuma kaldı.** K-24 (satır 91), G6 (satır 140–142) ve AD-20 §1 üçlüsü kendi içinde tutarlı: mail görünürlük + bildirim üretir, kayıt durumu üretmez, aksiyonu insan alır. Ancak **G8 satır 164** round 2'nin metnini aynen taşıyor: *"⛔ Maille gelen cevap durum üretir (K-24): thread'e düşmekle kalmaz, teklifi 'müşteriden yanıt var' haline getirir"* — K-24'ün yeni halinin tam zıddı. Ayrıca **proje-haritasi.md:393** de eski özeti taşıyor (*"Maille gelen cevap durum üretir"*). → F3-1

**2 · K-29 × AD-11 / kırmızı çizgi 12 — evet, yeterince ayrışmış.** G9 satır 173 üç unsuru da açıkça söylüyor: iptal silme değildir; kesilmiş fatura kritik kayıttır; iptal bir **statü ve gerekçedir**, yeni fatura öncekiyle bağını taşır. Bu, kırmızı çizgi 12'nin "iptal/revizyon (AD-11)" istisnasının doğru uygulanışıdır ve egitmen-spec K-25'in (ödeme kaydı silinmez) kurduğu emsalle aynı desendir. İhlal ya da muğlaklık yok.

**3 · K-30 × AD-23 / `groups` / P-37 — çelişmiyor.** Kapsam, mevcut ofis kullanıcı ağacına (`groups` ✓) ve AD-23'ün kapsam seviyeli yetki modeline oturuyor; yeni kavram icat edilmemiş. P-37 ile bileşim de tutarlı çözülmüş (`34-ek-not` §3): firmalı/kapalı talepte P-37'nin "atandığı firmaların talepleri" kuralı, firmasız açık talepte "kapsamına dahil olduğu açık talepler" — iki eksen çakışmıyor, tamamlıyor. K-9'un "hangi satışçının teklifi olduğunu görmez" kuralıyla da çatışma yok (farklı nesne, farklı bilgi). ⚠ Tek iş: planlama-spec P-37'nin metni hâlâ yalnız firma eksenini biliyor — talep tablosu yeniden kurulurken spec revizyonuna K-30 kırılımı işlenmeli (aşağıda Upstream, not düzeyi).

**4 · Otuz kararın çapraz taraması.** Tutarlı bulunanlar: K-24(yeni) × K-17 (revizyon isteği insan eliyle işlenir — çelişki kalmadı) · K-25 × K-29 (tamamlayıcı: onay faturayı doğurur, iptal/revize saha gerçeğini karşılar) · K-20 × K-29 (teyitte asılı kalem faturayı bekletmez — R2 F-R3'ün cevabı) · K-26 × K-30 (K-30 "açık"ın satışçı-içi kırılımı, K-26'nın müşteri sınırına dokunmuyor) · K-22 × K-22b × AD-20 · K-26 × 4b (erteleme kapsamı genişletir, iptal etmez). Çelişki iki yerde ve ikisi de aşağıda bulgu: G8'in eski K-24 metni (F3-1) ve karar tablosunun kayıp satırları (F3-2).

---

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

**F3-1 · G8 eski K-24 metnini taşıyor — belge kendi kararıyla çelişiyor.** Satır 91 K-24: *"maille gelen cevap… kaydın durumunu değiştirmez"*; satır 164 G8: *"Maille gelen cevap durum üretir (K-24)… teklifi 'müşteriden yanıt var' haline getirir"*. Aynı karar numarasına iki zıt metin — G8'i okuyan spec yazarı teklife mail kaynaklı bir durum geçişi koyar ve AD-20 §1'i deler. **proje-haritasi.md:393** de aynı eski özeti taşıyor; harita bakım kuralı ("karar alındığında aynı turda işlenir") gereği o satır da güncellenmeli.

**F3-2 · K-25…K-30 karar tablosundan kayıp — round 2'ye göre regresyon.** §3 tablosu K-22b ve K-24 eklenirken **K-25, K-26, K-27, K-28 satırlarını kaybetmiş** (round 2'de dördü de tablodaydı); **K-29 ve K-30 ise tabloya hiç girmemiş**. Bugünkü durumda: K-25/K-26/K-29'un tanımı yalnız G9/G11 gövde metninde gömülü; K-27 ve K-28 belgede **hiç geçmiyor** (K-28'in içeriği G6'da K-24'e atfedilmiş, numarası kaybolmuş); K-30'un tanımı yalnız `planlama-talebi-brief.md:52` ve `34-ek-not`ta. Kullanıcının "otuz karar" dediği kümenin altısı karar arşivinde numaralı satır olarak yok — *"spec yazılırken kaybolacak karar kalmasın"* kriterinin doğrudan ihlali: "K-27 nedir?" sorusunun bu belgede cevabı yok.

**F3-3 · §2 harita satırı 43 hâlâ "`training_requests` ✓"** — F-R2 düzeltmesinin dördüncü yeri atlanmış. §1 "⚠ yarım", K-19 "şekli yetmiyor", G6b "yeniden kurulacak" derken harita "✓ + `TrainingRequestPolicy` ✓, ekranı yok" diyor. Satır 98'in "birebir eşleşir" taahhüdü içerik için de geçerli olmalı. *(Düşük; bağlantılı not: satır 216 "training_requests hazır olduğu için" G5/müşteri tarafı için savunulabilir — müşteri talebi tenant-kapsamlı kalıyor, brief §6 bunu açıkça koruyor.)*

## ⚠️ Upstream Findings

- *(Not düzeyi — spec revizyonu zaten planlanan işin içinde)* planlama-spec §2.3/P-37, K-30'un kapsam kırılımını (tüm satışçılar / grup / seçili kişiler) bilmiyor; talep tablosu yeniden kurulurken P-37 revize edilmeli.

## Notlar (blocker değil)

- **AD-19 notunun kapsamı dar:** `TLP-2026-0094` yalnız **üç harf** yönünden değil, **ardışık görünümlü numara** yönünden de AD-19'a aykırı (kural: rastgele `XXXX`; sıra numarası iş hacmi sızdırır, tasarımdaki sıralı format daha önce de bu karara göre düzeltilmişti). "Mockup metni bu yönüyle geçersiz" ifadesi iki yönü de kapsamalı — kod tarafı zaten AD-19'a göre yazılacaksa da karar arşivinde yarım kalması spec'e sıralı örnek taşıtabilir.
- `34-ek-not`un P-37 çözümü (madde 3) ve tasarımcının sorgulama-bağı eklemesinin kabulü belgeye/haritaya işlenmiş ✓; `34 Planlama Talebi.dc.html` mevcut ✓.

## Verdict: ❌ REJECTED (dar — üç bulgunun üçü de metin/arşiv düzeltmesi, yeni karar gerekmiyor)

İstenen dört kontrolün üçü olumlu: K-29'un AD-11/kırmızı çizgi 12 ayrımı açık; K-30 mevcut kapsam modeliyle çelişmiyor (P-37 bileşimi de çözülmüş); AD-20 revizyonunun düşmesi doğru karar. Verdict'i düşüren şey F-R1'in yarım kapanmasıdır: **G8 satır 164 ve proje-haritasi:393 eski "durum üretir" metnini taşıyor** — aynı karar numarasına iki zıt metin, spec yazarı için en tehlikeli türden tutarsızlık. İkincisi **karar tablosu regresyonu**: K-25…K-30'un altı kararı arşivde numaralı satır olarak yok, ikisi (K-27, K-28) belgeden tamamen düşmüş. Üçüncüsü tek satırlık kalıntı (§2:43). Üçü kapanınca belge spec aşamasına hazırdır — karar kümesinin kendisinde çelişki kalmadı.