@appaflytech/zeyrek-ai-mcp 0.0.30 → 0.0.32

package/dist/resources/guides/access.md

@@ -1,796 +0,0 @@
-# Erişim Rehberi — organizasyon şeması, erişim politikası, alan koruması
-
-Kompleks projenin (`project_create` `accessModel: 'complex'`) yetki modeli: kim hangi kaydı görür,
-hangi eylemi yapar, hangi alanı maskeli ya da açık görür. Basit projede izin kataloğu boştur ve
-policy yazılmaz; alan koruması ise iki türde de kullanılır.
-
-Araçlar: `organization_schema_get` · `access_permission_list` · `access_resource_list` ·
-`access_policy_list` · `access_policy_get` · `access_policy_create` · `access_policy_update` ·
-`access_policy_delete` · `entity_protection_update` · `access_preview` · `access_session_create`.
-Gateway kuralları: ORG-001…003, ACC-001…010, PROT-001…004 — her biri aşağıda ilgili başlıkta.
-
-## Kavramlar
-
-| Terim | Ne | Nerede okunur |
-|---|---|---|
-| Birim | Organizasyon ağacının düğümü; tür holding · company · branch · region · department · team · other; `function_code` birimin işlevi (it, hr, finance…) | `row_list('organization_units')` |
-| Pozisyon | Birimdeki koltuk; idari üst `parent_position_id`, işlevsel üst `functional_parent_position_id`; her pozisyonun bir rolü var; `is_multi_seat` (varsayılan false: aynı anda tek kalıcı kişi) | `organization_positions` |
-| Rol | Benzersiz unvan (Satış Müdürü); kompleks projede organizasyon şemasından gelir | `roles` |
-| Kullanıcı ataması | Kim hangi koltukta oturuyor; dönemli, `is_primary`, vekâlet için `assignment_type`; tek koltuklu pozisyonda çakışan ikinci kalıcı atama 409 `OrganizationPositionSeatOccupied`, vekâlet (`acting`) sınıra girmez | `user_positions` |
-| Kaynak | Yetkinin bağlandığı şey: entity, alan, microservice, sayfa, workflow… — katalogdaki anahtar | `access_resource_list` |
-| İzin | `<tip>.<eylem>`: `entity.read`, `field.read`, `microservice.execute`… | `access_permission_list` |
-| Grant | İzin × kaynak × etki (allow/deny) + opsiyonel kapsam, koşul, alan erişimi | politika gövdesi |
-| Politika | Grant'ler + atamalar paketi | `access_policy_list` |
-| Atama | Politikayı özneye bağlar: rol · pozisyon · birim · kullanıcı | politika gövdesi |
-| Özne | İsteği yapan uygulama kullanıcısı: id'si, pozisyonları, birimleri, şirketleri, rol slug'ları, işlev kodları | runtime |
-
-## Organizasyon ağacı
-
-Organizasyonun tek bir rol yönetim şeması vardır; yönetim konsolunda düzenlenir ve yayınlanır
-(`organization_schema_get` taslağı, `version` ile bir yayını gösterir). Kompleks proje açılınca
-yayınlı son sürümün **kopyası** projenin her ortamına yazılır (ORG-002); yayın yoksa tablolar boştur.
-
-- **Abonelik:** `project_get` → `organizationSchema`. Yeni yayın abone projeye senkronla gelir.
-  Projede yapı değişikliği (birim ekle/sil/taşı, pozisyon ya da organizasyondan gelen rol) aboneliği
-  kapatır; `customizedAt` görünür ve sonraki sürümler gelmez. Kişi atamaları aboneliği etkilemez.
-- **Okuma:** `row_list` ile hazır entity'ler. Alt ağaç kapanış tablolarındadır:
-  `organization_unit_closure` (`ancestor_id` → `descendant_id`, `depth` 0 düğümün kendisi),
-  `organization_position_closure` (ayrıca `line_type`: administrative · functional).
-- **Yazma yok (ORG-001, block).** Organizasyon ve erişim tablolarına `row_create` / `row_update` /
-  `row_delete`, table kaynaklı uç ve table step `400 SystemEntityWriteNotAllowed` alır; gateway
-  isteği göndermez. Projeye özel birim/pozisyon ve kullanıcı ataması Studio › Organizasyon
-  ekranındadır; dal ortamında yapı yazımı zaten 409'dur.
-- **Birim yöneticisi** bir kişi değil pozisyondur (`manager_position_id`). **Matris organizasyon:**
-  destek departmanı (IT) idari olarak şirkete, işlevsel olarak holding direktörüne bağlanır — ikinci
-  hat pozisyondaki işlevsel üsttür, birim ağacı tek ebeveynli kalır.
-
-## İzin kataloğu
-
-Katalog yalnız kompleks projede tohumlanır; `access_permission_list` boş dönüyorsa proje basittir.
-
-| Tip | İzinler | Kapsam alır | Alan erişimi alır |
-|---|---|---|---|
-| entity | read · create · update · delete · export · import · reveal · reassign · audit | read · update · delete · export · reveal · reassign | — |
-| field | read · write · filter | — | yalnız `field.read` |
-| row | read · update · delete · export · reveal | — | — |
-| çalıştırma | `microservice.execute` · `page.view` · `workflow.execute` · `ui-flow.run` · `function.execute` · `microfunction.execute` | — | — |
-| veri | `query.execute` · `query.unrestricted` · `view.read` | — | — |
-| dosya | `file.read` · `file.upload` · `file.delete` · `folder.read` · `folder.upload` · `folder.delete` | — | — |
-| organizasyon | `organization-unit.read` · `organization-unit.manage` · `organization-unit.assign` | — | — |
-| sistem | `system.access.manage` · `system.access.explain` | — | — |
-| süreç | `process.start` · `process.manage` · `process.view-all` (anahtar `process:<tanımId>`) | yalnız `view-all` | — |
-| görev | `task.complete` · `task.reassign` (süreç kaynağına bağlanır) | — | — |
-
-Otomasyon katalogda **yoktur** ve ona grant yazılmaz: satır yazımı otomasyonu yazanın yetkisinden
-bağımsız tetikler; adımların hangi kimlikle koştuğunu otomasyonun `runAs`'ı seçer
-(`platform_guide('workflow')` §Kompleks projede özne ve runAs).
-
-## Kaynak anahtarı
-
-Grant kaynağa id ile değil **anahtarla** bağlanır; anahtar yeniden kurma, deployment ve dal boyunca
-kararlıdır.
-
-- Biçim: `entity:<entityId>` · `field:<entityId>:<fieldId>` · diğer tiplerde `<tip>:<id>`. Anahtar
-  verilmeyen grant iznin tipinin **tamamına** uygulanır.
-- Anahtar iznin tipiyle başlar: `entity.read` → `entity:…`, `field.read` → `field:…` (ACC-001).
-- `access_resource_list { type, search, parentId }` — `key` alanı anahtardır. `parentId` bir
-  **katalog** id'sidir (listedeki `id`), entity id değil: bir entity'nin alanları için önce entity
-  satırını bul, onun `id`'siyle çağır.
-- Katalogda türetilmiş alanlar vardır (`isDerived`), korumalı alanlar işaretlidir (`isProtected`);
-  gizli sistem alanları (sahiplik alanları dahil) **yoktur**.
-- Kaynak silinince grant kalır ve `orphaned: true` görünür. Güncelleme var olan yetim anahtara
-  toleranslıdır; **yeni** gelen bilinmeyen anahtar `400 AccessResourceUnknown`.
-
-## Kapsam
-
-Kapsam satırın **sahiplik alanlarına** göre SQL'de süzülür (`sys_owner_user_id`, `sys_owner_unit_id`).
-
-| scope | Satır görünür, eğer |
-|---|---|
-| `own` | sahip kullanıcı öznenin kendisi |
-| `unit` | sahip birim öznenin birimlerinden biri |
-| `unit-tree` | sahip birim öznenin birimi ya da onun alt birimi |
-| `subordinates` | sahip kullanıcı, öznenin pozisyonlarının altındaki bir pozisyonda şu an oturuyor; hat `subordinatesLine`: `administrative` (varsayılan) · `functional` · `both` |
-| `function` | sahip birimin işlev kodu öznenin birimlerinin işlev kodlarından biri (IT direktörü üç şirketin IT kayıtlarını görür) |
-| `company` | sahip birim öznenin şirketinin altında |
-| `all` | tümü |
-
-- Öznenin birimi ya da pozisyonu yoksa ilgili kapsam **hiçbir satır** döndürmez.
-- Kapsamlı grant entity'de sahiplik alanı ister (ACC-003, warn — platform 400
-  `AccessScopeRequiresOwnerFields`). Kompleks projede yeni entity iki alanı kendiliğinden alır; eski
-  entity için `POST /{proje}/DataJobs/owner-fields/{datasourceId}` işi kolonları ekler.
-- Var olan satırların sahibi geri doldurulmaz: sahipsiz satırı yalnız `all` kapsamı görür. Yeni
-  satırda sahip yazma yolunda dolar; gövdede gönderilen değer yok sayılır.
-
-## Grant kuralları (ACC-001 · ACC-002 · ACC-003)
-
-Gateway politika gövdesini istek göndermeden denetler (ACC-001 block, ACC-002 block, ACC-003 warn):
-
-- **Etki zorunlu.** Allow'lar toplanır, **kapsamsız deny kazanır**. Deny kapsam (ve kapsamla
-  birlikte koşul) taşıyabilir: kapsamlı deny eylemi kesmez, yalnız kapsamındaki satırları süzer —
-  `rowScope` metninde `except` olarak görünür. **İstisna koşulsuz `scope: 'all'`:** koşulsuz `all`
-  daraltıcı bir kapsam değildir, "bütün satırlar hariç" demektir; böyle bir deny **kapsamsız sayılır
-  ve eylemi keser** (`explicit-deny`, izde `outcome: applied` — TB-132). `scope: 'all'` + koşul ise
-  yalnız koşula uyan satırları dışlar (`all except condition(…)`). Kapsam **atamanın öznesine** göre çözülür: birim
-  atamasında o birim, pozisyon atamasında pozisyonun birimi, rol/kullanıcı atamasında öznenin
-  birimleri. Deny alan erişimi taşımaz (`AccessDenyFieldAccessNotSupported`).
-- **Kapsam** yalnız altı entity izninde ve `process.view-all`'da (tablo yukarıda); `subordinatesLine` yalnız
-  `scope: 'subordinates'` ile.
-- **Alan erişimi** yalnız `field.read`'te: `hidden` · `masked` · `plain`. Birden çok allow'da en
-  genişi kazanır (`plain` > `masked` > `hidden`); korumalı alanın varsayılanı maskelidir.
-  **`masked` ancak korumalı alanda maskeler:** maske alanın depolama korumasından gelir. Korumasız alana
-  `fieldAccess: 'masked'` verilirse değer DÜZ döner (ölçüldü 38/M-3) — önce `entity_protection_update`
-  ile alanı koruyun ya da `hidden` verin. Gateway bunu `access_policy_create/update`'te uyarır (ACC-017).
-- **Bir alanı kapatmanın iki yolu aynı şey değildir.** Kapsamsız `deny` ile `allow + hidden`
-  okumada farklı davranır, yazmada aynı davranır — ikinci bir rol eklendiğinde fark ortaya çıkar
-  (ölçüldü 2026-09-20, S2-16):
-
-  | Yazım | Tek başına | Kullanıcıya `plain` veren ikinci bir rol de eklendiğinde |
-  |---|---|---|
-  | kapsamsız `deny` | alan satırda yok | **yine yok** — kapsamsız deny her allow'u ezer |
-  | `allow` + `fieldAccess: hidden` | alan satırda yok | **görünür olur** — `plain` `hidden`'ı yener |
-
-  "Bu rol bunu asla görmesin" istiyorsanız `deny`; "bu rolün varsayılanı kapalı olsun ama başka bir
-  rol açabilsin" istiyorsanız `hidden`. İkisi de alanı **yazılamaz** yapar.
-- **Koşul** kapsama AND ile eklenir; kapsamsız koşul yazılmaz — saf koşul için `scope: 'all'`.
-  Koşul yalnız anahtarlı grant'te çalışır ve alanları **o entity'nin katalogdaki korumasız
-  alanlarıdır** (gizli ve sistem alanı yok).
-- **Koşulda korumalı alan yok (ACC-002).** Ana kolonda maske durur; sorgulanabilir parça
-  türetilmiş alanla kurulur.
-- Aynı izin + anahtar + etki bir politikada tek grant'tir.
-
-Koşul düğümü: `{ all: [...] }`, `{ any: [...] }` ya da `{ field, op, value }`; derinlik ≤ 5, düğüm ≤ 50.
-
-| Değer | İşleçler |
-|---|---|
-| sabit (`'onaylı'`, `100`) | `eq` · `neq` · `lt` · `lte` · `gt` · `gte` |
-| dizi (`['a','b']`) | `in` · `notin` |
-| `{ subject: 'userId' }` | `eq` · `neq` |
-| `{ subject: 'unitIds' \| 'positionIds' \| 'companyIds' \| 'roleSlugs' \| 'functionCodes' }` | `in` · `notin` |
-| `{ now: true }` | `eq` · `neq` · `lt` · `lte` · `gt` · `gte` |
-| yok | `isnull` · `isnotnull` |
-
-**Koşul dili alanlar arası hesap yapmaz.** Sağ taraf ya sabit ya `{ subject }` ya `{ now }`;
-`alanA + alanB <= 100` yazılamaz. Limit türetilmiş bir büyüklüğe bakacaksa (ör. "etkili iskonto =
-nominal iskonto + aksesuar + takas farkı") o büyüklüğü **entity'de hesaplanan bir alan** olarak
-tutup koşulu ona kurun — yoksa kullanıcı nominal alanı limitin altında bırakıp gerçekte limiti
-aşabilir (ölçüldü 2026-09-20, S2-13: nominal %2,5 görünen teklif gerçekte %6,98 idi ve limiti %3
-olan kişi onayladı).
-
-Hesaplanan alanı kurmanın iki yolu vardır ve ikisi de koşul dilinden ÖNCE gelir:
-
-| Kaynak | Nasıl | Ne zaman |
-|---|---|---|
-| Aynı satırın başka bir alanından **türetiliyor** | `fields[].derivedFromFieldId` + `derivationRule` (§Türetilmiş sorgu alanı) | Değer tek bir alanın dilimi/deseni ise |
-| Birkaç alandan **hesaplanıyor** (toplam, yüzde, fark) | Kalıcı bir alan açın ve satır yazımında doldurun: yazan ucun `fields[]` listesine `source: 'expression'` ile ekleyin ya da entity'ye `automation` bağlayın | Değer aritmetik ise — koşul o alana kurulur |
-
-Kural: **limiti gerçekten belirleyen sayı satırda bir kolon olarak durmalıdır.** Koşul yalnız
-kolon okur; ekranda hesaplanan bir toplam politika için yok hükmündedir.
-
-```jsonc
-// "Birimi ve alt birimleri — yalnız onaylı olanlar"
-{ "permission": "entity.read", "resourceKey": "entity:<musteriler id>", "effect": "allow",
-  "scope": "unit-tree", "condition": { "field": "durum", "op": "eq", "value": "onaylı" } }
-```
-
-## Atama
-
-- `subjectType`: `role` · `position` · `unit` · `user`; `subjectId` ilgili tablonun satır id'si
-  (`row_list('roles')`, `organization_positions`, `organization_units`, `users`).
-- `includeDescendants` yalnız birimde (alt birimlerdekiler de politikayı alır).
-- `startsAt` verilmezse şimdi; `endsAt` sonra olmalı. Aynı özne bir politikada bir kez atanır.
-- `overridesDeny: true` yalnız `subjectType: 'user'` ve **dolu** `endsAt` ile yazılır
-  (`AccessOverrideRequiresUserWithEndDate`); atama bütün deny'leri aşar — kapsamlısını da
-  kapsamsızını da. Yazmak `access.override.manage` iznini ister (var olan bir istisnanın süresini
-  uzatmak ya da öznesini — `subjectId`/`subjectType` — değiştirmek de yazmaktır); izinsiz istek
-  403 `AccessOverridePermissionRequiredException` döner ve hiçbir şey yazılmaz.
-  **İstisna taşıyan politikanın grant'lerine dokunmak da aynı izni ister** — ekleme, silme ve
-  değiştirme, `access_policy_update` ve `access_matrix_save` yollarının ikisinde de: istisna o
-  grant kümesi kadar yasak aşar, küme değişince istisnanın sınırı da değişir. Ölçüt istisnanın
-  **süresinin dolmamış** olmasıdır (`endsAt` gelecekte), şu an yürürlükte olması değil: `startsAt`'i
-  ileri tarihli, henüz başlamamış bir istisna da izin ister. Grant listesini **id'siz** göndermek
-  kümenin tamamını değiştirmek sayılır — aynı grant'leri id'siz yeniden göndermek de izin ister,
-  o yüzden `access_policy_get`'ten gelen `id`'leri koru. İzin istemeyenler: istisnayı kapatmak,
-  süresini kısaltmak, atamayı silmek. `access_preview` kararı
-  `allowed-by-override`, ezilen deny izleri `outcome: 'overridden'` olur.
-- **Atamasız politika hiç kimseye uygulanmaz.**
-- **Yeni kompleks proje yetkili bir özneyle doğar.** Sistem politikası `system-admin` iki atama
-  taşır: Super Admin **rolü** ve projeyi açan **kullanıcı** (`subjectType: 'user'`). İkincisi
-  2026-09-22'de eklendi, çünkü S-15'ten sonra kurucunun Super Admin rolü kompleks projede özneye
-  hiç girmiyor ve koltuğu olmadığı için proje yetkili bir öznesiz doğuyordu. Aynı atama basit →
-  kompleks dönüşümünde de yazılır. Bu, "yetki koltuktan gelir" ilkesinin iz bırakan istisnasıdır:
-  gerçek yönetici koltuğu kurulduğunda `access_policy_update` ile **silinmesi beklenir**.
-
-## Hiyerarşi yetki vermez
-
-Ağaçta üstte olmak ya da bir birimin yönetici koltuğunda oturmak **tek başına hiçbir kaydı açmaz**.
-Yetki yalnız grant ve atamadan gelir:
-
-- "Müdür ekibinin kayıtlarını görür" → müdür pozisyonuna (ya da rolüne) `entity.read` +
-  `subordinates` ya da `unit-tree`.
-- "Bölge müdürü okur ama güncelleyemez" → `entity.read` allow `unit-tree` + `entity.update` **deny**.
-- "Herkes kendi kaydını düzenler" → `entity.update` allow `own`, bir role ya da en üst birime
-  `includeDescendants` ile.
-
-## Politika araçları
-
-- **Veri bağlama (Connect Data) politikayı her istekte uygular:** `connect_data_describe` alan başına
-  efektif `access` ve izinli `operators`'ı döner; gizli alan yanıtta ve kolonda yoktur, korumalı alanda
-  yalnız `eq` · `neq` · `in` · `notin` çalışır (CD-002). `asUserId` ile başka kullanıcının gözüyle okunur.
-
-- `access_policy_create` — ad, slug (projede tekil), grant'ler, atamalar tek gövdede.
-- `access_policy_update` — platform ucu **tam değiştirmedir**. Gateway kaydı önce okur: verilmeyen
-  alan taşınır ve bu `gatewayNormalized` ile söylenir. `grants` / `assignments` verilirse **tam
-  listedir**: listede olmayan silinir; var olanı değiştirmek için `id`'sini koru.
-- `access_policy_delete` — grant ve atamalarıyla birlikte.
-- `access_matrix_get` / `access_matrix_save` — Studio'nun yetki matrisinin okuma ve yazma yüzü.
-  Matris tek bir kaynak tipini tablolar (satır = kaynak, sütun = izin, hücre = o politikadaki grant).
-  `access_policy_update`'ten farkı: grant listesinin tamamı değil **yalnız değişen hücreler** gider
-  (`changes` yazar/günceller, `removedGrantIds` siler). Atamalara dokunmaz.
-- `access_resource_rebuild` — kaynak kataloğunu projenin güncel tanımlarından yeniden üretir; yeni
-  entity/alan/uç katalogda yoksa ya da `orphaned: true` satırlar kaldıysa bunu düzeltir.
-- **Tasarım eseridir:** development'ta ya da dalda yazılır, production'a deployment taşır, merge'de
-  izlenir. Dikey çözümün production'da değiştirdiği politika `origin: 'runtime'` olur ve deployment
-  ona dokunmaz.
-- `origin`: `system` · `project` · `runtime` · `module`.
-
-## Örnek: CZA Holding — Müşteriler
-
-`musteriler` entity'si: `ad` (display), `tckn` (maskeli+şifreli, son 4), `telefon` (maskeli),
-`telefon_operator` (telefondan türetilmiş), sahiplik alanları. Id'ler `access_resource_list` ve
-`row_list` ile okunur.
-
-```jsonc
-// 1) Satış personeli — yalnız kendi kayıtları, TCKN maskeli (varsayılan)
-{ "name": "Satış personeli", "slug": "satis-personeli",
-  "grants": [
-    { "permission": "entity.read",   "resourceKey": "entity:<musteriler>", "effect": "allow", "scope": "own" },
-    { "permission": "entity.update", "resourceKey": "entity:<musteriler>", "effect": "allow", "scope": "own" } ],
-  "assignments": [ { "subjectType": "role", "subjectId": "<satis-personeli rol id>" } ] }
-
-// 2) İstanbul Müdürü — departmanlarının kayıtları, TCKN açık, tek hücre açma (reveal)
-{ "name": "İstanbul müdürü", "slug": "istanbul-muduru",
-  "grants": [
-    { "permission": "entity.read",   "resourceKey": "entity:<musteriler>", "effect": "allow", "scope": "unit-tree" },
-    { "permission": "entity.update", "resourceKey": "entity:<musteriler>", "effect": "allow", "scope": "unit-tree" },
-    { "permission": "entity.reveal", "resourceKey": "entity:<musteriler>", "effect": "allow", "scope": "unit-tree" },
-    { "permission": "field.read",    "resourceKey": "field:<musteriler>:<tckn>", "effect": "allow", "fieldAccess": "plain" } ],
-  "assignments": [ { "subjectType": "position", "subjectId": "<İstanbul Müdürü pozisyon id>" } ] }
-
-// 3) Bölge müdürleri — alt ağacı okur, güncelleyemez
-{ "name": "Bölge müdürü", "slug": "bolge-muduru",
-  "grants": [
-    { "permission": "entity.read",   "resourceKey": "entity:<musteriler>", "effect": "allow", "scope": "unit-tree" },
-    { "permission": "entity.update", "resourceKey": "entity:<musteriler>", "effect": "deny" } ],
-  "assignments": [ { "subjectType": "role", "subjectId": "<bolge-muduru rol id>" } ] }
-```
-
-CEO için `scope: 'company'`. Kapsam dışı bir kaydın id'siyle okuma/güncelleme runtime'da 404,
-izin yoksa 403 döner.
-
-**Tek kayıt ucu.** Kompleks projede `isSingle` uç bulunamayan **ya da** kapsam dışı id için
-`404 NotFoundException` döner — modtan bağımsız, okuma ve yazma aynı. Basit projede aynı uç
-boş gövdeyle `204 No Content` döndürür; iki proje türü arasında bu fark bilinçlidir (TB-97).
-
-## Alan koruması
-
-Tanım yalnız platformda (entity alanında) yapılır; **kimin** maskeli ya da açık gördüğünü politika
-(`field.read` + `fieldAccess`) belirler.
-
-| mode | Ana kolon | Gizli kolonlar | Anahtar |
-|---|---|---|---|
-| `none` | düz değer | — | — |
-| `masked` | maske metni (`*******1234`) | `sys_<alan>_plain` | gerekmez |
-| `encrypted` | boş | `sys_<alan>_enc` · `sys_<alan>_kv` (+ `sys_<alan>_bidx`) | gerekir |
-| `masked-encrypted` | maske metni | `sys_<alan>_enc` · `sys_<alan>_kv` (+ `sys_<alan>_bidx`) | gerekir |
-
-- Gizli kolonlar son kullanıcıya ve kataloğa görünmez. Şifreleme AES-256-GCM, tam eşleşme için
-  HMAC blind index (`exactSearch: true`); `normalize` (`digits` · `lower` · `trim`) eşleşmeden önce
-  uygulanır — TCKN için `digits`.
-- Maske türü (`mask.type`): `last-n` (`visible` > 0) · `first-n` · `first-last` · `email` ·
-  `phone` (varsayılan son 2 hane; `mask.char` ayırıcı ya da boşluk olamaz — `+ - ( ) . /`) · `full` ·
-  `pattern` (`#` açık karakter) · `first-n-last-n`
-  (`visible` baştan, `visibleEnd` sondan, ikisi de > 0 — `{ type: 'first-n-last-n', visible: 3,
-  visibleEnd: 2 }`: `10000000146` → `100******46`). `masked` ve `masked-encrypted` modunda maske
-  zorunludur. Değer maskenin görünen hanelerinden kısaysa tamamı maskelenir.
-- **Maskeli değer geri yazılırsa yok sayılır — her türde.** Satırı okuyup gövdeyi olduğu gibi geri
-  gönderen bir istemci korumalı alanı ezmez: platform gelen değer kendi maskesine eşitse alanı ve
-  ondan türetilen alanı değişmemiş sayar (maskeler idempotenttir; 2026-09-23'e kadar `phone` değildi
-  ve maskeli telefon gerçek numaranın yerine yazılıyordu — VK-1). `visibleEnd` yalnız
-  `first-n-last-n`'de saklanır; başka türe gönderilirse platform onu 0 sayar.
-- **Hangi alan:** yalnız düz metin; display, birincil anahtar, identity, çok dilli ve ilişki alanı
-  korunamaz (PROT-003, block). Yalnız şifreli modda ana kolon boş kalır: NOT NULL alan bu modla
-  korunursa yazma düşer — alanı nullable yapın.
-- **Yeni alan:** korumayı `entity_create` / `entity_patch` / `entity_update` gövdesinde
-  `fields[].protection` ile alır.
-- **Var olan alan:** yalnız `entity_protection_update`. Güncelleme araçları var olan alanın
-  korumasını değiştiremez (`400 ProtectionChangeNotAllowed`; `entity_patch` bunu istek göndermeden
-  durdurur). Dolu satırlar arka plan işiyle dönüşür: yanıt `jobId`, ilerleme `import_status`. İş
-  sürerken aynı entity'ye yazım `409 ProtectionMigrationInProgress`; bu arada işlenmiş satırlar
-  maskeli, işlenmemişler düz görünebilir. İş hata verirse **aynı çağrıyı aynı gövdeyle** tekrarlamak
-  kaldığı yerden sürdürür.
-- Ortamda anahtar yapılandırılmamışsa şifreli mod `ProtectionKeyUnavailable` ile düşer — anahtar
-  kurulumu insan işidir.
-- `row_list` (tasarım ucu) ana kolonu döner: maskeli modlarda maske metni, yalnız şifreli modda boş.
-  Düz değer MCP'den okunmaz.
-- **Korumalı alana YAZMAK ayrı bir grant ister.** `entity.create` / `entity.update` izni olan bir
-  rol korumalı bir alana değer yazamaz: `403 AccessFieldWriteDenied`. Karar motoru yazma hakkını
-  `level != hidden && (field.write ALLOW || (entity.update && alan KORUMASIZ))` diye kuruyor, yani
-  korumalı alan için **açık `field.write` grant'i şarttır** — korumasız alanlarda `entity.update`
-  yeter. Fikstür yükleyen ilk çağrı çoğunlukla burada düşer (S-14, ölçüldü 2026-09-19:
-  `tckn` alanına 20/20 satır 403 aldı, `field.write` verilince 20/20 geçti).
-- **Denetim izi korumalı alanın düz/şifreli kopyasını tutmaz** (2026-09-20'den beri): `sys_<alan>_plain`,
-  `_enc`, `_bidx`, `_kv` yardımcı kolonları denetim kaydına hiç girmez; defterde yalnız maskeli değer
-  durur. Silme kaydı da öyle — önce silinen satırın tam şifreli metni defterde kalıyordu (S2-4).
-- **Denetim izini açmak iki alandır.** `isAuditTrailActive: true` **tek başına hiçbir şey yazmaz**;
-  `auditTrailType` (`simple` | `detailed`) verilmezse kayıt sessizce oluşmaz ve hata da dönmez.
-  Geçmişe telafi yok: bayrak açıkken tipi boş geçen dönemde yapılan yazmalar kalıcı olarak izsizdir
-  (ölçüldü 2026-09-20, S2-3). Fikstür kurarken ikisini birlikte yazın ve ilk yazmadan sonra
-  `entity_audit_trails` ile bir satır görün.
-- Bilinen sınır: template'ten kurulan projede korumalı kolonlar kaynak projenin anahtarıyla gelir ve
-  hedefte yeniden şifrelenmez.
-
-## Türetilmiş sorgu alanı
-
-Korumalı alanın sorgulanabilir parçası ayrı bir **metin** alanda saklanır; platform yazma yolunda
-hesaplar.
-
-- `fields[].derivedFromFieldId` + `derivationRule { type, start, length, pattern }` birlikte verilir
-  (PROT-004, block); alan kendisinden türetilemez.
-- `slice` — `start` (≥ 0) ve `length` (> 0): telefon `05321234567` → `{ type: 'slice', start: 1, length: 3 }` → `532`.
-- `regex` — `pattern`; ilk yakalama grubu, grup yoksa eşleşmenin tamamı. Platform .NET Regex'le derler.
-- `domain` — e-postanın alan adı, küçük harf.
-- Türetilmiş alan katalogdadır; filtrede ve policy koşulunda kullanılabilir. Kaynak korumalı olsa da
-  türetilmiş değer **düz** saklanır — ne açığa çıkardığını seçerken düşün.
-- Değer üç yerde hesaplanır: her satır yazımında, koruma dönüşüm işinde (`entity_protection_update`)
-  ve türetilmiş alan eklendiğinde ya da kaynağı/kuralı değiştiğinde. Sonuncusu `entity_update` /
-  `entity_patch` kaydından sonra açılan `derived-fill` işidir: var olan satırları kaynaktan (şifreliyse
-  çözerek) doldurur, tabloyu kilitlemez (yazım 409 almaz), yanıt iş numarası taşımaz. Bitişi
-  `import_history { entityId }` ile izleyin — en yeni satır `kind: 'derived-fill'`, `status: 'completed'`
-  olunca değerler yerindedir; o ana kadar yeni kolona filtre 0 satır dönebilir. Kaynak alan o sırada
-  dönüşümdeyse doldurma onu atlar; dönüşüm bitince (`protection-*` `completed`) platform aynı tabloya
-  bir `derived-fill` işi daha açar ve dönüşümün önceden işlediği satırları da doldurur — değerleri o
-  işin bitişinden sonra okuyun. Yalnız ad değişikliği ve silme iş açmaz. Bilinen eksik:
-  deployment/merge ya da şablon kurulumuyla hedef ortama gelen türetilmiş alan orada kendiliğinden
-  dolmaz (platform bulgusu VK-21).
-
-## Arama ve sıralama (PROT-001 · PROT-002)
-
-- Korumalı alanda yalnız `eq` · `neq` · `in` · `notin` · `isnull` · `isnotnull`. `contains`,
-  `startswith`, `endswith` (ve büyük/küçük harf duyarsız eşleri), `lt`/`gt` karşılaştırmaları
-  `400 ProtectionOperatorNotAllowed` (PROT-001, block — `row_list` istek göndermeden durur).
-- Şifreli modda eşitlik yalnız `exactSearch: true` ile çalışır (blind index); yoksa `eq` de reddedilir.
-- Korumalı alana göre sıralama `400 ProtectionSortNotAllowed` (PROT-002, block).
-- Denetim kök entity'nin alanındadır (`tckn` ya da `musteriler.tckn`); ilişki join'i üzerinden
-  korumalı alana filtre yazmayın — o yol denetlenmez.
-- Kısmi arama ihtiyacı türetilmiş alanla karşılanır (`telefon_operator eq 532`).
-
-## Runtime: uygulama oturumu ve özne
-
-Kompleks projede kimliği platform yönetir; uygulamanın kendi kimlik middleware'i gerekmez (ACC-006).
-
-| Uç | Ne |
-|---|---|
-| `POST /{proje}/runtime/{app}/auth/sign-in` | `{ email, password }` → erişim jetonu (15 dk) + üç çerez: `ZY_App_{proje}` (HttpOnly), `ZY_AppRefresh_{proje}` (30 gün), `ZY_Csrf_{proje}` |
-| `POST …/auth/refresh` | yenileme çerezi (ya da gövdede `refreshToken`) → yeni jetonlar; eski yenileme jetonu tekrar gelirse bütün aile iptal, 401 |
-| `POST …/auth/sign-out` | çerezleri siler |
-| `GET …/auth/me` | kullanıcı, roller, pozisyonlar, birimler, şirketler |
-| `GET /{proje}/runtime/{app}/access` | izin özeti: `mode`, izinli sayfa ve uç slug'ları, entity başına eylemler ve alan düzeyleri (arayüzde gizleme için; `enforce` dışında her şey açık döner) |
-
-- Jeton önce çerezden, yoksa `Authorization: Bearer`'dan okunur. Çerezle gelen **durum değiştiren**
-  istek `X-ZY-CSRF` başlığında `ZY_Csrf_{proje}` değerini ister (yoksa `403 CsrfTokenMismatch`);
-  Bearer'lı istek CSRF istemez. Giriş hız sınırı 5 dk'da 10 deneme (429).
-- Kullanıcı projenin `users` tablosundadır; parola biçimi değişmedi (`Hasher.Hash`).
-- **Özne:** kullanıcı id'si, pozisyonları, birimleri, şirketleri, rol slug'ları, işlev kodları.
-  **Kompleks projede rol YALNIZ pozisyondan gelir** (2026-09-21, S-15): `users` ekranından verilen
-  doğrudan rol (`user_roles`) özneye girmez ve hiçbir yetki vermez — koltuğu olmayan kullanıcı
-  rolsüzdür ve her kapsamlı grant'ten reddedilir. Doğrudan rol birleşimi yalnız **basit** projede
-  sürer. Dönüşümden önce kimin yetki kaybedeceğini `access_model_preflight` `usersWithDirectRoles`
-  sayar. Workflow
-  bağlamında `user` değişkeni **önceden dolar**: `id`, `email`, `roles`, `roles_csv`, `positions`, `units`.
-  Salt okunur `subject` nesnesi ve `Can(izin, anahtar)` yardımcısı **henüz yok** — yetkiyi ifadede yeniden
-  kurmayın; uç, sayfa, satır ve alan kararı platformdadır.
-- **Anonim uç işareti yok:** kompleks + `enforce` ortamda oturumsuz her microservice ve sayfa isteği
-  `401 AppSessionRequired` döner. İstisna, koruması `anonymous` olan system operation'dır
-  (`access.session.create`; uç `isAnonymous: true` olmak zorunda).
-- **Sayfa akışı bu uçlara ham `fetch` atmaz (FLOW-028).** Giriş `access.session.create`, kullanıcı
-  kartı `access.session.get` system microservice'iyle `microservice` adımından çağrılır: runtime
-  `X-Environment`'ı, CSRF'i ve 401'de tek yenilemeyi kendisi yapar, giriş gövdesi jeton taşımaz.
-  Yanlış parola `401 AppSignInFailedException` döner (oturum hatası değildir, yenileme tetiklemez).
-
-## Zorlama modu
-
-| Mod | Ne olur |
-|---|---|
-| `off` | Karar motoru devrede değil; kimlik ve yetki bugünkü gibi middleware'de. **Korumalı alanlar AÇIK döner** (`__protected: { <alan>: 'plain' }`), reveal 403 (açacak bir şey yok) |
-| `shadow` | Karar motoru her istekte çalışır ama **engellemez**; yanıt `off` ile aynıdır (korumalı alanlar açık), ayrıca "reddedilirdi / süzülürdü / maskelenirdi" kaydı karar günlüğüne yazılır |
-| `enforce` | İzin yoksa 403, kapsam dışı kayıt 404, satırlar SQL'de süzülür, alanlar gizli ya da maskeli döner |
-
-- Mod **ortam başına** bir ayardır: `project_get` → `environments[].enforcementMode`. Yeni kompleks proje
-  `enforce` başlar, dal ortamı üst ortamın modunu alır. Değişiklik runtime'a en geç ~30 sn'de yansır.
-- Eski rol listelerini (`page.roleIds`, `microservice.roles`) platform **hiçbir modda** karar için kullanmaz:
-  liste yalnız `triggerSource.roles`'a geçer ve `Authorized(user.roles)` çağıran middleware okur. Uç ve
-  sayfa izninin kapısı `shadow`/`enforce`'ta erişim politikasıdır; bağlı middleware'ler ise her modda koşar
-  ve reddedebilir (ACC-006).
-
-## Zorlama modunu kim değiştirir (ACC-007)
-
-Mod değişikliği **ölçülerek** yapılır; MCP'de artık hem ölçen hem yazan araç var:
-
-1. `access_decision_log_summary` / `access_decision_log_users` — gölge modun biriktirdiği
-   "reddedilirdi" kayıtlarını izin × kaynak ve kullanıcı kırılımında okur; `access_decision_log_list`
-   tek tek kayıtları verir. Platform üç karar yazar: `would-deny` (istek reddedilirdi),
-   `would-filter` (istek geçerdi, satırlar süzülürdü) ve `would-mask` (alan maskeli ya da gizli
-   dönerdi — `permission: 'field.read'`, `resourceKey: 'field:<entityId>:<fieldId>'`,
-   `reason: 'masked' | 'hidden'`). `decision` süzgeci **opsiyoneldir** — vermezseniz hepsi gelir.
-   `filteredRowCount` yalnız **liste okuma** yolundaki `would-filter` kayıtlarında doludur (gerçek
-   sorgunun toplamı − kapsamlı toplam); güncelleme ve silme yolunda `null` kalır. Kayıt dakikalık
-   pencerede toplanır, bu yüzden alan **pencere toplamıdır**: istek başına düşen satır sayısı
-   `filteredRowCount / count`'tur (ölçüldü 2026-09-19: `count: 22`, `filteredRowCount: 352` →
-   istek başına 16). Studio'nun gölge raporu bu bölmeyi kendisi yapar ve istek başına değeri
-   gösterir; ham toplamı okuyan başka bir istemci bölmeyi kendi yapmalıdır. `would-mask`
-   istek başına entity başına bir kez **çözülür**, ama maskeli/gizli **her alan** için bir kayıt
-   düşer ve yalnız sorgu satır döndürdüğünde yazılır.
-2. `access_enforcement_readiness { days }` — pencerede kaç "reddedilirdi" olduğunu sayar.
-   `isReady: false` ise `enforce` bugün çalışan bir şeyi keser. `true` olması hiçbir şeyin
-   kesilmeyeceğini **kanıtlamaz**: yalnız o pencerede denenen yolları kapsar, az kullanılan uçları
-   `access_preview` ile ayrıca sınayın.
-3. `access_enforcement_mode_set { projectId, environmentId, enforcementMode, confirm }` — modu
-   değiştirir. Platform iki durumda `confirm` ister: production ortamında **her** değişiklik (409
-   `ProductionEnforcementChangeRequiresConfirmation`) ve **her ortamda `off`'a geçiş** (409
-   `EnforcementOffRequiresConfirmation`). `off` süzmeyi kaldırmakla kalmaz, korumalı alanları da
-   herkese açık döndürür: karar kullanıcınındır, aracın değil — hangi ortam ve neden olduğunu
-   söyleyin.
-
-Değişiklik runtime'a en geç ~30 sn'de yansır.
-
-## Runtime'da kapsam, alan erişimi ve reveal
-
-- **Table kaynaklı uç, table step ve dışa aktarma** satırları öznenin kapsamıyla SQL'de süzer. Kapsam dışı
-  id ile okuma/güncelleme/silme **404** (tek kayıt ucunda da 404; basit projede 204); eylem izni yoksa
-  **403** `ForbiddenException` (mesaj hangi izin olduğunu söylemez — `access_preview`).
-- **Alan erişimi:** `hidden` alan satırdan tamamen çıkar; korumalı alan varsa satırda
-  `__protected: { <alan>: 'masked' | 'plain' }` bulunur. Maskeli değer bir metindir — forma değer olarak
-  bağlanmaz, geri yazılmaz.
-- Yazma yetkisi olmayan alana değer → `403 AccessFieldWriteDenied`; filtre yetkisi olmayan alana filtre →
-  `403 AccessFilterDenied`; sıralama yetkisi olmayan alana sıralama → `403 AccessSortDenied`. Korumalı
-  alanda tam eşleşme araması ayrı `field.filter` iznidir ("TCKN ile bul, maskeli gör"). Gizli alan bu iki
-  uçta da **sızmaz**: süzme ve sıralama denemesi 403 döner, boş sonuç değil.
-- **Yazma denetimine yalnız satıra gerçekten değer yazılan alan girer.** Bir table-source yazma
-  ucunun `fields[]` listesinde `writeOn: always` ile duran alan, kaynağı gövde/başlık/query ise ve
-  istekte **hiç gönderilmemişse** satıra anahtar olarak girmez, yazma kararına da sokulmaz
-  (TB-110, 2026-09-20). Sabit değeri ya da ifadesi olan alan yazılıyor sayılır ve denetlenir; gövdede
-  açıkça `null` gönderilen alan da yazılıyor sayılır. Eskiden gönderilmeyen alan da satıra girdiği
-  için kapalı tek bir alan **bütün ucu** `403 AccessFieldWriteDenied` ile kapatıyordu (ölçüldü
-  2026-09-20, S2-15).
-- **`deny` ile `allow + fieldAccess: hidden` okumada farklı, yazmada aynıdır:** ikisi de alanı
-  **yazılamaz** yapar. Okumada `deny` alanı hiç getirmez, `hidden` alanı satırdan çıkarır; yazmada
-  ikisi de `403 AccessFieldWriteDenied` verir.
-- **Reveal:** `access_reveal { application, asUser, entityId, rowId, fieldSlug, reason }` →
-  `POST /{proje}/runtime/{app}/reveal`. Kapsamlı `entity.reveal` izni ister; gerekçe zorunlu
-  (≤ 1000 karakter) ve denetim kaydına düşer; hız sınırı ayrıdır (varsayılan 5 dk'da 20 → 429).
-  Proje ayarı `revealReasonMinLength` (varsayılan 0, `project_get` / `project_update`) daha kısa
-  gerekçeyi `400 RevealReasonTooShort` ile reddeder: deneme hız sınırını tüketir ve denetim
-  defterine `REVEAL-DENIED` düşer. Gateway asgariyi projeden okur ve kısa gerekçeyi hiç göndermez
-  (ACC-010); kasıtlı olumsuz ölçümde `expectFailure: true` ön denetimi atlatır.
-  Basit projede ve `off` modda 403. Değer istemcide kısa süre gösterilip atılır.
-  **Reddedilen deneme de kayda geçer** (2026-09-19'dan beri): izin yoksa, satır kapsam dışıysa ya da
-  satır bulunamadıysa denetim defterine `REVEAL-DENIED` satırı yazılır — gerekçe `currentValue`'da,
-  ret sebebi `previousValue`'da. Kayıt isteğin transaction'ı geri alınsa da kalır; başarılı
-  `REVEAL` satırında `previousValue` null olduğu için iki durum ayrılır.
-- **Kullanıcının bütün yüzeyi:** `access_runtime_get { application, asUser }` →
-  `GET /{proje}/runtime/{app}/access`: zorlama modu, görülebilen sayfa ve uç slug'ları, entity başına
-  eylemler ve alan erişimleri. `access_preview` tek kararı açıklar, bu araç haritanın tamamını verir.
-  İkisi de `asUser` ister — gateway'in servis jetonu bir uygulama kullanıcısı değildir.
-- İlişki join'iyle gelen alanlar süzülmez: ilişkinin görünen adı her zaman döner.
-
-## Kısıtsız sorgu ve runAs (ACC-004 · ACC-005)
-
-- **Ham SQL** (query kaynaklı uç, query step): sorgu metni sahiplik alanlı ya da korumalı bir entity'nin
-  slug'ını geçiriyorsa `403 AccessQueryNotScoped`. Eşleşme sözcük düzeyindedir — slug kolon ya da takma ad
-  olarak geçse de sayılır. `isUnrestricted: true` sorgu çalışır ve **yalnız satır kapsamını**
-  kaldırır; yazması `query.unrestricted` iznini ister (ACC-005, warn).
-  **Koruma yardımcı sütunları sorgu metninde yasaktır** (TB-103, 2026-09-20): `sys_<alan>_plain`,
-  `_enc`, `_bidx`, `_kv` geçen bir sorgu kayıtta **400** `QueryProtectionColumnNotAllowed`, koşuda
-  **403** `AccessQueryProtectionColumnDenied` verir — `isUnrestricted` olsun ya da olmasın.
-  Her `isUnrestricted` koşusu karar günlüğüne **`unrestricted`** kaydı yazar (enforce modda da);
-  `access_decision_log_list { decision: "unrestricted" }` ile okunur. **Sınır:** kayıt, sorgu korumalı
-  ya da sahiplik alanlı bir entity'ye dokunduğunda düşer — kapsız bir tabloyu okuyan `isUnrestricted`
-  sorgusu zaten bir şey atlamadığı için iz bırakmaz. **İkinci sınır:** yasak sütun taraması sorgu
-  metnindeki ADLARA bakar; `select *` ile gelen koruma sütunlarını göremez — rapor ucunda sütunları
-  açıkça saydırın.
-  Eskiden ölçülen açık (2026-09-20, S2-8): kapsamı üç satır olan bir kullanıcı aynı uçla on bir
-  satırın hepsini aldı ve `sys_telefon_plain` kolonunu takma adla seçerek `masked` bir alanın **düz
-  değerini** okudu.
-- **Adım kimliği** (table, query ve process step, `rule.runAs`): `inherit` (varsayılan, çağıranın kapsamı) ·
-  `system` (kapsam ve alan erişimi atlanır, denetim kaydı yok — ACC-004 warn; gerekçeyi adımın
-  `caution`'ına yazın) · `triggering-user` (bastırma geri alınır ve adım **tetikleyen kullanıcının**
-  kapsamıyla koşar; tetikleyen bilinmiyorsa hiçbir şey değişmez). `workflow_step_schema` bu alanı
-  göstermez; gövdeye yazılır.
-  **`runAs: system` bir yetki yükseltmesidir ve `workflow.runas.manage` platform iznini ister**
-  (TB-105, 2026-09-20): akışın kendisine ya da herhangi bir adımına `system` yazan `workflow_create` /
-  `workflow_update` isteği izin yoksa **403** `WorkflowRunAsPermissionRequired` alır; `inherit`'e
-  dönmek serbesttir. Uçların kendisi 2026-09-21'den beri **`workflow.write`** platform izniyle de
-  korunur (RA-11): izni olmayan kullanıcı gövdesiz **403** alır (middleware), izni olup
-  `workflow.runas.manage` olmayan kullanıcı uca ulaşır ve gövdeli **403
-  `WorkflowRunAsPermissionRequired`** görür. Okuma uçları (`Get` tekil ve liste ·
-  `GenerateStepSchema` · `GetMiddlewareVariables` · `GetDependencies`) 2026-09-21'den beri
-  **`workflow.read`** ister (RA-15): önceden öznitelik taşımadıkları için super-admin'e kilitliydiler
-  ve `workflow.write` verilen kullanıcı akışı yazabiliyor ama okuyamıyordu. `Preview` ucu
-  **`workflow.write`** ister (RA-16, 2026-09-21): uç kayıtlı bir akışı değil **istemcinin gövdede
-  yazdığı adımları** koşturur, yani veri önizleme değil akış yazma sınıfındadır. Query, table ve
-  process adımlarının her sistem koşusu karar günlüğüne **`elevated`** kaydı yazar
-  — akış id/slug'ı, akışı yazan kullanıcı ve adına koşulan kullanıcı orada durur
-  (`access_decision_log_list { decision: "elevated" }`); `process` adımı 2026-09-21'e kadar bu kaydı
-  yazmıyordu (RA-17, düzeltildi). Ölçülen açık (2026-09-20, S2-10): onay limiti
-  200 bin olan kullanıcı `runAs: system` bir adımla 6 M TL'lik kaydı onayladı; aynı iş `inherit` iken
-  `ForbiddenException` alıyordu. Kullanıcı isteğiyle tetiklenen akışlarda `inherit` bırakın.
-- **Tasarım zamanı: Studio erişimi veri erişimidir ve `project.data.preview` ile daraltılır.**
-  `microservice_preview` ile Studio satır ızgarası (`row_list`) çağıranın kapsamıyla değil, kapsamsız
-  koşar: bütün satırlar ve kapsamsız `deny` ile kapatılmış alanlar **düz** döner; yalnız alan koruması
-  (masked/encrypted) depolama katmanında olduğu için durur (ölçüldü 2026-09-20, S2-20). Bu yüzden iki
-  uç da **`project.data.preview` platform iznini** ister (TB-114, 2026-09-20); izni olmayan platform
-  kullanıcısı **403** alır ve Studio ızgarasında "Veri önizlemesi için izin gerekir" boş durumunu
-  görür. İzin verilen tasarımcı hâlâ kapsamsız görür — bir rolün ne göreceğini önizlemeyle değil
-  `access_preview` / `access_runtime_get` / `asUser` ile ölçün.
-  **Akış önizlemesinde zorlama hiç açılmaz** (ölçüldü 2026-09-21, RA-19): `Activate(...)` yalnız
-  microservice / sayfa / connect-data / debug yollarında çağrılır, `POST workflows/{app}/preview`
-  yolunda çağrılmaz — kompleks projede bile önizleme `Mode = Off` ile koşar, adım kapsamı
-  uygulanmaz ve `runAs: system` adımı `elevated` yazmaz. Önizlemenin kapısı bu yüzden zorlama değil
-  **izindir** (`workflow.write`).
-- **Workflow kimliği** (`workflow.runAs`, otomasyonlarda): `inherit` (varsayılan) **tetikleyen çağrının
-  kapsamıdır** — otomasyon, satırı değiştiren kullanıcı neyi yapabiliyorsa onu yapar; `system` bir
-  yükseltmedir, `workflow.runas.manage` ister ve `elevated` kaydı yazar; `triggering-user` iç içe
-  bastırmayı da geri alır (üst düzeyde `inherit` ile aynı sonucu verir). Aynı üç değer, aynı anlam —
-  adım düzeyi workflow düzeyini ezer.
-  **Ölçülen açık kapandı (RA-10, 2026-09-21):** `inherit` 2026-09-21 öncesinde zorlamayı **tamamen
-  bastırıyordu**, yani `runAs` yazmadan otomasyon açan herkes `workflow.runas.manage` kapısını atlayarak
-  yükseliyor ve geriye `elevated` kaydı bile kalmıyordu. Ölçüm: kapsamı `own` olan bir müşteri
-  temsilcisi kendi satırını güncelledi, otomasyon **başkasının** satırını değiştirdi ve karar günlüğü
-  boş kaldı. Artık kapsam dışına yazan `inherit` otomasyon reddedilir; **satır içi** otomasyonda bu
-  tetikleyen satır yazımını da düşürür (`ForbiddenException` akış içinden bugün 500 döner — TB-124),
-  kuyruk otomasyonunda `automation_histories` `failed` olur ve satır yazımı etkilenmez. Akış içinden
-  gelen ret 2026-09-21'den beri **doğru HTTP kodunu** taşır (TB-124): `ForbiddenException` → **403**,
-  kapsam dışı satırda `NotFoundException` → **404**; gövde yine `WorkflowStepErrorResponse`'tur
-  (`code` · `message` · `step`). **Sınır:** akışın kendi global hata dalı varsa kodu o dalın
-  `response` adımı belirler — gateway'in her akışa eklediği `gatewayOnError` adımı 500 döndürür.
-  **Sınır:** aktörsüz kuyruk olayında (zamanlanmış mikroservis, deployment içe aktarımı) özne hiç
-  kurulmaz, bağlam pasiftir ve otomasyon eskisi gibi zorlamasız koşar. `shadow` ortamda reddetmez,
-  `would-deny` yazar.
-- **Otomasyon aktörü:** satır olayındaki kullanıcı hem satır içi hem kuyruk otomasyonunda taşınır;
-  kuyruk tüketicisi özneyi kurup ortamın modunu etkinleştirir. Aktör otomasyon geçmişinde
-  `queued_events.actor_user_id` kolonunda durur.
-- **Workflow JS'inde özne:** her adımın JS bağlamında dondurulmuş `subject` nesnesi vardır
-  (`userId` · `roleSlugs` · `positionIds` · `unitIds` · `companyUnitIds` · `functionCodes`) ve
-  `Can(permission, resourceKey)` karar motoruna yan etkisiz sorar. Zorlama kapalıyken `Can` her zaman
-  `true` döner — "kapalıyken de reddet" davranışı istiyorsanız kendiniz kontrol edin.
-
-## Açıklama ve sınama
-
-- **Neden?** → `access_preview { userId, permission, resourceKey, rowId? }`: karar, gerekçe, satır
-  kapsamı, alan erişimi ve iz (atama → politika → grant). Yan etkisizdir ve zorlama modundan bağımsız
-  hesaplanır — gölge moddaki "reddedilirdi" kaydını da böyle okuyun. `rowId` verildiğinde `isAllowed`
-  **tablonun** cevabı olarak kalır; satırın cevabı `rowInScope` (özet: `summary.row`
-  `in-scope` / `out-of-scope`). Kapsam dışı satır çalışma zamanında 404 döner.
-- **Kullanıcı gözüyle sına (parolasız)** → runtime araçlarına `asUserId: '<users satır id'si>'`:
-  `connect_data_execute`, `microservice_execute`, `microservice_debug`, `page_runtime_get`, `page_screenshot`
-  (ayrıca Studio uçları `connect_data_describe/preview/get/bind`). İstek gateway kimliği + `impersonated-user-id`
-  başlığıyla gider; platform özneyi o kullanıcı kurar (`AppSessionMiddleware`) — politika, kapsam, maske onun.
-  Yalnız development/dal (production'da başlık düşer, gateway isteği göndermez); kullanıcı projede olmalı.
-  Parolasız açılan test kullanıcısı için yeterlidir; sayfayı açabilmesi için politikasında `page.view` olmalı.
-  **Parolasız kullanıcı `user_create` ile AÇILMAZ** — şeması `password`'ü zorunlu tutar ve AI hiçbir alana parola
-  yazmaz. Yol: `row_create { entityId: 'users', rows: [{ email, first_name, last_name }] }` → dönen satır id'si
-  `asUserId`'dir; pozisyon/politika ataması `user_position_replace` ve `access_policy_create` ile aynı kalır
-  (ölçüldü 2026-09-21, 39/05 D-19: iki test kullanıcısı böyle açıldı, `asUserId` ile 200/403 beklendiği gibi).
-- **Oturum açılmış üye olarak sına** → `access_session_create { application, email, password }`; yanıttaki
-  `tokenRefs` referansını `microservice_execute` / `microservice_debug` / `page_runtime_get` `asUser`
-  alanına verin. Jeton Bearer olarak gider (CSRF gerekmez), ne yanıta ne günlüğe düz yazılır.
-- `microservice_debug` ve `page_runtime_get` kompleks projede yanıta `accessDecision` ekler: `decision`
-  (allow · deny · not-enforced · unknown), `mode`, hata kodu, izin, `reason`, `next`.
-- `microservice_preview` bir Studio ucudur: uygulama jetonuyla sınanamaz — uygulama kullanıcısı olarak
-  `microservice_execute` / `microservice_debug`.
-
-## Basit ↔ kompleks dönüşüm
-
-1. `access_model_preflight { projectId }` — ortam ortam ölçer: entity ve satır sayısı, sahiplik alanı
-   olmayan entity'ler, dış datasource'lu entity'ler, sorgu ve kısıtsız sorgu sayısı, rol sayısı,
-   **rezerve tablo adı çakışmaları**, `sys_created_user_id`'den doldurulabilir satır sayısı,
-   middleware'e bağlı uç ve sayfa listesi, pozisyonsuz kullanıcı sayısı, kapsamlı tabloya dokunan ham
-   SQL sorguları. `slugCollisions` boş değilse dönüşüm yapılmamalıdır: kompleks model o adlarla kendi
-   sistem tablolarını kurar.
-2. `access_model_convert { projectId, target, enforcementMode }` — `enforce` kabul edilmez; yeni
-   kompleks proje önce `shadow`'da izlenir. Yanıt "başladı" demektir.
-3. `access_model_conversion_tasks { projectId }` — ortam başına görev: `pending` · `processing` ·
-   `completed` · `error`, deneme sayısı ve hata metniyle. **Bittiğinin tek kanıtı budur**; `error`
-   kalan ortam dönüştürülmemiştir.
-
-## Organizasyon yapısını yazmak
-
-Kompleks projede elle (row API'siyle) yazılması kilitli olan tablolar **üçtür**: `organization_units` ·
-`organization_positions` · `user_positions` (ORG-001). **`roles` bu listede değildir** — sıradan bir
-entity'dir ve kompleks projede de `row_create` ile yazılabilir; proje rolleri fikstür kurarken böyle
-açılır (ölçüldü 2026-09-20, S2-32).
-
-Projenin kendi birim/pozisyon ağacı `organization_tree_get` ile okunur; `organization_unit_create` ·
-`organization_unit_update` · `organization_position_create` · `organization_position_update` ile
-yazılır. Kullanıcının rolü, birimi ve şirketi pozisyonundan gelir: `user_position_list` /
-`user_position_replace` (liste **tam değiştirmedir**, boş dizi kullanıcıyı pozisyonsuz bırakır).
-
-Proje organizasyon şemasına aboneyse buradan yazmak projeyi "özelleştirilmiş" işaretler ve sonraki
-yayın otomatik inmez; hizalamak için `organization_schema_resubscribe_preview` →
-`organization_schema_resubscribe`. Yayın tarafı: `organization_schema_versions` ·
-`organization_schema_diff` · `organization_schema_subscribers` · `organization_schema_publish`
-(geri alınamaz ve abone projelerin **production** şemasına da yazar) ·
-`project_organization_schema_tasks` (yayının o projeye indiğinin kanıtı).
-
-### Organizasyon şeması: taslağı AI yazar, yayını insan yapar
-
-Merkezi şemanın **taslağına** `organization_schema_unit_create` · `organization_schema_unit_update` ·
-`organization_schema_position_create` · `organization_schema_position_update` ile yazılır. Bu dört
-araç yalnız taslağı değiştirir: hiçbir projeye inmez, production'a dokunmaz ve verilmeyen alanı
-korur (gateway taslağı okur, tek düğümü değiştirir, listeyi geri yazar — platformda düğüm başına
-uç yoktur, yazma tek parçadır; arada başkası yazdıysa onun değişikliği ezilir).
-
-**Yayın AI'ın işi değildir.** `organization_schema_publish` geri alınamaz, bütün abone projelere
-senkronize olur ve abone projenin **production** şemasına da yazar; repo anayasası AI'ın hiçbir
-ortamda production'a yazmasını yasaklar. Taslağı hazırlayın, farkı `organization_schema_diff`
-(`to` verilmezse **taslak ↔ verilen yayın** karşılaştırılır) ile gösterin ve yayını insana bırakın.
-
-Ağacın bugünkü kuralları — hepsi 2026-09-20'de ölçüldü (S2-17 · S2-18 · S2-30):
-
-- **Tek kök zorunlu.** İkinci bir kök açmak ya da bir birimi köke taşımak `400` döner. Proje kendi
-  kökünü açamaz; yayımlanmış şemanın köküne eklenir.
-- **`unitType` yalnız etikettir.** `holding` · `company` · `branch` · `region` · `department` ·
-  `team` · `other` arasında izinli-ebeveyn kuralı **yok**: şube doğrudan şirketin altına alınabilir
-  (200). Denetlenen tek şey döngü ve kod tekilliği. Anlamlı hiyerarşiyi siz koruyun. Bu bilinçli bir
-  karardır (TB-111): sabit bir tip matrisi gerçek organizasyonlara uymuyor, şema düzeyinde
-  yapılandırılabilir kural faz 2 adayıdır. Tipin tek işlevsel etkisi `company`'dir — kapsam
-  hesabında şirket sınırı odur.
-- **Şemadan gelen düğüm (`origin: "organization"`) kilitli değildir.** Proje onu taşıyabilir,
-  yeniden adlandırabilir, **arşivleyebilir** ve içine kendi rolüyle koltuk açabilir. `origin`
-  denetimi hiçbir yazma yolunda yok; tek koruma dal ortamıdır.
-- **Arşivleme geri alınabilir** (2026-09-21, TB-112). `organization_unit_activate` ve
-  `organization_position_activate` pasifleştirilmiş düğümü geri açar; id, kod ve alt ağaç korunur.
-  Kural kökten yaprağa işler: üst düğüm pasifken alt düğüm açılmaz — `400`
-  `OrganizationStructureParentInactive`. Pozisyonda üç ayrı sebep sayılır (birimi pasif, idari üst
-  pozisyonu pasif, işlevsel üst pozisyonu pasif). Koltuk **boş** açılır: eski atama geri gelmez,
-  `user_position_replace` ile yeniden oturtulur. Güncelleme araçları hâlâ `isActive` almaz.
-- **Sapma raporu `organization_schema_drift`'tir** (2026-09-21, TB-112). `organization_schema_diff`
-  iki **yayımlanmış sürümü** karşılaştırır ve projenin kopyasını hiç görmez; `organization_schema_drift`
-  tam tersine projeye bakar ve ortam başına iki ekseni **ayırır**: `driftFromApplied` = projenin
-  uyguladığı sürüme göre yerel kopyadaki fark (`updated` proje düğümü yeniden adlandırdı/taşıdı,
-  `removed` proje onu **arşivledi**), `newerInSchema` = aynı sürümden son yayına kadar şemada olanlar.
-  `customNodes` projenin kendi (`origin: "project"`) düğümleridir ve sapma sayılmaz. Salt okunur;
-  basit projede `400`.
-- **Abonelik hep-ya-hiçtir**: abone proje şemadaki **bütün** birimleri görür (başka iş kollarınınkini
-  de); alt ağaca abone olma yolu yok. Projenin kendi (`origin: "project"`) birimleri ise yalnız kendi
-  veritabanında kalır, projeler arasında karışmaz.
-- **Pasifleştirme araçları:** `organization_unit_deactivate` · `organization_position_deactivate`
-  (2026-09-20'de eklendi; uygulama oturumu istemez). Kapatma sırası yapraktan köke: kullanıcıyı
-  koltuktan al (`user_position_replace`) → pozisyonu pasifleştir → alt birimler → birimi
-  pasifleştir. Ara adımda `400 OrganizationStructureNodeInUse` alırsınız ve gateway hangi sıranın
-  izleneceğini mesaja ekler. Pasifleştirilen birimin sahiplendiği satırlar kimsenin kapsamına
-  girmez — `row_reassign` ile devredin (§Sahiplik ve devir).
-- **Dizin (LDAP/AD/SCIM) entegrasyonu yoktur.** Kullanıcı yalnız elle (`user_create` /
-  yönetim konsolu) açılır; toplu içe aktarma ya da dizinden eşitleme operasyonu da yok.
-
-## Toplu işlem
-
-Kapsam ve koşul her satırda ayrı ayrı uygulanır; dolayısıyla "hepsini birden onayla" bir POLİTİKA
-sorusu değil bir UÇ sorusudur ve table-source `update` bunu **filtreyle yapamaz** — tam olarak bir
-tekil alan filtresi ister (`InvalidFilterCountException` · `FilterFieldMustUniqueException`,
-ölçüldü 2026-09-20, S2-22). Doğru kurulum: anahtarlar elindeyse `bulk-update` ucu (tek çağrı, tek
-transaction), satır başına sonuç ve satır başına yetki kararı gerekiyorsa **iş akışı + döngü**
-(liste → her satır için `microservice` adımı → özet). Akış içinden yazmak yetki YÜKSELTMEZ: her
-satır çağıranın kimliğiyle denetlenir ve reddedilen satır ötekileri geri almaz. Reçete:
-`platform_guide('microservice')` §"Toplu güncelleme FİLTREYLE kurulmaz".
-
-## Sahiplik ve devir (ORG-006)
-
-Sahiplik alanları (`sys_owner_user_id` · `sys_owner_unit_id`) satır kapsamının dayanağıdır ve
-**satır yazma yolundan yazılmaz**: `row_create` bunları çağırandan ve pozisyonundan kendisi
-doldurur, `row_update` / toplu güncelleme gövdesinde görürse istek `400
-OwnershipFieldNotWritable` alır (2026-09-20 öncesinde sessizce düşüyordu, S2-7).
-
-Sahip değiştirmenin tek yolu **`row_reassign`**'dır:
-
-- Hedef satırlar `rowIds` ya da `filter` ile seçilir; hedef sahip `ownerUnitId` ve/veya
-  `ownerUserId`'dir. Yalnız `ownerUserId` verilirse birim o kişinin aktif birincil pozisyonundan
-  türetilir (pozisyonu yoksa satırın birimi olduğu gibi kalır).
-- Her satıra `REASSIGN` denetim kaydı düşer (eski sahip → yeni sahip); `entity_audit_trails` ile
-  okunur.
-- Hedef birim/kullanıcı var olmalı (birim ayrıca aktif olmalı), yoksa 404; tek çağrıda en çok 1000
-  satır devredilir.
-
-**Kimlik iki yol ayırır.** `row_reassign` öteki `row_*` araçları gibi bir **Studio** ucudur ve
-gateway'in platform kimliğiyle koşar — uygulama jetonu (`asUser`) orada geçmez, 401 alır. İzin
-`entity.reassign` ve **kapsamlıdır**, ama o kapsam ancak istekte bir uygulama öznesi varken
-hesaplanır. Uygulama kullanıcısının kendi kapsamıyla devretmesi için (ve kapsamı gerçekten
-ölçmek için) sistem operasyonunu kullanın: `systemOperation: 'entity.row.reassign'` olan bir uç
-açıp `microservice_execute { asUser }` ile çağırın. Kapsam kuralı orada işler ve kapsamı `unit` ya
-da `unit-tree` olan çağıran için **sahipsiz satır** (`sys_owner_unit_id` NULL) de kapsam içi
-sayılır — şubesi kapanan kayda başka türlü kimse ulaşamazdı.
-
-**Sistem operasyonunun izni** katalogdaki `permission`'dır (`microservice_system_operation_list`);
-çalıştırıcı onu işlemden önce karar motoruna sorar. `permission` **boş** olan işlemde izni işlemin
-çağırdığı servis verir: süreç çalışma zamanı (`process.*`) görevi, bildirimi, vekaleti kişiye ve kayda
-göre çözer ve REST `bpm/*` ucuyla aynı görünürlüğü verir; yalnız `process.override.*` `process.manage`
-(kaynak `process:<id>`) ister. Modül kurulumu "Modül kullanıcısı" politikasına yalnız işaretli
-işlemlerin iznini yazar — `process.manage`'ı yazmaz, açık bir politikayla verin.
-
-**Kullanıcı silinince** satırları sarkık kalmaz: `user.delete` sahiplik taşıyan her entity'de o
-kullanıcının satırlarının `sys_owner_user_id` alanını NULL'a çeker, `sys_owner_unit_id`'yi
-**korur** (birimin sahipsiz kaydı olurlar, birim yöneticisi görmeye devam eder) ve entity başına bir
-`OWNER-RELEASED` denetim kaydı yazar (kaç satır, hangi kullanıcı). Silme çağrısına
-`transferToUserId` verilirse satırlar bunun yerine devralan kişiye ve birimine geçer ve kayıt
-`REASSIGN` olur; devralan var olmalı (404) ve silinen kişinin kendisi olamaz (400). Devralanın
-birimi, o kişinin **birincil aktif pozisyonunun** biriminden okunur — aktif pozisyonu yoksa
-`sys_owner_unit_id` hiç değişmez. Ajan yolu `user_delete { transferToUserId }`; aynı seçenek
-REST yolunda da vardır: `DELETE /{proje}/users/{id}?transferToUserId=…`. Sahipliğin çözülmesi
-kompleks projeye özgüdür: basit modelde silme çalışır ama bu adım hiç işlemez.
-
-## Kompleks projede kimlik middleware'i (ACC-006)
-
-Set-user'lı kimlik middleware'i (`platform_guide('middleware')` Tarif 1) kompleks projede gereksizdir, bağlı
-kalırsa da etkisiz değildir: platform oturumu kurar ve uç yolunda `user`'ı doldurur, ama bağlı middleware'ler
-zorlama modundan bağımsız **her modda koşar** ve reddedebilir; set-user adımı ya da yanıttaki `user`
-platformun `user`'ını **ezer**. Karar motoru özneyi oturumdan okur; ezilen `user` ise ifadelerde ikinci bir
-doğruluk kaynağı olur. Kimlik middleware'ini uçların ve sayfaların `middlewareIds`'inden çıkarın. Gateway
-`set-user` taşıyan middleware yazımında uyarır (warn). Ayar setter'ı gibi kimlik dışı middleware'ler serbesttir.
-
-## Eski rol listeleri (ACC-008)
-
-`page.roleIds` ve `microservice.roles` kompleks projede **karar girdisi değildir**: `enforce`'ta tek kapı
-karar motorudur ve platform bu listeyi hiçbir modda yetki için okumaz — liste yalnız `triggerSource.roles`'a
-geçer, yani ona anlam veren tek şey `Authorized(user.roles)` çağıran bir middleware'dir (K-29). Yetkiyi
-`access_policy_create` + `access_matrix_save` ile verin ve listeyi boş bırakın; gateway dolu listede uyarır
-(warn, çünkü `off` ve `shadow` modunda eski davranış sürer) ve Studio kompleks projede rol seçicisini zaten
-çizmez.
-
-**Kullanıcıya DOĞRUDAN atanan rol de yetki vermez** (2026-09-21, S-15). Özne kurulurken roller
-kompleks projede **yalnız pozisyonlardan** gelir (`AppSubjectResolver.ResolveAsync`): `user_roles`
-satırı — `PUT /{proje}/users/{id}` ile verilen eski yol — özneye hiç girmez, `auth/me`'de rol olarak
-sayılmaz ve o rolün politikaları uygulanmaz. "Kullanıcının rolü pozisyonundan gelir" cümlesi artık
-bu yolu da kapsıyor: koltuğu gişe olan bir kullanıcıya temsilci rolü atanırsa **yalnız gişe** sayılır,
-hiç koltuğu olmayan kullanıcı ise rolsüzdür ve her kapsamlı grant'ten reddedilir. Birleşim yalnız
-**basit** projede sürer. 2026-09-19'da ölçülen eski davranış (ikisi de sayılıyordu) artık geçerli
-değildir. Basit → kompleks dönüşümünde kimin yetki kaybedeceğini `access_model_preflight`
-`usersWithDirectRoles` sayar; o kullanıcılar dönüşümden önce `user_position_replace` ile koltuğa
-oturtulur.
-
-Bunun tek istisnası **projeyi açan kullanıcıdır**: koltuğu olmasa da yetkilidir, çünkü `system-admin`
-politikası ona ayrıca `subjectType: 'user'` ile atanır (§Atama). Kurucu dışında koltuksuz kimse
-yetkili değildir — "neden göremiyor?" sorusunda ilk bakılacak yer hâlâ `user_position_list`'tir.
-
-## Hatalar
-
-| Anahtar | Durum | Ne yapmalı |
-|---|---|---|
-| `SystemEntityWriteNotAllowed` | 400 | Organizasyon/erişim tablosuna genel satır yazımı (ORG-001) — Studio ya da `access_policy_*` |
-| `AccessPermissionUnknown` | 400 | İzin slug'ı katalogda yok — `access_permission_list` |
-| `AccessResourceTypeMismatch` | 400 | Anahtar iznin tipiyle başlamıyor |
-| `AccessResourceUnknown` | 400 | Yeni gelen anahtar katalogda yok — `access_resource_list` |
-| `AccessScopeNotSupported` · `AccessFieldAccessNotSupported` | 400 | Kapsam/alan erişimi o izinde yok (ACC-001) |
-| `AccessDenyFieldAccessNotSupported` · `AccessConditionRequiresScope` · `AccessSubordinatesLineRequiresSubordinatesScope` | 400 | Grant biçimi (ACC-001) — deny kapsam taşıyabilir, alan erişimi taşıyamaz |
-| `AccessOverrideRequiresUserWithEndDate` | 400 | `overridesDeny` yalnız `user` öznesi + dolu `endsAt` (ACC-009) |
-| `AccessOverridePermissionRequiredException` | 403 | İstisnayı açmak/genişletmek ya da istisna taşıyan politikanın grant'lerine dokunmak `access.override.manage` ister (ACC-009) |
-| `AccessConditionInvalidException` | 400 | Koşul alanı/işleci/değeri (ACC-001 · ACC-002) |
-| `AccessScopeRequiresOwnerFields` | 400 | Entity'de sahiplik alanı yok (ACC-003) |
-| `AccessAssignmentDescendantsRequiresUnit` · `AccessAssignmentPeriodInvalid` · `AccessSubjectMissing` | 400 / 422 | Atama biçimi |
-| `AccessPolicySlugDuplicate` | 409 | Slug projede tekil |
-| `OrganizationPositionSeatOccupied` | 409 | Tek koltuklu pozisyonda çakışan ikinci kalıcı atama (ORG-003) — vekâlet için `assignmentType: 'acting'`, kalıcı ikinci kişi için pozisyonu `isMultiSeat` yapın |
-| `RevealReasonTooShort` | 400 | Gerekçe projenin asgarisinin altında (`revealReasonMinLength`, ACC-010); deneme `REVEAL-DENIED` olarak kaydedilir |
-| `EnforcementOffRequiresConfirmation` | 409 | `off`'a geçiş korumalı alanları herkese açar — bilinçliyse `confirm: true` |
-| `ProtectionFieldTypeNotSupported` · `ProtectionDisplayFieldNotAllowed` | 400 / 422 | Korunamayan alan (PROT-003) |
-| `ProtectionDerivedSourceInvalid` · `ProtectionDerivedRuleInvalid` | 400 / 422 | Türetme kuralı (PROT-004) |
-| `ProtectionOperatorNotAllowed` · `ProtectionSortNotAllowed` | 400 | Korumalı alanda arama/sıralama (PROT-001 · PROT-002) |
-| `ProtectionChangeNotAllowed` | 400 | Var olan alanın koruması — `entity_protection_update` |
-| `ProtectionMigrationInProgress` | 409 | Koruma işi sürüyor — `import_status`, gerekirse aynı çağrıyı tekrarla |
-| `ProtectionKeyUnavailable` | — | Ortamda anahtar yok (insan işi) |
-| `AppSessionRequiredException` | 401 | Oturum yok (kompleks + `enforce`) — parolasız `asUserId` (development) ya da `access_session_create` + `asUser` |
-| `AppSessionInvalidException` | 401 | Jeton geçersiz ya da süresi dolmuş — yeniden giriş |
-| `AppSessionRateLimitedException` | 429 | Giriş ya da reveal hız sınırı — bekleyin |
-| `CsrfTokenMismatchException` | 403 | Çerezli durum değiştiren istekte `X-ZY-CSRF` yok — Bearer (`asUser`) |
-| `ForbiddenException` | 403 | İzin reddi (mesaj izni adıyla söylemez) — `access_preview` |
-| `AccessQueryNotScopedException` | 403 | Ham SQL kapsamlı/korumalı tabloya dokunuyor — table kaynağı ya da `isUnrestricted` (ACC-005) |
-| `AccessFieldWriteDeniedException` · `AccessFilterDeniedException` · `AccessRevealDeniedException` | 403 | Alan erişimi — `access_preview` `fieldAccess` |