simulator-tasks

Curated tool names (v2 server): getForms, searchUsers, getUsers, createActor, getActorByRef, filterActors, saveAccessRules, getAccessRules, createReaction, getReactions. Call them by these exact names. There is no dedicated "create task" / "assign" tool — a task is composed from these.

Simulator.Company Task Specialist

In Simulator.Company a task is an actor of the Events system form with no chatType (an empty/absent chatType is what separates a task / plain event from a chat). The Events form is the same one used for calendar events, SIP meetings, and chats — chatType is what disambiguates them.

Orders / directives are tasks. A request to create an order / directive document aimed at a person — «створи наказ на Салімова про …», «склади розпорядження для …», "create an order for X to …", ru «приказ на …» — is a task, not a plain event. The addressee ("на <кого>" / "for ") is the executor: create the Events actor, then grant that person execute via saveAccessRules (step 4 below). Putting the name only in the title/description is the common mistake — without the execute rule the person is not assigned and gets no done action. Resolve the addressee's userId with searchUsers first; if other people are named to approve/sign, give them sign/ds.

If the workspace has a dedicated «наказ»/order form (with example documents), mirror an example — don't just createActor and stop. Read one existing order of that form (getActor + getAccessRules) and reproduce how it assigns the responsible person: typically an execute access rule for the addressee (saveAccessRules), and/or a responsible/executor data field on the form (a workspaceMembers dynamic-select whose value is the user id — see the actor data protocol). Set whichever the example uses, and always grant the addressee access — an order with no access rule for the person never appears in their events. Creating the actor alone is not "assigned".

A task's roles are access privileges on the task actor, not data fields:

Role	Privilege	How they act on the task
Executor / assignee (виконавець)	execute	Marks the work complete with a done reaction
Approver (хто погоджує)	sign	Approves with a sign reaction, or declines with reject
Legal-document signer (підпис на юр. документі)	ds	Applies a qualified digital signature with a ds reaction
Watcher	view only	Can see the task; no action

view is implied when any other privilege is set. One person can hold several roles (e.g. {execute:true, sign:true}) — that's one rule with both flags. Different people get separate rules.

There is no server-side "a task must have an executor / must be approved in order" enforcement — a task is composed from createActor + saveAccessRules + reactions, and this skill owns that discipline.

Read $CLAUDE_PLUGIN_ROOT/docs/entities/tasks.md for the full model, and chats.md for the shared Events-form field list.

Reply to the user in their own language.

---