@appaflytech/zeyrek-ai-mcp 0.0.7 → 0.0.9

package/dist/resources/guides/microservice.md

@@ -77,6 +77,12 @@ servis formunda görünür ve `microservice_get` outline görünümünde geri ok
      > (`'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.
      >
+     > **`(@p = '' OR kolon = @p)` YAZMA** — "filtre boşsa hepsini getir" dalı hiçbir zaman
+     > çalışmaz, çünkü boş değer `NULL` bağlanır. Değeri form bileşeninden gelen parametrede
+     > dokunulmamış alanın `null` ya da `''` göndermesi fark etmez; ikisi de `NULL` olur
+     > (2026-09-15 bulgusu: pano 0 kart, `COALESCE`/`IS NULL` ile 141). Gateway bu kalıbı
+     > `query_create`/`query_update`/`query_preview`'da **QRY-007** (warn) ile işaretler.
+     >
      > **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
@@ -115,7 +121,15 @@ servis formunda görünür ve `microservice_get` outline görünümünde geri ok
 
 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.
+   adım adım executionItems ağacı döner. Zamanlanmış (`schedule-job`) uçta sıra farklıdır:
+   `workflow_preview` → `microservice_debug` → `microservice_schedule_control` `trigger` →
+   `microservice_job_history`; geçmişteki `completed` başarı kanıtı DEĞİLDİR (§Zamanlanmış işin
+   gerçek sonucunu görmek).
+   Çağrı parametrelerini (sorgu parametresi, filtre değeri) üst düzey `parameters: { ad: değer }`
+   ile ver; gateway GET'te query-string'e, POST/PUT'ta gövdeye koyar. Değeri NULL bağlanan query
+   parametresini debug yanıtı `unboundParameters` ile söyler — ağaçta o satırın `value` anahtarı
+   görünmez. Tool'un tanımadığı bir üst düzey argüman artık reddedilir (GW-005); 2026-09-15'e
+   kadar `parameters` hata vermeden atılıyordu ve dört farklı filtre aynı gövdeyi döndürdü (G-13).
 
 ## Yanıt sözleşmesi (DTO) uca DEĞİL workflow'a bağlanır (MS-018, block)
 
@@ -159,8 +173,9 @@ DTO'dan süzülmez (WF-026 — `platform_guide('workflow')` §Hata yolu). Sözle
 ## 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)):
-  `get · create · update · delete · upsert · count`. **`list` yoktur** — liste için
-  `operation: 'get'` + `isSingle: false`, tek kayıt için `isSingle: true`.
+  `get · create · update · delete · upsert · count · bulk-create · bulk-update · bulk-delete`.
+  **`list` yoktur** — liste için `operation: 'get'` + `isSingle: false`, tek kayıt için
+  `isSingle: true`.
 - **`upsert` vardır ve tercih edilmelidir.** Aynı formun hem yeni kayıt hem düzenleme
   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
@@ -174,9 +189,42 @@ DTO'dan süzülmez (WF-026 — `platform_guide('workflow')` §Hata yolu). Sözle
 
 > **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.
+> güncellemede **sessizce değişir** (İK koşusu M-3: EMP-0005 → EMP-0006). Çözüm alan bazlı
+> **`writeOn: create | update | always`**'dir (varsayılan `always`) ve 2026-09-04'ten beri
+> platformdadır: üretilen alana `writeOn: 'create'` verirsen upsert'in UPDATE dalı o alanı satıra
+> hiç koymaz (`ToRow(entityDto, writeOn)` iki satırı ayrı kurar). `writeOn` YALNIZ
+> `operation: 'upsert'` ucunda anlamlıdır — başka operasyonda `always` dışında bir değer
+> **MS-017** ile reddedilir. Gateway **MS-016** ile uyarır; alan `writeOn: 'create'` taşıyorsa
+> susar. **`writeOn` bir "kısmi güncelleme" bayrağı DEĞİLDİR** — hangi DALIN yazacağını söyler,
+> "gövdede gelmeyen alanı atla" demez (aşağıdaki §Güncelleme sözleşmesi).
+- **Toplu yazma için `bulk-create` / `bulk-update` / `bulk-delete` vardır.** Aynı tabloya N satır
+  yazmak için akışta döngü kurmayın: bu üç uç gövdedeki **JSON diziyi** tek çağrıda işler
+  ([TableMicroserviceExecutor](../../../../zeyrek-backend/src/NgApps.Domain/Contexts/Studio/Microservices/Executors/TableMicroserviceExecutor.cs)).
+  Kurallar:
+  - Gövde bir **dizi** olur; her eleman bir satırdır. `bulk-delete` gövdesinde yalnız birincil
+    anahtar alanı aranır ve tek bir `IN` filtresine çevrilir.
+  - `filters` **kullanılmaz** — satırlar ve anahtarlar gövdeden okunur.
+  - Tek istekte en fazla **1000 satır** (`EntityConstants.BulkRowLimit`); aşılırsa
+    `BulkRowLimitException` (422).
+  - Parti **hep-ya-hiç**tir: bir satır doğrulamadan geçmezse `BulkRowFailedException` hangi
+    satırın (index) patladığını söyler ve hiçbir satır yazılmaz.
+  - **Dosya alanı olan tablolarda `bulk-create`/`bulk-update` da desteklenir** — her satırın
+    dosya (ve çoka-çok dosya) alanı, tekil `create`/`update` ile **aynı format** üzerinden
+    (`{ type, fileName, value, clone, override, id }`) satır satır `fileService`'e gönderilir;
+    artık dosya alanı yüzünden 422 dönmez. Aynı entegrasyon workflow **table step**'inde de
+    vardır (satır dizisindeki dosya değeri de aynı formatı izler).
+  - **Bulk upsert yoktur.**
+  - `bulk-update` gövdesinde birincil anahtar **bulunur ve zorunludur** — tekil `update`'in
+    aksine satırı belirleyen filtre değil, gövdedeki anahtardır. `UpdateRowsAsync` bu anahtarı
+    `SET` listesinden dışlayıp `WHERE`'e taşır, bu yüzden alan listesinde görünmesi doğrudur ve
+    GENERATED ALWAYS koruması onu es geçer.
+  - Workflow **table step**'inde de aynı üç işlem vardır; orada satır dizisi adımın `expression`
+    alanından (JS) gelir, gövdeden değil. **Ancak studio'nun workflow table formunda bu
+    `expression` alanı için editör henüz yoktur** — akış adımında bulk seçilirse satır dizisi
+    girilemez ve adım `MissingParameterException` ile düşer. v1'de bulk yalnız microservice
+    ucundan kullanılır.
+  - Adımda tanımlı ama değeri boş bırakılan alanlar gövdeden/expression'dan gelen veriyi
+    **ezmez**; yalnız değeri dolu olan sabitler her satıra uygulanı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ı —
@@ -233,6 +281,61 @@ DTO'dan süzülmez (WF-026 — `platform_guide('workflow')` §Hata yolu). Sözle
 }
 ```
 
+## Güncelleme sözleşmesi: yazılan alan kümesi TANIMDAN gelir, gövdeden DEĞİL
+
+`create` / `update` / `upsert` ucunda **SET listesi `fields[]`'tir**; gövde yalnız o alanların
+DEĞERİNİ taşır. Studio'daki karşılığı "Oluşturulacak veya güncellenecek alanlar" ekranındaki
+**İstek alanları** listesidir: önce hangi alanların yazılacağı seçilir, gövde sonra gelir.
+İki yön de sessizdir, ikisi de 200 döner (ölçüm: 2026-09-15, `emrah/test`, `development`):
+
+| Tanımda (`fields[]`) | Gövdede | Sonuç |
+|---|---|---|
+| alan **var** | anahtar **yok** | kolona **NULL yazılır** — eski değer silinir |
+| alan **var** | anahtar var | değer yazılır |
+| alan **yok** | anahtar var | **yok sayılır** — o alan bu uçtan hiç değiştirilemez |
+
+Kod yolu: gövdede anahtar yoksa alan `null` değerini alır
+(`MicroserviceRuntimeCacheDto.SetSourceEntityFieldAndFilterValue`, `:145-148`), `ToRow` Default
+modlu **bütün** alanları sözlüğe basar (`:169-175`) ve `UpdateRowAsync` SET listesini doğrudan o
+sözlüğün anahtarlarından kurar (`PostgreSqlEntityConnector.cs:262-273`; null → `DBNull.Value`).
+"Yalnız gövdede gelen alanı yaz" diye bir bayrak **yoktur**.
+
+Ölçülen üç vaka (`pu_test`: `title` · `owner` · `status`):
+
+| # | Uç tanımı | Gövde | Sonuç |
+|---|---|---|---|
+| 1 | `fields: [title, owner, status]` | `{ id, status: 'done' }` | 200 — `status` değişti, **`title` ve `owner` NULL** oldu (`entity_audit_trails` ikisini de yalnız `previousValue` ile gösteriyor) |
+| 2 | `fields: [status]` | `{ id, status, title: '…', owner: '…' }` | 200 — yalnız `status` değişti; listelenmeyen iki alan **yazılmadı** |
+| 3 | `fields: [title, owner, status]`, `status` kolonu NOT NULL | `{ id, title }` | **400 `RowValidationFailed`** ("Please complete all required fields") — satır hiç değişmedi |
+
+Yani kolon `nullable` ise kayıp **sessizdir**, NOT NULL ise istek **gürültülü** düşer. Kanban'da
+kart sürüklemek, satır içi tek alan düzenlemek, "arşivle" düğmesi — hepsi 1. satırın tuzağıdır:
+kart doğru sütuna geçer, başlığı ve sorumlusu silinir.
+
+### Kısmi güncellemenin üç doğru yolu
+
+1. **Eylem başına uç (varsayılan tercih).** Kartı taşıyan uç yalnız `status` yazar, başlığı
+   düzenleyen uç yalnız `title`: `fields[]` = o eylemin gerçekten yazdığı alanlar. Fazladan okuma
+   yok, eşzamanlı düzenlemede birbirini ezme yok, yetki yüzeyi de dar kalır (2. ölçüm bunun
+   kanıtıdır — uç, gövdeye konan `title`/`owner`'ı yok sayar).
+2. **Tam form ucunda gövde de tam olur.** Düzenleme formu kaydediyorsa gövde `fields[]`'teki HER
+   alanı taşır; kullanıcının dokunmadığı alan da forma yüklendiği hâliyle geri gönderilir. Uçta
+   yapılacak bir şey yoktur — eksik gönderen istemci alanı siler.
+3. **Oku-birleştir (alan kümesi ancak çağrı anında belliyse).** Akışta önce `table get`, sonra
+   `table update`; gelmeyen alan okunan değere düşer:
+
+   ```js
+   typeof input.title !== 'undefined' && input.title !== null ? input.title : read_row.data.title
+   ```
+
+   Ölçüldü: `{ id, status }` gövdesiyle `title` ve `owner` korundu, `status` yazıldı. Bedeli iki
+   veritabanı turu ve **son yazan kazanır** — okuma ile yazma arasında başkasının yazdığı alan
+   geri alınır. Bu yüzden 1. yol varken bu yola girilmez.
+
+> Aynı kural workflow **table step**'inde birebir geçerlidir; orada değer gövdeden değil
+> ifadeden gelir ve `undefined` dönen ifade de `null` yazar —
+> `platform_guide('workflow')` §"Table update adımı".
+
 ## İlişki alanı: `row_list` NESNE döner, uç/step JOIN'siz DÜZ FK döner
 
 Aynı alan iki yoldan farklı şekilde gelir ve bu fark sessizce yanlış sonuç üretir:
@@ -590,6 +693,57 @@ Yeni işte tanımı `typeParameters.schedule` ile yazın ve kaydetmeden önce
   `cronExpression`'ı değiştiren PUT/PATCH `422 ScheduleCronConflict` alır — sessizce eski cron
   kalmaz. `typeParameters: null` işi zamanlayıcıdan siler.
 
+### Zamanlanmış işin gerçek sonucunu görmek: geçmiş `failed` yazar, adım izini önizleme verir
+
+Zamanlanmış koşu Quartz işi `MicroserviceJob` içinde koşar: `ExecuteAsync(microservice, BOŞ
+parametre)`. 2026-09-16'dan beri iki hata yolu da geçmişe `failed` olarak düşer ve transaction geri
+alınır:
+
+| Geçmişte görünen | Gerçekte olan |
+|---|---|
+| `failed`, `errorMessage: "Step 'boom' failed: <sebep>"` | fail dalı bağlanmamış adım patladı; motor `WorkflowStepFailedException` fırlattı |
+| `failed`, `errorMessage: "The job's workflow returned 500 (JavaScriptException): <mesaj>"` | akış bağlı global-error dalından (gateway'in eklediği `gatewayOnError` dâhil) 2xx dışı sonuç döndü; `MicroserviceJob` `ScheduleJobWorkflowFailedException` fırlattı |
+| `failed`, başka mesaj | motor dışı exception: tanım/cache hatası, sonsuz döngü, canlı `revert`, DTO davranış uyumsuzluğu |
+| `completed`, beklenen süre | akış 2xx ile bitti, yazmalar commit edildi — kalıcı etkiyi yine `row_list` ile say |
+| satır yok | koşu veto edildi (deployment/şablon kurulumu sürüyor) ya da zamanlayıcıda kayıt yok — `microservice_schedule_get` |
+
+Eski davranış (2026-09-16 öncesi imaj): adım hatası exception değildi; geçmişe `completed` + kısa
+süre + boş `errorMessage` yazılır, yazmalar commit edilirdi — "90 ms'de tamamlandı ama hiçbir şey
+yapmadı". Karşındaki platform hâlâ bunu yapıyorsa imaj eskidir.
+
+Dört gerçek daha:
+
+- **Geçmiş satırı `{ status, triggeredAt, completedAt, durationMs, errorMessage }`'dan ibarettir.**
+  Mesaj patlayan adımı ve sebebini söyler ama adım adım girdi/çıktı vermez; son koşunun adım izini
+  döndüren bir MCP aracı **yoktur** (açık backend işi P-19c). Adım izi için aynı tanımı önizlemede
+  koştur.
+- **Zamanlanmış koşunun bağlamı boştur:** girdi yok (`MicroserviceExecuteParameter.Create()`),
+  middleware koşmaz (`user` yok), `request` yok, `context`/`triggerSource` kurulmaz. Akış
+  `input.x`, `user.id`, `request.*`, `context.language` okuyorsa zamanlanmış koşuda hepsi
+  `undefined`'dır — önizlemede geçen akış bu yüzden zamanlayıcıda patlayabilir.
+- `microservice_schedule_get` içindeki `lastExecution` aynı geçmiş satırıdır.
+- Geçmiş mesajları resx varsayılanıyla (İngilizce) yazılır; iş iş parçacığında istek dili yoktur.
+
+**Sıra — tetiklemeden önce gör** (Studio'daki akış "Önizleme"si + servis önizlemesinin MCP karşılığı):
+
+1. **Akışı `workflow_preview` ile koştur** (`platform_guide('workflow')` §Önizleme çıktısını
+   okumak): `workflow_get` gövdesini olduğu gibi ver, **`previewPayload` VERME** — iş girdisiz
+   koşar, önizleme de girdisiz koşsun. Akış `parameterDtoId` taşıyorsa zamanlanmış koşuda DTO boş
+   bağlanır; zorunlu alanı olan DTO'yu zamanlanmış akışa bağlama. Hata varsa `runtimeErrors` +
+   `steps[].hasError` / `errorMessage` / `input[]` patlayan adımı ve sebebini verir.
+2. **Kayıtlı ucu `microservice_debug` ile koştur:**
+   `{ application: '<app slug>', microservice: '<uç slug>', method: 'POST' }` — schedule-job için
+   de slug yolu çalışır (tip denetimi yok), rollback'lidir, `httpStatus` akışın kendi sonucudur
+   (4xx/5xx'te gateway `runtimeErrors` ekler) ve `executionItems` ağacı adım adım girdi/çıktıyı
+   verir. Düğümlerde hata bayrağı yoktur: patlayan adımın `output`'u boştur, hata gövdesi hata
+   dalındaki response adımının çıktısındadır. Fark: debug ucun middleware'lerini de koşturur,
+   zamanlayıcı koşturmaz.
+3. **`microservice_preview({ id })`** en kısa "geçer mi" sondasıdır: yanıt `httpStatus` + gövdeden
+   ibarettir, adım ağacı DÖNMEZ (`executionItems` yalnız `/debug/` yolunda).
+4. Ancak sonra `microservice_schedule_control` `trigger` → `microservice_job_history`. `failed`
+   ise mesaj patlayan adımı ve sebebini söyler; adım adım girdi/çıktı gerekiyorsa 1-2'ye dön.
+   `completed` ise kalıcı etkiyi `row_list` ile say.
+
 ## Sık hatalar
 
 - `description` boş (MS-014, block — uç listesinde ne işe yaradığı okunamaz)

package/dist/resources/guides/page.md

@@ -78,27 +78,33 @@ mümkündür ama doğrulama duvarı ve canlı canvas yalnız `page_schema_patch`
   her turda çözümlenmiş metinle EZER — anahtar yalnız `ref`'te yaşar, `data`'ya yazıp
   güvenme (`code` prop'uyla aynı davranış). Tam şekil, fallback zinciri ve `translation_*`
   tool'ları için `platform_guide('translation')`.
-- **Kurulmuş bir düğümün prop TİPİNİ `set_prop_type` micro-op'u değiştirir.**
+- **Kurulmuş bir düğümün prop TİPİNİ yerinde değiştir — düğümü yeniden KURMA.** İki eş yol var:
+  `{ op: 'replace_prop', target: '<elementId>', prop: 'content', value: { type: 'translation', ref: 'dashboard.kpi.total' } }`
+  (applier `code` ve `translation` sarmalını tipiyle korur; gateway 2026-09-15'e kadar translation
+  sarmalını reddediyordu) ya da
   `{ op: 'set_prop_type', target: '<elementId>', prop: 'content', propType: 'translation', ref: 'dashboard.kpi.total' }`
-  bir `static` prop'u çeviriye, `propType: 'code'` + `ref: '<ifade>'` koda, `propType: 'static'` +
-  `data: <değer>` sabite bağlar. Bu bir **gateway emülasyonudur**: `replace_prop` gönderilen ham
-  değeri her zaman `static` Prop'una sarar ve sarmalanmış Prop nesnesini reddeder, yani prop tipini
-  yazamaz. Op olmadan tek yol düğümü `remove_component` + `add_component` ile yeniden kurmaktı;
-  2026-09-06 koşusunda on bir etiket bu yolla kuruldu ve onlara yazan **dokuz setter iteratee'si**
-  platform tarafından sessizce silindi (üç KPI kartı boş kaldı). Taşıyıcı alan tipe göre değişir —
-  `static` değeri `data`'da, `code` ve `translation` `ref`'te taşır; eksik taşıyıcı istek
-  gönderilmeden reddedilir ve `page_schema_validate` aynı kararı verir.
-
-- **`blocks[].size`, komponentin `component_get`'teki `maxSize`'ını aşamaz.** Dikkat: katalog
-  varsayılanı aşabiliyor (`page-header` default `h:8`, `maxSize` `h:4`) — varsayılanı körü körüne
-  kopyalama, doğrulayıcı `"Height of 'page-header' must be between 1 and 4."` ile reddeder.
+  (platformun kendi op'u — 2026-09-14'e kadar gateway emülasyonuydu — ve yamanın geri kalanıyla
+  aynı PATCH'te gider; mevcut `data`'yı tasarım yedeği olarak taşır). Taşıyıcı alan tipe göre
+  değişir — `static` değeri `data`'da, `code` ve `translation` `ref`'te taşır; eksik taşıyıcı istek
+  gönderilmeden reddedilir ve `page_schema_validate` aynı kararı verir. Eski yol
+  `remove_component` + `add_component` idi: 2026-09-06 koşusunda on bir etiket bu yolla kuruldu ve
+  onlara yazan **dokuz setter iteratee'si** sessizce silindi; 2026-09-15'te (G-04) aynı zincir bir
+  `daterangepicker` yer tutucusunu çeviriye bağlarken tekrarlandı — setter hedefi elementId değil
+  komponentin iç kimliğidir (aşağıda Kural 2, `FLOW-018`).
+
+- **`blocks[].size`'ı komponentin `component_get`'teki `minSize`..`maxSize` aralığında tut.** Dikkat:
+  katalog varsayılanı aşabiliyor (`page-header` default `h:8`, `maxSize` `h:4`) — varsayılanı körü
+  körüne kopyalama. Sınır grid kanvasının kuralıdır; API 2026-09-15'ten beri reddetmez, ama aşan
+  blok kanvasta boyutlandırılamaz (aşağıda Kural 7 "Boyut tuzağı").
 - **Kurulmuş bir düğümün boyutunu `resize_component` micro-op'u değiştirir.**
   `{ op: 'resize_component', target: '<elementId>', size: { w, h } }` ızgara boyutunu,
   `{ …, appearance: { heightType: 'fixed', heightString: '340px' } }` flex ölçüsünü yazar; ikisi
-  aynı op'ta verilebilir, `breakpoint` varsayılanı 1024'tür. Bu bir **gateway emülasyonudur**:
-  platformun micro-op sözlüğünde boyut yoktur ve `move_component` gövdesine konan `size` 200 dönüp
-  SESSİZCE düşer (bu yüzden gateway artık onu reddeder ve buraya yönlendirir). Op şemayı okuyup
-  sayfayı tam gövdeyle geri yazar. Ebeveynin düzeni yazdığın alanı etkisiz kılıyorsa (flex kabın
+  aynı op'ta verilebilir, `breakpoint` varsayılanı 1024'tür. Gateway op'u platformun
+  `set_block {target, breakpoint, size}` + `set_appearance {target, appearance}` +
+  `set_states {target, states}` op'larına çevirir ve yamanın geri kalanıyla **aynı PATCH'te** yollar
+  (o üç op'u doğrudan da gönderebilirsin). `move_component` gövdesine konan `size` gateway'de
+  reddedilir ve buraya yönlendirir; konumu belirli bir breakpoint'e yazmak için
+  `move_component`'e `breakpoint` ver. Ebeveynin düzeni yazdığın alanı etkisiz kılıyorsa (flex kabın
   içine `size`, ızgaranın içine `appearance`) yanıt `PAGE-019` uyarısı taşır — istek yine geçer.
   **Düğümü silip yeniden kurmayın:** o yol ona yazan akış setter'larını sessizce öldürür
   (`FLOW-018`, aşağıda Kural 2).
@@ -164,8 +170,10 @@ uymayan adı **PAGE-008** ile istek gitmeden reddeder.
 **Olay KALDIRMAK için `remove_event` kullan.** Platformun `set_event` micro-op'u olay silemez:
 `eventValue: null` verildiğinde kayıt `{ name: 'click' }` olarak (değersiz) kalır, diziden
 çıkmaz — şemada ölü bağ artığı bırakır. `{ "op": "remove_event", "target": "<elementId>",
-"event": "click" }` gateway emülasyonudur: şemayı okur, olayı diziden çıkarır ve sayfayı tam
-gövdeyle geri yazar (yanıtta `removedEvents`). Sayfa düzeyi olaylar için `target: "page"`.
+"event": "click" }` platformun op'udur: olayı diziden çıkarır (yanıtta `removedEvents`); olmayan
+bir olayı kaldırmaya çalışmak `missing-event` ile 422 döner. Sayfa düzeyi olaylar için
+`target: "page"`. Referanssız kalan akış silineceği için `allowFlowDeletion` kuralı (G-21) bu op'ta
+da geçerlidir.
 
 **Olay YÜKÜ komponente özeldir ve `component_get` onu da veriyor** (`events[].payload`, gerekirse
 `events[].reads`) — **ama yük akışa `event.data` ile GELMEZ.** Motor emit'in `data`'sını önce
@@ -394,6 +402,14 @@ göstermek error flow'un işidir.
 >   "branches": [{ "id": "<GUID>", "name": "always", "nextStepId": null }] }
 > ```
 
+> **`confirm` adımının diyalog çerçevesi de yazılabilir.** `args` dört düz metin alanı taşır:
+> `message` (gövde), `title` (başlık), `confirmText` (onay düğmesi, `yes` dalı), `cancelText`
+> (vazgeç düğmesi, `no` dalı). Son üçü isteğe bağlıdır; boş bırakılan alan dile göre sabit metne
+> düşer ("Emin misiniz?" / "Evet" / "Hayır" — `dialog.functions.ts` `resolveDialogFrame`).
+> Dördü de `alert`'in `message`'ı gibi DÜZ METİNDİR (FLOW-022 hepsini denetler):
+> `{ "type": "confirm", "args": { "message": "Bu risk ve 4 aksiyonu silinecek.", "title": "Riski sil",
+> "confirmText": "Sil", "cancelText": "Vazgeç" } }`.
+
 > **Hangi yolu seçeceksin — `errorSteps` mi, ana akışta `condition` mı?** İkisi birden
 > kurulamaz (yukarıdaki 1. madde), yani bu bir tercih değil bir karar:
 >
@@ -600,8 +616,8 @@ Türkçe başlık `props.title` / `props.text` / `props.label` / `props.pageTitl
 > `elementId` ile eşit tutmazsan `element:` alanı çalışır ama ifadedeki değişken `undefined` kalır.
 >
 > Gateway bunu **PAGE-009** ile HER sayfa ve layout yazma yolunda istek gitmeden reddeder:
-> `page_create`, `page_update(schema)`, `add_component`, `layout_create`, `layout_update(views)`
-> ve `layout_patch`.
+> `page_create`, `page_update(schema)`, `add_component` (sayfa, `layout_schema_patch` ve
+> `component_schema_patch` yamalarında), `layout_create`, `layout_update(views)` ve `layout_patch`.
 
 ## Kural 1d — Sayfa iskeleti: `page_container` ve boyutlandırma
 
@@ -893,6 +909,16 @@ Beş şeyi bilmeden flex kurma:
    aradaki boşluklar çizilmez. Yine de bitişik ver (0,1,2…): kapsayıcı ileride `grid`'e
    döndürülürse şema geçerli kalsın. Gateway bu yüzden **flex kapsayıcının İÇİNDE PAGE-010
    boşluk uyarısı üretmez** (ızgarada üretmeye devam eder).
+   **Dizi sırası çizimi belirlemez** — `children[]` içindeki yer değil `y` kazanır; `y`'si eşit
+   iki çocukta dizi sırası kazanır. Bu yüzden flex kapta sıralamanın yolu `index`'tir:
+   `add_component`/`move_component`'e verilen `index` **görünen sıradaki yeri** belirler ve gateway
+   kardeşlerin konumunu Studio'nun flex tuvali gibi yeniden yazar (x=0, alt alta birikimli y;
+   yanıtın `gatewayNormalized` notu hangi `y`'nin değiştiğini söyler). Grafiğin üstüne başlık:
+   `{ "op": "add_component", "parent": "<flex kap>", "index": 0, "component": { … } }` — koordinat
+   hesaplamak gerekmez, `remove_component` + `add_component` hiç gerekmez. **Izgara kapta `index`
+   çizimi değiştirmez** (her çocuk kendi `position`'ında mutlak çizilir): sırayı
+   `move_component { target, position: { x, y } }` ile ver; sona eklemeyen `index` orada
+   **PAGE-033 (uyarı)** üretir.
 3. **Flex kapsayıcının yüksekliği içeriğine oturur.** `verticalAlign`'ın dağıtacak boşluğu
    olması için `appearance.heightType: 'fixed'` vermelisin — ölçü `heightString`'den
    (serbest CSS uzunluğu, ör. `"30vh"`), o yoksa `size.h × 10px`'ten gelir. `heightString`
@@ -1010,7 +1036,8 @@ UYGULAMAZ** — koordinatları aynen kaydeder (aşağı itme yalnız `page_creat
 > sarmalayıcıya bağla (yukarıdaki `box_multi`). Sarmalayıcıyı **`isWrapper:false`** kur
 > (Kural 1f: wrapper = `min-height:80vh`) ve çerçevesini `style` ile kapat:
 > `{ background:'transparent', border:'none', '&__body': { padding:'0px' } }`.
-> `appearance.isHidden` diye bir kaçış yolu YOKTUR — runtime onu hiç okumaz.
+> `appearance.isHidden` diye bir alan YOKTUR (2026-09-15'te platformdan kaldırıldı, S-16) —
+> görünürlük yalnız `props.isHidden`'dır.
 
 > **Satır BAŞINA doğrulama kurulamaz.** `validations` komponentin kendisindedir, tüm satırlar
 > onu paylaşır — "3. soru zorunlu, 4. soru değil" şemayla ifade edilemez. Zorunluluk satır
@@ -1030,8 +1057,9 @@ UYGULAMAZ** — koordinatları aynen kaydeder (aşağı itme yalnız `page_creat
 >   (iç repeater bir kez `item` olmadan da değerlendiriliyor).
 >
 > **Gateway bunu `PAGE-013` ile istek gitmeden reddediyor** — `page_create` / `page_update(schema)` /
-> `layout_create` / `layout_update(views)` / `layout_patch` gönderilen ağaca, `page_schema_patch` hem
-> eklenen alt ağaca hem op'lar UYGULANDIKTAN SONRAKİ ağaca bakarak. Layout'ta da geçerlidir: kırılma
+> `layout_create` / `layout_update(views)` / `layout_patch` gönderilen ağaca; `page_schema_patch`,
+> `layout_schema_patch` ve `component_schema_patch` hem eklenen alt ağaca hem op'lar UYGULANDIKTAN
+> SONRAKİ ağaca bakarak. Layout'ta da geçerlidir: kırılma
 > `_repeaterValues` geri yazmasındadır, barındıranın sayfa mı layout mu olduğuna bakmaz.
 >
 > **Yapılacak:** satır içi listeyi tek bir `textarea`'da **satır başına bir öğe** olarak topla
@@ -1060,6 +1088,12 @@ yapmanın yolu budur — ölçülmüş kurallar (anket-doldur, 2026-08-19):
 > Bu kural TEMA/GÖRSELLİK içindir. Çocukların dizilimi (ortalama, yaslama, aralık, "kalanı
 > doldur") `style` ile değil kapsayıcının kendi `layout` prop grubuyla kurulur — Kural 1f-2.
 
+> **ÖNCE PROJE TEMASI.** Bir markayı uygulamanın birinci yolu `theme_update`'tir
+> (`platform_guide('theme')`): tema kaydı BÜTÜN sayfalara iner, `theme_get(view:'resolved')`
+> hangi değişkenin hangi değeri aldığını söyler. Aşağıdaki `page_container.style` yöntemi
+> yalnız O SAYFAYA özgü sapma içindir — her sayfada tekrarlanan bir ezme, temaya taşınmamış
+> bir karardır.
+
 > **Stil anahtarları camelCase'dir: `minHeight`, `fontSize`, `letterSpacing`.** Kebab-case anahtar
 > (`min-height`) platform tarafından KABUL EDİLİR, `page_schema_get` ile aynen geri okunur ve
 > runtime onu HİÇ UYGULAMAZ; tek işaret tarayıcı konsolundaki tek satırdır ve `page_screenshot`
@@ -1120,6 +1154,8 @@ işareti taşıyan input'un **sonraki kardeşini** boya (`&__item-input:checked
 ### 1h-2 — Tema değişkeni envanteri (`Theme.svelte`, tamamı)
 
 Bunlar **runtime'da her sayfada tanımlıdır**; `style` içinde yeniden tanımlayarak eziyorsun.
+Bir projedeki GÜNCEL değerleri (ve buradaki listenin tamamını) `theme_get(view:'resolved')`
+`cssVars` alanından okursun — aşağıdaki tablo kümeleri anlatır, değerleri değil.
 Varsayılan palet `white.ts` (accent `#0052CC`, border `#dfe1e6`, text `#262626`) — yani hiçbir şey
 yapmazsan ekran "platform mavisi" görünür; marka rengine çevirmek tek satırdır.
 
@@ -1245,8 +1281,9 @@ kaldırır); sayı `0` "seçilmedi" sayılır.
 tipli grup alanları temayı alan alan EZER; düğümün serbest `style`'ı en üstte SON SÖZDÜR.
 Boyut alanları CSS uzunluğu metnidir (`'18px'`, `'1.2em'`); `radius` tek alanda preset
 anahtarı YA DA CSS uzunluğu kabul eder.
-**Tema preset'i bağlamak:** `style: { $preset: 'card' }` (adlar `project_get` → `theme.presets`;
-`componentStyles[type]` referanssız uygulanır). Bir alanı temaya bırakmak = o alanı hiç yazmamak;
+**Tema preset'i bağlamak:** `style: { $preset: 'card' }` (adlar `theme_get` → `presets`, sayfa
+bağlamında `page_runtime_get` → `theme.presets`; `componentStyles[type]` referanssız uygulanır).
+Preset'in kendisini yazmak/silmek `theme_update` işidir — `platform_guide('theme')`. Bir alanı temaya bırakmak = o alanı hiç yazmamak;
 studio'da bunun adı "Temaya dön"dür. Tema değerini gruba kopyalama — bağ kopar, tema değişince izlemez.
 
 **Efektif stili okumak:** `page_runtime_get(resolveStyles: true)` her düğüme `resolvedStyle`
@@ -1299,12 +1336,14 @@ dokunuldu" sorusunun kanıtı) ve **`newVersion`** (`UpdatedAt.Ticks`).
 > yamadan sonra şemayı okuyup gönderdiğinle karşılaştırarak söyler. Kırpma bu yüzden kanıt kaybı
 > değildir; `view: 'full'`e yalnız gerçekten platformun ham gövdesini incelerken düş.
 
-**Sürüm kontrolü platformda var ama gateway bugün KULLANMIYOR.** Platform gövdede `baseVersion`
-(long tick) kabul eder ve tutmazsa 409 verir; `page_state.baseVersion` bu değeri döner.
-`page_schema_patch` bu alanı geçirmez — bayat plan koruması gateway tarafında
-`expectedUpdatedAt` ile yapılır: sayfa okunur, `audit.updatedAt` karşılaştırılır, tutmazsa istek
-hiç gönderilmez. Bu kontrol **iki çağrı arasına başka bir yazar girerse yakalamaz**; gerçek
-korumayı isteyen ham HTTP ile `baseVersion` göndermelidir.
+**Sürüm kontrolü `baseVersion` ile yapılır.** `page_schema_get` yanıtı `version` taşır (mikrosaniye,
+STRING — sayıya çevirme); `page_schema_patch`'e `baseVersion` olarak ver. Sayfa o sürümden beri
+değiştiyse platform **409** döner ve hiçbir op uygulanmaz; yanıttaki `newVersion` bir sonraki
+yamanın `baseVersion`'ıdır. Kontrol platformda atomiktir (satır kilidi + sürüm koşulu tek
+`UPDATE`'te), yani iki çağrı arasına giren yazarı da yakalar. `baseVersion` vermezsen gateway yalnız
+bu çağrıda zaten okuduğu sayfanın sürümünü gönderir; hiç okumadıysa yama sürümsüz gider ve son
+yazan kazanır. Eski `expectedUpdatedAt` hâlâ çalışır ama `baseVersion`'ın yerini tutmaz.
+Yanıttaki `touched`, kaydı değişen elementId'leri listeler (eklenen alt ağaç dâhil).
 
 > **Büyük şemada çalışma sırası:** `mode:'summary'` ile ağacı çıkar (props yok, 500 KB'lık sayfada
 > bile küçük) → hedefin `elementId`'sini al → gerekiyorsa `mode:'subtree'` ile yalnız o dalı oku →
@@ -1319,14 +1358,15 @@ korumayı isteyen ham HTTP ile `baseVersion` göndermelidir.
 > `set_event` ile bağla ya da `flow_get` ile gövdesini yedekle. Ayrıntılı analiz:
 > `PatchPageSchemaCommandHandler` (backend) — kilit, sürüm ve hep-ya-hiç davranışının kaynağı.
 
-## Kural 3 — Flow yazımı barındırıcıyı da günceller
+## Kural 3 — Flow yazımı yalnız akışı yazar, bağ ayrı yamadır
 
-Platform `flow` uçlarında gövdede hem akışı hem barındırıcının tam güncelleme komutunu ister
-(`{ flow, page | layout | component }`) — şemadaki `events[].value` = flow id bağı tek işlemde
-tutarlı kalsın diye. **Silme bile gövdelidir.** Gateway barındırıcıyı okuyup gövdeye kendisi
-koyar; sen yalnız akışı verirsin.
+2026-09-14'ten beri `flow_create` / `flow_update` / `flow_delete` barındırıcının şemasına
+**dokunmaz**: gövde yalnız akıştır (silmede yalnız `id`). Eskiden gateway barındırıcının tam
+güncelleme komutunu da gönderiyordu; bu, her akış yazmasında sayfayı, layout'u ya da widget'ı
+baştan yazıyor ve açık bir Studio designer'ının kayıtlı tabanını eskitiyordu.
 
-Akışı bir komponente bağlamak ayrı adımdır:
+Akışı bir komponente bağlamak ayrı adımdır ve akış kaydedildikten **sonra** yapılır (layout'ta
+`layout_schema_patch`, widget'ta `component_schema_patch`, op'lar aynı):
 
 ```
 flow_create(host:'page', hostId:<pageId>, name:'Save order', slug:'save-order', steps:[…])
@@ -1368,18 +1408,13 @@ Sonradan akış eklemen gerekirse sayfayı baştan kurmana gerek yok — **bağ
 `eventValue: null` olay kaydını bırakıp değerini boşaltır ve kilidi açar.
 
 > **Aynı kilit LAYOUT'ta da vardır** (ölçüm 2026-08-18: menüye yeni bağlantı eklerken
-> `POST /layouts/<id>/flows` aynı hatayı verdi). Layout'un olayları komponentin kendi `events`
-> dizisinde satır içidir (`{ "name": "click", "value": "<flow id>" }`) ve `page_schema_patch`
-> layout'a uygulanmaz; çözüm de bu yüzden farklı yazılır:
+> `POST /layouts/<id>/flows` aynı hatayı verdi). Layout'ta sıra sayfadakiyle aynıdır ve bağlar
+> `layout_schema_patch` ile yazılır: `flow_create × N` → TEK `layout_schema_patch` (bütün
+> `set_event`'ler). Sıfırdan kurarken kilide takılmazsın (akışları bağlamadan önce yaratırsın).
 >
-> ```
-> 1) layout_update  → tüm komponentlerde "events": []   (bağları çöz)
-> 2) flow_create × N
-> 3) layout_update  → tam ağaç + bütün events'ler
-> ```
->
-> Sıfırdan kurarken kilide takılmazsın (akışları bağlamadan önce yaratırsın); kilit yalnız
-> **mevcut ve bağlı** bir layout'a yeni akış eklerken çıkar.
+> **Yeniden ölçülmeli (2026-09-14):** iki ölçüm de flow isteğinin barındırıcıyı baştan yazdığı
+> dönemdendi. Zarfsız istekte barındırıcı yazılmadığı için kilit kalkmış olabilir; ölçülene kadar
+> kuruluş sırasını koru.
 
 ## Kural 4 — Komponent güncellemesi slug ile, silme id ile
 
@@ -1559,6 +1594,21 @@ alanına dokunur. **Komponenti silip yeniden eklemeyin:** `remove_component` + `
 turu o komponente bağlı setter hedeflerini koparır (Kural 1e sonundaki not) ve komponentin tek
 referans verdiği akışları kalıcı olarak sildirir (Kural 2'deki yan etki notu).
 
+**Kurulu düğümün appearance'ını değiştirmek: `set_appearance`.** Aynı gerekçeyle appearance için
+de silip yeniden ekleme gerekmez:
+
+```jsonc
+{ "op": "set_appearance", "target": "box_summary", "appearance": { "heightType": "auto", "tooltip": null } }
+```
+
+Op **birleştirir**: yalnız verilen alanları yazar, gerisini korur; `null` alanı temizler (null
+kabul etmeyen `heightType` gibi alanlar hariç). Alan adları `page_schema_get`'in döndürdüğü
+appearance anahtarlarıdır; bilinmeyen alan `unknown-appearance-field`, tanınmayan ya da null
+kabul etmeyen değer (`heightType: "tall"`) `invalid-appearance` ile 422 döner ve yama atomik
+olduğu için hiçbir op yazılmaz. Kurulu düğümün `states` bayrakları için eşi `set_states`'tir.
+**`isHidden` bir appearance alanı DEĞİLDİR** — gizlemek için `replace_prop { prop: 'isHidden' }`
+ya da `set_binding { prop: 'isHidden' }` (Kural 7a'daki `isHidden` notu).
+
 **Kip ayrımı query parametresidir:** aynı sayfa `?id=<kayıt>` ile edit, parametresiz create.
 
 `mount` akışı (`page_container` ya da `form` üzerine bağlanır):
@@ -1671,10 +1721,12 @@ start → [setter] btn_save.isLoading = true
 > artık doğrudan `props.isHidden` yazılabilir; sırf gizlemek için `container`'a sarmak
 > GEREKMEZ. Tek doğru kaynak `component_get` + `page_schema_validate` kuru koşusudur.
 >
-> **`appearance.isHidden` bir kaçış yolu DEĞİLDİR:** kaydedilir ama runtime hiçbir yerde okumaz
-> (renderer yalnız `props.isHidden`'a bakar) — komponent görünmeye devam eder. Başlangıçta gizli
-> göstermek için ya komponenti `isHidden`'ı OLAN bir `container`'a sar (Kural 1g) ya da
-> görünürlüğü sayfa açılış akışının setter'ıyla kur.
+> **Appearance'ta `isHidden` alanı YOKTUR** (2026-09-15'te platformdan kaldırıldı, S-16): renderer
+> yalnız `props.isHidden`'a bakar. Başlangıçta gizli bildirim şemada
+> `"props": { "isHidden": { "type": "static", "data": true } }` ile kurulur, açılışı akıştaki
+> setter yapar. `add_component` / `page_update` gövdesine yine de `appearance.isHidden` konursa
+> gateway değeri `props.isHidden`'a taşır ve `gatewayNormalized`'da bildirir (prop zaten verilmişse
+> o kazanır); `set_appearance` ile `isHidden` yazmak istek gönderilmeden reddedilir.
 
 ### 7b — Liste → form geçişi
 
@@ -1797,8 +1849,9 @@ Komponentlerin **`style` prop'u** vardır ve iç parçalara iner (`textinput.sty
 `&__body`). Tasarım kararlarını buradan uygula — varsayılan görünümle bırakmak zorunda değilsin.
 
 > **Boyut tuzağı:** katalog varsayılan `size`'ı `maxSize`'ı aşan komponentler var
-> (`textinput` default `h:8`, `maxSize.h:5`). Varsayılanı körü körüne kopyalarsan doğrulayıcı
-> reddeder; gateway aşan değeri `maxSize`'a kırpar ve `gatewayNormalized` ile bildirir.
+> (`textinput` default `h:8`, `maxSize.h:5`). Boyut sınırı grid kanvasının kuralıdır, API
+> reddetmez; ama aşan blok kanvasta boyutlandırılamaz. Gateway aşan değeri `maxSize`'a kırpar ve
+> `gatewayNormalized` ile bildirir.
 
 ## Kural 8 — Korunan sayfa: `middlewareIds` vermeden `Page.user` YOKTUR
 
@@ -1859,11 +1912,49 @@ hiçbiri** bağlı değildi; üç portalın da rol menüsü boş çıkıyor, pan
 > `Host: <org>.<suffix>` + `X-Environment` başlıklarıyla. Ham `curl` yerine tool'u kullanmak
 > yeterlidir.
 >
+> **Kareyi GÖRMEDEN doğrulamak — önce bunu dene.** `page_screenshot` her yanıtta `summaryText`
+> döner: her kök düğüm için tek satır — kimlik (tip) · görünür/GİZLİ/ekran dışı · metnin ilk 80
+> karakteri · `rows=<satır>` · `tab=<açık sekme>` · `value=<kutudaki değer>` · `BOŞ` ·
+> `errors=<sayı>`, sonda toast ve hata mesajları. "Kart göründü mü, tablo doldu mu, hata var mı"
+> sorularının cevabı budur ve **kareye gerek yoktur**: `image: 'none'` ile kare hiç çekilmez.
+> Ölçüldü (2026-09-16, 40 satırlık tablo taşıyan sayfa): özet **416** karakter, aynı sayfanın
+> `fullPage` karesi **151 276** karakter. Görsel soru (renk, hizalama, referansa sadakat) için
+> kareyi al ama küçült: `clip: { element: '<elementId>' }` yalnız o bölgeyi keser, `scale: 0.5`
+> rasteri yarıya indirir (sayfa yine 1280 CSS pikselinde çizilir — kırılım noktaları kaymaz),
+> `format: 'jpeg'` + `quality: 60` ölçekle BİRLİKTE kazandırır (tek başına neredeyse hiç).
+> Aynı sayfayı yeniden koştururken `diff: true` neyin değiştiğini listeler ve
+> `image: 'ifChanged'` değişmemiş kareyi hiç göndermez. `summary: 'full'` yapısal `domSummary`
+> dizisini de verir; runtime `data-component-type` basmıyorsa tipler yazılmaz ve `summaryNote`
+> bunu söyler.
+>
+> **Sekme, açılır kutu, form.** `actions` sözlüğünde üç fiil daha var.
+> `{ action: 'tab', target: 'tabs_settings', value: 'iot' }` sekmeyi ANAHTARIYLA seçer — sekme
+> grubunun köküne `click` göndermek DOM sırasındaki İLK sekmeye gider ve bu yüzden artık
+> reddedilir. **Etkin olmayan sekmenin içeriği DOM'da yoktur**: o sekmedeki bir düğüme yazmadan
+> ya da onu kırpmadan önce `tab` adımı koy. `{ action: 'select', target: 'dd_city', value: '34' }`
+> açılır kutudan seçer (kutu native alan değildir; `set` de aynı yola devreder) ve seçenekler
+> sorgudan geliyorsa listeyi 3 sn'ye kadar bekler — `optionsSeen: 0` görürsen kusur kutuda değil
+> sorgudadır, `query_preview` ile bak. `{ action: 'submit', target: 'frm_note' }` formu gönder
+> butonu olmadan gönderir. Her adımın raporu `matchedBy` · `activeTab` · `optionsSeen` ·
+> `waitedMs` · `submitVia` ile ne olduğunu söyler.
+>
 > **Yerleşimi görüntüsüz ölçmek.** Taşma/çakışma şüphesinde `page_screenshot(layoutReport: true)`:
 > `layoutSummary.overflowing` boş değilse içeriğine sığmayan kutu, `outsideViewport` boş değilse
 > hiç görünmeyen düğüm var; `zeroSized` çizilmemiş komponenti gösterir. Runtime düğümleri
 > `data-element-id` basmıyorsa yanıt `layoutReportUnavailable` der — tool tahmin üretmez.
 >
+> **Sürükle-bırakı gerçekten sınamak (G-09).** `kanban` ve `eventcalendar` iç öğelerine
+> `<elementId>__<rol>` kimliği yazar (tablonun `__row-<n>`'i ile aynı kalıp):
+> kart `kb_board__card-<id>`, kolon `kb_board__col-<value>`; etkinlik `cal_plan__event-<id>`,
+> gün `cal_plan__day-<yyyy-MM-dd>`, tüm gün hücresi `cal_plan__allday-<yyyy-MM-dd>`, saat dilimi
+> `cal_plan__slot-<yyyy-MM-dd>T<HH>`. `id`, `idField`'ın değeridir (yoksa `card-<sıra>` /
+> `event-<sıra>`); tarih yereldir. Tıklama yolu `click` ile, taşıma `drag` ile sınanır:
+> `actions: [{ action:'drag', target:'kb_board__card-42', to:'kb_board__col-Assigned' }]`.
+> `actionsReport[].flowRuns`/`requests` sıfırsa `cardMove`/`eventMove` bağı kurulu görünse de
+> taşıma kalıcılaşmamıştır. Kaynak `draggable` değilse (`isDraggable`/`isEditable` kapalı)
+> adım `applied:false` ve notla döner. Çok günlü etkinlik aynı kimliği her gün hücresinde taşır;
+> hedef ilk eşleşmedir.
+>
 > **Üye kimliğiyle doğrulama (`asUser`).** Kapının kapalı olduğunu görmek yarısıdır; açık
 > olduğunu görmek diğer yarısı. `page_runtime_get` ve `page_screenshot` aynı `asUser` alanını
 > alır: uygulamanın kendi giriş ucundan (`microservice_execute`) aldığın üye jetonunu verirsin,
@@ -1951,10 +2042,22 @@ micro-op hattına dönün.
 >
 > **Gateway artık bunu söylüyor (FLOW-018).** `remove_component` içeren bir yamada gateway sayfanın
 > akışlarını okur ve silinen düğümü hedefleyen setter adımlarını uyarı olarak listeler: hangi akış,
-> hangi adım, hangi hedef. Uyarıyı gördüğünde yapılacak tek şey `flow_update` ile aynı gövdeyi
-> yeniden kaydetmektir. Ters yönü (`silinen düğümün referans verdiği` akışların platformca kalıcı
+> hangi adım, hangi hedef. Ters yönü (`silinen düğümün referans verdiği` akışların platformca kalıcı
 > silinmesi) ayrı bir uyarı kapsar; ikisi birlikte çıkabilir. Ölçüm 2026-09-04 (benchmark 4. koşu):
 > uyarı yokken aynı tuzak ~8 dakika teşhis aldı ve yalnız ekran görüntüsüyle görüldü.
+>
+> **Mekanizma ve onarım (2026-09-15, G-04).** Setter iteratee'si hedefini elementId olarak DEĞİL,
+> komponentin iç kimliği olarak saklar (`step_iterates.DesignComponentId`, FK `SetNull`); düğüm
+> yeni kimlikle yazılınca eski satır silinir ve alan boşalır — `flow_get` iteratee'yi `element`'siz
+> döndürür. Bu yüzden **`flow_get`'ten okunan gövdeyi aynen yeniden kaydetmek onarmaz** (element
+> zaten yok; `flow_update` FLOW-017'ye takılır). İki güvence var: (1) backend artık AYNI yamada
+> silinip aynı `elementId` ile eklenen düğüme (alt ağaç dahil) eski kimliğini geri veriyor, bağ
+> kopmuyor; (2) gateway yamadan sonra akışları yeniden okur ve kopan her iteratee için yanıtta
+> `flowTargetsLost` ile hazır onarımı verir:
+> `flow_patch` `{ op: 'add', path: '/steps[stepId=s4]/args/iteratees/0/element', value: 'f_range' }`.
+> `flow_get` de hedefsiz setter iteratee'sini `flowWarnings` (`FLOW-017 (okuma)`) ile gösterir.
+> Ayrı isteklerle (önce sil, sonra ekle) yapılan yeniden kurulum ve komple şema yazan `page_update`
+> bu korumanın DIŞINDADIR — prop tipini değiştirmek için düğümü hiç yeniden kurmayın.
 
 ## Bilinen sınırlar
 
@@ -2029,8 +2132,11 @@ micro-op hattına dönün.
   (süssüz) ekrana ifadenin **kendisini** basar; ifade yalnız `data`'da olursa prop **boş**
   render edilir. `set_binding` micro-op'u eski sürümlerde `data`'ya yazıyordu — bu davranış
   düzeltildi, ama daha önce kurulmuş sayfalarda kalıntı olabilir. Prop nesnesini birebir
-  kontrol etmen gerekirse `remove_component` + `add_component` ile
-  `{"type":"code","ref":"{{ … }}","data":"<yedek>"}` yaz; `replace_prop` her zaman `static` kurar.
+  kontrol etmen gerekirse `replace_prop` ile
+  `value: {"type":"code","ref":"{{ … }}"}` yaz — code tipi ve `ref` olduğu gibi kaydedilir
+  (platform code prop'unda `data`'yı saklamaz).
+  `replace_prop`'a `expression` alanı verme: platform onu yalnız `set_binding`'de okur (gateway
+  code sarmalına çevirir).
 
 - **Ana sayfa sayfadan değil application'dan değişir:** `page_create/update` gövdesindeki
   `isHomepage` platformca yok sayılır (tasarım). Doğru yol `application_update` →