# Review — Ofis T4 Planı (Kullanıcı Oluşturma, Grup Ağacı, Eğitmen Kaydı) — 2026-07-28

> **Review type:** plan-review
> **Previous review:** N/A (ilk review)
> **Upstream document(s) read:** `docs/arch/mimari-kararlar.md` (AD-23, AD-09; ayrıca AD-05, AD-08, AD-11, AD-21, AD-24, AD-25, AD-26, AD-27) · `cati-dokumani.md` §174, §178 (ve 2. tur kararları) · `docs/specs/egitmen-spec.md` §1–§4 (+ §6.3, §7.8, §9–§11 çapraz referansları) · `design/61 Yonetici Tanimlar.dc.html` · `design/63 Yonetici Kullanici Log.dc.html`
> **Other cross-referenced documents:** `CLAUDE.md` · `config/authorization.php` · `docs/infra/ortamlar.md` · mevcut kod: `app/Actions/Office/AssignOfficePermissions.php`, `app/Actions/Auth/RequestOfficeMagicLink.php`, `app/Policies/UserPolicy.php`, `app/Http/Controllers/Office/UserController.php`, `app/Support/Authorization/{PermissionFamily,PermissionMatrix}.php`, `database/migrations/2026_07_28_040100_create_office_magic_links_table.php`, `2026_07_26_001000_create_sensitive_data_tables.php`, `2026_08_06_000100_documents_per_owner.php`, `2026_08_10_000100_name_the_account_states.php`, `2026_07_28_000300_create_permission_families.php`, `database/seeders/LocalOfficeAccountSeeder.php`, `routes/office.php`
> **Stage locks in effect:** `egitmen-spec` locked (heyet 158 APPROVED). Ayrı spec turu bilinçli atlandı (Sets, 28.07.2026); matrix doğrudan AD-23/AD-09/çatı/egitmen-spec/tasarıma karşı üretildi.

---

