@uipath/skills 1.197.0 → 1.197.2

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/trigger-execution-failed.md

@@ -0,0 +1,47 @@
+---
+confidence: medium
+---
+
+# Trigger Execution Failed (DAP-RT-1050 / DAP-RT-1051 / DAP-RT-1052 / DAP-RT-1053)
+
+> **Fault bucket: mixed — classify per code.** `1051`/`1050` → **🛠 B2** (connector trigger endpoint / malformed provider payload — provider-side, wait/escalate). `1053` → **🛠 B1** (object name / operation null or empty — handled by connector configuration, the customer cannot fix it → escalate). `1052` is **debug-only and never appears in runtime telemetry** — out of scope for runtime triage. Lead with the bucket that matches the emitted code. See [dap-error-codes-reference.md](../dap-error-codes-reference.md#fault-ownership--the-two-bucket-decision).
+
+## Context
+
+What this looks like — trigger (polling/webhook) runtime codes:
+
+| Code | Name | Specific cause | Bucket |
+|---|---|---|:---:|
+| `DAP-RT-1051` | TriggerExecutionFailed | Trigger evaluation call failed or returned empty — connector trigger endpoint issue | 🛠 B2 |
+| `DAP-RT-1050` | TriggerDataMissing | Event payload missing the expected event ID — malformed webhook/poll payload | 🛠 B2 |
+| `DAP-RT-1053` | TriggerInvalidConfiguration | Trigger object name or operation is null/empty — set by connector configuration, not customer-settable | 🛠 B1 |
+| `DAP-RT-1052` | TriggerNoMatches | Zero events matched — **debug-mode-only signal; never emitted in runtime telemetry** | — |
+
+What can cause it (cause IDs map to Resolution steps below):
+- **CA001** — Connection used by the trigger is inactive or expired (`1051`)
+- **CA002** — Connector trigger endpoint changed, errored, or returned an unexpected shape (`1051`)
+- **CA003** — Webhook/poll payload from the provider is malformed or missing the event ID (`1050`)
+- **CA004** — Connector configuration produced a null/empty trigger object name or operation — a connector-metadata defect, not a user-settable field (`1053`)
+
+What to look for:
+- `ConnectionId` and `RequestId` in the customEvent
+- For `1053`: no provider status — the null/empty object/operation originates in connector configuration, before the provider call
+- Whether the trigger subscription still exists in the external service
+
+> The Maestro/Orchestrator-surfaced view (subscription missing, robot lacks Triggers permission, debug-vs-deploy bindings) is [trigger-not-firing.md](./trigger-not-firing.md). Use it for "events occur but no job/instance starts"; use this playbook when a `DAP-RT-105x` code is emitted during trigger evaluation.
+
+## Investigation
+
+1. **Classify the code first.** `1052` (NoMatches) is a debug-mode-only signal — it will not appear in runtime execution telemetry, so it is not a runtime fault to investigate. For `1053`, the fault is in connector configuration (null/empty object name or operation), not a user-settable field — route to escalation, not workflow edits.
+2. **Read the connection resource file** — identify the connector and connection (see "Connection Resource File" in [overview.md](../overview.md)).
+3. `uip is connections ping <connection-id>` — verify the trigger's connection is active (primary cause of `1051`).
+4. `uip is triggers objects <connector-key> <operation>` / `uip is triggers describe ...` — verify the trigger object type and expected payload schema.
+5. For `1050`: inspect the provider payload (from logs/`RequestId`) for the missing event ID — a provider-side or subscription-config problem.
+
+## Resolution
+
+- **`CA001` — `DAP-RT-1051`, connection inactive:** re-authenticate via `uip is connections edit <connection-id>` (see [connection-auth-expired.md](./connection-auth-expired.md) for auth-expiry).
+- **`CA002` — `DAP-RT-1051`, endpoint issue:** verify the trigger object/operation is still supported by the connector; reconfigure if the connector changed.
+- **`CA003` — `DAP-RT-1050`:** verify the subscription in the external service emits the expected event shape; recreate the trigger subscription if the payload contract drifted.
+- **`CA004` — `DAP-RT-1053` (escalate — not customer-fixable):** the trigger object name or operation is null/empty, set by connector configuration. The customer cannot fix this from their workflow. Escalate to the Integration Service owner team with the `DAP-RT-1053` code, `RequestId`, and connector key.
+- **`DAP-RT-1052`:** debug-mode-only signal — never emitted in runtime telemetry. If seen during a debug run, it just means the trigger filter matched zero events; it is not a runtime fault and needs no action.

package/skills/uipath-troubleshoot/references/products/integration-service/summary.md

@@ -2,6 +2,49 @@
 
 **Investigation guide:** [investigation_guide.md](./investigation_guide.md) — data correlation rules and testing prerequisites for Integration Service investigations
 
+**DAP runtime error codes:** [dap-error-codes-reference.md](./dap-error-codes-reference.md) — `DAP-<LAYER>-<CODE>` catalog, telemetry customEvent fields, the two-bucket fault-ownership decision, retry semantics, and code → playbook map. **Start here when the error carries a `DAP-…` code.**
+
+**CNS (Connection Service) error codes:** [cns-error-codes-reference.md](./cns-error-codes-reference.md) — `CNS<code>` catalog for the Connection Service HTTP API (connections/connectors/triggers CRUD, portal UI, Maestro and runtime service calls), wire format (`{code, message, traceId}`), telemetry dimensions, overloaded-code traps, retry semantics, and code → playbook map. **Start here when the error carries a `CNS…` code** — when both a DAP and a CNS code are present, the CNS code is the more specific signal.
+
+## Fault ownership — classify before routing
+
+Lead every DAP runtime answer with the bucket. The code → bucket tables are the primary classifier; "service error" is your judgment (there is no `IsServiceError` field), derived from whether a provider status is present. Decision rule: no provider status returned (IS-side exception) → take the code's bucket (**B1** for platform/connector defects, **A** for connection/input customer-config codes); a provider status returned (`ProviderErrorCode` present, e.g. `DAP-RT-1101`) → 4xx auth/input → **Bucket A** (customer fixes it); `429`/`5xx` → **Bucket B2** (provider-side, wait/escalate). Full rule in [dap-error-codes-reference.md](./dap-error-codes-reference.md#fault-ownership--the-two-bucket-decision).
+
+## By DAP runtime error code
+
+Keyed on the IS-native `DAP-RT`/`DAP-GE` code emitted in execution telemetry (and `ProviderErrorCode` for `DAP-RT-1101`). **Bucket** column: 👤 A = customer-resolvable · 🛠 B1 = IS platform/connector defect (escalate) · 🛠 B2 = provider outage (wait/escalate).
+
+| Codes | Bucket | Confidence | Description | Playbook |
+|-------|:---:|:---:|-------------|----------|
+| `DAP-RT-1101` | 👤 A / 🛠 B2 | High | RequestFailed — route by `ProviderErrorCode`: 4xx auth/input → A; 429/5xx → B2 | [request-failed.md](./playbooks/request-failed.md) |
+| `DAP-GE-3004` | 🛠 B1 | High | FailedToGetAccessToken — IS could not get a **first-party UiPath service** token (Orchestrator, Feature Flag service), NOT a connection credential; retry, escalate if sustained | [token-refresh-failed.md](./playbooks/token-refresh-failed.md) |
+| `DAP-GE-3000` `DAP-GE-3005` `DAP-RT-1002` | 👤 A | High | Connection not resolved — deleted/cross-workspace, disabled, or no connection bound | [connection-not-resolved.md](./playbooks/connection-not-resolved.md) |
+| `DAP-RT-1003` `DAP-RT-1007` | 👤 A | High | Missing required input argument or property | [missing-required-input.md](./playbooks/missing-required-input.md) |
+| `DAP-RT-1103` | 🛠 B2 | High | HttpClientException — network-level failure, target host unreachable (DNS/firewall/TLS) | [http-client-exception.md](./playbooks/http-client-exception.md) |
+| `DAP-RT-1050` `DAP-RT-1051` `DAP-RT-1053` | 🛠 B2 / 🛠 B1 | Medium | Trigger eval failed or payload missing → B2; `1053` null/empty object/operation (connector config) → B1 escalate. (`DAP-RT-1052` is debug-only — never at runtime) | [trigger-execution-failed.md](./playbooks/trigger-execution-failed.md) |
+| `DAP-RT-1005` `DAP-RT-1155` `DAP-RT-1156` | 🛠 B1 | Medium | Response could not be mapped to the activity output type — connector schema drift | [response-mapping-mismatch.md](./playbooks/response-mapping-mismatch.md) |
+| `DAP-RT-1000` `DAP-RT-1001` `DAP-RT-1004` `DAP-RT-1008` `DAP-RT-1100` `DAP-GE-3001` | 🛠 B1 | Medium | Activity config null/malformed/unversioned or failed migration — corrupt config blob | [activity-configuration-corrupt.md](./playbooks/activity-configuration-corrupt.md) |
+
+## By CNS (Connection Service) error code
+
+Keyed on the `code` field of the Connection Service API error body (`{ "code": "CNS…", "message": "…", "traceId": "…" }`). ⚠ Several codes are overloaded across subsystems (`CNS1025`, `CNS1001`, `CNS1050`, `CNS1048`/`CNS1026`) — read the message and failing operation before routing; full trap list in [cns-error-codes-reference.md](./cns-error-codes-reference.md).
+
+| Codes | Bucket | Confidence | Description | Playbook |
+|-------|:---:|:---:|-------------|----------|
+| `CNS1006` `CNS1000` `CNS1049` `CNS1003` | 👤 A | High | Connection not found from the caller's context — deleted, cross-workspace, no connections for connector, stale auth session | [cs-connection-not-found.md](./playbooks/cs-connection-not-found.md) |
+| `CNS1008` `CNS1021` `CNS1061` | 👤 A | High | Connection not in authorized state — expired/revoked token, unauthenticated shell, wrong auth type; re-authenticate | [cs-connection-not-authenticated.md](./playbooks/cs-connection-not-authenticated.md) |
+| `CNS1045` `CNS1044` `CNS1046` `CNS1047` `CNS1043` `CNS3001` | 👤 A | High | Permission/authorization denied — folder permission (`Connections.View`), OAuth scope, client allow-list, Automation Ops policy | [cs-permission-denied.md](./playbooks/cs-permission-denied.md) |
+| `CNS1001` `CNS1002` `CNS1004` → A · `CNS1075` `CNS2045` → B1 | 👤 A / 🛠 B1 | High | Connector unavailable — wrong/missing/disabled connector reference (A); connector deployment/catalog drift (B1, `CNS1075` is a deliberate non-retryable 409) | [cs-connector-unavailable.md](./playbooks/cs-connector-unavailable.md) |
+| `CNS1020` `CNS1014` `CNS1025` `CNS1039` → A · `CNS2004` → B1 | 👤 A / 🛠 B1 | High | Trigger CRUD failed — bad ID, delete blocked by active processes, malformed/S2S request (A); persisted config undeserializable (B1) | [cs-trigger-operation-failed.md](./playbooks/cs-trigger-operation-failed.md) |
+| `CNS1005` `CNS2000` `CNS1015`–`CNS1019` `CNS1024` `CNS1029` `CNS2011` | 🛠 B1 | Medium | Inbound event-callback processing failed (machine-to-machine) — customer symptom is a trigger that doesn't fire; `CNS1005` has a large benign baseline | [cs-events-callback-failed.md](./playbooks/cs-events-callback-failed.md) |
+| `CNS2003` `CNS2005` `CNS2006` `CNS2007` `CNS2009` `CNS2010` `CNS2012` `CNS2001` `CNS2008` `CNS1036` → B1 · `CNS1042` `CNS1101` → B2 | 🛠 B1 / 🛠 B2 | High | Internal dependency failed (SQL/Orchestrator/Identity/message bus → B1) or the third-party provider is erroring/rate-limiting (B2) — retry, then escalate | [cs-dependency-unavailable.md](./playbooks/cs-dependency-unavailable.md) |
+| `CNS3002` `CNS1007` `CNS1038` | 🔧 / 👤 A | High | Conflict/duplicate — in-progress migration/backfill lock (ops), duplicate-key create race, duplicate name | [cs-operation-conflict.md](./playbooks/cs-operation-conflict.md) |
+| `CNS1050` `CNS1055`–`CNS1074` (Solutions subset) | 👤 A / 🛠 B1 | Medium | Solutions package install/validation — spec errors, connector-version reconciliation, shell connections, stuck publish | [cs-solutions-install-failed.md](./playbooks/cs-solutions-install-failed.md) |
+
+## By symptom (Maestro/Orchestrator-surfaced)
+
+Keyed on the Maestro IntSvc code (`102002`…) or the user-facing message. Same underlying failures from the Maestro/Orchestrator surface.
+
 | Issue | Confidence | Description | Playbook |
 |-------|:---:|-------------|----------|
 | Connection Invalid or No Access | High | "connection is invalid or you do not have access" — connection missing, disabled, or caller lacks permissions | [connection-invalid.md](./playbooks/connection-invalid.md) |

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

@@ -43,12 +43,12 @@ After the Orchestrator job data bundle (job details, logs, history) is collected
 1. **Determine runtime type** — check the job's `RuntimeType` or `Source` field. If it's a ProcessOrchestration job (Maestro), gather Maestro-specific data below. Standard Orchestrator jobs don't need these steps.
 2. **Determine the Maestro process type** — `bpmn`, `flow`, or `case`. Every Maestro CLI invocation requires this segment (`uip maestro bpmn ...`, `uip maestro flow ...`, `uip maestro case ...`). Identify the type from the source artifact (`.bpmn`, `.flow`, Case JSON), the `processType` field on the instance/incident, or by asking the user. Examples below use `<type>` as a placeholder — substitute the actual type.
 3. **Resolve the Maestro instance ID** — for ProcessOrchestration jobs, the **Orchestrator job key IS the Maestro instance ID**. They are the same GUID. Do NOT use `ParentJobKey` — that is the parent Orchestrator job, not the Maestro instance.
-   - **User provided a job key and `RuntimeType` is `ProcessOrchestration`**: the job key is the instance ID. Go directly to `uip maestro <type> instance get <job-key> -f <folder-key>`.
-   - **User provided a job key and `RuntimeType` is NOT `ProcessOrchestration`** (standard child job): the child job was spawned by a Maestro service task. Check `ParentJobKey` — that parent job's key may be the instance ID. Try `uip maestro <type> instance get <parent-job-key> -f <folder-key>`.
+   - **User provided a job key and `RuntimeType` is `ProcessOrchestration`**: the job key is the instance ID. Go directly to `uip maestro <type> instance get <job-key> --folder-key <folder-key>`.
+   - **User provided a job key and `RuntimeType` is NOT `ProcessOrchestration`** (standard child job): the child job was spawned by a Maestro service task. Check `ParentJobKey` — that parent job's key may be the instance ID. Try `uip maestro <type> instance get <parent-job-key> --folder-key <folder-key>`.
    - **Neither works**: search with `uip maestro <type> incident summary --output json` to find the `processKey`, then `uip maestro <type> processes incidents <process-key> --folder-key <folder-key>` to find incident records containing the `instanceId`. If the process type is unknown, try each (`bpmn`, `flow`, `case`) in turn.
    - **`instance list` may return empty** for completed or faulted instances. Always try `instance get` directly before concluding an instance doesn't exist. Do NOT rely on `instance list` alone.
-4. **Full incident details** — `uip maestro <type> instance incidents <instance-id> -f <folder-key>`. This returns `errorDetails` with stack traces. Do NOT use `uip maestro <type> incident summary` — that returns summaries only without error details.
-5. **Element executions** — `uip maestro <type> instance element-executions <instance-id> -f <folder-key>` to see what each element did and where execution stopped.
+4. **Full incident details** — `uip maestro <type> instance incidents <instance-id> --folder-key <folder-key>`. This returns `errorDetails` with stack traces. Do NOT use `uip maestro <type> incident summary` — that returns summaries only without error details.
+5. **Element executions** — `uip maestro <type> instance element-executions <instance-id> --folder-key <folder-key>` to see what each element did and where execution stopped.
 6. **Child jobs** — if the process has service tasks, list child jobs and check their state and error messages. The child's failure reason is often the actual root cause.
 
 ## Top-20 Error Quick Route

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/personal-automation-quota.md

@@ -32,7 +32,7 @@ What to look for:
 
 ## Resolution
 
-- **If Personal Automation quota exhausted:** request a license upgrade via [self-service license increase](https://uipath.atlassian.net/wiki/spaces/LIC/pages/2834596253), or wait for the monthly quota reset
+- **If Personal Automation quota exhausted:** request a license upgrade via the organization admin or UiPath account manager, or wait for the monthly quota reset
 - **If Agentic Units expired:** allocate AU from **Admin > Organization > Subscriptions** or contact the UiPath account manager
 - **If recurring:** redesign the workflow to use a tenant-level Unattended robot instead of Personal Automation so quotas come from the shared pool
 

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

@@ -1,13 +1,8 @@
 # Orchestrator Investigation Guide
 
-## Output Capture Pattern
+## Output Capture
 
-Every `uip` data-gathering command below assumes two patterns to keep the agent's context lean AND preserve an audit trail:
-
-1. **Filter at the source with `--output-filter`** — only pull the fields you actually need. Do NOT fetch the full response and truncate the output with `[:3000]` or similar post-hoc slicing — that silently drops information.
-2. **Save AND inspect in one call with `| tee`** — pipe the filtered response through `tee` to `.local/investigations/raw/<command>.json`. The response is visible in the tool result for immediate use AND saved on disk for the hypothesis-tester to re-read later. **Run `mkdir -p .local/investigations/raw` once before the first fetch — `tee` does not create the directory and will otherwise drop the file silently.**
-
-Reference shape:
+Follow the generic guide § Output Capture (filter at source; `| tee` for small/filtered results, `>` + selective read-back for heavy/unfilterable ones; filter-failure fallback; anti-patterns). Orchestrator-specific filter expressions appear inline in each command below. Reference shape:
 
 ```
 uip or jobs list --folder-key <key> --state Faulted \
@@ -16,16 +11,7 @@ uip or jobs list --folder-key <key> --state Faulted \
   | tee .local/investigations/raw/triage-jobs-list.json
 ```
 
-**Filter-failure fallback.** If `--output-filter '<jsonpath>'` returns an empty result, an error, or a shape the agent cannot interpret (likely cause: a field name in the documented filter has drifted from the current CLI response schema), retry the SAME command ONCE without `--output-filter` to see the actual response shape. Use that unfiltered response for the current call, and note the stale filter in your evidence summary so the discrepancy gets fixed in the guide. Do NOT silently swallow filter errors — they mean the documented filter is stale.
-
-Anti-patterns — do NOT do these:
-
-- `uip <cmd> --output json > file.json` — redirect alone hides stdout; the agent then needs an extra turn running `python -c "json.load(...)"` just to see what it fetched.
-- `uip <cmd> --output json | head -c 3000` or any byte/character slice — truncation silently drops fields that may be required by the playbook downstream.
-- Fetching the unfiltered full response when only 2–3 fields are needed — bloats the agent's context and the cache-read budget on every subsequent turn.
-- Inventing JSONpath field names on the fly. Use only the filter expressions documented in this guide for each command. If a documented filter fails, apply the filter-failure fallback above — do NOT guess different field names.
-
-If the CLI's `--output-filter` cannot express the shape you need, see `scripts/` for skill-provided filter helpers, OR fetch with a minimal field set first and only re-fetch with more fields when a specific gap forces it.
+If `--output-filter` cannot express the shape you need, see `scripts/` for skill-provided filter helpers, or fetch a minimal field set first and re-fetch more only when a gap forces it.
 
 ## Data Correlation
 
@@ -38,17 +24,17 @@ Before fetching ANY job, queue, or asset data, resolve identity first:
    - **(A) User named a folder explicitly in the prompt** (e.g., "the failed job in *Shared*", "in *PurchaseOrderProcessing* folder") → continue with step A below.
    - **(B) User did NOT name a folder** (e.g., "investigate my last failed job", "my automation broke") → **STOP and ask the user. Do NOT run `uip or jobs list` looking for the failed job. Do NOT iterate over folder keys hoping to find it. Do NOT infer the folder from `project.json` — that is a hint to surface in the ask, not a selector to commit on.** Go directly to step B below.
 
-   The above is non-negotiable. The single most expensive triage failure mode is `jobs list` enumeration against arbitrary folders trying to "find" a job whose folder is unspecified — it burns 20–40 turns and an extra subagent dispatch before the orchestrator's sanity gate catches the wrong pick. Asking the user is 2 turns. Always cheaper.
+   The above is non-negotiable. The single most expensive anchoring failure mode is `jobs list` enumeration against arbitrary folders trying to "find" a job whose folder is unspecified — it burns 20–40 turns before the correlation check catches the wrong pick. Asking the user is 2 turns. Always cheaper.
 
    ---
 
    **Step A — User named a folder.** Resolve its key:
    ```
    uip or folders list --output json \
-     --output-filter "[?DisplayName=='<name>'].{Key:Key,FullyQualifiedName:FullyQualifiedName}" \
+     --output-filter "[?Name=='<name>'].{Key:Key,Path:Path,Type:Type}" \
      | tee .local/investigations/raw/triage-folders-list.json
    ```
-   If the result is empty (no folder with that name), write `needs_input.json` listing the available folders and asking the user to confirm the correct one. Do NOT guess. Proceed once the key is resolved.
+   If the result is empty (no folder with that name), ask the user via `AskUserQuestion`, listing the available folders as options to confirm the correct one. Do NOT guess. Proceed once the key is resolved.
 
    ---
 
@@ -57,12 +43,12 @@ Before fetching ANY job, queue, or asset data, resolve identity first:
    1. Run folders list ONCE to get candidates:
       ```
       uip or folders list --output json \
-        --output-filter "[].{Key:Key,DisplayName:DisplayName,FullyQualifiedName:FullyQualifiedName}" \
+        --output-filter "[].{Key:Key,Name:Name,Path:Path,Type:Type}" \
         | tee .local/investigations/raw/triage-folders-list.json
       ```
-   2. Write `needs_input.json` with the candidate folder names as `options`. If `project.json` exists in the working directory and its `name` matches one of the folders, put that folder FIRST in the options list with the label `"<folder> (your current project)"` — surface the hint, do not select for the user. Ask: *"Which folder is the failing job in?"*
-   3. Return to the orchestrator. Do NOT continue with any data fetch.
-   4. On re-spawn with the user's answer, record the chosen folder in `state.json` and proceed to step 2 (Process).
+   2. Ask via `AskUserQuestion` with the candidate folder names as options. If `project.json` exists in the working directory and its `name` matches one of the folders, put that folder FIRST in the options list with the label `"<folder> (your current project)"` — surface the hint, do not select for the user. Ask: *"Which folder is the failing job in?"*
+   3. Do NOT continue with any data fetch until the user answers.
+   4. Record the chosen folder in `.local/investigations/notes.md` and proceed to step 2 (Process).
 
    **Bounded fallback** — applies ONLY when the user explicitly answers step B.3 with "I don't know" / "no preference" / equivalent. Run ONCE without folder filter, pick the most-recent, record the folder, proceed:
    ```
@@ -92,7 +78,7 @@ If data doesn't match: **discard it**. Do NOT fetch details for jobs or items fr
 
 ## Job Data Bundle
 
-For every job under investigation, gather these in order. Follow the Output Capture Pattern above — pipe through `tee` and filter at the source.
+For every job under investigation, gather these in order. Follow the generic guide § Output Capture — filter at the source, `tee` the filtered results, `>` the dense/unfiltered ones (e.g. traces).
 
 1. **Job details** — state, input/output arguments, timing, machine info, error details
    ```
@@ -115,9 +101,9 @@ For every job under investigation, gather these in order. Follow the Output Capt
 4. **Job traces** — execution traces (activity states, variable snapshots, execution path). Available for all job types.
    ```
    uip or jobs traces <key> --output json \
-     | tee .local/investigations/raw/triage-job-traces.json
+     > .local/investigations/raw/triage-job-traces.json
    ```
-   Traces are dense; consider filtering by activity name or error attribute when re-fetching for hypothesis testing.
+   Traces are dense and unfiltered — redirect with `>` (not `tee`) so the full body stays out of context, then read back only the activity/error entries you need. Filter by activity name or error attribute when re-fetching for hypothesis testing.
 
 This is the baseline. Domain-specific data gathering builds on it — see the investigation guide for each matched domain (UI Automation, Integration Service, Maestro) for additional steps after the baseline.
 

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

@@ -34,7 +34,7 @@ What can cause it:
    - An Unattended runtime is licensed and free to take the job. `uip or licenses info` reports `Used.Unattended` = the count of **connected/allocated** Unattended runtimes, NOT the count of running jobs. The template's connected idle runtime holds its slot, so `Used == Allowed` is *expected and healthy* when that slot belongs to the assigned template — it is NOT exhaustion. Confirm the runtime is idle rather than busy with a different job: `uip or jobs list --folder-key <key> --state Running --output json`. If no OTHER Unattended job is Running, the licensed runtime is available for this job. Treat the license as the blocker ONLY when a *different* Running Unattended job holds the slot.
 4. **All four prerequisites confirmed AND PendingReasons.Errors unchanged AND JobHistory shows no re-evaluation** → the conclusion is stale-dispatch.
 
-> **Do not invent a folder-assignment cause.** The PendingReasons text "…there is none connected to this folder" is Orchestrator's eligibility verdict **captured at dispatch time** — not live proof that the machine template is unassigned from the folder. No `uip` command enumerates folder→machine-template assignments, so a "template not assigned to the folder" root cause cannot be evidenced and MUST NOT be confirmed (shared.md invariants #1, #9). If `machines list` shows the assigned template currently has a connected runtime AND `JobHistory` has only the original Pending entry, the codes are stale: this playbook applies and the fix is stop + re-trigger — not a folder reconfiguration.
+> **Do not invent a folder-assignment cause.** The PendingReasons text "…there is none connected to this folder" is Orchestrator's eligibility verdict **captured at dispatch time** — not live proof that the machine template is unassigned from the folder. No `uip` command enumerates folder→machine-template assignments, so a "template not assigned to the folder" root cause cannot be evidenced and MUST NOT be confirmed (SKILL.md §1 invariants #1 no-fabrication and #8 symptom-≠-cause). If `machines list` shows the assigned template currently has a connected runtime AND `JobHistory` has only the original Pending entry, the codes are stale: this playbook applies and the fix is stop + re-trigger — not a folder reconfiguration.
 
 ## Resolution
 
@@ -58,7 +58,7 @@ Do NOT attempt to "fix" the stale codes by reassigning the template, adding the
 | `JobHistory` past the original entry | Maybe | No (only the original Pending entry) |
 | Remediation | Provision the missing prerequisite | Stop + re-trigger |
 
-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.
+Both playbooks can match on the shared Pending signals. When both match, resolve 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.
 

package/skills/uipath-troubleshoot/references/runtime-exceptions/playbooks/argument-null-exception.md

@@ -31,7 +31,7 @@ What to look for:
 
 1. **Get the stack trace** — for local execution, list `%localappdata%\UiPath\logs\` and open the log for today's date (if not found, ask for the error date); for Orchestrator, get job traces. Confirm the fault originates from the user's workflow code
 2. Extract the parameter name from the error message (`Parameter 'paramName'`) — this is the key troubleshooting signal
-3. Locate the faulted activity in source code and match the parameter name to the activity's input properties or the method being called
+3. Locate the faulted activity in source code and match the parameter name to the activity's input properties or the method being called. The stack trace names the workflow file (e.g. `Main.xaml` at the faulting activity) — check the working directory top level for the project (`project.json` + that file) and read it before presenting; tracing WHY the argument was null requires source. If absent, ask for the project path and present the parameter-level finding as **unconfirmed** — do not enumerate candidate null sources as findings
 4. Trace the argument source: find where the null value originates (variable assignment, activity output, config lookup, argument binding). Check if the assignment is conditional or depends on external data
 5. Check for missing defaults — does the variable have a default value? Is there a fallback for null?
 6. If intermittent: compare input data between successful and failed executions

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

@@ -1,6 +1,6 @@
-# Troubleshooting Reference Router
+# Domain Catalog
 
-Start here. Find the product or package that matches the user's issue, then follow the links to drill down into playbooks.
+Domain descriptions, namespaces, and CLI entry points. Runtime routing greps the playbook corpus directly (SKILL.md §4) — use this catalog to cross-check a (system, entity) classification, map exception namespaces to owning packages, browse a domain's playbook index during escalation, and route silent failures via the no-signature table below.
 
 ## Orchestrator
 
@@ -29,13 +29,15 @@ Agentic orchestration platform built on Orchestrator. BPMN-based process design
 
 ## Integration Service
 
-Connector platform for third-party integrations (Salesforce, Outlook, SAP, Slack, etc.). Manages OAuth connections, exposes activities for automations and BPMN processes, and provides event-based triggers. Issues here involve connection failures, expired authentication, triggers not firing, and operation errors. Connection errors from Integration Service often surface through Maestro or Orchestrator as the calling product. Also covers the runtime exceptions thrown by the connector activities (`ConnectorActivity`, `ConnectorTriggerActivity`, `ConnectorHttpActivity`): `GeneralException`/`RuntimeException` with `DAP-GE-*`/`DAP-RT-*` codes, and `UiPath.Ipc`/`UiPath.CoreIpc` `RemoteException`.
+Connector platform for third-party integrations (Salesforce, Outlook, SAP, Slack, etc.). Manages OAuth connections, exposes activities for automations and BPMN processes, and provides event-based triggers. Issues here involve connection failures, expired authentication, triggers not firing, and operation errors. Connection errors from Integration Service often surface through Maestro or Orchestrator as the calling product. Also covers the runtime exceptions thrown by the connector activities (`ConnectorActivity`, `ConnectorTriggerActivity`, `ConnectorHttpActivity`): `GeneralException`/`RuntimeException` with `DAP-GE-*`/`DAP-RT-*` codes, and `UiPath.Ipc`/`UiPath.CoreIpc` `RemoteException` — plus the `CNS…` error codes returned by the Connection Service HTTP API (connections/connectors/triggers CRUD, permissions, event callbacks, Solutions installs).
 
 Namespaces: `UiPath.IntegrationService.Activities`, `UiPath.IntegrationService.Activities.Runtime.Exceptions`
 
 CLI: `uip is --help`
 
 - [products/integration-service/overview.md](./products/integration-service/overview.md) — Product overview, connectors, connections, and CLI commands
+- [products/integration-service/dap-error-codes-reference.md](./products/integration-service/dap-error-codes-reference.md) — DAP runtime error-code catalog, telemetry customEvent fields, retry semantics, code → playbook map
+- [products/integration-service/cns-error-codes-reference.md](./products/integration-service/cns-error-codes-reference.md) — CNS (Connection Service API) error-code catalog: wire format, fault buckets, overloaded-code traps, retry semantics, code → playbook map
 - [products/integration-service/summary.md](./products/integration-service/summary.md) — All playbooks for Integration Service issues
 
 ## Agents
@@ -145,15 +147,6 @@ Namespaces: `UiPath.Database.Activities`
 - [activity-packages/database-activities/overview.md](./activity-packages/database-activities/overview.md) — Package overview, connection model, key activities, and common failure patterns
 - [activity-packages/database-activities/summary.md](./activity-packages/database-activities/summary.md) — All playbooks for Database Activities issues
 
-## Python Activities
-
-Activities for running Python code from a UiPath workflow via the `UiPath.Python.Activities` package. A `Python Scope` initializes an out-of-process Python engine (bound through Python.NET) that its child activities — `Load Python Script`, `Invoke Python Method`, `Get Python Object` — run against. Issues here involve engine-initialization failures (invalid `Path`, `Target` bitness mismatch, `Library path` missing for Python > 3.9 on Windows, unsupported Python version, missing .NET Desktop Runtime 6+), script load/import errors (`ModuleNotFoundError`, top-level syntax/exception, unresolved local imports), and hangs / oversized return data. Engine-config and module errors often surface only on the robot host — the scope uses the interpreter at `Path` and Windows environment variables, not the IDE's venv/conda env.
-
-Namespaces: `UiPath.Python.Activities`
-
-- [activity-packages/python-activities/overview.md](./activity-packages/python-activities/overview.md) — Package overview, Python Scope execution model and properties, and common failure patterns
-- [activity-packages/python-activities/summary.md](./activity-packages/python-activities/summary.md) — All playbooks for Python Activities issues
-
 ## Web Activities
 
 Activities for outbound HTTP calls and payload deserialization. `HttpClient` (legacy, RestSharp) and `NetHttpRequest` (modern, `System.Net.Http`) issue HTTP requests; `DeserializeJson`, `DeserializeJsonArray`, and `DeserializeXml` parse a string into a typed object / `JArray` / `XDocument`. Issues here involve HTTP request failures (`System.Net.WebException` — status / DNS / connection / SSL), request timeouts (`System.TimeoutException`), null request inputs (`System.NullReferenceException`), modern-activity faults wrapped in `System.AggregateException`, malformed JSON/XML payloads (`Newtonsoft.Json.JsonReaderException` / `System.Xml.XmlException`), JSON type mismatches (`Newtonsoft.Json.JsonSerializationException`), and null/empty payloads (`System.ArgumentNullException`). These activities propagate raw framework exceptions — the faulted activity class + exception class is the discriminator. A malformed/null deserialize fault is frequently a symptom of an upstream HTTP call.
@@ -163,6 +156,15 @@ Namespaces: `UiPath.Web.Activities`
 - [activity-packages/web-activities/overview.md](./activity-packages/web-activities/overview.md) — Package overview, activity families, and common failure patterns
 - [activity-packages/web-activities/summary.md](./activity-packages/web-activities/summary.md) — All playbooks for Web Activities issues
 
+## App Events (Workflow Events) Activities
+
+Internal activities that connect a **UiPath App** (or a Studio Web app preview) to the robot running the App's workflows. They are `[Internal]` — a user never places them — so failures surface as **a job invoked by an App faulting**, with the activity name (`HandleAppRequest`, `AppRequestTrigger`, `InitializeHubConnection`) appearing in the job error / trace spans rather than the user's project. The App↔robot channel runs in one of two modes: RobotJS (legacy local pipe) or SignalR (modern hub). These activities propagate raw .NET framework exceptions (no package-specific wrapper), so the faulted activity class + exception class is the discriminator: `HandleAppRequest` `NullReferenceException` (a null deref inside the App-invoked workflow), `AppRequestTrigger` `TimeoutException`/`IOException`/`InvalidOperationException` (App↔robot channel/transport lost), and `InitializeHubConnection` `AggregateException` (SignalR hub bootstrap failed — unwrap the inner).
+
+Namespaces: `UiPath.WorkflowEvents.Activities`
+
+- [activity-packages/workflowevents-activities/overview.md](./activity-packages/workflowevents-activities/overview.md) — Package overview, connection modes, activity types, and common failure patterns
+- [activity-packages/workflowevents-activities/summary.md](./activity-packages/workflowevents-activities/summary.md) — All playbooks for App Events (Workflow Events) Activities issues
+
 
 ## Playbooks
 
@@ -175,3 +177,22 @@ All playbooks use the same headers: `## Context`, `## Investigation` (optional),
 | **Low** | General symptoms → multiple causes | General guidance or absent | Robot unresponsive → could be heartbeat, network, or machine issue |
 
 Template and full guide: [templates/playbook-template.md](./templates/playbook-template.md) | [knowledge-base-guide.md](./knowledge-base-guide.md)
+
+## No-signature routing
+
+For problems with nothing greppable (no exception, no error code — silent failures, hangs, wrong results), map the symptom to a domain, then check that domain's `summary.md` for the matching silent playbook:
+
+| Symptom | Domain | Entry |
+|---|---|---|
+| Job/run Successful but the action had no effect or output is wrong | The acting activity's package (ui-automation, word, excel, gsuite, o365, database, system) | Activity-level trace logs — look for zero-count lines ("Replaced 0 occurrence"), Simulate/inert-verify configurations, provider quirks |
+| Job stuck Pending | orchestrator | `PendingReasons` on the job record — its error codes ARE greppable signatures; re-grep after fetching |
+| Job/instance stuck Running | orchestrator (plain job) / maestro (BPMN instance) | Child-job states + open incidents; a Maestro instance with an Open incident is blocked until the incident is resolved |
+| Works in Debug, fails deployed | maestro | Debug-vs-deploy silent playbook |
+| Duplicate task/element executions | maestro | Boundary-event silent playbook |
+| Traces/evidence missing or disappearing | maestro / orchestrator retention | Silent playbooks; retention windows |
+| Robot unresponsive, heartbeat gaps | orchestrator | Machine/session state via the orchestrator investigation guide |
+| Hang mid-activity, no fault, no timeout | The activity's package | Package overview "common failure patterns" (e.g., Word background modal dialogs, Python stdout flooding) |
+| Reads/writes the wrong files with no error | The activity's package | Relative-path resolution quirks (e.g., Python per-package WorkingFolder) |
+| Slowness / degradation without errors | Owning product | Product overview + `uip docsai ask` |
+
+Cross-domain rule: the symptom's *reporting* surface is not necessarily the owning domain — extract entity keys from the fetched records and follow them one hop before settling on a domain.

package/skills/uipath-troubleshoot/references/templates/playbook-template.md

@@ -7,7 +7,7 @@ confidence: high | medium | low
 ## Context
 
 What this looks like:
-- <observable symptom 1>
+- <observable symptom 1 — quote verbatim error strings (exception FQN, message fragment, error code); routing greps for them>
 - <observable symptom 2>
 
 What can cause it:

package/version-manifest.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 1,
-  "skillsVersion": "1.197.0",
+  "skillsVersion": "1.197.2",
   "targetCli": "^1.197.0"
 }

package/skills/uipath-troubleshoot/agents/depth-verifier.md

@@ -1,164 +0,0 @@
-# Depth-Verifier Sub-Agent
-
-Gate confirmed root-cause hypotheses for depth. Output: a `verdict`
-(`verified` | `shallow`) + gap list the orchestrator uses to decide —
-present the resolution, or re-spawn one more hypothesis-tester round.
-Do NOT generate hypotheses, run CLI, or rewrite findings (see Invariants).
-
-## Inputs you read
-- `.local/investigations/state.json` — for `matched_playbooks` and `scope`
-- `.local/investigations/hypotheses.json` — every hypothesis with
-  `is_root_cause: true`
-- The matched playbook file referenced by
-  `state.json.matched_playbooks[*].path` — read its `## Context` cause
-  list ("What can cause it") and `## Resolution` section
-- `.local/investigations/evidence/*.json` — for cause-specific evidence
-
-## The three depth checks (per confirmed hypothesis)
-
-1. **Specific cause named.** The hypothesis's `evidence_summary` (or
-   description) names *one* item from the playbook's cause list ("What
-   can cause it", under `## Context`) verbatim or as a tight paraphrase —
-   specific, not a vague generalization (e.g. "the connection is invalid"
-   when the playbook lists four distinct sub-causes).
-
-2. **Evidence pinned to the cause.** Evidence files contain a datum that
-   distinguishes the chosen cause from its siblings in the same
-   cause list. Symptom-level data (e.g. "ping returned 404") fits
-   multiple causes — not enough. Require evidence that singles out *this*
-   cause: file contents, ownership, folder bindings, configuration flags,
-   trace attributes.
-
-3. **Resolution alignment.** The playbook's `## Resolution` must contain
-   a branch keyed on the named cause. If it offers multiple branches
-   under "If X, then …", confirm one corresponds to the cause named in
-   check 1. (The hypothesis's `resolution` field is written later by the
-   orchestrator — do not depend on it being populated here.)
-
-## Causal precedence
-
-A root cause is an *originating fault*: an event that, had it not
-occurred, would mean the failure never happened. A hypothesis that
-instead describes a consequence, propagation pattern, or persistence
-of an upstream fault is not a root cause — even if every check above
-passes — because eliminating the consequence does not prevent the
-fault.
-
-Apply two precedence checks:
-
-1. **Explicit-event check.** List every event the hypothesis treats
-   as given (the inputs to its causal chain) and ask "why did that
-   occur?". If any input has a more upstream answer that the current
-   hypothesis does not address, this hypothesis is downstream.
-
-2. **Implicit-presupposition check.** A persistence or
-   state-transition narrative typically *presupposes* an upstream
-   condition without naming it as an event — e.g., "state X did not
-   transition" presupposes "the system needed to transition out of
-   X", which presupposes "the system entered X for a reason worth
-   investigating". Identify the presupposed upstream condition and
-   require a separate hypothesis answering "why is the system in
-   that condition?". If `hypotheses.json` does not contain such a
-   hypothesis (or contains one still `pending`), the current
-   hypothesis cannot be root cause.
-
-If either check finds a missing upstream, reject the verdict — emit
-`shallow` with a `gaps` entry of `kind: "textual"` and
-`check: "causal_precedence"` (a string identifier distinct from the
-numbered depth checks 1–3 above; the orchestrator routes on `kind`,
-not on `check`), detail
-`"hypothesis describes consequence/persistence; upstream of <X> not investigated"`.
-The orchestrator must test the upstream condition before any
-downstream hypothesis can be accepted as root cause.
-
-## Output
-
-Write `.local/investigations/depth-check.json`:
-
-```json
-{
-  "schema_version": "1.1",
-  "verdict": "verified",                                   // or "shallow"
-  "hypothesis_id": "H1",
-  "playbook_path": "<path from state.json.matched_playbooks>",
-  "named_cause": "<verbatim or quoted paraphrase from the playbook's 'What can cause it' list>",
-  "evidence_for_cause": [
-    "<file path under .local/investigations/evidence/ or .local/investigations/raw/>"
-  ],
-  "resolution_alignment": "matches",                       // or "mismatch", or "missing"
-  "gaps": [
-    {
-      "kind": "factual",                                   // or "textual"
-      "check": 2,                                          // 1, 2, or 3 (corresponds to the depth check)
-      "detail": "<one-line description of the gap>"
-    }
-  ]
-}
-```
-
-If multiple hypotheses are flagged `is_root_cause: true`, write one
-entry per hypothesis as an array under a top-level `"checks"` key
-instead.
-
-If `verdict` is `shallow`, list every missing dimension in `gaps`. The
-orchestrator routes by gap `kind` (see Gap classification below).
-
-## Gap classification
-
-Each gap MUST be classified as either `factual` or `textual` so the
-orchestrator can decide whether re-spawning the hypothesis-tester is
-worth the cost.
-
-- **`kind: "factual"`** — applies to **check 2 only** (Evidence pinned).
-  The evidence files do not contain a datum that singles out the named
-  cause from neighboring causes in the same playbook list. Re-running
-  the hypothesis-tester *can* fix this by gathering more CLI output,
-  reading additional project-source files, or inspecting trace span
-  attributes.
-
-- **`kind: "textual"`** — applies to **checks 1 and 3** (Specific cause
-  named, Resolution alignment). The cause is named imprecisely
-  (paraphrase too loose, wrong sub-cause picked from a list of similar
-  causes) or the resolution branch listed in the hypothesis is the
-  wrong one for the named cause. Re-running the hypothesis-tester will
-  NOT fix this — the cause/resolution narrative is the *generator's*
-  output, not the tester's. The orchestrator handles textual gaps by
-  accepting the hypothesis at reduced confidence and surfacing the gap
-  to the user via the presenter, rather than re-running tests.
-
-  **A textual gap on check 1 (cause naming) does NOT invalidate the
-  matched playbook's `## Resolution` procedure.** Cause label and
-  remediation path are separable. When the matched playbook's resolution
-  is interactive (e.g., "show the user the recovered selector and ask
-  whether to apply"), that procedure remains the authoritative resolution
-  even if the cause description has been refined or partially refuted.
-  Do NOT advise switching to another playbook's resolution just because
-  that other playbook better names the cause — the original playbook's
-  remediation must still run. Note the cause refinement in the gap
-  `detail` so the presenter can surface it alongside the unchanged
-  resolution. The only situation in which the resolution branch itself
-  should change is a check 3 gap (Resolution alignment) — flag that
-  separately.
-
-If a single check produces a gap that has both factual and textual
-character (e.g., evidence is missing AND the named cause is
-paraphrased), emit two separate gap entries — one of each kind.
-
-## Invariants
-
-- You do NOT alter `hypotheses.json` or `state.json`.
-- You do NOT call sub-agents.
-- You do NOT run uip commands.
-- You read playbooks from paths in `state.json.matched_playbooks` —
-  same rule as every other agent.
-- Apply the standard `shared.md` invariants. In particular, **symptom
-  ≠ cause**: a symptom-level match alone does not satisfy check 1
-  or check 2.
-
-## When you may declare `verified` despite incomplete evidence
-
-If a playbook's cause list ("What can cause it") is truly exhaustive but a
-specific cause cannot be distinguished from the available data
-(genuine data gap, not laziness), declare `verdict: shallow` with
-`gaps: ["cannot disambiguate causes X vs Y from available evidence"]`.
-The orchestrator will route to `needs_input` rather than re-test.

package/skills/uipath-troubleshoot/agents/hypothesis-generator.md

@@ -1,42 +0,0 @@
-# Hypothesis Generator Sub-Agent
-
-Produce ranked hypotheses based on investigation state and evidence.
-
-See `shared.md` § Invariants and § Confidence-Level Behavior first.
-
-## Inputs
-
-- `.local/investigations/state.json`
-- `.local/investigations/evidence/` — all evidence so far
-- `.local/investigations/hypotheses.json` — if re-invoked (deepening or scope adjustment)
-
-## Output
-
-Write or update: `.local/investigations/hypotheses.json` — see `schemas/hypotheses.schema.md`
-
-## Steps
-
-1. **Read state + evidence + signals.** Read `state.json`, `evidence/triage-initial.json` (especially its `signals` array — the structured fact inventory triage produced), and the matched + eliminated playbook lists. Verify the evidence relates to the user's reported problem (correct process, queue, entity). If it doesn't, STOP — write `needs_input.json` (see shared.md) flagging the mismatch.
-2. **If re-invoked:** read existing hypotheses; skip those in `generation_context.eliminated_ids` (never regenerate eliminated ones). On `trigger: deepening`, each new sub-hypothesis MUST name a *distinct upstream cause* for the parent's confirmed state — not a reworded paraphrase. If you cannot name a distinct upstream cause, write `needs_input.json` instead of restating.
-3. **Read matched playbooks** from `state.json.matched_playbooks` — these are pre-ranked by `signal_match_count` (highest specificity first). Honor that ordering: H1 is drafted from the top-ranked playbook, H2 from the second-ranked, etc. **Never draft hypotheses from playbooks in `eliminated_playbooks`** — those have been disproved by signals already.
-
-   Generate hypotheses for **every** matched playbook in a **single round** (see Single-round coverage rule in `shared.md`). The number of hypotheses per playbook follows the confidence-level behavior table in `shared.md` ("Generator" column).
-
-   **Cite signals.** Each hypothesis records `signals_supporting` — the names of signals from `evidence/triage-initial.json.signals` that drove this hypothesis. A hypothesis with zero supporting signals is a contract violation: every drafted hypothesis must trace back to at least one observed signal, otherwise it is unfounded speculation.
-4. **Search documentation** — run up to 5 `uip docsai ask` queries for additional context. If after playbooks + 5 queries you still lack context: generate from what you have. If you truly cannot generate any hypothesis, write `needs_input.json` (see shared.md).
-5. **Inspect for explicit fault signals first.** Before drafting any hypothesis, scan triage evidence for explicit fault data — exception stacks, error codes, faulted-state details, error-level logs, incidents, element/activity errorDetails. If any fault signal is present, the **originating-fault hypothesis** (what caused the fault to occur) MUST be drafted first and assigned the highest confidence. Persistence, propagation, cleanup, recovery-gap, or state-transition hypotheses go *after* it. Never lead the hypothesis set with a pattern that explains how a fault was handled or how its consequences propagated when an explicit fault stack is on hand.
-
-6. **Generate hypotheses**, each with:
-   - Description, scope level, confidence, reasoning
-   - **Source citation** — which reference doc, search result, or playbook informed it
-   - `to_confirm` and `to_eliminate` evidence requirements
-   - `to_eliminate` MUST include execution path verification for multi-step hypotheses
-   - **Evidence requirements must be grounded in triage data.** Only reference entity types that actually appear in triage evidence or are explicitly mentioned in the matched playbook's `## Context`.
-   - **Evidence requirements must be feasible.** Check `state.json` data gaps before writing steps. If a data source is unavailable, propose an alternative for the **same entity** (never substitute a different entity). If no alternative exists, set `needs_user_input: true` in the evidence requirement with a description of what the user must provide.
-
-## Boundaries
-
-- Do NOT run uip commands against the platform — that's the tester's job
-- Do NOT test hypotheses — generate them with evidence requirements
-- Do NOT present hypotheses to the user — write them to `hypotheses.json`
-- Do NOT read source code files or query live platform data — that's the tester's job. Use triage evidence, playbooks, and docsai results to generate hypotheses.