studio-assistant-act-guide

name	studio-assistant-act-guide
description	Explains the current DOT Studio Act contract: participants, relations, subscriptions, actRules, safety, and publish-safe field boundaries. Use for Act contract, relation, subscription, and runtime guardrail questions. For role split/topology decisions, load studio-assistant-workflow-guide.
compatibility	Designed for the DOT Studio built-in assistant projection.

Act Contract Guide

Use this skill when the user asks about Act structure, relation fields, subscriptions, actRules, safety, or contract-correct Act mutations.

Mental Model

• An Act is participant choreography.
• Workspace Acts, canonical Act assets, runtime definitions, and runtime thread state are different layers.
• Assistant mutations operate on the Studio workspace layer but should still aim for publishable structure.

Contract Facts

• Participants are keyed records in Studio workspace state.
• Canonical Act assets use participant key plus Performer URNs, not workspace performerRef.
• Relations use between: [sourceKey, targetKey], direction, name, and description.
• For one-way, relation order matters.
• Opposite one-way relations are valid as separate relations.
• Participant subscriptions use messagesFrom, messageTags, callboardKeys, and eventTypes.
• eventTypes currently supports only runtime.idle.
• Use callboardKeys as the canonical field name.

Relation Rules

• A multi-participant workflow Act should have at least one relation unless the user explicitly asks for an unconnected group.
• Every new relation needs source, target, direction, non-empty name, and non-empty description.
• Use source... and target... locator fields in assistant payloads, not legacy from... or to....
• Relation direction should follow real work, authority, approval, or escalation flow.
• Relation names should name the artifact or coordination moment, such as research brief, review notes, or launch handoff.
• Avoid generic relation names like handoff, sync, or collaboration.

actRules, Safety, And Subscriptions

• Use actRules for durable whole-team behavior.
• Put participant-specific focus in the linked Performer description.
• Put runtime caps, loop limits, quiet windows, and thread deadline behavior in safety.
• safety.threadTimeoutMs is a runtime limit, not a participant wake.
• Participant subscriptions are wake filters, not permissions.
• Add subscriptions only for concrete wake behavior.
• Align messageTags and callboardKeys with concrete handoffs.

Runtime Waiting Vocabulary

• Use wait_until condition names message_received, board_key_exists, wake_at, all_of, and any_of.
• wake_at is the scheduled self-wake condition name.
• Do not call scheduled waits timeout.

Legacy Fields To Avoid

• participant id
• relation permissions
• relation maxCalls
• relation timeout
• relation sessionPolicy

Self-Check

• Load studio-assistant-action-surface-guide before emitting payloads.
• If a new Act has multiple participants and represents a workflow/team, include at least one relation.
• Keep relation payloads contract-correct and publish-safe.