Docs/Reference

REFERENCE / GUIDE 11

Authoring operations

Typed changesets, aliases, versions, and retries.

studio_apply_changes accepts a campaign-scoped changeset with 1–100 typed operations. Read studio_get_schema before writing: it returns the exact strict JSON Schemas, including each node type's config shape. Unknown fields fail validation.

Changeset envelope

Send campaignId, expectedEditVersion, a UUID requestId, operations, and optionally mode (preview or commit) and validation (draft or ready). The expected version comes from a recent campaign read. draft validation allows an incomplete working draft with findings; ready requires a publishable path.

Preview a changeset before committing it. The commit runs as one transaction: either all operations are accepted, or none are saved. A successful commit advances the draft version once and adds one change-history entry.

Operation families

Campaign and routing

  • campaign.update changes editable campaign fields.
  • campaign.set_entry selects the entry mission.
  • transition.connect routes a named exit to a mission or ending.
  • transition.remove removes a campaign route transition.

Missions

  • mission.create adds a mission with author and player titles, canvas position, and a default starter graph or custom graph.
  • mission.update changes titles or notes.
  • mission.remove removes a mission.
  • mission.reorder changes its zero-based order in the campaign graph.
  • mission.duplicate creates an independent copy.

With initialGraph: "default", a new mission gets Start and Mission exit nodes. If the mission operation has a ref alias, it also publishes <ref>.start and <ref>.exit aliases for subsequent operations in that batch. A custom graph must become structurally valid before commit.

Nodes, edges, and layout

  • node.create, node.update, and node.remove manage typed mission nodes.
  • node.duplicate copies a node.
  • edge.connect and edge.remove manage internal mission connections and named source ports.
  • layout.set_positions moves listed nodes without changing unlisted positions or runtime edges.

Node label, order, and authorNotes are flattened in the operation contract but stored under the node's author metadata. A node update merges supplied configuration fields with the existing configuration; inspect the live schema before writing a complex config.

Reusable resources

  • location.create, location.update, and location.remove manage locations.
  • content.create, content.update, and content.remove manage reusable content.
  • ending.create, ending.update, and ending.remove manage route endings.

Resource data is checked against the corresponding document schema. IDs and persistence timestamps are server owned. Referenced resources may be protected from removal until their uses are replaced.

Aliases and IDs

Persisted entities use UUIDs. A batch may give a created entity a lowercase ref alias and refer to it later as { "ref": "alias-name" }. Aliases exist only within that changeset. This allows one batch to create a mission, create its nodes, connect edges, and route its exit without first committing to obtain IDs.

Concurrent editing and retries

If expectedEditVersion is stale, the write returns a conflict. Re-read the campaign and affected mission, reconcile changes, and submit a new logical write. If a committed request's response was lost, retry the exact same body with the same requestId; the server can replay its recorded result. Reusing an ID for a different body is rejected.

The change journal records whether an accepted edit came from Studio or MCP. studio_list_changes lets you inspect that history.