Your game.
Your next build.

Start from completed files

Prepare a build from your repository.

Download and verify bundlepack for Linux or WSL. Build your frontend and generate your published math with your existing tools, then stop anything writing to those output folders. Select the source, frontend, math and notices you want to include.

{
  "schemaVersion": 1,
  "project": {
    "game": "nebula",
    "rgsGameId": "nebula_rgs",
    "revision": 1,
    "parentSHA256": "",
    "sourceStaticPrefix": "source/frontend",
    "mathIndex": "math/publish_files/index.json",
    "modes": [{"name": "base", "costX100": 100,
      "eventTypes": ["reveal", "finalWin"]}]
  },
  "frontend": "dist",
  "math": "library/publish_files",
  "source": ["src", "package.json", "pnpm-lock.yaml"],
  "notices": ["NOTICE.txt"],
  "creative": {"game": "nebula", "rgsGameId": "nebula_rgs",
    "slots": [], "cues": []}
}

The layout describes your game's modes, event vocabulary and creative declarations. Replace the example with your actual configuration, and include only existing selected paths. The math directory needs its published index and referenced lookup/book files. The supported event format has ordered event indexes and a terminal finalWin matching the published payout.

Libraries of a million or more books per mode are supported. Convert each mode's books with bundlepack math seekable so the preview reads them in bounded frames. A prepared build may hold files up to 4.5 GiB (Stake Engine accepts compressed books files up to about 4.2 GB), 16 GiB in total, 48 GiB of decoded books and lookup rows, and two million books per mode. Preparation validates every book, so a library this size takes a few minutes; a five-mode, million-book game packs to about 4 GB.

If your math build writes the Engine configuration file, add "mathConfig": "library/configs/config.json" beside "math". Preparation copies it unchanged to math/configs/config.json. Its per-mode settings, such as autoEndRoundDisabled: false so zero-win rounds close at the server, then travel with the build. If a path or rule is rejected, the error names it.

bundlepack prepare -root /work/nebula \
  -layout /work/nebula/reelgrove-layout.json \
  -out /work/prepared-nebula
bundlepack -source /work/prepared-nebula \
  -out /work/nebula-build.tar

Use new output paths outside the source repository, with existing parent directories. Preparation preserves the selected files, records the contract and checks the published math. It never runs source. Hidden files, links and credential-like content are rejected; select source files explicitly instead of the whole repository.

Review before making it a project

Upload, validate, then register.

1. 01

   Choose Import existing game.

   In your studio's Projects section, select the prepared TAR and give the game a name. Keep that exact file while the upload is in progress.

2. 02

   Validate the completed upload.

   Request validation, then inspect the reported result. Validation checks the captured contract, bundle structure and published math in an isolated worker.

3. 03

   Register the validated game.

   Confirm registration to create the private project, then open its Lab and isolated test-credit preview. A game with a large math library can take up to four minutes to start; the preview shows the elapsed wait meanwhile. Registration does not submit a game to Engine.

Creating a project needs permission to create and import projects, the required discipline access and available editing capacity. Teammates receive only the access their membership grants.

Keep the creative iteration

Import a new build into the same project.

Prepare the next completed build, open Import new build on your independent project and upload its TAR. Validation creates a candidate; your current game stays active while you review it. Explicit activation copies the saved Lab work and switches the project to the new revision. Earlier source and Lab revisions remain retained.

Ordinary source, frontend and math changes can keep the same project contract. The contract also pins your notices, creative declarations and Engine math configuration. When any of those change, or declared capabilities, modes or event vocabulary, increment its contract revision by one and set parentSHA256 to the preceding contract identity (the previous preparation report’s manifest.originalDigest). An upload that does neither is refused with the exact revision and parent to use. Activation requires the active source revision you reviewed. If another build wins first, refresh and deliberately prepare a new request.

Check the activated game in its preview, including the hooks used by existing bindings. Declarations determine whether a symbol, reel, feature or win animation is available; the game must call the corresponding adapter. Saving a newer animation document does not silently replace a version already bound to an event.

Private previews accommodate short bursts of script and image requests. If loading reports that preview capacity is busy, wait briefly and reopen the preview.

a separate destination

Create a new owned project through MCP.

