@uipath/skills 1.195.1 → 1.196.0

package/skills/uipath-troubleshoot/references/products/agents/playbooks/is-invalid-credentials.md

@@ -0,0 +1,123 @@
+---
+confidence: high
+---
+
+# IS Invalid Credentials (401)
+
+## Context
+
+What this looks like:
+- Agent job faults during an IS tool call; `uip agent run status <job-id> --output json` shows `Faulted`
+- `uip traces spans get <trace-id> --output json` contains a `toolCall` span whose `ATTRIBUTES.error` contains:
+  ```
+  {"details":"Invalid Organization or User secret, or invalid Element token provided.","message":"Failed to execute IS call to /curated_soqlQuery: HTTP Status: 401 - Unauthorized","status":400}
+  ```
+- The `message` field identifies the IS endpoint and connector type — the error is connector-agnostic (Salesforce, Slack, Jira, ServiceNow, and others all produce the same 401 pattern)
+- Failure is immediate (first IS call in the run); no successful IS calls precede it
+
+What can cause it:
+- IS connection is in the personal workspace or a folder different from where the agent executes — IS cannot resolve the connection at runtime (most common cause)
+- OAuth client secret or API key stored in the IS connection was rotated or expired on the external system
+- The user account whose delegated credentials are stored in the connection was deactivated or de-provisioned
+- An Element token (connector-level auth) was manually revoked
+- IS connection was created with sandbox credentials and deployed to production (or vice versa)
+
+What to look for:
+- Whether the connection is in the correct folder — `uip is connections list` and check the folder/scope
+- Whether `details` says `Invalid Organization or User secret` (connection-level credentials) vs. `invalid Element token` (connector-level) — fix path differs
+- Whether other IS connections to the same external system also return 401 (system-wide credential change vs. single-connection issue)
+
+## Investigation
+
+1. Get the job trace ID:
+
+   ```bash
+   uip agent run status <job-id> --output json \
+     --output-filter "traceId"
+   ```
+
+2. Pull the IS tool call span and extract the error:
+
+   ```bash
+   uip traces spans get <trace-id> --output json \
+     --output-filter "spans[?attributes.error != null].{name: name, spanType: spanType, error: attributes.error}"
+   ```
+
+3. Parse the error JSON to identify credential type:
+
+   ```bash
+   uip traces spans get <trace-id> --output json \
+     --output-filter "spans[?attributes.error != null].attributes.error" \
+     | jq -r '.[] | fromjson | .details' 2>/dev/null \
+     || grep -o '"details":"[^"]*"'
+   ```
+
+   - `Invalid Organization or User secret` → connection-level credentials invalid (OAuth client ID/secret or API key)
+   - `invalid Element token` → connector-level Element token revoked
+
+4. List IS connections and verify scope — the connection must be in the folder where the agent runs:
+
+   ```bash
+   uip is connections list --output json \
+     --output-filter "connections[?name == '<connection-name>'].{id: id, name: name, connector: connector, folders: resource.folders}"
+   ```
+
+5. Ping to confirm authentication fails:
+
+   ```bash
+   uip is connections ping <connection-id> --force-refresh --output json
+   ```
+
+## Resolution
+
+**If the connection is in the wrong folder or personal workspace:**
+
+  Create a new connection scoped to the correct folder:
+
+  ```bash
+  uip is connections create <connector-key> --output json
+  ```
+
+  Note the new connection ID. Update `properties.connection.id`, `properties.connection.name`, and `solutionProperties.resourceKey` in `<agent-path>/resources/<ToolName>/resource.json` to the new connection ID — see [`uipath-agents`](/uipath:uipath-agents) IS tool reference for the full resource shape.
+
+  Validate, refresh, and republish:
+
+  ```bash
+  uip agent validate --output json
+  uip solution resource refresh --output json
+  uip solution publish --output json
+  ```
+
+  > Use this same rebind sequence for all resolution paths that create a new connection.
+
+**If `Org/User secret` invalid — re-authenticate with updated credentials:**
+
+  On the external system, regenerate the client secret. Then:
+
+  ```bash
+  uip is connections edit <connection-id>
+  ```
+
+  Complete OAuth flow with the new credentials.
+
+**If `Element token` invalid — recreate the connection:**
+
+  Element tokens cannot be refreshed in place. Delete the stale connection and create a new one:
+
+  ```bash
+  uip is connections delete <connection-id> --output json
+  uip is connections create <connector-key> --output json
+  ```
+
+  Note the new connection ID. Then use the rebind sequence above.
+
+**If the user account was deactivated or connection targets the wrong environment:**
+
+  Delete the stale connection and create a new one in the correct context:
+
+  ```bash
+  uip is connections delete <connection-id> --output json
+  uip is connections create <connector-key> --output json
+  ```
+
+  Note the new connection ID. Then use the rebind sequence above.

package/skills/uipath-troubleshoot/references/products/agents/playbooks/is-invalid-element-instance.md