## Upstream Coverage Matrix

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| AD-23 — tek grup ağacı + üyelik (kişi×grup×rol) | ✓ | Plan Görev 1; `(user, group, role)` tekilliği AD-23'ün çoklu-rol örneğiyle uyumlu (plan 144) |
| AD-23 — üyeliğin ROL bileşeni: "Rol = yetki seti (backoffice tanımlı)" | ❌ | Ofis ailesinin rol sözlüğü bugün **boş** (`LocalOfficeAccountSeeder.php:82-85`: "The office family has no role vocabulary; permissions are granted per person"); plan "mevcut roller kullanılır" diyor (Açık kalanlar 3) ama mevcut ofis rolü yok, hiçbir görev rol üretmiyor/seed etmiyor → F-5 |
| AD-23 — kapsam seviyeleri (own/group/all) + tek çözümleyici | ⚠ | Görev 2 kurar; ama izin listesi mevcut sözlükle örtüşmüyor (F-2), plan içi çelişki var (F-3), mevcut bare-name kontrollerin kaderi planlanmamış (F-4) |
| AD-23 güvenlik kuralı 1 — "kimse sahip olmadığı yetkiyi devredemez" + tek istisna | ⚠ | Kural kaybolmuyor (Görev 6 Adım 3); ama alt-küme yarısı **bugün zaten kodda** (`AssignOfficePermissions.php:51-58`) — "taşı" öncülü kısmen yanlış; backoffice'in aynı action içinden muaf geçmesi mevcut mimariyle (`AssignOfficePermissions.php:25-28` "does not come through here"; `config/authorization.php:17-21`) çelişiyor ve adreslenmemiş → F-11, F-12 |
| AD-23 güvenlik kuralı 2 — dört göz | ⚠ | Bu turda onay akışı kurulmuyor; plan hiç anmıyor, kapanış adresi yok. K-D akışında "oluşturan = yetki tanımlayan" olabilir mi sorusu açık → F-13, Açık soru 3 |
| AD-23 — kullanıcı oluşturma iki yol, tek kural | ✓ | Görev 4 (tek Action) + Görev 9 Adım 2 (Filament aynı Action'ı çağırır); A-14 |
| AD-23 — provisioning muafiyeti (kapsam + devir) | ⚠ | Kapsamı AD-23'ün tarifiyle örtüşüyor, genişletme yok (aşağıda "Sorulara cevaplar" 4); ama muafiyet **aktör tipine** bağlanmış, backoffice iznine değil → F-11 |
| AD-23 — backoffice'te kullanıcı yönetimi için MFA zorunlu | ✓ | Görev 9 Adım 3 testi: "MFA'sız backoffice kullanıcısı bunu yapamaz" |
| AD-23 — atamalar: müşteri→grup (zorunlu) / kişi; eğitmen→planlamacı süreli havuz | ❌ | Planda yok, "Açık kalanlar"da da yok; mevcut `office_customer_assignments` kişi bazlı. Eğitmen havuzu `egitmen-spec` §6.3'ün ön koşulu → F-13 |
| AD-23 — kullanıcı çıkışı (pasifleştirme + müşteri devri sihirbazı) | ✓ | Pasifleştirme mevcut (`ChangeOfficeAccountStatus`, AD-11/A-13); sihirbaz Açık kalanlar 2'de adresli (müşteri/satış turu) |
| AD-23 — onay ve eskalasyon omurgası | ❌ | Planda anılmıyor, kapanış adresi yok → F-13 |
| AD-09 — ofis/backoffice sınırı; K-B ile grup/kullanıcı yönetimi iki yerde | ✓ | Sets kararı K-B upstream'dedir; Görev 9 Adım 1 "ikisi de aynı Action'ları çağırır" |
| AD-09 — tehdit varsayımı **yalnız süper admin** içindir; diğer backoffice rolleri kullanıcı yönetimine erişmez | ⚠ | `mimari-kararlar.md:117`; plan muafiyeti `BackofficeUser` tipiyle tanımlıyor, `office_user.create` / `office_user.assign_permissions` izin kapısı (`config/authorization.php:184-187`) hiçbir görevde anılmıyor → F-11 |
| çatı §174 — roller + eğitmen kategorileri | ⚠ | Kategoriler ✓ (Görev 7: `permanent/contracted/project_based` = spec §1.1); roller → F-5 |
| çatı §178/1 — izolasyon, her adım loglanır | ✓ | Her görevde audit adımı; A-11, A-12 |
| egitmen-spec §1 — kullanıcı ≠ dosya; pasifleşince dosya durur | ✓ | Görev 7 migration `restrictOnDelete` + test "kullanıcı pasifleşince dosya durur" |
| egitmen-spec §1.2 — kadro değişikliği bildirim görevi (15 gün, admin ayarı) | ❌ | T-2 gerekçesinde tüketici olarak sayılıyor (plan 41, 379) ama hiçbir görev adımı işe alım/ayrılışta bu görevi açmıyor → F-14 |
| egitmen-spec §2 — bakanlık ID zorunlu | ✓ | Görev 7 migration + test "bakanlık ID'siz kayıt reddedilir"; A-8 |
| egitmen-spec §2 — iki yetkilendirilmiş kuruluş sınırı "kayıtta kontrol edilir" | ⚠ | Kolon var (`authorised_institutions`), kontrolün yeri/test kanıtı yok; sınır değerinin admin-tanımlı/uyarı rejimi (AD-27, kırmızı çizgi 14) belirsiz → F-14 |
| egitmen-spec §2 — son eğitim verme tarihi (türetilir), CTU/CSS evrakları | ⚠ | İkisi de planda yok, kapanış adresi yok → F-14 (CTU/CSS ayrıca F-7'ye bağlı) |
| egitmen-spec §2.1 — hassas veri rejimi (AD-05 şifreleme, AD-21 erişim logu, maske) | ❌ | Planın gösterdiği adres (`sensitive_data` yapısı) **tenant-scoped müşteri tablolarına dönüşmüş durumda**; ofis tarafı için böyle bir yapı yok → F-6 |
| egitmen-spec §3 — uygunluk kapısı; §3.1 yetkinlik matrisi §11/2'ye ertelenmiş | ✓ | Erteleme spec'in kendi kararı ("bu bir eksik değil, sıralama" §3.1 ⚠; §11/2 adresi: eğitim tanımı turu); plan Görev 7 Adım 1 ⛔ aynı adresi tekrarlıyor. Belge ayağı Görev 8 testiyle kuruluyor ("eksik belgeli eğitmen aday listesinde görünmez", A-10) |
| egitmen-spec §4.1/§4.3 — saatlik/günlük birim; boş = kategori tarifesi | ✓/⚠ | `rate_unit`/`rate_amount` ✓, "boşsa kategori tarifesi" notu ✓ (Görev 7 Adım 2 ⚠); ama §4.2'nin kategori tarifesinin tanımlanacağı yer (backoffice *Eğitmen ayarları*, spec §9) bu turda kurulmuyor ve adressiz → F-14 |
| egitmen-spec §4.4 — işlem bazlı override planlamada | ✓ | Bu turun kapsamı dışında (atama/maliyet turu); spec kendi içinde adresli |
| AD-05 — hassas alan şifreleme, day-one | ❌ | F-6 |
| AD-21 — hassas okuma erişim logu | ✓/⚠ | Görev 7 testi "açık okuma erişim logu yazar"; ama testin `omurga-rls` grubuna konması yanlış iz (instructors tenant-scoped değil) — F-6 içinde |
| AD-11 / kırmızı çizgi 12 — silinmezlik, pasifleştirme | ✓ | Görev 1 ⚠ `restrictOnDelete` + `is_active`; A-13; kullanıcı pasifleştirilir |
| AD-26 — grup etiketi, çıplak `now()` yasağı, RLS owner yasağı | ✓ | Global kısıtlar bölümü + Görev 7 Adım 3 |
| AD-24 Ek 2 — sahip başına evrak tablosu; "sahip tablosu kendi modülüyle doğar" | ❌ | Eğitmen modülü bu turda doğuyor; `instructor_documents` planda yok; bugünkü tek satır tablosu `customer_documents` (`2026_08_06_000100:60`) → F-7 |
| Tasarım 61 — eğitmen ekleme drawer'ı, sade dilli yetki listesi, "engelli başlar" | ✓ | Görev 7/8; sade dil listesi Görev 6'nın yetki ekranına taşınmış (kompozisyon bağlayıcı değil); "engelli" türetilmiş durum olarak yorumlanmış (Görev 8 Adım 1 ⚠) — savunulabilir |
| Tasarım 63 — "＋ Kullanıcı", kullanıcı listesi/detayı, geciken işler bandı | ✓ | Görev 4 Adım 5, Görev 6 Adım 4, Görev 8 Adım 2 |
| K-A — parola asla belirlenmez; davet 24 saat (admin ayarı) | ✓/⚠ | İmzada ve ekranda parola yok (Görev 4 Adım 1 ⛔, A-1/A-2); ama 24s TTL'nin settings anahtarı ve davet şablonunun `notification_templates` satırı için üretim adımı yok → F-16 |
| K-B — kullanıcı yönetimi iki yerde | ✓ | A-14 |
| K-C — belgeleri açan yükler ya da kişiye görev düşer; kullanıcı panelinden takip | ⚠ | Yönetici tarafı planlı; **eğitmen tarafı ekransız** (görev listesi + yükleme yolu yok) ve belge satırlarının yazılacağı tablo yok → F-7, F-8 |
| K-D — yetki oluşturmada verilmez; ilk girişte görev düşer | ⚠ | İmza/ekran/test ayağı sağlam (Görev 4, A-3); görev-atama modeli çelişkili (F-9), boş yetkili kümesi/bootstrap tanımsız (F-10) |
| T-1 — kapsam izin adının eki | ✓ | Dayanak doğrulandu: `config/authorization.php:13-15` birebir öyle diyor; türetme upstream'e sadık (uygulanışı F-2/3/4) |
| T-2 — genel görev kaydı | ✓/⚠ | Tek tablo kararı savunulabilir; ama `assigned_to` yalnız ofis `users`'a bağlı — AD-24'ün evrak talebi görevi müşteri yetkilisi/katılımcıyı da hedefliyor ve kimlik alanları tablo paylaşamaz; "genel" iddiasının sınırı tanımsız → Açık soru 2 |
| T-3 — davet, magic link'in ikinci amacı | ✓/⚠ | Tek tablo kararı doğru; ama planlanan `purpose` migration'ı **zaten var olan** kolonu ikinci kez ekliyor → F-1 |

---

## ✅ What works

- **Tek Action, iki çağıran** (Görev 4 + Görev 9 Adım 2) AD-23'ün "iki yol, tek kural" hükmünü doğru yerde topluyor; Filament'in kendi yaratma kodu yazmaması ⛔ ile sabitlenmiş.
- **K-A/K-D'nin imzada yaşaması** ("imzada ne parola vardır ne izin") kural-kontrolden daha sağlam bir tasarım; kabul kriterleri (A-1…A-5d) gözlemlenebilir yazılmış.
- **`descendants()` recursive CTE** kararı ve `restrictOnDelete` gerekçeleri yerinde; `(user, group, role)` tekilliği AD-23'ün çoklu-rol örneğini doğru okuyor.
- **Boş panel kararının gerekçesi** (giriş, uyarıyı tetikleyen olaydır; kimlik kanıtlanmış, yetki gecikmesi kullanıcının suçu değil) tutarlı ve güvenlik açısından savunulabilir.
- **Görevin role değil kapsama bağlanması** (Görev 6 Adım 2 ⛔ "oluşturan ayrılmış olabilir") doğru bir işleyiş kararı.
- **Yetkinlik matrisi ertelemesi** spec'in kendi sıralamasına sadık ve adresli (aşağıda "Sorulara cevaplar" 5).
- Audit, dil, test grubu, `timestampsTz`, factory disiplini görev şablonlarına işlenmiş.

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

**F-1 — Planlanan `purpose` migration'ı zaten var olan kolonu ekliyor.** `office_magic_links.purpose` 2026_07_28_040100 migration'ında zaten var (satır 37: `string('purpose', 32)->default('sign_in')`) ve `OfficeMagicLink` modelinde fillable (satır 40); `RequestOfficeMagicLink.php:70` `'purpose' => 'sign_in'` yazıyor. Görev 3 Adım 1'in `add_purpose_to_office_magic_links` migration'ı (üstelik farklı genişlikle, 16) çalıştığı anda duplicate-column hatası verir. Plan mevcut şemaya karşı doğrulanmamış (CLAUDE.md "Varsayımla Kod Yazmak Yasak" 1: migration dosyasını OKU).

**F-2 — Görev 2 Adım 3'ün kapsamlandırma listesi mevcut izin sözlüğüyle örtüşmüyor.** Listede `customer.view`, `quote.view`, `training.view` var; ofis ailesinde bu adların hiçbiri yok (`config/authorization.php:25-81`). `training.view` yalnız **backoffice** ailesinde var (satır 120) ve orada kapsam kavramı yoktur — migration aile filtresi tanımlamıyor, isimle rename backoffice satırını bozar. `quote.view` hiçbir ailede yok. Mevcut `customer.view_all` (satır 41, §6.5.2 deseni) ile yeni `customer.view.all` biçiminin ilişkisi (rename mi, birlikte mi yaşar, `user.assign_customers` deseni ne olur) hiç adreslenmemiş. "Mevcut satırı `.all` yapar" taahhüdü, var olmayan satırlar için tanımsızdır.

**F-3 — Plan kendi içinde çelişiyor: `user.create` hem kapsamsız örnek hem kapsamlandırılan izin.** Görev 2 Adım 1 ⚠ "kapsamsız isim, kapsam sorusu olmayan izindir (`user.create` gibi)" (plan 196); Adım 3 `user.create`'i kapsamlandırılanlar listesine koyuyor (plan 218). İkisi aynı anda doğru olamaz; geliştirici hangisini uygulayacağını bilemez.

**F-4 — Rename sonrası mevcut bare-name yetki kontrolleri kırılır; plan hiçbir güncelleme adımı içermiyor.** `UserPolicy.php:49-81` (`user.view`, `user.create`, `user.update`, `user.deactivate`), `UserController.php:42,62,140-141` (`user.view`, `user.assign_permissions`), `PermissionMatrix.php:128-132` bare adlarla soruyor. Migration `user.view` satırını `user.view.all` yaptığı anda bu kontroller bulunamayan izne düşer — "bugün o izni taşıyan kişi bugünkü kadar görmeye devam eder" güvencesi veri katmanında sağlanıp **kod katmanında bozulur**. Gate'in kapsam-farkındalı çözümü mü yazılacak, çağıranlar mı skoped ada geçecek — planda yok. (Spatie izin önbelleğinin migration sonrası tazelenmesi de anılmamış.)

**F-5 — "Bu turda mevcut roller kullanılır" öncülü yanlış: ofis ailesinin rol sözlüğü boş.** `LocalOfficeAccountSeeder.php:82-85`: *"The office family has no role vocabulary (omurga spec §3): permissions are granted per person"*; hiçbir seeder ofis rolü yazmıyor. Görev 1/4 üyelikte `role_id` istiyor, Görev 7 `instructor` rolünün varlığına dayanıyor, Görev 4 Adım 5 ekranı "grup + rol" seçtiriyor — ama hiçbir görev rolleri üretmiyor. Ayrıca `group_memberships.role_id`'nin Spatie izin değerlendirmesiyle ilişkisi tanımsız: rol izin taşırsa A-3'ün "etkin izin kümesi boş" kriteriyle çelişir; taşımazsa AD-23'ün "İzmit'te satış yöneticisi, İstanbul'da satışçı" örneğinin (grup başına farklı yetki) bu modeldeki karşılığı yoktur — düz kullanıcı-izinleri grup başına ayrışamaz.

**F-6 — Eğitmen hassas verisinin adresi yanlış; izlenirse kimlik alanı sızıntısı doğurur.** Görev 7 Adım 1 ⚠ hassas alanları (TCKN, kimlik, ehliyet, SGK sicil) "mevcut `sensitive_data` yapısına" (2026_07_26_001000) gönderiyor. O migration'ın tabloları consent/documents idi ve 2026_08_06_000100 ile `customer_documents`/`customer_document_versions`'a daraltıldı — **tamamı tenant-scoped, sahibi müşteri** (migration yorumu: "an instructor's diploma is 3E's data… one table cannot be row secured for some of its rows"). Eğitmen ofis kimliğidir, tenant'sızdır; bu adrese yazmak ya koşullu `tenant_id` (chunk2 yasağı) ya kimlik alanı karışması üretir. Ofis tarafında alan şifreleme deseni encrypted kolonlardır (`users`, `customer_users.national_id` emsali) — planın işaret ettiği "yapı" bu amaçla mevcut değil. Aynı karışıklığın izi: `InstructorSensitiveDataTest`'in `omurga-rls` grubuna konması — `instructors` tenant-scoped olmayacak bir tablodur, RLS suite'inin konusu değildir.

**F-7 — Eğitmen belgelerinin yazılacağı tablo yok.** AD-24 Ek 2: sahip başına ayrı evrak tablosu; "sahip tablosu kendi modülüyle doğar" (`documents_per_owner` migration yorumu: "The other owner tables (instructor, participant, office personnel, training) are created WITH their modules"). Eğitmen modülü **bu turda** doğuyor; plan `instructor_documents`/`instructor_document_versions` migration'ı içermiyor. Görev 8'in "mevcut belge motoru"ndan yükleme adımı, satırların gideceği tablo olmadan uygulanamaz; `document_types`'ın eğitmen kapsamı da (AD-24: kapsam listesi ↔ tablo listesi kilidi) karşılıksız kalır.

**F-8 — K-C'nin eğitmen tarafı ekransız ve adressiz.** "Kendi yüklesin" görevleri kişinin paneline düşer; dosya haritasında görev listesi ve eğitmenin kendi belge yükleme ekranı yok (ön yüz: Users/Create, Instructors, AcceptInvitation, Permissions — hepsi yönetici/auth tarafı). "Belge yüklenince görev tamamlanır" testinin production yolu yok; `MyTasks` sorgusu bu turda hiçbir ekrana bağlanmıyor. Backbone kabulü meşru olabilir, ama o zaman kapanış adresi (hangi tur) yazılmalı — bugün ne planda ne "Açık kalanlar"da.

**F-9 — Görev-atama modeli kendi kurallarıyla çelişiyor.** `tasks.assigned_to` tek kullanıcı ve NOT NULL (Görev 5 migration); Görev 6 Adım 2 görev "kapsamdaki **herkese** düşer; ilki tanımlayınca görev kapanır" diyor; Görev 5 testi "başkasının görevini tamamlamak reddedilir"; A-5d "görev otomatik kapanır". Kişi başına N satır mı açılıyor (o zaman kardeş satırları kim, hangi kuralla kapatıyor — "başkasının görevini tamamlama" yasağıyla nasıl bağdaşıyor), tek satır mı (o zaman `assigned_to` kime yazılıyor) — plan iki modeli aynı anda ima ediyor ve hiçbirini seçmiyor.

**F-10 — Yetkili kümesi boşken K-D akışı tanımsız (bootstrap dahil).** Kapsamda `user.assign_permissions` taşıyan kimse yoksa — ilk ofis kullanıcısı (AD-23: "sistem ilk açıldığında yalnız backoffice kullanıcıları vardır") veya yeni açılmış bir dal — görev kimseye düşemez; `assigned_to` NOT NULL olduğundan kayıt hiç yazılamaz ve "yetki bekleyen kullanıcı" sessizce görünmez kalır. Plan boş küme için ne fallback ne eskalasyon tanımlıyor.

**F-11 — Backoffice muafiyeti aktör TİPİNE bağlanmış, backoffice İZNİNE değil.** Görev 4 Adım 1 ⛔: "Aktör `BackofficeUser` ise kapsam kontrolü uygulanmaz"; Görev 9 testlerinde MFA var ama `office_user.create` / `office_user.assign_permissions` izin kapısı (`config/authorization.php:184-187`) hiçbir görevde anılmıyor. AD-09 tehdit varsayımı **yalnız süper admin rolü** içindir ve "backoffice'e eklenecek diğer roller … kullanıcı yönetimine erişmez" (`mimari-kararlar.md:117`); backoffice'in kendi yetki hiyerarşisi tam bunun için var. Tip bazlı muafiyet, yarın eklenecek dar backoffice rolüne kapsam sınırsız kullanıcı yönetimi açar.

**F-12 — Görev 6 Adım 3'ün öncülü kısmen yanlış; mevcut mimariyle çelişkisi adreslenmemiş.** Devir kuralının alt-küme yarısı **bugün zaten** `AssignOfficePermissions`'ta uygulanıyor (`AssignOfficePermissions.php:51-58`, Gate üzerinden — MFA'sız etkisiz izni de devredilemez kılan biçimde). "Kuralı taşı" ifadesi geliştiriciyi ikinci bir alt-küme kontrolü yazmaya götürebilir; yeni olan yalnız (2) kapsam daraltma ve (3) hedef-kapsam kontrolüdür. Ayrıca action'ın kendi PHPDoc'u backoffice'in "buradan geçmediğini" söylüyor (satır 25-28: farklı aile, farklı action) ve imza `User $actor` — plana göre muafiyet bu action **içinde** uygulanacaksa imza ve mimari duruş değişiyor; plan bu değişikliği görmüyor.

**F-13 — AD-23'ün üç kalemi ne kapsanmış ne kapanış adresi almış.** (a) Eğitmen→planlamacı süreli havuz ataması (egitmen-spec §6.3'ün ön koşulu), (b) müşteri→grup zorunlu ataması (mevcut `office_customer_assignments` kişi bazlı), (c) onay/eskalasyon omurgası ve güvenlik kuralı 2'nin bu akıştaki karşılığı. Bu turun işi olmamaları meşru; ama onay kuralı 6 gereği ⚠/❌ satır adressiz kapanamaz — "Açık kalanlar" tablosuna tur adresiyle yazılmalı.

**F-14 — Kilitli `egitmen-spec`'in dört kalemi planda karşılıksız ve adressiz.** (a) §1.2 kadro değişikliği bildirim görevi — T-2'nin gerekçesinde bu turun tüketicisi sayılıyor (plan 41) ama hiçbir görev adımı işe alım/ayrılışta görev açmıyor; (b) §2 iki-kuruluş sınırı — kolon var, "kayıtta kontrol edilir" davranışının yeri ve testi yok; sınır değerinin nereden geleceği (admin alanı/mevzuat uyarısı — kırmızı çizgi 14) belirsiz; (c) §2 "son eğitim verme tarihi" türetimi ve CTU/CSS evrak zorunluluğu — adres yok; (d) §4.2 kategori bazlı baz tarifenin tanımlanacağı backoffice *Eğitmen ayarları* sayfası (spec §9) — bu turda yok ve adressiz; "boşsa kategori tarifesi geçerlidir" (Görev 7 Adım 2 ⚠) tarifesiz boşlukta çözümsüz.

**F-15 — A-8'in akışı kurulmamış: instructor alanları hangi ekrandan/imzadan geçiyor?** A-8 "rol `instructor` seçilince eğitmen dosyası aynı transaction'da açılır; bakanlık ID'siz kayıt reddedilir" der. Ama Görev 4 Adım 5 ekran alanları yalnız "ad soyad, e-posta, telefon, grup + rol"; `CreateOfficeUser` imzasında eğitmen dosyası verisi yok; `Instructors/Create.vue` ayrı bir ekran. Users/Create'ten instructor rolü seçildiğinde bakanlık ID/kategori/belge tarihi nereden gelir — iki ekranın sorumluluk sınırı ve verinin aynı transaction'a giriş yolu tanımsız.

**F-16 — Görev 3'ün üretim adımları eksik.** (a) `invited` durumu için `AccountStatus` enum'u ve `isActive()`/`EnsureAccountIsActive` yollarının değişimi dosya listesinde yok (davet kabul rotasının `invited` hesaba açık, panelin kapalı olması bu yollardan geçer); (b) davet şablonunun `notification_templates` satırı nasıl doğuyor (seed mi, backoffice tanımı mı) — mevcut magic-link maili template tablosunu değil Notification sınıfını kullanıyor (`RequestOfficeMagicLink.php:77`), yeni mekanizmaya geçişin adımı yok; (c) 24 saatlik davet TTL'sinin admin-tanımlı ayar anahtarı (settings) için adım yok.

*Blocker olmayan notlar (bilgi):* `groups.unique(['parent_id','name'])` PostgreSQL'de NULL parent'lı (kök) satırlarda tekillik vermez — çift kök adı mümkün; `groups.vertical` değer kümesi yorum satırında yaşıyor, kontrolü tanımsız; `tasks.opened_by` `nullOnDelete` — kullanıcı hiç silinmediği (AD-23) için ölü daldır.

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

1. **Üyelik rolünün izin semantiği:** `group_memberships.role_id` Spatie rolü mü, etiket mi? AD-23'ün "grup başına farklı rol → farklı yetki" örneği, düz kullanıcı-izin + kapsam-eki modelinde nasıl ifade edilecek? (F-5'in karar tarafı.)
2. **T-2'nin kimlik alanı sınırı:** AD-24'ün evrak talebi görevi müşteri yetkilisi/katılımcıyı da hedefliyor; `tasks.assigned_to` yalnız ofis `users`. Müşteri tarafı görevleri ileride bu tabloya mı (kimlik alanları tablo paylaşmaz — çelişir) yoksa sahip başına ayrı görev tablosuna mı gidecek?
3. **K-D × dört göz:** kullanıcıyı oluşturan kişi, kapsamdaki yetkili olarak aynı kullanıcının yetkisini kendisi tanımlayabilir mi, yoksa AD-23 kural 2'nin ruhu burada da bir ikinci kişi mi ister?
4. **Süresi dolan davet:** 24 saat geçtikten sonra akış ne? Yeniden davet gönderme eylemi (kim, hangi yetkiyle) planda yok.
5. **`user.create` kapsamlı mı kapsamsız mı?** (F-3'ün karar tarafı — Sets'in T-1 çerçevesinde netleştirmesi gerekir.)

## Sorulara cevaplar (talep edilen altı nokta)

1. **Görev 2 veri taşıması güvenli mi?** Hayır — üç ayrı yoldan: liste mevcut sözlükle örtüşmüyor (F-2), plan kendi içinde çelişiyor (F-3) ve rename sonrası bare-name kontroller kırılıyor (F-4). `down()` + seeder koşusu doğru düşünülmüş ama yeterli değil.
2. **AD-23 kural 1'in yeri:** Kural kaybolmuyor; Görev 6 Adım 3 doğru yerde topluyor. Ancak "bugün o action'da yok" tespiti alt-küme yarısı için **yanlış** — `AssignOfficePermissions.php:51-58` bugün zaten uyguluyor; yeni olan kapsam-daraltma ve hedef-kapsam. Backoffice'in aynı action'dan muaf geçirilmesi mevcut "ayrı aile, ayrı action" duruşuyla çelişiyor (F-12).
3. **K-D boş panel:** Güvenlik sakıncası görmedim. Kimlik kanıtlanmış, yetki yok; kırmızı çizgi 3 zaten her uçta yetki doğrulatıyor (A-5b'nin 403 ayağı bunu test ediyor), `RequireStrongOfficeSession`/MFA sürüyor, giriş-tetikleyici gerekçe tutarlı. Tek şart: boş panelin shell'i veri taşımamalı — plan bunu söylüyor.
4. **Backoffice muafiyetinin sınırı:** Kapsam olarak AD-23 ile örtüşüyor, genişletme yok — "kapsam sınırı olmadan oluşturma" ve "taşımadığı yetkiyi atama" aynı adlandırılmış istisnanın iki yüzüdür (AD-23 kural 1 + "Kullanıcı oluşturma" bölümü). Sorun kapsam değil **uygulanış**: muafiyet aktör tipine bağlanmış, backoffice'in kendi izin kapısı planda yok (F-11).
5. **Yetkinlik matrisi ertelemesi:** Kabul edilebilir ve spec'e uygun. `egitmen-spec` §3.1 ⚠ ertelemeyi kendisi kutsuyor ("model gelene kadar bu kapı çalışmaz — eksik değil, sıralama") ve §11/2 adresi (eğitim tanımı turu) hem spec'te hem planda yazılı. Kapanış adresi yeterince net; ek bulgu yok.
6. **Wire-up:** Görev 10 listesi bu turun ana sembollerini kapsıyor (`CreateOfficeUser` iki çağıran, `ScopeResolver`, `OpenTask`, davet rotası). Baştan caller'sız kalacağı belli olan tek sembol `MyTasks`'tır (eğitmen görev ekranı bu turda yok) — backbone kabulü meşru, ama plan bunu söylemiyor ve kapanış adresi yazmıyor (F-8). `PermissionScope`/`GroupTree` bu turda caller'lı.

## ⚠️ Upstream Findings

Yok. (F-6 izlenirse kimlik alanı sızıntısına dönüşür, ancak bu planın düzelteceği bir plan hatasıdır; kilitli spec'lerde geri dönüş gerektiren bulgu tespit edilmedi.)

## Verdict: ❌ REJECTED

Matrix'te 5 ❌ ve 9 ⚠ satır var; 16 bulgu açık. Planın omurga fikirleri (tek Action, imzada yaşayan K-A/K-D, tek çözümleyici) sağlam; ancak plan üç yerde mevcut kod tabanına karşı doğrulanmamış (F-1, F-2, F-5, F-12), iki yerde kendi içinde çelişiyor (F-3, F-9), hassas veri ve evrak ayağı bugünkü şemada karşılıksız (F-6, F-7) ve kilitli upstream'in birkaç kalemi adressiz (F-13, F-14). Bu haliyle geliştirici bu plandan belirsizliğe düşmeden kod yazamaz.