# Spec — Ofis Ön Yüzü ve Kimlik Yüzeyi *Sürüm 1.0 — 27.07.2026. Kaynak: bu tarihli brainstorm oturumu (Sets). Üst belgeler: `docs/specs/omurga-spec.md`, `design/HANDOFF.md`, `docs/arch/kod-yerlesimi.md`.* Bu belge ofis panelinin **ön yüz temelini** ve **kimlik doğrulama yüzeyini** tanımlar. Omurga planı iş ekranı üretmez (`docs/plans/omurga-plan.md:2461`); ofis tarafı oradan devredilen ilk dikey iştir ve kendi spec'ini burada alır. --- ## 1. Neden bu belge var Ofis tarafında bugün **akış var, ekran yok**. `routes/office.php` giriş, çıkış, oturum listesi, kullanıcı yönetimi ve sistem günlüğü uçlarını taşıyor; hepsi `JsonResponse` dönüyor. `OfficeNavigation` menüyü izne göre filtreli üretiyor ama menüyü çizen bir şey yok. Ön yüzde `inertiajs/inertia-laravel` composer'da duruyor; Vue, Inertia adaptörü, root view ve derleme girişi yok. Yani bu tur bir **temel** turudur: tasarım sistemini koda çevirir, kabuğu kurar ve mevcut akışların üstüne ilk gerçek ekranları koyar. ⛔ **Tasarımcının teslim ettiği eksiksiz uygulanır** (`design/HANDOFF.md`) *— düzeltme: Sets, 30.07.2026; protokol 31.07.2026*. Bu satır önce *"nihai değildir; sayfa kompozisyonu bağlayıcı değil"* diyordu ve pratikte **"umursamayın"** diye okundu. Bağlayıcı olan: token seti, bileşen dili, semantik renk, erişilebilirlik, responsive davranış **ve sayfa kompozisyonu, alan sıralaması, ekran bölünmesi, menü grupları**. Bağlayıcı olmayan tek şey örnek verilerdir. Sapma yalnız Sets söylediğinde; prosedür `CLAUDE.md` → Tasarım Uygulama Protokolü. Mockup içi **metinler** güncel değil; çelişkide AD'ler ve omurga spec'i esastır. --- ## 2. Kapsam ### Kapsam içi - Vue 3 + Inertia + Tailwind 4 kurulumu ve panel başına derleme girişi - `00 Tokenlar`'ın tamamının CSS değişken katmanına çevrilmesi - Atomic design iskeleti (`kod-yerlesimi.md` §3) ve standart atom seti - Çalışma zamanı çeviri mekanizması - Ofis kimlik yüzeyi: şifre girişi, ikinci faktör doğrulama ve kurulumu, şifre sıfırlama, magic link, passkey - Ofis kullanıcıları ekranı ve sistem günlüğü ekranı - Hata sayfaları (403 / 404 / 500 / bakım / oturum süresi doldu) ### Kapsam dışı | Ne | Neden | Adres | |---|---|---| | Müşteri portalı ve katılımcı ekranları | Ayrı kimlik alanı, ayrı kabuk, ayrı derleme girişi | Kendi spec'i — `EGT-24` (Spec 4) ve `EGT-38` altında açılacak turu. Ofisle **aynı tasarım sisteminden** beslenir (AD-25): atomlar ve token katmanı ortaktır, yeniden yazılmaz | | Landing page | EGT-40, "en son" | EGT-40 | | `63`'teki kullanıcı detay kokpiti (geciken işler, haftalık performans, ciro) | Beslediği satış ve mali modüller yazılmadı; bugün uydurma veriyle dolardı | satış / mali spec'leri | | `63`'teki Onaylar sayfası | Aynı gerekçe: onaya düşen iş türleri (indirim aşımı, masraf, fiyat değişikliği) henüz yok | satış / mali spec'leri | | Bildirim merkezi içeriği | Chunk 7 (bildirim altyapısı) yazılmadı; kabuğunda yeri ayrılır, içi doldurulmaz | chunk 7 | | Filament panelinin token kaynağına bağlanması | Sets kararı: backoffice kendi görsel dünyasında kalır | — (karar 8) | --- ## 3. Bu turun kararları *Hepsi Sets'in kararı; 1–10 27.07.2026, karar 11 ile karar 8'in AD-25 netleştirmesi 28.07.2026 (heyet review 147 sonrası). Gerekçeler kısaltılmadan yazıldı: bir kararın nedeni kaybolduğunda karar bir sonraki turda yeniden tartışılır.* ⚠ **Numaralar kimliktir, sıra değildir.** Karar 11 sonradan adlandırıldığı için sonda duruyor; §7 ve §8 ona numarasıyla atıf yapar. ### Karar 1 — Bileşen kütüphanesi ekran güdümlü doğar, standart atomlar baştan yazılır Katalog önce yazılsaydı çağıranı olmayan büyük bir yığın çıkar ve prop şemaları ancak ilk ekranda sınanırdı. Tamamen ekran güdümlü olsaydı aynı şeyin iki varyantı riski denetime kalırdı. Orta yol: **atomlar** (buton, input, label, select, searchable select, rozet, checkbox/radio/toggle…) baştan yazılır — küçüktürler ve `01 Form Elemanlari`'nde tüm state'leriyle tanımlıdırlar. **Molekül ve organizmalar** ilk ihtiyacı doğuran ekranla birlikte doğar; ikinci ekran onu tekrar yazamaz, genişletir. ### Karar 2 — İlk yolculuk: giriş → kabuk → kullanıcılar Temel, gerçek bir uçtan uca yolculukla sınanır. Mevcut backend'e oturur, hiçbir yerde uydurma veri kullanılmaz. ### Karar 3 — Çeviri çalışma zamanında teslim edilir, paket kullanılmaz `laravel-vue-i18n`'in Vite eklentisi `lang/*.php`'yi **derleme sırasında** JSON'a çevirir; backoffice'e planlanan çeviri paneli o modelde her düzenlemede yeniden derleme isterdi. Ayrıca paketin son sürümü 2.8.0 / 29.03.2025 ve JS ile PHP ayrıştıran bir bağımlılık taşıyor. Mekanizma: sunucu, sayfanın bildirdiği çeviri gruplarını Inertia prop'u olarak gönderir; Vue tarafında ince bir `t()` (anahtar + `:değişken` + `|` çoğul). Çeviri paneli geldiğinde teslimat yolu değişmez — panel veriye yazar, translator okur, prop taze gelir. ⚠ Bedeli bilinçlidir: hangi grubun hangi sayfaya gittiği elle yazılır. Eksik grup ekranda **ham anahtar** olarak görünür — sessiz değil, görünür bir hata. ### Karar 4 — Kabuk route'tan seçilir, kimlik alanından değil Kimlik alanı yetmiyor: public host tek başına üç yüz taşıyor ve ikisi aynı alanda — `/` landing (misafir), `/panel` müşteri portalı (sidebar'lı), `/katilimci` katılımcı akışı (`05 Navigasyon`: *"Katılımcı panelinde nav yok — tek akışlı sayfa"*). `/panel` ile `/katilimci` aynı `customer` kimlik alanıdır (spec §3.0) ama farklı kabuktur. `bootstrap/app.php` her route dosyasını zaten kendi domain'ine bağlıyor; kabuk da oraya yazılır. ⚠ Root view yalnız HTML iskeletini, ``'i ve **hangi derleme girişinin** yükleneceğini söyler. Sidebar'lı / nav'sız farkı Vue `templates/` katmanına aittir, blade'e değil. ### Karar 5 — Derleme girişi panel başına ayrılır `office` · `portal` (müşteri) · `participant` · ileride `landing`. Katılımcı brief'e göre *"neredeyse tamamen mobil, hayatında bir-iki kez"* (`docs/design/tasarim-brief.md:25`); tek pakette ofisin tablo ve matris kodu o telefona da inerdi. Ortak atom ve moleküller Vite'ın paylaşılan chunk'ına düşer — kod tekrarı doğmaz. Bu turda yalnız `office` girişi yazılır. ### Karar 6 — Ofiste ikinci faktör yetki bazlı kalır Spec §5.2 değişmez: alan bazlı zorunluluk yalnız backoffice'tedir. Ofiste kurulum ilk girişte **teklif edilir**, dayatılmaz — teklif ayrı bir ekran değil, panelde duran bir uyarı bandıdır (`04 Geri Bildirim` banner deseni). MFA'lı yetkilerden birini tutan kişi kurana kadar o yetki **etkisiz** kalır ve ekran nedenini söyler. ⚠ `10 Ortak Auth` mockup'ı *"Girişten sonra 2FA doğrulaması istenir — ofis hesaplarında zorunludur"* diyor. **Bu metin geçersizdir**; HANDOFF'un kendi kuralı gereği çelişkide spec esastır. Bugün etkilenen tek somut yer: `user.assign_permissions` MFA'lı izinler arasında (`config/security.php:33`) ve `PermissionFamilies::requiresMfaAndLacksIt()` izni iptal etmez, **etkisizleştirir**. Yani kullanıcılar ekranındaki yetki atama, ikinci faktörü olmayan kişi için kilitli görünür ve kilit nedenini söyler. ### Karar 7 — Magic link + kanıtlanmış ikinci faktör = güçlü oturum (yalnız ofis) Spec §5.3 bugün *"Magic link panel yetkisini AÇMAZ"* diyor ve gerekçesi paylaşılabilirliktir. Ofis için kural **oturuma** sorulacak biçimde daraltılır: magic link **tek başına** hâlâ güçlü değildir, ama üzerine ikinci faktör kanıtlandıysa oturum güçlüdür — paylaşılan bağlantının sahibi ikinci faktörü veremez. ⚠ Müşteri ve katılımcı tarafında kural **aynen kalır**: orada magic link katılımcı ekranlarının kapısıdır ve panel yetkisi açmaz. ### Karar 8 — Filament kendi görsel dünyasında kalır `kod-yerlesimi.md` §4 *"token'lar tek CSS değişken kaynağından **hem Vue hem Filament** tarafına beslenir — iki ayrı palet oluşmaz"* diyor. Backoffice önceki turlarda Filament'in kendi paletiyle boyandı ve tasarımcı Filament'i kapsam dışı bıraktı. Kural **Filament dışındaki tüm ön yüzlere** daraltılır — aynı ifade AD-25'te de kullanılır, iki belge iki farklı sınır yazmasın. ⚠ **AD-25 revize edilmez, netleştirilir** *(Sets, 28.07.2026)*. `mimari-kararlar.md:373` *"Design token'ları tek CSS değişken kaynağından **her iki tarafa** beslenir"* diyor ve bu cümle Filament'i tartışan bir paragrafın sonunda durduğu için "Vue + Filament" diye okunuyor. Sets'in kastı **ofis + müşteri** — ikisi aynı tasarımı kullanır, Filament'in bununla ilgisi yoktur. Yani AD-25 zaten karar 8 ile uyumludur; sorun politikada değil ifadededir ve **cümle iki ayrı okuyucu tarafından yanlış okundu** (bu spec'in ilk sürümü ve heyet review'u). Bu yüzden AD-25'in son cümlesi **dışlama biçiminde** yazılır: *"Design token'ları tek CSS değişken kaynağından **Filament dışındaki tüm ön yüzlere** beslenir."* ⚠ Sayım yerine dışlama, çünkü sayım eksik kalır: heyet haklı olarak landing'in (EGT-40) ne ofis ne müşteri yüzeyi olduğunu, *"ofis ve müşteri"* denirse dışarıda kalacağını işaretledi. Dışlama ifadesi bugünkü üç yüzeyi de, yarın doğacak dördüncüyü de kapsar ve kuralın gerçek sınırını söyler — sınır Filament'tir. Değişen tek politika `kod-yerlesimi.md` §4'tür: orada Filament **adıyla** sayılıyor. ### Karar 9 — Tasarımdan sapmak gerekçe ve onay ister ⚠ **Bu kural diğer sekizinin üstünde durur.** Ofis ve portal ekranlarında tasarımcının `design/` altında ürettiği sayfalar ve katalog esastır. Katalogdan üretim, ekleme ve düzenleme serbesttir; **"temel tasarım / temel design öğeleri" dışında bir şey gerekiyorsa durulur, sebebi açıklanır ve onay alınır** — ekran, bölüm veya bileşen icat edilmez. Bu, `HANDOFF.md`'nin *"tasarımcı böyle yapmış gerekçe değildir"* kuralının ters yönüdür. İkisi birlikte okunur: **sapma serbest değil, gerekçeli ve onaylı.** Kapsam dışı bırakılan tasarım parçaları da aynı şekilde açıkça listelenir (§2) — sessiz çıkarma da sapmadır. Bu spec'te bu kurala tabi iki ekleme var ve ikisi de onaylandı; §8.3'te gerekçeleriyle duruyorlar. ### Karar 10 — Doğrulama Pest + Inertia assertion'larıyla, tek zorunlu koşuyla Zorunlu olan: `assertInertia` ile hangi bileşenin çizildiği, hangi prop'ların gittiği, yetkisizin ne gördüğü, menünün izne göre filtrelendiği. Mevcut CI kullanılır; AD-26'nın grup sözlüğü değişmez. **Grup:** ofis omurga ekranları `omurga` grubuna yazılır — bugün ofis rotalarının testleri de orada (`tests/Feature/OmurgaRls/AuthorizationClosureTest.php`, `SessionSeparationTest.php`). `planlama` ve `satis` grupları kendi dikey modülleri geldiğinde kullanılır. Vitest (bileşen) **gerektiğinde** eklenir — zorunlu değildir, yasak da değildir. ⚠ **Playwright T1'de zorunludur** *(Sets, 28.07.2026)*, ama dar bir işle: kriter 7 ve 8'in kanıtı. Responsive akış bütünlüğü ve erişilebilirlik ölçüleri (focus ring, dokunma hedefi) hesaplanmış stilden okunur; elle denetim regresyonu yakalamaz ve kanıtı olmayan kriter kapanmış sayılamaz. İş mantığı Playwright'a taşınmaz — orası Pest'in işi. ### Karar 11 — Ofiste dört yöntem birden açılır Spec §5.1 dört yöntemi ilk günden tanımlıyor ve yöntem–alan eşlemesini koda sabitlemiyor (AD-08); hangi alanın hangi yöntemi kullanacağı bir **ayardır**. Sets ofiste dördünün de açık olmasını istedi: şifre, ikinci faktör (2FA), magic link, passkey. Bu, spec'e yeni bir yetenek eklemez — `config/security.php`'nin tohum varsayılanının (`office => ['password', 'two_factor']`) eksik bıraktığı iki yöntemi ekler ve o iki yöntemin ofis tarafındaki **akışlarını** T3'e yazar. ⚠ **Karar 7 ile karıştırılmamalı.** Karar 7 yalnız *"magic link + kanıtlanmış ikinci faktör = güçlü oturum"* kuralını tanımlar; dördünün açılması bu karardır. Passkey'in ofise gelmesi de buraya bağlıdır, karar 7'ye değil. (Heyet bulgusu F-10.) --- ## 4. Mimari ### 4.1 Kurulum `vue` · `@vitejs/plugin-vue` · `@inertiajs/vue3` eklenir. `tailwindcss@4`, `vite@8`, `laravel-vite-plugin@3` zaten `package.json`'da. `HandleInertiaRequests` middleware'i `web` grubuna eklenir; root view'ı **route grubu** belirler (karar 4). Ofis grubunun kökü `resources/views/office.blade.php`, derleme girişi `resources/js/office.js`. Fontlar (Archivo, IBM Plex Mono) repoya alınır ve `@font-face` ile servis edilir. Mockup'lar `fonts.googleapis.com` kullanıyor; üretimde her sayfa yüklemesinde üçüncü tarafa giden bir istek gereksizdir. ### 4.2 Paylaşılan prop'lar | Prop | İçerik | Kaynak | |---|---|---| | `auth` | ad, e-posta, baş harfler, ikinci faktör durumu | oturumdaki `User` | | `navigation` | izne göre filtreli menü | `App\Queries\Office\OfficeNavigation` | | `flash` | tek seferlik bildirim | session | | `translations` | sayfanın bildirdiği çeviri grupları | `lang/{locale}/*.php` | | `locale` | aktif dil | `SetLocale` | ⚠ Menü **zaten** izin filtreli üretiliyor ve ikinci hattır: rota kendi yetkisini taşır (`routes/office.php`). Kriter 2f ikisini birden ister — menüde olmamak **ve** adresi yazarak ulaşamamak. ### 4.3 Token katmanı `resources/css/tokens.css`, Tailwind 4 `@theme` bloğu. `00 Tokenlar`'ın tamamı birebir: - **ink skalası** — 8 basamak (`#1E262E` … `#E7EBEE`) - **yüzeyler** — surface `#FFFFFF`, bg `#EEF1F3`, bg-sunken `#E6EAED` - **accent** — `oklch(.5 .1 243)` / `oklch(.42 .1 243)` / `#E0EBF3` - **semantik dörtlüler** — kritik · uyarı · dikkat · başarı · bilgi · nötr, her biri dot/fg/bg/border - **viz paleti** — 8 renk, sıra sabittir (seri 1 daima viz-1) - **spacing** — 4'lük ızgara, 10 adım - **radius** — 4 chip · 8 input · 10 banner · 12 kart · full rozet - **gölge** — kartta yok; popover/menü ve modal/drawer için iki seviye - **breakpoint** — 375 / 768 / 1024 / 1440 - **tipografi** — display / h1 / h2 / h3 / body / small / caption / micro, `tnum` açık ⚠ **Token dışı renk ve spacing kullanılmaz.** Mavi asla sorun anlatmaz; aynı renk her yerde aynı anlamı taşır. ### 4.4 Atomic yapı ``` resources/js/ ├── office.js Inertia createApp, layout ataması, t() kurulumu ├── lib/ t() · rota yardımcıları · tarih/para/telefon biçimleyicileri ├── atoms/ BaseButton · TextInput · PasswordInput · OtpInput · SelectInput │ SearchableSelect · Checkbox · Radio · Toggle · Badge · Chip │ Avatar · Spinner · Icon · Label · HelperText · ErrorText ├── molecules/ FormField · StatusBadge · LockNote · PageHeader · EmptyState │ ConfirmModal · Toast · SessionRow ├── organisms/ AppSidebar · AppTopbar · DataTable · PermissionMatrix ├── templates/ AuthLayout · PanelLayout · ErrorLayout └── pages/ Auth/* · Profile/* · Errors/* · Users/* · SystemLog/* ``` Kurallar (`kod-yerlesimi.md` §3): - Sayfa iş mantığı barındırmaz; hesap ve dönüşüm `lib/`'e veya sunucuya taşınır. - Üç seviyeden fazla prop geçişi yapı hatasıdır — composable'a taşınır. - Birden çok sayfada kullanılamayan organizma, sayfaya ait bir molekül yığınıdır. Dosya ve sembol adları İngilizce, kullanıcıya görünen her metin Türkçe ve çeviri dosyasından (CLAUDE.md dil kuralı). ### 4.5 Veri akışı Controller → `app/Queries/Office/*` → `app/Data/*` → prop. Form → Inertia form helper → `app/Http/Requests/*` → `app/Actions/*`. Controller'da query builder ve `validate()` yasak; Action tek public giriş noktası taşır ve transaction sınırıdır. Doğrulama hataları Inertia'nın `errors` prop'undan `FormField`'a düşer. ⚠ **Ölçülmesi gereken kalem:** `bootstrap/app.php`'deki `AuthenticationRefused` işleyicisi `expectsJson()` ile dallanıyor — JSON tarafı 422, diğeri `back()->withErrors()`. Inertia isteğinin hangi dala düştüğü **çalıştırılarak** doğrulanır. Yanlış dal, giriş hatasının ekranda hiç görünmemesi demektir ve bu sessiz bir hatadır. ### 4.6 Hata yüzeyi 403 / 404 / 500 / bakım / oturum süresi doldu — hepsi Inertia sayfası, `ErrorLayout` üzerinden. 403 sayfası *"yetkiniz yok"* der; audit satırı zaten `bootstrap/app.php`'de yazılıyor ve bu ekran onu değiştirmez. ⚠ **"Yetkiniz yok" ile "bu kayıt olmaz" ayrı cümlelerdir.** Birincisi 403 sayfası, ikincisi `LockNote` — kaydın kendi engel listesi (`GuardsDeactivation` deseni). --- ## 5. Kimlik yüzeyi ### 5.1 Yöntemler Spec §5.1 ilk günden dört yöntem tanımlar ve yöntem–alan eşlemesini **koda sabitlemez** (AD-08). Ofis için dördü de açılır: | Yöntem | Bugünkü durum | Bu turda | |---|---|---| | Şifre | `SignInOfficeUser` çalışıyor | ekranı yazılır (T1) | | İkinci faktör (2FA) | kolonlar var, akış yalnız Filament'te | ofis kurulum + doğrulama ekranı (T1) | | Magic link | müşteri tarafında çalışıyor | ofis akışı + güçlü oturum kuralı (T3) | | Passkey | yalnız backoffice'e bağlı | ofis tablosu + model + RP id (T3) | `config/security.php` `default_methods.office` bugün `['password', 'two_factor']`; `magic_link` ve `passkey` eklenir. Bu bir tohum varsayılanıdır — kalıcı ayar admin panelindedir. ### 5.2 Passkey'in gerçek maliyeti ⚠ **"Altyapı kurulu, sadece entegre et" değildir.** `config/passkeys.php` `authenticatable`'ı `BackofficeUser`'a, relying-party id'sini backoffice host'una bağlıyor; dosyanın kendi yorumu *"bu basitçe başka yere yöneltilemez — izin aileleri gibi kendi tablosuna ihtiyaç duyarlar"* diyor ve `docs/issues.md` aynı kaydı *"Passkey — üç kimlik alanı, tek authenticatable model"* başlığı altında tutuyor. Bir passkey **kayıt edildiği host'a** bağlıdır: backoffice passkey'i ofis host'unda çalışmaz. Ofis passkey'i = kendi tablosu + kendi modeli + ofis relying-party id'si + kendi tören akışı. Bu yüzden T3'tedir. ⚠ Passkey **güvenli bağlam** ister; ekran bunu kontrol eder ve sessizce başarısız olmak yerine söyler. ### 5.3 İkinci faktör kuralı Kural **oturuma** sorulur, hesaba değil (spec §5.2, v1.15): ya kimlik girişi + ikinci faktör, ya passkey. Ofiste bu kural **yetki bazlıdır** (karar 6): kurulmamışsa MFA'lı izinler etkisizdir. Profil değişikliklerinde şifre yeniden sorulur ve **ayrı bir modal**'dır, form alanı değil (spec §5.2, v1.16): e-posta değişimi, şifre değişimi, passkey ekleme/silme, ikinci faktör kurma/kapatma. ⚠ **Kapı buton yokluğuyla kurulmaz.** Backoffice'te bu ders canlı öğrenildi: gizlenmiş bir işlem adıyla çağrılabiliyordu. Ofis tarafında da kapı sunucuda durur. ### 5.4 Ofis magic link akışı ve kapatılamaz teyit adımı Spec §5.3: *"Magic link ile açılan **her** oturumda ek kimlik teyidi adımı zorunludur ve kapatılamaz. Teyit adımının **hangi bilgiyi sorduğu** admin tarafından seçilebilir, **varlığı** seçilemez."* Gerekçe: bağlantı paylaşılabilir olduğu için tek başına kimlik kanıtı değildir. ⚠ **Ofiste bu adımın soracağı bir şey yok.** Bugünkü tek seçenek `national_id_last_four` (`config/security.php:49`) ve ofis `users` tablosunda TCKN kolonu yok — `national_id` yalnız müşteri kimlik tablolarında (`2026_07_27_000200_create_customer_identity.php:158`). Ofis kimliğinden TCKN toplamıyoruz ve bu turda toplamayacağız. **Karar** *(Sets, 28.07.2026 — backoffice'te aynı desen zaten çalışıyor)*: ofiste teyit adımının yerini **ikinci faktörün kendisi** alır ve akış bir **ara ekranla** kurulur: 1. Magic link tıklanır, oturum açılır ama **hiçbir panel ekranı açılmaz**. 2. İkinci faktörü kurulu olan kişiye faktör sorulur; kanıtlanınca oturum güçlü olur (karar 7) ve gideceği yere düşer. 3. İkinci faktörü **kurulu olmayan** kişi ara ekrana düşer: *"Devam etmek için passkey ya da iki adımlı doğrulama tanımlamalısınız."* Kurulum biter bitmez akış kaldığı yerden devam eder. ⚠ **Bu, karar 6'yı geçersiz kılmaz — yol bazlı bir farktır ve farkın kaynağı §5.3'tür.** Şifre yolunda ikinci faktör **yetki bazlıdır**: kurulum teklif edilir, MFA'lı yetkiler kurulana kadar etkisiz kalır. Magic link yolunda ikinci faktör **zorunludur**, çünkü §5.3'ün kapatılamaz teyit adımı ofiste odur. Aynı kişi şifreyle girip faktörsüz çalışabilir, ama magic link ile giremez. ⚠ Bu okuma §5.3'e **ofis niteleyicisi** ekler ve §7 tablosunda revizyon olarak listelidir. Müşteri ve katılımcı tarafında teyit adımı aynen kalır: orada soru `national_id_last_four`'dur ve ikinci faktör bunun yerini almaz. ### 5.5 "Yetki bekliyor" ile "ikinci faktör bekliyor" ayrı uyarılardır İki uyarı benzer görünür ve **karışırlarsa yönetici yanlış işi yapar**. Ayrımın kelimesi *"tanımlanmış"* ile *"etkin"* arasındadır: | Uyarı | Koşul | Kime | Çözümü kim yapar | |---|---|---|---| | **Yetki bekliyor** (omurga-spec §3.0.2 P-2) | Aktif hesap, **hiç yetki tanımlanmamış** | Yöneticisine | Yönetici — yetki atar | | **İkinci faktör bekliyor** (karar 6 bandı) | Yetki tanımlı, ama MFA'lı olanlar **etkisiz** çünkü ikinci faktör kurulu değil | Kullanıcının kendisine | Kullanıcı — faktörünü kurar | ⚠ **Koşul "etkin yetki" olsaydı kural kendi içinde çelişirdi** *(heyet bulgusu R2-1)*. MFA'lı izinler kurulum yapılmadan **etkisizdir** (`PermissionFamilies::requiresMfaAndLacksIt()` — verilmiş ama etkin değil). Yalnız MFA'lı izin atanmış bir kullanıcıda — örneğin ilk yetkileri `user.assign_permissions` ve `financial.view` olan yeni bir direktörde — etkin yetki sayısı sıfır olurdu: uyarı yetki verildiği hâlde düşmez, yönetici "yetki bekliyor" okur, oysa bekleyen şey kullanıcının kendi kurulumudur. Upstream'in kelimesi de bunu söylüyor: §3.0.2 *"yetkileri henüz **tanımlanmadıysa**"* der, "etkisizse" değil. --- ## 6. Ekran envanteri ### T1 — Temel ve giriş | Ekran | Kaynak | Not | |---|---|---| | Ofis girişi | `10 Ortak Auth` | koyu sol kolon + form; **passkey butonu ve magic link yolu dahil** (v1.5) | | İkinci faktör doğrulama | `10 Ortak Auth` | 6 haneli kutulu giriş, yedek kod bağlantısı | | Şifre sıfırlama (iste / belirle) | `10 Ortak Auth` | güç göstergesi; güncelleme sonrası tüm oturumlar kapanır | | Profil — güvenlik | `10 Ortak Auth` | ikinci faktör kurulumu, aktif oturumlar, şifre modalı | | Hata sayfaları | `10 Ortak Auth` | 403 / 404 / 500 / bakım / oturum | | Panel kabuğu | `20 Planlamaci Sorgulama` · `30 Satisci Dashboard` · `40 Egitmen Paneli` | sidebar (216px, gruplu, ≤5 kalem, hairline), **sidebar altında kimlik bloğu**, breadcrumb'lı sayfa başlığı standardı. ⚠ **Topbar yok** (v1.5) | | Profil — passkey | `10 Ortak Auth` | ekleme/silme, şifre penceresi arkasında | | Ofis magic link | `10 Ortak Auth` | iste / gönderildi / süresi doldu | | **İkinci faktör ara ekranı** | §5.4 | *"Devam etmek için passkey ya da iki adımlı doğrulama tanımlamalısınız."* Passkey ve uygulama yolu aynı ekranda | ### T2 — İş ekranları | Ekran | Kaynak | Not | |---|---|---| | Kullanıcılar | `63` + `02 Veri Gosterimi` | liste, durum rozeti, son giriş, yetki matrisi, kilitli atama. Hızlı aksiyonlar: **detay · dondur · kapat · kısıtı kaldır** — *"kısıtla"* yok (§8.1). **Dondur ve kapat gerekçe ister** (§8.4) | | Kullanıcı detayı | `63` | Sade hesap detayı: kimlik, hesap durumu, son giriş, ikinci faktör durumu, yetki matrisi **ve o kişinin denetim izi**. ⚠ Kokpit kartları (geciken işler, haftalık performans, ciro) **yok** — besledikleri modüller yazılmadı; geldiklerinde bu ekrana eklenir (§2) | | "Yetki bekleyen kullanıcınız var" uyarısı | omurga-spec §3.0.2 P-2 | Listede rozet + kabukta uyarı bandı. ⚠ Ofis kimliğinde **yeni kolon gerekmez**: §3.0.2'nin statü ayrımı (eğitim personeli ↔ panel personeli) müşteri tarafına aittir; ofiste herkes panel personelidir, dolayısıyla uyarının koşulu *"aktif hesap, **hiç yetki tanımlanmamış**"*tır — bkz. §5.5 | | Sistem günlüğü | `63` | append-only, filtreli, maskeli değerler | ### T3 — *(boşaltıldı, v1.5)* ⚠ **T3'ün tamamı T1'e alındı** *(Sets, 28.07.2026)*. Gerekçe kapsamdı, bağımlılık değil: `spatie/laravel-passkeys` her değeri `Support/Config`'ten **çağrı anında** okuduğu için tek paket iki alana hizmet edebilir — `PermissionFamilies::using()` deseninin aynısı (`App\Support\Auth\Passkeys\PasskeyDomains`). Bu, spec'in daha önceki *"basitçe başka yere yöneltilemez"* okumasını düzeltir: yöneltilemeyen şey **tablodur**, mekanizma değil. Sets'in ilk günkü şartı dördünün de ofiste çalışmasıydı; T3 ayrımı o şartı sessizce daraltıyordu. --- ## 7. Üst belgelerde yapılacak revizyonlar Onay kuralı 6 gereği açıkça listelenir; hiçbiri örtük bırakılmaz. | Belge | Değişiklik | Kaynak karar | |---|---|---| | `docs/specs/omurga-spec.md` §5.3 — *"magic link panel yetkisini açmaz"* | magic link + kanıtlanmış ikinci faktör = güçlü oturum, **yalnız ofis**; müşteri/katılımcı aynen kalır | karar 7 | | `docs/specs/omurga-spec.md` §5.3 — *"her oturumda ek kimlik teyidi zorunlu"* | ofiste teyit adımının yerini ikinci faktör alır; müşteri/katılımcıda `national_id_last_four` aynen kalır | karar 7 · §5.4 | | `docs/specs/omurga-spec.md` §5.5 kabul kriteri | *"magic link oturumunun panel ekranlarını açmadığı gösterilir"* cümlesine ofis niteleyicisi eklenir — aksi halde karar 7 uygulandığında kriter yanlışlanır | karar 7 | | `docs/specs/omurga-spec.md` §14 kriter 25 | aynı niteleyici: ofiste ikinci faktör kanıtlanmış magic link oturumu panel ekranlarını açar | karar 7 | | `docs/plans/omurga-plan.md` — kriter sicili satır 25, chunk6 kriter 7c'nin ofis bacağı | kanıt adresi ofis turuna taşınır; **plan aşamasında** yapılır, bu spec'in işi değil ama adresi burada duruyor | karar 7 | | `config/security.php` | `default_methods.office` → `password`, `two_factor`, `magic_link`, `passkey` | **karar 11** | | `docs/arch/kod-yerlesimi.md` §4 | tek token kaynağı kuralı **Filament dışındaki tüm ön yüzlere** daralır; Filament adıyla sayıldığı için **gerçek revizyon**. ⚠ İfade AD-25 satırıyla **birebir aynı** olmalı — iki belgede iki sınır, landing turunda aynı soruyu yeniden doğurur | karar 8 | | `docs/arch/mimari-kararlar.md` AD-25 (`:373`) | politika değişmez, **ifade netleşir**: *"her iki taraf"* → *"Filament dışındaki tüm ön yüzler"*. Cümle iki ayrı okuyucu tarafından "Vue + Filament" diye okundu; sayım yerine dışlama, landing'i de kapsasın diye | karar 8 | | `docs/arch/kod-yerlesimi.md` §3 | derleme girişi panel başına ayrılır kuralı eklenir | karar 5 | | `docs/issues.md` — *"Passkey — üç kimlik alanı, tek authenticatable model"* | kayıt açıktan T3'e adreslenir | **karar 11** | | `current_todo.md` §7/1 | "kısıtla" sorusu **kapandı**: hız sınırı, yaptırım değil (§8.1) | karar — Sets, 27.07.2026 | --- ## 8. Tasarımla uzlaştırılan noktalar *Hepsi Sets tarafından kapatıldı: §8.1–§8.3'ün ilk iki satırı 27.07.2026, §8.3'ün üçüncü satırı (ara ekran) ve §8.4 28.07.2026. Açık kalan yok.* ### 8.1 "Kısıtla" bir yaptırım değil, sistemin ürettiği geçici durumdur `63`'te *"5 başarısız deneme · 09:12"* → rozet *"Girişi Kısıtlı (30 dk)"*. Bu **giriş hız sınırıdır** (spec A-1: eşik ve kilit süresi admin-tanımlı) ve **hesap durumu değildir**. ⚠ **Bir kullanıcının başka bir kullanıcıya elle uygulayabileceği yaptırım ikidir: dondur ve kapat.** Tasarımdaki *"Kısıtla"* aksiyonu bu yüzden **yazılmaz** — kimse durduk yere bir hesabı kısıtlamaz; kısıtı sistem koyar. *"Kısıtı Kaldır"* **kalır**: yaptırımın kendisi değil, kaldırılmasıdır ve tek yönlüdür. Yanlış şifreyle kendini kilitleyen kişi 30 dakika beklemek yerine yöneticisine söyler. Audit'lenir. Bu, `current_todo.md` §7'nin birinci açık sorusunu kapatır. ### 8.2 Telefon maskesi alana göre seçilir Tasarımcının `(5__) ___ __ __` maskesi ilk haneyi sabitler ve sabit hatları reddeder; bizim `(999) 999 99 99` standardımız (`app/Support/Phone/PhoneNumber.php`) sabitlemez. Karar: **maske alanın anlamına göre seçilir.** Cep telefonu istenen alanlarda tasarımcının maskesi, genel telefon alanlarında (firma santrali, eğitim yeri) esnek olan. Depolama her iki durumda da E.164 ve tek kolon — bu değişmez. ### 8.3 Tasarımda karşılığı olmayan iki ekleme — onaylandı | Ekleme | Gerekçe | Nasıl | |---|---|---| | Ofis giriş ekranına magic link yolu | `10 Ortak Auth` magic link'i yalnız müşteri girişine koymuş; Sets dört yöntemin de ofiste olmasını istedi (**karar 11**) | Desen müşteri giriş ekranından bire bir alınır: "VEYA" ayıracı + ikincil buton. Yeni bileşen icat edilmez. T3 | | Panelde "ikinci faktörünü kur" uyarı bandı | MFA'lı yetki tutan ama ikinci faktörü olmayan kişi, yetkisinin neden çalışmadığını bir yerden öğrenmeli (karar 6) | `04 Geri Bildirim`'in mevcut banner deseni kullanılır — yeni bileşen değil, mevcut desenin yeni kullanımı. T1 | | Magic link sonrası ikinci faktör ara ekranı | §5.4'ün kapatılamaz teyit adımı; tasarımda ofis magic link akışı hiç yok | Backoffice'te çalışan desenin aynısı. Bileşenleri T1'in kurulum ekranıyla ortak. T3 | ### 8.4 Dondur ve kapat gerekçe ister `HANDOFF.md` bağlayıcı kural 10: *"Dondur/kısıtla gerekçeli"*, ve `04 Geri Bildirim` destructive modal deseni zaten gerekçe alanı taşıyor. Spec v1.1 yalnız *"kısıtı kaldır audit'lenir"* diyordu; eksikti. **Kural:** dondurma ve kapatma **gerekçe alanı zorunlu** bir onay modalıyla yapılır; gerekçe audit satırına yazılır. Kapatma ayrıca **şifre onayı** ister (geri dönülemez işlem — backoffice'te uygulanan kural). Kısıtı kaldırmak gerekçe istemez ama audit'lenir: yaptırım değil, kaldırılmasıdır. --- ## 9. Kabul kriterleri 1. Ofis host'unda giriş sayfası açılıyor; doğru kimlikle panele giriliyor, yanlış kimlikte **hata ekranda görünüyor** (test — Inertia yanıtı ve `errors` prop'u). ⚠ İkinci yarı ilk yarıdan önemli: §4.5'teki `expectsJson()` dallanması yanlış tarafa düşerse giriş hatası hiç görünmez. 2. `tokens.css`, `00 Tokenlar`'daki her değeri karşılıyor; `resources/js` altındaki hiçbir dosya ham hex rengi veya keyfi Tailwind değeri (`bg-[#…]`, `p-[13px]`) taşımıyor (arch testi — dizin taraması). 3. Menü izne göre filtreli çiziliyor **ve** yetkisiz kullanıcı adresi yazarak da giremiyor (test — iki ayrı iddia). 4. Kullanıcıya görünen hiçbir metin Vue dosyasına gömülü değil; hepsi çeviri prop'undan geliyor. Arch testi `resources/js` altında **iki kanalı** ölçer: - **(a) Template metin düğümleri** — `t()` çağrısı ya da boş olmalı. - **(b) Kullanıcıya görünen attribute ve prop'lar** — `label`, `placeholder`, `title`, `alt`, `aria-label`, `aria-description` ve bileşenlerin metin taşıyan prop'ları (`…Label`, `…Text`, `…Message`) **bağlı yazılmalıdır** (`:label="t('…')"`); düz literal (`label="Ad Soyad"`) reddedilir. Liste config'te tutulur ve yeni bir metin prop'u eklendiğinde oraya yazılır. ⚠ Ölçüm iki kez düzeltildi. Önce "Türkçe karakter taraması"ydı — diakritiksiz metni (*"Durum"*, *"Profil"*, *"Ad"*) kaçırıyordu (heyet F-8). Sonra yalnız metin düğümü taramasıydı — form ağırlıklı bu sistemde metnin büyük kısmı **prop olarak** geçtiği için kanalın yarısını ölçmüyordu (heyet R2-2). ⚠ **Bilinen sınır:** `