@@ -0,0 +1,96 @@
+---
+confidence: high
+---
+
+# IS Invalid Element Instance (404)
+
+## Context
+
+What this looks like:
+- Agent job faults during an IS tool call; `uip agent run status <job-id> --output json` shows `Faulted`
+- `uip traces spans get <trace-id> --output json` contains a `toolCall` span whose `ATTRIBUTES.error` contains:
+  ```
+  {"detail":"Invalid Element Instance Id provided.","message":"Failed to execute IS call to /search: HTTP Status: 404 - Not Found","status":400}
+  ```
+- The IS endpoint in `message` varies (`/search`, `/records`, `/curated_contact`, etc.) but `detail` is always `Invalid Element Instance Id provided`
+- Unlike 401/403 errors, this can fire mid-run — earlier IS calls in the same run may have succeeded
+
+What can cause it:
+- The IS connection referenced by the agent tool was deleted after the agent was published
+- Agent deployed to a different environment (staging → production) where the source environment's IS connection does not exist — IS does not auto-create connections
+- The connection ID in the agent's tool configuration was manually edited to a non-existent value
+- A backend platform issue invalidated element instance IDs — `uip is connections list` shows the connection as healthy but the underlying instance is no longer valid; requires a support ticket
+
+What to look for:
+- Whether the agent was recently deployed to a new folder or environment
+- Whether an IS administrator deleted the connection for this connector recently
+- Whether user action (deletion, redeployment) explains the missing connection — if not, escalation is needed
+- The tool name in the faulting span — identifies which IS connection the agent is trying to use
+
+## Investigation
+
+1. Get the job trace ID:
+
+   ```bash
+   uip agent run status <job-id> --output json \
+     --output-filter "traceId"
+   ```
+
+2. Pull the faulting `toolCall` span and note the span name:
+
+   ```bash
+   uip traces spans get <trace-id> --output json \
+     --output-filter "spans[?attributes.error != null].{name: name, spanType: spanType, error: attributes.error}"
+   ```
+
+   The span `name` identifies which tool (and IS connection type) caused the 404.
+
+3. List current IS connections and locate the connection the agent should be using:
+
+   ```bash
+   uip is connections list --output json \
+     --output-filter "connections[*].{id: id, name: name, connector: connector}"
+   ```
+
+   - If no connection matches the connector type → the connection was deleted or never existed in this environment; proceed to Resolution.
+   - If a matching connection exists and shows as healthy → suspect backend migration; capture the trace ID and escalate to the Integration Service team.
+
+4. Ping the candidate connection to confirm it is active:
+
+   ```bash
+   uip is connections ping <connection-id> --force-refresh --output json
+   ```
+
+## Resolution
+
+**If the connection was deleted — recreate it and rebind the agent:**
+
+  Create a new IS connection:
+
+  ```bash
+  uip is connections create <connector-key> --output json
+  ```
+
+  Note the new connection ID from the output. The span name from step 2 identifies `<ToolName>`. Update `properties.connection.id`, `properties.connection.name`, and `solutionProperties.resourceKey` in `<agent-path>/resources/<ToolName>/resource.json` to the new connection ID — see [`uipath-agents`](/uipath:uipath-agents) IS tool reference for the full resource shape.
+
+  Validate, refresh, and republish:
+
+  ```bash
+  uip agent validate --output json
+  uip solution resource refresh --output json
+  uip solution publish --output json
+  ```
+
+**If the connection doesn't exist in the target environment — create it first:**
+
+  IS does not auto-create connections during agent deployment. Create the connection in the target environment:
+
+  ```bash
+  uip is connections create <connector-key> --output json
+  ```
+
+  Then update the `resource.json` and republish using the same sequence above.
+
+**If the connection appears healthy but the 404 persists — escalate to Integration Service team:**
+
+  Not user-fixable. Open a support ticket with UiPath and provide the trace ID and the connection ID from `uip is connections list`.

package/skills/uipath-troubleshoot/references/products/agents/playbooks/llm-insufficient-information.md

@@ -58,8 +58,8 @@ What to look for:
 - Validate and republish:
 
   ```bash
+  uip agent refresh --output json   # upgrades agent.json to the latest schema version and regenerates derived files
   uip agent validate --output json
-  uip agent migrate --output json  # upgrades agent.json to the latest schema version; skip if validate reports no schema version change
   uip agent publish --output json
   ```
 

package/skills/uipath-troubleshoot/references/products/agents/summary.md

@@ -7,3 +7,7 @@ Covers errors from `uip agent` (low-code agents). Primary investigation surface:
 | Input Schema Validation Failure | High | `agent.json failed schema validation` (Variant A: config schema) or `Data failed json schema validation DynamicType_0 BatchJson` (Variant B: input payload). Faults at agent startup before any LLM call. | [input-schema-validation-failure.md](./playbooks/input-schema-validation-failure.md) |
 | Context Grounding Index Not Found | High | `ContextGroundingIndex not found Code: AGENT_RUNTIME.UNEXPECTED_ERROR` on a `contextGroundingTool` span. Grounding index deleted or mis-referenced after publish. | [context-grounding-index-not-found.md](./playbooks/context-grounding-index-not-found.md) |
 | LLM Call Failed — Insufficient Information | Medium | `{"detail":"Insufficient information..."}` on a `completion` or `agentRun` span. System prompt too vague or required input missing from caller payload. | [llm-insufficient-information.md](./playbooks/llm-insufficient-information.md) |
+| Guardrail Violation | High | `AGENT_RUNTIME.TERMINATION_GUARDRAIL_VIOLATION` on `agentRun` span or a `{agent\|llm\|tool}{Pre\|Post}Guardrails` container span. Pre-stage = input-side block; post-stage = output-side block. Trigger payload on `guardrailEvaluation`/`toolGuardrailEvaluation` child span. Also fires when Escalate action reviewer rejects. | [guardrail-violation.md](./playbooks/guardrail-violation.md) |
+| IS Connection Disabled (403) | Medium | IS Event call returns 403 — connection disabled after consecutively failing to refresh the token; re-authenticate to restore. | [is-connection-disabled.md](./playbooks/is-connection-disabled.md) |
+| IS Invalid Credentials (401) | High | IS call returns 401 — most common cause: connection in wrong folder or personal workspace (folder/scope mismatch). Also: Org/User secret or Element token rotated, expired, or sandbox/production mismatch. | [is-invalid-credentials.md](./playbooks/is-invalid-credentials.md) |
+| IS Invalid Element Instance (404) | High | IS call returns 404 — Element Instance Id referenced in the agent was deleted, or the agent was deployed to an environment where the connection doesn't exist. | [is-invalid-element-instance.md](./playbooks/is-invalid-element-instance.md) |

package/skills/uipath-troubleshoot/references/products/orchestrator/investigation_guide.md

