# Review — docs/plans/sube-plan.md v1.1 — 20.10.2026

> **Review type:** plan-re-review
> **Previous review:** `docs/reviews/review-sube-plan-2026-10-20.md` (heyet 820, REJECTED, F-1…F-5)
> **Upstream document(s) read:** `docs/specs/sube-spec.md` v0.6 (heyet 819 APPROVED) — tamamı, sıfırdan yeniden okundu
> **Other cross-referenced documents:** `proje-haritasi.md` §4.4 · `CLAUDE.md` (17 kırmızı çizgi) · kod doğrulamaları (bu turda koşuldu): `app/Actions/Backoffice/UpdateBusinessSettings.php:80,235,247` (yazma yolu, `company.*` anahtarları), `app/Filament/Backoffice/Pages/BusinessSettings.php:104,483,578` (`letterhead_min_width_px` alanı), `app/Support/Business/Settings.php:150-157` (`letterheadMinimumWidth()`, kırmızı çizgi 9 referanslı docblock), grep ile `companyLetterhead`/`'company.'` okuyan tüm yerler (dört kimlik okuyucusu + bu beşinci ayar)
> **Stage locks in effect:** Spec locked (v0.6, heyet 819); spec kararları tartışılmadı. 820'nin bulgu kapsamı dışındaki önceki onaylı kısımlar da kilitli; bu turda yalnız F-1…F-5'in karşılıkları ve onların yarattığı yeni yüzey değerlendirildi.

---

## Upstream Coverage Matrix

(Sıfırdan üretildi.)

