@stechquick/studio-cli 4.2.0-0 → 4.2.0-1

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/end.md

@@ -0,0 +1,16 @@
+# end
+
+Terminates a path. At least one per flow; several are fine (one per branch). When the flow reaches an `end`, whatever sits in `flow.output` at that moment is the result returned to the caller.
+
+Ports: one input port `"_"`, no outputs.
+
+## Props
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"End"`. |
+
+```json
+{ "ID": "1", "sp": { "x": 754, "y": 271 }, "name": "end", "version": "0.8",
+  "props": { "label": "End" } }
+```

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/restServiceCall.md

@@ -0,0 +1,33 @@
+# restServiceCall (Rest Service)
+
+Calls a [restService](../../../../platform/models/rest-service-syntax.md) model. Panel label **Rest Service**.
+
+Ports: `"_"` in, `"_"` out.
+
+## Props
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"Rest Service"`. |
+| `type` | yes | Always `"referenced"`. |
+| `id` | yes | `<<restService:Owner/Path/Name>>`. |
+| `ignoreErrorAndContinue` | yes | `false` by default. `true` = a non-2xx / failed call does not abort the flow — you then must check `responseStatus` yourself. |
+| `mapping` | yes | Callee contract **plus** `"props": { "httpMethod": … }`. The method must be one the service model declares (`GET \| POST \| PUT \| DELETE \| PATCH`). |
+
+```json
+{ "ID": "3", "sp": { "x": 443, "y": 166 }, "name": "restServiceCall", "version": "0.8",
+  "props": { "label": "Call GetUser API", "type": "referenced",
+             "id": "<<restService:services/GetUser>>", "ignoreErrorAndContinue": false,
+             "mapping": {
+               "inParamMapping":  [ { "variable": { "type": "input",  "value": "userId" },
+                                      "mapping":  { "type": "input",  "value": "userId" } } ],
+               "outParamMapping": [ { "variable": { "type": "output", "value": "response" },
+                                      "mapping":  { "type": "vars",   "value": "rawUser" } },
+                                    { "variable": { "type": "output", "value": "responseStatus" },
+                                      "mapping":  { "type": "vars",   "value": "status" } } ],
+               "props": { "httpMethod": "GET" } } } }
+```
+
+Mapping sources follow the general rule: a caller-side value may be a store reference, a literal, or a `constant` reference (`{ "type": "constant", "value": "<<constant:…>>" }`). Service inputs that exist to carry a key or a fixed header value are usually fed that way rather than from the flow's own inputs.
+
+**The response-extraction idiom:** a service `response` is a structured object — land it in a `vars` member, then a follow-up `code` step assigns the scalars the flow actually outputs (`flow.output.fullName = flow.vars.rawUser.fullName`). Map `responseStatus` and check it (or set `ignoreErrorAndContinue` deliberately) before trusting the payload.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/s3FileDelete.md