Explicit project-creation scope adds initial TAR upload, isolated validation and reviewed registration to the machine workflow. A key on an existing project supplies the authorization anchor; the server reserves a different project and preserves the original. Upload, validation and registration are separate actions with durable retry identities.

The anchor key gains no destination read, edit or export access. Create a separate key for the new project before continuing automation there. Same-actor read access can recover status or completed registration after editing expires, while new effects require the original key and current creation/import permissions. See the CLI commands and full tool contract. The separate portable-restoration commands require explicit plan review; machine cloning has its own explicit capture.

Use the same reviewed workflow from CI

Upload with a project key.

Download studioctl. In Developer access, select the existing project and issue a short-lived key with Import whole game bundles and its required discipline scopes. Store the secret in a private file with mode 0600, outside your repository and command arguments.

studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  owned-build upload -archive nebula-build.tar -receipt build-104.json
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  owned-build validate -receipt build-104.json
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  owned-build status -receipt build-104.json

# After reviewing the validated candidate:
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  owned-build activate -receipt build-104.json

Upload pins the active revision when the receipt is first created; you can supply -expected-revision explicitly. Keep the receipt and identical TAR on private durable storage across CI retries. The receipt contains request identities and hashes, not the key or game files. Validation and activation finish asynchronously; inspect status until the result is known.

After an uncertain response, repeat the exact command with the same receipt. Revoking the admitting key stops its pending work; issuing another key does not revive that authority. See the MCP guide for scoped tools and permissions.

Keep an outcome you can discuss again

Save an exact test scenario.

In the workspace's Frontend → Saved test scenarios, choose a published mode, variant and book, name the scenario and save its requested device settings. ReelGrove records the original outcome and the exact source, frontend, math and creative input identities.

New scenarios default to replay, wait:complete; if an older saved scenario requests play, capture a new scenario with these supported actions before running hosted browser checks—the original record remains unchanged.

Open saved outcome replays that recorded book in a private preview. History identifies which inputs changed, and you can download the scenario and original event JSON. The outcome is frozen; the interactive preview still uses current creative state. Saving or opening it records no automated browser pass.

For local CI, bundlepack qa captures and checks scenarios from completed local directories. Use the isolated Chromium runtime with your game’s observer adapter to collect actual replay completions, control checks, errors and a screenshot. Keep saved expectations, measured browser results and human review decisions distinct when assessing a release.

retained QA history

Keep the working list focused.

The Active, Archived and All retained views organize saved scenarios and release candidates. Select an exact record, choose Archive scenario or Archive release, review its identity and choose Confirm archive. This is a permanent organizational change; it does not delete the original evidence.

Working and retained QA capacity shows project and studio usage separately. Archiving releases working capacity while retaining exact books, expectations, review decisions and references from suites, matrices and readiness reviews. It adds a small receipt and does not free retained storage or make stale evidence current.

A project allows 128 active scenarios and 64 active candidates, with separate retained limits of 4,096 scenarios, 2,048 candidates and 256 MiB of combined retained QA evidence. Studio and installation budgets also apply. Archiving does not reset suite, matrix, policy or browser-execution history limits; check the displayed capacity before capturing more evidence.

After a lost reply, use Recover archive receipt before starting another archive. Recovery reads the original receipt with current access, including after editing expires or the active revision changes. New archive actions require all evidence read permissions, review-comment permission and current editing capacity. The matching scoped MCP workflow uses the same current authority checks.

Choose a useful regression case

Find a published test outcome.

In Frontend → Saved test scenarios → Find a published outcome, enter a published mode and optional variant. Search for Zero payout, an inclusive Payout range in base-stake multiples, the Published maximum, or an exact Recorded event type. Event names match the stored record; ReelGrove does not infer feature behavior from their names.

Results preserve exact outcome IDs, payout values, draw weights, event counts and book hashes. Published maximum includes records with zero draw weight. Those records are not selected by the weighted draw, but you can select one explicitly for replay review. Browse 32 records at a time; each continuation checks the same published math identity. If the math changes, start a fresh search.

Choose Use this outcome to fill the scenario form’s mode, variant and outcome ID. Name the scenario, review its browser profile and explicitly choose Save scenario. Search and selection do not save, open a preview or start a browser run. Saving reads the current published outcome again and captures its current input identities.