@@ -18,7 +18,7 @@ Only after identity is resolved, fetch data and verify every result against it:
 If data doesn't match: **discard it**. Do NOT fetch details for jobs or items from other processes. Do NOT use unrelated data as a proxy. Report the mismatch and ask for clarification.
 
 4. **Job selection** — if multiple jobs exist for the identified process, present the list to the user (showing state, timestamp, error summary) and ask which one to investigate. If the user said "latest" or didn't specify, default to the most recent faulted job and state this assumption explicitly. Do NOT fetch details for multiple jobs — investigate one at a time. **If the user gave no job key but described the job by state + folder** (e.g. "my pending job in Shared"), resolve it by enumeration: `uip or jobs list --folder-key <key> --state <State> --output json`. If exactly one candidate matches, proceed with it; if several, present them and ask. Do not ask the user for a key you can discover this way.
-5. **Queue item** — if the issue is queue-related, resolve the queue and item. Use `uip resource queues list --folder-key <key> --name <name>` to find the queue definition key. If the user provided a queue item key, use `uip resource queue-items get <item-key> --folder-key <key>` to confirm it exists and extract the queue name, error details, and retry status. If the queue item is not found in the first folder, try other folders from `folders list`.
+5. **Queue item** — if the issue is queue-related, resolve the queue and item. Use `uip or queues list --folder-key <key> --name <name>` to find the queue definition key. If the user provided a queue item key, use `uip or queue-items get <item-key> --folder-key <key>` to confirm it exists and extract the queue name, error details, and retry status. If the queue item is not found in the first folder, try other folders from `folders list`.
 
 ## Job Data Bundle
 
@@ -35,15 +35,15 @@ This is the baseline. Domain-specific data gathering builds on it — see the in
 
 For every queue item under investigation, gather these in order. Write each to `raw/` immediately.
 
-1. **Resolve queue** — `uip resource queues list --folder-key <key> --name <name>` — find the queue definition and its key
-2. **Queue item details** — `uip resource queue-items get <item-key> --folder-key <key>` — status, SpecificContent, processingException, retry count
-3. **Queue item history** — `uip resource queue-items get-history <item-key> --folder-key <key>` — state transitions with timestamps (New → InProgress → Failed/Retried)
-4. **Last retry** — `uip resource queue-items get-last-retry <item-key> --folder-key <key>` — details of the most recent retry attempt
+1. **Resolve queue** — `uip or queues list --folder-key <key> --name <name>` — find the queue definition and its key
+2. **Queue item details** — `uip or queue-items get <item-key> --folder-key <key>` — status, SpecificContent, processingException, retry count
+3. **Queue item history** — `uip or queue-items get-history <item-key> --folder-key <key>` — state transitions with timestamps (New → InProgress → Failed/Retried)
+4. **Last retry** — `uip or queue-items get-last-retry <item-key> --folder-key <key>` — details of the most recent retry attempt
 
 For comparison investigations (e.g., queue-items-failing playbook), also gather successful items:
 
-5. **List failed items** — `uip resource queue-items list --queue-definition-key <queue-key> --folder-key <key> --status Failed` — all failed items for comparison
-6. **List successful items** — `uip resource queue-items list --queue-definition-key <queue-key> --folder-key <key> --status Successful --limit 3` — sample of successful items to compare SpecificContent
+5. **List failed items** — `uip or queue-items list --queue-definition-key <queue-key> --folder-key <key> --status Failed` — all failed items for comparison
+6. **List successful items** — `uip or queue-items list --queue-definition-key <queue-key> --folder-key <key> --status Successful --limit 3` — sample of successful items to compare SpecificContent
 
 ## Finding Related Jobs
 

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/job-pending-no-host.md

@@ -17,12 +17,13 @@ What can cause it:
 - UiPath Assistant is connected to a different Orchestrator URL or tenant than the one where the job was triggered
 - UiPath Robot Service is stopped on the host machine
 - Network connectivity lost between host and Orchestrator
+- No host machine is installed on the assigned template at all — the user is on a different machine that is not part of the template's host list, or no host has ever connected to the template (this is the "not on the assigned machine" branch handled by Investigation step 6 and the corresponding Resolution branch below)
 
 What to look for:
 - Machine template assigned to the job and which hosts are registered to it
 - Connection status of hosts on that machine template (connected vs disconnected)
 
-**Discriminator vs [job-pending-stale-dispatch.md](./job-pending-stale-dispatch.md):** before concluding no-host, check `uip or machines list --all-fields` for the assigned template. If it currently has a connected runtime (`robotVersions` populated) AND credentials/mode are valid AND `JobHistory` contains only the original Pending entry, the host is actually present — the `PendingReasons.Errors` codes are a stale snapshot from the original dispatch attempt. Switch to that playbook; the remediation is to stop and re-trigger, not to provision a host. Two traps that look like no-host but are not: the PendingReasons phrase "…none connected to **this folder**" is the dispatch-time verdict, NOT current proof the template is unassigned (no `uip` command can verify folder→template assignment, so do not confirm that as a cause); and `Used.Unattended == Allowed` is NOT exhaustion when the consumed slot is the connected template's own idle runtime.
+**Discriminator vs [job-pending-stale-dispatch.md](./job-pending-stale-dispatch.md):** before concluding no-host, check `uip or machines list --all-fields` for the assigned template. If it currently has a connected runtime (`robotVersions` populated) AND credentials/mode are valid AND `JobHistory` contains only the original Pending entry, the host is actually present — the `PendingReasons.Errors` codes are a stale snapshot from the original dispatch attempt. Switch to that playbook; the remediation is to stop and re-trigger, not to provision a host. Two traps that look like no-host but are not: the PendingReasons phrase "…none connected to **this folder**" is the dispatch-time verdict, NOT current proof the template is unassigned (no `uip` command can verify folder→template assignment, so do not confirm that as a cause); and `Used.Unattended == Allowed` is NOT exhaustion when the consumed slot is the connected template's own idle runtime. **Also**: `Job.MachineKey` is empty for *every* Pending job (Orchestrator only populates it when a host accepts the job). MachineKey emptiness is NOT evidence of no-host — it is the normal Pending-state value for both no-host and stale-dispatch — verify host presence via `machines list` (`robotVersions`) instead.
 
 ## Investigation
 
