@appaflytech/zeyrek-ai-mcp 0.0.4 → 0.0.6

package/dist/resources/guides/expressions.md

@@ -15,7 +15,10 @@ Uydurma fonksiyon adı runtime'da `X is not defined` 500'üdür — yalnız bura
 **Değişkenler:** step çıktıları (`<stepAdı>.data`), middleware değişkenleri (`user`,
 `settings`, `permissions`… — `workflow_middleware_variables` ile keşfet), HTTP bağlamı:
 `cookie`, `header`, `queryString`, `body`, `triggerSource`/`context` (tetikleyen ucun
-type/name/roles/impersonatedUserId'ı). Workflow'da istek girdisi `input.`, automation'da
+type/name/roles/impersonatedUserId'ı). Gövde bir JSON **nesnesi** ise `body.alan` diye okunur,
+gövde bir JSON **dizisi** ise `body[0].alan` diye — 2026-09-04 öncesinde nesne gövde de diziye
+sarılıyordu ve `body.alan` sessizce `undefined` dönüyordu, bu yüzden gövdeye bakan yetki kapıları
+açık kalıyordu. Workflow'da istek girdisi `input.`, automation'da
 tetikleyen satır `row` / `previousRow` / `user`.
 
 **Fonksiyonlar (qm'de aktif kullanılanlar önce):**
@@ -57,6 +60,27 @@ tetikleyen satır `row` / `previousRow` / `user`.
 (motor tr-TR + UTC); automation zinciri istek başına workflow başına 10 koşumda
 `InfiniteLoopException` ile kesilir (sonsuz döngü koruması).
 
+> **İki ayrı sınır var ve önce KÜÇÜK olan konuşur.** `AutomationConsumer` automation'ı
+> çalıştırmadan önce `triggerCount > 2` kontrolü yapar (yani 3. tetiklemede keser);
+> `WorkflowContext.CheckProcessCount` ise workflow koşumunu 10'da keser. Yukarıdaki 10 yalnız
+> ikincisidir. Hata mesajı artık hangi automation'ın kaç kez tetiklendiğini ve sınırı söyler.
+>
+> **Kapıyı doğru yere koy:** sayaç, akışın ilk adımı koşmadan önce artar. Tetikleyen satıra geri
+> yazan bir automation'da `row.status !== previousRow.status` kapısını akışın içindeki bir
+> `condition` ADIMINA koymak koşumu saydırmayı sürdürür; aynı ifade `automation.condition`
+> alanında ise yeniden tetikleme hiç doğmaz ve sayaç artmaz (`RowConsumer.cs:130-143`).
+>
+> **Yanıltıcı `failed` DÜZELTİLDİ (2026-09-05).** Sayaç pas başına İKİ artıyordu: runner'ın kendi
+> 10'luk koruması (`CheckProcessCount`) ile tetikleme zincirinin sayacı aynı sözlüğü paylaşıyordu,
+> bu yüzden tetikleyen satırını güncelleyen her automation ikinci pasında `processCount: 3` ile
+> kesiliyordu — ölçümde 10 durum değişikliğinin **10'unda da**. İki sayaç ayrıldı; artık her pas
+> zinciri bir artırır: 1. pas kapıyı geçip yazar, 2. pas kapıya takılıp durur ve zincir `2`'de
+> biter. Ölçüm (aralıklı 10 güncelleme): 20 olay, hepsi `completed`, `failed` yok.
+>
+> Kalan tek durum bir YARIŞTIR: aynı satıra ara vermeden art arda güncelleme atılırsa bir zincir
+> önceki zincirin yazması havadayken başlayabilir ve seyrek bir `failed` düşebilir (10 hızlı
+> güncellemede 1). Satır başına tek akış bekliyorsanız güncellemeleri aralıklandırın.
+
 **Tohum parola üretmek istiyorsan** hash'i platformun kendisine ürettir: parolayı düz metin alan
 bir workflow yazıp `crypto.SHA256.encode(input.password)` sonucunu döndür, ya da kullanıcı kaydını
 açan ucu kullan. Dışarıda kendi SHA-256'nı hesaplayıp yazarsan giriş akışı **hiçbir zaman**
@@ -73,14 +97,32 @@ dalından devam eder.
 | `Page` | `Page.user`, `Page.variables`, `Page.components`, `Page.properties`, `Page.queryParams`, `Page.authorized(roles)` |
 | **Komponent adları** | Her komponent adıyla doğrudan değişkendir: `specialties_table.rows = data` hem prop'u yazar hem UI'ı günceller (change event). Addaki `-` silinir: `tickets-table` → `ticketstable` |
 | `state.page` / `state.app` | Kalıcı state (oku/yaz): `state.page.selectedId = row.id`. **Tanımlı değişkenler de buradadır:** `variable_create` ile yazılan her `key` sayfa düzeyinde `state.page.<key>`, uygulama düzeyinde `state.app.<key>` olur; `value` nesneyse alanlarına inilir (`state.page.MyTest.isActive`) |
-| `Steps` | Adım çıktıları: `Steps.load_specialties` (stepId ile); `error` = son hata |
+| `Steps` | Adım çıktıları: `Steps.load_specialties` — anahtar adımın **ADIdır**, `stepId` değil (`setStorage(task.name, …)`); `Steps.<adım>.error` o adımın hatası — ama YALNIZ HTTP durum metnidir (401 için `'Unauthorized'`), ucun mesajı değil. `Steps.error` ise hata akışı için doldurulur (`onError` koşmadan önce `setStorage('error', …)` yapar) ama **YAPIŞKANDIR**: storage sayfa başına tek `FlowMachine`'de yaşar ve `'error'` anahtarı hiç temizlenmez, yani ilk hatadan sonra o sayfadaki her akışta dolu kalır — normal akışta `Steps.error` okuyan bir ifade bayat hatayı görür ve şekli `{ message, code, step: { id, name, type, data } }`'dir: kullanıcıya gösterilecek metin `Steps.error.message`'tır (`err.response.data.message`, boşsa durum metni). **Başarılı bir adımda `Steps.<adım>.data` gerçek bir `Array`'dir** — `.map` · `.filter` · `.concat` · `.length` çalışır. Adım HATA dönerse aynı alan ucun hata gövdesini taşır; aşağıdaki kutuya bakın |
 | `self` · `item` · `Row` / `RowIndex` | Tetikleyen komponent (yazılabilir) · repeater/tablo satırı (yazmak satırı günceller) |
 | `event` | `{name, data, source: {id, props}}` |
 | `cookie` | `cookie.get(name)` / `cookie.set(name, value, {expiresInHours, path})` / `cookie.remove(name)` — tarayıcı cookie'si |
 | `setComponentProperty(name, key, value)` / `getComponentProperty(name, key)` | fonksiyon alternatifi |
 | `LocalStorage` · `Widget` · `params` | yerel veri · widget bağlamı · olay parametreleri |
+| `t(key)` | Çeviri anahtarını çözer: aktif dil → projenin varsayılan dili → anahtarın kendisi. Boş string de "eksik" sayılır. Sözlük `machine.context.state.translations`'tan gelir; dil `language-selector` ile değişince bir sonraki çağrı yeni dili görür. **Yalnız UI flow kodunda vardır** — backend ifadelerinde karşılığı `Loc()`'tur (`platform_guide('workflow')`) | `t('home.welcome')` |
 | `log(...)` | console (proxy'leri temizler) |
 
+> **`.map is not a function` bir dizi sözleşmesi sorunu DEĞİL, düşmüş bir adımdır.**
+> Ölçüldü 2026-09-05 (`f09-repro/probe`, yerel kurulum): başarılı bir microservice adımında
+> `Steps.<adım>.data` `[object Array]`'dir, `Array.isArray` true döner ve `.map`/`.filter`/
+> `.concat` çalışır. Adım hata döndüğünde (401, 500, geçersiz parametre) motor aynı alana ucun
+> **hata gövdesini** yazar — o bir nesnedir, dizi metodları yoktur ve
+> `(Steps.x.data || []).map is not a function` tam olarak burada çıkar. 2026-09-05 koşusunda
+> boş kalan şirket filtresinin sebebi buydu: adım korumalı bir uca 401 ile düşmüştü.
+> **Teşhis sırası:** önce `Steps.<adım>.error`'a bak, sonra ifadeyi suçla. Bir dizi bekliyorsan
+> `Array.isArray(Steps.<adım>.data)` ile koru; boş listeye düşmek, hata gövdesi üzerinde
+> dönmekten iyidir.
+>
+> **Patlayan ifade artık sessiz değil (F-09).** Hedef prop yine YAZILMAZ — bozuk bir değeri
+> yazmak durumu kötüleştirir — ama akış bunu yapısal olarak bildirir: `page_screenshot` yanıtı
+> `runtimeErrors` taşır ve hangi komponentin hangi prop'unun yazılamadığını (`element` ·
+> `property`) söyler. Aynı defter hata dönen microservice adımlarını da kaydeder. **Kare
+> "çalışıyor" görünse bile `runtimeErrors` doluysa o adımlar işini YAPMAMIŞTIR.**
+
 **Prop'a doğrudan ifade bağlama (`{{ }}`):** akış kurmadan bir prop'u ifadeye bağlamak için
 prop `type: 'code'` olur, **ifade `ref` alanına `{{ }}` içinde** yazılır, `data` tasarım zamanı
 değerini taşır:

package/dist/resources/guides/external-component.md

@@ -127,3 +127,12 @@ Platform, npm paketi olmadan servis eder:
 
 `external_component_scaffold` bu sözleşmeye uyan bir iskeleti yerel dizine
 zaten yazar; kit, iskeleti elle düzenlerken referans olarak işinize yarar.
+
+## Backend doğrulama sınırları (EXT-001)
+
+`external_component_publish` manifest'i kayıt ucuna gitmeden denetler (block): `protocolVersion`
+1; `definition.blocks` en az bir blok; `definition.props[].name` DOM/host adı olamaz
+(`attributes`, `children`, `class`, `className`, `id`, `name`, `style`, `slot`, `innerHTML`…) ve
+`zx`/`on` ile başlayamaz; `definition.props[].type` platform sözlüğünden (`text`, `number`,
+`switch`, `dropdown`, `object`, `array`, `views`, `component`…). Slug deseni `^x-[a-z][a-z0-9-]*$`
+ve 2 MB paket sınırı tool'un kendisinde denetlenir. Tam liste: `ngapps://rules/backend-constraints`.

package/dist/resources/guides/getting-started.md

@@ -7,21 +7,41 @@ Bağımlılıklar bu sırayı zorunlu kılar; atlama:
 ```
 1. project_create        (application zorunlu: ilk application projeyle birlikte açılır;
                           application slug'ı ORG GENELİNDE tekildir — 'web' büyük olasılıkla
-                          doludur, 409'da project_list ile mevcut slug'ları tara)
+                          doludur, 409'da project_list ile mevcut slug'ları tara.
+                          DİL: gateway create'ten sonra projenin dillerini kurar — verirsen
+                          languages/defaultLanguage'ı, vermezsen tek dillik ['en'] tohumunu
+                          (PRJ-003). Ürünün dili farklıysa BURADA yaz; dilsiz projede yazılan
+                          çeviriler runtime'da ham anahtar olarak çizilir, bkz.
+                          platform_guide('translation'))
 2. project_get           (environment id'leri + application id burada)
-3. datasource_list       (her projede built-in datasource hazır gelir — çoğu iş için yeterli;
-                          dış DB gerekiyorsa datasource_test_connection → datasource_create)
+3. datasource_list       (built-in datasource PROJEYLE BİRLİKTE doğar: project_create ayrı bir
+                          veritabanı, her environment için ayrı bir şema ve o veritabanına bağlı
+                          built-in datasource açar. Entity'lerini oraya aç — listede
+                          isBuiltIn: true olan kayıt odur, silinemez.
+                          TEMİZ BİR İSİM ALANI İSTİYORSAN YENİ PROJE AÇ, yeni datasource değil:
+                          tek datasource içinde önek/şema ayırmanın yolu YOK.
+                          datasource_create YALNIZ kullanıcı kendi veritabanını verdiğinde
+                          çağrılır ('host/port/kullanıcı/parola şunlar'); built-in'in parolası
+                          hiçbir tool'dan okunamaz ve okunması gerekmez. Dış bir DB'ye kurulan
+                          entity users'a ilişki KURAMAZ — kimlik gerektiren her uygulama
+                          built-in'de kurulur, bkz. platform_guide('entity'))
 4. entity_list           (ÖNCE BAK: platform her projeye hazır entity'ler açar — users (kimlik:
    (applicationId'siz)    email/password/first_name/last_name), roles, user_roles, permissions.
                           applicationId VERİRSEN bunlar listede GÖRÜNMEZ. Ürünün "müşteri" /
                           "öğrenci" / "üye" kavramı için sıfırdan bir kimlik tablosu açmadan önce
-                          users'ı gör — bkz. platform_guide('entity') §'Hazır entity'ler')
+                          users'ı gör — bkz. platform_guide('entity') §'Hazır entity'ler'.
+                          ROL: role_create diye bir tool YOK ve olmamalı — roles sıradan bir
+                          entity'dir. Projeyle gelen roller yetmiyorsa yol entity_get('roles') +
+                          kendi microservice ucun; sayfaya bağlama page_create roleIds ile)
 5. entity_create         (applicationIds Studio'nun application bazlı entity listesi içindir —
                           boşsa satır uçları ÇALIŞIR ama entity Studio listesinde görünmez;
                           önce ilişkisiz gövdeler, sonra update/patch ile ilişki alanları —
                           bkz. platform_guide('entity'))
 6. row_create            (test verisi; alan tanımlarını row_list ile doğrula)
-7. dto_list / dto_create (workflow/automation'ın parameterDtoId/returnDtoId sözleşmeleri;
+7. dto_list / dto_create — çocuk alanın `type` değeri **`"string"`**'tir; `"text"` yazmak sessizce
+   `object`'e çevrilir ve DTO bozuk kurulur (ölçüldü 2026-09-05, teşhis platformun kendi ürettiği
+   bir DTO'yu okuyarak yapıldı). Şablon için var olan bir DTO'yu `dto_get` ile alın.
+   (workflow/automation'ın parameterDtoId/returnDtoId sözleşmeleri;
                           platform entity başına DTO üretir — önce dto_list ile ara)
 8. workflow_create       (type: 'middleware' — YALNIZ ihtiyaç varsa; bkz. aşağıdaki karar tablosu.
                           Kuruyorsan guard + 'user' değişkeni; uçlara middlewareIds ile
@@ -51,8 +71,17 @@ kilitler:
 2. O workflow'un ucu, kimlik kurulduğu için `middlewareIds` ile auth middleware'ine bağlıdır.
 3. Auth middleware'i token'ı **çerezten** okur; ortada henüz kullanıcı yoktur, dolayısıyla token
    da yoktur.
-4. **Yeni projede `users` tablosu BOŞ gelir** — `organization_sync_users` Studio operatörünü
-   otomatik kopyalamaz.
+4. **Yeni projede `users` tablosu BOŞ gelir.** Studio operatörü (`admin@…`) organizasyon
+   kullanıcısıdır, uygulamanın kullanıcısı DEĞİLDİR; kimse onu otomatik kopyalamaz.
+
+**Bu bir platform boşluğudur, kısa yolu yoktur.** İlk kullanıcıyı açmanın desteklenen tek yolu
+aşağıdaki bootstrap desenidir: geçici bir uç aç, kullanıcıyı yaz, ucu hemen sil. Bakım/migration
+uçlarını (`/organizations/sync-users` gibi `Sync*` uçları) **kullanma** — onlar ürün yüzeyinin
+parçası değildir, özellik geliştirirken veri düzeltmek için yazılmışlardır ve kaldırılmaktadırlar.
+Gateway de onları araç olarak yayınlamaz.
+
+Bu tur, kimlik kuran her yeni projede ödenmek zorunda: iki koşuda da (09-02 ve 09-04) `users`
+boş bulundu ve ikisi de bu deseni elle kurdu.
 
 **Bootstrap deseni** (crm koşumunda uygulandı):
 
@@ -107,3 +136,44 @@ koda baktığını gizlemek yerine raporlamak.
 - microservice → `microservice_execute`, beklenmedik sonuçta `microservice_debug`
 - workflow → `workflow_preview`; automation → `automation_trigger` + `automation_histories`
 - "API 200 döndü" tek başına bitti saymaz; politika bulgularını (`policyFindings`) oku ve gereğini yap
+
+
+## Yazdıktan sonra `silentlyDropped` alanına bak
+
+Platformun bir alanı **hatasız yutması** bu depodaki en pahalı hata sınıfı: çağrı 200 döner,
+`appliedPatch` uygulandığını söyler, `*_get` değeri geri verir ve o alan hiç işe yaramaz.
+2026-09-05 koşusunda kaybedilen sürenin çoğu sekiz böyle çağrıdan geldi.
+
+Gateway yazma tool'larında gönderdiğin gövdeyi kaydedilenle karşılaştırır ve farkı yanıta
+`silentlyDropped` olarak koyar (`microservice_*`, `query_*`, `flow_*`, `dto_*`, `workflow_*`,
+`layout_create`, `page_schema_patch`). Boş değilse o alan **kaydedilmemiştir**:
+
+```jsonc
+"silentlyDropped": [
+  "steps[stepId=sync_filters].args.expression: gönderilen \"state.page.month = …\" ↔ kaydedilen yok"
+]
+```
+
+Diff dizi öğelerini indeksle değil KİMLİKLE eşler (`stepId`, `elementId`, `name`, `id`), çünkü
+platform diziyi kendi sırasında geri döndürür. Diff üretilemeyen tek durum, yanıtın kayıt değil
+kabul gövdesi olmasıdır; o zaman alan hiç görünmez ve doğrulamayı `*_get` ile kendin yaparsın.
+
+## `unmappedMembers`: anahtarın komutta HİÇ olmadığını söyler
+
+İki kanal aynı yanıtta çıkabilir ve **kanıt güçleri farklıdır**:
+
+- `silentlyDropped` bir SEZGİSELDİR: gönderdiğin gövdeyi kaydedilenle karşılaştırır. Platform bir
+  alanı başka adla saklarsa ya da id'yi yeniden atarsa yanlış alarm verebilir.
+- `unmappedMembers` OTORİTERDİR: o anahtar gönderdiğin komutun şemasında **yoktur**. Platform onu
+  hata vermeden yok sayar, yani yazdığını sandığın değer hiç kaydedilmez.
+
+```jsonc
+"unmappedMembers": ["indexes[0].isUnique"]
+```
+
+Bu satırı gördüğünde alanı silme — **doğru adı bul**. Şema `ngapps://schemas/<Komut>` altındadır
+(ör. `ngapps://schemas/UpdateEntityCommand`) ve gerçek maliyeti ölçülmüştür: `unique` yerine
+`isUnique` yazılan bir index UNIQUE OLMADAN kurulur ve çağrı 200 döner.
+
+Kanal yalnız senin yazdığın anahtarları bildirir; gateway'in bir kaydı okuyup geri yazarken
+taşıdığı alanlar (`slug`, `datasourceId`, `audit` gibi) burada görünmez.

package/dist/resources/guides/layout.md

@@ -12,10 +12,22 @@ kutusu layout modülünde süzülmez — tüm katalog kullanılabilir.
 
 **2. Şema alanının adı `schema` değil `views`.** (LAY-001)
 
-**3. Micro-op hattı YOKTUR.** `page_schema_patch`'in layout karşılığı yok (backend'de
-`PATCH /layouts/.../schema` ucu yok). Değişiklik `layout_update` ile yazılır; gateway kaydı
-önce okur ve yalnız verdiğin alanları değiştirir, `views` göndermezsen ağaç korunur.
-Okumak için `layout_schema_get` (summary kipi hedef bulmak için yeterlidir).
+**3. Micro-op ucu yok, ama `PATCH /layouts/{app}/{id}` var.** `page_schema_patch`'in birebir
+karşılığı yoktur (`PATCH /layouts/.../schema` ucu yok); onun yerine platform genel bir JSON Patch
+ucu verir ve `layout_patch` onu kullanır: layout'u okur, JSON Patch'i ve kendi normalizasyonlarını
+uygular, doğrulamadan geçirir ve **farkı** `{ baseVersion, ops }` olarak yazar — tam gövde PUT'u
+atılmaz. Böylece tek bir başlık düzeltmesi için 12 düğümlük ağacı yeniden göndermezsin (ölçüm:
+09-04 koşusu Y-25). Yol İNDEKS yerine SEÇİCİ alır:
+`/views/0/children[elementId=baslik]/props/content/data`.
+
+**Sürüm ve 409.** Okunan kaydın `version` alanı `baseVersion` olarak gider. Sen okuduktan sonra
+başka biri yazdıysa platform **409** döner ve HİÇBİR op uygulanmaz; doğru tepki "aynı op'ları
+tekrar göndermek" değil, `layout_schema_get` ile yeniden okuyup patch'i güncel hâle göre kurmaktır.
+`version` bir **string**tir (mikrosaniye cinsinden zaman damgası, JavaScript'in güvenli tam sayı
+sınırının üstünde) — sayıya çevirme, olduğu gibi geri gönder. `expectedUpdatedAt` verirsen gateway
+ayrıca istek gitmeden önce yerel bir kontrol daha yapar. Tam ağacı kendin yazacaksan `layout_update`;
+`views` göndermezsen mevcut ağaç korunur. Okumak için `layout_schema_get` (summary kipi hedef bulmak
+için yeterlidir).
 
 **4. TEK slot.** Sayfa şeması **her** slot'a ayrı ayrı kopyalanır — iki slot, sayfayı iki
 kez çizer ve `elementId`'leri tekrarlar. (LAY-002 / LAY-006)
@@ -45,7 +57,9 @@ runtime hem Studio tuvali bölgeleri 12 kolonluk ızgarayla yerleştirir.
 **7. Mobilde flex YIĞILMAZ.** Runtime'ın mobil kuralı yalnız ızgara özelliklerini ezer.
 Telefonda alt alta düşmesi gereken satırı `layout:'grid'` ile kur; `layout:'flex'` +
 `direction:'row'` telefonda da yan yana kalır (375px'te ölçüldü: ızgara çocukları 375/375px
-alt alta, flex çocukları 49/310px yan yana).
+alt alta, flex çocukları 49/310px yan yana). Not: `wrap` varsayılanı artık açık (2026-09-01) —
+sığmayan çocuk alt satıra SARAR ama bu ızgara yığılması değildir; dar ölçülü çocuklar yan
+yana kalmaya devam eder.
 
 **8. Doğrulama tek yerden:** `page_runtime_get`. Layout'un kendi serve URL'i yoktur —
 gerçek çıktıyı, layout'a bağlı bir sayfanın runtime paketinde görürsün (slot yerleşimi