Searching remains available after editing expires when your account retains the required project and discipline read permissions. Saving still requires current capture access. Add a saved expectation to a named regression suite when you want to check it repeatedly.

Review the expectation before reusing it

Take a saved scenario into the current build.

Open a saved scenario in Frontend → Saved test scenarios and choose Reuse on current build. Start with its original selection and profile, edit the new name or settings as needed, then choose Review current outcome. ReelGrove reads the selected book from the current published math.

Review the original and current selection, exact book, payout, event positions and browser profile, alongside changed source, frontend, math and creative inputs. The screen distinguishes the same recorded outcome and profile from a changed expectation. An equal payout alone does not make two outcomes the same.

Choose Save reviewed scenario to keep a new expectation linked to its original. If the target changes after your review, prepare and inspect it again. Earlier scenarios and browser observations remain unchanged, and this save records no browser pass. Use a fresh candidate and browser observation to test the new build.

The tab retains the exact save request before sending it. After an interrupted response, use Recover saved request before creating another scenario. Saved results and their lineage remain readable with the required project permissions, including after editing expires; preparing or saving a new expectation requires capture access. The downloaded scenario includes its carry-forward review.

Keep the cases your team checks repeatedly

Save a named regression suite.

In Frontend → Named regression suites, choose New suite, name the set and select 1–32 exact saved scenarios. Give each case a unique stable key, such as bonus-entry or base-loss. Save suite version records the selected scenario identities and hashes; it starts no browser run.

Open a suite to inspect each case’s changed inputs and download the exact definition. Edit from this version starts from its current head and saves a new immutable version. Existing versions and scenarios remain unchanged. When inputs change, review and save replacement expectations, then select them in the suite editor while retaining the relevant case keys. Equal keys, names or payouts do not establish the same outcome.

Show version history opens an explicit older version. If every selected case matches the current project inputs, enter a candidate title and requirements and choose Capture this suite version. The resulting release retains that exact version, including its original case membership; it never silently switches to the latest head. Use Open captured release for the existing human review and separately started browser observations.

The tab retains the exact save or capture request. After an interrupted response, choose Recover saved suite request before starting another action. Completed receipts remain recoverable after a project revision changes or editing expires, while required read access remains. A rejected request can be discarded explicitly; a changed suite head needs a fresh review before a new save.

New versions and candidates require review-comment permission, the game’s discipline reads and available studio resources. Suite history remains readable without mutation permission. Saving a suite, matching current inputs or capturing its candidate records no browser pass or Engine approval.

Keep every requested combination

Apply saved profiles to exact outcomes.

In Frontend → Profile and action matrices, choose New matrix. Name the matrix and each combination, then set its viewport, currency, language, reduced motion and ordered actions. Save matrix version retains that exact definition. Older versions remain available through Matrix version history.

Select exact saved outcomes and choose Prepare complete matrix. Review every outcome with every combination: two outcomes and two profiles produce four cells. The complete set is limited to 32 cells. Changed outcomes first need reviewed replacement expectations; preparation never drops a case to fit.

Choose Save all cells as one suite, then Open complete suite to capture and run. Capture that exact suite version as a release and start its browser execution separately. The supported requested actions are replay, wait:complete, skip and turbo. A game that does not implement a requested control produces an explicit failed result.

Use Recover matrix request after a lost reply. Captured history retains every cell, original book and stale marker. Saving needs review-comment permission, all discipline reads and current studio resources. Matrices and their complete history travel in portable exports; imported expectations do not become destination tests or approvals. Use the same workflow from MCP.

Make the reviewed version explicit

Capture a studio release candidate.

Open Frontend → Studio release review, enter a title and requirements, select saved scenarios that match every current input, then choose Capture candidate. Teammates can comment, request changes or record a studio approval with the appropriate review permissions. Reviewers do not need an editor seat.

Changing source or a creative input marks affected evidence stale. Prior decisions remain attached to the exact candidate they reviewed. Download candidate and review evidence to retain those identities and decisions with your build.

Trial expiry keeps saved scenarios, release candidates and earlier reviews available to teammates who retain the required read permissions. New captures, reviews and game previews still require an active trial when trial rules apply.

Human decisions and browser observations are separate records. On an enabled installation, inspect the candidate’s Browser observations below its reviews. Engine approval remains not assessed. A studio approval does not deploy, publish or submit the game.

