@uipath/skills 1.203.0-preview.889 → 1.203.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uipath/skills",
-  "version": "1.203.0-preview.889",
+  "version": "1.203.0",
   "description": "UiPath agent skills for Claude Code, Codex, Cursor, Copilot, Gemini and OpenCode — RPA, UI automation, UI testing, coded agents/apps/workflows, and troubleshooting. Distributed as the UiPath Claude Code plugin.",
   "author": {
     "name": "UiPath"

package/skills/uipath-automationhub/references/api-endpoints.md

@@ -43,7 +43,7 @@ All idea flows (workflow types) on the tenant. Each element has `Idea flow name`
 ### GET `/idea-schema?idea_flow_id={id}`
 Full JSON schema for an idea flow + a ready-made `user_inputs` template. Response wrapped as `{ status: "success", data: {...} }`:
 - `data.properties.schema.properties` — field definitions, 3-level nested (Assessment Type > Section > Question); enums carry `answer_option` codes + labels in `custom_properties`.
-- `data.user_inputs` — the exact POST body template ("fill in the blanks"). Most fields wrap as `{ "value": <v> }`; owner/submitter questions take a direct string (no wrapper); questions with no example are omitted.
+- `data.user_inputs` — the exact POST body template ("fill in the blanks"). Every field wraps as `{ "value": <v> }` except **user questions**: owner, submitter, and any user picker the tenant adds (the schema marks them `format: email`). Those take the email as a **direct string**; the server also accepts `{ "value": <email> }` for them. A bare string on any other question reads as empty; questions with no example are omitted.
 
 *(Used by the publish flow.)*
 
@@ -54,7 +54,7 @@ Body:
 ```json
 { "idea_flow_id": <id>, "user_inputs": { "<AssessmentType>": { "<section-ahid>": { "<question-key>": { "value": "<v>" } } } } }
 ```
-**Do not POST `data.user_inputs` verbatim** — its example values are placeholders that the API rejects. Replace each with a real value; in particular resolve a **valid** `OVERVIEW_CATEGORY` id (the template's `1` → `Invalid Category Id`) and real `answer_option` codes (a placeholder code → backend `co_question_answer_option_value` crash).
+**Do not POST `data.user_inputs` verbatim** — its example values are placeholders that the API rejects. Replace each with a real value; in particular resolve a **valid** `OVERVIEW_CATEGORY` id (the template's `1` → `Invalid Category Id`) and real `answer_option` codes. A code not in that field's `enum` is never selected: on a `required` question the create fails with `Please fill in all the required information`, and `errorDetails` names the field (`An answer selection is required for submission`). On an optional question the create **succeeds and the answer is silently dropped**, so the preflight is the only guard.
 
 **Required fields (Business Process, `idea_flow_id`=7), verified live** — note the backend enforces owner + submitter even though the schema's `required` flags omit them:
 
@@ -69,6 +69,14 @@ Body:
 
 **Studio Web link** (optional): the schema's `OVR-OVERVIEW_STUDIO_WEB_LINK` question links the process to a Studio Web solution. Its `value` is a JSON **string** — `{"url": "<{baseUrl}/{org}/studio_/designer/{projectId}?solutionId={id}>", "name": "<solution name>", "hasProcessMap": <bool>}` (`url` required; `hasProcessMap: true` only when the solution's orchestration project has a `.bpmn` — it drives AH's Maestro diagram preview). Settable at create or via the update path; empty string unlinks.
 
+**Applications used** (`<ASSESSMENT>-COUNT_APPS`; optional unless the tenant flags it `required`): `value` is an array of `/appinventory` ids. When the schema shows a **`new_applications`** property beside `value`, the same answer can also create applications the inventory lacks — any submitter, no `MANAGE_APP_INVENTORY`, no `categoryIds`:
+
+```json
+{ "value": [12], "new_applications": [ { "application_name": "…", "application_version": "…", "application_language": "…" } ] }
+```
+
+Each entry: `application_name` required (1–50), optional `application_version` (≤20), `application_language` (≤50), `application_comments` (≤512), `application_is_citrix_client` (boolean); no other keys; ≤20 entries. Matched on name + version (case/space-insensitive) — a match reuses the existing inventory row, otherwise a new row is created and linked. Either key alone is fine at create. Set a new app's thin flag and comments **inline**, on its entry (`application_is_citrix_client: true`, `application_comments`), so the create needs no follow-up update. **Updates** (`PATCH /automations/{id}` with body `{ "user_inputs": { … } }`; working example in [`publish-process.md`](publish-process.md) Step 6b): `value` and `new_applications` together **replace** the process's whole application list. Ids in `value` resolve to bare inventory rows, so any update that answers "Applications used" also clears every existing thin flag and per-application comment. Leave both application questions out of an update unless the caller asked to change applications. If they did, send the complete list and the "Thin applications used" answer in the same update, and tell the user that per-application comments were reset. An answer with an empty `value` and no `new_applications` leaves the list unchanged: the Open API can't empty it, so a `200` there is not a removal. The property is absent on builds that predate it and when the admin disabled adding applications for the section. Rejections are `400` with message `Invalid Application Data. <reason>`: `Unknown application id(s): …`, `Adding new applications is disabled for this assessment…`, `…requires a non-empty application_name`, `…exceeds 50 characters`, `…invalid version, language, comments, or citrix flag`, `…has unknown field(s): …`, `new_applications must be an array…`, `At most 20 new applications…`. "Thin applications used" (`…-COUNT_THIN_APPS`) accepts inventory ids only.
+
 When a required field is missing the API may return `errorDetails: {}` (no field named) with `"Please fill in all the required information"` — usually the un-flagged owner/submitter, but **tenant admins can mark additional questions required** (commonly "Applications used"/"Thin applications used"); diff the payload against every `required`-flagged question in the live schema.
 
 **Response 201** — the standard envelope with the created process **nested under `data`**: `{ "message": "Resource Created", "statusCode": 201, "data": { "process_id": …, "process_uuid": …, "process_name": … } }`. Read **`data.process_id`** — it is NOT at the top level. If you received a 201 the process WAS created — never re-POST because a field read came back undefined; re-read the response instead. *(Used by the publish flow.)*
@@ -116,7 +124,7 @@ The Automation Hub users on the tenant (verified live): paged envelope with the
 **It is not the ground truth for who can own a process, and must never gate a publish.** Two defaults make it under-report: `invite` defaults to **activated users only**, so a user who has only ever used the API or CLI is missing from it while being perfectly able to own a process; and results are paged (default 20) under an ordering that is not deterministic when no search text is given, so a user can be absent from one page and present in another. Pass **`?s=<email>&invite=all`** for a scoped, server-side lookup — both parameters, since search alone still hides a not-invited user. The authority for the signed-in identity is the auth/identity call, and the authority for whether an owner is acceptable is the create response. *(Optional in the publish flow.)*
 
 ### GET `/appinventory?limit=<n>`
-The tenant's application inventory (paged; entries carry the application id, name, version, language). **This is the valid-answer set for tenant-required application questions** ("Applications used", "Thin applications used") in the publish flow. *(Used by the publish flow when the tenant requires application questions.)*
+The tenant's application inventory (paged; entries carry the application id, name, version, language). **These ids are the `value` answers for the application questions** ("Applications used", "Thin applications used"); systems not listed go in `new_applications` (see `POST /idea-from-schema`). *(Used by the publish flow whenever the material names systems.)*
 
 ### GET `/automations?search=<text>&limit=<n>&offset=<n>`
 Search/list processes. Returns a paged list (results under a resource key, e.g. `processes`, or a bare array). Use to resolve a name → `process_id`. *(Used by the get flow.)*

package/skills/uipath-automationhub/references/cli-commands.md

@@ -45,8 +45,8 @@ Failure: `Result` is `Failure`/`ValidationError` with a `Message` and usually an
 | `uip ah categories get` | category tree | `Data.Levels` + `Data.Categories` (nested `subcategories`; pick `category_is_active: 1` only) |
 | `uip ah users list` | list tenant users | entries carry `Email`, `IsActive`, `InviteStatus`; paged (default 20); filters: `--search`, `--invite-status`, `--limit` |
 | `uip ah users list --search <email> --invite-status all` | optional owner lookup | both flags needed; a miss is **no signal** — never block on it |
-| `uip ah applications update --file f.json` | create **or** update an application | `application_id: null` inserts; needs `MANAGE_APP_INVENTORY` (403 otherwise) |
-| `uip ah applications list` | app inventory (tenant-required application questions) | entries carry `Id`, `Name` |
+| `uip ah applications update --file f.json` | create **or** update an application | `application_id: null` inserts; needs `MANAGE_APP_INVENTORY` (403 otherwise). **Publish flow: prefer `new_applications` in the answer** — see `publish-process-cli-guide.md` → Applications |
+| `uip ah applications list` | app inventory (answers for application questions) | entries carry `Id`, `Name`, `Version` |
 | `uip ah automations create --from-schema --idea-flow-id <id> --file <answers.json>` | **create the process** | `Data.Id` is the new process id |
 | `uip ah documents create <automation-id> --title <t> --description <d> --document-type-id <n> --file <path>` | **upload a document's bytes** | `Data.Id` (document id) + `Data.FileId`; use `--embed-link <url>` *instead of* `--file` for link-only docs (exactly one of the two) |
 | `uip ah documents list <automation-id>` | verify attachments | entries carry `Id`, `Title`, `FileId` (file-backed) or `EmbedLink` (link-backed) |

package/skills/uipath-automationhub/references/publish-process-cli-guide.md

@@ -44,7 +44,7 @@ First **enumerate the tenant's actual required set from the schema file**: every
 | **Documentation** answer code | The `PROCESS_DOCUMENTS` question's own `enum` in the schema — match by label, send its `answer_option` code. |
 | **Owner email** | **`uip ah auth-info get`** → `Data.User.Email` is the signed-in identity and the default owner. That call is the authority; do not substitute an address from any list. |
 | **Submitter email** | Same as owner; usually the same person. |
-| **Application questions** (when tenant-required) | `uip ah applications list` → match the material's systems. Missing ones: **create them** (below). If creating fails for any reason, pick from the listed entries and record the real systems in the description — never block the publish on applications. |
+| **Application questions** | Driven by **what the material names** — see [Applications](#applications) below. `uip ah applications list` → select the systems that exist; send the ones that don't as `new_applications`. None named and the question not required → leave it out. Never block the publish on applications. |
 
 The discovery commands are independent — run the ones you need (`auth-info get`, `categories get`, `applications list`) **in a single shell invocation** rather than one per turn; each is fast, the round-trips between them are not.
 
@@ -56,9 +56,46 @@ uip ah users list --search "<owner-email>" --invite-status all
 
 Both flags: `--search` keeps it server-side and off the page limit; `--invite-status all` is required because the default filter hides users who can still own a process. Whatever it returns, use the `auth-info` email verbatim, submit, and let the API decide — only a real `Cannot identify owner by email` from the create is an owner problem (Step 5).
 
-### Creating a missing application
+### Applications
 
-`uip ah applications` has no `create` verb — **creation happens through `update`**, by sending an element whose `application_id` is `null`. The service upserts: an element with a real id updates that application, an element with `null` inserts a new one. (The CLI's own `update --help` claims it cannot add one; that is wrong, and it is why agents give up here.)
+**Answer from the material, one PDD at a time.** Record exactly the systems the PDD/SDD names — no more, no fewer:
+
+- **Named and in the inventory** → put their ids in the question's `value` array.
+- **Named but not in the inventory** → add them in the same answer (below). A missing system is never a reason to stop, to ask the user, or to pick a look-alike.
+- **Nothing named** → if the schema does **not** flag the application question `required`, **omit it entirely** — a process with no applications is valid. Never pad the answer with inventory entries to "fill it in". Only when the tenant flags it `required` and the material names no system, ask the user with `AskUserQuestion` (inventory entries as options, plus free text for a system not in the list).
+
+#### Adding systems that are not in the inventory — `new_applications`
+
+Check the schema first: if the application question (`<ASSESSMENT>-COUNT_APPS`, "Applications used") has a **`new_applications`** property next to `value`, the submission itself can create applications — **no admin permission, no separate call, no `categoryIds`**. Send the new systems alongside any existing ids:
+
+```json
+"OVR-COUNT_APPS": {
+  "value": [12],
+  "new_applications": [
+    { "application_name": "Kinaxis RapidResponse", "application_version": "2026.2", "application_language": "English" },
+    { "application_name": "SUNAT Portal" }
+  ]
+}
+```
+
+- `application_name` is required (1–50 chars); `application_version` (≤20), `application_language` (≤50), `application_comments` (≤512), `application_is_citrix_client` (boolean) are optional. At most **20** per submission. No other fields are accepted.
+- Each entry is **matched by name + version, ignoring case and surrounding spaces**: an entry that matches an existing application reuses it, so sending a system that turns out to be in the inventory is harmless — it never creates a duplicate. Keep the version the material gives; a different version is a different application.
+- Created applications land in the tenant's application inventory (the same as a user typing one in the web form), and are selectable by id on every later submission.
+- `new_applications` exists only on "Applications used". "Thin applications used" (`…-COUNT_THIN_APPS`) takes inventory ids only and just flags applications already answered in "Applications used" — an id that is not in "Applications used" has no effect, and an id not in the inventory is rejected. A newly added application has no id until the create returns, so flag it as thin **inline** instead: `application_is_citrix_client: true` on its `new_applications` entry. Don't answer the application questions in a later `automations update` unless the caller asked to change applications. Updates replace the whole list and clear thin flags and comments (see [`api-endpoints.md`](api-endpoints.md), `new_applications`).
+
+A `400` whose message starts `Invalid Application Data.` names the problem — fix it locally and retry once:
+
+| Message tail | Fix |
+|---|---|
+| `Unknown application id(s): …` | An id in `value` is not in `applications list` — drop it or move that system to `new_applications`. |
+| `Adding new applications is disabled for this assessment…` | The tenant admin turned off adding applications for this section. Fall back to [the admin upsert](#fallback-no-new_applications-in-the-schema), then to substitution. |
+| `…requires a non-empty application_name` / `…exceeds 50 characters` / `…invalid version, language, comments, or citrix flag` | Fix that entry's field. |
+| `…has unknown field(s): …` | Drop the named key — usually a typo, or an `application_id` (ids go in `value`). |
+| `At most 20 new applications…` | Keep the 20 most material systems; name the rest in the description. |
+
+#### Fallback: no `new_applications` in the schema
+
+The property is absent on Automation Hub builds that predate it, and whenever the admin has disabled adding applications for that section. Then, and only then, create through the inventory API. `uip ah applications` has no `create` verb — **creation happens through `update`**, by sending an element whose `application_id` is `null`. The service upserts: an element with a real id updates that application, an element with `null` inserts a new one. (The CLI's own `update --help` claims it cannot add one; that is wrong, and it is why agents give up here.)
 
 All five fields are required by the request schema, and `categoryIds` needs at least one valid id from `uip ah categories get`:
 
@@ -82,9 +119,21 @@ Then re-read `uip ah applications list` and use the new ids in the answer.
 {"Result":"Failure","Message":"This user is not permitted to perform this action based on their role. (403 Forbidden)"}
 ```
 
-**If creating fails for any reason — 403, a validation error, a bad category id, anything — fall through; never retry it and never stop.** Pick the closest entries from `applications list` to satisfy the required field, and name the real systems in `OVERVIEW_DESCRIPTION` (e.g. "Systems per PDD: Salesforce, CREDILEX, SUNAT Portal — not in tenant inventory"). The process record is what matters; applications are editable afterwards. **Never abandon a publish because an application is missing or uncreatable, and never silently pass off an unrelated application as the real one — say what you substituted.**
+**If creating fails for any reason — 403, a validation error, a bad category id, anything — fall through; never retry it and never stop.** Answer with the systems that *are* in the inventory; if that leaves a **required** question empty, pick the closest entries from `applications list` to satisfy it (an optional one stays empty). Either way, name the real systems in `OVERVIEW_DESCRIPTION` (e.g. "Systems per PDD: Salesforce, CREDILEX, SUNAT Portal — not in tenant inventory"). The process record is what matters; applications are editable afterwards. **Never abandon a publish because an application is missing or uncreatable, and never silently pass off an unrelated application as the real one — say what you substituted.**
+
+Write the answers to `./ah-answers.json` as the filled `user_inputs` structure (the CLI accepts the whole schema-get document or just the answers map). Wrapping rules unchanged: every field is `{ "value": <v> }` except **user questions**: owner, submitter, and any user picker the tenant adds (the schema marks them `format: email`). Those take the email as a **direct string**; the server also accepts `{ "value": <email> }` for them (a bare string on any other question reads as empty); enum codes from that field's own `enum`; integers as numbers. Show the user a concise preview and get a confirm before writing.
+
+### Preflight: check the answers against the schema
+
+`ah-schema.json` is the same document the service validates against, so check `ah-answers.json` against it locally **before** creating:
+
+1. **Required answers present** — every question the schema flags `required`, plus owner and submitter (enforced but never flagged), has a non-empty value. Take requiredness from *this tenant's* schema, never from a fixed list: the same Business Process flow requires `COUNT_APPS` on one tenant and rejects it on another.
+2. **Every answer wrapped** — each answer except user questions (owner, submitter, any `format: email` user picker) is an object with a `value` key. A bare string is read as empty: on `OVR-OVERVIEW_NAME` that fails as `Automation name cannot be empty.`, elsewhere as a missing answer.
+3. **Enum codes verbatim** — every enum answer (Documentation, application questions, any select) is a code that appears exactly in that question's own `enum`. Copy it; never retype it. A code with a dropped segment (`…-ovrbp-0-3-5` instead of `…-ovrbp-0-3-0-5`) is never selected: a `required` question then fails with `Please fill in all the required information`, and an optional one is **silently dropped**, so this check is the only guard.
+4. **No placeholders left** — no `Sample input`, no `First.last@example.com`, no template category `1` unless the tenant's tree really has it.
+5. **Applications match the material** — every system the PDD names is either an id in `value` or an entry in `new_applications` (only if the schema has that property); nothing the PDD doesn't name; no application question at all when the PDD names none and it isn't `required`.
 
-Write the answers to `./ah-answers.json` as the filled `user_inputs` structure (the CLI accepts the whole schema-get document or just the answers map). Wrapping rules unchanged: most fields `{ "value": <v> }`; owner/submitter are **direct strings**; enum codes from that field's own `enum`; integers as numbers. Show the user a concise preview and get a confirm before writing.
+Fix anything found locally, then create. This costs nothing on a correct payload and catches most of the `400`s below before they happen.
 
 ## Step 5: Create the process
 
@@ -93,7 +142,8 @@ uip ah automations create --from-schema --idea-flow-id $IDEA_FLOW_ID --file ./ah
 ```
 
 - `Result: Success` → **`Data.Id`** is the new process id. A success means it WAS created — never re-run on a confusing field read (that duplicates).
-- `ValidationError`/`Failure` → the `Message`/`Instructions` carry the service's validation text; the same causes as the API flow apply (unnamed required field → owner/submitter first, then diff against the schema's required set; `Invalid Category Id`; placeholder answer codes). Fix and retry **once**.
+- `ValidationError`/`Failure` → the `Message`/`Instructions` carry the service's validation text; the same causes as the API flow apply (unnamed `Please fill in all the required information` → re-run the preflight: a missing required answer or an enum code that is not verbatim from the schema; `Invalid Category Id`; `Automation name cannot be empty.` → `OVR-OVERVIEW_NAME` is missing, empty, or a bare string instead of `{ "value": … }`; `errorDetails` with `An answer selection is required for submission` on a field → that field's enum code isn't copied verbatim from its `enum`). Fix and retry **once**.
+- `Cannot set properties of undefined (setting 'co_question_answer_option_value')`, or `Question "<key>" can't be answered on this tenant: it has no answer slot to hold a value…` → **a server-side defect: this tenant has nowhere to store one of your free-text answers** (an answer whose schema `value` is a plain `string` or `number` with no `enum`). Your values aren't wrong, so don't rewrite them. Newer builds return `Question "<key>" can't be answered on this tenant: it has no answer slot to hold a value…` instead, naming the question: drop exactly that key. The older message names nothing: drop every **optional** free-text answer. In both cases keep every `required` answer and owner/submitter, retry **once**, and tell the user which answers were left out. If it still fails, or the named question is `required`, stop and report it with the tenant and `--idea-flow-id`.
 - `Cannot identify owner by email` → **not a typo'd address; do not retry with a different email.** The account is authenticated but has never been activated on this tenant. Confirm with `uip ah auth-info get` — `IsActive: 1` plus a role list proves the identity is real — then tell them to open Automation Hub in a browser once and sign in, and retry unchanged:
 
   ```

package/skills/uipath-automationhub/references/publish-process.md

@@ -40,7 +40,7 @@ curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
 
 Parse `data.properties.schema.properties` for the field catalog (Assessment Type > Section > Question; note types, required flags, enum `answer_option` codes/labels) and keep `data.user_inputs` as the payload template. The process-name question (key contains `OVERVIEW_NAME`) is **required**.
 
-> ⚠️ **Do NOT POST `data.user_inputs` verbatim.** The template ships **example/placeholder values that the API rejects** — e.g. `OVERVIEW_CATEGORY: 1` (→ `Invalid Category Id`), a placeholder `PROCESS_DOCUMENTS` answer-option that triggers a backend `co_question_answer_option_value` crash, and `First.last@example.com` owner/submitter emails. Treat the template as **shape only** and replace every value with a real one (below).
+> ⚠️ **Do NOT POST `data.user_inputs` verbatim.** The template ships **example/placeholder values that the API rejects** — e.g. `OVERVIEW_CATEGORY: 1` (→ `Invalid Category Id`), an example `PROCESS_DOCUMENTS` answer that has nothing to do with the real documents, and `First.last@example.com` owner/submitter emails. Treat the template as **shape only** and replace every value with a real one (below).
 
 ## Step 4: Collect the inputs, then assemble the payload
 
@@ -59,9 +59,25 @@ The six baseline inputs:
 | **Owner email** | The **signed-in identity is the default owner** — take it from the auth/identity call, not from a list. `GET /users` is optional; if you use it, do a targeted lookup with `?s=<email>&invite=all` (both parameters — the default filter hides users who can still own a process) and treat a miss as no signal. **Never block the publish on it** — submit and let the API decide. |
 | **Submitter email** | Same recipe as owner; usually the same person. |
 
-**Tenant-required application questions** ("Applications used", "Thin applications used", and similar): the valid answers are the tenant's application inventory — `GET /appinventory` (paged; entries carry the app id, name, version, language). Match what the caller's material names. Follow that question's own schema shape for how the selected entries are encoded in `user_inputs`.
+**Application questions** ("Applications used", "Thin applications used"): **answer from the material, one PDD at a time** — record exactly the systems it names. The inventory is `GET /appinventory` (paged; entries carry the app id, name, version, language).
+- **Named and in the inventory** → their ids go in the question's `value` array.
+- **Named but not in the inventory** → add them in the same answer via `new_applications` (below). A missing system is never a reason to stop, to ask, or to pick a look-alike.
+- **Nothing named** → if the schema does **not** flag the question `required`, **omit it** — a process with no applications is valid; never pad it with inventory entries. Only when it is flagged `required` and the material names no system, `AskUserQuestion` (inventory entries plus free text).
 
-**When the material's systems are not in the inventory, create them** — `PUT /appinventory` upserts, and an element whose `application_id` is `null` inserts:
+**Adding systems that are not in the inventory.** If the "Applications used" question (`<ASSESSMENT>-COUNT_APPS`) in the live schema has a **`new_applications`** property next to `value`, the submission itself creates them — no admin permission, no extra call, no `categoryIds`:
+
+```json
+"OVR-COUNT_APPS": {
+  "value": [12],
+  "new_applications": [
+    { "application_name": "Kinaxis RapidResponse", "application_version": "2026.2", "application_language": "English" }
+  ]
+}
+```
+
+`application_name` required (1–50 chars); `application_version` (≤20), `application_language` (≤50), `application_comments` (≤512), `application_is_citrix_client` (boolean) optional; at most 20 per submission. Entries are matched on **name + version, case- and space-insensitive** — a match reuses the existing application, so it never duplicates. New ones land in the tenant inventory and are selectable by id afterwards. "Thin applications used" (`…-COUNT_THIN_APPS`) takes inventory ids only and just flags apps already answered in "Applications used". To flag a new app as thin, set `application_is_citrix_client: true` on its entry, so the create needs no follow-up update. Updates replace the whole list; read [`api-endpoints.md`](api-endpoints.md) (`new_applications`) before touching applications on an existing process. The field contract and its `400` messages are in [`api-endpoints.md`](api-endpoints.md) → `POST /idea-from-schema`.
+
+**Fallback — no `new_applications` in the schema** (an Automation Hub build that predates it, or the admin disabled adding applications for that section, which also returns `400 "…Adding new applications is disabled for this assessment…"`): create through the inventory API. `PUT /appinventory` upserts, and an element whose `application_id` is `null` inserts:
 
 ```json
 [{ "application_id": null, "application_name": "SUNAT Portal",
@@ -69,11 +85,11 @@ The six baseline inputs:
    "categoryIds": [1] }]
 ```
 
-All five fields are required and `categoryIds` needs ≥1 real id. This needs the **`MANAGE_APP_INVENTORY`** permission; ordinary roles do not have it and get a `403 "This user is not permitted to perform this action based on their role."` **If creating fails for any reason — that 403, a validation error, a bad category id, anything — fall through; never retry it and never stop.** Pick the closest inventory entries to satisfy the required field and name the real systems in the description. **Never abandon a publish because an application is missing or uncreatable, and never pass off a substituted application as the real one without saying so.**
+All five fields are required and `categoryIds` needs ≥1 real id. This needs the **`MANAGE_APP_INVENTORY`** permission; ordinary roles do not have it and get a `403 "This user is not permitted to perform this action based on their role."` **If creating fails for any reason — that 403, a validation error, a bad category id, anything — fall through; never retry it and never stop.** Answer with the systems that *are* in the inventory; only if that leaves a **required** question empty, pick the closest entries to satisfy it (an optional one stays empty). Either way, name the real systems in the description. **Never abandon a publish because an application is missing or uncreatable, and never pass off a substituted application as the real one without saying so.**
 
 Then build `user_inputs` using the template's **structure** but the **collected values**:
 - Place each value in its `AssessmentType > section > question` slot.
-- Follow the template's wrapping per field: most are `{ "value": <v> }`; owner/submitter questions take a **direct string** (no `value` wrapper).
+- Follow the template's wrapping per field: **every** answer is `{ "value": <v> }` except **user questions**: owner, submitter, and any user picker the tenant adds (the schema marks them `format: email`). Those take the email as a **direct string**; the server also accepts `{ "value": <email> }` for them. Never send a bare string for any other question: it reads as an empty answer, and on `OVR-OVERVIEW_NAME` the API rejects it with `Automation name cannot be empty.`
 - Convert enum labels to their `answer_option` codes taken from that field's own `enum` in the schema — **never** reuse the template's placeholder code. Send integers as numbers.
 
 **Required fields for `idea_flow_id` = Business Process** (verified live — the backend enforces owner + submitter even though the schema's `required` flags do **not** list them):
@@ -89,6 +105,8 @@ Then build `user_inputs` using the template's **structure** but the **collected
 
 Include only sections that have at least one populated field. Show the user a concise preview (name + key fields, and "show raw JSON" on request) and get a confirm before writing.
 
+**Preflight before creating:** validate the payload against the schema you fetched — every `required`-flagged question plus owner/submitter answered; every answer except user questions wrapped as `{ "value": … }` (a bare string reads as empty); every enum answer a code copied **verbatim** from that question's own `enum` (a code with a dropped segment is never selected: a `required` question then fails with `Please fill in all the required information`, and an optional one is silently dropped); no template placeholders left; applications exactly the systems the material names (ids in `value`, the rest in `new_applications` when the schema offers it, the question omitted when none are named and it isn't `required`). Requiredness comes from *this tenant's* schema, never a fixed list — the same flow requires `COUNT_APPS` on one tenant and rejects it on another.
+
 ## Step 5: Create the process
 
 ```bash
@@ -102,7 +120,7 @@ where `$PAYLOAD` is `{ "idea_flow_id": <id>, "user_inputs": { … } }`.
 
 - **201** → the envelope is `{ "message": "Resource Created", "statusCode": 201, "data": { … } }` — read **`data.process_id`** (it is nested, NOT top-level). Keep it for Step 6. A 201 means the process WAS created: if a field read comes back undefined, re-read the response — **never re-POST** (that creates a duplicate and 409s).
 - **400** → fix and retry. The message shapes seen live:
-  - `errorDetails: { "<question>": ["An answer selection is required…"] }` → that required field is missing/empty; add it.
+  - `errorDetails: { "<question>": ["An answer selection is required…"] }` → that required field is missing or empty, or its enum code isn't copied verbatim from that field's `enum`. Fix it.
   - `errorDetails: {}` with `"Please fill in all the required information"` → a required field the API **won't name** is missing. Check in order: (1) owner (`OVR-PROCESS_OWNER`) / submitter (`OVR-OVERVIEW_PROCESS_SUBMITTER`) — enforced but never flagged; (2) **diff your payload against every `required`-flagged question in the live schema** — tenant admins add required questions (e.g. "Applications used" / "Thin applications used"), and a payload missing any of them gets this same generic 400. Fill the gaps (Step 4 recipes), then retry once.
   - `"Cannot identify owner by email"` (`localizationKey: error_invalid_process_owner`) → **not a typo'd address; do not retry with a different email.** The account is authenticated but has never been activated on this tenant: AH creates a user row just-in-time on first authenticated call, and only an interactive web sign-in promotes it to the state owner/submitter assignment requires. Confirm the identity is real with the auth/identity call (`IsActive: 1` plus a role list), then tell them to open Automation Hub in a browser once and sign in, and retry unchanged:
 
@@ -112,7 +130,9 @@ where `$PAYLOAD` is `{ "idea_flow_id": <id>, "user_inputs": { … } }`.
 
     Build that URL from the org/tenant you are already authenticated against — never from the error response. Nothing was created, so the retry is safe. Newer Automation Hub versions accept these users with no sign-in at all, so on an up-to-date tenant this error should not appear.
   - `"Invalid Category Id."` → `OVERVIEW_CATEGORY` isn't a real category on this tenant (see Step 4).
-  - `Cannot set properties of undefined (setting 'co_question_answer_option_value')` → an enum field carries an invalid `answer_option` code (you left a template placeholder in). Use a code from that field's `enum`.
+  - `"Automation name cannot be empty."` → `OVR-OVERVIEW_NAME` is missing from the payload, empty, or a bare string. Send it under its section as `{"value": "<name>"}`, then retry once.
+  - `Cannot set properties of undefined (setting 'co_question_answer_option_value')`, or `Question "<key>" can't be answered on this tenant: it has no answer slot to hold a value…` → **a server-side defect: this tenant has nowhere to store one of your free-text answers** (an answer whose schema `value` is a plain `string` or `number` with no `enum`). Your values aren't wrong, so don't rewrite them. Newer builds return `Question "<key>" can't be answered on this tenant: it has no answer slot to hold a value…` instead, naming the question: drop exactly that key. The older message names nothing: drop every **optional** free-text answer. In both cases keep every `required` answer and owner/submitter, retry **once**, and tell the user which answers were left out. If it still fails, or the named question is `required`, stop and report it with the tenant and `idea_flow_id`.
+- **500** on create, with no `user_inputs` key at the top of the body → the answers weren't wrapped. Send `{ "idea_flow_id": <id>, "user_inputs": { … } }` and retry once.
 - **401** → re-authenticate. **409** → duplicate name; ask the user for a new name or stop.
 
 ## Step 6: Attach documents (PDD/SDD)

package/version-manifest.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 2,
-  "skillsVersion": "1.203.0-preview.889",
+  "skillsVersion": "1.203.0",
   "targetCli": "^1.203.0"
 }