@uipath/skills 1.196.0 → 1.197.0

package/skills/uipath-governance/references/compliance-pack/query/impl.md

@@ -0,0 +1,75 @@
+# Query — Control and Clause Lookup
+
+**Preview gate:** Compliance Standards is a preview feature. Append the disclaimer to user-facing output; on any compliance-packs **403**, stop (org not enrolled). See [preview-gate.md](../preview-gate.md).
+
+Pure information — no state commands, no mutations. Uses `catalog get` data only.
+
+## When to use
+
+- "What does clause A.6.2.8 recommend?"
+- "Which ISO 42001 controls address prompt injection?"
+- "What's the recommended setting for trace retention?"
+- "Show me all High-impact controls"
+- "What does the AI Trust Layer traceability section require?"
+
+## Command (if not already fetched)
+
+```bash
+# Read the session dir written by catalog get; run catalog get if not yet fetched this session.
+SESSION_TEMP=$(cat "$HOME/.uipath-compliance-current-session" 2>/dev/null) || {
+  SESSION_TEMP=$(mktemp -d)
+  echo "$SESSION_TEMP" > "$HOME/.uipath-compliance-current-session"
+}
+uip gov compliance-packs catalog get iso-42001-2023 --output json > "$SESSION_TEMP/catalog.json"
+```
+
+## Filter from catalog
+
+**By clauseId:** match `clauses[].clauseId` exactly ("A.6.2.8", "6.1.4")
+
+**By topic:** match user content words against:
+- `clause.clauseName`
+- `editorialPolicies[].controls[].displayName`
+- `editorialPolicies[].controls[].description`
+- `editorialPolicies[].controls[].configLocation`
+
+**By impact:** `controls[].impact == "High"` for "high-impact" / "critical" / "priority"
+
+## Present matched controls
+
+For each matched clause:
+
+```
+<clauseName>  (<clauseId>)
+<N> settings  ·  <highCount> High  ·  <medCount> Medium  ·  <lowCount> Low
+
+┌──────────────────────────────┬─────────────────────────┬────────┬──────────────────────────────────────┐
+│ Setting                      │ Recommendation          │ Impact │ Where to configure                   │
+├──────────────────────────────┼─────────────────────────┼────────┼──────────────────────────────────────┤
+│ <controlDisplayName>         │ <recommendedSetting>    │ High   │ <configLocation>                     │
+│ <controlDisplayName>         │ <recommendedSetting>    │ Medium │ <configLocation>                     │
+└──────────────────────────────┴─────────────────────────┴────────┴──────────────────────────────────────┘
+[repeat per matched clause]
+
+Current posture on <tenantName>: <inPlaceCount> / <totalCount> settings Applied
+→ 'Check my ISO 42001 posture'  to see all gaps
+→ 'Apply <clauseName> settings'  to configure these
+```
+
+**Data sources:**
+- `controls[].displayName` → Control column
+- `controls[].recommendedSetting` → Recommendation column
+- `controls[].impact` → Impact column
+- `controls[].configLocation` → Where to configure column
+- Current posture line: read from `SESSION_TEMP/coverage.json` **only if it already exists** (written by a prior `state coverage` call this session) — parse `Data.Summary.InPlaceCount` / `DeploymentPolicyCount`. If the file does not exist, omit the posture line entirely. **Never run `state coverage` or any other `state` command here.**
+
+**Terminology:** "settings" for configured items. Plain-English clause name in headline, clause ID as secondary reference in parentheses.
+
+## Auth failure handling
+
+**403 / Forbidden** (not 401) → org not enrolled in the Compliance Standards preview; stop and show the opt-in message. See [preview-gate.md](../preview-gate.md).
+
+If `catalog get` returns an auth error (401 / `RetryWillNotFix`):
+1. Report the error to the user.
+2. Stop. Do NOT suggest or write example `state` commands (coverage, enable, disable, get) anywhere — not in the response, not in output files, not as comments.
+3. The query flow is read-only; if catalog data is unavailable, there is nothing to query.

package/skills/uipath-governance/references/diagnose/CAPABILITY.md