For decisions bound to structured requirements and exact browser evidence, use a readiness policy and candidate. Ordinary review records remain attached to the version they reviewed.

Retain what the reviewer actually inspected

Connect requirements, tests and a decision.

In the Frontend workspace, choose New readiness policy. Select an exact named-suite version, add human requirements and decide whether to allow explicit exceptions. Save policy version requires review-approval permission and current studio resources. Later policy changes append a version; earlier candidates keep their original policy.

Use Capture readiness candidate with the current policy, then open the candidate and run its saved scenarios. Under Evidence-bound release readiness, inspect retained screenshots and receipts and choose Use this observation for review for each required case. Add requirement assertions and notes, then choose Assess selected evidence.

The assessment keeps passed, failed, missing, open and stale checks visible. Save the human decision against that exact selection. If the policy permits an eligible exception, record a reason for each accepted check; the original failed result remains failed. A computed ready report is not a human approval or Engine approval.

After an interrupted reply, choose Recover saved readiness decision. Saved decisions retain their policy, assertions, exact observations and exceptions. Later project changes appear separately as stale inputs. Portable exports preserve the original decisions and selected evidence across builds. Read-only MCP tools let CI inspect the same evidence and readiness result.

Observe the captured build

Run a candidate’s saved scenarios.

When hosted browser execution is enabled, choose a current release candidate with matching saved scenarios and use Browser observations to start a run. ReelGrove freezes the standalone frontend, outcomes and creative inputs, then runs them in an isolated browser. Later Lab edits do not alter that frozen run.

Your game must integrate the observer adapter with its real replay handlers and displayed payout. Merely publishing compatible math is insufficient. Unsupported skip or turbo controls fail their requested checks. Choose scenario settings that exercise the device, currency, language, reduced motion and controls you intend to verify.

Projects created from an observer-enabled starter release can use its supplied integration. Existing studios keep their original template releases; selecting a newer starter default does not add the observer to those earlier projects. Check the adapter in the exact project you plan to run.

If result publication is briefly interrupted after the browser finishes, the worker can recover a complete staged result after checking its original output, screenshot, frozen inputs and current access. It preserves the observed pass or failure without running the browser again. Incomplete or changed evidence remains retained for review.

Open execution details to review completed cases while other cases are still running. Inspect observed passes and failures separately from interrupted runs. Visible screenshots load one at a time; use Retry screenshot if a read fails. Open retained screenshots and download verified receipts. A screenshot confirms the captured pixels; your team still reviews their visual quality. If preparation is interrupted, use Find saved request or Retry preparation in the same tab before starting another run.

Cancel unfinished work to stop the remaining scenarios. Retire evidence only when you intend to discard its files after cleanup; immutable identities remain. Retained history stays readable after editing expires while your account keeps every required read permission. Local Chromium replay is available when a hosted worker is unavailable.

Completed browser runs release unused storage reservation after ReelGrove verifies their retained files. Frozen builds, receipts and screenshots stay intact, including observed failures. Evidence selected in a readiness review remains protected from retirement.

Keep both sides of the change

Compare retained browser observations.

Open a completed run in Browser observations and choose Use as baseline. Open another candidate or run in the same project and choose Compare with baseline. The baseline stays in this browser tab across project revisions; both observations must retain their files and remain readable with your current permissions.

Compare expected and displayed payouts, expected event positions, observed handler positions, errors and screenshots side by side. The report identifies changed source, math and creative inputs. It shows the requested profile and actions separately from what each browser recorded, including incomplete actions in failed runs. Matching requests do not mean every control succeeded; inspect the retained receipt for control results. If the recorded outcome, selection, requested profile or browser differs, it explicitly warns that a failure becoming a pass does not establish that the same regression was fixed.

Pixel counts compare equal-size screenshots within a bounded size; larger or differently sized images remain available for visual review. Animation timing can change pixels. Use Download comparison JSON to retain the exact paired receipt identities and report. Comparing runs changes no scenario, observation or approval.

Compare before changing the game

Run a reviewed math experiment.

For an owned project with hosted math enabled, open Math → Math experiments. Select the exact retained source files, Python entry script and available profile. Set the seed your driver uses, time/output limits, published mode costs and any RTP or hit-rate targets, then explicitly confirm the source selection. Submitting requires Math editing permission and current editor capacity.