@@ -35,6 +36,7 @@ What to look for:
 
 ## Resolution
 
+- **If no host is connected to the assigned template at all (`robotVersions` empty):** no machine is available to run the job. Connect/sign a robot into a machine on that template (Assistant in Service/Unattended mode, pointed at this Orchestrator URL + tenant), or assign a machine template that has a connected host to the folder. Re-triggering will NOT help while no host is connected — a fresh dispatch finds the same empty template and lands back in Pending.
 - **If on the assigned machine and Assistant is signed out:** sign in to the Assistant and connect to the Orchestrator URL
 - **If on the assigned machine and Assistant is connected to the wrong Orchestrator/tenant:** update the connection in Assistant preferences to point to the correct Orchestrator URL and tenant
 - **If on the assigned machine and Robot Service is stopped:** restart the UiPath Robot Service

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/job-pending-stale-dispatch.md

@@ -60,4 +60,6 @@ Do NOT attempt to "fix" the stale codes by reassigning the template, adding the
 
 Both playbooks can match in triage. Triage records both; the hypothesis tester resolves which one applies by checking the four "currently resolved" signals plus `JobHistory` shape. If all four are resolved AND `JobHistory` is unchanged, this playbook wins.
 
+> **Fields that look like discriminators but aren't.** `Job.MachineKey` is **empty for both** no-host and stale-dispatch on a stuck Pending job — Orchestrator only populates `MachineKey` after a host *accepts* the job, which by definition has not happened. Empty `MachineKey` is the normal Pending-state value and MUST NOT be used to eliminate stale-dispatch (or to confirm no-host). Use only the signals in the table above: `robotVersions` populated, credential/mode confirmed, license slot held by the idle runtime, and `JobHistory` shape.
+
 > Common misreads that wrongly eliminate this playbook: (1) reading `Used.Unattended == Allowed` as license exhaustion when the slot is held by the assigned template's own idle runtime; (2) reading "none connected to this folder" as a current folder-assignment gap. Both are addressed above — neither moves the verdict toward `job-pending-no-host` when a connected runtime is present.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/job-stopped-exit-code-0x40010004.md