@@ -67,9 +81,12 @@ container  isWrapper:true  heightType:'fill'  layout:'flex' direction:'row' gap:
    └ slot       heightType:'fill'                                        block w12 y6
 ```
 
-- **Genişlik kolon payıdır:** yan menü `w:2` = 12'de 2 → 1440px tasarım genişliğinde 240px.
-  Sabit piksel istiyorsan `appearance.widthPx: 240` (yalnız flex çocuğunda okunur; ızgara
-  kabında okunmaz).
+- **Genişlik `appearance.widthType`'tan gelir (2026-09-01); kolon payı fallback'tir.**
+  Yan menü için `widthType: 'fixed'` + `widthString: "240px"` (serbest CSS uzunluğu:
+  `"50%"`, `"10vw"`, `calc(...)` de geçer; yalnız flex kabın çocuğunda okunur, mutlak
+  ızgara kabında okunmaz). `'fill'` kabın tüm genişliğini alır, `'auto'` içeriğe oturur;
+  `widthType` HİÇ yazılmazsa `w:2` = 12'de 2 → 1440px tasarım genişliğinde 240px payı
+  geçerlidir. String yalnız `'fixed'` modda okunur — tek başına `widthString` ölüdür.
 - **Yükseklik `fill`'dir**, `size.h` değil: kök ekranı doldurur, yan menü ve içerik sütunu
   kökün bıraktığını, slot da üst şeritten artanı alır. Slot'un grid satırı ayrıca açık
   uçludur (`y / auto`), yani sayfa uzadıkça slot uzar.
@@ -115,6 +132,29 @@ bağlantı nesnesi ya da tam yol).
 // flex anlamının devreye girmemesi.
 ```
 