The worker runs without network access. Use dependencies supplied by the selected profile or retained in your reviewed source. Generated files undergo independent validation. Read the resulting distribution and target checks, compare two completed experiments, and download the exact report or comparison. Abbreviated values marked ≈ are display approximations; downloaded rational values remain exact.

Open a completed experiment and use Find a generated outcome before promotion. Search by zero payout, payout range, maximum or recorded event type, then choose Open frozen replay to inspect the outcome with a frozen copy of its compatible frontend and creative files. Retained older results remain searchable; replay requires their original build to remain active and read access to every game discipline. Opening a replay neither promotes the math nor records an automated browser pass.

Choose Prepare validated build only for the result you want to review. Confirm the preparation, then open project build history to inspect ordinary validation and activate it separately. The prepared build preserves the retained source, frontend and contract while replacing generated math; an experiment never changes the active game by itself.

Reloading the tab preserves its pending request identity. Recover that request after an uncertain response. Historical results remain readable after editing expires. Cancellation queues file removal after worker cleanup, and unfinished build preparation must be resolved first. You can also run math experiments locally with your own pinned tools.

exact native build evidence

Read a build receipt, then compare two runs.

Open a retained validated experiment in Math experiments, then choose Read build receipt in Build evidence. The view distinguishes one recorded legacy build from one measured normalized build, shows its limitations, and lets you download the exact receipt bytes and SHA-256.

Choose another retained experiment and select Compare build evidence. The view separately reports selected source/revision, recipe/toolchain, input bytes, output bytes and whether the observations came from distinct native runs. Only two eligible normalized observations that match every condition can state Two clean runs matched. That statement does not guarantee future determinism, game correctness or approval. Ordinary distribution comparison remains separate.

Download both original receipts and the comparison to preserve the exact pair. Imported receipt JSON and matching submitted hashes cannot create native observations. Current Project and Math read access is required; historical reads remain available after editing expires. Canceled or removed results cannot issue new receipts, and changing selection or losing access clears the displayed evidence. These controls never rerun source, promote math or activate a project.

The optional python313-normalized-v1 profile still requires separately enabled reviewed images. Legacy, SDK and optimizer runs retain their historical limitations. Read the machine-tool contract or use the CLI examples.

Bring your existing game modules

Generate with the pinned Engine Math SDK.

When listed in your workspace, engine-math-e37dd1f-v1 supplies Engine Math SDK Python modules from revision e37dd1f5993 and locked dependencies. Select your game’s Python modules, reel/configuration files and a small driver. The separate python313-v1 profile supplies the Python standard library.

The optional python313-normalized-v1 profile uses Python’s standard library with fixed selected-input metadata and measured toolchain identities. Choose it when the experiment context lists it. The build receipt tools and workspace controls read exact native observations and compare two eligible runs. Ordinary distribution comparisons and imported CI receipts do not establish native reproducibility.

For retained source under source/project/math, put your game in math/games/my_game and use a driver such as math/generate.py. Adapt the game name to your contract. Call prepare() before importing game modules:

import runpy
import sys
from reelgrove_engine import prepare, publish

root = prepare()
sys.path.insert(0, str(root / "games/my_game"))
runpy.run_path(str(root / "games/my_game/run.py"), run_name="__main__")
publish("my_game")

Choose source/project/math as the working directory and source/project/math/generate.py as the entry script. Include every required game file in your reviewed selection. The helper directs SDK output into the isolated job; your published game ID, modes and costs must match the project contract.

This profile runs Python generation and includes its analysis dependencies. It does not contain the Rust optimizer or install packages during a run. Your generator must use REELGROVE_MATH_SEED where applicable; supplying a seed cannot make arbitrary code deterministic. Compare the retained measured output, then prepare and review a build explicitly.

When separately listed, engine-opt-e37dd1f-v1 adds the precompiled Rust optimizer from the same SDK revision. Import prepare_optimizer from reelgrove_optimizer and call it instead of prepare(), before importing your game modules. Your driver generates books and configuration, runs the SDK’s OptimizationExecution.run_all_modes, generates final configuration and calls publish(). Select search settings that fit your execution budget; Cargo and package installation are unavailable during a run.