@@ -0,0 +1,104 @@
+---
+confidence: medium
+---
+
+# Job Stopped — Unexpected Exit Code 0x40010004
+
+## Context
+
+Orchestrator records `System.Exception: Job stopped with an unexpected exit code: 0x40010004`. The executor (`UiPath.Executor.exe`) was killed via `TerminateProcess` — Windows reports `DBG_TERMINATE_PROCESS` (`0x40010004`). The workflow itself did not throw; the Robot service surfaces the missing graceful shutdown as a Faulted job.
+
+What this looks like:
+- Job state: Faulted (occasionally Stopped) with `Info` / error message exactly `System.Exception: Job stopped with an unexpected exit code: 0x40010004`
+- No workflow stack trace — origin is the Robot service supervising the executor, not user code
+- Execution logs cut off mid-activity; no `Job Completed` / `Execution ended` summary line
+- Correlates with an Orchestrator audit action (Stop/Kill), a Windows session event (logoff/disconnect), a service restart, or a host-level event (reboot, OOM, AV quarantine)
+
+What can cause it:
+- **Operator Kill from Orchestrator** — `--strategy Kill` (or "Stop" → "Kill" in UI) calls `TerminateProcess` and produces this exact code. `SoftStop` does not.
+- **Robot service restart** — `Restart-Service UiPath.Robot`, Robot auto-update, or installer upgrade terminated the executor mid-run
+- **RDP disconnected instead of signed out** — leaving an active RDP session in "Disconnected" state drops the user environment for unattended Robots; the executor goes with it. Always sign out (log off) on automation hosts; never "X" the RDP window. `LoginToConsole` in Orchestrator must match the host's actual login model.
+- **Session ended on the host** — user logged off, GPO idle-disconnect, fast user switching, or a Windows shutdown event invalidated the user session
+- **Robot session timeout exceeded** — `UIPATH_SESSION_TIMEOUT` (typically 60 seconds) elapsed during a long-running step. AI / ML inferences and other slow activities are the common offenders — the Robot considers the session stalled and kills the executor.
+- **Machine shutdown / restart / power loss** — host went down while executor was running
+- **Process killed externally on the host** — Task Manager, `Stop-Process`, parent process tree termination, AV/EDR quarantine of `UiPath.Executor.exe`
+- **Out-of-memory kill** — Windows or a job object terminated executor on memory pressure (Application event log has a Windows Error Reporting entry). AI / ML workloads spike memory hard when models load; an undersized VM running both the bot and the model is the common shape.
+- **Native crash in an activity** — non-managed crash (UI automation driver, OCR native lib, browser host) tore down executor; WER artifact on host, abrupt termination on Orchestrator
+- **Platform recycle** — cloud / serverless robot host was recycled, redeployed, or scaled in mid-run
+
+What to look for:
+- `uip or jobs history <key>` showing transition into `Stopping` or `Killing` before `Faulted` → operator stop/kill
+- Audit events mentioning the job key with action involving Stop/Kill → names the actor
+- Windows System log entries for `UiPath.Robot` service stop/start around `EndTime` → service restart
+- Security log Logoff (4634, 4647) or session disconnect (4779) for the executor's user/session → session ended
+- Application log Windows Error Reporting entry naming `UiPath.Executor.exe` → native crash or OOM
+- A new job started on the same Robot immediately after → retry/trigger preempted prior run
+
+## Investigation
+
+1. Confirm the exit code and capture timing. `uip or jobs get <job-key> --output json`. Record `State`, `StartTime`, `EndTime`, `Info`, `MachineName`, `HostMachineName`, `RobotName`. The error string must be exactly `System.Exception: Job stopped with an unexpected exit code: 0x40010004`. Other exit codes encode different causes — this playbook does not apply.
+2. Get state history. `uip or jobs history <job-key> --output json`. If transitions include `Running → Stopping → Faulted` or `Running → Killing → Faulted`, the job was stopped by Orchestrator — go to step 3. If transition is `Running → Faulted` with no Stopping/Killing state, the executor died on the host — go to step 4.
+3. Identify the actor. Query the audit service in a tight window around `EndTime`:
+   ```bash
+   uip admin audit tenant events \
+     --from-date <EndTime-2min ISO8601> \
+     --to-date <EndTime+1min ISO8601> \
+     --search "<job-key>" \
+     --output json
+   ```
+   The matching event's `actorName` / `actorEmail` / `eventSummary` names the user, robot account, or system trigger that issued the stop. Empty result → kill did not originate in Orchestrator; move to step 4.
+4. Inspect the host. Resolve `HostMachineName` from step 1. On that host:
+   - **Robot execution log** — `%LocalAppData%\UiPath\Logs\Execution.log` for the job's user. Find the last activity logged before the abrupt end (no `Job Completed` / `Execution ended` line). Note the last activity — it is the closest signal to a crashing component if step 4b confirms a native crash.
+   - **Application event log** — Windows Error Reporting / .NET Runtime entries near `EndTime`:
+     ```powershell
+     Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=<EndTime-5min>; EndTime=<EndTime+1min>} |
+       Where-Object { $_.ProviderName -in 'Windows Error Reporting','Application Error','.NET Runtime' -or $_.Message -match 'UiPath\.Executor' }
+     ```
+     A WER entry naming `UiPath.Executor.exe` confirms native crash or OOM. The faulting module in the entry points at the culprit (e.g., `chrome.dll`, `tessocr.dll`, `clr.dll`).
+   - **System event log** — Robot service activity:
+     ```powershell
+     Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=<EndTime-5min>; EndTime=<EndTime+1min>; ProviderName='Service Control Manager'} |
+       Where-Object { $_.Message -match 'UiPath' }
+     ```
+     `UiPath.Robot` stop/start in this window → service restart killed the executor.
+   - **Security event log** — session events for the executor's user:
+     ```powershell
+     Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4634,4647,4779; StartTime=<EndTime-5min>; EndTime=<EndTime+1min>}
+     ```
+     Logoff (4634/4647) or session disconnect (4779) on the executor's session in this window is the cause.
+   - **AV/EDR quarantine** — vendor-specific. Check Defender via `Get-MpThreatDetection | Where-Object { $_.Resources -match 'UiPath' }`.
+5. Check for session-timeout kills on long-running steps. If `EndTime - StartTime` of the **last logged activity** approaches `UIPATH_SESSION_TIMEOUT` (typically 60 seconds) — frequently the case for AI/ML inferences, model loads, long HTTP waits, or batch OCR — the Robot likely killed the executor for an unresponsive session. Confirm:
+   - Check the environment variable on the host: `[Environment]::GetEnvironmentVariable('UIPATH_SESSION_TIMEOUT','Machine')` (and `User` scope). If unset, the Robot default applies.
+   - In `Execution.log`, the abrupt end follows a single long-running activity with no intermediate log lines.
+6. If host evidence is unavailable (cloud robot, serverless, host already recycled):
+   - `uip or machines list --output json` — confirm the host is still healthy; redeploys and pool scaling recycle executors mid-run.
+   - `uip or jobs list --folder-key <key> --process-name <name> --created-after <EndTime-5min> --output json` — a new job created within seconds of `EndTime` indicates a retry policy or trigger fired immediately. Verify whether retry was triggered by the platform (transient infra) vs. configured retry policy.
+7. Cross-check related patterns. If the same host repeatedly produces `0x40010004` followed by an orphan `UiPath.Executor.exe`, see [foreground-already-running.md](./foreground-already-running.md) — session-stability is the upstream issue.
+
+The root cause is **who terminated the process and why** — not the exit code. A confirmed finding must name the actor (Orchestrator user, trigger, service restart, session logoff, OOM, native crash, platform recycle) and the evidence backing it.
+
+## Resolution
+
+- **Operator-initiated Kill (audit names the actor):** confirm intent. If unintended, restrict who holds `Jobs.Edit` on the folder (Orchestrator → Roles). Train operators to use `SoftStop` first (`uip or jobs stop <key> --strategy SoftStop`) so the workflow can exit gracefully; reserve `Kill` for genuinely stuck jobs.
+- **Robot service restart (System log shows `UiPath.Robot` stop/start):** if Robot auto-update caused it, schedule updates outside production windows (Orchestrator → Machines → Updates) or pin a Robot version. If an admin restarted the service, coordinate maintenance windows around running jobs.
+- **Session logoff / RDP disconnect (Security log 4634/4647/4779):** for unattended runs, enable "Login to Console" on the Robot so it owns its own session — and confirm `LoginToConsole` in Orchestrator matches the host's actual login model (console vs. RDP). The inverted rule from typical interactive guidance: on automation hosts, **sign out, do not disconnect** — a "Disconnected" RDP session drops the user environment and kills any running executor with `0x40010004`. Disable idle-disconnect GPOs on the automation account. Also see related sessions in [foreground-already-running.md](./foreground-already-running.md).
+- **Robot session timeout exceeded (last activity approached `UIPATH_SESSION_TIMEOUT`):** raise the timeout for the host that runs slow steps — `setx UIPATH_SESSION_TIMEOUT <seconds> /M` (Machine scope), then restart the Robot service. For AI / ML inferences, size the timeout above the worst-case inference time plus model-load. As a workflow-level fix, split the long step into smaller activities (yields heartbeat log lines that reset the timeout) or move the heavy step to a dedicated process / Maestro stage with its own retry policy.
+- **Machine shutdown / restart:** correlate with infrastructure change windows. Move automation hosts off generic patch/reboot rings; set Windows Update Active Hours or maintenance groups. For cloud VMs, exclude automation hosts from scheduled recycle policies.
+- **AV/EDR quarantine (vendor detection naming `UiPath.Executor.exe`):** allowlist `UiPath.Executor.exe`, `UiRobot.exe`, the project's `bin` directory, and `%LocalAppData%\UiPath`. Capture the quarantine record as evidence before re-running.
+- **OOM kill (WER entry with memory pressure or working-set exceeded):** profile the workflow for large in-memory data (DataTables, byte arrays, screenshots); stream rather than buffer. Raise page file or move to a machine template with more RAM. For coded workflows, check for large-object-heap pressure and GC pinning. **AI / ML workloads:** size the host to fit the bot **plus** the model in memory simultaneously, with headroom for inference batches. Lazy-load models, dispose them when idle, and pin model serving to a separate process if a single VM cannot satisfy both.
+- **Native crash (WER entry naming a non-UiPath module — `chrome.dll`, `IEFRAME.dll`, `tessocr.dll`, etc.):** isolate the activity logged immediately before the abrupt end. Update the related activity package; if reproducible, capture a `.dmp` via WER and file a support ticket. The workflow cannot recover from a native crash inside the executor.
+- **Platform recycle (cloud / serverless robot, no host evidence available):** enable retry on transient infra failures (Orchestrator → Process → Retry Settings). For long-running workflows, checkpoint state (queue items, storage buckets, Maestro persistence) so re-runs resume rather than restart.
+- **External `Stop-Process` / Task Manager kill on host:** treat as Orchestrator Kill — intentional but uncontrolled. Tighten host access (restrict RDP into automation hosts; remove Administrator rights from operators).
+
+Prevention:
+- Default to `SoftStop` in operator runbooks; reserve `Kill` for stuck jobs.
+- Keep automation hosts out of generic patch/reboot rings; schedule maintenance windows around job activity.
+- Allowlist UiPath executables and folders in AV/EDR.
+- On automation hosts: sign out, do not disconnect. Disable idle-disconnect GPOs on the automation account. Confirm `LoginToConsole` matches the host's login model.
+- Size `UIPATH_SESSION_TIMEOUT` against the slowest expected step (especially AI / ML inferences); size host RAM against the bot **plus** the model.
+- Isolate risky steps (native automation, OCR, browser hosts, AI inference) into child workflows / Invoke Process so the parent can detect abrupt exit and react.
+- For high-value long runs, add checkpointing so a `0x40010004` failure does not lose all work.
+
+## Reference
+
+- UiPath Docs — Execution Troubleshooting and Robot session configuration. Use the latest version on the UiPath documentation portal; do not rely on links cached here.

