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

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/platform/models/soap-service-syntax.md

@@ -0,0 +1,186 @@
+# soapService — syntax
+
+Syntax rules for a `.soapService` model: one external SOAP operation — the WSDL address, the operation name, the SOAP headers and body it sends, and the extraction of the response into store variables.
+
+**This model type is legacy — do not create new `.soapService` files.** A new SOAP integration is built with the newer, WSDL-driven SOAP service type instead. Existing `.soapService` models still run, and these rules are for reading and updating them.
+
+## File layout
+
+```
+---studio-metadata DO NOT EDIT---
+id: <model id>
+ownerName: <owner>
+---studio-metadata DO NOT EDIT---
+{ "id": "…", "type": "soapService", "name": "CustomerQuery", … }
+```
+
+The metadata header is identity — never edit or strip it. The model body is **JSON**.
+
+## Model body
+
+Written in the order pulled files use:
+
+```json
+{ "id": "<as pulled>", "type": "soapService",
+  "name": "CustomerQuery", "_name": "customerquery", "desc": "Find customer",
+  "hostKey": { "type": "constant", "value": "<<constant:services/CrmSoapConfig>>" },
+  "hostKeyExtension": [ { "value": { "type": "string", "value": "CustMgmt/CustomerQueryV6?wsdl" } } ],
+  "methodName": { "type": "string", "value": "retrieveCustomerByCustomerNumber" },
+  "wsdlOptions": [ { "bodyKey": "", "value": { "type": "input", "value": "WSDLOptions" } } ],
+  "requestBody": [ { "bodyKey": "tns:customerNumber", "value": { "type": "input", "value": "customerNumber" } } ],
+  "requestHeader": { "p:consumerContext": { "type": "input", "value": "consumerContext" },
+                     "wsse:Security":     { "type": "input", "value": "securityHeader" } },
+  "responseHeader": {},
+  "responseBody": [ { "bodyKey": "RetrieveCustomerResponseDTO",
+                      "value": { "type": "output", "value": "retrieveCustomerResponse" } } ],
+  "mock": [],
+  "store": { "context": { … }, "input": { … }, "output": { … } } }
+```
+
+| Field | Required | Rule |
+|-------|----------|------|
+| `id` | yes | Model id — as pulled. |
+| `type` | yes | The literal `"soapService"`. |
+| `name` | yes | Identical to the filename without the extension. Studio overwrites it with the model's name every time the editor opens the file. |
+| `_name` | yes | Derived from `name`: lowercased, with separator runs collapsed and the following letter capitalized. Studio recomputes it on every open. |
+| `desc` | yes | May be `""`, but the key is present. |
+| `hostKey` | yes | Base address, as an expression object. Usually a constant reference. |
+| `hostKeyExtension` | no | Array of `{ "value": <expression> }`, appended to the base address — see URL assembly below. |
+| `methodName` | yes | The SOAP operation to invoke, as an expression object. Resolving to an empty value fails the call at runtime. |
+| `requestHeader` | no | Object keyed by SOAP header name; `{}` or absent when none. |
+| `requestBody` | yes | Array of `{ bodyKey, value }` entries that build the call arguments. |
+| `responseHeader` | no | Object keyed by response header name, each value a write target. |
+| `responseBody` | no | Array of `{ bodyKey, value }` entries that extract from the response. |
+| `wsdlOptions` | no | Array of `{ bodyKey, value }` entries, assembled exactly like `requestBody` into the options object used when the WSDL client is created. The usual form is a single `bodyKey: ""` entry pointing at an input that carries the whole options object. `[]` when none. |
+| `security` | no | `{ "username": <expression>, "password": <expression> }` — plain WS-Security user/password. Applied only when both resolve to non-empty values. Most services omit this key entirely and pass credentials as a `wsse:Security` request header instead. |
+| `mock` | no | Array of canned responses — see below. |
+| `store` | yes | `{ context, input, output }` — the service's own variables. |
+
+There is no `contentType`, no `httpMethod`, no `requestUrl`, no `timeout` and no cache field in this model type, and no `responseStatus` field either — the status is written to the store, see below.
+
+## Expression objects
+
+Every dynamic value is an object `{ "type": …, "value": … }`:
+
+- `string` / `literal` — `value` is the literal text.
+- `input`, `output`, `context` — `value` is the name of a member of that store section. A dot path may reach into a member's nested fields (`customer.basicInfo.fullName`).
+- `constant` — `value` is a `<<constant:…>>` reference, resolved per environment at runtime.
+
+Reference bodies (`<<constant:…>>`, `<<dataType:…>>`) are the target model's path in a pulled workspace without the file extension, but files of this generation often carry a raw model id there instead. Leave an existing reference in whichever form you find it — never convert one into the other by hand. Any reference you add is written in the path form and must name a file that is really in the workspace; never copy one out of another model, because a raw id belongs to the app it came from and resolves to nothing here.
+
+Request-side positions (`hostKey`, `hostKeyExtension`, `methodName`, `requestHeader`, `requestBody`, `wsdlOptions`, `security`) are read; response-side positions (`responseHeader`, `responseBody`) are written, so they must name `output` or `context` members — a read-only type there never lands anywhere. Every `input`/`output`/`context` name used anywhere in the model must exist in `store`.
+
+## URL assembly
+
+The resolved `hostKey` loses a single trailing `/`, then every `hostKeyExtension` entry is appended in array order, each joined with `/`. The result is the WSDL address the client is created from, so the extension list normally ends with the `…?wsdl` segment.
+
+```json
+"hostKey": { "type": "constant", "value": "<<constant:services/CrmSoapConfig>>" },
+"hostKeyExtension": [ { "value": { "type": "string", "value": "CustMgmt/CustomerQuery?wsdl" } } ]
+```
+
+Each entry is an object with a single `value` key — there is no `bodyKey` and no `required` here.
+
+## requestHeader / responseHeader
+
+Objects keyed by the header name, which on this model type is the SOAP header element name and may carry a namespace prefix (`wsse:Security`, `p:consumerContext`).
+
+Request headers are resolved and sent as SOAP headers; a header whose expression resolves to nothing is dropped from the request rather than sent empty. Response headers write the incoming header of the same name into their target.
+
+A header value is normally a whole structured input — one store member typed with the dataType that models that header element (a consumer-context object, a WS-Security header object), not a scalar. Model the header as a dataType and bind the input, rather than assembling it from several entries.
+
+## requestBody
+
+An array of `{ bodyKey, value }` entries assembled into the operation's argument object:
+
+```json
+[ { "bodyKey": "customerNumber",     "value": { "type": "input", "value": "customerNumber" } },
+  { "bodyKey": "tns:retrieveOptions", "value": { "type": "input", "value": "retrieveOptions" } } ]
+```
+
+- `bodyKey` is the element name and may carry a namespace prefix. It is the argument key verbatim — no dot paths.
+- `bodyKey: ""` is special: the resolved value must be an object, and its properties are merged into the body root.
+- A named entry is skipped entirely when its value resolves to empty — only `false` and `0` survive as falsy values. Sending an explicit empty string is not possible this way.
+
+## responseBody
+
+The mirror image: `bodyKey` is a path **into the response**, and `value` is where the extracted piece is written.
+
+```json
+[ { "bodyKey": "RetrieveCustomerResponseDTO",     "value": { "type": "output", "value": "retrieveCustomerResponse" } },
+  { "bodyKey": "customer[0].basicInfo.fullName",  "value": { "type": "output", "value": "customer.basicInfo.fullName" } },
+  { "bodyKey": "BusinessFault",                   "value": { "type": "output", "value": "businessFault" } } ]
+```
+
+- The common form is one entry per top-level response element, written as a plain element name and landing in an output typed with that element's dataType.
+- A deeper `bodyKey` is dot-separated and supports array indexing with `[n]` (`customer[0].fullName`); use it only when a nested piece is needed on its own. A path that does not exist yields nothing rather than an error.
+- `bodyKey: ""` writes the whole response body.
+- Entries are applied in array order.
+
+## store
+
+Three sections — `context`, `input`, `output`. There is no `vars` section. Each member is keyed by its own name:
+
+```json
+{ "context": { "currentUser": { "name": "user", "desc": "user", "type": "dataType",
+                                "objectID": "<<dataType:DataTypes/User>>", "list": false, "required": true } },
+  "input":   { "customerNumber": { "name": "customerNumber", "desc": "", "type": "string",
+                                   "list": false, "required": true,
+                                   "default": { "type": "string", "value": "" } },
+               "securityHeader":  { "name": "securityHeader", "desc": "", "type": "dataType",
+                                    "objectID": "<<dataType:DataTypes/SecurityHeader>>",
+                                    "list": false, "required": false,
+                                    "default": { "type": "string", "value": "" } } },
+  "output":  { "retrieveCustomerResponse": { "name": "retrieveCustomerResponse", "desc": "", "type": "dataType",
+                                             "objectID": "<<dataType:DataTypes/CustomerResponse>>",
+                                             "list": false, "required": false,
+                                             "default": { "type": "string", "value": "" } },
+               "businessFault": { "name": "businessFault", "desc": "", "type": "dataType",
+                                  "objectID": "<<dataType:DataTypes/Fault>>", "list": false, "required": false,
+                                  "default": { "type": "string", "value": "" } } } }
+```
+
+| 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. |
+| `list` | `true` = array of that type. |
+| `required` | Enforced on the caller's mapping. |
+| `default` | Optional initial value, an expression object. |
+
+- `input` holds one member per dynamic header, body or WSDL-options value; `output` holds the extraction targets. Structured request pieces (header objects, option objects, element payloads) are inputs typed with their own dataType, and `list: true` when the element repeats.
+- Fault payloads are ordinary outputs — a SOAP fault is extracted through `responseBody` like any other element, and the business/system fault pair commonly shares one fault dataType.
+- `responseStatus` is not a field of this model: the runtime always writes the call's status into a store output **named** `responseStatus` — `200` on a non-null response, `404` when the response body is null, and the transport's status or `500` on error. Declare that output if the caller needs the status.
+- `context.currentUser` is engine-backed — leave it as pulled.
+- Older bodies carry a `_name` alongside `name` on store members, with the display label in `name` and the identifier in `_name`. On load `_name` wins and is dropped, so the surviving identifier is the `_name` value. Don't add `_name` to members you write.
+- Some files carry a `props` key inside `store`. Leave it exactly as found; never add one.
+
+## mock
+
+Canned responses used only in live preview and local runs; in every real environment the block is inert.
+
+```json
+[ { "reqExp": "",
+    "requestHeader": { "p:consumerContext": { "attributes": { "xsi:type": "p:BranchContextType" } } },
+    "requestBody":   { "customerNumber": "12345" },
+    "responseBody":  { "customer": [ { "customerNumber": 12345 } ] },
+    "responseHeaders": {},
+    "responseStatus": 200 } ]
+```
+
+- Matching is by **partial equality** of `requestHeader` and `requestBody` against the outgoing call: every key present in the mock must match, keys absent from the mock are ignored.
+- An entry with neither `requestHeader` nor `requestBody` (or with both empty) is the fallback, used when nothing else matches. Only the first such entry counts.
+- `reqExp` is carried in the file but plays no part in matching on this model type; `""` is normal.
+- `responseHeaders` is plural here, unlike the singular `responseHeader` of the model root. `responseBody` may be an object or a JSON string. `responseStatus` may be omitted, in which case the call reports no status.
+
+## Easy to get wrong
+
+- The options field is `wsdlOptions`. Older files contain a misspelled `wdslOptions`, which is simply never read — the client is then created with no options at all.
+- `requestHeader` (root, singular) versus `responseHeaders` (inside a mock, plural) — the two spellings are not interchangeable.
+- `hostKeyExtension` entries hold only `value`; they are not body entries and take no `bodyKey`.
+- In `requestBody`, `bodyKey` is a flat element name; in `responseBody` it is a dot/index path. The same field name means different things on the two sides.
+- An empty-resolving request entry disappears from the call instead of being sent as empty.
+- `security` must carry both `username` and `password` to take effect; half of it is the same as none.
+- The status is a store output named `responseStatus`, not a field of the model.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/platform/models/soap-service-v2-syntax.md