@@ -0,0 +1,71 @@
+# Diagnose — Investigate Governance Policy Failures
+
+Capability index for diagnosing AOps product-policy and Access tool-use-policy failures via `uip gov`.
+
+> **Where you came from / where to go next.** Diagnose is downstream of Operate (a deployed policy failed
+> to take effect, blocked something unexpected, or returned empty). Source fixes — policy edits, redeployment,
+> rule changes — are Operate actions requiring explicit user consent after root cause analysis.
+>
+> **Inherits universal rules from [SKILL.md](../../SKILL.md).** Use `uip gov ... --output json` for all diagnostic reads.
+
+## When to use this capability
+
+- Investigate why a deployed AOps policy isn't taking effect.
+- Debug deployment precedence (user > group > tenant override chain).
+- Diagnose wrong policy applied (license-type / product mismatch).
+- Triage access-policy blocking a legitimate tool invocation.
+- Investigate access-policy not blocking when it should (rule too narrow).
+- Diagnose `deployed-policy get` returning empty (no deployment, wrong subject).
+- Investigate policy create/update rejection (invalid product identifier, malformed JSON).
+- Audit which policies are deployed to which subjects.
+
+## Critical rules
+
+1. **Diagnose reads; Operate mutates.** Do not create/delete/redeploy policies while diagnosing — present findings and let the user decide the fix.
+2. **Use the CLI as the diagnostic interface.** Run `uip gov ... --output json` for all reads.
+3. **Use `deployed-policy get` for effective policy.** Returns the single policy that applies after the user → group → tenant chain is walked. Use `deployed-policy list` to see every applicable policy in priority order.
+4. **Use `access-policy evaluate` for rule testing.** The PDP resolves `Allow` / `Deny` / `NoOp` for a concrete request context — faster and more authoritative than manual rule inspection.
+5. **Classify the branch first.** AOps (product-layer) and Access (tool-use) are separate systems. Determine which branch the symptom belongs to before investigating.
+6. **Do not expose private data.** Redact tenant URLs, policy payloads, and user identifiers in summaries.
+
+## Workflow
+
+| Journey | Read |
+|---------|------|
+| Triage a governance failure (sequential ladder) | [references/troubleshooting-guide.md](references/troubleshooting-guide.md) |
+| Recognize a known failure pattern (lookup) | [references/failure-modes.md](references/failure-modes.md) |
+
+## Common tasks
+
+| I need to... | Read |
+|---|---|
+| Investigate why a deployed AOps policy isn't enforced | [troubleshooting guide → Step 2](references/troubleshooting-guide.md#step-2-check-whats-deployed) |
+| Debug deployment precedence (user > group > tenant) | [troubleshooting guide → Step 3](references/troubleshooting-guide.md#step-3-check-precedence) |
+| Diagnose wrong policy applied | [failure modes → Wrong policy applied](references/failure-modes.md#wrong-policy-applied-license-type-mismatch) |
+| Investigate blocked tool invocation | [failure modes → Access policy blocking legitimate invocation](references/failure-modes.md#access-policy-blocking-legitimate-tool-invocation) |
+| Investigate access policy not blocking | [failure modes → Access policy not blocking](references/failure-modes.md#access-policy-not-blocking) |
+| Diagnose empty deployed-policy result | [failure modes → Deployed policy returns empty](references/failure-modes.md#deployed-policy-returns-empty) |
+| Troubleshoot policy create/update rejection | [failure modes → Policy create/update rejected](references/failure-modes.md#policy-createupdate-rejected) |
+| Evaluate access-policy rules against test inputs | [troubleshooting guide → Step 4](references/troubleshooting-guide.md#step-4-for-access-evaluate-with-test-inputs) |
+
+## Anti-patterns
+
+- **Never redeploy or edit policies while diagnosing.** Present findings first; let the user authorize mutations.
+- **Never assume which branch the failure belongs to.** Classify AOps vs Access before investigating.
+- **Never skip `deployed-policy get` and jump to policy definition.** The effective policy (after chain resolution) may differ from the policy definition.
+- **Never run `access-policy evaluate` with dummy UUIDs and draw conclusions.** Untagged/unknown UUIDs correctly return `NoOp` — that does not mean the policy is broken.
+- **Never guess subject IDs.** Resolve via `deployment user/group/tenant list` before deeper queries.
+
+## References
+
+### Diagnose-scoped
+
+- [troubleshooting-guide.md](references/troubleshooting-guide.md) — diagnostic priority ladder
+- [failure-modes.md](references/failure-modes.md) — recurring failure patterns
+
+### Cross-capability
+
+- [aops-policy-deployed-guide.md](../aops-policy/aops-policy-deployed-guide.md) — query effective deployed policy
+- [aops-policy-deploy-guide.md](../aops-policy/aops-policy-deploy-guide.md) — deployment precedence and subject matrix
+- [access-policy-commands.md](../access-policy/access-policy-commands.md) — CLI reference including `evaluate`
+- [disambiguation-guide.md](../disambiguation-guide.md) — classify AOps vs Access intent

package/skills/uipath-governance/references/diagnose/references/failure-modes.md

@@ -0,0 +1,201 @@
+# Failure Modes — Governance Policies
+
+Named failure patterns with symptom → cause → investigation → fix. Match the user's symptom to a pattern, then follow the investigation steps.
+
+---
+
+## Policy Not Taking Effect (Deployment Precedence Issue)
+
+**Symptom:** Admin deployed a policy to a tenant (or group), but a specific user still sees the old behavior or no policy at all.
+
+**Causes:**
+1. A user-level assignment overrides the group/tenant assignment (user > group > tenant)
+2. A group-level assignment overrides the tenant assignment for members of that group
+3. User belongs to multiple groups with different policies — the group with the **lower priority number wins** (lower = more important)
+4. User has an explicit `null` (No Policy) override at a narrower scope
+5. Policy deployed to wrong subject (e.g. wrong group ID)
+
+**Investigation:**
+1. Check effective policy for the user:
+   ```bash
+   uip gov aops-policy deployed-policy get \
+     "$LICENSE_TYPE" "$PRODUCT_NAME" "$TENANT_ID" \
+     --output json
+   ```
+2. List all applicable policies to see the full chain:
+   ```bash
+   uip gov aops-policy deployed-policy list \
+     "$LICENSE_TYPE" "$PRODUCT_NAME" "$TENANT_ID" \
+     --output json
+   ```
+3. Check user-level override:
+   ```bash
+   uip gov aops-policy deployment user get "$USER_ID" --output json
+   ```
+4. Check group-level override:
+   ```bash
+   uip gov aops-policy deployment group get "$GROUP_ID" --output json
+   ```
+5. Check tenant-level assignment:
+   ```bash
+   uip gov aops-policy deployment tenant get "$TENANT_ID" --output json
+   ```
+
+**Fix:** Cause 1/2 → remove the narrower-scope override (`deployment user delete` or `deployment group delete`) or update it to match intent. Cause 3 → lower the priority number of the intended group's policy to make it win (lower priority = more important). Cause 4 → remove the explicit `null` override. Cause 5 → redeploy to the correct subject after resolving the right ID.
+
+---
+
+## Wrong Policy Applied (License-Type Mismatch)
+
+**Symptom:** Tenant has a policy deployed but the wrong rules are enforced — or a policy has no effect on certain users.
+
+**Causes:**
+1. Policy deployed to wrong `(product, license type)` pair — e.g. Assistant policy on `Unattended Robot` license (which has no Assistant slot)
+2. User's actual license type differs from the one the policy was deployed to
+3. Multiple license types exist and only one has the policy
+
+**Investigation:**
+1. List license types to see available options:
+   ```bash
+   uip gov aops-policy license-type list --output json
+   ```
+2. Check tenant deployment to see which `(product, licenseType)` pairs have assignments:
+   ```bash
+   uip gov aops-policy deployment tenant get "$TENANT_ID" --output json
+   ```
+3. Verify the product is included in the target license type (see [aops-policy-deploy-guide.md — License-type → product compatibility](../aops-policy/aops-policy-deploy-guide.md#license-type--product-compatibility)).
+
+**Fix:** Cause 1 → redeploy to a license type that includes the target product. Cause 2 → deploy to the license type the affected users actually hold. Cause 3 → deploy to all relevant license types.
+
+---
+
+## Access Policy Blocking Legitimate Tool Invocation
+
+**Symptom:** Agent, Flow, or automation reports "denied" or fails to invoke a child resource that should be allowed.
+
+**Causes:**
+1. Selector rule too broad — matches resources beyond the intended scope
+2. Actor rule excludes the calling user/group
+3. Executable rule blocks the actor process type
+4. Tags on the resource or executable trigger a deny-intent policy
+5. Robot/ExternalApplication actor — `actorRule` only matches `User`/`Group`, so robot actors return `NoOp` on all policies with `actorRule`
+
+**Investigation:**
+1. Evaluate the exact request context:
+   ```bash
+   uip gov access-policy evaluate \
+     --resource-type "<RESOURCE_TYPE>" \
+     --resource-id "<RESOURCE_UUID>" \
+     --actor-process-type "<ACTOR_PROCESS_TYPE>" \
+     --actor-process-id "<ACTOR_PROCESS_UUID>" \
+     --output json
+   ```
+2. Inspect `Data.enforcement` and `Data.effectivePolicies[]` to identify which policy contributed.
+3. Fetch the blocking policy:
+   ```bash
+   uip gov access-policy get "<POLICY_ID>" --output json
+   ```
+4. List all active access policies:
+   ```bash
+   uip gov access-policy list --filter "status in ('Active')" --output json
+   ```
+
+**Fix:** Cause 1 → narrow selector `resourceType`/`tags`. Cause 2 → add the calling user/group to `actorRule`. Cause 3 → add the actor process type to `executableRule`. Cause 4 → adjust tags on the resource or policy. Cause 5 → see [plugins/actor/impl.md — Robot intent](../access-policy/plugins/actor/impl.md) for the User-fallback pattern.
+
+---
+
+## Access Policy Not Blocking
+
+**Symptom:** Expected a deny/restrict behavior but the invocation goes through. `evaluate` returns `NoOp` or `Allow` when `Deny` was expected.
+
+**Causes:**
+1. No policy matches the request context (selector/actor/executable don't cover it)
+2. Policy status is `Inactive` (not enforced)
+3. Tags on the resource don't match the selector's tag filter
+4. Policy uses `enforcement: "Allow"` (the only authorable value) — deny intent requires targeting what should be allowed, not what should be blocked
+5. `evaluate` called with wrong resource-type or actor-process-type enum
+
+**Investigation:**
+1. Evaluate:
+   ```bash
+   uip gov access-policy evaluate \
+     --resource-type "<RESOURCE_TYPE>" \
+     --resource-id "<RESOURCE_UUID>" \
+     --output json
+   ```
+2. List policies and check status:
+   ```bash
+   uip gov access-policy list --output json
+   ```
+3. Inspect each candidate policy's selectors, executableRule, and actorRule:
+   ```bash
+   uip gov access-policy get "<POLICY_ID>" --output json
+   ```
+4. Verify the resource's tags in the Resource Catalog match the selector's tag filter.
+
+**Fix:** Cause 1 → broaden selector or add a new policy covering the gap. Cause 2 → update status to `Active`. Cause 3 → correct tags on resource or policy. Cause 4 → reframe deny intent as allow-only (see [plugins/tags/planning.md — Deny-to-Allow flip](../access-policy/plugins/tags/planning.md#deny-to-allow-flip)). Cause 5 → use correct enum values from [plugins/selector/impl.md](../access-policy/plugins/selector/impl.md).
+
+---
+
+## Deployed Policy Returns Empty
+
+**Symptom:** `deployed-policy get` returns `null`, `{}`, `{ "Message": "No policy applies." }`, or HTTP 204. `deployed-policy list` returns `[]`.
+
+**Causes:**
+1. No policy deployed at any scope (user/group/tenant) for this `(license type, product, tenant)` tuple
+2. Policy deployed to wrong tenant ID
+3. Policy deployed to wrong product name or license type
+4. User/group has an explicit `null` override (No Policy) and no fallback exists
+
+**Investigation:**
+1. Check tenant deployment:
+   ```bash
+   uip gov aops-policy deployment tenant get "$TENANT_ID" --output json
+   ```
+2. List all tenants with deployments:
+   ```bash
+   uip gov aops-policy deployment tenant list --output json
+   ```
+3. Verify the product name matches exactly:
+   ```bash
+   uip gov aops-policy product list --output json
+   ```
+4. Check user-level override:
+   ```bash
+   uip gov aops-policy deployment user get "$USER_ID" --output json
+   ```
+
+**Fix:** Cause 1 → deploy a policy via [aops-policy-deploy-guide.md](../aops-policy/aops-policy-deploy-guide.md). Cause 2 → redeploy to the correct tenant. Cause 3 → use the product `name` (not label) from `product list`. Cause 4 → remove the `null` override or deploy a policy at a broader scope.
+
+---
+
+## Policy Create/Update Rejected
+
+**Symptom:** `aops-policy create` or `access-policy create/update` returns 400, validation errors, or rejects the JSON payload.
+
+**Causes:**
+1. Invalid `productIdentifier` — used label instead of `name`
+2. Malformed JSON (missing required fields, wrong types)
+3. Access policy: `enforcement: "Deny"` used (only `Allow` is authorable)
+4. Access policy: `Selectors[].Values` missing `["*"]`
+5. Access policy: name collision (409 Conflict)
+6. AOps policy: invalid template structure
+
+**Investigation:**
+1. For AOps — verify product identifier:
+   ```bash
+   uip gov aops-policy product list --output json
+   ```
+2. For AOps — verify template structure:
+   ```bash
+   uip gov aops-policy template list --output json
+   uip gov aops-policy template get "<PRODUCT_NAME>" --output json
+   ```
+3. For Access — validate JSON structure:
+   ```bash
+   jq type "<POLICY_FILE>"
+   jq '.[0] | keys' "<POLICY_FILE>"  2>/dev/null || jq 'keys' "<POLICY_FILE>"
+   ```
+4. For Access — check error message in response `Data.errors`.
+
+**Fix:** Cause 1 → use `name` from `product list`. Cause 2 → fix JSON (validate with `jq`). Cause 3 → switch to `enforcement: "Allow"`. Cause 4 → add `"values": ["*"]` to selector entries. Cause 5 → choose a different name. Cause 6 → regenerate from template via [configure-aops-policy-data-guide.md](../aops-policy/configure-aops-policy-data-guide.md).

package/skills/uipath-governance/references/diagnose/references/troubleshooting-guide.md

@@ -0,0 +1,137 @@
+# Diagnostic Priority Ladder
+
+Sequential triage workflow for governance policy failures. Work through in order — stop when you have enough to diagnose.
+
+## Step 1: Identify the Policy Branch
+
+Determine whether the symptom belongs to AOps (product-layer) or Access (tool-use) based on user description:
+
+| Symptom | Branch | Next step |
+|---------|--------|-----------|
+| "Policy not enforced in Studio/Assistant/Robot" | AOps | Step 2 (check deployed) |
+| "Wrong rules applied to a product" | AOps | Step 2 (check deployed) |
+| "Policy not taking effect for a user/group" | AOps | Step 3 (check precedence) |
+| "Agent/Flow blocked from invoking a process" | Access | Step 4 (evaluate) |
+| "Tool invocation going through when it shouldn't" | Access | Step 4 (evaluate) |
+| "Policy create/update rejected" | Either | Step 5 (inspect definition) |
+| "Deployed-policy returns empty" | AOps | Step 2 (check deployed) |
+
+If the branch is unclear, ask the user: "Is this about product behavior (Studio/Robot features) or tool invocation (one workflow calling another)?" See [disambiguation-guide.md](../../disambiguation-guide.md).
+
+## Step 2: Check What's Deployed
+
+For AOps policy issues, start by querying the effective deployed policy.
+
+Get the effective policy for a `(license type, product, tenant)` tuple:
+```bash
+uip gov aops-policy deployed-policy get \
+  "$LICENSE_TYPE" "$PRODUCT_NAME" "$TENANT_ID" \
+  --output json
+```
+
+List every applicable policy in priority order:
+```bash
+uip gov aops-policy deployed-policy list \
+  "$LICENSE_TYPE" "$PRODUCT_NAME" "$TENANT_ID" \
+  --output json
+```
+
+Interpret:
+- `Data` present with `policyIdentifier` → a policy applies. Verify it matches the expected one.
+- `Data` is `null` / `{}` / `{ "Message": "No policy applies." }` → no policy applies. See [failure modes → Deployed policy returns empty](failure-modes.md#deployed-policy-returns-empty).
+- `Data` is an array (on `list`) → inspect `source` column (User/Group/Tenant) to understand where each policy comes from.
+
+If the policy does not exist at all, check whether it was created:
+```bash
+uip gov aops-policy list --output json
+```
+
+## Step 3: Check Precedence
+
+AOps deployment precedence: **User > Group > Tenant**. A user-level assignment always wins.
+
+Check each scope level:
+```bash
+uip gov aops-policy deployment user get "$USER_ID" --output json
+uip gov aops-policy deployment group get "$GROUP_ID" --output json
+uip gov aops-policy deployment tenant get "$TENANT_ID" --output json
+```
+
+Compare the assignments at each level for the target product:
+- If a user override exists (including explicit `null`), it wins over group and tenant.
+- If a group override exists, it wins over tenant for members of that group.
+- If the user belongs to **multiple groups** with different policies, the group with the **lower priority number wins** (lower = more important). Compare group priorities to identify which policy takes effect.
+- A `null` override means explicit "No Policy" — it is NOT the same as "no assignment" (which would inherit from the next level).
+
+List all deployment subjects to find unexpected overrides:
+```bash
+uip gov aops-policy deployment user list --output json
+uip gov aops-policy deployment group list --output json
+uip gov aops-policy deployment tenant list --output json
+```
+
+## Step 4: For Access — Evaluate with Test Inputs
+
+For access-policy issues, `evaluate` is the primary diagnostic tool.
+
+```bash
+uip gov access-policy evaluate \
+  --resource-type "<RESOURCE_TYPE>" \
+  --resource-id "<RESOURCE_UUID>" \
+  --actor-process-type "<ACTOR_PROCESS_TYPE>" \
+  --actor-process-id "<ACTOR_PROCESS_UUID>" \
+  --output json
+```
+
+Interpret `Data.enforcement`:
+- `Allow` → policy working as intended; the invocation is permitted.
+- `Deny` → a policy is blocking. Inspect `Data.effectivePolicies[]` for the blocking policy ID.
+- `NoOp` → no policy matched. Either no policy covers this context (expected with untagged/unknown resources) or the selector/actor/executable rules don't match.
+
+Fetch the blocking or candidate policy:
+```bash
+uip gov access-policy get "<POLICY_ID>" --output json
+```
+
+List all active policies:
+```bash
+uip gov access-policy list --filter "status in ('Active')" --output json
+```
+
+Check whether a robot/external-app actor is involved — `actorRule` only matches `User`/`Group`. See [plugins/actor/impl.md](../../access-policy/plugins/actor/impl.md).
+
+## Step 5: Inspect the Policy Definition
+
+When the deployment and evaluate steps don't reveal the issue, inspect the policy definition itself.
+
+For AOps:
+```bash
+uip gov aops-policy get "<POLICY_ID>" --output json
+```
+
+Verify:
+- `data` payload contains the expected rules for the product
+- Product identifier matches the deployment target
+- Template structure is valid
+
+For Access:
+```bash
+uip gov access-policy get "<POLICY_ID>" --output json
+```
+
+Verify:
+- `status` is `Active` (not `Inactive`)
+- `selectors[].resourceType` matches the target resource type
+- `selectors[].values` includes `["*"]` (required even when tags narrow scope)
+- `executableRule` covers the actor process type
+- `actorRule` (if present) includes the calling user/group
+- `enforcement` is `Allow` (only authorable value)
+- `organizationId` and `tenantId` match the current context
+
+## Outputs
+
+After completing the relevant steps, present:
+1. **Root cause** — what specifically failed and why
+2. **Evidence** — which CLI commands confirmed the diagnosis
+3. **Fix ownership** — whether the fix requires redeployment, policy editing, scope change, or policy creation
+4. **Recommended action** — specific next step (do not execute; present for user approval)

package/skills/uipath-governance/references/disambiguation-guide.md

@@ -7,6 +7,21 @@ The two branches:
 - **Branch A — AOps product policy** (`uip gov aops-policy`) → governs *product feature behavior* on Studio / StudioX / Assistant / Robot / AI Trust Layer / Agent Builder.
 - **Branch B — Access ToolUsePolicy** (`uip gov access-policy`) → governs *resource/tool use* on the Actor Process → child Resource boundary.
 
+## Compliance standard override (highest priority)
+
+**Before evaluating Branch A / B signals**, check for compliance standard framing:
+
+If the request contains a **standard name** (`ISO 42001`) **AND** a scope-limiting phrase (`just that area`, `only that part`, `not the whole standard`, `just that control`, `just the traceability`, `only the AI provider controls`, `just that compliance piece`), it is a **partial-apply** request regardless of whether the content words also match a Branch A model-gate signal.
+
+| Request shape | Route |
+|---|---|
+| ISO 42001 + "make AI usage traceable / logged" + "not the full standard" | Compliance standard → partial-apply (AITrustLayer traceability clauses) |
+| ISO 42001 + "lock down AI model providers / approved providers" + "just that control" | Compliance standard → partial-apply (AITrustLayer model-governance clauses) |
+| ISO 42001 + "robot allowlists / URL allowlists / application allowlists" + scoped | Compliance standard → partial-apply (Robot UIAutomation clauses) |
+| ISO 42001 + no scope-limiting phrase | Compliance standard → full-apply or posture check |
+
+Do **not** route ISO 42001 + model/traceability intents to `aops-policy` directly — even though those intents look like Branch A model-gate signals, the standard-framing signals the catalog-based path that understands which clauses apply.
+
 ## Strong signals — Branch A (AOps)
 
 Route directly, no disambiguation needed, when the user:

package/skills/uipath-governance/scripts/merge-overrides.mjs

@@ -0,0 +1,81 @@
+#!/usr/bin/env node
+import fs from "node:fs";
+import path from "node:path";
+
+const args = {};
+for (let i = 2; i < process.argv.length; i++) {
+    const a = process.argv[i];
+    if (a === "--summary") { args.summary = true; continue; }
+    if (a.startsWith("--")) args[a.slice(2)] = process.argv[++i];
+}
+const basePath = args.base ?? args.defaults;
+for (const [k, v] of Object.entries({ base: basePath, overrides: args.overrides, out: args.out })) {
+    if (!v) {
+        console.error(`error: --${k === "base" ? "base (or --defaults)" : k} is required`);
+        process.exit(2);
+    }
+}
+
+function readJson(p) {
+    try { return JSON.parse(fs.readFileSync(p, "utf8")); }
+    catch (e) { console.error(`error: ${p}: ${e.message}`); process.exit(2); }
+}
+
+const base = readJson(basePath);
+const overrides = readJson(args.overrides);
+
+if (base === null || typeof base !== "object" || Array.isArray(base)) {
+    console.error(`error: --base must be an object (the bare formData, not wrapped in { data: ... })`);
+    process.exit(2);
+}
+if (overrides === null || typeof overrides !== "object" || Array.isArray(overrides)) {
+    console.error(`error: --overrides must be an object (the bare formData, not wrapped in { data: ... })`);
+    process.exit(2);
+}
+
+const touched = [];
+
+function isPlainObject(v) {
+    return v !== null && typeof v === "object" && !Array.isArray(v);
+}
+
+function merge(dst, src, trail) {
+    for (const key of Object.keys(src)) {
+        const overrideVal = src[key];
+        const next = trail ? `${trail}.${key}` : key;
+        if (overrideVal === null) {
+            dst[key] = null;
+            touched.push({ path: next, op: "clear" });
+            continue;
+        }
+        if (isPlainObject(overrideVal)) {
+            if (!isPlainObject(dst[key])) dst[key] = {};
+            merge(dst[key], overrideVal, next);
+            continue;
+        }
+        if (Array.isArray(overrideVal)) {
+            dst[key] = overrideVal.slice();
+            touched.push({ path: next, op: "replace-array", size: overrideVal.length });
+            continue;
+        }
+        dst[key] = overrideVal;
+        touched.push({ path: next, op: "replace-scalar" });
+    }
+    return dst;
+}
+
+const merged = JSON.parse(JSON.stringify(base));
+merge(merged, overrides, "");
+
+fs.mkdirSync(path.dirname(path.resolve(args.out)), { recursive: true });
+fs.writeFileSync(args.out, JSON.stringify(merged, null, 2));
+process.stdout.write(`MERGED: ${path.resolve(args.out)}\n`);
+
+if (args.summary) {
+    process.stdout.write(`Overridden paths: ${touched.length}\n`);
+    const grouped = touched.slice(0, 20);
+    for (const t of grouped) {
+        process.stdout.write(`  ${t.op.padEnd(16)} ${t.path}${t.size != null ? ` (array[${t.size}])` : ""}\n`);
+    }
+    if (touched.length > 20) process.stdout.write(`  … and ${touched.length - 20} more\n`);
+}