package/skills/uipath-troubleshoot/references/products/orchestrator/summary.md

@@ -11,3 +11,4 @@
 | Job Pending — No Available Host | High | Job stuck in Pending with "No host is available on the machine template" error AND template has zero connected runtimes | [job-pending-no-host.md](./playbooks/job-pending-no-host.md) |
 | Job Pending — Stale Dispatch-Time PendingReasons | High | Job stuck in Pending with no-host-family `PendingReasons.Errors` BUT a runtime IS connected, credentials/mode/license are valid, and `JobHistory` has only the original entry — Orchestrator never re-evaluated. Fix: stop + re-trigger | [job-pending-stale-dispatch.md](./playbooks/job-pending-stale-dispatch.md) |
 | Foreground Process Already Running | Medium | `InvalidOperationException: A foreground process is already running. Only one foreground process can run at a time.` — Robot rejects concurrent foreground jobs on the same session | [foreground-already-running.md](./playbooks/foreground-already-running.md) |
+| Job Stopped — Exit Code 0x40010004 | Medium | `System.Exception: Job stopped with an unexpected exit code: 0x40010004` — executor was killed via `TerminateProcess` (operator Kill, service restart, session logoff, OOM, native crash, or platform recycle) | [job-stopped-exit-code-0x40010004.md](./playbooks/job-stopped-exit-code-0x40010004.md) |

package/skills/uipath-troubleshoot/references/summary.md

@@ -6,7 +6,7 @@ Start here. Find the product or package that matches the user's issue, then foll
 
 Manages automation resources, robots, processes, and execution. Handles job scheduling, queue management, asset storage, triggers, storage buckets, and folder-based access control. Issues here involve failed jobs, stuck jobs, queue item failures, trigger problems, robot connectivity, permissions, and platform availability.
 
-CLI: `uip or --help`, `uip resource --help`
+CLI: `uip or --help`
 
 - [products/orchestrator/overview.md](./products/orchestrator/overview.md) — Product overview, features, and dependencies
 - [products/orchestrator/summary.md](./products/orchestrator/summary.md) — All playbooks for Orchestrator issues
@@ -71,6 +71,15 @@ Namespaces: `UiPath.Core.Activities`
 - [activity-packages/system-activities/overview.md](./activity-packages/system-activities/overview.md) — Package overview, activity types, and common failure patterns
 - [activity-packages/system-activities/summary.md](./activity-packages/system-activities/summary.md) — All playbooks for System Activities issues
 
