@appaflytech/zeyrek-ai-mcp 0.0.5 → 0.0.7

package/dist/resources/guides/merge.md

@@ -0,0 +1,231 @@
+# Dal ve Merge Rehberi (environment dallanma)
+
+Kendi başına çalışabileceğin bir kopya aç, orada değiştir, sonra `development`'a geri birleştir.
+Deployment (`deployment_start`) bu işin dışındadır: o `development → production` yolu ve **insan
+onaylıdır**. Buradaki tool'ların hiçbiri production'a yazmaz.
+
+## Politika (değişmez)
+
+- **Merge hedefi her zaman dalın ebeveynidir.** Ebeveyn `development`'tır; başka bir hedef seçilemez.
+- **Production'a merge eden tool yoktur.** Production'a giden tek yol insan onaylı deployment'tır.
+- Sabit environment'lar (`development`, `production`) silinemez; `environment_delete` bunu HTTP'ye
+  gitmeden reddeder.
+
+## Akış
+
+```
+environment_create {projectId, name}        → 202, dal "creating"
+environment_list   {projectId}              → state "ready" olana kadar (30-60 sn)
+… tenant tool'larını environment: "<dal>" ile çağır (page_schema_patch, entity_patch, …)
+merge_plan   {projectId, sourceEnvironmentId} → 202, plan "planning"
+merge_get    {projectId, planId}              → status "planned" olana kadar
+merge_get    {projectId, planId, view:"conflicts"} → çakışanları oku
+merge_resolve{projectId, planId, resolutions[]}   → her çakışmaya source|target seç
+merge_apply  {projectId, planId, message}         → 202  (message ZORUNLU)
+merge_get    {projectId, planId}                  → status "applied"
+environment_list {projectId}                      → dal listede yok, şeması düştü
+```
+
+## Dalda çalışmak
+
+Dal adı `X-Environment` başlığının değeridir. Tenant tool'larına `environment: "odeme_akisi"`
+geçmek yeterlidir; `DEFAULT_ENVIRONMENT` yalnız varsayılandır. Dal `ready` değilken o dalda
+yazmaya çalışmak 400 döner — `environment_list` ile durumu doğrula.
+
+Dal açılırken **yalnız tanımlar** kopyalanır. `includeRecords: true` verirsen projenin kendi
+veritabanındaki **bütün** veri tablolarının satırları da gelir — entity'de kayıt taşıması ayarı
+açık olmasa bile (çok dilli companion tablolar ve junction'lar dahil; `files`/`folders` ve audit
+trail tabloları hariç, dış datasource'lara dokunulmaz). Kayıt taşıması ayarı deployment'ın
+(`promote`) kuralıdır ve orada aynen geçerlidir. **Satırlar merge'de geri taşınmaz** — merge yalnız
+tanım işidir.
+
+Dalda `page_screenshot` **çalışır** (2026-09-09'dan beri); ayrıntısı bir sonraki bölümde.
+
+## Dalda görsel doğrulama
+
+**Dalda kurulan sayfanın karesi dalda alınır** — `page_screenshot {..., environment: "<dal>"}`.
+Studio'nun runtime rotasının üç şeridi vardır ve **ortamı URL belirler**:
+
+| Ortam | Şerit |
+|---|---|
+| `production` | `/view/{proje}/{app}/{sayfa}` |
+| `development` | `/dev/{proje}/{app}/{sayfa}` |
+| dal | `/branch/{dal}/{proje}/{app}/{sayfa}` |
+
+Sayfanın **bütün** istekleri o dala gider: sayfa şeması da, akışların uç çağrıları da. Yani kare
+"yarı doğru" değildir — gördüğünüz ekran dalın gerçek ekranıdır.
+
+Reddedilen tek şey **dal adı olamayacak bir ad**: harfle başlamayan, küçük harf/rakam/alt çizgi
+dışında karakter taşıyan, 3-31 aralığının dışına çıkan ya da rezerve bir ad (`public`, `api`,
+`pg_*` …). Projedeki dalları `environment_list` verir.
+
+2026-09-09 öncesinde bu çağrı **reddediliyordu**: runtime rotası dal adı taşımıyordu, ortam
+modül içi bir store'dan geliyordu ve dal adıyla istenen kare development'ı gösterirdi. O günlerin
+alışkanlığı olan "dalda `page_schema_get` + `page_runtime_get`, kare merge sonrasına" zinciri
+hâlâ geçerli bir doğrulama yoludur, ama artık **zorunlu değildir**.
+
+`page_schema_get` (komponent ağacı, prop ve olay bağları) ile `page_runtime_get` (akışlar,
+değişkenler, çözülen ref'ler) kareyi tamamlar: kare ne çizildiğini, bu ikisi neden öyle
+çizildiğini söyler.
+
+## Planı okumak
+
+`merge_get` üç görünüm sunar; varsayılan `conflicts`:
+
+| view | ne döner |
+|---|---|
+| `summary` | yalnız sayaçlar (`added/updated/deleted/conflicts/unresolved/dataRisk`) |
+| `conflicts` | yalnız çakışan kayıtlar ve onların çakışan elemanları |
+| `full` | değişen her kayıt ve her eleman |
+
+`items[]` yalnız **değişen** kayıtları taşır. Her kayıtta:
+
+- `kind`: `add` | `update` | `delete` | `conflict`
+- `dataRisk`: entity kaleminde veri riski var — **sebep `dataRiskReasons[]` içindedir**
+- `derivedFromKey`: kalem OTOMATİK ÜRETİLMİŞ bir kayıtsa (varsayılan DTO) kaynağının anahtarı
+- `elements[]`: `path`, `kind`, `base`, `source` (dal), `target` (development), `resolution`
+
+`dataRisk` bir **uyarıdır, apply'ı bloklamaz**; üç sebepten biriyle doğrudur:
+
+| `dataRiskReasons` | Ne demek |
+|---|---|
+| `field-removed` | Alan siliniyor |
+| `field-narrowed` | Tip / `nullable` / `unique` daraltılıyor |
+| `not-null-without-default-on-populated-table` | **Hedefte satır varken** varsayılansız zorunlu alan ekleniyor — bu apply'ı DDL aşamasında düşürür. Alanı `nullable` yapın ya da `defaultValueType: "default-value"` + `defaultValue` verin |
+
+Son satır 2026-09-09'da eklendi; öncesinde bu durum `dataRisk: 0` diyordu ve risk ancak apply
+denenerek öğreniliyordu. Hedef tablo **boşsa** aynı alan riskli sayılmaz.
+
+`derivedFromKey` dolu olan kalemi ayrıca çözmeye çalışmayın: kaynağını (entity ya da query)
+çözdüğünüzde aynı yoldaki çakışması **kendiliğinden** aynı tarafa çözülür. Entity adını değiştiren
+bir merge'de entity ve onun varsayılan DTO'su böylece zıt çözülemez.
+
+`add` / `update` / `delete` elemanları **otomatik alınır** — karar istemezler. Yalnız `conflict` ve
+`order-conflict` elemanları `merge_resolve` bekler.
+
+## Çakışma çözmek
+
+```json
+{ "itemKey": "page:8f1c…", "path": "components[elementId=btn_save].props[name=label].ref", "choice": "source" }
+```
+
+`path` boş bırakılırsa o kaydın **tüm** çakışmaları aynı tarafa çözülür. `source` = dal,
+`target` = development.
+
+`merge_resolve` **özet döner** — `{ planId, status, summary, resolved }`. Planın kendisi yanıtta
+yoktur; kalan çakışmalar için `merge_get {planId, view:"conflicts"}` çağırın.
+`summary.unresolved` 0 olduğunda `merge_apply` yolu açıktır.
+
+## Apply'ın reddettiği üç durum
+
+| Durum | Kod | Ne yapmalı |
+|---|---|---|
+| Çözülmemiş çakışma var | 409 | `merge_get view:"conflicts"` → `merge_resolve` → tekrar `merge_apply` |
+| Development plan alındığından beri değişti | 409 | `merge_plan` ile **yeniden planla**; eski planı uygulama |
+| Plan 24 saatten eski | 400 | yeniden planla |
+
+Aynı `merge_apply` çağrısını tekrarlamak sonucu değiştirmez — 409 geçici bir hata değildir.
+
+## Mesaj zorunludur
+
+`merge_apply` mesajsız çalışmaz. Mesaj plana yazılır, plan uygulandıktan sonra da durur ve
+geçmişte bu mesajla görünür — git'teki merge commit mesajının karşılığıdır.
+
+- Boş ya da yalnız boşluktan oluşan mesaj **şema katmanında** reddedilir; istek platforma hiç gitmez.
+- En fazla 200 karakter.
+- Kalıp: `<dal> → development: <amaç>`. Ne yaptığını yaz, "merge" yazma.
+
+Gateway senin yerine mesaj **uydurmaz**: ne değiştirdiğini bilen sensin.
+
+## Geri almak
+
+Uygulanmış bir merge silinmez, **ters bir planla** geri alınır:
+
+```
+merge_revert {projectId, planId, message}   → 202, ters plan planning
+merge_get {projectId, planId: <ters plan>}  → status planned olana kadar
+merge_apply {projectId, planId: <ters plan>, message}
+```
+
+Bittiğinde ters plan `applied`, kaynak plan `reverted` olur; ikisi de geçmişte durur.
+
+Üç şey normal merge'den farklıdır:
+
+- **Sütunların anlamı terstir.** Ters planın `elements` satırlarında `source` merge **öncesi**
+  değer, `target` **şimdiki** değerdir. Bir kaydı merge'den sonra elle değiştiren biri olduysa o
+  satır `conflict` gelir; `source` seçmek geri almayı, `target` seçmek o kaydı olduğu gibi bırakmayı
+  seçer.
+- **Pencere vardır.** `RevertWindowDays` (varsayılan 7 gün) dolduğunda 400 döner, çünkü merge
+  öncesi anlık görüntü de aynı pencereyle silinir. Uygun bir plan için `merge_list status:'applied'`.
+- **Ters planın ters planı yoktur.** `kind=revert` bir planı geri almaya çalışmak 400 verir; aynı
+  değişikliği tekrar istiyorsanız dalı yeniden merge edin.
+
+Geri alma reddedildiğinde **mesaj hangi kapıya takıldığını söyler** — üçünü karıştırmayın
+(2026-09-09'dan beri üç ayrı cümle; öncesinde üçü de aynı cümleyi veriyordu):
+
+| Ne denendi | Mesaj ne der | Ne yapılır |
+|---|---|---|
+| `kind=revert` bir planı geri almak | "A revert plan cannot itself be reverted" | Ters planın geri aldığı **kaynak planı** geri alın ya da dalı yeniden merge edin |
+| Hiç uygulanmamış plan (`planned`, `failed`, `discarded`) | "this plan is '<durum>'" — planın **gerçek durumu** cümlede | `merge_list status:'applied'` ile uygulanmış planı seçin |
+| Zaten geri alınmış plan | aynı cümle, **`this plan is 'reverted'`** | Geri alma zaten yapılmış; ters planı `merge_get` ile görün |
+
+## Geçmişi okumak
+
+Merge sonrası hedefte dokunulan kayıtlar revizyon defterine `source: merge` ile düşer:
+`revision_list {projectId, module, recordId}` bir kaydın merge ile mi yoksa elle mi değiştiğini
+söyler, `revision_diff` ise ne değiştiğini.
+
+
+`merge_list` projenin merge planlarını en yeniden eskiye verir:
+
+```
+merge_list {projectId}                          → son planlar (her durumdan)
+merge_list {projectId, status:"applied"}        → uygulanmış merge'ler
+merge_list {projectId, environmentId:"<env>"}   → o environment'ı kaynak ya da hedef alan planlar
+```
+
+`items[]` bu uçta **her zaman boştur** — bir planın değişiklik listesi için `merge_get`.
+Satırda `message`, `createdBy` (planı alan), `appliedBy` (uygulayan), `appliedAt` ve
+`summary` sayaçları gelir. Sayfalama `pageIndex` / `pageLength` ile.
+
+Bir kaydın neden değiştiğini ararken sıra: `merge_list status:"applied"` → ilgili satırın
+`id`'si → `merge_get {planId, view:"full"}`.
+
+`activity_list` daha geniştir: dal açma/silme, plan alma/çözme/uygulama ve dağıtım aynı akışta.
+
+```
+activity_list {projectId}                              → tüm geçmiş, en yeni önce
+activity_list {projectId, kind:"merge.applied"}        → yalnız uygulanmış merge'ler
+activity_list {projectId, environmentId:"<env>"}       → o dalın hikâyesi
+activity_list {projectId, userId:"<id>"}               → bir kişinin yaptıkları
+```
+
+Her satırda `actor`, `actorSource` (`human` | `ai` | `system`) ve türe göre değişen bir
+`summary` vardır. **Bu gateway üzerinden yaptığın her iş `actorSource: "ai"` olarak düşer** —
+istekler `X-Client: mcp` başlığı taşır. Merge satırlarında `subjectId` plan id'sidir;
+ayrıntı için `merge_get`.
+
+## Merge bittikten sonra
+
+**Cache için elle bir şey yapmanız gerekmez (2026-09-09'dan beri).** Merge, dokunduğu entity'lerin
+`entityId:` / `entityApi:` / `entityRelationId:` anahtarlarını hedef ortamda **merge biter bitmez**
+yeniden kurar; dalda kurulmuş join'li bir microservice `development`'ta ilk çağrıda çalışır.
+Öncesinde entity anahtarları yalnız geçersizleştiriliyor, yeniden kurulmuyordu ve uç
+`Sequence contains no matching element` ile **500** veriyordu — kurtulmanın tek yolu entity'ye
+anlamsız bir `entity_patch` atmaktı. Cache yenileme hatası merge'i düşürmez: `cacheError`'a yazılır,
+plan `applied` kalır.
+
+- `applied` → dal `merged` olur ve **şeması düşer**; `environment_list` artık göstermez.
+- `applied-with-drift` → dal ve şeması **durur**. `verification.driftTables` dal ile development
+  arasında hâlâ farklı olan tabloları listeler; incelenmeden dal silinmez.
+- `failed` → plan `failed`, dal `ready`'ye döner. Dal ve içindeki iş kaybolmaz; yeniden planlanır.
+
+## Sınırlar
+
+- Projede aynı anda **tek** açık merge planı olur. Yenisini istemeden önce `merge_apply` ya da
+  `merge_discard`.
+- Merge sürerken dal ve development'a yazma kilitlidir; **diğer dallar etkilenmez**.
+- Proje başına açık dal sayısı sınırlıdır (varsayılan 5) — sınır bağlantı bütçesidir, ürün kararı
+  değil.
+- Dal adı `^[a-z][a-z0-9_]{2,30}$` kuralına uyar ve şema adı olur; `development`, `production`,
+  `public`, `pg_*` gibi adlar rezervedir.

package/dist/resources/guides/microfunction.md

@@ -0,0 +1,166 @@
+# Microfunction Rehberi
+
+Microfunction, kullanıcının yazdığı **tek bir fonksiyonun** platformun dışında, kendi
+runtime'ında koşmasıdır: Node ya da Python kodu kaydedilir, yayınlanır, workflow adımı onu
+çağırır ve çıktısı sonraki adımlara akar. Platformun JavaScript ifade motoru (global function'lar,
+code step) sürecin İÇİNDE koşar; microfunction ise ayrı bir runtime'dadır — bu yüzden ağır iş,
+üçüncü parti kütüphane ve zaman aşımı riski taşıyan işler oraya taşınır.
+
+Kayıtlar **proje + environment** kapsamlıdır (`development` ile `production` ayrı kayıtlardır);
+`microfunction_list` bir uygulamaya değil projeye bakar. Süzme ve sayfalama uçta yapılır:
+`searchTerm` ad, slug ve açıklamada arar, `status` durum süzgecidir, `pageIndex`/`pageLength` sayfa
+verir (gateway kendi çağrısında 200 gönderir; platform varsayılanı 10'dur).
+
+## Ne zaman microfunction, ne zaman code step
+
+| İhtiyaç | Doğru yer |
+|---|---|
+| Birkaç satır dönüşüm, alan eşleme, koşul | `code` step / ifade (aynı süreç, en ucuz) |
+| İfadelerde çıplak adla çağrılacak yardımcı | global function (`global_function_create`, JS) |
+| Kütüphane gerektiren iş (kriptografi, PDF, görüntü, parse) | microfunction (zip kaynak) |
+| Python gereken iş | microfunction — platformun ifade motoru YALNIZ JavaScript'tir |
+| Uzun süren/CPU yiyen iş | microfunction (kendi bütçesi, API sürecini bloke etmez) |
+
+Global function'lar JS'tir ve Python fonksiyonlarına bağlanmaz; microfunction çağrısı yalnız
+workflow adımından (ve test için `microfunction_invoke`'tan) yapılır.
+
+## Çalışma zamanı sözleşmesi (protocol 1)
+
+Kullanıcı kodu **tek bir handler** dışa aktarır. Inline kaynakta dosya adı SABİTTİR: Node'da
+`function.js`, Python'da `function.py`; entrypoint `function.handler`'dır ve gönderilmez.
+
+```js
+// node — function.js
+exports.handler = async (args, context) => {
+  return { total: args.a + args.b, environment: context.environment }
+}
+```
+
+```python
+# python — function.py
+def handler(args, context):
+    return {"total": args["a"] + args["b"], "environment": context["environment"]}
+```
+
+- `args` — adımın `rule.expression`'ından üretilen argüman nesnesi. Fonksiyonun
+  `parameterDtoId`'si yoksa `{}` gelir.
+- `context` — **salt okunur anlık görüntü**. İçine yazmak hiçbir şeyi değiştirmez; akışa dönen
+  tek kanal fonksiyonun DÖNÜŞ DEĞERİdir.
+
+`context` şekli (ölçüldü, `MicrofunctionStep.BuildContext`):
+
+```jsonc
+{
+  "input": {},                    // akışın parameterDto girdisi
+  "variables": {},                // workflow değişkenleri (middleware'in kurduğu 'user' dahil)
+  "steps": { "<adım adı>": { "data": {}, "error": { "code": null, "message": null, "type": null } } },
+  "user": { "id": "…", "email": "…", "roles": [] },
+  "request": { "headers": {}, "queryString": {} },
+  "triggerSource": {},
+  "language": "tr",
+  "project": "<proje slug'ı>",
+  "environment": "development"
+}
+```
+
+**`request` yalnız `headers` + `queryString` taşır** ve `authorization` · `cookie` ·
+`x-impersonated-user-id` başlıkları AYIKLANIR (ölçüldü 2026-09-10) — token'ı fonksiyona taşımaya
+çalışmayın, taşınmaz. Çerez okuma yolu yoktur.
+
+Yanıt zarfını shim üretir; `microfunction_invoke` bunu olduğu gibi döner:
+
+```jsonc
+{ "protocol": 1, "ok": true, "output": { "total": 3 }, "error": null, "logs": [], "durationMs": 12 }
+```
+
+- `ok: false` ⇒ `error: { type, message, stack }` ve adım **fail dalına** düşer.
+- `logs` yalnız `preview: true` çağrılarında dolar (`console.log` / `print` yakalanır). Normal
+  koşumda log toplanmaz — hata ayıklarken `microfunction_invoke(preview: true)` kullanın.
+- İstek gövdesi (args + context) 5 MB'ı aşarsa adım `MicrofunctionPayloadTooLargeException` ile
+  fail dalına düşer: bütün tabloyu fonksiyona geçirmeyin, işi fonksiyona taşıyacak kadarını geçirin.
+
+## Yaşam döngüsü: kayıt yayınlanmadan ÇALIŞMAZ
+
+```
+draft ──publish──▶ publishing ──▶ published ──update──▶ published + hasUnpublishedChanges
+                        └────────▶ publish-failed (publishError)
+```
+
+1. `microfunction_create` kaydı **draft** açar. `publish: true` verirseniz aynı çağrıda yayın istenir.
+2. Yayın **asenkrondur**: çağrı `publishing` döner, kuyruk paketi runtime'a kurar ve bir `probe`
+   çağrısıyla duman testi yapar. Sözdizimi/import hatası **yayın anında** `publish-failed` olur —
+   koşumda değil. Durumu `microfunction_get` ile birkaç saniye arayla okuyun.
+3. Yayındaki kaydı `microfunction_update` ile değiştirirseniz runtime **ESKİ sürümü koşmaya
+   devam eder**: `hasUnpublishedChanges: true` olur (`revision` ≠ `publishedRevision`). Yeni kodu
+   canlıya almak için `microfunction_publish`.
+4. `microfunction_delete` runtime'daki fonksiyonu da kaldırır; bir workflow adımı kaydı
+   kullanıyorsa 400 ile reddedilir.
+
+## Workflow adımı (WF-MF-001)
+
+Adım tipi `microfunction`; `workflow`, `automation` ve `middleware` akışlarının hepsinde
+kullanılabilir. Kuralı iki alan taşır:
+
+```jsonc
+{
+  "id": "<GUID>",
+  "name": "toplam",
+  "type": "microfunction",
+  "description": "İki sayıyı microfunction'da toplar.",
+  "rule": {
+    "microfunctionId": "<published kaydın id'si>",
+    "expression": "({ a: input.a, b: input.b })"
+  },
+  "branches": [
+    { "id": "<GUID>", "name": "success", "type": "success", "nextStepId": "<sonraki adım>" },
+    { "id": "<GUID>", "name": "fail", "type": "fail", "nextStepId": "<hata adımı>" }
+  ]
+}
+```
+
+- `microfunctionId` **zorunludur** ve gateway kaydı çağrıdan önce okur: durum `published` değilse
+  (ya da kayıt o ortamda yoksa) istek platforma GÖNDERİLMEZ. Adım taslak bir fonksiyona bağlıysa
+  akış kaydedilir, koşar ve sessizce fail dalına düşer (`MicrofunctionNotPublishedException`) —
+  ön-denetimin varlık sebebi budur.
+- `expression` argüman nesnesini üreten JavaScript ifadesidir; şemayı `microfunction_get`
+  çıktısındaki `parameterScheme` verir. Fonksiyonun parametre DTO'su varken ifade boşsa gateway
+  uyarır (fonksiyon `args` içinde hiçbir alan göremez).
+- Çıktı sonraki adımlara `Steps.<adım adı>.data` ile akar; şemasını `returnDtoId` belirler.
+- Adım **senkrondur**: akış fonksiyon dönene kadar bekler. Zaman aşımı fonksiyonun
+  `timeoutSeconds` bütçesidir, aşılırsa fail dalı.
+- `workflow_preview` adımı GERÇEK runtime'da koşturur; preview'ın rollback garantisi fonksiyonun
+  dış dünyada yaptığı işi geri ALMAZ.
+
+Tam gövde örneği: `ngapps://examples/microfunction-node-sum`.
+
+## Built-In ve AWS Lambda farkı
+
+| | `built-in` | `aws-lambda` |
+|---|---|---|
+| Nerede koşar | Platformun kendi Fission kümesi | Müşterinin AWS hesabı |
+| Runtime kaydı | YOK — `runtimeId` verilmez | `microfunction_runtime_create` ile zorunlu |
+| Zaman aşımı tavanı | 300 s | 900 s |
+| `memoryMb` | kaydedilir, küme limiti geçerlidir | gerçekten uygulanır |
+| Ölçüm alanları | `billedDurationMs`/`memoryUsedMb` boş | Lambda raporundan dolar |
+
+`azure-functions` enum'da tanımlıdır ama v1'de reddedilir (Faz 2). Lambda hesabı kimlik
+bilgilerini düz metin tutar (Datasource emsali) ve DTO'da maskeli döner — dar yetkili bir IAM
+kullanıcısı verin, `roleArn` fonksiyonun koşacağı execution rolüdür ve **zorunludur** —
+deseni tutmayan hesap gateway'de durur (MFR-001, block). Kaydettikten sonra
+`microfunction_runtime_test_connection` ile doğrulayın.
+
+## Sınırlar (v1)
+
+- **Bağımlılık build'i yok:** inline kod yalnız standart kütüphanedir; bağımlılık zip içinde gelir.
+- **MCP'den zip yükleme ve indirme yok** (`sourceKind: 'archive'` kaydı açılabilir, dosya
+  Studio'dan yüklenir) — Faz 2. Yüklenmiş zip platform ucunda okunabilir durumdadır
+  (`GET /{proje}/microfunctions/{id}/archive`, `application/zip`) ve Studio inspector'ında bir
+  indirme düğmesi taşır.
+- `timeoutSeconds` ve `memoryMb` komutta non-nullable int'tir: **göndermezseniz 0 gider ve platform
+  422 döner.** Gateway değer uydurmaz, eksikliği çağrıdan önce söyler (MF-001, block; ürün
+  varsayılanları 30 / 256). Aynı kural provider ↔ `runtimeId` eşleşmesini, inline kaynakta `code`
+  zorunluluğunu ve env anahtarlarını da çağrıdan önce denetler.
+- Env değişkenleri düz metin saklanır; anahtar `^[A-Z_][A-Z0-9_]*$`, toplam ≤ 4 KB. Sır yönetimi
+  için kullanmayın.
+- Asenkron (fire-and-forget) çağrı, preview ekranı, microservice'in doğrudan microfunction kaynağı
+  olması ve metering Faz 2'dedir.