@uipath/skills 1.195.0

package/skills/uipath-governance/references/access-policy/plugins/actor/impl.md

@@ -0,0 +1,203 @@
+# Actor Plugin — Implementation
+
+Concrete JSON for the `actorRule` block — the policy's **Actor Identity Rule**. Phase 2 reads this file to compose the `actorRule` block before assembling the top-level `PolicyDefinition` (see [planning-impl.md — Step 2](../../planning-impl.md#step-2--compose-each-block-via-plugins)). Omit the block entirely when the user expressed no identity intent.
+
+> **Required field: `values`.** Every entry under `actorRule.values[]` must include its own `values` (use `["*"]` for "all of this type"). Missing `values` returns `400 Bad Request` (Critical Rule #5). `actorRule.tags` is **never supported** — do not add a `tags` block here.
+
+> **Supported types: `User` and `Group` only** (Critical Rule #16). Robots resolve to `User` after lookup; `ExternalApplication` is not supported. See [planning.md](./planning.md) for the resolution flow.
+
+## Full `actorRule` shape
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User",  "values": ["<USER_UUID>", "..."],  "operator": "<Or | None>" },
+        { "type": "Group", "values": ["<GROUP_UUID>", "..."], "operator": "<Or | None>" }
+    ]
+}
+```
+
+### Structural constraints (Critical Rule #16)
+
+- `values[]` carries **at most two entries** — one `User` and one `Group`. Either, both, or none of those entries may be present, but never duplicates of the same type.
+- **Multiple users / groups go inside a single entry's `values[]` array** — never split across multiple entries of the same `type`.
+- **Operators must match across the two entries.** When both `User` and `Group` are present, both `operator` fields must be the same value (both `"Or"` or both `"None"`). Mixed operators are rejected by the API. Mixed-operator user intent must be split into two policies (see [planning.md — Mixed-operator intent → two policies](./planning.md#mixed-operator-intent--two-policies)).
+
+### Field rules
+
+| Field | Required | Value rules |
+|-------|----------|-------------|
+| `values` | yes | Array of at most two per-type entries (one `User`, one `Group`). At least one entry when the block is emitted. |
+| `values[].type` | yes | One of: `User`, `Group`. **Never** `ExternalApplication` or `Robot` (Critical Rule #16). Each type appears at most once across the array. |
+| `values[].values` | yes | `["*"]` or specific UUIDs. Multiple identities of the same type are listed here, not split into multiple entries. Never empty. |
+| `values[].operator` | yes | `"Or"` (include) or `"None"` (exclude). When both `User` and `Group` entries are present, this value MUST match across both entries. |
+| `tags` | **NOT SUPPORTED** | `actorRule` does not accept a `tags` block today. Never emit one. If the user wants tag-style narrowing, enumerate the matching users / groups under `values[].values` instead. |
+
+> **Whole-block emission is optional.** If the user did not mention any identity, omit the `actorRule` key from the top-level `PolicyDefinition` entirely — do NOT emit `{"values": [{"type": "User", "values": ["*"], "operator": "Or"}]}` as a default.
+
+> **No `actorRule.tags`.** Unlike `selectors[]` and `executableRule`, the Actor Identity rule does not support tag filters today. Emitting `actorRule.tags` returns `400 Bad Request` from the API.
+
+---
+
+## Worked examples
+
+### A. Single-type, specific users
+
+**Intent:** "Only users alice-uuid and bob-uuid can trigger this".
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["alice-uuid", "bob-uuid"], "operator": "Or" }
+    ]
+}
+```
+
+### B. Single-type, all of one type
+
+**Intent:** "Any user can trigger this" (no narrowing).
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["*"], "operator": "Or" }
+    ]
+}
+```
+
+> **No identity tag filter.** If the user said "any user tagged Admin", **`actorRule.tags` is not supported** — refuse and offer to (a) enumerate the admin user UUIDs under `values[].values`, (b) use a `Group` UUID for the Admins group, or (c) drop the tag filter so the rule applies to any user. Never emit `actorRule.tags`.
+
+### C. Multi-type (one User entry + one Group entry — operators match)
+
+**Intent:** "Members of the Ops group and admin users alice-uuid, bob-uuid can trigger this".
+
+Both entries are include-style, so both use `operator: "Or"` (the operator must match across `User` and `Group` per Critical Rule #16):
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User",  "values": ["alice-uuid", "bob-uuid"], "operator": "Or" },
+        { "type": "Group", "values": ["ops-group-uuid"],         "operator": "Or" }
+    ]
+}
+```
+
+**Mixed-operator intent → two policies.** If the user said "allow alice-uuid and bob-uuid **but exclude** the Ops group", the operators don't match and the API rejects it. Author two separate policies:
+
+```json
+// Policy A — allow specific users
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["alice-uuid", "bob-uuid"], "operator": "Or" }
+    ]
+}
+
+// Policy B — exclude the Ops group
+"actorRule": {
+    "values": [
+        { "type": "Group", "values": ["ops-group-uuid"], "operator": "None" }
+    ]
+}
+```
+
+**Same-type merging.** Multiple users (or multiple groups) belong in **one** entry's `values[]` array. Do NOT emit two `User` entries — merge their UUIDs:
+
+```json
+// CORRECT — single User entry with multiple UUIDs
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["alice-uuid", "bob-uuid", "carol-uuid"], "operator": "Or" }
+    ]
+}
+
+// WRONG — duplicate User entries (rejected by the API)
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["alice-uuid"], "operator": "Or" },
+        { "type": "User", "values": ["bob-uuid"],   "operator": "Or" }
+    ]
+}
+```
+
+### D. Deny-flipped actor
+
+**Intent (original):** "block user alice-uuid". **Flipped to Allow** with the `None` operator:
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["alice-uuid"], "operator": "None" }
+    ]
+}
+```
+
+This allows every User **except** `alice-uuid`. (See [../tags/planning.md — Deny-to-Allow flip](../tags/planning.md#deny-to-allow-flip) for the decision procedure.)
+
+### E. Robot-only trigger (resolves to `User`)
+
+**Intent:** "Only the unattended robot `build-bot` can trigger this".
+
+Resolution flow: look up `build-bot` via [resource-lookup-guide.md § Robots](../../resource-lookup-guide.md#robots-resolve-to-type-user) — the returned `id` becomes `bot-user-uuid` below. Then emit:
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["bot-user-uuid"], "operator": "Or" }
+    ]
+}
+```
+
+> Never emit `{ "type": "Robot", ... }`. The server rejects it as an unknown type, and the policy authoring contract does not support it (Critical Rule #16).
+
+---
+
+## Update-flow use
+
+When `policy-manage-guide.md — Update` needs to modify an existing `actorRule`:
+
+1. Start from the working file's current `actorRule` object (or absence — "add identity constraint" means inserting the block fresh).
+2. Change only the part the user asked about (add a type, add a UUID, flip an operator, adjust `tags`).
+3. Preserve every other field.
+
+Example: existing rule allows specific admin users; user says "also allow members of the Ops group".
+
+Before:
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User", "values": ["alice-uuid", "bob-uuid"], "operator": "Or" }
+    ]
+}
+```
+
+After:
+
+```json
+"actorRule": {
+    "values": [
+        { "type": "User",  "values": ["alice-uuid", "bob-uuid"], "operator": "Or" },
+        { "type": "Group", "values": ["ops-group-uuid"],         "operator": "Or" }
+    ]
+}
+```
+
+> **No `actorRule.tags`.** If you find a legacy `actorRule.tags` block on a policy fetched via `get`, drop it from the working file before submitting the update — emitting it returns `400 Bad Request` (see Debug table below).
+
+Removing the block entirely: drop the `actorRule` key from the working file (do not set it to `null` or `{}`).
+
+---
+
+## Debug
+
+| Error / signal | Cause | Fix |
+|----------------|-------|-----|
+| `400 Bad Request` / `ActorRule.Values is required` | `actorRule.values` empty or missing while block is present | Remove the `actorRule` key entirely, or include at least one entry. |
+| `400 Bad Request` / unknown actor `type` | Typo, or emitted `Robot` / `ExternalApplication`, or a resource type like `Agent` / `APIWorkflow` | Use exactly one of `User`, `Group`. Robot intent must be resolved to a `User` UUID first (Critical Rule #16). |
+| `400 Bad Request` / duplicate `type` in `actorRule.values` | Emitted two `User` entries (or two `Group` entries) | Merge them into a single entry whose `values[]` lists every UUID. `actorRule.values[]` carries at most one entry per type (Critical Rule #16). |
+| `400 Bad Request` / mismatched operators in `actorRule.values` | The `User` entry uses `operator: "Or"` and the `Group` entry uses `operator: "None"` (or vice versa) | Operators must match across both entries (Critical Rule #16). For mixed-include/exclude intent, split into two policies (see Worked Example C). |
+| `400 Bad Request` on `type: Group` | Server build does not accept `Group` | Fall back to enumerating member user UUIDs under a single `type: User` entry. Report the limitation. |
+| `400 Bad Request` / `Values is required` on a per-entry field | An entry's own `values` is empty | Use `["*"]` or specific UUIDs — never `[]`. |
+| Policy never matches the intended actor | Actor UUID not in `values` | Log in as that user (`uip login`) and run `uip gov access-policy evaluate --resource-type <TYPE> --output json` — the calling user is taken from the bearer. (Under an S2S token, pass `--actor-identity-id <UUID>` instead.) |
+| `400 Bad Request` referencing `tags` on `actorRule` | Emitted an `actorRule.tags` block (or kept one inherited from a fetched policy) | Remove the `tags` key from `actorRule` — Actor Identity does not support tag filters today (Spec rules / Critical Rule #5). Enumerate matching users / groups under `values[].values` instead. |
+| Evaluation returns Deny even though selectors + executable match | `actorRule` is present and the caller's identity falls outside `values` | Check whether the block should be present at all; omit it if the user never asked for identity enforcement. |

package/skills/uipath-governance/references/access-policy/plugins/actor/planning.md

@@ -0,0 +1,178 @@
+# Actor Identity Plugin — Planning
+
+> **User-facing terminology vs JSON field.** The user-facing name for this block is **Actor Identity rule**. The underlying JSON field is `actorRule` — that name is only shown in code / CLI contexts. When summarizing the policy to the user, always say "Actor Identity rule", never "Actor rule".
+
+The `actorRule` block is the policy's **Actor Identity Rule** — it identifies **who** (which user or group) is allowed (or blocked) from triggering the Actor Process that invokes the Resource. The access policy has at most one `actorRule` block, which can hold at most two entries — one `User` and one `Group` (Critical Rule #16).
+
+> **Supported types: `User` and `Group` only** (Critical Rule #16). `ExternalApplication` is **not supported** today; reject any intent that names a service principal / registered app and route the user to use a User or Group instead, or to omit Actor Identity entirely. **Robot intent maps to `User`** — look up the robot via [resource-lookup-guide.md § Robots](../../resource-lookup-guide.md#robots-resolve-to-type-user) and emit a `User`-typed entry. Never emit `type: "Robot"` or `type: "ExternalApplication"`.
+
+> **Terminology recap.** The access policy has three rule parts:
+> - **Selection Rule** → `selectors[]` — which Resource/Tool the policy applies to.
+> - **Actor Process Rule** → `executableRule` — which executable workflow is calling the Resource.
+> - **Actor Identity Rule** → `actorRule` — which user or group is triggering the Actor Process.
+>
+> All three must pass for the evaluation result to be Allow. See [../../access-policy-overview-guide.md](../../access-policy-overview-guide.md) for the full evaluation flow.
+
+## When to Use
+
+Emit `actorRule` **only when the user expressed actor-identity intent**. If the user did not mention a user, group, or robot identity, omit the block entirely — absence of `actorRule` means "any actor passes the identity check".
+
+## When intent is actor-shaped
+
+Flag these phrases during Phase 1 and route them to this plugin:
+
+- "only admins can…", "only user X can…"
+- "restrict user X from…", "block user Y from…"
+- "members of group G can…", "users in group Z can…"
+- "on behalf of actor X…"
+- "when robot R triggers…" (resolves to `User` — see [Robot intent](#robot-intent-resolves-to-user))
+
+If the user names an external application / service principal / S2S app / registered app, **stop and tell them** that `ExternalApplication` is not supported today (Critical Rule #16). Offer the workarounds:
+- Use a `User` (the user account the app authenticates as), or
+- Use a `Group` containing the app's identity, or
+- Omit the Actor Identity rule entirely so the policy applies regardless of identity.
+
+## Block shape (conceptual)
+
+```text
+actorRule = {
+    values: [
+        { type: "User",  values: [<user_uuid>, <user_uuid>, ...],   operator: <Or | None> },
+        { type: "Group", values: [<group_uuid>, <group_uuid>, ...], operator: <Or | None> }
+    ]
+}
+```
+
+Strict structural constraints (Critical Rule #16):
+
+- `actorRule.values[]` carries **at most two entries** — at most one `User` entry and at most one `Group` entry. Never duplicate entries of the same type.
+- **Multiple users / groups go inside a single entry's `values[]` array**, not as multiple entries. If the user names three admin users plus the Ops group, that is one `User` entry (with three UUIDs) plus one `Group` entry (with one UUID) — two entries total.
+- **Operators must match across `User` and `Group`.** When both entries are present, their `operator` must be the same value (both `Or`, or both `None`). Mixing `Or` on one and `None` on the other is invalid — the API rejects it. If the user expresses mixed intent (e.g. "allow these users but exclude this group"), split into **two policies**: one with the `User` entry (operator `Or`) and one with the `Group` entry (operator `None`).
+- **No `tags` block.** Unlike `selectors[]` and `executableRule`, `actorRule` does **not** support `tags` today. If the user asks for an identity tag filter, refuse and offer to enumerate the matching users / groups directly under `values[]`, or to drop the tag filter entirely.
+
+## Intent → actor identity type
+
+Map the user's phrasing to the enum.
+
+| User phrase | `type` |
+|-------------|--------|
+| "user X", "specific person", "admin Alice" | `User` |
+| "group G", "members of group", "role X" | `Group` |
+| "robot R", "unattended robot", "attended robot" | `User` (resolve via [Robot intent](#robot-intent-resolves-to-user)) |
+| "external application", "service account", "S2S app", "registered app" | **Not supported** — reject and offer workarounds (see [When intent is actor-shaped](#when-intent-is-actor-shaped)). |
+
+## Targeting modes
+
+Same two modes as selectors and executables:
+
+| Mode | `values` | `operator` |
+|------|----------|------------|
+| **All of this type** | `["*"]` | `Or` |
+| **Specific IDs** | `["<UUID>", ...]` | `Or` |
+| **Exclude specific IDs** | `["<UUID>", ...]` | `None` |
+
+`values: ["*"]` is required on every entry (Critical Rule #5). Missing it returns `400`.
+
+### Resolving Actor Identity names to UUIDs
+
+If the user named a specific identity ("only Alice", "members of group Ops"), resolve the name to a UUID via [resource-lookup-guide.md](../../resource-lookup-guide.md):
+
+- **User** → [resource-lookup-guide.md § Users](../../resource-lookup-guide.md#3-users-actor-identity-uuids). For "only me" intent, the agent must prompt for the user's email/display name first (no `current` shortcut available).
+- **Group** → [resource-lookup-guide.md § Groups](../../resource-lookup-guide.md#groups-uip-admin-fallback). Surface as an **Open question** on the Phase 1 Spec only when both the admin lookup and the user cannot supply a GUID.
+
+Present matched users as a numbered picker. Never silently pick the first row.
+
+### Robot intent resolves to `User`
+
+A robot in UiPath identity is **a kind of user** (Critical Rule #16). When the user says "robot R can trigger…":
+
+1. Look up the robot via [resource-lookup-guide.md § Robots](../../resource-lookup-guide.md#robots-resolve-to-type-user). The returned `id` is the identity UUID the policy server expects.
+2. Emit `{ "type": "User", "values": ["<ROBOT_ID>"], "operator": "Or" }` — never `type: "Robot"`.
+
+If the lookup returns nothing, ask the user to confirm the robot name or supply the UUID from the Admin portal — do not invent.
+
+## Multi-type actor rules
+
+`actorRule.values[]` holds **at most two entries** — one `User` and one `Group`. Same-type identities are merged into a single entry's `values[]` array, never duplicated as separate entries.
+
+### Single-`User`-entry merging (users + robots in one entry)
+
+If the user says "users alice-uuid, bob-uuid, and the build-bot robot can trigger…", these are **all `User`** in the JSON (Critical Rule #16 — robots resolve to `User`). Resolve the robot to its linked User UUID, then merge all three into one `User` entry — never emit two `User` entries:
+
+```text
+actorRule:
+  values:
+    1. type: User, values: ["alice-uuid", "bob-uuid", "<bot-user-uuid>"], operator: Or
+```
+
+### Two-type case (operators must match)
+
+If the user says "admins **and** members of group Ops can trigger…", emit one `User` entry plus one `Group` entry — both with the **same** operator:
+
+```text
+# CORRECT — both entries use operator: Or
+actorRule:
+  values:
+    1. type: User,  values: ["<ADMIN_UUID>", ...], operator: Or
+    2. type: Group, values: ["<OPS_GROUP_UUID>"],  operator: Or
+```
+
+The pattern below is **rejected by the API** (mismatched operators across the two entries):
+
+```text
+# REJECTED — User uses Or, Group uses None — API returns 400 Bad Request
+actorRule:
+  values:
+    1. type: User,  values: ["<ADMIN_UUID>"],     operator: Or       # ← include
+    2. type: Group, values: ["<OPS_GROUP_UUID>"], operator: None     # ← exclude (mismatch)
+```
+
+To express that mixed intent, split into two policies — see [Mixed-operator intent → two policies](#mixed-operator-intent--two-policies) below.
+
+### Mixed-operator intent → two policies
+
+If the user wants to **allow** specific users but **exclude** a group (or vice versa), the operators don't match — that cannot be expressed in a single `actorRule`. Split into two policies and tell the user:
+
+- Policy A: `actorRule.values: [{ type: "User", values: [...], operator: "Or" }]`
+- Policy B: `actorRule.values: [{ type: "Group", values: [...], operator: "None" }]`
+
+There is no `actorRule.tags` block — tags are not supported on Actor Identity today. To narrow within a type, list the specific UUIDs.
+
+## Deny-flipped actor intent
+
+"**Deny** user Alice from triggering this resource" must be expressed as Allow with `operator: None` (Critical Rule #2 — `enforcement: "Deny"` is not authorable):
+
+```text
+actorRule:
+  values:
+    1. type: User, values: ["<ALICE_UUID>"], operator: None    # allow all Users except Alice
+```
+
+"Only admins" is already positive — emit `operator: Or` with the admin user UUIDs (or a `Group` UUID for the Admins group). Identity tag filters are not supported on `actorRule`; if the user wants tag-style narrowing, enumerate the matching users / groups directly. See [../tags/planning.md — Deny-to-Allow flip](../tags/planning.md#deny-to-allow-flip) for the general flip pattern (which still applies to Resource and Actor Process tag filters).
+
+## When NOT to emit `actorRule`
+
+- The user said nothing about identity. Omit the block — do not default to `["*"]` on `User`, because that would still evaluate the block. Absence is semantically "no identity constraint".
+- The user's intent is actually a **tag on the executable** ("only admin-launched Agents" — emit `executableRule.tags` instead; see [../executable/planning.md](../executable/planning.md)).
+- The user asked for an **identity tag filter** ("any user tagged Admin"). Tags are not supported on `actorRule` today — refuse and offer to enumerate the matching users / groups, or drop the tag filter.
+- The user is asking for per-user access on a **non-ToolUsePolicy** policy type. This skill only mutates `ToolUsePolicy`; stop and tell them.
+
+## Relationship with Actor Process (executable) and Selection (selectors)
+
+Identity gates the **trigger**. The executable rule gates the **caller workflow**. The selector gates the **target resource**. These compose as AND — every rule present must pass for the evaluation to return Allow. See [planning-arch.md § The three rule blocks](../../planning-arch.md#the-three-rule-blocks-boundary-table) for the boundary table.
+
+## Anti-patterns
+
+- Do NOT emit `actorRule` when the user did not mention identity. An empty-but-present `actorRule` can still filter out actors that don't satisfy `["*"]` semantics.
+- Do NOT put resource or executable types (`RPAWorkflow`, `APIWorkflow`, `Agent`, `AgenticProcess`, `CaseManagement`, `Flow`) in `actorRule.values[].type` — this block is for **identity** types only. See [planning-arch.md § The three rule blocks](../../planning-arch.md#the-three-rule-blocks-boundary-table) for the boundary.
+- Do NOT emit `type: "Robot"` or `type: "ExternalApplication"`. Robot intent resolves to `User`; ExternalApplication is not supported.
+- Do NOT use `operator: And` on `values` — only `Or` / `None`.
+- Do NOT emit duplicate entries of the same type (Critical Rule #16). Two `User` entries or two `Group` entries → merge into one entry with all UUIDs in its `values[]` array.
+- Do NOT mix operators across `User` and `Group` entries (Critical Rule #16). When both entries are present, their `operator` must be the same value. Mixed intent ("allow these users, exclude that group") splits into two policies.
+- Do NOT emit more than two entries in `actorRule.values[]`. The maximum is one `User` entry plus one `Group` entry.
+- Do NOT invent identity types beyond `User | Group`.
+- Do NOT emit `actorRule.tags`. The Actor Identity rule does not support tag filters today.
+
+## Next: compose the JSON
+
+When Phase 2 needs the concrete JSON for the `actorRule` block, read [actor/impl.md](./impl.md).

package/skills/uipath-governance/references/access-policy/plugins/executable/impl.md

@@ -0,0 +1,167 @@
+# Executable Plugin — Implementation
+
+Concrete JSON for the `executableRule` block. Phase 2 reads this file to compose the single `executableRule` block before assembling the top-level `PolicyDefinition` (see [planning-impl.md — Step 2](../../planning-impl.md#step-2--compose-each-block-via-plugins)).
+
+> **Required field: `values`.** Every entry under `executableRule.values[]` must include its own `values` (use `["*"]` for "all of this type") — it cannot be omitted, even when the shared `executableRule.tags` narrow the scope. Missing `values` returns `400 Bad Request` (Critical Rule #5).
+
+## Full `executableRule` shape
+
+```json
+"executableRule": {
+    "values": [
+        {
+            "type": "<Agent | AgenticProcess | CaseManagement | Flow>",
+            "values": ["*"],
+            "operator": "<Or | None>"
+        }
+    ],
+    "tags": {
+        "values": ["<TAG_1>"],
+        "operator": "<Or | And | None>"
+    }
+}
+```
+
+### Field rules
+
+| Field | Required | Value rules |
+|-------|----------|-------------|
+| `values` | yes | Array of per-type entries. At least one entry. **Caller types not listed in `values[]` are NoOp on this policy** — this policy does not constrain them. Use this directly to author "any caller type except `<type>`" intent: list ONLY the excluded type with `operator: "None"` and omit the others. See [Example E](#e-all-caller-types-except-a-specific-type-canonical-idiom). |
+| `values[].type` | yes | One of: `Agent`, `AgenticProcess`, `CaseManagement`, `Flow`. NOT `RPAWorkflow` or `APIWorkflow`. |
+| `values[].values` | yes | `["*"]` or specific UUIDs. Never empty. |
+| `values[].operator` | yes | `"Or"` (include) or `"None"` (exclude). On a `["*"]` entry, `"None"` means "match any caller of types other than this entry's `type`". |
+| `tags` | optional | Omit entirely when there are no tag constraints. When present, compose via [tags/impl.md](../tags/impl.md). Applies to every entry in `values[]`. |
+
+---
+
+## Worked examples
+
+### A. Single-type, all-of-type, with tag filter
+
+**Intent:** "Production Maestros can use the resource".
+
+```json
+"executableRule": {
+    "values": [
+        { "type": "AgenticProcess", "values": ["*"], "operator": "Or" }
+    ],
+    "tags": {
+        "values": ["Production"],
+        "operator": "Or"
+    }
+}
+```
+
+### B. Single-type, specific UUIDs, no tag filter
+
+**Intent:** "The Maestro with ID def-456 can use the resource".
+
+```json
+"executableRule": {
+    "values": [
+        { "type": "AgenticProcess", "values": ["def-456"], "operator": "Or" }
+    ]
+}
+```
+
+(`tags` omitted.)
+
+### C. Multiple executable types in one rule
+
+**Intent:** "Both Agents and Maestros can use the resource, but only Production ones".
+
+```json
+"executableRule": {
+    "values": [
+        { "type": "Agent",          "values": ["*"], "operator": "Or" },
+        { "type": "AgenticProcess", "values": ["*"], "operator": "Or" }
+    ],
+    "tags": {
+        "values": ["Production"],
+        "operator": "Or"
+    }
+}
+```
+
+The `tags` block applies to both entries.
+
+### D. Deny-flipped executable
+
+**Intent (original):** "block Development Flows from using the resource". **Flipped to Allow** with the `None` operator on the executable's tags:
+
+```json
+"executableRule": {
+    "values": [
+        { "type": "Flow", "values": ["*"], "operator": "Or" }
+    ],
+    "tags": {
+        "values": ["Development"],
+        "operator": "None"
+    }
+}
+```
+
+This allows every Flow **except** Development-tagged ones.
+
+### E. All caller types except a specific type (canonical idiom)
+
+**Intent:** "Any caller can use the resource except `Agent` callers" — i.e. allow `AgenticProcess`, `CaseManagement`, and `Flow` callers but not `Agent` callers.
+
+```json
+"executableRule": {
+    "values": [
+        { "type": "Agent", "values": ["*"], "operator": "None" }
+    ]
+}
+```
+
+Emit ONE entry — the caller type to exclude — with `operator: "None"` and `values: ["*"]`. Caller types not listed (`AgenticProcess`, `CaseManagement`, `Flow`) are NoOp on this filter, so this policy does not constrain them. Combined with `enforcement: "Allow"`, the policy contributes Allow for any non-`Agent` caller.
+
+> **Use this idiom whenever the intent is "any caller type except `<type>`".** Do NOT enumerate every allowed type with `Or` — that produces the same effect but is verbose, error-prone, and obscures the intent. Listing only the excluded type with `None` is the canonical shape.
+
+---
+
+## Update-flow use
+
+When `policy-manage-guide.md — Update` needs to modify the existing `executableRule`:
+
+1. Start from the working file's current `executableRule` object.
+2. Change only the part the user asked about (add a type, add a UUID to an entry's `values`, flip an operator, adjust `tags`).
+3. Preserve every other field.
+
+Example: the user says "also allow CaseManagement". Existing `executableRule`:
+
+```json
+{
+    "values": [
+        { "type": "AgenticProcess", "values": ["*"], "operator": "Or" }
+    ],
+    "tags": { "values": ["Production"], "operator": "Or" }
+}
+```
+
+After update:
+
+```json
+{
+    "values": [
+        { "type": "AgenticProcess",  "values": ["*"], "operator": "Or" },
+        { "type": "CaseManagement",  "values": ["*"], "operator": "Or" }
+    ],
+    "tags": { "values": ["Production"], "operator": "Or" }
+}
+```
+
+Only `values[]` changed — `tags` is preserved verbatim.
+
+---
+
+## Debug
+
+| Error | Cause | Fix |
+|-------|-------|-----|
+| `400 Bad Request` / `ExecutableRule.Values is required` | `executableRule.values` missing or empty | Include at least one entry with `type` and `values`. |
+| `400 Bad Request` / unknown executable `type` | Tried `RPAWorkflow` or `APIWorkflow` | These are resource-only. Move them to `selectors[]`. |
+| `400 Bad Request` / `Values is required` on a per-entry field | An entry's own `values` is missing | Use `["*"]` or specific UUIDs — never an empty array. |
+| Policy never matches the intended caller | Caller's tags don't include the tag values in `executableRule.tags`, or caller UUID isn't in `values` | Verify the Resource Catalog tags on the executable, or use `["*"]` + tag filter. |
+| Two different executable types need different tag filters | Tried to put `tags` on a single `values[]` entry | Not supported — split the intent into two policies, one per executable type. |