+## Classic Activities
+
+The classic (non-"modern"/non-"Next") activities under `UiPath.Core.Activities`. Two groups: classic UI Automation — `Click`, `Type Into`, `Send Hotkey`, `Open Browser`, `Close Tab`, `Open Application`, `Attach Browser`/`Window`, `Take Screenshot`, `Wait Image Vanish`, `Wait UI Element Appear` (selector/image based, `SelectorNotFoundException` / `ActivityTimeoutException` / `ElementOperationException` / `BrowserOperationException`); and System/Core — `Invoke Workflow File`, `Invoke Code`, `Add Queue Item`, `Rename File`, `Move File`, `Append Line`, `Log Message`, `Kill Process`, `Start Triggers`, `For Each Row` (file/process/code/queue/workflow failures). Use this package when the faulted activity is one of the classic types above. For the modern UI "Next" activities (`NClick`, `Use Application/Browser`, Healing Agent) use **UI Automation**; for `Get Asset`/`Get Credential`/`Get Robot Asset` use **System Activities**.
+
+Namespaces: `UiPath.Core.Activities`, `UiPath.UIAutomation.Activities`, `UiPath.System.Activities`
+
+- [activity-packages/classic-activities/overview.md](./activity-packages/classic-activities/overview.md) — Package overview, classic activity groups, and failure families
+- [activity-packages/classic-activities/summary.md](./activity-packages/classic-activities/summary.md) — All playbooks for classic activity issues
+
 ## Google Workspace Activities
 
 Activities for interacting with Google Workspace including Google Calendar, Google Drive, Google Sheets, Gmail, Google Docs, Google Tasks, and Google Forms. Issues here involve files not found, sheet name conflicts, multiple items name conflicts, emails not found, sheet cell limit exceeded, sheets invalid ranges, upload storage quota exceeded.

package/version-manifest.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 1,
-  "skillsVersion": "1.195.1",
-  "targetCli": "^1.195.0"
+  "skillsVersion": "1.196.0",
+  "targetCli": "^1.196.0"
 }

package/skills/uipath-ixp/SKILL.md