@@ -0,0 +1,27 @@
+# s3FileDelete (S3 File Delete)
+
+Deletes an object from S3-compatible storage by its storage handle.
+
+Ports: `"_"` in, `"_"` out.
+
+## Props
+
+Inputs are expressions — `{ type, value }` with `type` one of `string`/`input`/`context`/`vars`/`constant`.
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"S3 File Delete"`. |
+| `storageHandle` | yes | The handle identifying bucket + key: the two joined by a slash, split on the **first** one, so `bucket/folder/file.pdf` means bucket `bucket` and key `folder/file.pdf`. A handle with no slash is rejected. It is built after the upload ([s3FileUpload](s3FileUpload.md#the-storage-handle)), not returned by it. |
+| `accessKeyId`, `secretAccessKey`, `endpoint`, `region` | yes | Storage credentials/endpoint — constants, as in [s3FileUpload](s3FileUpload.md). |
+
+```json
+{ "ID": "4", "sp": { "x": 500, "y": 200 }, "name": "s3FileDelete", "version": "0.8",
+  "props": { "label": "Delete attachment",
+             "storageHandle":   { "type": "input",    "value": "storageHandle" },
+             "accessKeyId":     { "type": "constant", "value": "<<constant:Owner/Constants/S3AccessKey>>" },
+             "secretAccessKey": { "type": "constant", "value": "<<constant:Owner/Constants/S3SecretKey>>" },
+             "endpoint":        { "type": "constant", "value": "<<constant:Owner/Constants/S3Endpoint>>" },
+             "region":          { "type": "constant", "value": "<<constant:Owner/Constants/S3Region>>" } } }
+```
+
+No output props — the step succeeds or throws.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/s3FileDownload.md

@@ -0,0 +1,27 @@
+# s3FileDownload (S3 File Download)
+
+Downloads an object from S3-compatible storage by its storage handle.
+
+Ports: `"_"` in, `"_"` out.
+
+## Props
+
+Inputs are expressions — `{ type, value }` with `type` one of `string`/`input`/`context`/`vars`/`constant`.
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"S3 File Download"`. |
+| `storageHandle` | yes | The handle identifying bucket + key — bucket and key joined by a slash, split on the **first** one ([s3FileUpload](s3FileUpload.md#the-storage-handle)). Usually taken from where the file was recorded, e.g. `processInstance.files[…].storageHandle`. |
+| `accessKeyId`, `secretAccessKey`, `endpoint`, `region` | yes | Storage credentials/endpoint — constants, as in [s3FileUpload](s3FileUpload.md). |
+| `fileBodyResponse` | yes | Write target `{ "type": "output" \| "vars", "value": … }` — receives the file content (byte array). |
+
+```json
+{ "ID": "3", "sp": { "x": 500, "y": 200 }, "name": "s3FileDownload", "version": "0.8",
+  "props": { "label": "Download attachment",
+             "storageHandle":   { "type": "input",    "value": "storageHandle" },
+             "accessKeyId":     { "type": "constant", "value": "<<constant:Owner/Constants/S3AccessKey>>" },
+             "secretAccessKey": { "type": "constant", "value": "<<constant:Owner/Constants/S3SecretKey>>" },
+             "endpoint":        { "type": "constant", "value": "<<constant:Owner/Constants/S3Endpoint>>" },
+             "region":          { "type": "constant", "value": "<<constant:Owner/Constants/S3Region>>" },
+             "fileBodyResponse": { "type": "output", "value": "fileBody" } } }
+```

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/s3FileUpload.md

@@ -0,0 +1,48 @@
+# s3FileUpload (S3 File Upload)
+
+Uploads a file body to S3-compatible storage. Companion steps: [s3FileDownload](s3FileDownload.md), [s3FileDelete](s3FileDelete.md).
+
+Ports: `"_"` in, `"_"` out.
+
+## Props
+
+All inputs are expressions — `{ type, value }` with `type` one of `string`/`input`/`context`/`vars`/`constant`. Credentials normally come from `constant` references, never hard-coded strings.
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"S3 File Upload"`. |
+| `bucketName` | yes | Target bucket. An empty value makes the runtime **create** a bucket and use it. |
+| `fileLabel` | yes | The object key the file is stored under. |
+| `fileBody` | yes | The file content (usually a `vars`/`input` reference). |
+| `accessKeyId`, `secretAccessKey`, `endpoint`, `region` | yes | Storage credentials/endpoint. |
+| `bucketNameResponse` | yes | Write target `{ "type": "output" \| "vars", "value": … }` — receives the bucket name actually used, written **before** the transfer, so a value there proves the bucket was resolved and nothing more. |
+| `policy` | no | `{ version?, statements: [{ sid, effect: "Allow" \| "Deny", principal, action, resource }] }` — bucket policy applied after upload. Rare; omit unless the flow already has one. |
+
+```json
+{ "ID": "7", "sp": { "x": 500, "y": 200 }, "name": "s3FileUpload", "version": "0.8",
+  "props": { "label": "Upload attachment",
+             "bucketName":      { "type": "constant", "value": "<<constant:Owner/Constants/FileBucket>>" },
+             "fileLabel":       { "type": "vars",     "value": "storageKey" },
+             "fileBody":        { "type": "input",    "value": "fileBody" },
+             "accessKeyId":     { "type": "constant", "value": "<<constant:Owner/Constants/S3AccessKey>>" },
+             "secretAccessKey": { "type": "constant", "value": "<<constant:Owner/Constants/S3SecretKey>>" },
+             "endpoint":        { "type": "constant", "value": "<<constant:Owner/Constants/S3Endpoint>>" },
+             "region":          { "type": "constant", "value": "<<constant:Owner/Constants/S3Region>>" },
+             "bucketNameResponse": { "type": "vars", "value": "bucketName" } } }
+```
+
+## What the step does not tell you
+
+**A failed transfer does not stop the flow.** The upload itself swallows its error and the step moves on regardless, so the next step runs as if the file were stored. What does throw is the surrounding work: unusable credentials or endpoint, and a named bucket that does not exist. Checking `bucketNameResponse` afterwards proves neither — it is set before the transfer starts.
+
+So a flow that must not continue on a lost file cannot rely on the step alone. Confirm the object is really there — an [s3FileDownload](s3FileDownload.md) of the key just written is the cheap version — and raise the error yourself when it is missing. Where the consequence of a silently missing file is small, say so in the step's label rather than pretending it was verified.
+
+## The storage handle
+
+`bucketNameResponse` gives the bucket, `fileLabel` is the key, and the handle the other two steps take is the two joined by a slash:
+
+```ts
+flow.output.storageHandle = flow.vars.bucketName + "/" + flow.vars.storageKey;
+```
+
+The split is on the **first** slash, so a key may contain further slashes and a handle without one at all is rejected. Build it in the `code` step after the upload — nothing hands it to you ready-made.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/set.md

@@ -0,0 +1,37 @@
+# set (Set)
+
+Assigns values to store members without writing script. Panel label **Set**. One box holds any number of assignments and performs them in order.
+
+A `code` step does the same work with fewer boxes and room for the conditions these assignments usually grow into — prefer it, and reach for `set` when a flow already uses it or when a single assignment would otherwise need a whole script box.
+
+Ports: `"_"` in, `"_"` out.
+
+## Props
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"Set"`. |
+| `items` | yes | The assignments, in execution order. `[]` is legal and does nothing. |
+
+Each item is `{ "variable": <target>, "assignee": <source> }`, both expressions:
+
+| Side | Allowed `type` |
+|------|----------------|
+| `variable` (target) | `output`, `vars` |
+| `assignee` (source) | `input`, `context`, `output`, `vars`, and the literals `string`, `number`, `boolean` |
+
+```json
+{ "ID": "3", "sp": { "x": 520, "y": 200 }, "name": "set", "version": "0.8",
+  "props": { "label": "Prepare totals",
+             "items": [ { "variable": { "type": "vars",   "value": "retryCount" },
+                          "assignee": { "type": "number", "value": "0" } },
+                        { "variable": { "type": "output", "value": "customerName" },
+                          "assignee": { "type": "input",  "value": "customer.fullName" } } ] } }
+```
+
+Notes:
+
+- The target may address a nested position — `"summary.total"`, `"lines[0].code"` — and the missing objects and arrays along the way are created for you.
+- The source may read a nested position the same way.
+- A target with an empty `value` assigns nothing. The item is silently skipped, so an unfinished assignment left in the list will not announce itself at runtime.
+- Assignments run top to bottom and see each other's results, so a later item may read what an earlier one wrote.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/soapServiceCall.md

@@ -0,0 +1,5 @@
+# soapServiceCall (Soap Service — Legacy)
+
+**Deprecated.** The editor lists it as "Soap Service (Legacy)". Same prop shape as [soapServiceCallV2](soapServiceCallV2.md) but bound to the legacy SOAP service model.
+
+Never author it in new flows — use `soapServiceCallV2`. When editing a flow that already contains one, leave the step as found or migrate it to V2 together with its service model.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/soapServiceCallV2.md

@@ -0,0 +1,39 @@
+# soapServiceCallV2 (Soap Service)
+
+Calls a [soapService](../../../../platform/models/soap-service-v2-syntax.md) model. Panel label **Soap Service**. This is the current SOAP step — never author the legacy [soapServiceCall](soapServiceCall.md).
+
+Ports: `"_"` in, `"_"` out.
+
+## Props
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"Soap Service"`. |
+| `type` | yes | Always `"referenced"`. |
+| `id` | yes | `<<soapServiceV2:Owner/Path/Name>>` — the token matches the model type, so a V2 service is never referenced as `soapService` (that tag belongs to the legacy model). |
+| `version` | yes | Editor-written, `""`. |
+| `mapping` | yes | Callee contract — [flow-syntax.md](../flow-syntax.md#mappings). No `props` block (unlike REST). |
+
+```json
+{ "ID": "5", "sp": { "x": 460, "y": 200 }, "name": "soapServiceCallV2", "version": "0.8",
+  "props": { "label": "Lookup customer", "type": "referenced", "version": "",
+             "id": "<<soapServiceV2:Owner/Services/CustomerLookup>>",
+             "mapping": {
+               "inParamMapping":  [ { "variable": { "type": "input",  "value": "customerNo" },
+                                      "mapping":  { "type": "input",  "value": "customerNo" } } ],
+               "outParamMapping": [ { "variable": { "type": "output", "value": "response" },
+                                      "mapping":  { "type": "vars",   "value": "soapResponse" } } ] } } }
+```
+
+Same response-extraction idiom as [restServiceCall](restServiceCall.md): land the structured `response` in a var, unpack it in a `code` step.
+
+## A failed call does not stop the flow
+
+The step catches whatever the call throws — an unreachable host, a timeout, a SOAP fault, a WSDL that will not load — writes the status it managed to obtain and moves on to the next step. Only two things end the flow here: a host key that cannot be resolved, and a service whose method name is empty.
+
+So the status is the whole signal, and reading it is the caller's job:
+
+- `responseStatus` is a **number**, not a string: `200` when the call returned a body, `404` when it returned nothing, `500` when the call failed without a status of its own, and otherwise whatever status the failure carried.
+- The response members are written from the response body, so on a failed call they are set to `undefined` rather than left at their previous value.
+
+A flow that must not continue on a failed call checks `responseStatus` in the `code` step that follows and raises its own error — `flow.createError` with `type: "technical"` is the usual choice, since the machinery failed rather than a business rule. Branching on the status with a [switch](switch.md) is the alternative when the failure has a real alternate path.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/start.md

@@ -0,0 +1,18 @@
+# start
+
+Entry point of the flow. Exactly **one** per flow; execution begins here.
+
+Ports: no inputs, one output port `"_"`.
+
+## Props
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"Start"`. |
+
+```json
+{ "ID": "0", "sp": { "x": 233, "y": 271 }, "name": "start", "version": "0.8",
+  "props": { "label": "Start" } }
+```
+
+Some pulled files also carry a leftover `"description"` prop from older templates — harmless, don't add it to new flows.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/subFlow.md

@@ -0,0 +1,32 @@
+# subFlow (Function)
+
+Calls another `.flow` model. Panel label **Function**. Chain sub-flows for shared conversions (date formatting, object shaping) instead of duplicating script.
+
+Ports: `"_"` in, `"_"` out.
+
+## Props
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"Function"`. |
+| `type` | yes | Always `"referenced"`. |
+| `id` | yes | The callee: `<<flow:Owner/Path/Name>>`. |
+| `mapping` | yes | Full callee contract — see [flow-syntax.md](../flow-syntax.md#mappings). |
+
+```json
+{ "ID": "convertCreateDate", "sp": { "x": 380, "y": 238 }, "name": "subFlow", "version": "0.8",
+  "props": { "label": "convertCreateDate", "type": "referenced",
+             "id": "<<flow:WorkflowCore/Functions/FromDefaultTimeStampString>>",
+             "mapping": {
+               "inParamMapping":  [ { "variable": { "type": "input",  "value": "timestamp" },
+                                      "mapping":  { "type": "input",  "value": "uploadedFile.created" } } ],
+               "outParamMapping": [ { "variable": { "type": "output", "value": "convertedDate" },
+                                      "mapping":  { "type": "vars",   "value": "createDate" } } ] } } }
+```
+
+Notes:
+
+- Caller-side `mapping` sources may be `input`/`vars`/`output`/`context` references (dotted paths allowed), literals, or constants; output targets are `output`/`vars`/`context`.
+- Enumerate **every** input and output of the callee, in its declared order; discard an output with `{ "type": "output", "value": "" }`.
+- This step exposes a Step ID field in the editor, so descriptive step `ID`s are common here.
+- The callee runs in the same engine pass and shares the caller's execution context.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/switch.md

@@ -0,0 +1,74 @@
+# switch (Decision)
+
+Branches the flow. Panel label **Decision**. One output port per case; the connection leaving each port carries the **case name** in `f_o`.
+
+Ports: `"_"` in; outputs = case names, with **Else** always present and shown last.
+
+## Cases — common rules
+
+`props.cases` is a record keyed `"1"`, `"2"`, `"3"`… where **key `"1"` is always the Else case**. Evaluation walks the cases in key order; the first case whose condition holds wins, otherwise Else. Case names: non-empty, unique within the step, max 20 characters. Nothing restricts the characters, so a name in the app's own language is fine — `f_o` carries the same string and is compared as written. The one place it matters is `decisionTree`, where the editor derives `_name` by camel-casing the name and drops anything outside `A-Z a-z 0-9 _ :` on the way; that derived value is a label, not something the branch is matched by. Every case (including Else) needs exactly one outgoing connection whose `f_o` equals the case name.
+
+Three variants, selected by `switchType`:
+
+## `switchType: "expression"`
+
+Each case's `value` is a boolean TypeScript expression evaluated with `flow` (`input`/`output`/`vars`/`context`) in scope. Else has `value: ""`.
+
+```json
+{ "ID": "4", "sp": { "x": 500, "y": 300 }, "name": "switch", "version": "0.8",
+  "props": { "label": "Level?", "switchType": "expression", "type": "switch", "name": "switch",
+             "cases": { "1": { "name": "Else", "value": "" },
+                        "2": { "name": "High", "value": "flow.vars.level === 'high'" } } } }
+```
+
+`type` and `name` are fixed editor-written strings (`"switch"`) — keep them.
+
+## `switchType: "decisionTree"`
+
+Structured conditions instead of free code. Each non-Else case is an `ISwitchCaseExp` tree; Else is `{ "props": { "name": "Else", "_name": "else" } }`.
+
+```json
+"cases": {
+  "1": { "props": { "name": "Else", "_name": "else" } },
+  "2": { "vType": "case",
+         "v": { "left":  { "vType": "variable", "v": { "type": "vars", "value": "level" } },
+                "operator": "eq",
+                "right": { "vType": "variable", "v": { "type": "string", "value": "high" } } },
+         "props": { "name": "High", "_name": "high" } } }
+```
+
+- A node is `{ "vType": "variable", "v": <expression> }` (leaf) or `{ "vType": "case", "v": { left, operator, right }, "props": { name, _name } }` (composite — nest `case` nodes under `left`/`right` to combine with `and`/`or`).
+- `negation: true` on a node inverts it.
+- `props.name` is the case name; `_name` is its camelCase form.
+
+Operators: `and`, `or`, `eq` (strict `===`), `ne` (loose `!=`), `gt`, `gte`, `lt`, `lte` (numbers only — non-numeric operands make the case false), `ns` (left is not set; no `right` needed), `in` (**left is an array** that contains right), `nin` (**right is an array** that does not contain left — note the operand swap vs `in`).
+
+## `switchType: "decisionTable"`
+
+Routes on a decision table model's outputs. Adds two props:
+
+```json
+"props": { "label": "Route", "switchType": "decisionTable", "type": "switch", "name": "switch",
+           "decisionTableId": "<<decisionTable:Owner/Tables/Routing>>",
+           "mapping": { "inParamMapping":  [ { "variable": { "type": "input",  "value": "amount" },
+                                               "mapping":  { "type": "vars",   "value": "amount" } } ],
+                        "outParamMapping": [ { "variable": { "type": "output", "value": "decision" },
+                                               "mapping":  { "type": "output", "value": "decision" } } ] },
+           "cases": { "1": { "name": "Else", "value": "" },
+                      "2": { "name": "Approve", "value": "dt.output.decision === 'approve'" } } }
+```
+
+`inParamMapping` feeds the table, one row per table input. Case `value` expressions then get an extra `dt` object in scope — but the two halves of it do not work the same way, and this is the thing to get right:
+
+- `dt.input.<name>` is keyed by the **table's** input names and is filled straight from `inParamMapping`. It always works.
+- `dt.output` is **the flow's own output bucket**, not the table's result. What lands in it is whatever `outParamMapping` copied there, under the **caller-side** member name.
+
+So a case that branches on a table result needs that result mapped out first: one `outParamMapping` row per output you branch on, with `variable` naming the table's output and `mapping` naming an `output` member of the flow — and the case then reads that member's name. An empty `outParamMapping` leaves `dt.output` without the table's values, every case evaluates false, and the switch silently takes Else on every run. Mapping into `vars` instead of `output` fails the same way, since `dt.output` only ever shows the output bucket.
+
+Declaring those members is no loss: the branch result is usually something the flow wants to return anyway. For plain table evaluation without branching, use the [decisionTable](decisionTable.md) step instead.
+
+## Easy to get wrong
+
+- Renaming a case without updating the matching connection's `f_o` silently orphans the branch.
+- A case with no outgoing connection dead-ends the flow at runtime.
+- Case order in the record is evaluation order — put the most specific case first.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/flow/steps/wait.md

@@ -0,0 +1,25 @@
+# wait
+
+**A join, not a timer.** `wait` synchronizes parallel branches: it remembers which of its incoming connections have fired and continues (once) only after **all** of them have arrived. It does not pause for a duration or condition.
+
+Use it when a step fans out into parallel paths and a later step needs every path finished:
+
+```
+start ─→ A ─→─┐
+      └→ B ─→─┤→ wait ─→ end
+```
+
+Ports: `"_"` in (accepts any number of incoming connections), `"_"` out.
+
+## Props
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"Wait"`. |
+
+```json
+{ "ID": "5", "sp": { "x": 600, "y": 200 }, "name": "wait", "version": "0.8",
+  "props": { "label": "Wait" } }
+```
+
+A `wait` with a single incoming connection is a no-op; with an incoming branch that can never fire (e.g. an unreachable switch case) the flow hangs there.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/sla-syntax.md

@@ -0,0 +1,149 @@
+# sla — syntax
+
+Syntax rules for a `.sla` model: the time milestones of a process or a user task — how long the work may take, how its priority rises as time passes, and which flow runs when a milestone is reached.
+
+## File layout
+
+```
+---studio-metadata DO NOT EDIT---
+id: <model id>
+ownerName: <owner>
+---studio-metadata DO NOT EDIT---
+{ "id": "…", "name": "OriginatorSLA", "description": "", "slaInfo": [ … ], … }
+```
+
+The metadata header is identity — never edit or strip it. A file you create from scratch has no header; write the JSON body alone and Studio adds the header once the model reaches it. The model body is **JSON**.
+
+The file's name is the model's name, and its folder is what other models reference it by.
+
+## Model body
+
+```json
+{ "id": "<as pulled>",
+  "name": "OriginatorSLA",
+  "description": "",
+  "slaInfo": [ { …GOAL… }, { …DEADLINE… }, { …CRITICAL… } ],
+  "initialPriority": { "type": "number", "value": "10" },
+  "store": { "context": {}, "input": {}, "output": {} },
+  "userId": { "type": "constant", "value": "<<constant:common/SlaSystemUser>>" } }
+```
+
+| Field | Required | Rule |
+|-------|----------|------|
+| `id` | yes | Model id — keep the pulled value; `""` in a file that has never reached Studio, which fills it. |
+| `name` | yes | Identical to the filename without the extension. Studio overwrites it with the model's name on every open. |
+| `description` | yes | May be `""`, but the key is present. Note the spelling: `description`, not `desc`. |
+| `slaInfo` | yes | The three milestone levels — see below. |
+| `initialPriority` | no | Expression object: the priority the work starts with, before any milestone fires. |
+| `store` | yes | `{ context, input, output }` — the model's own variables. |
+| `userId` | no | Expression object naming the identity escalation flows run as. Omitted entirely for the default identity — see below. |
+
+This model type has **no `type` field and no `_name`** — the file extension carries the type. Nothing else belongs at the root.
+
+## slaInfo — the three levels
+
+`slaInfo` always holds exactly three entries, one per level, in the order `GOAL`, `DEADLINE`, `CRITICAL`. Levels are never added, removed or renamed: a level that does not apply stays in the array with empty values.
+
+The three are escalating stages of the same piece of work, not three independent timers:
+
+| Level | Meaning |
+|-------|---------|
+| `GOAL` | The target — the time the work is expected to be finished in. Reaching it is a warning, not a failure. |
+| `DEADLINE` | The commitment — the point after which the work counts as late. |
+| `CRITICAL` | The last stage — the work is badly overdue and needs whatever the escalation does about it. |
+
+**Each interval is counted from the previous level's due date**, and only the first one that has an interval starts from the moment the process or task begins. So the values are per-stage durations, not totals: `GOAL 2 days` + `DEADLINE 3 days` puts the deadline five days out, not three.
+
+A limit measured from the start of the work is therefore a **total**, and it is not what the file holds. Writing one means subtracting the stages before it: a total of 1 day behind a 4-hour goal is a deadline stage of 20 hours, not 1 day.
+
+That subtraction is only possible while every earlier stage is a fixed number. An interval is a single value — one literal, one input or one constant — and levels cannot be combined arithmetically, so as soon as an earlier stage is bound to an `input` or a `constant` its length is unknown at authoring time and no total can be expressed after it. From that point on, each level can only be stated as a duration running from the previous milestone.
+
+The two readings produce different dates and the gap widens at every level, so which one a given number is has to be settled before it is written, not assumed.
+
+When a level is reached, three things happen: its `priority` is added to the current priority, its `escalationFunctionId` flow runs if it names one, and the remaining levels are recalculated from that moment. A level whose interval is empty is skipped — it never fires and never delays the ones after it, which is how a two-stage SLA is written.
+
+```json
+{ "type": "GOAL", "name": "GOAL", "description": "",
+  "interval": { "days":    { "type": "number", "value": "2" },
+                "hours":   { "type": "number", "value": "" },
+                "minutes": { "type": "number", "value": "" } },
+  "useBusinessDays": true,
+  "priority": { "type": "number", "value": "50" },
+  "escalationFunctionId": "" }
+```
+
+| Field | Rule |
+|-------|------|
+| `type` | `"GOAL"`, `"DEADLINE"` or `"CRITICAL"` — the key the level is found by. |
+| `name` | Repeats `type`. |
+| `description` | Free text, usually `""`. |
+| `interval` | `{ days, hours, minutes }`, each an expression object. All three keys are always present; an unused unit carries an empty `value`, not a missing key. Units add up, and an interval with all three empty disables the level. |
+| `useBusinessDays` | Boolean, always written. `true` counts the interval against the working calendar: days skip weekends and holidays, and hours and minutes are consumed only inside working hours. |
+| `priority` | Expression object — the priority increase applied when this level is reached. |
+| `escalationFunctionId` | The flow run at this level, as a `<<flow:…>>` reference. `""` means the level fires without running anything. |
+
+`useBusinessDays` is decided per level, so a GOAL counted in business days and a CRITICAL counted in calendar time are a legal combination.
+
+## Expression objects
+
+`initialPriority`, `priority`, each `interval` unit, and `userId` are objects `{ "type": …, "value": … }`. `value` is always a string, even for numbers.
+
+| Position | Allowed `type` |
+|----------|----------------|
+| `initialPriority`, `priority`, `interval.days` / `.hours` / `.minutes` | `number \| input \| constant` |
+| `userId` | `string \| constant` |
+
+- With `number` the `value` is the digits as text (`"2"`), and `""` means unset.
+- With `input` the `value` is the name of a member of `store.input`, so the attaching workflow decides the duration at runtime.
+- With `constant` the `value` is a `<<constant:…>>` reference.
+
+A reference is `<<type:target>>`, where `target` is the referenced model's path in the workspace without the file extension — a constant at `common/SlaSystemUser.constant` is written `<<constant:common/SlaSystemUser>>`, and a flow at `functions/fn_NotifyLate.flow` is written `<<flow:functions/fn_NotifyLate>>`.
+
+Every reference you write uses the path form and names a file that is actually in the workspace — locate that file first. Some older files carry a raw model id in that position instead: leave such a reference untouched where you find it, but never write a new one, and never copy a reference out of another model — ids belong to the app they came from and resolve to nothing here. If the model you need does not exist, it has to be created or picked first; a reference that resolves to nothing is not a placeholder.
+
+Older files may carry bare numbers (`"days": 2`, `"priority": 30`) instead of expression objects. Studio converts them on open, but write the object form.
+
+## escalationFunctionId
+
+A reference to the flow that runs when the level is reached, or `""` for none. It is written as `<<flow:<path of the flow file without its extension>>>` — a flow at `functions/fn_NotifyLate.flow` becomes `<<flow:functions/fn_NotifyLate>>`.
+
+The flow must take **no inputs**. This reference stands alone — there is no mapping beside it — so nothing can ever fill a flow's input variables from here, and a flow that declares any is not selectable as an escalation function. Whatever the escalation needs it must obtain itself or receive from the engine.
+
+That makes the flow's own declaration part of this field's validity, so it is checked before the reference is written: open the candidate flow file and confirm its store declares no inputs. A name that sounds right is not evidence — notification flows in particular tend to declare what they notify about. When no input-free flow fits the level, the field stays `""`; a reference to a flow with inputs is worse than no reference, because it looks wired and never runs.
+
+## store
+
+Three sections — `context`, `input`, `output`. There is no `vars` section, and `context` stays `{}` on this model type.
+
+```json
+{ "context": {},
+  "input": { "urgency": { "name": "urgency", "desc": "", "type": "number",
+                          "list": false, "required": false,
+                          "default": { "type": "number", "value": "0" } } },
+  "output": {} }
+```
+
+| Field | Rule |
+|-------|------|
+| `name` | Repeats the map key. |
+| `desc` | Free text, may be `""`. |
+| `type` | `string \| number \| datetime \| boolean \| dataType \| dataSet \| constant \| any`. |
+| `objectID` | Required with `dataType` and `dataSet`, and only there — a `<<dataType:…>>` / `<<dataSet:…>>` reference. |
+| `list` | `true` = array of that type. |
+| `required` | Enforced on the attaching model's mapping. |
+| `default` | Optional initial value, an expression object such as `{ "type": "number", "value": "0" }`. |
+
+Members are added to `input` and `output` only. An `input` member exists to be referenced by an `input`-typed expression above: declare the member, then point the interval or priority at it by name. A model whose milestones are all fixed numbers needs no store members at all — `{ "context": {}, "input": {}, "output": {} }` is the normal shape.
+
+Some files carry a `props` key inside `store`. Leave it exactly as found; never add one.
+
+## Easy to get wrong
+
+- The field is `description`, not `desc`, and there is no `type` field at the root.
+- `slaInfo` always has all three levels; an unused level is emptied, never deleted.
+- Interval units are expression objects with string values — `"2"`, not `2`, and `""` for unused units.
+- `priority` is the increase added when that level is reached, while `initialPriority` is the value the work starts at.
+- Interval values are per-stage durations measured from the previous level, not totals measured from the start. A total can only be written as a stage duration when every earlier stage is a fixed number.
+- `escalationFunctionId` holds a flow reference directly, with no mapping object around it, and the flow it names must declare no inputs — open that flow and check its store before writing the reference.
+- Omitting `userId` is how the default identity is chosen; an empty-valued object is not the same thing.
+- Every `input`-typed expression must name a member that exists in `store.input`.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/workflow/steps/end.md

@@ -0,0 +1,24 @@
+# end (End)
+
+Finishes the process. A workflow needs at least one, and several are normal — one per way the process can conclude. The shared shape — `ID`, `sp`, `version`, `label`, the single `"_"` input and no output — is in [the flow step's file](../../flow/steps/end.md).
+
+Unlike the flow version, this one decides what the finished process is called.
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"End"`. |
+| `procesStatus` | yes | The status written on the process instance as it finishes. Default `"Resolved-Completed"`. The panel lists the entries of the app's **ProcessStatus** dataSet plus `"Others"`; pick one of those values, or `"Others"` to compose the status yourself. Note the single `s` in the name. |
+| `procesStatusLiteral` | yes | `""` unless `procesStatus` is `"Others"`, in which case this carries the status text. It is evaluated as a template at runtime, so it may embed process data — `"Reddedildi-${flow.input.redSebebi}"`. |
+
+```json
+{ "ID": "end_mssmi335p7uOwIas", "sp": { "x": 1160, "y": 200 }, "name": "end", "version": "0.8",
+  "props": { "label": "End", "procesStatus": "Resolved-Completed", "procesStatusLiteral": "" } }
+```
+
+The panel exposes a **Step ID** field here too, so end steps commonly carry descriptive or generated ids.
+
+Notes:
+
+- Reaching an `end` is the process saying it concluded, whichever status it writes — a rejection and an approval are both ordinary endings, distinguished by the status, not by whether the step is reached.
+- One case overrides the step: a process ended by a terminate action keeps the status it already had, and what this step declares is ignored.
+- The status is a code. What a screen shows is the app's localization of it, falling back to the raw code when there is no entry for it, so a status invented here without a matching entry surfaces to users exactly as written.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/workflow/steps/start.md

@@ -0,0 +1,17 @@
+# start (Start)
+
+Where the process begins. One per workflow, no input port, a single `"_"` output. The shared shape — `ID`, `sp`, `version`, `label` — is in [the flow step's file](../../flow/steps/start.md).
+
+| Prop | Required | Rule |
+|------|----------|------|
+| `label` | yes | Box caption, default `"Start"`. |
+| `procesStatus` | yes | Editor-written, `""`. The panel offers no field for it, so leave the empty string as generated. Note the single `s` in the name. |
+
+```json
+{ "ID": "start_mssmi2ehweamQ7uVk", "sp": { "x": 200, "y": 200 }, "name": "start", "version": "0.8",
+  "props": { "label": "Start", "procesStatus": "" } }
+```
+
+The panel does expose a **Step ID** field, so a workflow's start step usually carries a descriptive or generated id rather than a plain number — `"start_mssmi2ehweamQ7uVk"` above is what Studio writes for a new one. Whatever the id is, every connection that names it has to agree with it.
+
+The empty `procesStatus` is what a freshly started process instance carries until a step gives it one; the statuses users see come from the human tasks the process reaches and from the `end` step it finishes at.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/workflow-kit/models/workflow/steps/subFlow.md

@@ -0,0 +1,10 @@
+# subFlow (Function)
+
+Runs a workflow function as a step of the process. The component is the same one the flow editor offers and the authored shape is identical — `type`, the `<<flow:…>>` reference in `id`, and the `mapping` that enumerates the callee's whole contract are described in [the flow step's file](../../flow/steps/subFlow.md).
+
+Two things are specific to running it here:
+
+- **The caller side is the workflow's store.** Mapping sources are the process's `input`, `output` and `context` members — there is no `vars` bucket in a workflow — and output targets are `output` and `context`. A function that has to see the business data is handed `context.dataInstance`, or the individual members it needs.
+- **The process is written to storage when the function returns.** Whatever the function changed in the process instance and its tasks is persisted at that point, so a function that alters the process takes effect as soon as the step completes rather than at the end of the run.
+
+The step needs the process engine; the same component in a plain function is the flow-side one, called from another function.