Update to Simulator.Company

{
  "description": "Simulator.Company access-control specialist — who can view/modify/remove/sign/execute an object (actor, form, account, template, tree layer). Use when the user wants to share or unshare an object, grant or revoke permissions, list who has access, or bulk-share. Activate when the user says \"share this with\", \"give access to\", \"grant permission\", \"revoke access\", \"who can see/edit this\", \"set permissions\", \"make read-only\", \"поділись з\", \"надай доступ\", \"забери доступ\", \"хто має доступ\", \"права доступу\", \"дай доступ\", \"открой доступ\", \"отзови доступ\", \"кто имеет доступ\", \"права доступа\". Also activate when a tool fails because the caller has NO access to an object — \"request access\", \"I can't see this actor\", \"access denied\", \"403\", \"no permission\", \"запроси доступ\", \"немає доступу\", \"немає прав\", \"відмовлено в доступі\", \"запроси доступ\", \"нет доступа\", \"доступ запрещён\". For the object's own data use the domain skill (`simulator-actors` / `simulator-forms` / `simulator-finance`).\n",
  "included_files": [],
  "name": "simulator-access",
  "skill_md_contents": "---\nname: simulator-access\ndescription: >\n  Simulator.Company access-control specialist — who can view/modify/remove/sign/execute an\n  object (actor, form, account, template, tree layer). Use when the user wants to share or\n  unshare an object, grant or revoke permissions, list who has access, or bulk-share. Activate\n  when the user says \"share this with\", \"give access to\", \"grant permission\", \"revoke access\",\n  \"who can see/edit this\", \"set permissions\", \"make read-only\", \"поділись з\", \"надай доступ\",\n  \"забери доступ\", \"хто має доступ\", \"права доступу\", \"дай доступ\", \"открой доступ\",\n  \"отзови доступ\", \"кто имеет доступ\", \"права доступа\". Also activate when a tool fails because\n  the caller has NO access to an object — \"request access\", \"I can't see this actor\",\n  \"access denied\", \"403\", \"no permission\", \"запроси доступ\", \"немає доступу\", \"немає прав\",\n  \"відмовлено в доступі\", \"запроси доступ\", \"нет доступа\", \"доступ запрещён\". For the object's\n  own data use the domain skill (`simulator-actors` / `simulator-forms` / `simulator-finance`).\n---\n\n> **Curated tool names (v2 server):** `getAccessRules`, `saveAccessRules`,\n> `getTemplateActorsAccess`, `saveTemplateActorsAccess`, `getTreeLayerAccess`,\n> `saveTreeLayerAccess`, `bulkSaveAccessRules`, `bulkSaveAccountPairsAccessRules`,\n> `requestAccess`. Call them by these exact names.\n\n# Simulator.Company Access-Control Specialist\n\nAccess rules say **who** (a user, SA user, or group) can do **what** (view / modify / remove /\nsign / ds / execute) to an **object**. Grants are applied **asynchronously** — save calls\nreturn a **`taskId`**.\n\n## The model\n\n- **objType** — one of `actor`, `form`, `account`, `formTemplate`, `templateActors`, `treeLayer`.\n- **objId** — the target object's id (actor UUID, or numeric form/account id as a string).\n- **rules** — a JSON **array** of operations: `{action, data}` where `action ∈ create | update | delete`.\n- **data** — identifies the grantee by **exactly one** of `userId` | `saId` | `groupId`, plus:\n  - **privs** — `{view, modify, remove (required booleans), sign?, ds?, execute?}`. `view` is\n    implied when any other privilege is set.\n  - **reactionOrders?** — `{sign, ds, execute}` positive integers ordering those reactions\n    (same number = parallel, higher waits for lower). **Optional** — pass it only to set a\n    sequence. A user holding `sign`/`ds`/`execute` without an order still counts toward task\n    completion; once anyone on the object has an order, such a user acts after the ordered users\n    of that stage. On `update` of an actor's own access, resend `reactionOrders` to keep the\n    sequence — omitting it clears the stored order. A graph/layer cascade never touches\n    `sign`/`ds`/`execute` or their orders on the actors inside.\n- **recursive** (default **true**) — cascade to child objects. Set **false** to apply to this object only.\n- **notify** (default **true**) — send access-change notifications. Set **false** to apply quietly.\n\n> `recursive`/`notify` default to true; the tools send an explicit `false` when you set it, so an\n> opt-out is honoured. \"Grant but don't cascade to children\" ⇒ `recursive=false`.\n\n## Workspace context\n\nObjects are addressed by their own id (`objId`), so most tools need no `accId`. Only\n`bulkSaveAccountPairsAccessRules` takes an `accId` (defaults to the configured workspace).\n\n## Finding the grantee (`userId` / `groupId`)\n\nA rule's grantee is identified by a real `userId` (or `saId` / `groupId`) — resolve it first,\nnever guess:\n\n- **`searchUsers(accId, query)`** — find a workspace member by name/email (the quickest path).\n- **`getUsers(accId)`** — list all members.\n- **`getUser(accId, userId, type=\"group\")`** — resolve a group id when sharing with a group.\n\n> **Share onto the `user`, never their twin actor.** Each user has a 1:1 digital-twin actor,\n> but access is granted to the **`userId`** — pass `userId` in the rule's `data`, not the twin\n> actor's id. The twin actor is for *transactions / accounts / graph placement*\n> (`getSystemActor`), not for sharing. See `$CLAUDE_PLUGIN_ROOT/docs/entities/users.md`.\n\n---\n\n## Read who has access\n\n```\ngetAccessRules(objType=\"actor\", objId=\"<actor UUID>\")      # actor | form | account | formTemplate | treeLayer\ngetTemplateActorsAccess(objId=\"<form-template id>\")        # the actors of a form template\ngetTreeLayerAccess(objId=\"<layer / root actor id>\")        # the actors on a tree layer\n```\n\n## Grant / change / revoke\n\n```\n# Give user 4210 view + modify on an actor, but not delete:\nsaveAccessRules(objType=\"actor\", objId=\"<actor UUID>\", rules=[\n  { \"action\": \"create\", \"data\": {\n      \"userId\": 4210,\n      \"privs\": { \"view\": true, \"modify\": true, \"remove\": false } } }\n])\n\n# Revoke a group's access to an account entirely:\nsaveAccessRules(objType=\"account\", objId=\"<account id>\", rules=[\n  { \"action\": \"delete\", \"data\": { \"groupId\": 88 } }\n])\n\n# Apply to this object only (don't cascade) and stay quiet:\nsaveAccessRules(objType=\"actor\", objId=\"<UUID>\", recursive=false, notify=false, rules=[ … ])\n```\n\n`saveTemplateActorsAccess(objId=<form-template id>, rules=[…])` and\n`saveTreeLayerAccess(objId=<layer id>, rules=[…])` take the same `rules` shape for the\ntemplate-actor and tree-layer scopes.\n\n## Bulk\n\n```\n# Many objects at once (≤50), each with its own rules:\nbulkSaveAccessRules(items=[\n  { \"objType\": \"form\", \"objId\": \"42\", \"rules\": [ … ] },\n  { \"objType\": \"actor\", \"objId\": \"<UUID>\", \"rules\": [ … ] }\n])\n\n# Share a whole account-name category across the workspace (every account named <prefix>_*):\nbulkSaveAccountPairsAccessRules(accId=\"ws_xxx\", items=[\n  { \"objId\": \"<account-name id prefix>\", \"rules\": [ … ] }\n])\n```\n\n---\n\n## Requesting access (when YOU can't see an object)\n\nMid-task a tool may fail with **403 / Access Denied** (or `getActor` etc. returns not-found)\nbecause the current user has **no `view` access** to that object. Don't give up or guess —\nask the owner for access with **`requestAccess`**:\n\n```\nrequestAccess(objType=\"actor\", objId=\"<actor UUID>\")          # request view access\nrequestAccess(objType=\"actor\", objId=\"<actor UUID>\", modify=true)   # request view + edit\n```\n\n- `requestAccess` does **not** grant access — it raises a request to the object's **owner(s)**\n  (creates a REQUEST_ACCESS invite + a request-access event they can approve/decline). You then\n  have to wait for approval before the blocked operation will work.\n- **Idempotent:** a pending request for the same object is reused, not duplicated — calling it\n  again is safe and returns the existing invite + `requestEventId`.\n- You do **not** need access to the object to call it (it's the one access tool that works\n  without `view`). `objType` is usually `actor`; it also accepts `form` / `account` / template\n  / `treeLayer`.\n- This is the **requesting** side. **Approving** a request is the owner granting access — i.e.\n  a normal `saveAccessRules(... privs:{view:true})` on the object (or the owner acts on the\n  request-access event in the UI).\n\n> When a read/write step is blocked by access, tell the user it's blocked, call `requestAccess`,\n> and report that approval is pending — rather than failing silently or inventing data.\n\n---\n\n## Tips\n\n- A save returns a **`taskId`** (applied async); the change may take a moment to fully propagate.\n- Identify the grantee by **exactly one** of `userId` / `saId` / `groupId`.\n- `privs.view/modify/remove` are required; `sign`/`ds`/`execute` optional. Setting any privilege implies `view`.\n- `reactionOrders` is optional — a single executor needs only `execute:true`.\n- `recursive=false` ⇒ this object only; `notify=false` ⇒ no notifications (both honoured).\n- **Blocked by access?** Use `requestAccess(objType, objId)` — it asks the owner (doesn't grant); approval is needed before retrying. It's the one access tool callable without `view`.\n- Use `action:\"delete\"` (grantee id only) to revoke; `create`/`update` to grant or change.\n- Resolve user/group ids first (don't guess) — grantees must belong to the workspace or the rule is rejected.\n"
}