The Rust optimizer uses random search, so a saved seed does not guarantee identical weights. Each run retains its actual inputs, profile and measured output for comparison. Independent validation and explicit build review still apply. Optional profiles require their own configured images; check the workspace’s profile list and current availability and access requirements.

Keep the editable work

Choose the export your next step needs.

Standalone game

A playable captured build with its supported Lab changes and required runtime. Verify it in your own hosting and game integration.

Development bundle

The selected source, built frontend, published math and build instructions. Edit and rebuild locally, then activate the new build in the same project to preserve saved Lab work.

Portable project

Development files plus current Lab metadata, all uploaded assets, captured editable animation versions, review lineage and saved QA/release records. With archived QA, the export retains complete saved QA history across project revisions and the original archive receipts. Use portable verify, plan and unpack to check the complete archive and recover files offline.

New portable archives include every retained animation version in the project, including earlier branches and documents with no current head. Source, math and other Lab settings describe the captured revision. Older archives retain only the versions their exporter captured.

Scoped MCP export tools and a verified CLI download let CI capture and retain these archives. Issue a key with Export project archives and the required discipline reads, retain the original request UUID and download the ready archive before switching project revisions.

Portable downloads also retain named suite version history, its exact referenced scenarios and books, and release links from the captured revision. Restoring into another project preserves that original evidence capsule; it does not create native suite authority or transfer approval. Review the destination independently.

On an installation with restoration enabled, prepare and restore the archive into a new editable project. Upload the prepared TAR, validate it, then explicitly confirm Restore editable project. Current destination permissions and editor capacity apply. Imported reviews and browser results remain historical evidence; the new project needs its own review.

Reusable studio kits select exact media and animation documents from a portable export. Extract them locally and import through the Lab controls, or choose Studio kits from the project menu (the project name at the top left of the Lab) in an enabled destination project. The upload, inspection and reviewed installation workflow shows added or reused media, fresh animation identities and storage before a separate confirmation. Existing Lab work remains intact. Recover an interrupted request from kit history and configure game bindings deliberately.

twelve scoped kit tools let a connected client upload, inspect, review and explicitly install the same creative subset. Exact request recovery keeps the original actor, key and project; inspection and installation remain separate steps.

Local math experiments retain selected inputs, pinned tools, generated distributions and constraint results. Compare jobs, then promote chosen math through your normal build and import workflow. Enabled installations also support the hosted experiment and explicit build preparation workflow.

Start another direction from saved work

Copy an editable project.

Cloning is available only on installations where the operator has enabled it. If the project menu at the top left of the Lab shows Clone project, save open drafts, choose a name and confirm Create editable copy. This captures the current source and saved Lab work into a new project in the same studio. Project creation, export and discipline permissions plus current editor capacity apply.

Follow the copy through export, source validation and Lab restoration. Open copied project appears only after the copy is complete. Closing the dialog leaves it running; reopen Clone project from the project menu or use Refresh copies to check progress. Unfinished copies expire after one hour.

After an interrupted response, use Recover saved request. It checks the original request and captured copy, including completed history after editing expires. Keep the request when its result is uncertain. Your history belongs to the account that started the copy. Available unfinished copies can be canceled after a separate confirmation; cleanup may take time. A copy marked Operator review required needs operator help and retains its identifiers.

The destination contains the captured editable source, current Lab work and retained animation versions. Earlier QA, scenario books, reviews, named suite versions and browser observations remain imported history. They grant no destination approval or credentials. Earlier complete source revisions are not recreated. Review and test the copied project independently before release.

project-key cloning through the CLI adds an explicit capture with a durable request receipt. Recovery preserves the original source and destination; the source key receives no access to the copied project.

Recover the existing request

Keep your place when work is interrupted.

Use import or activation history before creating another request. Reselect the same TAR to resume an upload. If a saved upload never reached the server and you have since rebuilt the archive, choose Discard saved request, then upload the new TAR. After a lost activation response, recover the saved activation receipt. History remains readable when editing expires, provided your read access remains. A stale source revision needs a newly reviewed request.

Independent imports and activation must be enabled on your installation. Your role needs the relevant capabilities, and editing needs an active trial or paid editor capacity. If a control is missing, ask your studio owner to check access and available capacity. For an operation requiring administrator review, retain its ID and visible status and contact support.