# Spec 1 — Platform Omurgası *EGT-21 · Sürüm 1.17 · 16.09.2026* **Upstream:** `cati-dokumani.md`, `docs/arch/mimari-kararlar.md` (AD-01…AD-28), `docs/mevzuat-kurallari.md` **Downstream:** Spec 2 (Tanımlar ve kural motoru), Spec 3 (Organizasyon, yetki ve onay), Spec 4-8 (dikey modüller) --- ## 1. Bu spec ne tanımlar Platform omurgası, **hiçbir dikey modülün kendi başına çözemeyeceği ve her modülün üzerine oturduğu** davranışları tanımlar: bir kaydın hangi kiracıya ait olduğu ve kimin görebileceği, kimin nasıl giriş yaptığı, her işlemin ve her hassas okumanın nasıl iz bıraktığı, hassas verinin nasıl korunduğu, kayıtların dışarıya hangi kodla anıldığı, bildirimlerin hangi kanaldan ve hangi izinle gittiği, kullanıcının bir şeyi anında nasıl öğrendiği. Bu davranışlar sonradan eklenemez. Tenant izolasyonu, audit ve şifreleme bir ürüne sonradan takılırsa her modül yeniden yazılır (AD-05, AD-06'nın gerekçesi). Bu yüzden omurga ilk spec'tir ve dikey modüller ona uyar, tersi değil. ## 2. Kapsam dışı (non-goals) Bunlar **başka spec'lerin işidir**; burada tanımlanmazlar ve burada eksik oldukları için bulgu sayılmazlar: | Konu | Nerede | |---|---| | Organizasyon ağacı, roller, kapsam seviyeleri, onay zincirleri, eskalasyon | Spec 3 | | Evrak türü şablonu, gereklilik motoru, evrak talebi görevleri | Spec 2 / Spec 4 | | Mevzuat kaydı ve kısıt miras kuralları | Spec 2 | | Eğitim, teklif, yoklama, sertifika, kontenjan, mali akışlar | Spec 4-8 | | Panel ekran tasarımları, sayfa kompozisyonu | Tasarım handoff — ⛔ **bağlayıcıdır** *(düzeltme: Sets, 30.07.2026; bu satır önce "bağlayıcı değil" diyordu)* | | Implementasyon yaklaşımı: hangi sınıf, hangi dosya, hangi migration | Plan aşaması | Ayrıca **ürün olarak kapsam dışı**: mobil uygulama, kişi bazlı kullanım/performans izleme, blockchain tabanlı kanıt zinciri, bakanlık sistemlerine otomatik veri gönderimi (AD-15). ⛔ **Pazarlama gönderimi ve İYS de kapsam dışı** *(Sets, 07.08.2026)*. Bu sistem üzerinden pazarlama yapılmıyor: gönderilen her şey işlemsel — teklif, şifre hatırlatma, magic link, görev bildirimi. Ticari elektronik ileti altyapısı **yok**, dolayısıyla İYS'ye bildirilecek bir onay/ret de yok. ⚠ Yapılırsa **planlanacak**, kendiliğinden eklenmeyecek. Kod bunu zaten söylüyor (`NotificationEvent`: hiçbir olay promosyonel değil) ve `MessageClass::Broadcast` yolu ilk promosyonel gönderim için hazır duruyor — o gün gelene kadar onay kapısı da İYS bildirimi de yazılmaz. ## 3. Üç bağımsız kimlik alanı *(v1.11 — 26.07.2026. Önceki sürümlerde **iki** alan tanımlıydı ve backoffice, ofis kimliği üzerindeki `system.access_backoffice` izniydi. Sets kararıyla üçüncü alana ayrıldı; gerekçe aşağıda.)* Omurga **üç ayrı kimlik alanı** tanır. Bunlar farklı organizasyonlara aittir ve **hiçbir tabloyu paylaşmazlar** — özellikle yetki tablolarını. Bir alandaki yetki kuralı diğerine sızamaz. | Alan | Kim | Kimlik kaydı | Tenant bağlamı | |---|---|---|---| | **Ofis** | 3E personeli: operasyon direktörü, satış/eğitim direktörü, grup yöneticileri, planlamacı, satışçı, eğitmen | `users` | Tenant'a ait **değildir**. Hangi müşterilerin verisine erişebileceği organizasyon kapsamından gelir (Spec 3). | | **Backoffice** | Sistem çekirdeğini yönetenler: süper admin (pratikte şirket sahibi) ve ileride destek görevlisi gibi **ofis personeli olmayan** roller | `backoffice_users` | Tenant'a ait **değildir**. **Yetki tavanı yoktur** — gerektiğinde her tenant'ın verisine erişebilir (§3.3). Bugün hangi işlerin backoffice'te yapıldığı ayrı bir sorudur ve **kapsam tercihidir** (§3.4). | | **Müşteri** | Firma yetkilisi, departman/grup yöneticisi, eğitim alan personel | `customers` + `customer_users` | Tam olarak bir tenant | **Gerekçe (Sets, 26.07.2026):** üçü bağımsız organizasyondur. Ofis ve müşteri için gerekçe zaten yazılıydı; backoffice'i ayırmanın gerekçesi ayrıdır ve şudur: > **Ofis çok net bir yapıdır; backoffice ihtiyaca göre şekillenecek, farklı ve karmaşık yetki yapıları gerektirecektir.** İleride kurulacak destek yapısı ofis paneline **hiçbir şekilde** girmeyecek ama işini yapabilmek için müşteri verisinin bir kısmına ticket bazında erişmek zorunda kalacaktır. Bu tür şeyleri normal `users` üzerinde **istisna** olarak tanımlamak yerine backoffice'in **normal rutini** olarak tanımlamak, ofis yapısını standartlar içinde tutar ve ofisin denetimini/kontrolünü belirgin biçimde kolaylaştırır. Yani ayrım bir güvenlik paranoyası değil, **karmaşıklığı tek yerde toplama** kararıdır: ofis sade kalsın, karmaşık ve duruma göre şekillenen yetki backoffice'te yaşasın. ### 3.0 Müşteri tarafında tek kimlik, katmanlı yetenek Müşteri tarafında **kişi başına tek kayıt** vardır (`customer_users`). "Panel kullanıcısı" ve "katılımcı" ayrı hesaplar değildir; aynı kişinin iki ayrı yeteneğidir. | Yetenek | Nereden gelir | Sonucu | |---|---|---| | **Katılımcılık** | **Veriden türer** — kişinin bir eğitime kayıt kaydı (`training_participants`) varsa | Katılımcı ekranları açılır: oturum beyanı, anket, kendi eğitim geçmişi | | **Panel yetkisi** | Firma tarafından **açıkça verilir** | Firma paneli menüleri açılır: teklif isteme, personel yönetimi, organizasyon | | # | Gereksinim | |---|---| | U-1 | Hiçbir panel yetkisi olmayan kişi **yalnız** katılımcı ekranlarını görür. Firma paneline URL ile de erişemez. | | U-2 | Eğitim kaydı olmayan kişi katılımcı ekranlarını görmez (ör. dışarıdan gelen muhasebe sorumlusu). | | U-3 | İkisi birden olan kişi her iki menü grubunu görür. **Hesap transferi, hesap birleştirme veya ikinci kayıt gerekmez.** | | U-4 | Bir katılımcıya panel yetkisi vermek = mevcut kayda yetki eklemek. Veri taşınmaz. | | U-5 | Yetki verme ve kaldırma audit'lenir ve kişiye bildirilir. | **Katılımcılık ayrı bir kayıttır:** `training_participants` kişi × eğitim ilişkisidir. Yoklama, sınav sonucu ve bakanlık sertifika kodu bu kayda aittir, kişiye değil — aynı kişi birden çok eğitime katılır, her biri ayrı kayıttır. #### 3.0.2 Hesap **ne olarak** açıldı — davet ve "yetki bekliyor" *(v1.12 — Sets, 27.07.2026. Üç kimlik alanının hepsi için geçerli.)* Bir hesap iki gerekçeden biriyle açılır ve bu, hesabın **statüsüdür**: | Statü | Ne beklenir | |---|---| | **Eğitim personeli** (katılımcı) | Panel yetkisi beklenmez. Yetkisiz olması normal ve kalıcı bir durumdur (U-1). | | **Ofis/panel personeli** | Yetki beklenir. Yetkileri henüz tanımlanmadıysa yöneticisine **"yetki bekleyen kullanıcınız var"** uyarısı çıkar. | | # | Kural | |---|---| | P-1 | Uyarı **"izni boş olanlar" diye hesaplanamaz.** Katılımcı hesabı da izinsizdir; öyle hesaplanırsa her katılımcı uyarı üretir, rozet kalıcı gürültüye döner ve gerçekten bekleyen kişi tam da o yüzden kaçırılır. Uyarının dayanağı hesabın **statüsüdür**. | | P-2 | ⚠ **İki statü birbirini dışlamaz ve kalıcı değildir.** Ofis personeli eğitime katılabilir; eğitim katılımcısı sonradan ofis personeli yapılabilir. Aynı kişi, aynı kayıt (U-3, U-4) — statü değişir, hesap değişmez. Uyarıyı doğuran şey kişinin **panel personeli olması**dır; ayrıca katılımcı olması bunu değiştirmez. | | P-3 | **Kritik bilgilerin tamamı hesap açılırken verilir** — ad, TCKN gibi zorunlu alanlar dahil. Eksik veriyle hesap açılmaz. Davet edilen kişinin kendisi **yalnız şifresini** belirler. | | P-4 | Davet bağlantısı **tek kullanımlık ve sürelidir**; tamamlanması tek başına **hiçbir yetki vermez**. Aynı e-posta başka bir tenant'ta kayıtlıysa cevap değişmez (I-1, I-2) — aksi hâlde davet ucu "bu firma 3E ile çalışıyor mu" sorusunu yanıtlayan bir sorgu hâline gelir. | | P-5 | **Son yetkilinin kaldırılması engellenmez, uyarılır.** Ofis tarafında dert değildir: backoffice adminleri durdukça operasyon direktörü görevden alınabilir ve yerine yenisi atanır. Sistem yalnız bilgilendirir; dayatma koymaz. | ### 3.0.1 Ofis tarafında da aynı ilke Ofis panelinde de menü ve sayfa erişimi **yetkiden türer**, kullanıcı türünden değil. Yetkisiz menü hiç render edilmez, yetkisiz sayfaya URL ile erişilemez (§6 Y-5). ### 3.1 Tenant = firma; firmanın iki hukuki türü vardır **Tenant = müşteri firma** (AD-02). Türk mali mevzuatı gereği firma iki türde açılabilir: - **Tüzel kişi** — şirket. - **Gerçek kişi** — şahıs firması. **"Bağımsız katılımcı" ayrı bir aktör değildir.** Kendi başına eğitim almak isteyen kişi, sisteme **gerçek kişi firma** olarak kaydedilir ve fatura ona bu sıfatla kesilir (çatı 2. tur karar #14). Bu tenant'ta tek bir `customer_users` kaydı bulunur; aynı kişi hem teklifi onaylar hem eğitime katılır. §3.0'daki katmanlı yetenek modeli bunu ek bir yapı gerektirmeden karşılar. Gerekçe: sektörde bu yapı olağandır — kendi şahıs şirketi üzerinden çalışan sürücüler, bir ofise bağlı da bağımsız da çalışabilen serbest meslek sahipleri. Ayrı bir "bireysel" aktör türü tanımlamak faturalama, teklif onayı ve izolasyon kurallarını ikiye bölerdi; firmanın hukuki türü zaten bu ayrımı taşıyor. ### 3.2 Kimlik tenant sınırını aşmaz — pazarlıksız kural **Katılımcı, kayıtlı olduğu firmaya aittir. Bir katılımcı firma değiştirirse sistem için YENİ bir kişidir.** | # | Gereksinim | |---|---| | I-1 | Sistem, müşteri tarafındaki kişileri **tenant'lar arasında eşleştirmez ve birleştirmez**. TCKN, telefon, e-posta veya başka bir kimlik alanı üzerinden çapraz tenant eşleme **yapılmaz** — otomatik olarak da, öneri olarak da, "aynı kişi olabilir" uyarısı olarak da. | | I-2 | Aynı gerçek kişi farklı tenant'larda ayrı `customer_users` kayıtları olarak yaşar; kayıtlar birbirini görmez ve birbirine referans vermez. ⚠ **v1.17 (16.09.2026, EGT-208):** bu ayrı kayıtlar **aynı e-posta adresini taşıyamaz** — e-posta sistem genelinde tektir (durumdan bağımsız). Firma değiştiren kişi yeni firmaya ancak farklı bir adresle ya da eski firma kaydı kalktıktan sonra eklenir. `ad+etiket@alan` ayrı adrestir. Kayıtların ilişkilendirilmemesi kuralı değişmedi; tekleşen yalnız adrestir. | | I-3 | Bir tenant'taki kişinin eğitim geçmişi başka tenant'a **hiçbir koşulda** taşınmaz, gösterilmez veya ima edilmez. | | I-4 | Yeni firmada yenileme eğitimi gerekiyorsa dayanak, **yeni firmanın yüklediği mevcut sertifikadır** (çatı §2) — eski işverendeki kaydımız değil. Geçerlilik ve "af yok" değerlendirmesi (YÖN-2019 md.8) bu belgeye dayanır. | | I-5 | Sistem **kimlik alanları arasında da eşleştirme yapmaz**. Aynı kişinin ofis ve backoffice kaydı olabilir; sistem ikisini birbirine bağlamaz, ortak bir kimlik üretmez, birinden diğerine yetki veya oturum taşımaz ve "aynı kişi" bilgisini veri modelinde tutmaz. Gerekçe: iki alanı veri modelinde ilişkilendirmek, ayrımın kurulma sebebini (karmaşık yetkinin `users`'a istisna olarak sızmaması, §3) sessizce geri getirir ve izin/oturum dünyalarını birleştirme baskısı üretir. İki kaydın aynı kişiye ait olduğu bilgisi **organizasyonel**dir, sistem verisi olmak zorunda değildir. *(v1.11 — heyet 141 F-6)* | Gerekçe: eski işverende kayıtlı personel o firmanın verisidir. Kişiyi telefon veya kimlik numarasıyla eşleştirip geçmişini yeni işverene göstermek, eski müşterinin veri gizliliğini ihlal eder — bu ürünün 1 numaralı kırmızı çizgisinin ihlalidir. Kolaylık gerekçesiyle bile yapılmaz. ### 3.3 Backoffice'in yetki tavanı **Backoffice'in yetki tavanı yoktur.** Sistemin çekirdeğine **her türlü yetkiyle** erişilebilen yer burasıdır; ayrımın sebebi de tam olarak budur. Somut olarak: - **İlk ofis kimliğini burası doğurur ve hiçbir zaman elini çekmez.** Ofisin süper admini olan operasyon direktörü hesabı backoffice'ten açılır — sistem ilk açıldığında ofiste kimse yoktur — ve backoffice ofis hesaplarını sonrasında da yönetebilir (AD-23 kural 1'in kalıcı istisnası: *backoffice provisioning*). ⚠ **Bu, kullanıcı yönetiminin yalnız backoffice'te olduğu anlamına GELMEZ** *(v1.12 açıklaması — Sets, 27.07.2026)*. Kullanıcı yönetimi **her iki tarafta da** vardır: operasyon direktörü kullanıcı ekleme yetkisi verilmişse ofis personeli ekler, satış direktörü verilmişse satışçı ekler. Ofis, günlük işleyişte kendi kadrosunu backoffice'e sormadan kurar. Backoffice'i ayıran şey **tavanının olmaması**dır (kendisi ofis yetkisi taşımadan ofis yetkisi atayabilir, Y-4'ün adlandırılmış istisnası), ofisin bu işi yapamaması değil — ofis tarafında aynı iş Y-4'e tabidir: kimse sahip olmadığını devredemez. - **Müşteri verisine gerektiğinde erişebilir.** Eğitim verisine erişip **eğitim de oluşturabilir**. Bu bir kaçak değil, alanın tanımıdır. - Karmaşık ve duruma göre şekillenen yetki **burada** yaşar; ofis sade kalır. Bunun **kapatılmayan** karşılığı denetimdir, kısıt değil: backoffice'in tenant verisine her dokunuşu **sert biçimde loglanır** ve log yazılamıyorsa dokunuş da olmaz. Bu bir yetki sınırı değil, **denetim koşuludur** ve süper admin dahil herkese uygulanır. Dokunuşun türüne göre logun **sınıfı** farklıdır ve ikisi birbirinin yerine geçmez: | Dokunuş | Log sınıfı | Garanti | |---|---|---| | **Okuma** (tenant kaydını görüntüleme) | **Erişim logu** (§7.2), yalnız backoffice'te görünür (§7.5) | Log yazılamıyorsa okuma da olmaz | | **Yazma** (tenant kaydı oluşturma/değiştirme) | **Yazma olayı audit'i** (§7.1), işlemle **aynı transaction**'da (AD-06) | Audit yazılamıyorsa işlem de olmaz | ⚠ Backoffice'in bir tenant kaydını **yazması** her iki satırı da tetikler: yazmadan önceki okuma erişim logu, yazmanın kendisi §7.1 audit'i üretir. Kriter 33 bunu bu şekilde ölçer. #### 3.3.1 Kapılı erişim — süper admin dışındaki backoffice rolleri için Backoffice'in **kendi yetki hiyerarşisi** vardır (AD-09): süper admin her şeye erişir, ileride eklenecek roller yalnız kendi alanına. İleride kurulacak **destek** rolü işini yapabilmek için müşteri verisinin bir kısmına erişmek zorunda kalacaktır ve o erişim **kapılıdır (gated)** — dört şartı birden taşır: | # | Şart | |---|---| | G-1 | Erişim **bir gerekçeye bağlıdır** (destek yapısında: ticket). Gerekçesiz erişim yoktur. | | G-2 | Erişim **kapsamlıdır**: gerekçenin işaret ettiği tenant ve kayıtlarla sınırlıdır. | | G-3 | Erişim **süreli**dir; gerekçe kapandığında düşer. Gerekçe hiç kapanmazsa bir üst sınır olup olmayacağı **destek spec'ine bırakılmıştır** (Sets kararı, 26.07.2026): sınır spec'i mekanizma tanımlamaz. | | G-4 | Her erişim **sert biçimde loglanır** (§7.2). Log yazılamıyorsa erişim de olmaz. | ⚠ Kapı, **süper admin için bir tavan değildir**; süper adminin de her erişimi loglanır (G-4 herkese uygulanır), ancak G-1…G-3 gerekçe/kapsam/süre şartları **rol bazlıdır** ve dar yetkili backoffice rollerini tarif eder. Destek yapısının kendisi bu spec'in kapsamı dışındadır ve ayrı bir spec'te tasarlanacaktır; burada sabitlenen yalnız **o rolün erişim biçimidir**. ⚠ **Sözleşme:** süper admin **dışındaki** her backoffice rolü için müşteri verisine giden yol G-1…G-4'ü **birden** taşımak zorundadır. Bu şartları taşımayan bir yol eklemek — rol hangi adla gelirse gelsin — **spec değişikliğidir**. "Bu yeni rol destek değil, o yüzden G şartları uygulanmaz" gerekçesi geçersizdir: şartlar rolün **adına** değil, *"süper admin değil ama müşteri verisine erişiyor"* durumuna bağlıdır. ⚠ Numaralandırma `G-` önekiyledir: `B-1…B-6` **§4.1'in bootstrap istisnasına** aittir ve çakışma downstream atıflarını belirsiz bırakırdı (heyet 141 F-4). ⚠ Bu erişim biçimi **ofis kimliğine genişletilemez.** Ofisin müşteri verisine erişimi organizasyon kapsamından gelir ve zaten tanımlıdır (T-3); ofise "ticket bazlı geçici erişim" eklemek, tam olarak bu ayrımın önlemek için yapıldığı şeydir. ### 3.4 Backoffice'te bugün ne var — kapsam tercihi, yetki değil Backoffice **yapabilirliği** geniştir (§3.3); **kapsamı** bilinçli olarak dardır. Bu ikisi karıştırılmamalıdır (AD-09, "Mali sınır" paragrafı). **Bugünkü tercih (Sets, 26.07.2026 — "şu an için"):** backoffice paneline yalnız **çekirdeğe dair parametreler** konur. Mali tablolar, müşteri tabloları ve eğitim operasyonu backoffice panelinde **yer almaz** — bunlar ofisin işidir ve **ofis panelinden** yapılır. Ofis yönetimi yapılmak isteniyorsa operasyon direktörü hesabı açılıp oradan yapılır. Gerekçe yetki değil **kapsam kaymasıdır**: backoffice'e operasyon ekranı girmeye başlarsa "şu da olsun, bu da olsun" gelir ve sonunda iki ofis yazıp iki ofis maintain ederiz. ⚠ Bu bir **tercihtir** ve değiştirilebilir. Değiştirmek bir **yetki modeli değişikliği değil**, ekran/kapsam kararıdır — "backoffice erişemez" diye okunamaz. ## 4. Tenant izolasyonu ### 4.1 Temel gereksinim Bir tenant'ın verisi başka bir tenant'a **hiçbir koşulda** görünmez. Bu ürünün 1 numaralı kırmızı çizgisidir. - İzolasyon **iki bağımsız katmanda** sağlanır: uygulama katmanı (policy + otomatik kapsam) ve veritabanı katmanı (PostgreSQL RLS). Biri atlanırsa diğeri durdurur. Tek katmana güvenilmez (AD-03). - Tenant bağlamı **her zaman transaction içinde** belirlenir ve transaction bitince kaybolur. Oturum ömürlü bağlam yasaktır (AD-04) — bağlantı havuzu paylaşımlı olduğu için A tenant'ının bağlamı B'nin sorgusuna sızabilir. - Tenant bağlamı **belirlenmeden** tenant-kapsamlı hiçbir veri okunamaz veya yazılamaz. Bağlamsız istek veri döndürmez; hata verir. **Tek istisna — kimlik doğrulama (bootstrap).** Müşteri girişinde tenant, kullanıcıdan belirlenir; ama kullanıcıyı bulmak için bakılacak kayıt da tenant-kapsamlıdır. Bu tavuk-yumurta yalnız şu şekilde çözülür: | # | Gereksinim | |---|---| | B-1 | Kimlik doğrulama, tenant bağlamı belirlenmeden yürütülebilen **tek** işlemdir. | | B-2 | Bu işlem **yalnız kimlik doğrulama için gereken asgari alanlara** erişir: kimlik eşleşmesi, kimlik doğrulama sırrı, hesap durumu ve kişinin ait olduğu tenant. Ad, iletişim bilgisi, eğitim geçmişi veya başka hiçbir veri bu yoldan okunamaz. | | B-3 | Erişim **tek ve denetlenebilir bir kapıdan** geçer. Tenant-kapsamlı tablolara genel bir "bağlamsız okuma" muafiyeti tanımlanmaz — muafiyet tabloya değil, bu tek işleme aittir. | | B-4 | Doğrulama başarılı olduğu anda tenant bağlamı belirlenir; sonraki her erişim normal kurala tabidir. | | B-5 | Başarılı ve başarısız her kimlik doğrulama denemesi audit'lenir (§7.1). | | B-6 | Magic link bu istisnaya ihtiyaç duymaz: bağlantı zaten belirli bir kayda üretilmiştir, tenant bağlantının kendisinden bilinir. | ### 4.2 Davranış gereksinimleri | # | Gereksinim | |---|---| | T-1 | Müşteri kullanıcısı yalnız kendi firmasının verisini görür; başka firmanın kaydına doğrudan referansla (URL, kod, ID) erişmeye çalışırsa **bulunamadı** yanıtı alır — "yetkiniz yok" bile denmez, çünkü kaydın varlığı da bilgidir. | | T-2 | Katılımcı yalnız kendi kişisel kayıtlarını ve katıldığı eğitimin kendisini ilgilendiren kısmını görür. Aynı eğitimdeki diğer katılımcıların kimliğini göremez. | | T-3 | Ofis kullanıcısı yalnız organizasyon kapsamındaki müşterilerin verisini görür (kapsam kuralları Spec 3). Kapsam dışı bir kayda erişimi T-1 ile aynı şekilde reddedilir. | | T-4 | Backoffice çapraz-tenant erişebilir ve **yetki tavanı yoktur** (§3.3): gerektiğinde müşteri iş verisine de, denetim kaydına da erişir. Karşılığı kısıt değil **denetim**tir — her erişim **erişim logu üretir** (§7.2), ayrı bir izinle yetkilendirilir ve maskeleme kuralları ona da uygulanır. Denetim kayıtlarındaki uygulanışı §7.5 **L-4**'tür. G-1…G-3'ün gerekçe/kapsam/süre şartları **dar yetkili backoffice rollerine** aittir (§3.3.1); süper admin için tavan değildir. Backoffice'te bugün hangi işlerin **yapıldığı** ayrı ve değişebilir bir **kapsam** kararıdır (§3.4). | | T-5 | Çok-tenant'lı kayıtlarda **kaydın kendisi ile kişisel veri ayrışır**: kaydın görünürlüğü eğitim türüne bağlıdır (§4.4), katılımcı kimlikleri her durumda yalnız ilgili tenant'a ve yetkili ofis kullanıcısına görünür. | | T-6 | Toplu/agregat sayılar (kontenjan doluluğu gibi) tenant kapsamından **bağımsız** okunur; kapsamlı sorgudan türetilirse yanlış sonuç verir ve bu bir hata sayılır. | | T-7 | Prod verisi ham haliyle prod dışına çıkmaz. Test/geliştirme ortamları maskelenmiş kopyadan beslenir (AD-16). | | T-8 | **Kayıt kimliği arayüze olduğu gibi verilmez** *(Sets, 27.07.2026)*. Ofis ve müşteri panellerinde tarayıcıya giden her kimlik, **o kişiye ve o oturuma özel** bir değerle sarmalanır; gelen istek aynı değerle çözülür. Aynı kaydı iki kişi farklı görür, aynı kişi ertesi gün farklı görür (oturum **içinde** ise aynı görür — liste ile formun anlaşması için). ⚠ Gerekçe yaşanmış bir olaydır: sıralı kimlik, bir kez görüldükten sonra **sistemin dışında yaşayan sabit bir ad** olur — not edilir, paylaşılır, kişiler ayrıldıktan sonra da birleştirilebilir kalır. Sarmalama bu mekanik yolu kapatır. **İnsanın adı yazmasını engellemez**; onun cevabı kapsam daraltmadır (T-3). ⚠ **Kalıcı bağlantılar** (e-posta, yer imi, basılı belge) oturumsuzdur ve bu değeri kullanamaz: onlar **kayda özel ayrı bir tanımlayıcı** taşır ve açıldığında yine kimlik doğrulama + yetki kontrolünden geçer. İş referans kodu (§9) bir **iletişim** kimliğidir, bağlantı kimliği değildir. | ### 4.3 Kabul kriteri Tenant-kapsamlı her veri türü için, "B tenant'ının kullanıcısı A'nın kaydını göremez" davranışı **negatif testle** kanıtlanır. Test, veritabanı katmanının da devrede olduğunu doğrulayacak şekilde, uygulama kapsamı devre dışı bırakıldığında dahi verinin gelmediğini gösterir. Ayrıca §3.2 için: aynı TCKN/telefonla iki farklı tenant'a kayıtlı katılımcının kayıtlarının birbirini görmediği ve sistemin bu iki kaydı ilişkilendirmediği gösterilir. ### 4.4 Eğitim kaydının görünürlük kümesi Bir eğitimin **varlığı, tarihi, yeri ve doluluk sayısı** kime görünür — bu, eğitim türünün belirlediği sabit bir kuraldır. Serbestçe seçilen bir "görünürlük ayarı" yoktur; tür seçildiğinde görünürlük belirlenir. | Eğitim türü | Kayıt kime görünür | |---|---| | **Açık eğitim** | Tüm tenant'lara. Duyuru ve kontenjan bilgisi açıktır — bu türün amacı budur (YÖN-2019 md.11 ortak eğitim semineri). | | **Kurumsal eğitim** | Yalnız eğitimin ait olduğu **tek firmaya**. | | **Kurumsal kapalı — davet bazlı** | Yalnız **davet edilen firmalara** (grup şirketleri, kardeş şirketler). Davetli olmayan tenant için bu eğitim **var değildir**: listede görünmez, kodla veya doğrudan referansla erişimde "bulunamadı" döner. | | # | Gereksinim | |---|---| | V-1 | Görünürlük kümesi eğitim türünden türetilir; tür değişmeden görünürlük değişmez. | | V-2 | Davet listesi **firma listesidir**, kişi listesi değil. Davetli firmanın yetkili kullanıcıları eğitimi görür. | | V-3 | Davet listesinden çıkarılan firma, eğitimi bir sonraki erişimde göremez. Zaten kaydolmuş katılımcıları varsa bu bir çatışmadır: sistem sessizce veri gizlemez, işlemi yapan kullanıcıya durumu bildirir ve karar ister. | | V-4 | Görünürlük **kişisel veriyi kapsamaz**: davetli firmalar eğitimin varlığını ve doluluk **sayısını** görür, diğer firmaların katılımcı kimliklerini asla görmez (T-5). | | V-5 | Eğitimin varlığı ve doluluğu ticari bilgidir; görünürlük kümesi dışına sızması AD-19'daki "iş hacmi sızdırma" yasağıyla aynı sınıfta bir ihlaldir. | ## 5. Kimlik doğrulama ### 5.1 Yöntemler ve yönetim İlk günden dört yöntem desteklenir: **şifre**, **passkey**, **2FA**, **magic link** (AD-07). ⚠ **`passcode` → `passkey`** *(v1.14 — Sets, 27.07.2026)*. Dördüncü yöntem her belgede `passcode` diye anılıyor ve **hiçbirinde tanımlanmıyordu**; yalnız tasarım brief'i (`docs/design/tasarim-brief.md:57`) kelimeyi *"6 haneli kutulu OTP"* için kullanmıştı. O okuma 27.07.2026'da koda geçirildi — söylenmeden. Sets aynı gün kapattı: dördüncü yöntem **passkey**'dir (parmak izi / Face ID / donanım anahtarı, WebAuthn), ve **iletilen tek kullanımlık kod magic link'in zaten yaptığı iştir** — ikisini birden tutmak aynı fikri iki adla taşımak olurdu. ⚠ **Passkey ikinci faktör değil, birincil doğrulayıcıdır.** Kullanıcı doğrulaması içinde: biyometri *olduğun şey*, cihaz *sahip olduğun şey*. Şifrenin üstüne binmez, **yanında durur** — bu yüzden bu listede, §5.2'nin ikinci faktör kutusunda değil; ve backoffice'in MFA zorunluluğunu **tek başına** karşılar. **Ayarların ekseni kimlik alanıdır** (ofis / backoffice / müşteri). Hangi alanın hangi yöntemleri kullanabileceği **admin panelden ayarlanır**; **üç alan** bağımsız ayarlanır. Kodda sabit yöntem–alan eşlemesi olmaz (AD-08). - Bir kimlik alanı için birden fazla yöntem açık olabilir; kullanıcı açık olanlardan birini seçer. - Bunun üzerine **yetenek bazlı sertleşme kuralı** biner: bir yöntemin kullanılabilir olması, o yöntemle her ekrana erişilebileceği anlamına gelmez. **Matris** "kim hangi yöntemle giriş yapabilir"i belirler; **sertleşme kuralı** "hangi yöntem hangi yetkiyi açar"ı belirler (§5.3). Panel yetkisi gerektiren ekranlar güçlü doğrulama ister. - Yöntem kapatıldığında o yöntemle açılmış aktif oturumlar geçerliliğini korur, ancak yeni giriş yapılamaz. (Aksi davranış istenirse ayar olarak tanımlanır.) ### 5.2 Zorunlu MFA Finansal veya hukuki sonuç doğuran yetkilere sahip roller için **MFA zorunludur** ve admin bu zorunluluğu kaldıramaz: teklif onaylama, e-fatura işlemleri, kullanıcı yetkisi değiştirme, mali tablo görüntüleme. **Backoffice kimlik alanının tamamı için MFA zorunludur** (AD-23) — yetki bazlı değil, **alan bazlı**. ⚠ **Zorunlu olan ikinci faktörün KENDİSİdir, yöntemi değil** *(v1.13, v1.14'te düzeltildi — Sets, 27.07.2026)*. Kişi seçer: **2FA** (kimlik doğrulama uygulaması) ya da **passkey** (parmak izi / donanım anahtarı). İkisi de §5.1'in yöntemlerinden; birini dayatmak güvenlik kuralı kılığında bir tercih olurdu. Zorunluluğun kendisi ayarla kaldırılamaz — değişen yalnız hangi yöntemle karşılandığı. ⚠ **Kural OTURUMA sorulur, hesaba değil** *(v1.15 — Sets, 27.07.2026)*. Tek cümleyle: **ya e-posta girişi + ikinci faktör, ya passkey.** - **Passkey ile giriş** kendi başına yeter; ayrıca 2FA sorulmaz. Kullanıcı doğrulaması passkey'in içindedir. - **E-posta + şifre** (ya da magic link) ile giriliyorsa **2FA zorunludur**. - Yalnız passkey'i olan biri şifreyle girerse **2FA kurulum ekranına düşer**. Bu kuralın çalışması demektir: ikinci faktörün gerçekten eksik olduğu an tam olarak odur. Girişi reddetmek daha kötü olurdu — kaybolan cihaz kilitlenmiş hesap anlamına gelirdi. ⚠ **Bu bir düzeltmedir, süsleme değil.** Önceki kurgu "hesabın passkey'i var mı" diye soruyordu ve passkey'i olan biri şifreyle girdiğinde Filament ona **alanı olmayan bir doğrulama formu** gösterip butona basınca içeri alıyordu — passkey hiç kullanılmadan zorunluluğu karşılamış sayılıyordu. Yani **passkey kaydetmek, şifreyle girişi sessizce tek faktöre düşürüyordu**. ⚠ **Profil değişikliklerinde şifre yeniden sorulur** *(Sets, 27.07.2026)*. Passkey ile açılmış oturum çalışmak için yeterlidir; ama **hesabı açan yöntemleri** değiştirirken şifre istenir: e-posta değişimi, şifre değişimi, **passkey ekleme/silme**, **2FA kurma/kapatma**. Gerekçe: çalınmış bir oturumdan passkey eklemek, hesabı kalıcı olarak elde tutmanın sessiz yoludur — saldırgan kendi anahtarını bırakır ve şifre değişimi onu kaldırmaz. ⚠ **Şifre adımı AYRI BİR MODAL'dır, form alanı değil** *(v1.16 — Sets, 27.07.2026)*. Formun içine yerleştirilen şifre alanı formun parçası gibi okunur — doldurulacak bir şey daha — ve form dolduran kimse durup "bu niye soruluyor" diye sormaz. *"Şifrenizi doğrulayın"* diye açılan bir pencere ise bir **adımdır**. İşlemin kendi penceresi olduğu gibi kalır: 2FA kurulumu hâlâ QR gösterir ve kod ister, kapatma hâlâ kod ister — şifre adımı bunların **önüne** eklenir, içine değil. ⚠ **Kapı buton yokluğuyla kurulmaz.** Her Filament action'ı tarayıcıdan **adıyla** çağrılabilir; yalnızca butonu gizlenen bir işlem tek çağrı uzaktadır. Şifre adımı tek kullanımlık bir izinle çalışır: pencere izni yazar, arkasındaki işlem onu **tüketir**. ⚠ **Passkey HTTPS ister.** Tarayıcılar WebAuthn'u yalnız güvenli bağlamda (HTTPS ve `localhost`) açar; düz http üzerinde `PublicKeyCredential` tanımlı bile değildir. Kayıt ve giriş ekranları bunu kontrol eder ve sessizce başarısız olmak yerine söyler. ⚠ **Dördüncü yöntem spec'te ilk sürümden beri yazılıydı ve kodda yoktu.** `AuthMethod` üçünü taşıyordu; 27.07.2026'da passkey olarak eklendi. Gerekçe: bu alanın yetki tavanı yoktur (§3.3) — hem sistem çekirdeğini (mevzuat, evrak türü, global parametre; etkisi **tüm tenant'lara** yayılır) hem gerektiğinde müşteri iş verisini görür, üstelik ofis kimliklerini de burası doğurur. Ayar olarak kapatılamaz; kod kuralıdır. *(v1.11'de eklendi: kural AD-23'te vardı ve spec'te karşılığı yoktu, plan da spec'te bulunmayan bir kurala atıf yapar durumdaydı — heyet 141 F-2.)* ### 5.3 Magic link - Magic link **tek kullanımlıktır** ve süre sınırlıdır. Kullanıldıktan veya süresi dolduktan sonra aynı link ikinci kez oturum açamaz. - Magic link **yoklama veya katılım kanıtı olarak kullanılamaz** (AD-07). Link paylaşılabilir; kimin tıkladığı kanıtlanamaz. Katılım kanıtı imzalı yoklamadır. - **Magic link ile açılan her oturumda ek kimlik teyidi adımı zorunludur ve kapatılamaz** (ör. TCKN son dört hane). Gerekçe: link paylaşılabilir olduğu için tek başına kimlik kanıtı değildir; teyit adımı kapatılabilir olsaydı magic link paylaşan herkesin oturum açabildiği bir yönteme dönüşürdü. Teyit adımının **hangi bilgiyi sorduğu** admin tarafından seçilebilir, **varlığı** seçilemez. ⚠ **Ofiste teyit adımının yerini ikinci faktör alır** *(Sets, 28.07.2026 — ofis spec'i §5.4)*. Ofis `users` tablosu TCKN taşımaz, dolayısıyla `national_id_last_four` orada sorulamaz; adım **kaldırılmaz, daha güçlüsüyle değiştirilir**. İkinci faktörü kurulu olmayan kişi bir ara ekrana düşer (*"Devam etmek için passkey ya da iki adımlı doğrulama tanımlamalısınız"*) ve kurmadan devam edemez. Müşteri ve katılımcıda soru aynen `national_id_last_four`'dur. - Magic link'in ilettiği oturumun kapsamı dardır: yalnız kişinin kendi kayıtları ve ilgili eğitim. - **Magic link panel yetkisini AÇMAZ.** Panel yetkisi olan bir kişi magic link ile girdiğinde katılımcı ekranlarını görür; firma paneli ekranları kilitlidir ve şifre/2FA ile giriş istenir. Gerekçe: magic link paylaşılabilir bir bağlantıdır; paylaşıldığında teklif onaylama veya personel yönetme yetkisinin de devrolması kabul edilemez. **Yetki arttıkça kimlik doğrulama sertleşir.** ⚠ **Ofis istisnası** *(Sets, 28.07.2026 — ofis spec'i karar 7)*: ofis kimliğinde magic link **tek başına** hâlâ panel açmaz, ama üzerine **ikinci faktör kanıtlandıysa** oturum güçlüdür ve panel ekranları açılır. Gerekçe kuralın kendi gerekçesiyle aynı yerden gelir: paylaşılan bağlantının sahibi ikinci faktörü veremez. Müşteri ve katılımcı tarafında kural **aynen** geçerlidir. **Açık nokta (çatı netleştirme #6):** içerik paketi erişiminde tek cihaz/oturum kısıtı veya ikinci doğrulama uygulanıp uygulanmayacağı henüz kararlaştırılmadı. Bu spec magic link'in genel davranışını tanımlar; içerik paketi erişim seviyesi ilgili spec'te kararlaştırılacaktır. ### 5.4 Oturum ve hesap güvenliği | # | Gereksinim | |---|---| | A-1 | Başarısız giriş denemeleri hız sınırına tabidir; eşik ve kilit süresi admin-tanımlıdır. | | A-2 | Kullanıcı aktif oturumlarını görebilir ve tek tek sonlandırabilir. | | A-3 | Yeni cihaz/yeni konumdan giriş, kullanıcıya bildirim üretir. | | A-4 | Şifre değişimi, MFA açma/kapama, e-posta/telefon değişimi hassas işlemdir: audit'lenir ve kullanıcıya bildirilir. | | A-5 | Kullanıcı **silinmez, pasifleştirilir** (AD-23). Pasif kullanıcı giriş yapamaz; geçmiş kayıtlardaki eylem sahipliği değişmez. | | A-5a | **Pasifleştirme anında etki eder** *(Sets, 27.07.2026)*. Bir hesap donduruldu, bloklandı veya pasifleştirildi mi — **üç kimlik alanında da fark etmez** — o kişinin **bütün açık oturumları, hangi cihazda olursa olsun, o anda sonlandırılır** ve açık **anlık bağlantıları (realtime) kapatılır**. Kilitlendiği andan itibaren hiçbir şey yapamaz. ⚠ *"Bir sonraki istekte düşer"* **yeterli değildir**: kişi o sırada açık bir ekranda oturuyor ve anlık bağlantı üzerinden veri almaya devam ediyor olabilir; istek atmadığı sürece hiçbir kontrol çalışmaz. Sonlandırma, durumu değiştiren işlemin **kendisinin** sonucudur — arka planda kuyruğa alınmaz. | | A-6 | Oturum süresi ve hareketsizlik zaman aşımı **kimlik alanı bazında** ayarlanabilir (ofis / backoffice / müşteri). | ### 5.5 Kabul kriteri Her kimlik alanı için, admin panelde kapatılmış bir yöntemle giriş denemesinin reddedildiği; MFA zorunlu bir role MFA'sız erişimin engellendiği; magic link'in ikinci kullanımının reddedildiği ve magic link oturumunun panel ekranlarını açmadığı gösterilir — **ofiste: ikinci faktör kanıtlanmadan açmadığı, kanıtlandıktan sonra açtığı** (§5.3 ofis istisnası). ## 6. Yetkilendirme (omurga sınırı) Organizasyon modeli Spec 3'tedir. Omurga yalnız **zorlama garantisini** tanımlar: | # | Gereksinim | |---|---| | Y-1 | Hassas veriye dokunan her eylem yetki doğrular. "Zaten giriş yapmış" savunma değildir. | | Y-2 | Yetki kontrolü **merkezî ve atlanamaz** olmalıdır; her ekranda ayrı ayrı yazılan kontrollere dayanılamaz. | | Y-3 | Yetkisiz erişim denemesi audit'lenir. | | Y-4 | Bir kullanıcı **sahip olmadığı bir yetkiyi başkasına veremez**; yetki atama ayrı bir yetkidir. **Üç kimlik alanının hepsi için** geçerlidir. **Tek ve adlandırılmış istisna: backoffice provisioning'i** (AD-23) — backoffice'in kullanıcı yönetimi, kendisi ofis yetkisi taşımadan ofis yetkisi atar. Bu kalıcı bir muafiyettir (sistem ilk açıldığında yalnız backoffice kullanıcıları vardır ve yetki sonrasında da orada kalır), tehdit varsayımı AD-09'da yazılıdır. Başka istisna yoktur. | | Y-5 | Yetkisiz menü/aksiyon **hiç render edilmez** — gösterilip tıklanınca reddedilmez. Bu **üç kimlik alanının hepsi için** geçerlidir (§3.0.1). Menünün boş olması güvenlik değildir; asıl kapı policy'dir — yetkisiz sayfaya URL ile de erişilemez. | | Y-6 | Referans kodu bilmek erişim sağlamaz (§9). | ## 7. Denetim izi (audit) ### 7.1 Yazma olayları Kritik her işlem **değiştirilemez** biçimde kaydedilir: kim, ne zaman, hangi kayıt, önceki ve sonraki değer, gerekçe (varsa). - Kayıt **append-only**'dir; güncellenmez ve silinmez. - Audit kaydı **işlemle aynı bütünlük içinde** yazılır: audit yazılamıyorsa işlem de gerçekleşmez. Kuyruğa devredilip kaybolması kabul edilemez (AD-21). - Audit'e yazılan hassas değerler **maskelenir** (§8.3). Ham değer yalnız şifreli ana kayıtta durur — audit silinemez olduğu için içine ham kişisel veri yazmak KVKK silme hakkıyla çelişir (AD-16). - Periyodik olarak audit kayıtlarının bütünlük özeti **mühürlenir**: batch başına Merkle kökü, batch'leri birbirine bağlayan hash zinciri, ve zincir hash'inin **dış tanığa** yayımlanması (AD-06). Mühür kaydı değiştirilemez depoda da saklanır. Zincir *hiçbir kaydın yeniden yazılmadığını* gösterir; *ne zaman kurulduğunu* gösteren şey dış tanıktır. Kanıt **takdiri delil** sınıfındadır — 5070 anlamında nitelikli damga değildir (gerekçe ve hukuk teyidi: AD-06). - Zincir **bağımsız doğrulanabilir** olmak zorundadır: yaprak sırası, hash fonksiyonu ve katlama kuralı yazılıdır; üçüncü bir taraf bizden bir şey istemeden yeniden hesaplayabilir. Yalnız kendi kodumuzun doğrulayabildiği bir zincir delil sayılmaz. **Kapsam (asgari):** teklif oluşturma/gönderme/onay/red, tüm onay adımları ve atlanan onaycılar, masraf giriş/onay/red, kullanıcı oluşturma/pasifleştirme/yetki değişikliği, evrak yükleme/onay/red, eğitim durum geçişleri, bakanlık bildirim kaydı, sertifika kodu girişi, iptal ve revizyonlar, tanım/parametre/mevzuat kaydı değişiklikleri, kimlik doğrulama olayları. ### 7.2 Okuma olayları — erişim logu Hassas kayda dokunan **her okuma** loglanır (AD-21): evrak görüntüleme ve indirme, TCKN/SGK/IBAN gibi hassas alanların görüntülenmesi, özel nitelikli veri görüntüleme, teklif metni okuma, sertifika kodu görüntüleme. Kayıt: kim, ne zaman, hangi kayıt, hangi alan sınıfı, kaynak IP ve oturum. Erişim logu da damgalanır. **Yazım garantisi:** erişim logu, yazma audit'i ile **aynı sınıftadır** — erişim logu yazılamıyorsa hassas veri **görüntülenmez**. Gerekçe: erişim logunun varlık sebebi "bu veriye kim baktı" sorusunu kanıtlamaktır; log olmadan görüntülemeye izin vermek, kanıtı olmayan bir erişim üretir ve AD-21'in amacını boşa çıkarır. **Saklama:** erişim logu silinmez. Kullanım logunun saklama süresi (§7.3) erişim loguna **uygulanmaz** — o ayar yalnız kullanım logunun disk yükünü yönetmek içindir. ### 7.3 Kullanım logu Liste ve sayfa görüntülemeleri daha hafif bir sınıfta tutulur: kullanıcı, rota, uygulanan filtre, dönen kayıt sayısı. Damgalanmaz. - Bir listede 200 satır görüldüğünde 200 erişim kaydı değil, "şu filtreyle 200 kayıt görüntülendi" kaydı üretilir. - **Yazım garantisi düşüktür:** kullanım logu yazılamazsa sayfa görüntüleme **engellenmez**; kayıp kabul edilebilir. Bu log delil değil, ürün geliştirme ve kaba iz amaçlıdır. - **Saklama süresi admin-tanımlıdır; taban 2 yıldır.** Yönetim ekranında logun kapladığı alan görünür; yönetici saklama süresini seçer (2 yıl veya 5 yıl) ve seçilen süreden eski kayıtlar silinir. ### 7.4 Mevzuat kaynaklı asgari saklama Eğitim kayıtları için mevzuat asgari saklama süreleri getirir: IMDG kapsamında **en az 3 yıl** (Y-2016 md.13/f), genel deniz gözetim kapsamında **5 yıl** (DG-2020 md.14/4). Bu süreler audit saklamasından bağımsızdır ve altına inilemez. ### 7.5 Log görünürlüğü *(v1.8 — Sets, 26.07.2026)* **Aksiyon log değildir.** Müşterinin teklifi onaylaması, revize talep etmesi, mesaj göndermesi; katılımcının katılımı, notu, check-in'i — bunlar **iş verisidir** ve yetkisi olan herkes normal ekranlarda görür. Bu bölümdeki üç log sınıfı bunların üzerine yazılan **denetim katmanıdır**. İş akışı ekranları denetim kaydından beslenmez. | Sınıf | Ofis | Backoffice | Müşteri / katılımcı paneli | |---|---|---|---| | **Yazma olayları (§7.1)** | Yalnız **ofis personelinin** olayları, yetki ve sorumluluk kapsamında | Tamamı | Görünmez | | **Erişim logu (§7.2)** | Görünmez | Tamamı | Görünmez | | **Kullanım logu (§7.3)** | Görünmez | Yalnız agregat (§8.5 k-anonimlik kuralı) | Görünmez | - **L-1** — Müşteri kimliklerinin ve katılımcıların denetim izi ofis tarafında **hiçbir ekranda** görünmez: giriş geçmişi, hangi ekranı açtığı, neyi görüntülediği. Bu kısıt iş aksiyonlarını kapsamaz. - **L-1a** *(L-1'in tek istisnası — Sets, 26.07.2026)* — Müşteri kullanıcısının **son aktif zaman damgası** ofiste müşteri kartında görünür (AD-21). İstisna tek bir türetilmiş alanla sınırlıdır: damganın kendisi. Giriş geçmişi, oturum listesi, giriş sayısı veya geçirilen süre **gösterilmez**. Gerekçe operasyoneldir — *"paneli açmayan müşteri = churn sinyali"*; başka türetilmiş alan bu istisnaya eklenemez. - **L-1b** — Ofis personelinin **kimlik doğrulama olayları** (giriş/çıkış) ofis feed'inde görünür; §7.1'in kapsamındadırlar ve yöneticinin sorumluluk alanına girerler. Sistem bu olaylardan **süre, oturum uzunluğu, aktiflik skoru veya sıralama üretmez** (§8.5, CLAUDE.md kırmızı çizgi 17) — giriş olayı zaten kullanım süresini göstermez: sabah giriş yapıp gün boyu panele bakmayan kişi de aynı satırı üretir. - **L-2** — Ofis tarafında yazma olayı okuması aktör türüne göre kısıtlanır; kısıt sorgu katmanındadır, ekran filtresinde değil. - **L-3** — Kullanım logu hiçbir kullanıcıya **satır satır gösterilmez**; yalnız §8.5'in agregat çıktısı görünür. - **L-4** — Backoffice tüm tenant'ların denetim kaydını görür. Bu, **T-4'ün denetim kayıtlarına uygulanışıdır** (yeni bir yetki değil): ayrı bir izinle yetkilendirilir ve okumanın kendisi erişim logu üretir. Denetim dışı iş verisi **bu okuma yolundan** gelmez — o veri kendi yolundan ve kendi izniyle okunur; L-4 denetim ekranını tarif eder, backoffice'in yetki tavanını değil (§3.3). ### 7.6 Kabul kriteri Audit yazımı engellendiğinde işlemin de gerçekleşmediği; hassas bir alanın görüntülenmesinin erişim logu ürettiği; audit içeriğinde ham TCKN/IBAN bulunmadığı gösterilir. ## 8. Hassas veri ### 8.1 Şifreleme TCKN, kimlik bilgileri, SGK verileri, iletişim bilgileri ve banka bilgileri **saklanırken şifrelenir** (AD-05). Müşteri ve katılımcı verisinde **tenant bazlı anahtar** altyapısı ilk günden kurulur — sonradan eklemek en pahalı kalemdir. **Giriş kimliği e-postası da şifrelenir; aranması için tenant'tan bağımsız bir arama kolu vardır** *(Sets, 27.07.2026)*. Kimlik doğrulama, kaydı **hangi tenant'a ait olduğunu bilmeden** bulmak zorundadır; tenant anahtarlı bir hash orada tanımı gereği çalışamaz. Bu yüzden e-posta tenant anahtarıyla şifrelenir ve yanında **kök anahtarla** üretilmiş bir arama hash'i durur. ⚠ **Kabul edilmiş artık risk:** bu hash tenant'tan bağımsız olduğu için aynı adres her tenant'ta aynı değeri üretir; tabloyu okuyabilen biri bir adresin iki firmada kayıtlı olduğunu anlayabilir — I-1/I-2'nin kurmayı reddettiği bağ. Kabul edilme gerekçesi: alternatifi (adresi düz metin saklamak) **kesinlikle daha fazlasını** açığa çıkarır, ve **uygulama bu kolon üzerinden tenant'lar arası eşleme yapmaz** — tek meşru okuyucu §4.1'in bootstrap kapısıdır ve bu sınır taramayla denetlenir. ⚠ **Sözleşme — kök anahtarlı türetme duruma bağlıdır, kolaylığa değil.** Tenant'tan bağımsız anahtar yalnız *"kayıt, hangi tenant'a ait olduğu bilinmeden bulunmak zorunda"* durumunda meşrudur. **İkinci bir kök-anahtarlı amaç eklemek spec değişikliğidir**; "aramak kolay olsun" veya "tenant'lar arası rapor lazım" gerekçeleri bu duruma girmez. Kural bir kez delindi ve delindiği yer adlandırıldı — eşiğin düşmemesi buna bağlıdır. **Dosyalar da aynı güvenceye tabidir.** Sistemdeki en yoğun hassas veri taşıyıcıları yapılandırılmış alanlar değil, yüklenen belgelerdir: kimlik fotokopisi, SGK evrakı, diploma, imzalı yoklama taraması, masraf fişi. Alanı şifreleyip aynı verinin taramasını korumasız bırakmak bu bölümün güvencesini kâğıt üstünde bırakır. | # | Gereksinim | |---|---| | D-1 | Hassas belgeler **saklanırken şifrelenir**. | | D-2 | Belgeye erişim yalnız **süreli ve tekil** bağlantıyla verilir; kalıcı veya tahmin edilebilir genel adres bulunmaz. | | D-3 | Her belge erişimi yetki ve tenant kontrolünden geçer ve **erişim logu üretir** (§7.2). Bağlantıya sahip olmak erişim hakkı vermez. | | D-4 | Belgeler bütünlük özetiyle ve sürümlü saklanır; kritik belgeler silinmez, iptal/revizyonla yönetilir (AD-11). | ### 8.2 Özel nitelikli veri Adli sicil kaydı, sağlık raporu gibi KVKK m.6 kapsamındaki veriler ayrı muameleye tabidir: erişim rol bazında daraltılır, **her görüntüleme loglanır** ve saklama süresi tanımlıdır (AD-24). Bir evrak türünün özel nitelikli olup olmadığı tanım aşamasında işaretlenir (AD-24, Spec 2). ### 8.3 Maskeleme Hassas değerler ekranda ve loglarda varsayılan olarak maskelenir (ör. TCKN `482•••••316`). Tam değeri görmek ayrı bir yetkidir ve görüntüleme erişim logu üretir. ### 8.4 KVKK hakları | # | Gereksinim | |---|---| | K-1 | Katılımcı onboarding'inde aydınlatma ve açık rıza adımı vardır; rıza kaydı **metin sürümünü, metnin dilini**, zamanı ve kullanıcıyı saklar. Dil zorunludur: rıza belirli bir dilde okunan belirli bir metne verilir; rıza kayıtları silinemez olduğu için dil sonradan eklenemez. Eğitim kaydı görüntü/ses içeriyorsa rıza bu kapsamı açıkça belirtir (AD-13). | | K-2 | Prod dışı ortamlar maskelenmiş veriyle beslenir. | | K-3 | Kişisel veri üçüncü taraf analitik araçlarına gönderilmez. | **Veri saklama ve silme politikası — sistem kapsamı dışıdır.** Hangi verinin ne kadar saklanacağı ve bir silme talebi karşısında ne yapılacağı **3E'nin (Sets'in) hukuki sorumluluğundaki operasyonel bir karardır**, sistemin davranışı değildir. Bu spec bu konuda kural koymaz. Sistem açısından sonuç nettir: **otomatik veri silme veya otomatik anonimleştirme özelliği yoktur.** Süre dolduğunda kendiliğinden çalışan bir silme işi, saklama dayanağı sınıflandırması veya silme talebi iş akışı geliştirilmez. Kayıtlar saklanır; kritik kayıtlar zaten silinemez (AD-11) ve hassas değerler maskelenir (§8.3, AD-16). Bir veri sahibi başvurusu geldiğinde izlenecek yol operasyon tarafından belirlenir; gerekirse ileride ayrı bir iş kalemi olarak ele alınır. ### 8.5 Kullanım analitiği sınırı Ürün geliştirme amaçlı kullanım ölçümü **yalnız agregattır**: - Kırılım: müşteri tarafında tenant × rol × ekran; ofis tarafında rol/grup × ekran. - **Kişi kırılımı üretilmez. Toplam çevrimiçi süre, aktiflik skoru veya benzeri performans metriği üretilmez.** - Kişi bazında tutulan tek türetilmiş bilgi **"son aktif" zaman damgasıdır** (kullanıcı kartında görünür; amacı operasyoneldir). - **k-anonimlik: bir kırılım eşikten az kişi içeriyorsa rolü gizlenir**, görüntüleme sayısı kalır. ⛔ **Eşik admin-tanımlı bir ayardır** *(AD-21, 28.07.2026 revizyonu — `business.usage.minimum_people`, varsayılan 2, 1 yapılınca kapanır)*; bu satır önce *"en az 2 kişi"* sabit sayısını ve *"bir üst kırılıma yuvarlanır"* kuralını yazıyordu. Yuvarlama **uygulanmadı**: sistemde rol hiyerarşisi yok ve uydurmak, birinin sayılarını ait olmadığı başlığa koymak olurdu — satır **rolsüz kalana katlanır**, toplam korunur. ## 9. Referans kodları Destek ve iletişimde kullanılacak kayıtlara sistem otomatik, **rastgele** public referans kodu üretir (AD-19). | # | Gereksinim | |---|---| | R-1 | Format `PREFIX-YYYY-XXXX`; prefix **iki harf**, son blok rastgele dört karakter. Karışan karakterler (0/O/1/I/L) ve sesli harfler kullanılmaz. | | R-2 | **Ardışık numara yasaktır** — sıra numarası iş hacmini sızdırır; teklif ve eğitim adedi ticari bilgidir. | | R-3 | Kod atandıktan sonra **değişmez ve yeniden kullanılmaz**; iptal edilen kaydın kodu boşa çıkmaz. | | R-4 | Prefix'ler merkezî bir kayıtta tanımlanır; yeni kayıt tipi aynı mekanizmayla eklenir. Üç harfli prefix kullanılmaz. | | R-5 | **Kod yetki değildir.** Kodla erişim her zaman yetki ve tenant kontrolünden geçer. Kodun tahmin edilemezliği bir güvenlik varsayımı olarak kullanılmaz. | | R-6 | Bakanlık sertifika numarası ve KUMS eğitim kimliği **bizim ürettiğimiz kod değildir**; ayrı alanlardır ve bu kurallara tabi değildir. | ### 9.1 Kodla kayda ulaşma Kodun varlık sebebi destek ve iletişimdir: telefonda "TK-2026-M3PD" denince kayda ulaşılabilmelidir. | # | Gereksinim | |---|---| | R-7 | Her panelde, kullanıcının yetkisi dahilinde **koda göre arama** yapılabilir; tam kod girildiğinde ilgili kayda gidilir. | | R-8 | Arama sonucu **yalnız kullanıcının kapsamındaki kayıtları** döndürür. Kapsam dışı bir koda karşılık **"bulunamadı"** döner — kaydın var olduğu bilgisi bile verilmez (T-1 ile aynı davranış). | | R-9 | Koda göre arama **erişim logu üretmez**, ancak erişilen kayıt hassassa o kaydın görüntülenmesi §7.2 kapsamındadır. | | R-10 | Kod tüm panellerde kayıt detayında görünür ve tek hareketle kopyalanabilir. | ## 10. Bildirim altyapısı ### 10.1 Kanallar | Kanal | Kullanım | Sınır | |---|---|---| | E-posta | İşlem bildirimleri, hatırlatmalar, teklif yazışması, duyurular | Transactional ve promosyonel **ayrı akışlarda** gönderilir; karıştırılmaz (AD-17) | | SMS | Yalnız kimlik doğrulama ve kritik işlem doğrulaması | Promosyonel SMS gönderilmez (AD-18) | | Uygulama içi | Bildirim merkezi, okundu/okunmadı, kategori filtresi | — | | Anlık (realtime) | §11 | — | | Discord | 3E iç operasyon bildirimleri | Müşteriye gitmez | ### 10.2 Ticari ileti onayı (6563 / İYS) - **Promosyonel her gönderim, alıcının ticari ileti onayı kontrolünden geçer. Onaysız alıcıya promosyonel ileti gönderilemez — bu bir sert kapıdır, uyarı değildir.** - Onay ve ret kayıtları tarih, kaynak ve kanıtla saklanır. - **Alınan her onay ve her ret İYS'ye bildirilir** (AD-17). Yükümlülük iki bacaklıdır: içeride kapı, dışarıda kayıt. İYS'ye iletilmemiş bir onay, mevzuat karşısında eksiktir. - İYS bildirimi başarısız olursa gönderim yapılmaz ve iş yeniden denenir; kalıcı başarısızlık yöneticiye görünür bir uyarı üretir. - Alıcı ret bildirdiğinde (unsubscribe) ret **derhal** etkili olur ve İYS'ye bildirilir. - Hizmet/işlem bildirimleri (hatırlatma, teklif onayı, süre uyarısı) bu kapsamda değildir. ### 10.3 Teslim edilebilirlik - Geri dönen (bounce) ve şikayet bildirimleri işlenir; ilgili adres **otomatik olarak gönderim dışı listesine** alınır. - Gönderim dışı listesindeki adrese tekrar gönderim denenmez. - Bildirim şablonları **admin-tanımlı ve sürümlüdür**; hangi sürümün gönderildiği kayıtlıdır. ### 10.4 Kullanıcı tercihleri Kullanıcı bildirim tercihlerini yönetebilir. **İşlem ve mevzuat kaynaklı kritik bildirimler kapatılamaz** (süre dolumu, bakanlık bildirimi uyarısı, onay talebi). ### 10.5 Kademeli süre bildirimleri Geçerlilik süresi olan her kayıt için kademeli hatırlatma üretilir (90/60/45/30/15/7 gün). Kademeler admin-tanımlıdır. Bildirim hem ilgili tenant'a hem sorumlu ofis kullanıcısına gider ve satış fırsatı sinyaline dönüşür. ### 10.6 Gelen e-posta güvenliği Sisteme gelen e-posta **doğrulanmamış içeriktir**. Gönderen taklit edilebilir; gelen e-posta hiçbir iş aksiyonunu otomatik tetiklemez. Müşterinin e-postadaki "onaylıyorum" ifadesi onay değildir — onay yalnız panelden verilir (AD-14, AD-20). ## 11. Anlık bildirim (realtime) | # | Gereksinim | |---|---| | RT-1 | Kullanıcı, kendisini ilgilendiren olayı **sayfayı yenilemeden** öğrenir: teklif onaylandı, cevap geldi, onay kuyruğuna iş düştü, kontenjan teyidi gerekti. | | RT-2 | Anlık kanal **kullanıcıya özeldir**; başka kullanıcının olaylarını taşımaz. | | RT-3 | "Bu kayıt üzerinde başka bir kullanıcı çalışıyor" uyarısı verilebilir; **kimin çalıştığı ve hangi müşteri için çalıştığı gösterilmez**. Uyarı tavsiye niteliğindedir, hiçbir akışı bloklamaz ve kendiliğinden sönümlenir. | | RT-4 | Anlık bağlantı koparsa uygulama çalışmaya devam eder; bildirimler uygulama içi bildirim merkezinden görülebilir. Realtime bir kolaylıktır, veri bütünlüğünün koşulu değildir. | | RT-5 | Anlık kanaldan **hassas veri içeriği taşınmaz**; olay bildirimi taşınır, içerik yetkili sorguyla alınır. | | RT-6 | "Çevrimiçi" göstergesi yalnız direktör ve operasyon direktörüne görünür. Müşteri kullanıcılarında ve katılımcıda çevrimiçi göstergesi **yoktur**. | | RT-7 | **Geçerli oturum yoksa anlık kanaldan hiçbir veri çıkmaz** *(Sets, 27.07.2026)*. Kanal aboneliği ve bağlantının kimliklendirilmesi, HTTP tarafındaki **aynı** oturum ve kimlik alanı kontrolünden geçer; oturum yoksa, süresi dolmuşsa veya hesap pasifse abonelik reddedilir. ⚠ Anlık katman ayrı bir kimlik doğrulama yolu **açmaz**: kendi tokenı, kendi anahtarı, kendi "bağlantı zaten kurulmuştu" muafiyeti olmaz. Anlık bağlantı, HTTP oturumunun bir uzantısıdır; oturum düştüğünde bağlantı da düşer (A-5a). | ## 12. Fonksiyonel olmayan gereksinimler | Alan | Gereksinim | |---|---| | Dil | Arayüz **çok dillidir**. İlk sürümde `tr` (varsayılan) ve `en` hazır set olarak gelir. Kullanıcıya görünen hiçbir metin koda gömülmez. | | Dil çözümleme | kullanıcı tercihi → tenant varsayılanı → uygulama varsayılanı (`tr`). Eksik çeviri boş ekran üretmez; zincir yukarı düşer. | | Admin-tanımlı içerik | Çevrilebilir alanlar (bildirim şablonu, katalog adı, evrak türü adı, parametre açıklaması) dil bazında saklanır; yönetim panelinde eksik çeviriler raporlanır. Hangi alanın çevrilebilir olduğu alan bazında işaretlenir — her alan çevrilebilir değildir. | | Mevzuat metinleri | **Çevrilmez.** Resmî kaynak hangi dilde yayımladıysa o dilde kalır. Yanlış çevrilmiş bir mevzuat kuralı, çevirisi olmayandan daha risklidir. Gerekirse bağlayıcı olmadığı açıkça belirtilmiş bilgilendirme çevirisi eklenir. | | Aydınlatma ve rıza metinleri | Veri sahibinin dilinde sunulur. Bugün yalnız Türkçe içerik vardır; yapı ek dile hazırdır (bkz. K-1). | | Biçim ve saat dilimi | Tarih `GG.AA.YYYY`, saat 24 saat, para birimi binlik ayraçlı. **Saat dilimi ve biçimler tenant bazlıdır**, varsayılan `Europe/Istanbul`. Tenant'a bağlı olmayan kimlik alanları — **ofis ve backoffice** — uygulama varsayılanını kullanır. Kayıtlar her zaman UTC saklanır. | | Arama | Türkçe karakter duyarsız arama (aksan/büyük-küçük harf farkı sonucu değiştirmez). | | Erişilebilirlik | WCAG AA kontrast, dokunma hedefi ≥44px (mobil form 48px), görünür odak göstergesi, klavyeyle tam kullanım. | | Responsive | Her akış 375px genişlikte eksiksiz tamamlanabilir. Mobil ayrı ürün değildir. | | Performans | Liste ekranları sayfalanır; sayfa boyutu ve toplam kayıt sayısı görünür. Ağır raporlar kullanıcıyı bloklamaz. | | Dayanıklılık | Dış servis (mail, SMS, depolama, damgalama) erişilemezse iş akışı durmaz; işlem kaydedilir, gönderim yeniden denenir. **İstisna: audit yazımı başarısızsa işlem gerçekleşmez.** | | Zaman | Süre hesapları (geçerlilik, kademeli bildirim, iş günü) sistem saatine değil, tanımlı takvime dayanır; resmî tatil takvimi admin-tanımlıdır. | ## 13. Sınır durumları | Durum | Beklenen davranış | |---|---| | Tenant bağlamı belirlenemeyen istek | Veri döndürülmez; hata üretilir ve loglanır. | | Kullanıcı birden fazla tenant'a bağlı | Yeni kimlik modelinde **yapısal olarak oluşamaz**: ofis kimliği hiçbir tenant'a bağlanmaz, müşteri kimliği tanım gereği tam olarak bir tenant'ın içindedir (§3). | | Pasifleştirilmiş kullanıcının açık oturumu | Bir sonraki istekte sonlandırılır. | | Yetkisi kaldırılan kullanıcının açık ekranı | Bir sonraki eylemde reddedilir; ekranda kalması erişim sağlamaz. | | Aynı kayıt üzerinde eşzamanlı değişiklik | Sonraki yazan uyarılır; sessiz üzerine yazma olmaz. | | Sayaç niteliğindeki alanlarda eşzamanlılık | Sayım tek kaynaktan ve atomik yapılır; iki eşzamanlı işlem sınırı aşamaz. | | Bildirim gönderimi başarısız | İşlem geçerli kalır; gönderim yeniden denenir; kalıcı başarısızlık ilgili kullanıcıya görünür. | | Damgalama servisi erişilemez | Audit yazımı devam eder; damgalama kuyrukta bekler ve servis dönünce tamamlanır. | | Anlık bağlantı yok | Bildirimler bildirim merkezinden görülür (RT-4). | | Aynı e-postayla ikinci kullanıcı | **Her yerde engellenir** (v1.17, EGT-208): `customer_users` e-posta üzerinde sistem genelinde tektir; ekleme formu, düzeltme çekmecesi, Excel aktarımı, ofis «kişi ekle» kutusu ve profil adres değişikliği «bu e-posta adresi kayıtlı» der — **hangi firmada** olduğunu söylemez. Önceki kural (aynı tenant içinde engellenir, farklı tenant'larda serbest) giriş ekranında hangi firmanın kastedildiğini bilemiyordu; canlıda aynı kişi aynı şifreyle iki firmada olunca hiç giremedi. Ofis (`users`), backoffice (`backoffice_users`) ve müşteri (`customer_users`) **üç ayrı tablodur**; aynı e-postanın bu üçünde bulunması çakışma değildir. | | Aynı kişinin iki kimlik alanında kaydı var | Meşrudur ve **kayıtlar birbirine bağlanmaz** (I-5). Bir direktörün hem ofis hem backoffice kaydı olabilir; sistem ikisini eşleştirmez, ortak bir kimlik üretmez ve birinden diğerine yetki/oturum taşımaz. | | Katılımcıya panel yetkisi verildi | Mevcut kayda yetki eklenir; yeni hesap açılmaz, veri taşınmaz (U-4). Kişi bir sonraki girişinde firma paneli menülerini görür. | | Panel yetkili kişi magic link ile girdi | Varsa katılımcı ekranlarını görür (U-2); panel ekranları kilitlidir ve şifre/2FA ile giriş istenir (§5.3). | | Katılımcı firma değiştirdi | Yeni tenant'ta yeni kayıt açılır. Eski kayıt eski tenant'ta kalır; taşınmaz, gösterilmez, eşleştirilmez. Yenileme dayanağı yeni firmanın yüklediği sertifikadır. | | Davetli olmayan tenant, davet bazlı eğitimin koduna sahip | "Bulunamadı" döner (R-8, V-3). | | Erişim logu yazılamıyor | Hassas veri görüntülenmez (§7.2). | | Kullanım logu yazılamıyor | Sayfa görüntüleme engellenmez (§7.3). | ## 14. Kabul kriterleri Omurga, aşağıdakilerin tamamı gösterilebildiğinde tamamlanmış sayılır: 1. Tenant-kapsamlı her veri türü için çapraz erişim denemesi **veri döndürmez**; uygulama kapsamı devre dışı bırakıldığında da veri gelmez (iki katman bağımsız çalışıyor). 2. Tenant bağlamı transaction dışında yaşamaz; bağlam belirlenmeden tenant-kapsamlı sorgu çalışmaz. 3. Kimlik doğrulama yöntemleri **kimlik alanı bazında** admin panelden açılıp kapatılabilir; kapalı yöntemle giriş reddedilir. 4. MFA zorunlu roller MFA'sız erişemez. 5. Magic link tek kullanımlıktır ve katılım kanıtı olarak kabul edilmez. 6. Kritik işlemler audit üretir; audit yazılamıyorsa işlem gerçekleşmez; audit'te ham hassas veri bulunmaz. 7. Hassas kayıt görüntüleme erişim logu üretir. 8. ⛔ **Hiçbir log otomatik silinmez** *(Sets kararı, 07.08.2026 — v1.3'ün "saklama süresi backoffice'ten değiştirilebilir, taban 2 yıl" maddesinin yerine geçer)*. Yazma olayı, erişim logu ve **kullanım logu** dahil: saklama yükümlülüğü 10 yıla kadar uzanıyor ve hangi logun hangi yükümlülüğe cevap verdiği yıllar sonra sorulan bir soru — sistemin bir gece chunk düşürerek önden karar vereceği bir şey değil. ⚠ **Bilerek silmek başka:** `PurgeUsageLog` bir backoffice eylemidir, kişi neyin gideceğini kendisi söyler, izni vardır ve audit satırı bırakır. Fark DELETE değil, **karar veren biri olup olmadığıdır**. 9. Analitik ekranlarında kişi kırılımı yoktur; eşikten az kişi taşıyan kırılımın **rolü gizlenir**. Eşik admin-tanımlı ayardır (`business.usage.minimum_people`, varsayılan 2 — AD-21, 28.07.2026 revizyonu); **sabit sayı değildir** (kırmızı çizgi 9). 10. Referans kodları rastgeledir, tekrar etmez ve kod bilmek erişim sağlamaz. 11. ⏸ **Promosyonel gönderim yok** *(Sets, 07.08.2026 — §2 kapsam dışı)*; onay kapısının bekleyeceği bir gönderim de yok. ⚠ Maddenin ikinci yarısı **yürürlükte ve kanıtlı**: bounce/şikayet sonrası adres otomatik gönderim dışına alınır (`FeedbackWebhookTest`) — işlemsel posta da geri dönebilir. 12. Kritik bildirimler kullanıcı tarafından kapatılamaz. 13. Anlık bildirim çalışmadığında iş akışı bozulmaz. 14. Prod dışı ortamda kişisel veri maskelidir. 15. Aynı kişi iki tenant'ta kayıtlıysa kayıtlar birbirini görmez ve sistem bunları ilişkilendirmez; hiçbir ekranda "aynı kişi olabilir" ipucu üretilmez. 16. Davet bazlı eğitim, davetli olmayan tenant için listede görünmez ve kodla erişimde "bulunamadı" döner. ⚠ **Bu ayrı bir özellik değildir** *(Sets, 08.08.2026)*: "davet bazlı" §4.4'ün **kurumsal kapalı** görünürlük türüdür — planlama kapalıysa firmalar `training_customers` üzerinde adıyla seçilir, teklif onlara gider, onaydan sonra personel eklenir. Adı geçmeyen firma eğitimi ne listede görür ne kodla erişir; `TrainingPolicy` erişimi, `TrainingVisibilityTest` ve `VisibilityRuleTest` listeyi, `ReferenceCodeTest` kod aramasını kanıtlar. 17. Erişim logu yazılamadığında hassas veri görüntülenmez; kullanım logu yazılamadığında sayfa görüntüleme engellenmez. 18. Hassas belgeye yalnız süreli ve tekil bağlantıyla erişilir; erişim yetki kontrolünden geçer ve erişim logu üretir. 19. ⏸ **İYS bildirimi yok** *(Sets, 07.08.2026 — §2 kapsam dışı)*. Pazarlama bu sistem üzerinden yapılmıyor, dolayısıyla bildirilecek onay/ret de yok. Pazarlama gelirse madde bu haliyle geri döner. 20. Kullanıcı, kapsamı dışındaki bir referans koduyla arama yaptığında "bulunamadı" alır. 21. Panel yetkisi olmayan kişi firma paneline **URL ile de** erişemez (U-1). 22. Eğitim kaydı olmayan kişi katılımcı ekranlarını görmez (U-2). 23. Katılımcıya panel yetkisi verildiğinde yeni hesap açılmaz ve veri taşınmaz; kişi bir sonraki girişinde firma paneli menülerini görür (U-3, U-4). 24. Yetki verme ve kaldırma audit üretir ve kişiye bildirilir (U-5). 25. Panel yetkili kişi magic link oturumundayken panel ekranına eriştiğinde şifre/2FA isteniyor; katılımcı ekranları erişilebilir kalıyor (§5.3). **Ofiste ikinci faktör kanıtlandığında panel ekranı açılıyor** (§5.3 ofis istisnası). 26. Kimlik doğrulama bootstrap'i yalnız asgari alanları döndürüyor; aynı yoldan başka veri okunamıyor (§4.1 B-2, B-3). 27. Başarılı ve başarısız kimlik doğrulama denemeleri audit üretiyor (§4.1 B-5). 28. Eksik çeviri boş ekran üretmiyor; fallback zinciri kullanıcı → tenant → uygulama varsayılanı sırasıyla çalışıyor (§12). 29. Rıza kaydı metin sürümü **ve dili** olmadan oluşturulamıyor (K-1). 30. Tenant'ın saat dilimi ayarı tarih gösterimlerine uygulanıyor; kayıtlar UTC saklanıyor (§12). *(31–37: v1.11 — üçüncü kimlik alanı. Emsal: v1.5'in davranışları için kriter 21–30 aynı disiplinle eklenmişti.)* 31. **Üç kimlik alanı hiçbir tablo paylaşmıyor** — kimlik, oturum, auth ayarı **ve izin tabloları** ayrı; şema kontrolüyle kanıt (§3). 32. **Y-4 ve Y-5 üç alanda da zorlanıyor**: sahip olunmayan yetki verilemiyor (tek istisna backoffice provisioning'i) ve yetkisiz menü/rota üç alanda da kapalı (§6). 33. **Backoffice'in tenant verisine her dokunuşu log üretiyor** — süper admin dahil, istisnasız: okuma **erişim logu** (§7.2), yazma **§7.1 audit'i** (aynı transaction). Her iki yolda da log yazımı engellendiğinde dokunuş da gerçekleşmiyor (§3.3 tablosu, G-4). ⚠ Kriter dokunuşun **loglandığını** kanıtlar, **engellendiğini** değil: backoffice'in yetki tavanı yoktur. 34. **Backoffice'in denetim kaydı okuması ayrı izinle yetkilendiriliyor** ve okumanın kendisi erişim logu üretiyor; denetim dışı iş verisi **bu okuma yolundan** gelmiyor (T-4, §7.5 L-4). 35. **Backoffice alanında MFA zorunlu** ve ayarla kapatılamıyor; MFA'sız backoffice kullanıcısı giriş yapamıyor (§5.2, AD-23). 36. **İki kimlik alanındaki kayıtlar ilişkilendirilmiyor** (I-5): aynı e-postayla ofis ve backoffice kaydı bir arada bulunabiliyor, sistem ikisini eşleştirmiyor ve birinden diğerine yetki/oturum taşımıyor (test). 37. **Backoffice panelinde mali tablo, müşteri tablosu veya eğitim operasyonu ekranı kayıtlı değil** — panel kayıtlarının taranmasıyla (§3.4). ⚠ Bu bir **kapsam** kriteridir; yetki kriteri değildir ve tercih değişirse kriter de değişir. 38. **Pasifleştirilen hesabın açık oturumları anında düşüyor** (A-5a): üç kimlik alanının her birinde, iki farklı cihazda açık oturumu olan bir kullanıcı pasifleştirildiğinde her iki oturum da o anda geçersiz oluyor ve kişi hiçbir ekrana erişemiyor; anlık bağlantısı da kapanıyor (test). ## 15. Açık noktalar | # | Konu | Etki | |---|---|---| | 1 | Magic link ile içerik paketi erişiminde ek doğrulama seviyesi (çatı netleştirme #6) | İçerik paketi spec'i | | 2 | Tenant bazlı şifreleme anahtarlarının yönetim biçimi (dış anahtar servisi mi, türetilmiş anahtar mı) | Plan aşamasında kararlaştırılacak; spec yalnız "tenant bazlı anahtar altyapısı gün bir" gereksinimini koyar | | 3 | Oturum süresi ve hareketsizlik zaman aşımı varsayılan değerleri | Operasyon teyidi | | 4 | Başarısız giriş eşiği ve kilit süresi varsayılanları | Operasyon teyidi | | 5 | ~~Resmî tatil takvimi kaynağı~~ | ⛔ **Kapandı, yapılmayacak** *(Sets, 18.08.2026, EGT-43 Won't fix)*: resmî böyle bir liste yok ve sektör 7/24/365 çalışıyor. Bütün süreler **takvim günü** sayılır | --- ## Revizyon geçmişi **1.1 — 25.07.2026.** Heyet spec review'ı (`docs/reviews/review-omurga-spec-2026-07-25.md`, 12 bulgu) üzerine revize edildi: | Bulgu | Yapılan | |---|---| | F-1 | §4.4 eklendi: görünürlük kümesi eğitim türünden türer (açık / kurumsal / davet bazlı kapalı). T-5 buna göre yeniden yazıldı. | | F-2, F-3 | §8.4 yeniden yazıldı. *(v1.3'te tamamen kaldırıldı — aşağıya bakınız.)* | | F-4 | §7.2 ve §7.3'e yazım garantisi seviyeleri eklendi (erişim logu sert, aktivite logu gevşek). | | F-5 | §7.2'ye saklama süresi eklendi: mevzuat süresinden kısa olamaz, en az 10 yıl. | | F-6 | §3.2 eklendi: kimlik tenant sınırını aşmaz; çapraz tenant eşleme yasak; firma değişiminde kişi yeni kayıttır; yenileme dayanağı yeni firmanın yüklediği sertifikadır. | | F-7 | §3.1 eklendi: tenant'ın hukuki türü (tüzel/gerçek kişi). "Bağımsız katılımcı" ayrı aktör türü değil, gerçek kişi firma tenant'ıdır. | | F-8 | §8.1'e D-1…D-4 eklendi: hassas dosyalar şifrelenir, süreli tekil bağlantı, erişim logu, sürümlü saklama. | | F-9 | §10.2'ye İYS bildirimi eklendi; başarısızlıkta gönderim yapılmaz. | | F-10 | §9.1 eklendi: koda göre arama, kapsam dışı kodda "bulunamadı". | | F-11 | §5.3 çelişkisi giderildi: teyit adımının **varlığı** zorunlu ve kapatılamaz, yalnız **hangi bilgiyi sorduğu** seçilebilir. | | Dil notu | §7.3 retention ifadesi netleştirildi. | Kabul kriterlerine 15-21 eklendi; §13 sınır durumları tablosu altı yeni satırla genişletildi. **1.2 — 25.07.2026.** Re-review (`docs/reviews/review-omurga-spec-2026-07-25-r2.md`) 12 bulgunun 12'sini kapalı buldu, revizyonun ürettiği 2 yeni bulgu için: | Bulgu | Yapılan | |---|---| | N-1 | §8.4'e K-6…K-9 eklendi: saklama dayanağı tanım aşamasında belirlenir (Spec 2); dayanağı tanımlı sınıf K-2, tanımsız sınıf K-5 kapsamındadır (varsayılan kişisel veri lehine); mali kayıt/fatura, teklif yazışması ve rıza kayıtları açıkça sınıflandırılacak; saklama süresi makine-okunur olmalı. K-4'e silinemez kayıt istisnası eklendi: bu sınıfta yalnız anonimleştirme uygulanır. | | N-2 | §13 "aynı e-posta" satırı tür istisnasıyla düzeltildi: aynı tenant'ta **aynı kullanıcı türünde** engellenir, **farklı türlerde** aynı e-posta bulunabilir. §3.1'e çift bağlamlı hesabın neden tercih edilmediği yazıldı. | | Açık soru 2 | §15'e madde 7 eklendi: KVKK hukuki rol ayrımı (veri sorumlusu / veri işleyen) hiçbir dokümanda yazılı değil; hukuk teyidine bağlandı. | **1.3 / 1.4 — 25.07.2026 (Sets kararı).** Veri saklama/silme politikası spec'ten **tamamen çıkarıldı**. Gerekçe: hangi verinin ne kadar saklanacağı ve silme talebi karşısında ne yapılacağı 3E'nin hukuki sorumluluğundaki operasyonel bir karardır — sistem davranışı değildir. **Sistemde otomatik veri silme veya anonimleştirme özelliği olmayacak**, dolayısıyla bu konuda yazılacak kod da yok. v1.1 ve v1.2'de bu başlık altında üretilen gereksinimler (K-2…K-9: talep reddi akışı, saklama dayanağı sınıflandırması, süre sonu otomatik işlem, silinemez kayıt istisnası) geçersizdir ve kaldırılmıştır. Kaldırılanlar: §8.4'teki silme/saklama kuralları · §8.2'deki "süre dolduğunda silinir/anonimleştirilir" ifadesi (AD-24 yalnız "saklama süresi tanımlıdır" der; silme ifadesi spec'in kendi eklemesiydi) · §13'teki "saklama süresi dolmamış kayda silme talebi" satırı · kabul kriteri 19 · §15'teki hukuk teyidi maddeleri (erişim logu süre tabanı, KVKK rol ayrımı) · §7.2'deki "en az 10 yıl" hükmü. Korunanlar: rıza kaydı (K-1), prod dışı maskeleme (K-2), üçüncü taraf analitiğe veri gitmemesi (K-3), maskeleme (§8.3), kritik kayıtların silinemezliği (AD-11), kullanım logu saklama ayarı (§7.3 — bu bir disk yönetimi ayarıdır, kişisel veri politikası değil). **1.5 — 25.07.2026 (Sets kararı, plan review sonrası upstream düzeltme).** Kimlik modeli yeniden yapılandırıldı. Tetikleyen: omurga plan review'ında ofis kullanıcısının çok-tenant erişimi (P-1) ve auth-öncesi bağlam bootstrap'i (P-2) majör bulgu çıktı; kök sebep tek `users` tablosunda dört kullanıcı türünü birden taşımaktı. | Değişiklik | Gerekçe | |---|---| | §3 yeniden yazıldı: dört kullanıcı türü → **iki bağımsız kimlik alanı** (ofis `users` · müşteri `customers` + `customer_users`) | Ofis ve müşteri iki bağımsız organizasyondur; yetki tablolarını paylaşmamalıdırlar | | §3.0 eklendi: müşteri tarafında **tek kimlik, katmanlı yetenek** (U-1…U-5) | "Panel kullanıcısı" ve "katılımcı" ayrı hesap değil, aynı kişinin iki yeteneği. Hesap transferi ihtiyacı ortadan kalktı | | §3.0.1 eklendi: ofis tarafında da erişim yetkiden türer | | | §3.1 sadeleşti | Bağımsız katılımcı artık ek yapı gerektirmiyor | | §3.2 yeni tablo adlarına uyarlandı | | | §5.1, §5.3: **magic link panel yetkisini açmaz** | Magic link paylaşılabilir; yetki arttıkça doğrulama sertleşir | | §13 "aynı e-posta" satırı yeniden yazıldı; iki yeni sınır durumu | Kişi başına tek kayıt olduğu için eski istisna gereksizleşti | | §12 çok dillilik | `tr`+`en` hazır set, fallback zinciri, çevrilebilir admin içeriği, mevzuat çevrilmez, **saat dilimi ve biçimler tenant bazlı** | | K-1: rıza kaydı **dili de** saklar | Rıza belirli bir dildeki metne verilir; kayıt silinemez olduğu için sonradan eklenemez | | Y-5 genişletildi | Menü gizleme güvenlik değildir; URL erişimi de policy ile kapalı | **1.6 — 25.07.2026.** v1.5 re-review'unun (`review-omurga-spec-2026-07-25-r6.md`) dört bulgusu kapatıldı: | Bulgu | Yapılan | |---|---| | B-1 (müşteri auth bootstrap tanımsız) | §4.1'e **tek istisna** bölümü eklendi (B-1…B-6): kimlik doğrulama bağlamsız yürütülebilen tek işlemdir, yalnız asgari alanlara erişir, tek denetlenebilir kapıdan geçer, tabloya genel muafiyet tanımlanmaz, doğrulama sonrası normal kural işler, her deneme audit'lenir. Magic link istisnaya ihtiyaç duymaz. | | B-2 (yeni davranışların kriteri yok) | §14'e **21-30 arası on kriter** eklendi: U-1…U-5, magic link panel kilidi, bootstrap asgari alan sınırı, auth denemesi audit'i, dil fallback, rıza dili, tenant saat dilimi. | | B-3 ("kullanıcı türü" ekseni askıda) | §5.1 yeniden yazıldı: ayarların ekseni **kimlik alanı**; üzerine **yetenek bazlı sertleşme kuralı** bindi (matris = kim hangi yöntemle girer · sertleşme = hangi yöntem hangi yetkiyi açar). §5.5 kabul kriteri ve §14/3 de kimlik alanı diline çevrildi. A-6 kimlik alanı bazına alındı. | | B-4 (§13'te eski model kalıntısı) | "Birden fazla tenant'a bağlı kullanıcı" satırı yeniden yazıldı: yeni modelde yapısal olarak oluşamaz. | | Notlar | §13 magic link satırına "varsa" eklendi; ofis kimliğinin saat dilimi kaynağı yazıldı. | **1.7 — 25.07.2026.** v1.6'nın re-review'u (`review-omurga-spec-2026-07-25-r7.md`) B-1 ve B-4'ü kapalı buldu; B-2 ve B-3'ün **metin gövdesinin dosyaya hiç işlenmediğini** tespit etti (R7-1…R7-3) — revizyon geçmişi yapılmamış değişiklikleri yapılmış olarak kaydediyordu. Kök sebep: toplu metin değiştirme adımı eşleşmeyi doğrulamadan çalıştırıldı, iki değişiklik sessizce atlandı. Bu sürümde B-2 ve B-3 **gerçekten** işlendi ve dosya üzerinde doğrulandı: §5.1 yeniden yazıldı (kimlik alanı ekseni + yetenek bazlı sertleşme kuralı), §5.5 ve §14/3 kimlik alanı diline çevrildi, §14'e 21-30 arası on kriter eklendi. 1.6 tablosundaki iki satır gerçek duruma göre düzeltildi. **1.8 — 26.07.2026 (Sets kararı, upstream terim ve görünürlük düzeltmesi).** Ofis/backoffice ayrımı AD-09'da eksiksiz tanımlanınca log tarafında iki eksik ortaya çıktı. | Değişiklik | Gerekçe | |---|---| | §7.3 **"aktivite logu" → "kullanım logu"** (semantik aynı) | "Aktivite" kelimesi iş olaylarını (*yeni teklif oluşturdu, revize gönderdi*) anlatmak için kullanılıyor. Aynı kelimenin sayfa görüntüleme telemetrisini de adlandırması, arayüzde "aktivite" yazan ekranın yanlış tablodan beslenmesine yol açardı. | | §7.5 **Log görünürlüğü** eklendi (L-1…L-4) | Hangi log sınıfının hangi panelde göründüğü spec'te tanımsızdı; plan bunu tenant üzerinden çözüyordu, oysa kural **aktör türü** üzerinden işliyor. Müşteri kimliklerinin denetim izi ofiste görünmez; backoffice çapraz-tenant okuması tek yoldan geçer ve kendisi audit'lenir. | | §7.5'e "aksiyon log değildir" ayrımı | Müşterinin onayı/revize talebi/yazışması iş verisidir, denetim kaydı değil. İş akışı ekranlarının audit tablosundan beslenmesi, denetim katmanının kurallarını arayüze sızdırır. | | Eski §7.5 (kabul kriteri) → **§7.6** | Numara kayması; dışarıdan referans yoktu. | **1.9 — 26.07.2026.** v1.8'in heyet turu (`review-egt50-ofis-backoffice-2026-07-26.md`, REJECTED — 10 bulgu) spec katmanında üç bulgu üretti; üçü de kapatıldı: | Bulgu | Yapılan | |---|---| | **F-1** — v1.8'in terim değişikliği spec'in kendi içinde eksik işlenmişti | §13 sınır durumu ve §14 kriter 8 hâlâ "Aktivite logu" diyordu. v1.8'in okumasıyla kriter 8, **silinmez** olan `audit_writes`'ın saklama süresinin ayarlanabildiğini iddia eder hale gelmişti — v1.8'in kendi uyardığı hata, v1.8'in kendi kabul kriterinde. İkisi de "kullanım logu"na çevrildi; kriter 8'e yönetim ekranının **backoffice** olduğu ve diğer iki sınıfın bu ayardan etkilenmediği yazıldı. | | **F-5** — "tek istisna" iddiası belge setinde tek değildi | §4.1 (auth bootstrap), §7.5 L-4 (backoffice okuma) ve chunk9 S-9 (`SECURITY DEFINER`) aynı sözü farklı eksenlerde veriyordu; ayrıca **T-4 sistem yöneticisine genel çapraz-tenant erişim** tanıyor ve L-4 ile yarışıyordu. L-4 yeniden yazıldı: **yeni bir yetki değil, T-4'ün denetim kayıtlarına uygulanışı**; kapsam tek yoldan genişletilir, denetim dışı iş verisi bu yoldan okunmaz. | | **T-4 belirsizliği** (F-5'in ikinci yarısı) | T-4'e sınır cümlesi eklendi: sistem yöneticisinin çapraz-tenant erişimi **iş yürütme yetkisi değildir** (backoffice ofis kapsamı taşımaz — AD-09), denetim ve destek amaçlıdır; denetim kayıtlarındaki uygulanışı §7.5 L-4'tür. | Heyetin diğer iki bulgusu **Sets kararıyla** kapatıldı ve §7.5'e işlendi: | Bulgu | Karar | |---|---| | **F-2** — AD-21'in "son aktif" hükmü ile L-1 aynı veriyi iki yöne çekiyordu | **L-1a:** müşteri kullanıcısının son aktif damgası ofiste görünür; istisna **tek bir türetilmiş alanla** sınırlı. Giriş geçmişi, oturum listesi, giriş sayısı ve geçirilen süre gösterilmez; istisnaya başka alan eklemek spec değişikliğidir. | | **F-3** — kimlik doğrulama olaylarının ofis feed'indeki durumu | **L-1b:** giriş/çıkış ofis feed'inde kalır. Heyetin "çevrimiçi süre elle çıkarılabilir" gerekçesi kabul edilmedi — giriş olayı kullanım süresini göstermez; sabah giriş yapıp gün boyu panele bakmayan kişi de aynı satırı üretir. Kırmızı çizgi 17'nin koruması **üretim tarafında** durur: sistem süre/skor/sıralama üretmez (§8.5, chunk9 S-2). | **1.9.1 — 26.07.2026 (heyet review 131).** r2 turu spec katmanında tek bulgu üretti ve kapatıldı: | Bulgu | Yapılan | |---|---| | **R2-1** — v1.9'da AD-23 kural 1 "ofis içinde" olarak kapsanmış ve backoffice provisioning'i adlandırılmış istisna olarak taşımıştı; ancak spec §6 **Y-4** niteliksiz kalmıştı ve aynı işlemi yasaklamaya devam ediyordu | Y-4'e istisna işlendi: kural her iki kimlik alanı için geçerlidir, **tek ve adlandırılmış istisnası backoffice provisioning'idir** (AD-23), kalıcıdır ve tehdit varsayımı AD-09'dadır. Böylece F-9'un AD katmanından spec katmanına taşınan yarısı da kapandı. | **1.9.1 düzeltmesi — 26.07.2026 (heyet review 132).** r3 turu spec katmanında yalnız sürüm başlığı düzeltmesi üretti (R3-6: başlık "1.9" derken revizyon geçmişi 1.9.1 diyordu). İçerik değişmedi; R2-1'in Y-4 düzeltmesi r3'te kapalı bulundu. **1.10 — 26.07.2026 (AD-06 yeniden yazımı — Sets kararı; heyet 135 F-8).** §7.1'in delil maddesi içerik olarak değişti ve sürüm damgası bir tur boyunca güncellenmedi; "spec v1.9.1" pini iki farklı içeriği işaret eder hale gelmişti. Planın kendi R4-1 kuralı ("sürüm damgası ile revizyon girdisi tek adımda atılır") burada spec'e de uygulandı. | Değişen | Yapılan | |---|---| | §7.1 delil dayanağı | **Nitelikli zaman damgası (KamuSM/ESHS) kaldırıldı.** Yerine: batch başına Merkle kökü + batch'leri bağlayan hash zinciri, her halka **oluşturulduğu anda** public bir dış tanığa yayımlanır. Bağımsız doğrulanabilirlik şartı yazıldı (yaprak kuralı, hash fonksiyonu, katlama kuralı yayımlanır). | | §7.1 delil sınıfı | **Takdiri delil** olduğu açıkça yazıldı — 5070'in güvenli elektronik imzaya tanıdığı statü BTK'ya kayıtlı bir ESHS'den gelir ve bu zincir onu taşımaz. İtiraz halinde ispat yükü bizdedir; **hukuk teyidi açık kalem** (`docs/issues.md`). | | Gerekçe | Sets kararı: ücretli/yüksek maliyetli yapı kullanılmayacak, KamuSM gibi bir entegrasyon olmayacak. Mevzuat ileride nitelikli damga zorunlu kılarsa dönüş mümkündür — sabitlenen şey zaten mevcut zincir hash'idir, veri modeli buna hazırdır. | **1.11 — 26.07.2026 (Sets kararı — üçüncü kimlik alanı).** §3 "İki bağımsız kimlik alanı" → **"Üç bağımsız kimlik alanı"**. Backoffice, ofis kimliği üzerindeki `system.access_backoffice` izni olmaktan çıkıp kendi tablo ailesine (`backoffice_users` + oturum + auth ayarı + izin ailesi) taşındı. | Değişen | Yapılan | |---|---| | §3 kimlik tablosu | Üçüncü satır eklendi: **Backoffice** — sistem çekirdeğini yönetenler, `backoffice_users`, tenant'a ait değil ve **yetki tavanı yok** | | §3 gerekçe | Ayrımın gerekçesi güvenlik değil **karmaşıklığın adresi**: ofis çok net bir yapıdır ve öyle kalmalıdır; backoffice ihtiyaca göre şekillenecek karmaşık yetki yapıları gerektirecektir. Destek görevlisi ofis paneline hiç girmeyecek ama ticket bazında müşteri verisinin bir kısmına erişecek — bunu `users` üzerinde **istisna** olarak taşımak ofisin standardını bozar | | **§3.3 (yeni)** | **Backoffice'in yetki tavanı** yazıldı: tavan yoktur — ofis kimliklerini doğurur, gerektiğinde müşteri ve eğitim verisine erişir. Karşılığı kısıt değil **denetimdir** (her dokunuş loglanır). **§3.3.1** dar yetkili backoffice rollerinin (destek) kapılı erişim biçimini tarif eder: gerekçeye bağlı · kapsamlı · süreli · sert loglanmış — süper admin için tavan değildir | | **§3.4 (yeni)** | **Bugünkü kapsam tercihi**: backoffice paneline yalnız çekirdek parametreleri konur; mali tablo, müşteri tablosu ve eğitim operasyonu ofisin işidir ve ofis panelinden yapılır. Bu bir **tercihtir**, yetki sınırı değil; değiştirmek ekran kararıdır | | §6 Y-4, Y-5 | "her iki kimlik alanı" → **üç kimlik alanının hepsi** | **v1.11 içi düzeltmeler (heyet 141, aynı sürüm içinde):** F-1 üçüncü alan §5.1/A-6/§12/§13'e işlendi · F-2 backoffice MFA §5.2'ye girdi (AD-23 zaten zorunlu kılıyordu) · F-4 kapı şartları `B-` → `G-` (çakışma §4.1 ile) ve yanlış L-3 atfı düzeltildi · F-5 AD-09'un eski "kapıdır" paragrafı · F-6 bağlamama kuralı spec'e taşındı (**I-5**) · F-7 kabul kriterleri **31–37**. §3.2.1 → **§3.3**. **F-3'ün ilk düzeltmesi geri alındı (Sets, 26.07.2026 — ikinci tur).** Heyet 141 F-3, T-4 ile §3.3 arasındaki çelişkiyi doğru tespit etmişti; **çözüm yanlış yöne uygulandı**: T-4 "yalnız denetim kayıtları" diye daraltıldı, yani **yapabilirlik** kısıtlandı. Sets'in düzeltmesi: *"backoffice her şeyi yapabilir, müşteri verisine de erişebilir gerektiğinde, eğitim verilerine erişip eğitim de oluşturabilir gerektiğinde; biz bunu **şu anda tercih etmiyoruz**."* Çelişki bu kez doğru yönden kapatıldı — **yetki tavanı (§3.3) ile kapsam tercihi (§3.4) ayrı iki başlık oldu**; T-4 geniş hâline döndü ve karşılığına kısıt değil **log** kondu. Not: AD-09'un "mali sınır" paragrafı bu ayrımı zaten doğru yazıyordu (*"backoffice'in yapabilirliği geniştir; kapsamı bilinçli olarak dardır"*) — spec ona uymamıştı. Karışıklık üçüncü kez çıktığı için AD-09'a ve heyet kontrol listesine kesin dille sabitlendi. **Re-review kapanışı (heyet 142 — APPROVED, iki minör bulgu yeni tur gerektirmeden kapatıldı):** **R2-1** — §3.3.1'e sözleşme cümlesi geri kondu, bu kez rolün **adına** değil *"süper admin değil ama müşteri verisine erişiyor"* **durumuna** bağlı; "bu yeni rol destek değil" gerekçesiyle aşınmaya kapalı. **R2-2** — §3.3'e log **sınıfı** tablosu: okuma → erişim logu (§7.2), yazma → §7.1 audit'i (aynı transaction); backoffice'in tenant kaydı yazması her ikisini de tetikler. Kriter 33 buna göre yeniden yazıldı. Ayrıca §3'ün alt bölüm sırası düzeltildi (3.3/3.4 fiziksel olarak 3.0'dan önce duruyordu). **Downstream etkisi:** AD-09 güncellendi (yetki tavanı + kapsam tercihi ayrımı, kapılı erişim rol tanımına indi, tehdit varsayımı yalnız süper admin rolüne daraldı); `docs/claude/heyet.md` kontrol kuralı 5 eklendi; chunk2 §2.8 bağlamsız tablo listesine üç backoffice tablosu eklendi; chunk5 §5.1 üç tablo ailesine çıkarıldı ve kapılı-erişim notu düzeltildi; chunk8 bildirim kanalı ailesi notu düzeltildi. --- **1.12 — 27.07.2026 (Sets — hesap açma, davet ve kullanıcı yönetiminin yeri).** İki noktada spec'in metni okuyanı yanlış yere götürüyordu; ikisi de kural değişikliği değil, **yanlış anlaşılmanın kapatılması**. | Değişen | Yapılan | |---|---| | **§3.3, birinci madde** | *"Ofis kimliklerini burası doğurur ve yönetir"* cümlesi, kullanıcı yönetiminin yalnız backoffice'te olduğu gibi okunuyordu ve plan ile kod bu okumayı devralmıştı. Düzeltildi: backoffice **ilk** ofis kimliğini doğurur (sistem açıldığında ofiste kimse yoktur) ve sonrasında da elini çekmez; ama **kullanıcı yönetimi her iki tarafta da vardır** — operasyon direktörü ekleme yetkisi verilmişse ofis personeli, satış direktörü verilmişse satışçı ekler. Ayrım **tavandadır**: backoffice kendi taşımadığı ofis yetkisini atayabilir (Y-4'ün adlandırılmış istisnası), ofis tarafında aynı iş Y-4'e tabidir. | | **§3.0.2 (yeni)** | Hesabın **ne olarak** açıldığı ve davet akışı yazıldı (P-1…P-5): eğitim personeli ↔ ofis/panel personeli statüsü, *"yetki bekliyor"* uyarısının statüye dayanması (izin boşluğuna değil — katılımcı da izinsizdir), iki statünün birbirini dışlamaması, kritik bilgilerin **hesap açılırken** verilmesi ve davet edilenin yalnız **şifresini** belirlemesi, davet bağlantısının tek kullanımlık/süreli olması ve tenant sızdırmaması, son yetkilinin kaldırılmasının **engellenmemesi** — yalnız uyarı. | **Reddedilen öneriler (kayda geçsin diye):** *(a)* "yetkileri hiç gözden geçirilmedi" bayrağı — gereksiz; statü zaten cevabı veriyor. *(b)* Son owner'ın kaldırılmasının engellenmesi — dayatma olmaz; backoffice adminleri durdukça yerine yenisi atanır, sistem yalnız bilgilendirir. *(c)* Adın şifre belirleme ekranında alınması — hayır; kritik bilgilerin tamamı verilmeden hesap açılamaz, davet edilen yalnız şifresini belirler. **Kapsam:** davet akışının kendisi bu turda **yazılmıyor**; kararlar kayda geçti, ekranıyla birlikte gelecek (kriter 15a'nın erteleme adresi). --- **1.13 — 27.07.2026 (Sets — ikinci faktörün yöntemi seçilebilir).** §5.2'ye iki not: (a) backoffice'te zorunlu olan **ikinci faktörün kendisidir**, yöntemi değil — kişi 2FA ile passcode arasında seçer; (b) **passcode** §5.1'de ilk sürümden beri sayılan dört yöntemden biriydi ve kodda hiç yoktu, bu tarihte eklendi. Zorunluluk ayarla kaldırılamaz kuralı **değişmedi**. --- **1.14 — 27.07.2026 (Sets — dördüncü yöntem passkey'dir).** §5.1'in `passcode`'u **passkey** oldu: parmak izi / Face ID / donanım anahtarı (WebAuthn). Kelime hiçbir belgede tanımlı değildi; tasarım brief'i onu 6 haneli OTP için kullanıyordu ve o okuma v1.13'te söylenmeden koda geçmişti. İletilen tek kullanımlık kod ayrı bir yöntem olmaktan **çıkarıldı** — magic link zaten odur. Passkey ikinci faktör değil birincil doğrulayıcıdır (kullanıcı doğrulaması içinde), dolayısıyla §5.1'de şifrenin yanında durur ve backoffice MFA zorunluluğunu tek başına karşılar. `spatie/laravel-passkeys` ile kuruldu. --- **1.15 — 27.07.2026 (Sets — ikinci faktör kuralı oturuma sorulur; passkey ile giriş bağlandı).** §5.2'ye dört not girdi ve üçü kural, biri ortam: 1. **Kural oturuma sorulur, hesaba değil:** ya e-posta girişi + ikinci faktör, ya passkey. Passkey ile girilen oturuma ayrıca 2FA sorulmaz; şifreyle girilen oturum ikinci faktörü ayrıca kanıtlar. 2. **Kapatılan açık:** önceki kurgu hesabın passkey'i olup olmadığına bakıyordu ve passkey sahibi biri şifreyle girdiğinde **alansız bir doğrulama formu** ile içeri alınıyordu — passkey hiç sunulmadan. Passkey kaydetmek, şifreyle girişi sessizce **tek faktöre** düşürüyordu. 3. **Profil değişikliklerinde şifre yeniden sorulur** (e-posta, şifre, passkey ekleme/silme). Çalınmış oturumdan passkey eklemek, hesabı kalıcı elde tutmanın sessiz yoludur. 4. **Passkey HTTPS ister** — düz http'de tarayıcı WebAuthn'u hiç tanımlamaz. Ekranlar bunu söyler; lokal ortamın TLS'i henüz yok (`docs/issues.md`). **Uygulama (v1.16, aynı gün):** şifre adımı ayrı modal'a alındı ve 2FA kurma/kapatmayı da kapsadı; kapı tek kullanımlık izinle gerçek kılındı (buton gizlemek yetmez). Ayrıca ikinci faktör kurulan sayfa artık **ilerliyor** — passkey kaydından sonra kullanıcı panele gidiyor; önceden kayıt tamamlanıyor, oturum yetkili hâle geliyor ve sayfa bunu haber almadığı için kişi ekranda kalıyordu. **Uygulama:** passkey ile **giriş** bağlandı (`SignInWithPasskey` + giriş sayfasındaki buton), her iki törende **kullanıcı doğrulaması zorunlu** kılındı (paket varsayılanı `preferred` idi — o hâliyle "passkey iki faktör sayılır" iddiası yalnız bir yorum satırı olurdu), passkey ekleme/silme audit'lenir (A-4) ve `passcode_enabled` kolonu düşürüldü. **1.17 — 16.09.2026 (Sets — e-posta müşteri tarafında sistem genelinde tek; EGT-208).** §3.2 I-2'ye not, §13 «Aynı e-postayla ikinci kullanıcı» satırı ters çevrildi, §14 kabul kriteri 3'ün test karşılığı (`IdentityDomainTest`, `InheritedCriteriaTest` D-4) yeniden yazıldı. Sebep ölçüldü: aynı adres üç firmada kayıtlıydı, şifreyle giriş «tam bir kayıt eşleşirse» kuralıyla çalıştığından aynı şifre iki firmada tutunca giriş hiç yapılamadı (bir sabahta 17 red). Karar: `customer_users.email_hash` **global unique** (migration `2026_10_27_000100`), `AddressRegistry` yazan her ekrana «bu e-posta adresi kayıtlı» dedirtir, firma adı söylenmez. Kabul edilen ifşa yalnız bu cümledir. `sets@x` ile `sets+test@x` iki ayrı adrestir — hash adres nasıl yazıldıysa öyle alınır; etiketin anlamına posta sağlayıcısı karar verir. Kimlik alanları arası (ofis/backoffice/müşteri) serbestlik değişmedi.