+## Çeviri: header/sidebar etiketini anahtara bağlamak
+
+Layout'un `views` ağacındaki bir etiketi çeviriye bağlamak için **bütün ağacı yeniden yazma**.
+`layout_patch` `set_prop_type` micro-op'unu tanır ve prop'un tipini yerinde değiştirir:
+
+```jsonc
+{ "op": "set_prop_type", "target": "app_header_title", "prop": "content",
+  "propType": "translation", "ref": "layout.header.title" }
+```
+
+- Anahtar **`ref`'te** yaşar, `data`'da değil — runtime `data`'yı her turda çözümlenmiş değerle
+  ezer. `ref` boşsa gateway isteği göndermeden reddeder.
+- Mevcut statik metin `data`'da yedek olarak KALIR, böylece Studio canvas'ında boş kutu görünmez.
+- `set_prop_type` ile JSON Patch aynı `ops` listesinde karışık verilebilir; micro-op'lar önce
+  uygulanır, sonra patch yolları çözülür.
+- Aynı op sayfa tarafında `page_schema_patch` ile çalışır — sözleşme birebir aynıdır. Anahtarları
+  `translation_list` ile bulun; fallback zinciri ve `t:` doğrulama mesajı sözleşmesi
+  `platform_guide('translation')`'da.
+
+> Layout'un diğer micro-op'ları YOKTUR: `add_component`, `remove_component`, `replace_prop` ve
+> arkadaşları yalnız sayfa hattındadır. Layout'ta düğüm eklemek/silmek için JSON Patch ya da
+> `layout_update` kullanılır.
+
 ## Sayfayı layout'a bağlama
 
 `page_update` ile `layoutId`. Bağlı sayfanın kendi şeması slot'un içine girer; sayfanın
