# Review — docs/specs/sube-spec.md v0.2 — 20.10.2026

> **Review type:** spec-review
> **Previous review:** N/A (ilk review)
> **Upstream document(s) read:** `proje-haritasi.md` §4.4 «Şubeler: tek merkez 3E Group» bloğu (satır 892–903) · YouTrack EGT-219 açıklaması (`youtrack.sh show EGT-219`)
> **Other cross-referenced documents:** `CLAUDE.md` (17 kırmızı çizgi) · `docs/arch/mimari-kararlar.md` AD-06, AD-09, AD-11, AD-12, AD-21, AD-23 (tam metin), AD-25, AD-26 · kod kanıtları: `config/authorization.php` (izin adları tek tek), `config/business.php` (`company.*`), `app/Http/Controllers/Office/SalesAgendaController.php`, `app/Queries/Office/FinancialOverview.php`
> **Stage locks in effect:** None (çatı design/brainstorm yok; Sets'in 19–20.10.2026 kararları kilitli — bunlar tartışılmadı, yalnız spec'in onları eksiksiz ve çelişkisiz taşıyıp taşımadığına bakıldı)

---

## Upstream Coverage Matrix

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| Harita 892: tek merkez 3E Group, şube yalnız verilen işleri yapar | ✓ | spec §2, §6 |
| Harita 893: şube yetenek setiyle kurulur, üç yetenek, sabit tip yok | ✓ | spec §2.2 |
| Harita 894: açık eğitimin şubeye görünmesi eğitim başına seçilir | ✓ | spec §7.2, kriter 6 |
| Harita 895: şube kaydı + dikey düğümler, AD-23 ağacı değişmez | ✓ | spec §2.1 |
| Harita 895: menüler şubeye göre değişmez, içerik daralır | ⚠ | spec §2.3 var; **kabul kriterlerinde karşılığı yok** → F-7 |
| Harita 896: yetenek = yetki tavanı (verilemez + verilmişse çalışmaz) | ⚠ | spec §3, kriter 3; **çok üyelikli kişide semantik tanımsız** → F-5 |
| Harita 897: şube backoffice'te kurulur | ✓ | spec §4, kriter 1 |
| Harita 898: eğitmen yeteneği olmayan şube yalnız merkezin açtığı eğitmenleri atar | ⚠ | spec §8, kriter 7, 15; **§11.1 `instructor.view`'ı Eğitmen yeteneğine bağlıyor, görme yetkisi çelişik/tanımsız** → F-6 |
| Harita 899: şubenin planladığı eğitimin görünürlüğü planlarken seçilir | ✓ | spec §7.1, kriter 5, 13 |
| Harita 900: mali — şube yetkiyle kendi tablosu, merkezde şube kırılımı | ⚠ | spec §9, kriter 8; **gider tarafının şube ataması tanımsız** → F-4 |
| Harita 901: 14 kararın spec'e işlenmesi (yetenek×yetki, kaldırma/kapatma akışı, eğitim görünürlükleri, kapsamsız eğitim, Takvimim/kokpit, genişletme onayı, merkez→şube eğitmen atama, eğitmen dosyası, gelir alanı, fatura kapsamı, fatura kesen şirket) | ⚠ | §11.1, §4, §7, §6, §9.1, §9.2, S-12 — hepsi mevcut; **§9.1 ↔ §9.2 ilişkisi çelişkili ve gelir alanının değer kümesi eksik** → F-2, F-3; **kapatma akışı fatura/şirket kimliği tarafını ele almıyor** → F-8 |
| Harita 903: şube yöneticisi yetkisi varsa kendi şubesine kullanıcı açar | ⚠ | spec §5, kriter 4; **"şube dışındaki kişiyi göremez" davranışı §6 tablosunda ve kriterlerde yok** → F-7 |
| EGT-219 kapsam 1: şube düğümleri + personel yerleştirme | ✓ | spec §2, §5 |
| EGT-219 kapsam 2: doğrudan planlanan eğitime kapsam yazılması | ✓ | spec §7.1 |
| EGT-219 kapsam 3: açık eğitimin şube personeline görünürlüğü | ✓ | spec §7.2 |
| EGT-219 kapsam 4: eğitmen kapsamı (şube bağı mı, atama yetkisi mi) | ✓ | spec §8 (ikisi birden: düğüm + eşleme + `training.assign_instructor` kapsamı) |
| EGT-219 kapsam 5: **müşteriyi açan kişinin otomatik ataması** (bugünkü durum ❌: `customer.view.all` olmayan şube satışçısı açtığı firmayı göremez — ticket, `OnboardCustomer` kanıtıyla) | ❌ | spec'te hiç yok; §6 müşteri satırı "bugünkü kural" diyerek tam da kırık davranışı spec'liyor; §12 kapsam dışı listesinde de değil → F-1 |
| EGT-219 kapsam 6: teklif, talep, takvim, arama ve raporlarda şube kapsamının her listede okunduğunun denetimi | ✓ | teklif/talep/takvim: §6 + kriter 2, 12; raporlar: §9; arama: backend global arama yok (ölçüldü: `route:list` ve `app/` grep'inde arama yüzeyi yok; `resources/js/lib/search.js` istemci tarafında, zaten kapsamlanmış listeleri süzer) |
| EGT-219 açık soru: İzmir yalnız satış mı | ✓ | yetenek seçimi cevaplıyor (§2.2) |
| EGT-219 açık soru: mali tablolar ve **fiyat listesi** şubeye nasıl görünür | ⚠ | mali: §9; fiyat listesi: §12 "istenmedi; fiyat listesi tektir" — bu bir Sets kararı olarak alıntısız duruyor → Açık Soru 2 |
| AD-23: ağaç/kapsam çözümleyicisi değişmez, güvenlik kuralı 1 (`Ceiling`) ve 2 (dört göz) | ✓ | spec §2.1, §5, §7.1 ("kimse kendi isteğini onaylayamaz") |
| AD-09 kural 2: genişletme engellenmez, onaya düşer | ✓ | spec §7.1 (yetkisiz genişletme Planlama Direktörü onayına) |
| AD-09 kural 3: backoffice mali tanım yapar, mali durum göstermez | ✓ | §9.2 şirket bilgileri backoffice'te **tanım**; mali tablolar ofiste (§9) |
| AD-06: şube yönetim eylemleri ve gelir alanı değişikliği audit'lenir | ✓ | spec §4 son satır, §9.1 |
| AD-11 / AD-23 (kırmızı çizgi 12): kapanışta kişi ve kayıt silinmez | ✓ | spec §4 "Şubeyi kapat" satırı, kriter 10 |
| AD-12: provider-bağımsız adaptör; entegratör gelince gönderici şube kimliği | ✓ | spec §9.2, §12 |
| AD-21: Takvimim/kokpit kişinin kendi verisi (kişi bazlı izleme değil — iş verisi) | ✓ | spec §6; bugünkü davranışla uyumlu (`SalesAgendaController` yalnız actor'ün verisini okur — kriter 9 ile 12 çelişmiyor, doğrulandı) |
| Kırmızı çizgi 9 / AD-08: spec'te hardcode edilmiş iş kuralı yok | ✓ | sayısal sabit yok; şirket kimliği `company.*` ayar ailesine paralel tanım |

---

## ✅ What works

- **14 kararın tamamı Sets'in cümlesiyle ve tarihle spec'te** — harita §4.4 ile birebir örtüşüyor; karar/varsayım ayrımı disiplinli.
- **§1 "bugünkü durum" tablosu koddan ölçülmüş ve doğru:** izin adlarını `config/authorization.php`'ye karşı tek tek doğruladım — §11.1 tablosundaki temel adların tamamı mevcut izinlerle eşleşiyor (`training.assign_instructor.{group,all}` dahil); uydurulmuş izin adı yok.
- **Kriter 9 ↔ kriter 12 çelişmiyor:** Takvimim/kokpit bugün de yalnız okuyanın verisini gösteriyor (`SalesAgendaController` sınıf yorumu + `SalesAgenda->for($this->actor())`); "yalnız kendisiyle ilgili" merkez görünürlüğünü değiştirmiyor.
- **§6 ↔ §7 tutarlı:** tablodaki üç eğitim satırı §7.1/§7.2'ye doğru bağlanmış; kapsamsız eğitim kararı geri dönük veri yazımını açıkça reddediyor ve Tayfun'a beyanı teslim adımına bağlıyor.
- **AD-23 omurgası korunmuş:** şube = düğüm, tavan = üyelik üstünde ek kontrol; dikey-önce ağaç ve tek kapsam çözümleyicisi değişmiyor; dört göz ve `Ceiling` doğru yerlerde anılıyor.
- Kapsam dışı üç kalemin adresi yazılı (§12), kiracı sınırı hiçbir maddede aşılmıyor (şube tamamen ofis kimlik alanında; müşteri portalı şubeyi bilmiyor).

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

**F-1 — EGT-219 kapsam maddesi 5 spec'te yok: müşteriyi açan kişinin otomatik ataması.** Ticket'ın ölçülmüş bugünkü durumu "❌ `customer.view.all` olmayan şube satışçısı açtığı firmayı göremez" (`OnboardCustomer`, `CustomerController::store`). Spec §6 müşteri satırı "yalnız kendisine atanmış firmalar (bugünkü kural)" diyerek bu kırık davranışı gereksinim olarak taşıyor; şube satışçısının açtığı/dönüştürdüğü firmayı görmeye devam edip etmeyeceği hiçbir yerde tanımlı değil, §12 kapsam dışı listesinde de yok. Şube modelinde bu bir köşe durum değil ana akıştır: İzmit satışçısı firma açar ve o anda kaybeder.

**F-2 — §9.1 ile §9.2 çelişiyor: belge kimliği, değiştirilebilir gelir alanına bağlanmış.** §9.1 "kim sattı / kim yaptı / fatura kimin adına kesildi **ayrı sorulardır**" der; §9.2 ise faturanın satıcı unvan/VKN/antet/serisini "**o şubeye yazılan fatura**"ya — yani §9.1'in gelir alanına — bağlar. Gelir alanı sonradan değiştirilebilir bir atama alanıdır (§9.1: "faturayı kesen kişi, yetkisi varsa, değiştirir"); kesilmiş bir resmî belgenin tüzel kişisi ve numara serisi değiştirilebilir bir alanı izleyemez. Ayrıca §9.2 "müşteri teklifle faturayı aynı şirketten görür" hedefi, gelir alanı faturalama anında başka şubeye çevrildiğinde bozulur — teklif A şirketinin antetiyle çıkmış, fatura B şirketinden kesilmiş olur. "Gelir kimin" (raporlama) ile "belgeyi hangi tüzel kişi kesti" (resmî kimlik) spec'te tek alana sıkışmış durumda.

**F-3 — §9.1 gelir alanının değer kümesi ve değiştirme yetkisi tanımsız.** (a) Alan "bu gelir hangi şubenin" — merkezin geliri için değer nedir ("merkez" bir şube değil)? (b) AD-12 faturanın teklifsiz (serbest kalem) ve bağımsız katılımcıya kesilebildiğini söyler; varsayılan "teklifi yazan kişinin şubesi" bu faturalarda tanımsız. (c) Mevcut faturaların (alan boş) şube kırılımında ve S-12 kapsamında nasıl değerlendirileceği yazılmamış — kapsamsız eğitim için verilen açıklığın (§6) fatura karşılığı yok. (d) "Yetkisi varsa değiştirir"in yetkisi adlandırılmamış; bugünkü izin ailesinde `invoice.update` yok (`invoice.create/cancel/record_payment/notify_accounting/view` var — `config/authorization.php`). (e) S-12'nin `invoice.view.own` kapsamında "own"ın ne olduğu (kesen kişi mi, teklif sahibi mi) tanımsız.

**F-4 — Mali tablonun gider tarafının şube ataması tanımsız.** §9.1 yalnız geliri bağlar; oysa mali tablo üç gider akışı toplar — eğitmen hakedişi, onaylı masraf, eğitim maliyet kalemleri (`app/Queries/Office/FinancialOverview.php:38-40,100`) — ve marj bu ikisinden hesaplanır. "Şube yalnız kendi rakamlarını görür" ve "merkez şube kırılımı görür" gereksinimlerinde maliyetin/marjın hangi şubeye yazılacağı (eğitimi veren şube mi, geliri alan şube mi, eğitmenin şubesi mi) spec'te yok. Finansal doğruluk gereksinimi eksik: Sets'in kendi örneğinde (müşteri merkezin, eğitimi İzmir veriyor) İzmir'in marjı tanımsız kalıyor.

**F-5 — §3 tavanının çok üyelikli kişide semantiği tanımsız.** AD-23'te bir kişi birden fazla grupta üye olabilir. Yalnız şube üyeliği olan ama **iki farklı şubede** (ör. İzmit=yalnız satış, İzmir=satış+planlama) üye olan kişide tavan nasıl işler: yetenek kümesi üyeliklerin birleşimi mi, kesişimi mi? `training.create` verilirse hangi düğümlerde çalışır — İzmir'in planlama düğümüyle mi sınırlanır, yoksa kapsam çözümleyicisi üyeliklerin birleşimini verdiği için İzmit kapsamına da mı taşar? §3'teki ⚠ notu yalnız merkez+şube bileşimini çözüyor; şube+şube bileşimi açık.

**F-6 — §8 ile §11.1 çelişiyor: eğitmen yeteneği olmayan şubenin planlamacısı eğitmeni hangi yetkiyle görür?** §11.1 `instructor.view`'ı **Eğitmen** yeteneğine bağlar; §3 tavanı gereği eğitmen yeteneği olmayan şubenin üyesine bu yetki verilemez ve verilmişse çalışmaz. Ama §8 aynı şubenin planlamacısının "merkezin o şubeye açtığı eğitmenleri" atamasını ister — atamak, adayları görmeyi gerektirir (`EligibleInstructors`/`PlanningCandidates`). Aday listesinin `instructor.view`'dan bağımsız olarak atama yetkisiyle mi geldiği, yoksa `instructor.view`'ın tavan dışına mı alındığı tanımsız; tablo haliyle §8'in 2. satırını imkânsız kılıyor.

**F-7 — Kabul kriterleri iki kararı kapsamıyor.** (a) §2.3 "menüler şubeye göre değişmez" (harita 895'teki Sets netleştirmesi) — hiçbir kriterde yok. (b) §5 "şube dışındaki kişiyi göremez" — kriter 2'nin test listesi §6 tablosuna bağlı, ama §6 tablosunda **kullanıcı listesi satırı yok**; kriter 4 yalnız kullanıcı *açmayı* kapsıyor, görünürlüğü değil. Brief'in "kabul kriterlerinin her kararı kapsaması" şartı bu iki noktada boş.

**F-8 — Şube kapatma / yetenek kaldırma akışı mali tarafı ele almıyor.** §4'ün atama soruları kişi + açık teklif/eğitim/potansiyel müşteriyi taşır; fatura tarafı yok: kapanan şubenin gelir alanını taşıyan faturalar (merkez kırılımında tarihçe nasıl durur), "kendi adına kesen" şube kapatıldığında şirket kimliği ve fatura serisinin akıbeti, o kimlikle kesilmiş bir faturanın kapanış sonrası iptali/iadesi hangi tüzel kişiyle yapılır — tanımsız. Satış yeteneği kaldırılan "kendi adına kesen" şube için de aynı boşluk geçerli.

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

1. **Muhasebeci teyidi (§9.2'nin kendi ⚠ notu):** ayrı tüzel kişinin ayrı seri zorunluluğu ve "3E'nin sırasında boşluk oluşmaz" iddiası doğrulanmadan plan bu bölüme giremez — spec bunu açıkça "doğrulamış değilim" diye işaretliyor, ama §11 başlığı "hepsi kapandı" diyor; bu teyit kimde ve ne zaman?
2. **Fiyat listesinin tekliği (§12) Sets kararı mı?** EGT-219 açık sorusu "fiyat listesi şubeye nasıl görünür" idi; §12 "istenmedi" diyor ama spec'in her yerde uyguladığı tarih+alıntı formatı bu satırda yok. Sets'in cümlesi varsa eklenmeli, yoksa bu bir varsayımdır ve spec'in kendi "varsayımla doldurulmuş satır yoktur" beyanıyla çelişir.

## ⚠️ Upstream Findings

Yok. (F-1 upstream'in *spec'e taşınmamış* maddesidir, upstream'in kendi hatası değildir.)

## Verdict: ❌ REJECTED

Matrix'te 1 ❌ ve 6 ⚠ satır var; sekiz bulgu scope içinde (fonksiyonel gereksinim eksiği F-1; çelişkili gereksinim F-2, F-6; tanımsız edge case / değer kümesi F-3, F-5, F-8; finansal doğruluk eksiği F-4; kabul kriteri boşluğu F-7). Kilitli Sets kararlarının hiçbiri tartışılmadı — bulguların tamamı kararların spec'e eksik ya da çelişkili aktarımıyla ilgilidir. Özellikle F-2/F-3 resmî belge kimliğine (unvan/VKN/seri) dokunuyor: bu belirsizlikler plana sızarsa yanlış tüzel kişiyle kesilmiş fatura üretir.