@@ -1,84 +0,0 @@
----
-name: uipath-ixp
-description: "[PREVIEW] UiPath IXP (Document Understanding) — review IXP predictions with Claude, confirm valid fields, improve prompts, publish models."
----
-
-# UiPath IXP Document Extraction Assistant
-
-Skill for working with UiPath IXP (Intelligent eXtraction Platform) projects — creating projects, uploading documents, reviewing predictions, and improving extraction quality.
-
-## When to Use This Skill
-
-- User asks to create an IXP project, upload documents, or train a document extraction model
-- User asks to label, review, or confirm document predictions
-- User asks to improve extraction scores, prompts, or field instructions
-- User asks to publish or manage IXP model versions
-- User provides a taxonomy file to import into a project
-- User asks for the project taxonomy at a specific trained model version — what the schema looked like when version N was published (use `deployments get-taxonomy <project-name> --version <N>`)
-
-## Critical Rules
-
-1. **ONLY use `uip ixp` CLI commands as documented in this skill** — do NOT use curl, do NOT call REST APIs directly, do NOT grep/read source code, do NOT explore the codebase.
-2. **Run workflows end-to-end automatically** — do NOT ask the user to do individual steps.
-3. **Always use `--output json`** when parsing CLI output programmatically.
-4. **Use `/tmp/ixp/<project-name>/` as the working directory with this structure:**
-   ```
-   /tmp/ixp/<project-name>/
-   ├── docs/         # Document files (<document-id>.pdf, .png, …) — downloaded once, reused across sessions
-   ├── taxonomies/   # Taxonomy snapshots (v1.json, v2.json, …) — new version after each update-prompts
-   └── prompts/      # Instruction update payloads (field_updates.json, group_updates.json, …)
-   ```
-   At the start of any workflow: `mkdir -p /tmp/ixp/<project-name>/{docs,taxonomies,prompts}`. If the directory already exists from a previous session, **reuse existing files** — do not re-download documents that are already present. Do NOT use the Write tool for `/tmp/ixp/` paths — on Windows it resolves to a different location than bash.
-5. **Use heredocs for `--updates`** — for `fields update-prompts --updates` and `groups update-prompts --updates`, use heredocs (`cat > /tmp/ixp/<project-name>/prompts/field_updates.json << 'EOF' ... EOF`) then `"$(cat /tmp/ixp/<project-name>/prompts/field_updates.json)"`.
-6. **Never use `UID` as a variable name** — it is a readonly shell variable. Use `DOC_ID`, `DOCUMENT_ID`, etc.
-7. **Always use the project `Name`, never the `Title`** — the `project list` output has both `Name` (e.g., `my_invoices-f1afa9ef-ixp`) and `Title` (e.g., `My_Invoices`). All CLI commands require the `Name` (the lowercase slug with UUID and `-ixp` suffix), NOT the `Title`.
-8. **Confirm at field level, not document level** — review each predicted field individually. Confirm only the fields that are correct using `labelling confirm --fields`. Fields with wrong predictions are left unannotated. **`--corrections` is ONLY for OCR-mangled values** — the prediction found the right field in the right location and the bytes-on-page are right, but the text was garbled (e.g., `MSIÓÓÓ601020/` → `MSI0601020`). Do NOT use `--corrections` to flip a wrong boolean, fix a wrong inferred/computed value, or change any value where the prediction itself was the wrong answer — those are NOT CONFIRMED. Overriding a non-OCR prediction is manual extraction (forbidden by rule 11).
-9. **Do NOT manually extract values** — all labelling goes through `labelling confirm` with predictions from IXP.
-10. **Max 8 documents for taxonomy suggestion** — the suggest-taxonomy endpoint accepts at most 8 attachment references.
-11. **Claude is the reviewer, not the extractor** — IXP generates predictions, Claude validates them. For each document, review predicted field values against the document file (Read tool handles PDF, PNG, JPG, etc.). Confirm correct fields (`labelling confirm --fields`), correct OCR-mangled values (`--corrections`), and skip wrong fields. Do NOT manually extract values. If a field's F1 is low, improve the **prompt** so IXP predicts better values.
-12. **Confirm a field as missing by listing it in `confirm --fields`, only when IXP also predicted nothing** — `labellings confirm --fields f1,f2,f3` treats every listed field uniformly: if IXP predicted a value, it's confirmed; if IXP predicted nothing for a listed field, a missing marker is written. The explicit listing IS the confirmation that the empty state is intentional. Only include a field in `--fields` for the missing case when IXP itself predicted no value (or an empty value) AND the field is genuinely absent from the document. If IXP predicted a wrong value, leave the field NOT CONFIRMED (omit it from `--fields`) — choosing "missing" yourself is the same kind of extractor decision rule 11 forbids. Use `labellings mark-missing` only as a fallback when `confirm --fields` is a no-op for a field you expected it to handle — this happens when the field has a prior annotation but doesn't appear in the current `get-predictions` output for that document (e.g., model behavior or the taxonomy changed between iterations). In that case, `mark-missing` reaches the stale annotation and overwrites it with a missing marker; `confirm` can't.
-
-## Quick Start
-
-1. Run `uip ixp projects list --output json` to see existing projects
-2. To create a new project: follow [Project Setup Guide](references/project-setup-guide.md)
-3. To improve an existing project: follow [Improve Prompts Guide](references/improve-prompts-guide.md)
-4. To label documents on an existing project: follow [Label Documents Guide](references/label-documents-guide.md)
-
-If the user provides a taxonomy file, use `--skip-taxonomy` and `import-taxonomy` (Option B in the Project Setup guide).
-
-## Task Navigation
-
-| User request | Action |
-|-------------|--------|
-| "Create an IXP project" / "Upload documents to a new project" | [Project Setup Guide](references/project-setup-guide.md) — **new** projects only (uploads + taxonomy in one call). For **existing** projects, see the "Upload a document" row below. |
-| "Import this taxonomy" / provides a taxonomy file | [Project Setup Guide](references/project-setup-guide.md) — Option B (`--skip-taxonomy` + `import-taxonomy`) |
-| "Label documents" / "Review predictions" | [Label Documents Guide](references/label-documents-guide.md) |
-| "Improve scores" / "Fix prompts" / "Improve F1" | [Improve Prompts Guide](references/improve-prompts-guide.md) |
-| "Publish the model" / "Tag as live" | `uip ixp projects publish <project-name> --output json` |
-| "Show metrics" / "What are the scores?" | `uip ixp projects get-metrics <project-name> --output json` |
-| "List projects" | `uip ixp projects list --output json` |
-| "Configure the model" | `uip ixp projects configure-model <project-name> [options] --output json` |
-| "Upload a document" / "Add documents to an existing project" | `uip ixp documents upload <project-name> <file> --output json` — see [CLI Reference § Uploading documents](references/cli-reference.md#uploading-documents-to-an-existing-project). One file per call; loop for multiple. For brand-new projects use `projects create` instead. |
-| "Delete a document" / "Remove a document" | `uip ixp documents delete <project-name> <document-id> --output json` — irreversible, triggers retrain. To delete by filename, look up the `DocumentId` via `documents list` (the `Filename` column shows the original upload name). |
-| "Add / delete / rename a field group" | `uip ixp groups {add,delete,rename} <project-name> --name <name> ... --output json` — see [CLI Reference § Groups](references/cli-reference.md#groups). `groups add` requires `--instructions` and `--fields '<json>'` with at least one field. `delete` requires `--confirm-data-loss`. |
-| "Add / edit / rename / delete a data type" | `uip ixp data-types {add,update-instructions,rename,delete} <project-name> --name <name> ... --output json` — see [CLI Reference § Data Types](references/cli-reference.md#data-types). `add` requires `--kind` (text/date/money/number/boolean/choice) and `--instructions`. `--input-value` (exact-match/inferred) is required only for `--kind text` and `--kind choice`; the other kinds don't have this property and the CLI rejects the flag for them. `delete` requires `--confirm-data-loss` because referencing fields break. |
-| "Add / delete / rename / retype a field" | `uip ixp fields {add,delete,rename,change-type} <project-name> --group <name> --field <name> ... --output json` — see [CLI Reference § Fields](references/cli-reference.md#fields). `change-type` deletes annotations and requires `--confirm-data-loss`. |
-| "Mark a field as missing for a document" | Include the field's id in `uip ixp labellings confirm <project-name> <document-id> --fields <ids> --output json` alongside any content fields you're confirming. When IXP's prediction for that field is empty, the explicit listing writes a missing marker; when it has content, the content is confirmed. **Only list a field for the missing case if IXP also predicted nothing for it.** See Critical Rule 12. Use `labellings mark-missing` only as a fallback when `confirm --fields` is a no-op for a field you expected it to handle — typically a field with a prior annotation that the current prediction no longer includes (model or taxonomy changed between iterations). |
-| "Undo / unconfirm a wrong confirmation" | `uip ixp labellings unconfirm <project-name> <document-id> --fields <ids> --output json` — rolls back an earlier `confirm` or `mark-missing` for the listed fields. Every other annotation on the document is carried forward. |
-| "Set overall extraction instructions" / "Update project prompt" | `uip ixp projects update-prompt <project-name> --prompt "<text>" --output json` — replaces the taxonomy-wide prompt (the "Overall extraction instructions" field in the IXP UI). Distinct from `fields update-prompts` (per-field) and `groups update-prompts` (per-field-group). |
-
-## Common Pitfalls
-
-| Symptom | Cause | Fix |
-|---------|-------|-----|
-| Metrics don't change after a prompt update | Re-evaluation hasn't completed | Wait ~2 minutes for retrain. |
-| ModelVersion doesn't advance | Retrain still in progress | Any change to model inputs (labellings OR instructions) triggers a full retrain. Wait ~2 min then retry. |
-| Field instructions conflict with label_def instructions | `fields update-prompts` only edits per-field instructions, NOT the parent label_def instructions | Before iterating, read the label_def `instructions` and update them with `groups update-prompts` if they contradict the per-field prompts. |
-
-## Reference Navigation
-
-- [CLI Commands Reference](references/cli-reference.md) — all `uip ixp` commands with options and output formats
-- [Project Setup Guide](references/project-setup-guide.md) — create a new project, review and label documents
-- [Improve Prompts Guide](references/improve-prompts-guide.md) — iterative optimization loop with regression detection
-- [Label Documents Guide](references/label-documents-guide.md) — reusable workflow for reviewing and confirming predictions