| Upstream § / madde | Plan'da durumu | Kanıt |
|---|---|---|
| §9.2 şirket değiştirme — teklif ve faturada **aynı**, yeteneğe bağlı olmayan tek yetki | ✓ | "Yetki değişiklikleri" tablosu: tek `issuer.choose`, "bağlı değil"; A5 testi ikisini birlikte kapsıyor (820 F-1 kapandı) |
| §9.1 şirket kimliğinin tek kaynağı (tüm okuyucular aynı yere bağlanır) | ⚠ | A5 adım 1 dört kimlik okuyucusunu (QuotePrintout/SendQuote, FrameworkContractPrintout, yoklama anteti, `BusinessSettings`/`companyLetterhead()`) doğru tek kaynağa bağlıyor (820 F-2 bu dört yer için kapandı) **ama** arch testinin kapsamı ("company. anahtarını IssuingCompany dışında okuyan kod yok") bu dört okuyucudan bağımsız, aynı önekte duran **ilgisiz bir ayarı** (`letterhead_min_width_px`) da süpürüyor → **F-1 (yeni)** |
| §4 kapanış akışı — açık teklif ve potansiyel müşterinin de sayılması/sorulması | ✓ | `Unwinding` artık "bu düğümlerin üyelerine ait açık teklifler ve açık potansiyel müşteriler"i listeliyor; `CloseBranch`/`RemoveBranchCapability` devir sorusu + "sahibinde kalsın" seçeneği; A7 testleri her türü ayrı senaryo olarak sayıyor (820 F-3 kapandı) |
| Migration sırası — `branches.issuing_company_id` ↔ `issuing_companies` | ✓ | Veri modeli artık FK'yı A1'den çıkarıp A5'e taşımış, backfill + `NOT NULL` adımı açık yazılı (820 F-4 kapandı) |
| Kriter 2 — Talep satırının testi | ✓ | A1 kriter listesine "talep" eklendi, A1 test listesinde `TrainingRequestQueue` ayrı senaryo (820 F-5 kapandı) |
| Diğer tüm §1–§12 maddeleri (önceki turda ✓ işaretlenmiş, bu turda dokunulmamış) | ✓ | Değişmedi; bu turun kapsamı dar (P-1'in veri modeli bölümü, "Yetki değişiklikleri" tablosu, A1/A5/A7 metinleri, revizyon) |

---

## ✅ What works

- **820'nin beş bulgusunun beşi de doğru ve eksiksiz kapandı.** F-1 tek yetkiyle (`issuer.choose`, yeteneksiz) spec'in iki cümlesini (§9.2 "aynı yetkiyle", §11.1 "yeteneğe bağlı değildir") birebir karşılıyor. F-2'nin çözümü titiz: dört okuyucunun her birinin hangi kuralla (teklifin kendi şirketi vs. varsayılan şirket) besleneceği ayrı ayrı gerekçelendirilmiş — çerçeve sözleşme ve yoklamanın "varsayılan şirket" kalması bilinçli bir seçim olarak işaretlenmiş ("spec'te yoktur ve istenirse ayrı karardır"), spec'in ötesine geçmiyor. F-3'ün çözümü, spec'in "kişi nereye, iş kime" ayrımını doğru yakalamış ("sahibinde kalsın" seçeneği dahil). F-4 migration sırasını düzeltmiş ve backfill+NOT NULL adımını açıkça yazmış. F-5 talep kuyruğunu A1'in hem kriter listesine hem test listesine eklemiş.
- **F-2'nin dört okuyucu iddiası kodla bire bir doğrulandı:** `grep` ile `companyLetterhead`/`'company.'` kullanılan tüm yerleri tazeden taradım; plan'ın saydığı dört yer (TrainingController, FrameworkContractPrintout, QuotePrintout, BusinessSettings/Settings) gerçekten yegâne okuyucular — beşinci bir kimlik okuyucusu yok.
- Hiçbir düzeltme önceki onaylı bölümleri (A2, A3, A4, A6, rollout/rollback) bozmadan, dar kapsamlı yapılmış.

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

**F-1 — F-2'nin düzeltmesi, ilgisiz bir ayarı (`letterhead_min_width_px`) yanlışlıkla kapsıyor.** A5 adım 1: *"Backoffice `BusinessSettings` sayfasındaki `company.*` alanları **kaldırılır**... Arch testi: `company.` ayar anahtarını `IssuingCompany` dışında okuyan kod yok."* Bu ifade `company.*` önekindeki **her** ayarı hedefliyor. Ama `company.letterhead_min_width_px` (`config/business.php`, `Settings::letterheadMinimumWidth()`, `app/Support/Business/Settings.php:150-157`) şirketin yasal kimliğiyle (unvan/VKN/antet) **ilgisi olmayan**, görseldeki antet yüklemesinin minimum genişliğini belirleyen bağımsız bir admin-ayarıdır — kendi docblock'u bunu kırmızı çizgi 9'a (hardcode iş kuralı yasağı) referansla açıkça söylüyor. Bu alan `issuing_companies` veri modelinde de yoktur (A5'in tablo tanımında yalnız unvan/vergi dairesi/no/adres/telefon/seri/ibare var), yani taşınacağı yeni bir yer de tanımlanmamış. Plan'ın hem "`company.*` alanları kaldırılır" ifadesi hem de arch testinin kapsamı bu ayarı da süpürür ve `UpdateBusinessSettings.php:80,235` (yazma yolu) ile `BusinessSettings.php:483` (form alanı) kaldırıldığında, bu **admin-tanımlı olması zorunlu** (kırmızı çizgi 9) ayar düzenlenemez hâle gelir — spec'in hiçbir yerinde istenmemiş bir yan etki.

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

Yok (önceki turun açık sorusu — fiyat listesi alıntısı — spec aşamasında kalmıştı, plan review'un kapsamı dışında).

## Previous Findings Status

- 820 F-1: ✅ Resolved — tek `issuer.choose` yetkisi.
- 820 F-2: ✅ Resolved (dört okuyucu için) — ⚠ ama çözüm yeni bir finding'e yol açtı (F-1, yukarıda).
- 820 F-3: ✅ Resolved — `Unwinding` + devir soruları + ayrı test senaryoları.
- 820 F-4: ✅ Resolved — FK A5'e taşındı, backfill + NOT NULL.
- 820 F-5: ✅ Resolved — talep kuyruğu A1'de.

## ⚠️ Upstream Findings

Yok.

## Verdict: ❌ REJECTED

Önceki turun beş bulgusunun beşi de doğru şekilde kapandı — bu gerçek bir ilerleme ve çözümlerin dördü (F-1, F-3, F-4, F-5) yeni bir sorun üretmedi. Ama F-2'nin çözümü, "company.* alanları kaldırılır" ve arch testinin kapsamını kimlik alanlarıyla sınırlamadığı için, spec'in hiç bahsetmediği ve kırmızı çizgi 9 uyarınca admin-tanımlı kalması gereken bağımsız bir ayarı (`letterhead_min_width_px`) da düzenlenemez hâle getiriyor. Tek bulgu da olsa scope içindeki her bulgu REJECTED sebebidir.