@@ -0,0 +1,204 @@
+# soapServiceV2 — syntax
+
+Syntax rules for a `.soapServiceV2` model: one external SOAP operation, driven by a WSDL that lives in the workspace as its own content model.
+
+**The WSDL import is a user action in Studio.** Importing a WSDL creates the `.wsdl` content model, the `.soapServiceV2` model that points at it, and the dataTypes describing the request and response elements. None of that is produced locally — this doc covers the resulting file: what its fields mean, and what may be changed in it afterwards.
+
+## File layout
+
+```
+---studio-metadata DO NOT EDIT---
+id: <model id>
+ownerName: <owner>
+---studio-metadata DO NOT EDIT---
+{ "id": "…", "type": "soapServiceV2", "name": "sampleWS", … }
+```
+
+The metadata header is identity — never edit or strip it. The model body is **JSON**.
+
+## Model body
+
+Written in the order generated files use:
+
+```json
+{ "id": "", "type": "soapServiceV2",
+  "name": "sampleWS", "desc": "sampleWS",
+  "hostKey": { "type": "constant", "value": "<<constant:sample/sampleEndpoint>>" },
+  "methodName": { "type": "string", "value": "sampleWS" },
+  "contentType": "application/xml",
+  "store": { "context": { … }, "input": { … }, "output": { … }, "props": { "insert": ["input", "output"] } },
+  "requestHttpHeaders": {},
+  "requestHeaders": {},
+  "responseHeaders": { "responseStatus": { "type": "output", "value": "responseStatus",
+                                           "description": "Http Response Status Code" } },
+  "requestBody":  [ { "bodyKey": "", "value": { "type": "input",  "value": "sampleRequest" } } ],
+  "responseBody": [ { "bodyKey": "", "value": { "type": "output", "value": "sampleResponse" } } ],
+  "soapAction": "http://example.com/sample/sampleOperation",
+  "timeout": { "type": "string", "value": "5000" },
+  "wsdlContentModelId": "<<wsdl:sample/sampleContent>>" }
+```
+
+| Field | Required | Rule |
+|-------|----------|------|
+| `id` | yes | Model id. Generated files often carry `""` here — Studio fills it from the header on open. Keep whatever is there; never invent one. |
+| `type` | yes | The literal `"soapServiceV2"`. |
+| `name` | yes | Identical to the filename without the extension. Studio overwrites it with the model's name on every open. |
+| `desc` | yes | May be `""`, but the key is present. |
+| `hostKey` | yes | The endpoint address, as an expression object of type `string \| literal \| input \| constant`. This overrides the address the WSDL declares, so it is what points the call at an environment — a constant reference is the usual form. |
+| `methodName` | yes | The WSDL operation to invoke, as an expression object of the same four types. Must match an operation the WSDL defines; resolving to empty fails the call. |
+| `contentType` | no | Only `"application/xml"`. |
+| `store` | yes | `{ context, input, output, props }` — the service's own variables. |
+| `requestHttpHeaders` | no | Object keyed by header name, for HTTP-level headers. Stored but not sent by the current runtime — SOAP headers belong in `requestHeaders`. |
+| `requestHeaders` | no | Object keyed by SOAP header element name; these are the headers actually sent. |
+| `responseHeaders` | no | Object keyed by response header name, each value a write target. |
+| `requestBody` | yes | Array of `{ bodyKey, value }` entries that build the call arguments. |
+| `responseBody` | yes | Array of `{ bodyKey, value }` entries that extract from the response. |
+| `soapAction` | yes | Plain string — the SOAPAction of the operation, taken from the WSDL. Not an expression object. It belongs to the same operation as `methodName`, so the two only ever change together. |
+| `timeout` | yes | Expression object of type `string \| literal \| input \| constant`, resolving to milliseconds (`{ "type": "string", "value": "5000" }`). |
+| `wsdlContentModelId` | yes | `<<wsdl:…>>` reference to the WSDL content model in the workspace. The client is built from that model's content, not fetched from the host. Never point it elsewhere by hand. |
+| `mock` | no | Array of canned responses — see below. Absent when the service has none. |
+
+There is no `_name` on this model type, and no `hostKeyExtension`, no `wsdlOptions` field and no `security` block — the last two have store-based equivalents described below.
+
+## Reading the WSDL
+
+`wsdlContentModelId` is not just provenance: the WSDL sits in the workspace as an ordinary file, at the reference's path with a `.wsdl` extension (`<<wsdl:sample/sampleContent>>` → `sample/sampleContent.wsdl`). Every reference in this model works that way — the body is the target's workspace path without the extension, and it must name a file that is really there; never copy a reference out of another model, because a raw model id belongs to the app it came from and resolves to nothing here. It carries the same metadata header as any model, with raw XML as its body. Open it before changing anything in this model — it is the only place that says what the service actually accepts.
+
+| Model field | Where it comes from in the WSDL |
+|-------------|--------------------------------|
+| `methodName` | An `operation` name under `portType` / `binding`. Only those names are callable. |
+| `soapAction` | The `soapAction` attribute of that operation's `soap:operation`. |
+| `requestBody` binding | The element of the operation's input message — its structure is what the request dataType mirrors. |
+| `responseBody` binding | The element of the operation's output message, mirrored by the response dataType. |
+| Nested dataTypes | Named `complexType` definitions in the schema section (each one became its own dataType). |
+| Namespace prefixes in header and body keys | The prefix declarations at the top of the definitions element. |
+| `hostKey` | Overrides the `soap:address location` of the service port — the WSDL's own address is the fallback the model replaces. |
+
+So a field name, a nesting level or an operation can be checked against the WSDL instead of guessed. Anything the WSDL does not define cannot be bound, however the store is written.
+
+## Expression objects
+
+Every dynamic value is an object `{ "type": …, "value": … }`, and header entries may also carry a `description` string. The allowed `type` differs by position:
+
+| Position | Allowed `type` |
+|----------|----------------|
+| `hostKey`, `methodName`, `timeout` | `string \| literal \| input \| constant` |
+| `requestHttpHeaders`, `requestHeaders`, `requestBody` values | `input \| context` |
+| `responseHeaders`, `responseBody` values | `output \| context` |
+
+Request bindings read from the store and response bindings write to it, so a request entry never carries a literal on this model type — put fixed values in the store member's `default`, or in a constant reached through `hostKey`-style fields. Every `input`/`output`/`context` name used anywhere must exist in `store`.
+
+## requestBody
+
+An array of `{ bodyKey, value }` entries assembled into the operation's argument object:
+
+```json
+[ { "bodyKey": "", "value": { "type": "input", "value": "sampleRequest" } } ]
+```
+
+- The generated form is a single entry with `bodyKey: ""` bound to one input typed with the request dataType: the resolved object's properties become the call arguments as a whole.
+- A named `bodyKey` sets that single argument instead. It is the argument key verbatim — no dot paths.
+- A named entry is skipped entirely when its value resolves to empty; only `false` and `0` survive as falsy values.
+
+## responseBody
+
+The mirror image: `bodyKey` is a path **into the response**, `value` is where the extracted piece is written.
+
+```json
+[ { "bodyKey": "", "value": { "type": "output", "value": "sampleResponse" } } ]
+```
+
+- `bodyKey: ""` writes the whole response body — the generated form, landing in one output typed with the response dataType.
+- A deeper `bodyKey` is dot-separated and supports array indexing with `[n]` (`customer[0].fullName`); a path that matches nothing yields nothing rather than an error.
+- Entries are applied in array order.
+
+## Headers
+
+Objects keyed by the header name, which for `requestHeaders` is the SOAP header element name and may carry a namespace prefix:
+
+```json
+"requestHeaders":  { "wsse:Security": { "type": "input", "value": "securityHeader" } },
+"responseHeaders": { "responseStatus": { "type": "output", "value": "responseStatus",
+                                         "description": "Http Response Status Code" } }
+```
+
+- A request header value is normally a whole structured input — one store member typed with the dataType that models that header element — not a scalar. A header whose expression resolves to nothing is dropped rather than sent empty.
+- `description` is optional free text carried alongside `type`/`value`.
+- These are objects: never write two entries with the same header name, or an entry with an empty name.
+- WS-Security has no dedicated field on this model type; it travels as a `wsse:Security` request header bound to a security-header dataType.
+
+## store
+
+Sections are `context`, `input`, `output` and `props`. There is no `vars` section.
+
+```json
+{ "context": { "currentUser": { "name": "user", "desc": "user", "type": "dataType",
+                                "objectID": "", "list": false, "required": true } },
+  "input":   { "sampleRequest": { "name": "sampleRequest", "desc": "", "type": "dataType",
+                                  "objectID": "<<dataType:sample/sampleRequest>>",
+                                  "list": false, "required": false,
+                                  "default": { "type": "string", "value": "" } },
+               "wsdlOptions":   { "name": "wsdlOptions", "desc": "", "type": "any",
+                                  "list": false, "required": false } },
+  "output":  { "sampleResponse": { "name": "sampleResponse", "desc": "", "type": "dataType",
+                                   "objectID": "<<dataType:sample/sampleResponse>>",
+                                   "list": false, "required": false,
+                                   "default": { "type": "string", "value": "" } },
+               "responseStatus": { "name": "responseStatus", "desc": "", "type": "string",
+                                   "list": false, "required": false,
+                                   "default": { "type": "string", "value": "" } } },
+  "props": { "insert": ["input", "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 caller's mapping. |
+| `default` | Optional initial value, an expression object such as `{ "type": "string", "value": "" }`. |
+
+Two store members carry meaning beyond being variables:
+
+- **`input.wsdlOptions`** — options passed to the SOAP client when it is built. This model type has no `wsdlOptions` field: before the call, the runtime looks up the store input whose key is exactly `wsdlOptions`, reads the value the calling flow mapped into it, and hands that object to the client. No such input means no options. The name is matched literally, so renaming the member turns it into an ordinary unused variable; delete it instead when the service needs no options.
+- **`output.responseStatus`** — the call status. This model type has no status field either: after the call, the runtime writes the status into the store output whose key is exactly `responseStatus` — `200` on a non-null response, `404` when the response body is null, and the transport's status or `500` on error. The value written is a number, whatever the member's declared `type` says — the generated declaration reads `string` and is left that way. Declare that output when the caller needs the status; the name is matched literally here too.
+
+  The status carries more weight than it looks. A call that fails — unreachable host, timeout, SOAP fault — does not stop the flow that made it: the failure is turned into a status and execution continues, with the response members left `undefined`. A caller that must not proceed on a failed call has to read `responseStatus` and decide for itself.
+
+Add members to `input` and `output` only; `context` is not extended, and `context.currentUser` keeps the member name `user` with its `objectID` as generated — Studio re-resolves that reference on every open by matching the name against a dataType of the same name, which is why an empty `objectID` there is normal.
+
+`props` is editor bookkeeping — it lists the sections that accept new members, and its presence in the body changes nothing. Leave it exactly as found; files that lack it are equally valid, so never add one.
+
+## mock
+
+Canned responses used only in live preview and local runs; in every real environment the block is inert. Absent entirely on a service with no mocks.
+
+A mock entry has exactly four keys — this is the shape a new entry is created with:
+
+```json
+[ { "reqExp": "/mock/test",
+    "responseBody":  { "SampleResponseDTO": { "customerNumber": 12345 } },
+    "responseHeaders": {},
+    "responseStatus": 200 } ]
+```
+
+- `reqExp` is the entry's label, defaulting to `/mock/test`. It plays no part in choosing a mock at runtime — it only tells entries apart while authoring.
+- `responseBody`, `responseHeaders` and `responseStatus` are the canned response, and they are the only things a mock may set. Anything else written into an entry is discarded the next time the mock is edited, which rebuilds the entry from those three keys plus `reqExp`.
+- `responseBody` is written **wrapped in its root response element**: the runtime takes the first key of the object and hands its contents to `responseBody` extraction. It may also be a JSON string instead of an object.
+- `responseStatus` is the number the call reports; the generated value is `200`.
+- Because entries carry nothing to match a request against, **the first entry in the array is always the one used** — the rest are dead weight until one is moved to the front.
+- Once a model has a `mock` array, live preview and local runs use it instead of calling the service, and an empty array there fails the call outright.
+- Mind the plural: `responseHeaders`, not `responseHeader` as on the model root.
+
+## Easy to get wrong
+
+- `wsdlContentModelId` binds the model to its WSDL; the request/response dataTypes were generated from that same WSDL. Editing bindings is fine, but retyping a member to a shape the WSDL does not have breaks the call.
+- `hostKey` is the endpoint override, not the WSDL location — the WSDL comes from the referenced content model.
+- Request-side expressions accept only `input` and `context`; a literal there never lands.
+- `soapAction` is a plain string while `timeout`, `hostKey` and `methodName` are expression objects.
+- `timeout` resolves to milliseconds and is written as a string value.
+- `wsdlOptions` and `responseStatus` are store member names with fixed meaning — renaming them silently disables what they do.
+- Header maps are objects: duplicate or empty names silently lose data.
+- `objectID` and the `dataType`/`dataSet` member types always travel together, in both directions.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/platform/modules-and-overrides.md

@@ -0,0 +1,11 @@
+# Modules and overrides
+
+How to customize a model that comes from an imported module.
+
+- **The rule.** Models in an imported module are read-only — they never unlock. To change one, you **override** it: a Studio action that creates an app-local copy shadowing the module's model. You never author an override by hand; Studio creates it, you edit the result.
+- **Identity stays with the module model.** After an override, everything keeps working through the *module model's* identity: pickers and lists still offer the module model, other models keep referencing it, and at runtime the engine runs **the override's content under the module model's identity**. The override is a content supplier, not a new address. In Studio's tree the module model appears struck through; opening it opens the override's content.
+- **What the workspace shows.** An overridden pair appears as **one file**, at the module model's path — the override. It is editable like any app-local model. Its metadata header carries the override's own `id` plus an `overrides: <module model id>` line naming what it shadows; the shadowed module model has no file of its own while the override exists.
+- **References.** Other files keep referencing the module path (`ModuleName/folder/Model`), and sync restores those references to the module model's identity. Never rewrite a reference to point at the override itself.
+- **Editing.** Edit the override file like any model file (checked out first if it is read-only). Changes appear everywhere the module model is used, and they are what runs at runtime.
+- **Undoing.** Delete the override in Studio: the module model resurfaces as itself, and the next sync restores its read-only file. There is no merge or drift tracking — the override is a snapshot; updating the module's version does not update the override's content.
+- **Not overridable:** `persona`, `role`, `swimlane` and `privilege` models have no override mechanism.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/platform/modules.md

@@ -0,0 +1,9 @@
+# Modules
+
+How an application's content is grouped, and what module ownership means for the files in the workspace.
+
+- An application groups its models into **modules** — shareable folders of models. An app has its own modules, and it can **import** modules published elsewhere, optionally pinned to a released version.
+- On disk, a module's models live under a folder named after the module, and each file's metadata header carries the module's name as `ownerName`. References to a module model carry the module name as the first path segment: `ModuleName/folder/Model`.
+- **Own modules** (created inside this app) are ordinary content — their models are editable like any other model.
+- **Imported modules are read-only.** Their models can never be edited from this app: not by checking out, not by editing the file. They never unlock, whatever their file permissions happen to be. Treat them as reference material.
+- A version-pinned import shows the models of that released version. Choosing a different module version in Studio changes what the app sees; the workspace follows on the next sync.

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/ui-kit/examples/README.md

@@ -0,0 +1,12 @@
+# Examples — split by style system
+
+These reference pages are split into two folders by which **style system** they use. Pick the folder that matches the page you are working on (see the routing rule in [../index.md](../index.md) — read `opt.V` first).
+
+| Folder | Contains | Reference it when |
+| --- | --- | --- |
+| [`style/`](style/) | **S-system pages**: `opt.V >= 2.0` — design authored in the node's `S` object. | **Authoring a new page** or editing an **S-system** page (`opt.V >= 2.0`). This is the default. |
+| [`cssClass/`](cssClass/) | **Legacy pages**: `opt.V` missing or `< 2.0` — design via `O.layout` (`dOpt` + compiled `class`) / CSS utility classes. | **Only** when editing a **legacy** page (`opt.V` missing or `< 2.0`). |
+
+**Rule of thumb:** if you are building or styling in the `S` system, look **only** in [`style/`](style/) — do not copy patterns from [`cssClass/`](cssClass/), which contains the legacy mechanism you must not author on new/`S` pages.
+
+**Split axis:** the signal is the page's `opt.V`, kept consistent with whether the page actually uses the `S` Style System. A page with `opt.V >= 2.0` (authored with `S` style objects) is on the `S` system → `style/`; a page with `opt.V` missing or `< 2.0` (styled via `O.layout` + CSS classes) is legacy → `cssClass/`. The presence of an `S` object is the ground truth: **treat any page carrying an `S` object as S-system regardless of the folder it currently sits in** (a few partially-migrated pages still sit in `cssClass/`; 

package/dist/studio-cli/kits/wf-app-kit/.ai-kit/ui-kit/examples/cssClass/AllowdDates.qjson

@@ -0,0 +1,122 @@
+let pjson = {
+	"pJson": [
+		{
+			"T": "Messaging",
+			"P": {
+				"ID": {
+					"H": "EdtrComp_4",
+					"T": "prop"
+				}
+			},
+			"E": {
+				"EndRender": {
+					"H": "(<any>components.EdtrComp_2).allowedDates = val => parseInt(val.split('-')[1], 10) % 2 === 0;\r\n\r\n(<any>components.EdtrComp_1).allowedDates = val => parseInt(val.split('-')[2], 10) % 2 === 0",
+					"HL": "TS"
+				}
+			},
+			"C": {},
+			"_Editor": {
+				"eID": "EdtrComp_4"
+			},
+			"O": {
+				"cType": "child"
+			}
+		},
+		{
+			"T": "VInlineDatepicker",
+			"P": {
+				"ID": {
+					"H": "EdtrComp_1",
+					"T": "prop"
+				},
+				"label": {
+					"H": "'Pick a date'",
+					"T": "prop"
+				},
+				"locale": {
+					"H": "'tr'",
+					"T": "prop"
+				},
+				"willAttach": {
+					"H": "'true'",
+					"T": "prop"
+				}
+			},
+			"E": {},
+			"C": {},
+			"_Editor": {
+				"eID": "EdtrComp_1"
+			},
+			"O": {
+				"cType": "slot"
+			}
+		},
+		{
+			"T": "VDatePicker",
+			"P": {
+				"ID": {
+					"H": "EdtrComp_2",
+					"T": "prop"
+				},
+				"qValue": {
+					"H": "Date.now().toFormattedString('YYYY-MM-DD')",
+					"T": "prop"
+				},
+				"eventColor": {
+					"H": "'primary'",
+					"T": "prop"
+				},
+				"firstDayOfWeek": {
+					"H": "1",
+					"T": "prop"
+				},
+				"locale": {
+					"H": "'tr-tr'",
+					"T": "prop"
+				},
+				"visible": {
+					"H": "true",
+					"T": "prop"
+				},
+				"type": {
+					"H": "'month'",
+					"T": "prop"
+				}
+			},
+			"E": {},
+			"C": {
+				"default": {
+					"c": [
+						{
+							"T": "Ghost",
+							"P": {
+								"ID": {
+									"H": "EdtrComp_3",
+									"T": "prop"
+								}
+							},
+							"E": {},
+							"C": {},
+							"_Editor": {
+								"eID": "EdtrComp_3"
+							},
+							"O": {
+								"cType": "child"
+							}
+						}
+					],
+					"cType": "slot"
+				}
+			},
+			"_Editor": {
+				"eID": "EdtrComp_2"
+			},
+			"O": {
+				"cType": "slot"
+			}
+		}
+	],
+	"lrids": {},
+	"description": {}
+};
+export default pjson