@@ -140,8 +180,11 @@ bunlardan biri olabilir:
 (`mapPageLayoutToPreview`), `packages/ng-apps-ui/src/shared/render/render.functions.ts`
 (`resolveNodeBoxStyle` — slot'un `y / auto` satırı, flex çocuk genişliği),
 `packages/ng-apps-ui/src/shared/render/RenderComponent.svelte` (mobil media kuralı),
-`packages/ng-apps-screen-builder/src/flex-layout.ts` (`getFlexChildStyle` — `widthPx` ve
-`heightType:'fill'` dalı; tuval ve runtime aynı fonksiyonu okur),
+`packages/ng-apps-screen-builder/src/flex-layout.ts` (`getFlexChildStyle` — `widthType`
+fill/fixed/auto dalları, `normalizeCssSize` kabul kuralı; tuval ve runtime aynı fonksiyonu okur),
+`apps/studio/src/features/page/components/appearance/appearance-size.functions.ts` (panelin
+mod↔string yazım kuralları), `apps/studio/src/components/screen-builder/quick-stack.functions.ts`
+(Quick Stack iskeleti; `docs/features/quick-stack.md`),
 `apps/studio/src/features/layout/layout.functions.ts` (`getDefaultLayout` — Kural 5a/5b'deki iskelet),
 `docs/components/layout-composition.md`, `docs/specs/2026-08-28-free-layout-responsive-design.md`,
 `docs/issues.md` ARC-031 / BE-002 / CQ-143.

package/dist/resources/guides/microservice.md

@@ -43,23 +43,119 @@ servis formunda görünür ve `microservice_get` outline görünümünde geri ok
      (varsayılan 20) ve `offset` alır. Kurulum sırası: `view_create` (aranacak tablo/alanlar +
      analizör) → `view_rebuild` → `source:'view'` microservice. Satış özeti / top-N gibi
      rapor işleri view'e DEĞİL raw query'e aittir (`query_create` + query kaynaklı uç).
+     **Alan kapsamı:** view kaynaklı uç `selectFields` boşken yalnız view'ın indekslediği
+     alanları + birincil anahtarı döndürür. İndekslenmemiş kolon (maaş, TCKN) kendiliğinden
+     gelmez; daha fazlasını istiyorsan `selectFields` ile açıkça iste (İK koşusu M-7).
    - `workflow`: çok adımlı iş mantığı gerekiyorsa microservice'i workflow'a bağla
-     (`workflowId`).
+     (`workflowId`). **Yanıtı açık bir DTO sözleşmesine bağlamanın tek yolu da budur** — DTO
+     alanları uçta değil akıştadır; bkz. aşağıda §"Yanıt sözleşmesi (DTO) uca DEĞİL workflow'a
+     bağlanır".
    - `query`: yalnız ham SQL gerçekten şartsa. Politika lint'i her query kullanımında gerekçe
      ister (MS-002, warn).
-2. **`selectFields` asla boş bırakılmaz.** Boş = platform TÜM alanları döndürür; join'li
-   sorguda maliyet katlanır. Join varken boş bırakmak block'tur (MS-001).
+
+     > **BOŞ STRING PARAMETRE `NULL`'A ÇEVRİLİR — sorgu sessizce 0 satır döner.** Platform
+     > önizleme/çalıştırma parametrelerini normalize ederken boş ya da yalnız boşluktan oluşan
+     > değeri `null` yapar. `WHERE company_id = @company` yazıp `company: ''` gönderirsen koşul
+     > `= NULL` olur ve **hiçbir satırla eşleşmez**: HTTP 200, boş sonuç, hata yok, uyarı yok.
+     > Üç koşuda üst üste ölçüldü (09-02, 09-04 birinci ve dördüncü koşu) ve üçünde de teşhis
+     > ancak `SELECT (@p IS NULL)` gibi bir sonda ile yapılabildi.
+     >
+     > **Parametre listesi ZORUNLUDUR.** `@token` kullanan bir sorguyu `query_create` ile
+     > kaydederken her belirteci `parameters` içinde `{ name, type, value }` olarak bildir. Eksik
+     > bırakılırsa istek **400** döner ve mesaj hangi belirtecin bildirilmediğini adıyla söyler.
+     > (2026-09-04'ten önce aynı durum `500 "Please correct the query syntax."` veriyordu ve SQL'i
+     > suçluyordu; kaydetme yolu gövdeyi önce bir kez çalıştırıp yanıt şemasını ürettiği için
+     > bağlanmamış belirteç sözdizimi hatası gibi görünüyordu.) `value` yalnız kayıt anında
+     > kullanılır: SQL doğrulanır ve `returnScheme` ondan üretilir.
+     > Yorum satırındaki `{{ad}}`/`@ad` belirteçleri parametre sayılmaz — kaydetme yolu
+     > sorguyu yorumlarından arındırdıktan sonra tarar. SQL çalıştırılamazsa kayıt **yine de**
+     > oluşur: `returnScheme` boş kalır ve yanıttaki `message` nedeni söyler; SQL'i düzeltip
+     > `query_update` ile kaydet.
+     >
+     > "Filtre yok" demek istiyorsan iki doğru kalıptan birini kullan:
+     > `(@company IS NULL OR c.company_id::text = @company)` ya da bir sentinel değer
+     > (`'all'`) ve SQL'de ona bakan bir dal. Aynı davranış workflow query adımında da geçerli;
+     > oradaki anlatım `platform_guide('workflow')` "Query adımı" bölümünde.
+     >
+     > **KAPSAM UYARISI: query kaynaklı ucun parametreleri ÇAĞRIDAN gelir.** Middleware'in
+     > kurduğu `user` bu yola girmez — kimlik/tenant kapsamını gövdeye yazan bir uç
+     > sahtelenebilir (ölçüldü 2026-09-07). Kapsam sunucuda zorlanacaksa sorguyu bir workflow
+     > query adımından çağır; reçete aşağıda §"Kimlik kapsaması × uç kaynağı".
+2. **`selectFields` asla boş bırakılmaz.** Boş = platform TÜM alanları döndürür (view kaynaklı
+   uçta: yalnız view'ın indekslediği alanlar + birincil anahtar); join'li sorguda maliyet
+   katlanır. Join varken boş bırakmak block'tur (MS-001).
 3. **Join'ler ilişkilerden türetilir.** `sourceParameters.joins` öğesi:
    `{ alias, entityId, fieldId, path, joins }` — iç içe join mümkündür. Her join'in getirdiği
    alanlar da `selectFields`'ta `{ alias, fieldId, path, fieldSlug }` ile açıkça seçilir.
    **`path` boş bırakılamaz** — Studio join'li seçimleri yalnız `path` üzerinden eşleştirir
    (aşağıdaki bölüme bak).
+3b. **Kayıtlı ucu önizleme:** `microservice_preview` tam gövde istemez — `id` verirsen gateway
+   tanımı platformdan çeker ve yalnız `previewParameters`'ı senden alır (09-04 Y-09). Şekil
+   `{ body: [{…}] }` · `{ queryString: {…} }` · `{ routeParams: {…} }`; **tanımsız bir şekil
+   sessizce yutulur** ve bütün sayaçlar 0 döner (09-02 M-2).
 4. **HTTP sözleşmesi:** `type: 'rest-api'` + `httpMethod: get|post|put|delete` + `url`
    (route şablonu). Zamanlanmış işler `type: 'schedule-job'`, kuyruk tüketicileri `consumer`.
+4b. **`query_preview` yazma sorgusunu ÇALIŞTIRIR, GERİ ALIR ve BUNU SÖYLEMEZ.**
+   `INSERT`/`UPDATE`/`DELETE` önizlediğinde `affectedRowCount` **gerçek** sayıyı döndürür ama
+   transaction geri alınır ve tabloda satır kalmaz. **Yanıtta rollback işareti yoktur** — yalnız
+   `{ affectedRowCount, elapsedMilliseconds }` gelir (2026-09-07'de ölçüldü; `rolledBack` alanı
+   yalnız OKUYAN sorgunun yanıt şeklinde var ve orada hep `false`). Yani sayıya bakan çağıran
+   yazdığını sanır: 09-04 4. koşusunda 624 satırlık bir seed böyle "yazıldı" sanıldı. Kalıcı
+   yazma için sorguyu kaydedip query kaynaklı bir uçtan ya da workflow'dan çalıştır; kalıcılığın
+   tek kanıtı sonradan çekilen `row_list`'tir. **Var olan satırlardan türetilmiş satır üretmenin
+   uçtan uca reçetesi** (anahtar sözleşmesi dâhil) `platform_guide('entity')` §"Toplu ve
+   türetilmiş satır" bölümündedir; aynı davranış `platform_guide('workflow')` "Query adımı"
+   bölümünde de yazılıdır.
+
+4c. **Sayfalama toplamı `Total-Count` header'ından gelir.** Sayfalı bir uç kurduğunda toplam
+   kayıt sayısı gövdede değil header'dadır (`microservice_execute` yanıtında `headers` altında,
+   küçük harfle `total-count`). Tabloya bağlarken sayfa göstergesinin okuduğu sözleşme budur;
+   ayrıntı `platform_guide('page')` sayfalama bölümü. Alternatif olarak sorgunun kendisi
+   `COUNT(*) OVER()` ile toplamı satıra koyabilir — o zaman header'a hiç bağımlı kalmazsın.
+
 5. **Doğrulama akışı:** `microservice_preview` (kaydetmeden) → kaydet → `microservice_execute`
    (gerçek runtime yolu) → sonuç beklenmedikse **aynı parametrelerle `microservice_debug`** —
    adım adım executionItems ağacı döner.
 
+## Yanıt sözleşmesi (DTO) uca DEĞİL workflow'a bağlanır (MS-018, block)
+
+`returnDtoId` · `parameterDtoId` · `returnBehavior` · `parameterBehavior` **microservice
+komutunda yoktur** (`Create/UpdateMicroserviceCommand`). Gövdeye yazarsan platform 200 döner ve
+alanı sessizce düşürür: uç sözleşmesiz kalır, ne hata ne uyarı gelir (2026-09-09 koşusu `S-2`).
+Gateway bu gövdeyi artık MS-018 ile **platforma hiç göndermeden** reddeder.
+
+Yanıt şeklini kaynak belirler:
+
+| Kaynak | Yanıt şeklini ne belirler | Açık DTO sözleşmesi |
+|---|---|---|
+| `table` | `sourceParameters.selectFields` (+ join alanları) | yok |
+| `query` | sorgunun `returnScheme`'i — kayıt anında SQL'den üretilir | yok |
+| `view` | view'ın indekslediği alanlar + birincil anahtar (`selectFields` ile genişletilir) | yok |
+| `workflow` | akışın `returnDtoId` + `returnBehavior` sözleşmesi | **var** |
+
+Yani "yanıtın alanları şu DTO'dan olsun" diyeceksen uç **workflow kaynaklı** kurulur:
+
+1. `dto_list` ile mevcut DTO'yu bul (platform entity başına DTO üretir) ya da `dto_create` → `dtoId`
+2. `workflow_create` → `returnDtoId: dtoId` + `returnBehavior: 'object' | 'array' | 'primitive'`.
+   WF-002: `type:'workflow'` akışta `returnDtoId` **zorunludur** (yoksa akış `unready` kalır);
+   `returnBehavior`'ı boş bırakırsan gateway `object` ile doldurup `gatewayNormalized` der.
+3. `microservice_create` → `source: 'workflow'` + `workflowId` — DTO alanı **uca yazılmaz**.
+4. Aynı uç `middlewareIds` ile kimlik kapsamasını da taşır (§"Kimlik kapsaması × uç kaynağı").
+
+Kayıtlı bir akışa sözleşmeyi sonradan bağlamak tek çağrıdır:
+`workflow_patch(id: <workflowId>, ops: [{ op: 'add', path: '/returnDtoId', value: <dtoId> }, { op: 'add', path: '/returnBehavior', value: 'object' }])`.
+
+**Sözleşmenin bağlandığını uçtan oku:** workflow kaynaklı uçta `microservice_get` yanıtındaki
+`returnScheme` **DTO'nun alanlarını** taşır; table/query/view kaynaklı uçta şema kaynaktan türer.
+Bağlanmamış sözleşmenin belirtisi budur — uç 200 döner ama `returnScheme` DTO'yu değil kaynağı
+yansıtır (2026-09-09'da ölçüldü: `returnDtoId` yazılan table kaynaklı uçta şema `['id','name']`
+kaldı, DTO'nun beş alanı gelmedi).
+
+Sözleşme yalnız **2xx** yanıtlarda uygulanır: 401/422 döndüren bir `response` adımının gövdesi
+DTO'dan süzülmez (WF-026 — `platform_guide('workflow')` §Hata yolu). Sözleşme **süzer, uydurmaz**:
+`bodyExpression`'ın ürettiği DTO dışı alan yanıttan düşer, DTO'da olup üretilmeyen alan gelmez
+(ölçüm: `gizliNot` alanı yanıtta yok, `slot_minutes` de yok).
+
 ## Asgari doğru table-source microservice (platformda doğrulanmış kurallar)
 
 - `operation` enum'u **tam olarak** şudur ([MicroserviceTableOperation](../../../../zeyrek-backend/src/NgApps.Domain/Contexts/Studio/Microservices/MicroserviceTableOperation.cs)):
@@ -69,12 +165,26 @@ servis formunda görünür ve `microservice_get` outline görünümünde geri ok
   yapmasını iki ayrı uç + akışta condition dallanmasıyla kurmayın: tek `operation: 'upsert'`
   ucu yeterlidir. Aynı işlem workflow **table step**'inde de desteklenir
   ([TableStep](../../../../zeyrek-backend/src/NgApps.Domain/Contexts/Flow/Workflows/Steps/TableStep.cs)).
+
+- **Upsert eşleşmesi `filters` ile kurulur, PK `fields`'a KONMAZ** (ölçüm: İK koşusu M-4,
+  2026-09-01). PK'yı `fields`'a koyarsan `AlwaysGeneratedFieldCantBeWritten` alırsın. Doğru şekil:
+  `filters`'a `source: "body"` + `isRequired: false` bir id filtresi; gövdede id **varsa** eşleşen
+  satır güncellenir, **yoksa** yeni satır açılır. `isRequired: true` yaparsan "yeni kayıt" yolu
+  kapanır (id gelmeyince uç reddeder).
+
+> **Upsert'te üretilen alan tuzağı.** `operation: 'upsert'` UPDATE yolunda da alan ifadelerini
+> yeniden değerlendirir; sicil/kod gibi üretilen bir değeri `source: 'expression'` ile yazarsan
+> güncellemede **sessizce değişir** (İK koşusu M-3: EMP-0005 → EMP-0006). Alan bazlı
+> `writeOn: create | update | always` platformda **yok**; o gelene kadar oluşturma ve güncelleme
+> için iki ayrı uç kurun. Gateway **MS-016** ile uyarır.
 - **`count` vardır** — kayıt sayısı için tüm satırları çekip uzunluğuna bakmayın; panel/KPI
   sayaçlarının doğru şekli budur.
 - Gövde kökünde **`entityId` zorunlu**. (Eski "kökte datasourceId zorunlu" bilgisi yanlıştı —
   komutta öyle bir alan yok, gönderilirse yok sayılır; asıl zorunluluk selectFields'taki fieldId.)
-- `selectFields[]` öğelerinde **`fieldId` zorunlu** (yalnız `fieldSlug` yetmez); kök tablo
-  alanlarında alias = **entity'nin slug'ı** ve `path` **yazılmaz**. Alias verilmezse
+- `selectFields[]` / `filters[]` öğelerinde platform **`fieldId`** ister; gateway'e **`fieldSlug`**
+  vermen yeter — kök entity'nin alanları için id'yi gateway çözer ve `gatewayResolved` ile bildirir
+  (join'lenen entity'lerin alanlarında hâlâ `fieldId` gerekir). Kök `entityId` de slug olabilir.
+  Kök tablo alanlarında alias = **entity'nin slug'ı** ve `path` **yazılmaz**. Alias verilmezse
   `ArgumentNullException(key)`, farklı alias verilirse "missing FROM-clause entry" gelir.
 - `sort` ve `limit` **her zaman** verilir (MS-008, block) — aşağıya bak.
 - Filtrelerde `value` bir **JavaScript ifadesidir** — sabit metin tırnak içinde
@@ -90,6 +200,11 @@ servis formunda görünür ve `microservice_get` outline görünümünde geri ok
   `{ alias, fieldId, fieldSlug }`). Aynı kural workflow table create/update step'lerinde de
   geçerlidir. Boş `returnFields` ile write operasyonu yazarsan MS-009 uyarır; buna karşılık
   write operasyonunda boş `selectFields` **uyarı üretmez** (platform onu zaten yok sayar).
+- **Platformun ürettiği alanları `fields` içine koymayın.** Primary key/identity gibi
+  `alwaysGenerated` alanlar yazılırsa istek 400 döner ve hatalı alan slug'larını sayar; bu alanlar
+  create'te platformca üretilir, upsert eşleşmesi gerekiyorsa değer `fields` yerine `filters`ta
+  taşınır. Incremental alanın create/update zamanlaması ayrı tasarım konusudur; mevcut sınır için
+  [`writeOn` tasarımına](../../../../zeyrek-backend/docs/alan-yazma-zamani/01-tasarim.md) bakın.
 
 ```jsonc
 {
@@ -208,6 +323,19 @@ karşılamayı imkânsız kılar. Karar kuralı:
   "isRequired": false, "children": [], "order": 0 }
 ```
 
+> **`source: "query-string"` / `"body"` / `"header"` filtresinde `value` VERİLMEZ** (ölçüm: İK
+> koşusu M-2, 2026-09-01). Değer çağrıdan gelir, parametre adı alan slug'ından türer. `value`
+> yazarsan platform onu JS ifadesi sanıp eval eder → `JavaScriptException: <ad> is not defined`
+> ile 500. `value` yalnız `source: "expression"` ve `"static"` kaynaklarında anlamlıdır. Sabit
+> ön-süzme (tenant, aktiflik) `expression` ile yapılır. Gateway **MS-015** lint'i bu
+> kombinasyonu istek platforma gitmeden yakalar.
+
+> **Dış kaynaklı filtreye (`query-string` / `body` / `header`) `value` yazılmaz.** Değer çağrıdan
+> gelir; tanımdaki `value` çalışma zamanında yok sayılır — parametre gelmezse filtre atlanır ve uç
+> **süzülmemiş** tam liste döner (2026-09-03 öncesinde aynı alan JS olarak değerlendirilip 500
+> veriyordu; İK koşusu M-2). Tanımdan gelen sabit değer istiyorsan `source: 'static'` ya da
+> `'expression'` kullan.
+
 ### Dinamik filtre (`enableDynamicFilters`) — süzülebilir tablonun uç şekli
 
 `enableDynamicFilters: true` verilen uç, süzme koşullarını **tanımdan değil çağrıdan** alır.
@@ -267,12 +395,69 @@ hem `joins` ile getirin hem `selectFields`'a koyun; ondan sonra `filters[0][fiel
 > (qm kanıtı: `sy-users-get-my-profile`). Ayrıntı ve tarifler: `platform_guide('middleware')`.
 > Middleware bağlamadan `user.` okuyan expression yazarsan MS-011 uyarır — runtime'da
 > `user is not defined` 500'ü yersin.
+>
+> **`middlewareIds`'i `microservice_create` GÖVDESİNDE ver, sonradan patch'leme.** Ucu kurup
+> ardından `microservice_patch` ile `/middlewareIds` yazmak her uç için fazladan bir tur demektir:
+> 2026-09-06 koşusunda dokuz uç kuruldu ve dokuz patch çağrısının dokuzu da yalnız bu yolu yazdı
+> (~3 dk). Alan create gövdesinde zaten kabul ediliyor.
 
 > Sayfa tarafındaki karşılığı: kullanıcı ekrandan süzüyorsa (`table` + `filterMode` açık, ya da
 > `datatable` + `isFilterable` kolonlar) uç `enableDynamicFilters: true` olmalı; komponent seçilen
 > koşulları kendi `filters` prop'una yazar ve akış onu uca `filters` parametresi olarak geçirir.
 > Süzme yoksa statik query-string filtreleri yeterlidir — bkz. `platform_guide('page')` Kural 1e.
 
+### Kimlik kapsaması × uç kaynağı — query kaynaklı uç BAĞLAM GÖRMEZ
+
+Yukarıdaki `source: 'expression'` + `value: 'user.id'` kalıbı **yalnız table kaynaklı** uçlarda
+vardır. Agregasyon/rapor uçları query kaynaklı olduğu için aynı kalıp orada yoktur ve
+**parametrelerinin tamamı çağrıdan gelir** — kapsamı gövdeye yazan bir uç sahtelenebilir.
+
+| Uç kaynağı | Parametre/filtre nereden gelir | Kapsam sunucuda zorlanır mı |
+|---|---|---|
+| `table` | `filters[]` · `source:'expression'`, `value:'user.id'` | **Evet** (MS-011 middleware bağını denetler) |
+| `query` | Yalnız çağrının kendisi: **body → query-string → header** (`Query.PrepareQueryParameters` → `FindValue`) | **Hayır** — ifade değerlendirmesi yoktur |
+| `workflow` | Adım ifadeleri; `user.*` bağlı middleware'den gelir | **Evet** (ölçüldü 2026-09-07) |
+| `view` | Arama sözleşmesi (`searchText`) + view'ın indekslediği alanlar | **ölçülmedi** — kapsam şartsa workflow yolunu kullan |
+
+Query parametresine ifade kaynağı **eklenemez**: `parameters[].source` komut şemasında yoktur,
+platform anahtarı sessizce atar (gateway `unmappedMembers` ile söyler) ve kayıtlı şema
+`source: 'body'` kalır. Bu bir eksik değil, modülün tanımı: query modülü SQL seviyesinde çalışan
+ham SQL yüzeyidir, istek bağlamını bilmez.
+
+**Ölçüm (2026-09-07, aynı sorgu, aynı middleware — middleware `user.owner_key = 'OWNER-A'` kurdu):**
+
+| Uç | Gövde | Yanıt |
+|---|---|---|
+| `source:'query'` | `{ owner_key:'OWNER-A' }` | `{ owner_key:'OWNER-A', row_count:3, total:60 }` |
+| `source:'query'` | `{ owner_key:'OWNER-B' }` | `{ owner_key:'OWNER-B', row_count:2, total:300 }` ← **başkasının verisi** |
+| `source:'workflow'` | `{ owner_key:'OWNER-B' }` | `{ owner_key:'OWNER-A', row_count:3, total:60 }` ← gövde **yok sayıldı** |
+| `source:'workflow'` | `{ owner_key:'OWNER-B', min_amount:20 }` | `{ owner_key:'OWNER-A', row_count:2, total:50 }` ← kapsam dışı filtre gövdeden okundu |
+
+#### Reçete: kapsanmış agregasyon ucu
+
+Sorguyu değiştirmeye gerek yok; onu **bir katman yukarıdan** çağırırsın.
+
+1. `query_create` — agregasyonu kapsam parametresiyle yaz:
+   `… WHERE company_id = @company_id AND created_at >= @from`, `parameters` ile her belirteci bildir.
+2. `workflow_create` (`type: 'workflow'`) — start → **query adımı** → response. Adımın bağlaması
+   kapsamı middleware'den, kalan filtreleri gövdeden alır:
+   `rule.expression = "{ company_id: user.company_id, from: input.from }"`
+   (bağlamanın iki yazımı ve canlı motorun tuzağı: `platform_guide('workflow')` §"Query adımı").
+3. `microservice_create` — `source: 'workflow'`, `workflowId`, **`middlewareIds` dolu**.
+4. Doğrula: aynı ucu gövdeye **başka birinin** kapsam değerini yazarak çağır; yanıt değişmemeli.
+
+`middlewareIds` boşken bu akış `500 JavaScriptException: user is not defined` verir (ölçüldü) —
+MS-011'in workflow tarafındaki karşılığıdır ve gateway o dizinin boş kalmasını göremez, çünkü
+uçtan görünen tek şey `workflowId`'dir.
+
+Middleware tarafındaki karşılığı ve `user` değişkenini kuran akış:
+`platform_guide('middleware')` Tarif 3c.
+
+**Her agregasyonu sarmalama.** Kapsam gerekmeyen bir özet (herkese açık istatistik, zaten
+middleware'in reddettiği bir panelde tüm şirketleri gösteren yönetici raporu) düz `source:'query'`
+kalır: fazladan workflow, DTO ve response adımı bedavaya gelmez. Ölçü basit — **bu parametreyi
+çağıran seçebilmeli mi?** Hayırsa sarmala.
+
 ### `sort` ve `limit` her zaman verilir
 
 **MS-008 (block).** Platform bunları null bırakır; Studio formu ise `data.sort.name` /
@@ -285,6 +470,24 @@ Gateway bu kuralları MS-005/MS-006 olarak istek gitmeden denetler; platform val
 hatası alırsan `microservice_debug` çıktısıyla raporla — o zaman gerçek bir bug'dır.
 Query source'a kaçış yalnız ham SQL şartsa; query yazarken parser `SELECT` sonrası satır sonu
 kabul etmez — ilk kolon `SELECT` ile aynı satırda olmalı ("Please use a supported query type").
+Kayıtlı query'nin `@ad` / `{{ad}}` belirteçleri uçta **body → query-string → header** sırasıyla
+bağlanır; bunun için parametreler query kaydedilirken `parameters` ile bildirilmiş olmalıdır
+(`platform_guide('workflow')` §"Query adımı"). Davranış `query_preview` ile aynıdır.
+
+**`language` AYRILMIŞ bir parametredir.** Ham sorguda `{{language}}` (ya da `@language`)
+kullanırsan platform onu isteğin diliyle kendisi doldurur — `parameters` listesine yazmana gerek
+YOKTUR ve yazarsan doğrulama onu zorunlu saymaz. Çok dilli companion tablosunu elle join eden bir
+raporun dili böyle alınır:
+
+```sql
+SELECT p.id, COALESCE(l.title, d.title) AS title
+FROM products p
+LEFT JOIN products_localization l ON l.product_id = p.id AND l.language = {{language}}
+LEFT JOIN products_localization d ON d.product_id = p.id AND d.language = 'en'
+```
+
+`query_preview` da aynı parametreyi ekleyerek koşar, yani şema çıkarımı `{{language}}` yüzünden
+"eksik parametre" diye patlamaz.
 
 ## Middleware'siz uçta çok adımlı yazım ATOMİK DEĞİL (ölçüm 2026-08-19)
 
@@ -336,13 +539,23 @@ kabul etti. Ayrıntı ve doğru rol kapısı tarifi: `platform_guide('middleware
 - `operation: 'list'` → geçersiz; `get` + `isSingle: false` kullanın (PLT-006)
 - Üst seviye `entityId` eksik (MS-004, warn)
 - Gerekçesiz `source: 'query'` (MS-002, warn)
+- Backend zorunlulukları (MS-017, block — istek gitmeden): `name` ve `url` boş olamaz (update'te
+  `slug` da); `queryId`/`entityId`/`workflowId` verilirse boş GUID olamaz; `source: 'expression'`
+  alan ve filtrede `value` dolu; tekil filtrede `fieldId`; `writeOn` yalnız `operation: 'upsert'`
+  ucunda; join'de `entityId` + `fieldId`. Tam katalog: `ngapps://rules/backend-constraints`.
+- Query kaydı (QRY-001, block): `rawQuery`'deki her `@ad` / `{{ad}}` `parameters[]`'ta
+  `{ name, type }` ile bildirilir — yalnız create denetler, update sessiz geçer ve sorgu çalışma
+  anında düşer; `slug`/`rawQuery`/`datasourceId` zorunlu; `outputType` `array` | `object`.
 - Execute'ta dönen `httpStatus` microservice'in kendi sonucudur — 4xx/5xx görünce önce
   `microservice_debug` ile hangi adımın ürettiğine bak, tanımı ona göre düzelt.
-- **`microservice_update` / `microservice_patch`, `operation: 'get'` tipli microservice'lerde
-  HER ZAMAN 500 verir** (`The instance of entity type 'Application' cannot be tracked` —
-  platform regresyonu, P-02 olarak düzeltilecek). Ayrım **operasyona** bağlıdır, tool'a değil:
-  `operation: 'create' | 'update' | 'delete' | 'upsert'` kayıtlarında PUT/PATCH sorunsuz çalışır
-  (crm koşumunda `update` uçlarında yeniden doğrulandı, 2026-08-25); yalnız `get` (liste ya da
-  `isSingle`) uçlarında patlar. Get-tipi bir microservice'i değiştirmen gerekiyorsa **`microservice_delete` +
-  `microservice_create`** kullan ve tanımı ilk POST'ta doğru üret; silme kümesini kendi
-  ürettiğin slug listesiyle sınırla. `entity_patch`, `workflow_patch`, `row_update` sağlamdır.
+- **`microservice_update` / `microservice_patch` tüm operasyon tiplerinde çalışır.** Eski
+  "`operation: 'get'` tipli kayıtta HER ZAMAN 500 (`Application cannot be tracked`)" kuralı P-02
+  regresyonuydu; 2026-08-16'da düzeltildi, 2026-09-01 İK koşusunda get ucunda
+  `microservice_patch` ile canlı doğrulandı (M-9). Get-tipi bir microservice'i değiştirmek için
+  artık delete+create gerekmez. `entity_patch`, `workflow_patch`, `row_update` sağlamdır.
+- **`microservice_patch` tam gövde geri yazar: okunan kayıtta olmayan alan SİLİNİR.** 09-04
+  koşusunda gidiş-dönüşte `description` düştü ve MS-014 patch'i bloke etti (Y-16). Gateway artık
+  açıklamasız bir patch gövdesini hiç göndermez; hata mesajı düzeltmeyi verir
+  (`{ "op": "add", "path": "/description", "value": "…" }`). Patch yanıtındaki `silentlyDropped`
+  alanı, gönderilen ama kaydedilmeyen alanları listeler — boş değilse platform bir alanı yutmuş
+  demektir.