# ReelGrove public documentation

Product and guides from the public website. Private studio and account data is excluded.

Source: https://reelgrove.net/stake-engine-tools/

Independent tools for Engine studios

# Stake Engine development tools.

ReelGrove is a private creative workspace for developers building slot games for [Engine (engine.io)](https://engine.io/), also known as Stake Engine. It brings artwork, sound, animation, game previews and project reports into one browser workspace.

Use it to refine a supported game build with your team, review changes and connect your AI assistants. ReelGrove is made by Mac Graver sp. z o.o. and is independent of Stake and Engine.

Art, Sound & Animation Labs  Private studio projects  Test-credit previews  Scoped MCP tools

## What can you do in ReelGrove?

### Replace artwork and tune sound

Use Art Lab to replace supported game artwork, adjust it and preview it in context. Use Sound Lab to audition replacements and tune supported sound settings. Saved changes belong to your project revision.

### Create motion and skeletal animation

Motion Lab adjusts supported game motion. Animation Lab creates rigs, clips and layered mixes with crossfades, keys tint and flash colours, imports supported Spine JSON rigs and binds supported animations to game events. Supported exports include the animation runtime and source under the supplied project-use terms.

### Inspect math and check frontend files

Read math reports computed from published weights, including return to player (RTP), hit rates and payout distributions. Run static frontend checks on the current revision. For built games with the observer adapter, [local Chromium replay](https://reelgrove.net/downloads/#browser) collects actual outcome completions, control checks and a screenshot. Engine submission review remains a separate step.

### Repeat the checks that matter

[Save profile and action matrices](https://reelgrove.net/docs/existing-games/#profile-matrices) across exact outcomes, capture complete suites and inspect every isolated browser result. [Readiness policies](https://reelgrove.net/docs/existing-games/#release-readiness) bind structured requirements and the observations your team reviewed to an immutable decision. Failed and missing evidence stays visible.

### Preview and review together

Run game previews with simulated test credits. Save exact published outcomes, capture release candidates and record human reviews against their input identities. Changed inputs are marked stale. Enabled installations also record [isolated browser observations](https://reelgrove.net/docs/existing-games/#browser-runs) against the frozen candidate. Review completed cases, verified receipts and screenshots while the remaining cases finish. Invite teammates with role presets or custom permissions for the work they need to do. Editors use paid seats after the trial; reviewers join free.

Use the viewport selector in the preview toolbar to test desktop, laptop, popout and three mobile sizes at their exact pixel dimensions; separate preview dialogs offer the same sizes in their Screen selector. Resizing preserves the running test session. [See the preview guide](https://reelgrove.net/docs/getting-started/#review) or [the editors and real product screenshots](https://reelgrove.net/#labs).

## Where it fits in your Engine workflow

### Start with a supported project.

Choose an available starter game, or import your completed Engine frontend and published math where independent imports are enabled. [The existing-game guide](https://reelgrove.net/docs/existing-games/) covers initial admission, later builds and CI. [Bundlepack](https://reelgrove.net/downloads/) packages local Engine frontend and math files for import.

### Make and review creative changes.

Replace symbols, tune sounds and build animations in the Labs. Preview the result, save exact outcomes, inspect reports and collect release feedback in your private studio.

### Export and continue your build.

Download a standalone game, development bundle or portable project with its captured files. Edit game source and generate math in your local toolchain, then activate a rebuilt bundle in the same project to preserve saved Lab work. Exports keep working independently of ReelGrove.

### Submit through your own Engine account.

Follow the [official Engine documentation](https://stake-engine.com/docs) and approval requirements. A ReelGrove template, report or export does not grant submission approval.

## Connect AI agents through MCP

ReelGrove provides a remote Model Context Protocol (MCP) endpoint for compatible assistants and coding tools. A project key limits access to a selected project, revision and set of tool scopes. Available tools inspect project context, edit supported Lab resources, capture complete regression matrices and assess the exact evidence behind release decisions. Use studioctl to upload an existing project’s next build or download a verified export. Project keys enforce the same resource permissions; human approvals remain in the account workflow.

Start with the [MCP setup guide](https://reelgrove.net/docs/mcp/) for connection settings, permissions and example tasks. For product research, the [text documentation index](https://reelgrove.net/llms.txt) and [public documentation as text](https://reelgrove.net/llms-full.txt) are available without signing in.

## Common questions

### Is ReelGrove an official Stake Engine product?

ReelGrove is an independent development service. Your company maintains its own Engine account and submits games through Engine. ReelGrove does not provide approval, casino distribution or a revenue guarantee.

### Does it replace the Engine SDK or generate my game math?

Keep your local source and math-generation tools. ReelGrove adds creative Labs, previews, published math reports, saved scenarios, release reviews and build imports. [Local math experiments](https://reelgrove.net/downloads/#math-experiments) retain inputs, pinned tools, distributions and constraint results for comparison. When enabled, [hosted experiments](https://reelgrove.net/docs/existing-games/#math-experiments) run reviewed source, compare validated distributions and prepare a build for separate activation. Build imports depend on the formats and features enabled for your studio.

### Can I use real money in a preview?

Previews use simulated test credits with no deposits, withdrawals or redemption. Subscription payments buy access to development tools and are separate from preview balances.

### Does “engine.io” mean the Socket.IO networking library?

Here, engine.io refers to the Engine game-development platform. The Engine.IO networking library used by Socket.IO is a separate project.

## Try your first project

The 7-day free trial includes three editor seats including the owner, free reviewers and all seven starter games, with no card required. After the trial, the studio plan is €49 per editor per month plus applicable tax. Reviewers are free, and team invitations are available during an active trial. See [pricing and plan details](https://reelgrove.net/#plan).

### Make your first playable change.

[Follow the first-project guide](https://reelgrove.net/docs/getting-started/) or [contact support](https://reelgrove.net/support/).

[Start your free trial ](https://reelgrove.net/app/?mode=register)

---

Source: https://reelgrove.net/

For the people who make slot games

# Make your next slot game your own.

A creative workspace for [Engine (Stake Engine)](https://engine.io/) studios. Iterate on your game’s artwork, sound and animations in a live preview, explore the math and put your AI agents to work.

[Start your 7-day free trial ](https://reelgrove.net/app/?mode=register)[Explore the editors ](https://reelgrove.net/#labs)

7 days free. No card required. [Then €49 per editor / month + applicable tax](https://reelgrove.net/#plan)Reviewers join free.

A look inside your next creative workspace

Meet ReelGrove. 38 seconds · English narration & captions

Read the overview transcript

Your next slot game should feel like yours. Meet ReelGrove: a creative workspace for Engine studios. Start with example games, then shape the art, tune the sound, and bring your symbols to life in Animation Lab. Preview your changes as you work. Explore advanced math statistics and run frontend checks before your next build. Invite your team with the permissions each person needs. Connect your AI agents through scoped MCP tools. From the first idea to the final details, keep your studio moving. Make it yours, with ReelGrove. Explore reelgrove.net.

Real editors and example games. Generated demo artwork. Preview with test credits.

Real starters. Your art direction.

## One visual world. Two ways to play.

Engine’s Lines and Cluster examples, rebuilt with generated Ember artwork. These are actual game replays, showing the finished symbols and background in play.

01 / LINES STARTER

### Ember Lines.

[View full screenshot ↗](https://reelgrove.net/landing-media/ember-lines-preview.webp)

02 / CLUSTER STARTER

### Ember Cluster.

[View full screenshot ↗](https://reelgrove.net/landing-media/ember-cluster-preview.webp)

Actual Lines and Cluster starter replays with generated Ember artwork. Demo credits only.

Your creative workspace

## Create. Preview. Keep refining.

Iterate on artwork, sound and animation with your game in view. Save a change, preview it in context and keep refining.

REELGROVE / ART LAB  ACTUAL EDITOR CAPTURE

Owned Demo · three saved symbol replacements  Test credits · no cash value

01 / ART

### Make it unmistakable.

Replace a symbol or background. Supported games apply saved artwork live; older builds reload the private preview.

02 / SOUND

### Give every moment a voice.

Audition clips and tune your mix. Supported games pick up sound changes live for the next cue.

03 / MOTION

### Add that little spark.

Shape supported idle and win animations with pulse, bob and tilt. Save a preset and sample it in context.

04 / ANIMATION

### Give your character a performance.

Build a rig, shape its motion and preview a saved clip in your game. [Start in Animation Lab ↗](https://reelgrove.net/docs/getting-started/#animation)

Animation Lab

## From a simple rig to a full performance.

Open the Animation Lab tab in your project’s Lab. Build, import and refine editable rigs, then take the animation and its playback runtime into your own game.

### Rig and deform.

Bones, attachment variants and skins give your character structure. Shape meshes, paint and lock weights, key deformation, and share geometry through linked meshes.

[Rigging and meshes ↗](https://reelgrove.net/docs/getting-started/#animation-meshes)

### Shape every pose.

Refine timing in the dopesheet and value graph. Normalize curves to compare different channels, edit groups of keys and Bezier tangents, and compare poses with ghosts.

[Timing and curves ↗](https://reelgrove.net/docs/getting-started/#animation-timing)

### Add responsive movement.

Use IK targets, transform constraints and editable paths. Add spring motion with gravity, damping and travel stops that replay consistently when you scrub.

[Constraints and physics ↗](https://reelgrove.net/docs/getting-started/#animation-constraints)

### Layer the performance.

Key tint and flash-to-white colour, and blend sprites with add, screen or multiply. Animate drawing order, clip with polygon masks, and mix override and additive layers with bone masks and crossfades.

[Colour, order and mixing ↗](https://reelgrove.net/docs/getting-started/#animation-appearance)

### Time the finishing touches.

Place events with optional values and audio cues, edit trims, fades and gain, and bind exact saved clips or mixes to supported game hooks. Review versions and recover retained drafts.

[Sound, events and recovery ↗](https://reelgrove.net/docs/getting-started/#animation-mixing)

### Bring a rig. Keep the result.

Import supported Spine 4.1.17 or 4.2.22 JSON, reuse native rigs and export atlas players or packages with runtime source. Project-use runtime rights continue after your subscription ends.

[Import support and export options ↗](https://reelgrove.net/docs/getting-started/#spine-import)

Spine import supports a verified subset; the compatibility report explains unsupported features before insertion. Exports include their runtime license and third-party notices.

Advanced math statistics

## Know the odds. See the whole picture.

Explore RTP, hit rate, variance and payout distributions from your published math. Compare modes, run session simulations and use calculators to estimate exposure and sample sizes.

Actual customer Math interface · owned Studio Demo report · example project Open image for a closer look ↗

Computed from the published weights. These are read-only reports of the source files. They describe the distribution; they do not establish deployed game behavior or submission approval.

Keep the gaps visible. This Demo has 23 passed checks, one publication-format failure and three manual reviews. Automated checks and remaining reviews are both part of the report.

Look beneath the surface

## Every file. A clearer picture.

Inspect your published frontend: its entrypoint, declared game identity, local resources and artwork registry. Each result stays tied to the project revision.

Actual customer Frontend interface · owned Studio Demo report · example project Open image for a closer look ↗

Computed from the frontend files. This Demo passes four static checks across 12 files. Refresh the report to inspect the current revision without running the game.

Browser verification still matters. Authentication, play, replay, layout and saved Lab replacements need separate browser execution. Static checks do not establish runtime behavior or submission approval.

A place to start. Room to make it yours.

## From first idea to your next game.

Bring your existing Engine game or start with an available approved template. Keep your build tools and bring the team into one private project.

01

### Start a game.

Import a completed Engine frontend and published math where independent imports are enabled, or choose a starter template.

YOUR OWN PRIVATE COPY

02

### Find its character.

Add artwork, bind sound cues and animate your symbols. Connect saved animations to supported game hooks.

ART, SOUND & ANIMATION

03

### Make it better, together.

Save exact test outcomes, capture a release candidate and collect team reviews against the version they saw.

SAVED SCENARIOS & STUDIO REVIEWS

04

### Take your work with you.

Download a standalone game, development bundle or portable project. Keep saved Lab work when activating your next build.

PLAYABLE & EDITABLE EXPORTS

[Bring your existing game and connect CI ](https://reelgrove.net/docs/existing-games/)

[Follow the first-project walkthrough ](https://reelgrove.net/docs/getting-started/)

[Repeat exact outcomes across saved profiles and controls](https://reelgrove.net/docs/existing-games/#profile-matrices), then [review a release against the evidence your team inspected](https://reelgrove.net/docs/existing-games/#release-readiness). Template availability varies. Development examples and exports do not grant Engine submission approval. [See how ReelGrove fits your Engine workflow.](https://reelgrove.net/stake-engine-tools/)

A studio for your people

## Different disciplines. One shared project.

The work around the work, in one place. Invite your team, decide who can change what, and manage the editor capacity your studio needs.

### Bring the right people in.

Invite artists, sound designers, animators and reviewers. Start with a role preset and see the access attached to each invitation.

Current Studio interface · example team and invitation data Open image for a closer look ↗

The owner keeps full access and controls billing. Permissions describe access; tools are available where the current product supports them.

Connected to your workflow

## MCP for your agents.

Give your agents project tools for artwork, sound, motion and math. Let them inspect assets, apply supported changes, compare modes and run calculations or simulations through the scoped access you choose.

Project keys have scoped permissions and an expiry. Use studioctl to upload your next build or download a verified archive. Capture regression matrices and inspect release readiness from CI. Editing follows your team’s current access and editor capacity.

[Read the MCP developer guide ](https://reelgrove.net/docs/mcp/)

An example tool workflow

### “Review the sound cues and help me refine the mix.”

01

Read the current project`project_context`

02

Inspect cues and their saved levels`sound_cues`

03

Apply a change with the observed revision`bind_sound`

Illustrative workflow using real project tools. The guide covers setup, permissions and handling conflicting edits.

A closer look

## Small details. A bigger picture.

Two short tours of the creative work and the tools behind it. Watch with sound, or follow the on-screen captions.

[See how to get started ](https://reelgrove.net/docs/getting-started/)

### Give your game its character.

[Download video ](https://reelgrove.net/landing-media/reelgrove-creative-v1.mp4) 28 sec · Art · Sound · Animation

Read the creative Labs transcript

The art sets the scene. The sound makes it land. The motion brings it to life. In ReelGrove, refine your artwork, tune your sound cues, and animate your symbols in one creative workspace. See the details come together. Make your next slot game your own. reelgrove.net.

### Go deeper. Stay in control.

[Download video ](https://reelgrove.net/landing-media/reelgrove-agents-v1.mp4) 29 sec · Math · Frontend · MCP

Read the project tools transcript

Great slot games need more than great artwork. Explore advanced math statistics. Check your frontend files. Give your AI agent scoped MCP tools for your project. Keep your team in control, with permissions for every discipline. Meet ReelGrove. A workspace built for Engine studios. reelgrove.net.

A straightforward studio plan

## Seats for makers. Room for reviewers.

Explore the creative workspace together for 7 days with three editor seats, including the owner, and free reviewers. Subscribe to keep editing after the trial.

STUDIO PLAN  7-day free trial

€ 49 per editor / month after your free trial

Free reviewers.  Because good feedback matters.

- 7 days for your team, 3 editor seats and all 7 starter games

- Private projects and supported creative Labs

- Role presets and custom team permissions

- Test-credit previews and supported exports

- Monthly billing. Cancel renewal at any time.

Prices exclude applicable VAT or other taxes. Checkout shows the final total. Each editor, including the owner, uses one seat per studio across all projects. Pending invitations are not charged.

[Start your 7-day free trial ](https://reelgrove.net/app/?mode=register)

No card required. Invite editors and reviewers during your active trial.

A few things to know before you start

Built for Engine teams. ReelGrove is independent of Stake and Engine. Your company submits games through its own account.

From the Lab to your build. Inspect published math, check frontend files, and refine your artwork, sound and motion in the Lab. Keep your source workflow and bring rebuilt bundles back through Import new build. On supported owned projects, run reviewed math experiments and replay generated outcomes before choosing a build.

Your work stays yours. Supported exports include captured Art, Sound and Motion settings, saved Animation Lab rigs and supported game-animation bindings. Animation packages include the runtime and source under the supplied project-use terms. Exports keep working independently of ReelGrove. Template readiness and submission approval are separate.

Make room for your next idea

## A good game starts with your people.

[Start your 7-day free trial ](https://reelgrove.net/app/?mode=register)

---

Source: https://reelgrove.net/docs/getting-started/

One idea. Your first playable change.

# Make a game feel like yours.

Start with a private project, replace a symbol, add a sound and see the result in the game. Invite your team during the trial, then capture an export of the work you want to keep.

Art, Sound & Animation  Private team workspace  Test-credit previews

01

### Create your account and studio.

[Create an account](https://reelgrove.net/app/?mode=register) with your email address and a password, verify your email when prompted, then give your studio a name. If you have an invitation, use the email address it was sent to.

02

### Start your free trial.

Keep Start my 7-day free trial selected when you create your studio, or start it later from Overview or Plan & billing. No card is required. Your 7 days begin when all seven private starter games are ready. Editing needs current trial or paid editor capacity and permission for that discipline. Your studio owner manages these.

03

### Open a project or start a new game.

In Overview, open an available project’s Lab, or create a new game from an available approved template. Give it its own name. Each new game has its own files and saved Lab changes. Already building an Engine game? Follow the [existing-game workflow](https://reelgrove.net/docs/existing-games/) to import it, preserve Lab work across builds and connect CI where independent imports are enabled.

For your next sign-in, add a passkey from Sign-in & security. You can continue using your email address and password.

The [Engine](https://engine.io/) starter collection includes Cluster, Lines, Number Picker, Price, Scatter, Ways and Lines Feature Match. Your trial prepares private copies of all seven starter games; a confirmed subscription also provides the starter collection. Open Overview to see your projects; existing studios keep the templates they started with.

Try the studio together.

The trial includes three editor seats, including the owner, and free reviewers. Once your starter games are ready, invite a developer, artist or reviewer from Team. Editing roles share the trial capacity; reviewers do not use a seat. You also get 2 GiB of uploaded and animation Lab assets and up to three additional project copies. Your files remain available in read-only mode when the trial ends. To continue editing, the owner explicitly purchases a subscription in Plan & billing; your trial never charges automatically, and upgrading keeps the same projects and files.

Make the first change small

## Replace one symbol.

Open your project’s Lab and choose the Art tab in the Lab bar. Use the search and Show filter in the Art control row to find an image slot declared by your game. Inspect its current artwork and any size or format requirements before choosing a replacement.

- Click Replace image on the chosen slot, or drop one image directly onto its tile. Use an image you have permission to use.

- The editor uploads the file and saves its binding to that slot in one action. Wait for the saved confirmation; you do not need a separate Save button.

- With the Auto preview switch in the control row on, each saved replacement updates the running game when the build supports live updates; other builds restart the preview. With it off, save several images, then choose Apply to preview, or Reload preview on builds that restart. Check the symbol at its actual on-screen size.

Use the slot’s Restore original control if you want its original artwork back. This changes that binding; it does not reset the whole project.

Agents using a project key, teammates and your other browser tabs can also save artwork. Those slots show Changed elsewhere and a time. With Auto preview on, the running game picks them up without restarting on builds that support live updates; other builds keep the previous image until you choose Reload preview. Choose the count in the control row, such as 3 changed, or Changed elsewhere in Show, to list only those slots. Opening a marked slot changes its marker to Reviewed; a slot changed while the Lab was open opens with Before outside change beside the current image. Mark all seen clears the markers. To hand work to an agent, Copy brief copies up to 60 shown slots as plain text, with their sizes, revisions and the MCP arguments to use, and Copy slot brief in the image inspector copies one slot. Help → Connect an agent opens your studio’s Developer access page to create a project key.

Start with a clear silhouette.

Try replacing one symbol before uploading a complete set. Check its edges, spacing and contrast against the game’s background.

Give the change a voice

## Choose a cue and listen in context.

Open the Sound Lab tab, find a declared cue with the search in its control row and audition its current sound when a playable asset is available. Drop a replacement file directly onto that cue row, or click its current take to choose a file. The editor uploads and binds it in one action. Adjust its level with the row’s volume control; releasing the control saves the level.

You can also upload several sounds through Browse files, then drag an uploaded take onto its cue row. A general library upload leaves the cue unchanged until you bind the take.

Preview the cue on its own first. Enable sound in the game’s own controls, then trigger the matching event, such as a spin or a win. Hearing an audition confirms the asset plays; the game event confirms that the cue works in context.

Keep the first pass simple: one spin sound and one win sound are enough to hear whether the direction fits.

Movement belongs with the artwork

## Tune a supported Motion state.

In the Art tab, open Motion for a slot that declares animation support. Choose an available state, such as idle or win, and adjust the presets and timing that the game exposes.

- Choose the state and adjust its preset, duration, intensity and easing where available.

- Choose Save motion and wait for confirmation. Sampling uses the saved revision, so save a draft before judging it in the game.

- Choose Sample saved motion, inspect the result and check its acknowledgement. Adjust and save again if needed.

The available states and controls depend on the game. For your own rigs, animation timelines and supported Spine imports, open [Animation Lab](https://reelgrove.net/docs/getting-started/#animation).

From the first bone to the finished clip

## Create an animation in Animation Lab.

Open your project’s Lab, then choose the Animation Lab tab beside Art in the Lab bar. Animation Lab fills the workspace below the bar. Drag the panel dividers, or focus one and use the arrow keys, to give the canvas, hierarchy, inspector or timeline more room. Dopesheet and Graph share your saved timeline height. Layout preferences stay on this device; Reset layout restores the defaults. On smaller screens, use Scene, Timeline, Layers, Inspector, Cues and Mixer to switch panels. If the tab is missing, check that your installation has Animation Lab enabled and your role includes View animations. Creating and editing animations also needs the matching permission and available editor capacity.

- Open a saved rig from Project, or choose New rig. Use Project assets to copy a PNG from Art Lab or a supported WAV from Sound Lab. You can also import a local PNG. Copying an asset into a rig keeps its source independent of later replacements in the Lab.

- Choose Setup pose. Select a parent and use + Bone or + Sprite to build the hierarchy. Position, rotate and scale your layers on the canvas or in the inspector. Names and choices open in inline forms with Create and Cancel actions.

- Switch to Animate, choose or add a clip, and move the playhead. Changing an animated field adds a key; its diamond button keys the current value. Play or scrub the clip, adjust its timing and use Undo/Redo to compare edits.

- Choose Save to project and wait for confirmation. For a game that declares animation hooks, open the game-binding controls and select an exact saved rig version and clip or mix. Choose an event declared by the game, such as Board win, symbol, reel or feature events, and whether to play authored sound after a game gesture. Events appear only where the game declares and implements their adapters. Save the binding, then preview the matching game event. Saving a newer rig does not silently replace a version already bound to the game.

Original Luma example in the real customer editor, using a local demonstration project. Open the image for the full-size view.

### Build and reuse a rig.

Parent bones and sprites, edit bone lengths, duplicate or reparent subtrees, and manage attachment variants and named skins. Attachment keys can switch an image or hide it during a clip. Export rig packages a reusable rig with its dependencies; Import rig adds a separately named copy with its own identities and animations. Invalid references and incomplete copies are reported before an edit is applied. A rejected rig file names the fault by its JSON path and reason, and suggests the intended name for a close misspelling. Saving applies the same checks on the server, which also refuses constraint cycles that playback cannot load.

### Shape meshes and paint weights.

Create and triangulate meshes, edit their outline, vertices and UV coordinates, and bind them to bones. For meshes created and bound in the editor, paint weights in the mesh graph and lock influences. Imported meshes with bone-local influence points also support a brush on the scene canvas and editing those points on the canvas or numerically. Setup changes the rest geometry; Animate creates free-form deformation keys. Linked meshes share geometry, including across compatible sprite owners, and can share deformation or keep their own. Use Edit source mesh to navigate to shared geometry, or unlink to keep an independent editable copy.

### Refine timing, curves and pose spacing.

The dopesheet supports multiple-key selection, range selection, snapping, zoom, copying, retiming and clip duplication. Use Graph to adjust scalar curves and Bezier handles, box-select visible keys or link adjacent tangents. Enable Normalize curves to compare channels with different units on a shared percentage axis. Each curve uses its full clip range, including easing overshoot; key labels retain the original values. Moving selected keys by 10% moves each by one tenth of its own range. A flat curve sits at 50%, with a full scale of one displayed unit. Ghost poses show earlier and later silhouettes while you scrub. Mesh deformation, constraint and physics keys participate in the timeline; portable keyframe paste asks you to map compatible rig parts when identities differ.

Normalize curves compares channels on a shared percentage axis. The key labels retain their original units. Open the image for the full-size view.

### Tint, flash and blend.

Under Colour & blending in the inspector, set a layer’s Tint with the colour picker or exact red, green and blue values; children inherit it. Dark colour colours the art’s shadows: White flash keys a short flash to white at the playhead, and a warm dark colour lifts shadows into a glow. Both can be keyed in Animate and appear as Colour and Dark colour lanes in the dopesheet, with separate red, green and blue curves in Graph. Sprites also have a Blend mode: normal, add, screen or multiply. The stage and ghosts draw them as the exported runtime does. Opening an older rig upgrades it to format version 13; a rig that uses none of these features saves without them.

### Add rig controls and secondary motion.

Use one- or two-bone IK to reach a target, transform constraints to follow another bone, or editable paths to guide followers. Animate targets, path owners and constraint parameters, and inspect unreachable-target diagnostics. Physics · secondary motion adds springs to bones: set frequency, damping and travel/rotation stops in Setup, then key gravity and translation/rotation mix in Animate. Scrubbing, restarting and looping reproduce the same simulated motion. These are ReelGrove’s native physics controls; importing Spine physics is not supported.

### Control what appears in front.

Drawing order lists sprites from back to front. Move a sprite one step or send it to either end. Setup changes the initial order; Animate keys the whole scene order. Use Alt + Up/Down for adjacent moves, or key the setup order to restore it later. Order switches happen exactly at their keys. Polygon clipping masks follow their owner bones and keep their assigned sprite targets as drawing order changes.

### Layer clips and time events and sound.

Save mixes with weighted override or additive layers, inherited bone masks, crossfades and queued clips. Preview the result in Mixer. Drawing order is a global channel and is not limited by bone masks. In Cues, add named events and audio with source trims, fades, gain and waveforms; use the Sound Lab library for supported project audio. Seeking stays silent. Events can carry optional integer, number and text values, which exported runtime event callbacks receive. Clip loops marks a clip that exported runtime scenes loop by default; saved mixes, presentation scenes and game bindings still play it once. Clip tags label clips, such as `idle` or `win:big`. Saved bindings connect animation to declared game hooks; game logic owns gameplay completion and settlement.

### Bind a saved rig to an actual game event.

In Game animations, refresh the declared events, choose Game event and select Choose open rig’s saved version. Pick its clip or saved mix, appearance and sound, then choose Bind saved version. Each event has its own exact version and history; later rig edits do not change an existing binding.

The available events come from your game’s retained source. A game can declare board wins, individual symbol landings or wins, reel stops or anticipation, bonus transitions and specific win tiers. The list comes from that game’s declaration; replay a recorded outcome to check that each hook is connected. Existing starter projects keep their original declarations when newer templates become available.

Use Preview saved binding to inspect the actual game placement, then replay saved outcomes and check skip, turbo, reduced motion and sound. Games with concurrent symbol or reel effects have shared rendering and audio limits; smaller rig canvases and media leave room for more effects. Loading does not play sound, and the preview button cannot unlock game audio. Use the game’s own Sound or Spin control. Decorative animations never decide a payout or hold up game completion.

### Take the rig and runtime with you.

Download JSON keeps an editable document with embedded media. Export player creates a standalone preview; Export atlas player packs supported images into texture pages. Export package includes the editable rig, original media, playback runtime, runtime source, examples and notices, with an optional atlas. The runtime draws tint, dark colour and blend modes with WebGL or WebGPU. The editor stage and exported player render at the device pixel ratio; runtime scenes can follow it with `resolution: 'auto'` and use optional mipmaps for art drawn well below its texture size. Test the exported result in your game’s own integration.

The included runtime project-use license permits commercial projects, modifications and distribution as part of those projects. Those permissions continue after a ReelGrove subscription ends. Keep the included license and third-party notices; artwork, audio and other third-party rights remain separate. The export license covers the included runtime, not distribution of the hosted editor as a separate product.

Continue with an existing rig

## Import a supported Spine export.

Choose Import Spine in Animation Lab. The supported JSON export profiles are 4.1.17 and 4.2.22. Use files and images you have permission to use. Proprietary `.spine` project files and binary `.skel` exports are not supported.

- Select the JSON and its original PNGs, or its `.atlas` file and PNG pages. Choose folder retains nested image paths. The supported atlas reader handles trimmed regions and quarter-turn rotation, using straight-alpha PNGs and Linear/Linear sampling.

- Review the compatibility result, rig name and canvas origin before importing. If rounded source time handles need an adjustment, the form explains it and requires a separate opt-in; it is never applied silently.

- Choose Import Spine rig. Inspect every clip and skin, scrub key boundaries, then save the editable native rig to your project. The complete insertion can be undone once; Cancel leaves the open rig intact.

The importer supports region attachments; unweighted and supported weighted meshes with deformation; skins and attachment switches; direct linked meshes with supported shared or independent deformation; plain one- and two-bone IK, including partial and animated one-bone mixes within the checked angle and scale limits; static unweighted clipping; and slot drawing-order timelines. Imported bone-local mesh influences remain editable.

Check the compatibility report for your rig.

Support is a tested subset, not complete Spine file or runtime parity. Linked-mesh chains, animated or weighted clipping, clipping combined with drawing-order timelines, advanced IK settings, partial or smoothly changing two-bone IK mixes, unproven one-bone mix angle ranges, path/transform/physics constraints, animated shear, Spine audio events, attachment colours that differ between skins, and unsupported inheritance or timeline features are rejected. Slot colours, two-color tint, blend modes and event int/float/string values are kept in the imported rig, and the editor and exported runtime draw its colours and blend modes. Duplicate source key times are rejected. Simplify or re-export the source, then retry; the importer does not discard those features to force a successful import.

Current document limits include 256 scene nodes, 32 image assets, 256 clips and 20,000 keys across the document. Physics adds its own simulation-work limits, and imported attachment variants can expand one source slot into several native sprites. The compatibility report checks the resulting native document and its media before insertion.

Look at the whole game

## Preview, then read the checks.

Use the private game preview to play with test credits; the preview toolbar keeps Test credits · no cash value in view. The viewport selector in that toolbar offers Desktop (1200×675), Laptop (1024×576), Popout S (400×225), Popout L (800×450), and Mobile L/M/S (425×812, 375×667, 320×568), plus phone portrait, tablet and Fit to window. These presets also appear in the Screen selector of separate game-preview dialogs. The game receives the exact selected pixel dimensions and scales down to fit your workspace; the size readout beside the selector shows the pixel size and any scale. Changing screen size keeps the current session and round. Listen for the cues you changed and watch the saved artwork and motion.

Open the collapsible Session settings sidebar beside the game preview in Frontend, Sound, Art or Animation Lab. Changing currency or starting balance starts a fresh test session. New session starts another with your current settings. Language, device and social settings reload the same session. Check connection reads its current balance and the game’s available bet ladder; it does not reset your credits. Use the reset controls to restore the preview defaults. Focus in the preview toolbar hides the Lab bar and keeps Session settings beside the game; press Esc or choose Exit focus to leave.

### Math

Inspect the published math library, its modes, payout distribution and RTP information. Reports describe the selected published data. Owned projects with hosted math enabled can also [run reviewed experiments](https://reelgrove.net/docs/existing-games/#math-experiments), compare results and explicitly prepare a validated build.

### Frontend

Read each static check and investigate failures in the declared files or resources. Static checks do not include browser execution. Open a captured candidate under Studio release review → Browser observations to inspect retained runs or choose Run saved scenarios on an enabled installation. For a built game with the observer adapter, [run an isolated Chromium replay locally](https://reelgrove.net/downloads/#browser) and retain its result and screenshot.

### Review

Ask a teammate to inspect the actual saved result. A passing static report does not establish that every animation, game event or screen size behaves correctly.

In Frontend → Saved test scenarios, save an exact published outcome and its input identities. Reopen that book to discuss it again; the interactive preview uses current creative state. In Studio release review, capture a candidate with matching scenarios, then collect comments and human approval against that exact version. Changed inputs are marked stale. On installations with hosted execution enabled, the candidate’s [Browser observations](https://reelgrove.net/docs/existing-games/#browser-runs) record isolated runs of its frozen frontend and saved outcomes. A studio approval does not grant Engine approval. [Read the scenario and release workflow](https://reelgrove.net/docs/existing-games/#reviews).

Use [Find a published outcome](https://reelgrove.net/docs/existing-games/#find-outcomes) to search for zero payouts, an inclusive payout range, the published maximum or an exact recorded event type. Results show exact IDs and draw weights, including zero-weight records. Use this outcome fills the capture form; review its name and browser settings, then save explicitly. Searching never runs the game. Observer support follows the starter release in each project; a newer default does not retrofit earlier studio templates.

Use a completed browser observation as a baseline, then [compare it with another retained run](https://reelgrove.net/docs/existing-games/#compare-observations). Review changed payouts, events, errors and screenshots before deciding whether a change fixes the same case. Requested profiles and actions remain separate from recorded browser behavior, so an incomplete failed run can still be compared without implying its controls succeeded.

After changing a build, open a saved scenario and choose Reuse on current build. [Review the current outcome against the original](https://reelgrove.net/docs/existing-games/#carry-forward), including the book, payout, event positions, input identities and profile, then explicitly save the reviewed scenario. The original and its observations remain intact; a reused expectation still needs a new browser run.

Use Frontend → Named regression suites to [group exact saved scenarios under stable case keys](https://reelgrove.net/docs/existing-games/#regression-suites). Save immutable versions, inspect changed inputs and choose the precise version for a release candidate. Open captured release continues into review and separately started browser checks. After a lost response, recover the saved suite request before creating another.

In Frontend → Profile and action matrices, save viewport, locale, motion and action combinations, select exact outcomes and [review every resulting cell](https://reelgrove.net/docs/existing-games/#profile-matrices) before capturing the complete set as a suite. Run that suite separately; unsupported controls stay visible as failed checks.

Use [readiness policies](https://reelgrove.net/docs/existing-games/#release-readiness) to connect structured requirements and an exact suite to a release candidate. Reviewers select the observations and screenshots they inspected, record requirement notes and save a decision with any explicitly permitted exceptions. Earlier evidence remains intact when the project changes.

Game source and general game settings are not editable in the customer Lab. Where import and activation are both enabled, a permitted editor can validate a separately prepared bundle and activate the resulting build through the project’s import workflow.

Give each person the right tools

## Invite your collaborators.

Open Team, enter your teammate’s email and choose a role. Review the permission checkboxes before creating the invitation, then share its invitation link with that person.

Use Art designer, Sound designer, Animator, Frontend developer or Math designer as a starting point. A Studio admin can manage projects and invite or remove teammates. Only the owner can change members’ permissions and manage billing. Studio roles do not grant platform administration access. Review-only members do not consume editor capacity; editing roles do. An active free trial includes three editor seats, including the owner, and free reviewers. A pending invitation does not reserve a seat; one must be available when an editor accepts it.

The presence pill at the end of the Lab bar shows who has the project open. When another person saves a change, the Lab refreshes saved Art and Sound assets while keeping your drafts and game preview open. A small Saved assets refreshed notice appears at the bottom left and closes after about 10 seconds; when Art slots changed, its Show changes lists them as Changed elsewhere. If an operation is still running, the same notice says saved changes are waiting; use Refresh saved assets in it once the operation finishes, or close it with ×. If a save conflicts, review the current binding before deciding what to save next.

Avoid losing an unsaved draft.

Finish or note your draft before reloading or changing project revisions. Collaboration protects saved changes from silent overwrites; it does not merge simultaneous drafts.

### Recover an Animation Lab draft.

Open Project → Recovery on this device to review a tab’s retained draft or unfinished save. Recover session opens the reviewed copy in the current tab; recovery does not automatically send an old save. For a lost save response, use the offered exact-request retry and inspect the confirmed result before saving later edits.

Project history retains saved versions for review and explicit restore. Find earlier revisions locates rigs saved before a project reset. The recovery manager also lets you review, download or explicitly delete local copies from earlier revisions. Copies belong to the same signed-in account and project; current permissions still apply. Browser storage can be cleared, so save to the project or download JSON for a lasting copy.

Take the finished work with you

## Capture and download an export.

- Save the artwork, sounds, Motion presets and Animation Lab rigs you want included. Save any game-animation bindings to the intended rig versions.

- In the Lab, choose the project name at the top left to open the project menu, then choose Export game. You can also choose it on the project in Overview. Select Standalone game, confirm the capture and choose Create export.

- Review the captured project revision and saved change versions. Wait for the export to be ready, then choose Download ZIP.

- Keep the archive and its included source and notices. Build and verify it in your own development environment before submission.

An export captures a point in time. Later Lab changes require another export. Supported exports run independently of ReelGrove; downloading an export does not grant Engine submission approval.

The standalone ZIP includes the captured Art, Sound, Motion and game animation settings, their required media, and saved animation documents as editable JSON files. Import new build cannot restore this ZIP as a complete Lab project.

### Keep an editable project archive.

Retained hosted browser observations include their frozen game inputs, recorded results and screenshots. Failed checks remain part of that evidence. [Offline verification](https://reelgrove.net/downloads/#portable) checks the captured files; imported records do not transfer another studio’s approvals.

Choose Portable project to capture development files, current Lab metadata, all uploaded assets, every retained animation version and branch, review lineage and current-revision scenario and release records. [Verify and unpack it with bundlepack](https://reelgrove.net/downloads/#portable) for offline recovery. Older archives include only their originally captured history.

Portable archives also retain complete profile-matrix history and original readiness policies, decisions and their selected test evidence. Named suite versions retain their exact referenced scenarios, books and captured-revision release links in the portable archive. Imported suite history remains original evidence; a restored project needs its own authorized suite and release decisions.

Where restoration is enabled, [prepare the archive and restore a new editable project](https://reelgrove.net/downloads/#restore-project) through Import existing game. Review the validated candidate and explicitly choose Restore project. Imported decisions remain historical evidence; review and test the destination independently. You can also [create reusable studio kits](https://reelgrove.net/downloads/#kits) for deliberate import through the destination Lab.

If the project menu in your Lab shows Studio kits, [upload a kit, inspect its complete contents and review the destination plan](https://reelgrove.net/downloads/#install-kit). Installation requires a separate confirmation of added files, reused assets, fresh animation identities and storage. Use Recover saved request after an interrupted response. Existing Lab work is preserved; configure new game bindings and review playback yourself.

### Make an independent editable copy.

On installations with cloning enabled, choose Clone project from the project menu at the top left of the Lab. Save open drafts, name the new project and confirm Create editable copy. The copy captures the current source and saved Lab work in the same studio, then validates and restores it before offering Open copied project.

Use Recover saved request after an interrupted reply; it keeps the original capture. Your copy history remains readable when editing expires. Unfinished copies expire after one hour and can offer a separate cancellation confirmation. Imported QA, review and animation history is retained; the new project needs its own tests and approvals. Read the [copy and recovery workflow](https://reelgrove.net/docs/existing-games/#clone-project) for exact limits.

### Edit and rebuild a game locally.

- Choose Development bundle in the export dialog and download the ready ZIP. It contains your current source, preview and production builds, published math and build instructions.

- Extract the ZIP into a private working folder. Follow `source/development/README.md` and the included source instructions to edit and build both frontend targets locally.

- Keep dependency installs and build caches outside the finished bundle. [Download and verify bundlepack](https://reelgrove.net/downloads/) for your Linux or WSL2 environment, then follow its setup instructions to package the completed bundle as a `.tar` file.

- Open Import new build for the same project, upload the TAR, review validation and activate the build when ready. Then check the game in the Lab and preview.

Your uploaded assets and saved Art, Sound, Motion and Animation Lab work stay in the original project. Activate the rebuilt game in that same project to preserve them. Development downloads contain empty Lab overrides and omit animation documents; importing into another project transfers the source, builds and math without that saved Lab work. After activation, check that the new game still declares the hooks needed by your animation bindings. Import and activation must be enabled for your installation and your role.

Keep your place

## If something gets stuck.

### A tool is missing or editing is disabled.

Without current editing capacity, the Lab bar shows a Read-only chip, or Editing ended once your trial or paid editing access has expired. Choose it to read why; it links back to your studio, or to your plan if you manage billing. Ask your studio owner to check your permissions, trial or subscription status, and editor capacity. The Lab only shows disciplines you can read. If access changed while the page was open, a row under the Lab bar says Your access changed; choose Reload workspace or sign in again to refresh it.

### Your connection dropped during an operation.

Return to the same project and inspect the operation’s history and status. Use its offered recovery or retry action. For an uncertain activation, check whether it was admitted before starting another request.

### Animation graphics could not start.

Animation Lab and its exported players need working WebGL or WebGPU support. Enable graphics acceleration in your browser, reload, or try another browser. For complex rigs, hardware acceleration helps keep playback smooth; software rendering can run more slowly. Atlas players can reduce texture switching.

### A preview expired.

Reopen the project’s preview from the Lab. Preview links are private, temporary and tied to your session; share studio invitations with teammates instead of copying a preview URL.

### A preview is taking a while to open.

The game area shows whether the workspace is being prepared, your private preview is starting or its window is loading. If the window is still loading after 30 seconds, you can keep waiting or use Reload in the preview toolbar; a later load clears the message. If the window opens with an error, follow the message shown there.

### An operation says it needs review.

Keep the operation ID, the visible error or status, the time it occurred and a short description of the steps you took. Send them to support@reelgrove.net. The platform administrator can inspect work status; your studio owner does not automatically have platform admin access.

Passwords, recovery links, project keys and private preview URLs are not needed in a problem report.

[Contact support ↗](https://reelgrove.net/support/) · [Return to your studio ↗](https://reelgrove.net/app/) · [MCP setup and troubleshooting ↗](https://reelgrove.net/docs/mcp/) · [Downloads ↗](https://reelgrove.net/downloads/)

Your account

## A sign-in that works for you.

Sign in with your email address and password, or use a passkey you have added to your account. Open [Sign-in & security](https://reelgrove.net/app/#security) to add a passkey after verifying your email. Use a recent sign-in when adding your first passkey, and an existing passkey when adding another.

Your device or password manager handles passkey verification. Platform administrators use a passkey to open the admin panel and confirm individual actions.

If you lose access, choose Forgot password on the sign-in page. Email recovery signs out previous sessions and removes existing passkeys. Add a passkey again once you have recovered your account.

Keep ReelGrove close

## Find us on Google.

Choose [ReelGrove as a preferred source on Google ↗](https://www.google.com/preferences/source?q=reelgrove.net) to help you find our public content in Search. The link opens Google’s source preferences in a new tab. If ReelGrove is available, select it and confirm your choice there.

You can also use Prefer ReelGrove on Google in the site footer. This preference belongs to your Google account; it does not change your ReelGrove account or guarantee that our pages appear in your results.

---

Source: https://reelgrove.net/docs/existing-games/

For teams already building Engine games

# Your game. Your next build.

Keep your repository and build tools. Bring a completed Engine frontend and published math into ReelGrove, refine the creative work together, then validate and activate later builds in the same project.

Independent project imports  Preserved Lab work  CLI and CI uploads  Exact review records

This workflow uses Import existing game where independent imports are enabled. It creates a private project without an approved starter ancestor. You can also [start with a supplied template](https://reelgrove.net/docs/getting-started/); those projects retain their original template rules.

Start from completed files

## Prepare a build from your repository.

Download and verify [bundlepack for Linux or WSL](https://reelgrove.net/downloads/#download). 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.

reelgrove-layout.json · adapt every path and game identity

```
{
  "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.

Run with the verified bundlepack executable on your PATH

```
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.

Declare the creative work your game supports.

The empty slots and cues in this minimal example let you admit a plain game. They do not add Art or Sound controls or wire animation events into its frontend. Your developer must declare supported integration points and connect the game adapters before those changes can appear in play.

Review before making it a project

## Upload, validate, then register.

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.

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.

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](https://reelgrove.net/downloads/#new-project) and [full tool contract](https://reelgrove.net/docs/mcp/#new-project). The separate [portable-restoration commands](https://reelgrove.net/downloads/#machine-restoration) require explicit plan review; [machine cloning has its own explicit capture](https://reelgrove.net/downloads/#machine-cloning).

Use the same reviewed workflow from CI

## Upload with a project key.

Download [studioctl](https://reelgrove.net/downloads/#ci). 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.

Use your Developer access endpoint and one durable receipt per build

```
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](https://reelgrove.net/docs/mcp/#tools) 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](https://reelgrove.net/downloads/#qa) captures and checks scenarios from completed local directories. Use the [isolated Chromium runtime](https://reelgrove.net/downloads/#browser) 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](https://reelgrove.net/docs/mcp/#qa-history) 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](https://reelgrove.net/docs/existing-games/#regression-suites) 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](https://reelgrove.net/docs/existing-games/#carry-forward), 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](https://reelgrove.net/docs/existing-games/#carry-forward); 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](https://reelgrove.net/docs/mcp/#profile-matrices).

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](https://reelgrove.net/docs/existing-games/#release-readiness). 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](https://reelgrove.net/docs/mcp/#release-readiness) 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](https://reelgrove.net/downloads/#browser) 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](https://reelgrove.net/downloads/#math-experiments) 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](https://reelgrove.net/docs/mcp/#math-build-receipts) or use the [CLI examples](https://reelgrove.net/downloads/#build-receipts).

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](https://reelgrove.net/docs/mcp/#math-build-receipts) and [workspace controls](https://reelgrove.net/docs/existing-games/#math-build-evidence) 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:

SDK driver · adapt the game directory

```
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](https://reelgrove.net/docs/existing-games/#limits).

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](https://reelgrove.net/downloads/#portable) 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](https://reelgrove.net/docs/mcp/#project-exports) 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](https://reelgrove.net/downloads/#restore-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](https://reelgrove.net/downloads/#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](https://reelgrove.net/downloads/#install-kit) 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](https://reelgrove.net/docs/mcp/#studio-kits) 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](https://reelgrove.net/downloads/#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](https://reelgrove.net/docs/existing-games/#math-experiments).

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](https://reelgrove.net/downloads/#machine-cloning) 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](https://reelgrove.net/support/).

### Bring the team into one project.

The 7-day trial includes three editors and free reviewers. [Read the trial and setup steps](https://reelgrove.net/docs/getting-started/#start).

[Open studio ](https://reelgrove.net/app/)

---

Source: https://reelgrove.net/docs/mcp/

Your workspace, connected

# Work with your game through MCP.

Give your assistant access to one private project. Inspect assets and math, edit native animation documents, bind saved versions to declared game hooks, or upload and activate a prepared build for an existing owned project.

122 live project tools  Streamable HTTP  Project-key authentication

Model Context Protocol (MCP) lets a compatible client discover and call ReelGrove’s tools. You choose which project it can reach and what it can change. ReelGrove checks that access on every call.

Start with read access.

Connect, ask the client to identify the project, and inspect its current state. Add write scopes only for the work you want it to perform.

Setup

## Three steps to your first call.

### Open Developer access

Sign in to ReelGrove and open [Developer access](https://reelgrove.net/app/#developer), or choose Help → Connect an agent in a project’s Lab. Select the studio that contains your game. You need a ready project and current project-read permission.

### Create a project key

Choose the project, give the key a recognizable name, and select its scopes. Expiry defaults to 7 days; you can choose 1–30 days. Save the secret from the one-time dialog.

### Add a manual HTTP connection

In your MCP client, choose a remote Streamable HTTP server. Copy the endpoint from Developer access and add the authorization header below. Then connect and ask for `project_context`.

Server URL

Your account’s origin followed by `/mcp`

Transport

Streamable HTTP

Header name

`Authorization`

Header value

`Bearer YOUR_PROJECT_KEY`

For example, an account at `https://studio.example` uses `https://studio.example/mcp`. Use the actual endpoint shown in your account; this example host is a placeholder.

Client configuration formats differ. Enter the URL and header in your client’s manual settings; there is no universal configuration JSON or OAuth sign-in flow for this endpoint. A client that only supports OAuth cannot use a project key through that flow.

Keep the secret in your client’s credential settings. Do not put it in a URL, a prompt, source control, or a shared screenshot. Signing into ReelGrove in a browser does not authenticate an MCP client.

Access

## Give the client a specific job.

Every key includes `projects:read`. Choose the additional scopes its task needs. Developer access includes matching read scopes for discipline writes. Whole-game import access (`projects:import`) includes project read and every Art, Sound, Motion, Math and Frontend read/write scope; existing keys keep their original scopes.

### Review artwork

`projects:read` `art:read`

Inspect slots and existing image assets without changing bindings.

### Work on sound

`projects:read` `sound:read` + `sound:write`

Upload audio, bind cues and set their volume.

### Review math

`projects:read` `math:read`

Read the available published libraries and their reports.

A key can never grant more access than its creator currently has. Its saved scopes are an upper limit, including for a studio owner. Membership changes and permission reductions take effect on later calls. The capabilities returned by `project_context` describe this intersection; they do not confirm current trial or paid editing capacity.

Keys do not use extra seats.

Art, Sound and Motion edits and owned-build mutations use the creator’s current editing access and require an active trial or subscription with enough editor capacity. Saving QA scenarios and release candidates uses review comment permission and does not require an editor seat. New capture, browser execution and analysis follow current trial access rules. Retained scenarios, candidates and execution results remain readable after a trial expires, with all their required read permissions.

Reference

## Customer project tools.

The hosted service provides 122 project tools. They cover creative work, exact QA history, profile matrices, read-only readiness assessment, exports, hosted math and browser observations, and explicit project creation, restoration, cloning and kit installation. Current permissions and feature availability are checked on every call.

Run `project_context` first. Use its `project.activeRevision` wherever the tool requires `expectedActiveRevision` or `expectedAnchorRevision`. Build status and chunk calls use the admission ID returned by their original request. The key selects the project; do not send a game, studio, project, actor, or filesystem path.

All calls require projects:read. Developer access includes matching reads when you select write scopes.

Tool

What it does

Additional scope

`project_context`

Current project, active revision and effective capabilities.

None

`get_project_clone_context`

Read current source and copying availability.

Current actor and source read access

`start_project_clone`

Capture the saved source into a distinct reserved project, or recover the exact original request.

Creation/import/export scopes and editing capacity for new captures

`get_project_clone`

Recover the original source, destination and copy status.

Current actor and source read access

`list_project_clones`

Find at most 50 actor-owned copies or an exact saved request.

Current actor and source read access

`cancel_project_clone`

Request guarded asynchronous cleanup of permitted unfinished work.

Current actor and source read access

`get_project_restoration_context`

Inspect the portable attachment and exact plan digest of a reserved creation.

Current actor and anchor read access

`start_project_restoration`

Explicitly restore the reviewed plan into its reserved destination with a saved request UUID.

Original creation key, complete creation/import scopes and editing capacity

`get_project_restoration`

Recover the original destination, plan and status.

Current actor and anchor read access

`list_project_restorations`

Find only this actor’s restoration history at the current key’s anchor.

Current actor and anchor read access

`cancel_project_restoration`

Request guarded cleanup of permitted unfinished work, including after editing expires.

Current actor and anchor read access

`get_qa_history_usage`

Read separate working and retained QA usage and limits.

All five discipline reads

`archive_scenario`

Explicitly archive an exact saved scenario, preserving its evidence and references.

All five discipline reads, reviews:comment and current editing capacity

`archive_release`

Explicitly archive an exact candidate, preserving reviews and observations.

All five discipline reads, reviews:comment and current editing capacity

`begin_owned_project`

Reserve a distinct project from an exact initial contract and TAR identity.

projects:create and the complete import scope set; original key

`write_owned_project_chunk`

Upload one verified chunk to the original reservation.

Complete creation/import scopes; original key

`validate_owned_project`

Explicitly queue isolated validation.

Complete creation/import scopes; original key

`register_owned_project`

Explicitly register the validated source with a separate request UUID.

Complete creation/import scopes for a new registration; original key

`get_owned_project`

Read your retained reservation and progress at this authorization anchor.

None

`list_owned_projects`

List your creation history or recover one exact request UUID.

None

`cancel_owned_project`

Cancel permitted unfinished work with current read access.

None

`create_project_export`

Capture a standalone, development or portable archive using one durable request UUID.

`projects:export` and all five discipline reads

`list_project_exports`

Page through your retained exports in this project.

`projects:export` and all five discipline reads

`get_project_export`

Read an exact job and its completed archive hash and byte count.

`projects:export` and all five discipline reads

`read_project_export_chunk`

Download verified chunks with current access checked on every request.

`projects:export` and all five discipline reads

`cancel_project_export`

Cancel your export and revoke further delivery.

`projects:export` and all five discipline reads

`get_kit_context`

Discover kit upload and installation availability and limits.

None

`begin_kit_upload`

Begin or recover an exact selected-file kit ZIP upload.

Selected Art, Sound or Motion reads and writes

`write_kit_upload_chunk`

Send a verified chunk at the committed decimal-string offset.

Selected discipline reads and writes; original key

`inspect_kit_upload`

Verify the complete archive and retain a separate inspection.

Selected and embedded discipline reads and writes; original key

`get_kit_upload`

Read your exact upload, progress and retained inspection.

Selected discipline reads

`list_kit_uploads`

List your uploads or recover one exact request UUID.

Selected discipline reads

`cancel_kit_upload`

Cancel unretained work with verified cleanup.

Selected discipline reads

`plan_kit_installation`

Review exact additions, reused media and storage before installation.

Selected and embedded discipline reads and writes; original key

`install_kit`

Explicitly confirm the reviewed plan hash using a separate UUID.

Selected and embedded discipline reads and writes; original key

`get_kit_installation`

Read your retained installation and exact original plan.

Selected and embedded discipline reads

`list_kit_installations`

List your installations or recover an exact planning request.

Selected and embedded discipline reads

`cancel_kit_installation`

Cancel unfinished owned work without removing retained Lab assets.

Selected and embedded discipline reads

`list_assets`

List image or audio asset metadata; choose `assetClass`.

`art:read` for image; `sound:read` for audio

`read_asset`

Read one listed asset as base64, up to 4 MiB.

`art:read` for image; `sound:read` for audio

`upload_asset`

Upload verified image or audio bytes, up to 4 MiB.

`art:write` for image; `sound:write` for audio

`art_slots`

Declared artwork slots, bindings and their revisions.

`art:read`

`sound_cues`

Declared cues, mixes and binding revisions.

`sound:read`

`bind_image`

Assign an uploaded image or restore a slot’s build default.

`art:write`

`bind_sound`

Assign audio, set its volume, or restore a cue’s build default.

`sound:write`

`list_motions`

Declared states, supported settings and saved Motion revisions.

`motion:read`

`set_motion`

Save supported Motion settings or restore the build default.

`motion:write`

`list_animation_revisions`

Page through retained project revisions containing animation documents.

`motion:read`

`list_animation_documents`

List document heads in the current or a selected retained revision.

`motion:read`

`get_animation_document`

Read exact native JSON and media provenance, up to 4 MiB.

`motion:read` and all embedded-media reads

`list_animation_versions`

Page through immutable version metadata for one document.

`motion:read`

`get_animation_version`

Read one exact retained document version, up to 4 MiB.

`motion:read` and all embedded-media reads

`save_animation_document`

Save admitted native JSON with its digest, observed sequence and request UUID.

`motion:write`; media permissions below

`restore_animation_version`

Append a new version from retained history without overwriting earlier work.

`motion:write` and embedded-media reads

`get_animation_save_result`

Recover the creator’s exact save or restore receipt by request UUID.

`motion:read`

`list_animation_scenarios`

Inspect source-verified game hooks, declaration hashes and current bindings.

`motion:read`

`get_animation_binding`

Read a current or retained binding and whether its hook remains available.

`motion:read`

`list_animation_binding_versions`

Page through immutable set and clear history for a hook.

`motion:read`

`set_animation_binding`

Pin a saved version and clip or mix to an exact source declaration.

`motion:write` and selected-media reads

`clear_animation_binding`

Append an explicit clear while retaining binding history.

`motion:write`

`get_animation_binding_save_result`

Recover the creator’s exact set or clear receipt.

`motion:read`

`list_math_libraries`

Published math available in this project revision.

`math:read`

`math_report`

Outcome weights and report evidence for a published variant.

`math:read`

`calculate_math`

Return, variance, sample size, hits, streaks, exposure, wagering and cash-flow calculators.

`math:read`

`compare_math_modes`

Compare published variants and modes within this project revision.

`math:read`

`simulate_math_sessions`

Reproducible session simulation from exact project weights or an uploaded CSV.

`math:read`

`analyze_bet_archive`

Analyze a submitted CSV or JSON bet archive in one currency.

`math:read`

`verify_math_seed`

Check a revealed MGRGS seed commitment and draw; this is not a generic slot verifier.

`math:read`

`get_engine_tracker`

Search all tracked games and providers, including artwork URLs and activity statistics.

`math:read`

`search_engine_games`

Search public live-game catalog and version metadata.

`math:read`

`find_scenario_outcomes`

Search current published books by zero payout, inclusive payout range, published maximum or exact recorded event type.

Art, Sound, Motion, Frontend and Math read

`list_scenarios`

List saved QA scenarios and independently stale source, math and creative inputs.

Art, Sound, Motion, Frontend and Math read

`get_scenario`

Read a saved scenario and its exact original event trace.

Art, Sound, Motion, Frontend and Math read

`capture_scenario`

Save a published outcome with server-derived source, asset, cost and payout commitments.

All five discipline reads, plus `reviews:comment`

`prepare_scenario_carry_forward`

Inspect an exact saved expectation against a selected current outcome and profile without saving.

All five discipline reads, plus `reviews:comment`

`carry_forward_scenario`

Save the freshly rechecked target and immutable parent link using the reviewed plan digest.

All five discipline reads, plus `reviews:comment` for new saves

`list_regression_suites`

List each named suite’s current saved version.

Art, Sound, Motion, Frontend and Math read

`list_regression_suite_versions`

Page through the immutable history of one suite.

Art, Sound, Motion, Frontend and Math read

`get_regression_suite`

Inspect an exact version, its selected scenarios and stale inputs.

Art, Sound, Motion, Frontend and Math read

`save_regression_suite`

Save a new suite version with 1–32 exact scenario references and stable case keys.

All five discipline reads, plus `reviews:comment` for new saves

`capture_regression_suite_release`

Capture a candidate from an exact suite version whose expectations match current inputs.

All five discipline reads, plus `reviews:comment` for new captures

`list_readiness_policies`

Discover current immutable readiness policies.

Art, Sound, Motion, Frontend and Math read

`list_readiness_policy_versions`

Page through the retained versions of one policy.

Art, Sound, Motion, Frontend and Math read

`get_readiness_policy`

Inspect an exact policy and its verified regression suite.

Art, Sound, Motion, Frontend and Math read

`assess_release_readiness`

Recompute readiness from explicitly selected observations and optional prior human assertions.

Art, Sound, Motion, Frontend and Math read

`get_readiness_review`

Verify one original human decision and its exact evidence; show current staleness separately.

Art, Sound, Motion, Frontend and Math read

`list_readiness_reviews`

Page through verified human decisions for one candidate.

Art, Sound, Motion, Frontend and Math read

`list_profile_matrices`

Discover current named matrix versions.

Art, Sound, Motion, Frontend and Math read

`list_profile_matrix_versions`

Read immutable version history for one matrix.

Art, Sound, Motion, Frontend and Math read

`get_profile_matrix`

Inspect one exact saved profile/action definition.

Art, Sound, Motion, Frontend and Math read

`save_profile_matrix`

Save 1–32 explicit combinations against the exact current head.

All five discipline reads, plus `reviews:comment` for new saves

`prepare_profile_matrix_expansion`

Review every exact selected outcome times every saved combination, at most 32 cells.

Art, Sound, Motion, Frontend and Math read

`capture_profile_matrix_expansion`

Save all reviewed cells and one ordinary suite version atomically.

All five discipline reads, plus `reviews:comment` for new captures

`get_profile_matrix_expansion`

Read an exact captured matrix, source provenance and all current stale markers.

Art, Sound, Motion, Frontend and Math read

`list_profile_matrix_expansions`

Page through complete retained captures for one matrix.

Art, Sound, Motion, Frontend and Math read

`begin_owned_build`

Begin or recover an exact prepared TAR upload for this existing owned project.

`projects:import` and all discipline reads/writes

`write_owned_build_chunk`

Upload one verified chunk, at most 1 MiB, at the committed offset.

`projects:import` and all discipline reads/writes

`get_owned_build`

Read admission, upload progress and validation status.

None

`validate_owned_build`

Explicitly queue isolated structural and math validation.

`projects:import` and all discipline reads/writes

`cancel_owned_build`

Cancel an unretained admission when no unfinished activation uses it.

None; admission actor or studio owner required

`activate_owned_build`

Explicitly preserve the current Lab revision and activate a validated build.

`projects:import` and all discipline reads/writes

`get_owned_build_activation`

Read an owned build’s activation result, including completed retries.

None

`capture_release`

Capture current inputs, requirements and up to 32 matching saved scenarios for review.

All five discipline reads, plus `reviews:comment`

`list_releases`

Page through retained candidates and their stale inputs.

All five discipline reads

`get_release`

Read exact candidate evidence and historical human decisions.

All five discipline reads

`start_release_execution`

Freeze a candidate and queue its selected scenarios for isolated browser observation, when enabled.

All five discipline reads, plus `reviews:comment`

`list_release_executions`

List retained browser runs for one candidate.

All five discipline reads

`get_release_execution`

Read execution status and verified observation receipts.

All five discipline reads

`compare_release_observations`

Compare two exact retained runs, including earlier revisions, with input, event, payout and screenshot pixel differences.

All five discipline reads

`cancel_release_execution`

Stop unfinished work while retaining completed observations.

All five discipline reads, plus `reviews:comment`

`retire_release_execution`

Request removal of execution files after cleanup; immutable identities remain.

All five discipline reads, plus `reviews:comment`

`find_math_experiment_outcomes`

Search exact retained generated books by zero payout, inclusive range, maximum or recorded event, before promotion.

`math:read`

`math_experiment_context`

Inspect exact owned source inventory, modes and enabled execution profiles.

`math:read`

`submit_math_experiment`

Run explicitly reviewed source with a fixed seed and bounded resources, when enabled.

`math:write` and current editing capacity

`get_math_experiment`

Read retained status and independently validated report bytes.

`math:read`

`list_math_experiments`

List retained experiment history for this project.

`math:read`

`compare_math_experiments`

Compare two validated distributions using exact probabilities and rational deltas.

`math:read`

`get_math_build_receipt`

Read exact native build evidence and its SHA-256 from a retained completed job.

`math:read`

`compare_math_build_receipts`

Compare selected bytes, measured recipe and outputs of two retained builds; only distinct eligible observations can establish that two clean runs matched.

`math:read`

`cancel_math_experiment`

Cancel work and request guarded result removal.

`math:read`; submitting actor or studio owner

`promote_math_experiment`

Prepare a result as an ordinary owned build for independent validation and separate activation.

`projects:import`, all discipline reads/writes and current editing capacity

`cancel_math_promotion`

Cancel unfinished build preparation and its incomplete upload.

`math:read`; submitting actor or studio owner

Discovery describes the tool contract. Hosted math and browser execution require separately enabled workers; a listed tool does not confirm installation availability or permission. Source inventory paths are returned by the server and can only select files inside the retained owned project.

Workflows

## Ask clearly. Check the result.

These are prompts you can give your connected assistant, followed by example MCP `tools/call` parameters. They are tool calls, not client configuration files.

### Inspect the project before making changes

Identify the project this key belongs to. List its artwork slots and current image assets. Tell me which images are replaced. Don’t change anything.

First call

```
{
  "name": "project_context",
  "arguments": {}
}
```

Read `project.activeRevision` from the result. The UUID below is illustrative: replace it with that exact value. Slot and cue names must come from the current registry.

Read declared artwork slots

```
{
  "name": "art_slots",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111"
  }
}
```

Then call `list_assets` with the same revision and `assetClass: "image"`. Use a returned `assetId` to read or bind an asset.

### Replace artwork, or restore it deliberately

Read the current circle binding, upload the supplied PNG, replace that slot using the latest observed revision, then reread to confirm. Stop on a conflict.

`upload_asset` takes `assetClass`, `filename`, base64 `data`, and its matching lowercase SHA-256 in `sha256`, plus the active revision. Uploading makes an asset available; `bind_image` assigns it to a declared slot.

For a replacement, send the returned `assetId`. For a restore, use `restoreDefault: true` instead. The example assumes the current registry declares `circle` at binding revision `"3"`:

Restore one artwork slot

```
{
  "name": "bind_image",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111",
    "slot": "circle",
    "expectedRevision": "3",
    "restoreDefault": true
  }
}
```

People watching the project’s Lab, or returning to it in the same browser, see slots saved with your key marked Changed elsewhere in Art Lab, with a time, until they open the slot or choose Mark all seen. The Lab does not say whether a person or an agent made the save. With Auto preview on, the saves apply to an open Lab’s running preview on builds that support live updates; the Lab never restarts the game for them. A saved bind does not prove the game draws the image, so ask a person to check the preview. In the Lab, Copy brief gives your assistant a starting point for up to 60 shown slots, with their sizes, binding revisions and these argument names.

### Set a sound cue’s level

Inspect the spin cue and its current audio. Keep the same take, set its gain to 45%, and confirm the saved binding. Stop if another person changes the cue first.

Call `sound_cues`, then `bind_sound` with `cue`, the existing `assetId`, the observed `expectedRevision` and integer `volumePpm: 450000`. The range is 0–1,000,000; one million means full volume. Omitting `volumePpm` uses the cue’s declared default gain, so send it explicitly when preserving a mix. It cannot accompany `restoreDefault`.

### Adjust a declared Motion state

Read the circle slot’s supported Motion settings. If its idle state allows this, save a gentle 1-second bob at intensity 550, with sineInOut easing and looping. Use the current saved revision. Tell me what changed and how to sample it in Art Lab.

Start with `list_motions`. Each build declares its own supported presets, timing and intensity limits. This example only applies when the returned idle capabilities permit these settings:

Save Motion with all settings explicit

```
{
  "name": "set_motion",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111",
    "slot": "circle",
    "state": "idle",
    "expectedRevision": "0",
    "settings": {
      "preset": "bob",
      "durationMs": 1000,
      "intensity": 550,
      "easing": "sineInOut",
      "loop": true
    }
  }
}
```

A successful save confirms persisted settings. To check rendering, open the project’s Art Lab and sample the saved Motion state. The MCP save itself does not prove that an animation rendered.

### Understand the published math

List the published math libraries and summarize the default variant’s theoretical return, outcome weights and evidence gaps. Separate what the report measures from anything it does not prove.

Read the default report

```
{
  "name": "math_report",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111"
  }
}
```

Call `list_math_libraries` first. For another published variant, add its exact name as `variant`. Omitting it, or sending an empty string, selects the default. A report does not certify game-event correctness or external platform approval.

QA review

## Keep an exact scenario.

Give the key `projects:read`, `art:read`, `sound:read`, `motion:read`, `frontend:read` and `math:read` to inspect scenarios. Add `reviews:comment` to save one. This does not use an editor seat.

Call `capture_scenario` with the active revision, a fresh `requestId` UUID, a short `name`, the exact published `mode` and decimal-string `bookId`. Add `variant` for a named math variant and `profile` for expected dimensions, currency, language, reduced motion and ordered actions.

ReelGrove reads the published outcome and computes the source and creative commitments. Saving records an expectation; it does not execute the browser or approve a game. After a timeout, retry the exact UUID and payload to recover the saved receipt. Reusing the UUID with changed arguments conflicts.

`list_scenarios` returns up to 50 records and a `nextOffset` for paging. Use `get_scenario` with a returned `scenarioId` to read exact original events and current stale components. An older trace remains reviewable after a reset; it is not evidence that the current game passed QA.

Select a regression case

## Find a published outcome before saving it.

Call `find_scenario_outcomes` with the current `expectedActiveRevision`, published `mode`, optional `variant` and one explicit `kind`. It uses the same [outcome finder as the workspace](https://reelgrove.net/docs/existing-games/#find-outcomes), with project read and all five discipline reads. Search remains available after editing expires; `canCapture` separately reports current capture access.

- `SCENARIO_OUTCOME_KIND_LOSS`: payout is exactly zero.

- `SCENARIO_OUTCOME_KIND_PAYOUT_RANGE`: supply inclusive `minPayoutX100` and `maxPayoutX100` as decimal strings. For 5× through 100× base stake, use `"500"` and `"10000"`.

- `SCENARIO_OUTCOME_KIND_MAXIMUM`: the largest published payout, including records with zero draw weight.

- `SCENARIO_OUTCOME_KIND_EVENT`: supply an exact recorded `eventType`. Names do not establish feature behavior.

Send only the fields for your selected filter. Each page contains at most 32 numeric-ID-ordered summaries with exact string IDs, payouts and draw weights, plus book hashes and event counts. Zero-weight records are not drawn by weighted selection; you can still choose one explicitly for replay review.

To continue, copy `nextAfterBookId` into `afterBookId` and copy `mathSha256` into `expectedMathSha256`, preserving the same filter and revision. The hash is required for continuation. Start a new search if published math changes. Keep IDs and payout bounds as strings, including values above JavaScript’s safe integer range.

outcomes.json — replace the revision with project_context’s active revision

```
{
  "expectedActiveRevision": "CURRENT_REVISION_UUID",
  "mode": "base",
  "kind": "SCENARIO_OUTCOME_KIND_MAXIMUM"
}
```

Run with a protected project key file

```
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  call find_scenario_outcomes -args-file outcomes.json
```

Searching does not save a scenario, open a preview or run a game. Explicitly call `capture_scenario` with a selected mode, variant and book ID after reviewing its name and browser profile. Capture reads the current book again; the search response is not a frozen expectation or browser evidence.

Regression workflow

## Carry an expectation into the next build.

Read the original with `get_scenario`, then call `prepare_scenario_carry_forward` with its `sourceScenarioId` and exact `sourceScenarioSha256`, the current `expectedActiveRevision`, a target `name`, published `mode` and `bookId`, and optional `variant` and `profile`. The server reads the current book independently; an old outcome identifier does not promise the same events in new math.

Inspect the returned `plan` and exact target `eventsJson`. Input changes, event positions, payout, selection and profile comparisons are separate. Equal payouts can still have different symbols or feature events. The plan always records `browserEvidence: "not_recorded"`.

To retain the expectation, call `carry_forward_scenario` with that exact preparation request inside `target`, a new durable `requestId` UUID and the plan’s `sha256` as `reviewedSha256`. The server checks the target again before saving both the new scenario and its parent link. Changed inputs require a fresh review; the original remains unchanged.

After a lost reply, retain the UUID and identical arguments. If the active revision changes, use `get_scenario` with the request UUID as `scenarioId` and the current revision to recover a historical save. An absent receipt does not prove an outstanding request cannot commit. Completed identical requests remain recoverable after review permission or editor capacity expires, provided all current read scopes still apply. New saves require current review access and available studio resources.

The saved scenario is an expectation for a later release execution. It does not prove the new build passed, create named suite membership, or approve a release. The [account QA workflow](https://reelgrove.net/docs/existing-games/#carry-forward) provides the same review and retained history.

Repeatable QA

## Keep a named set of exact expectations.

Use `list_regression_suites` to find each suite’s current head, `list_regression_suite_versions` to follow its `nextOffset` history, and `get_regression_suite` with an exact `suiteId` and `versionId` to inspect its definition and each case’s stale inputs. Keep the current `expectedActiveRevision` on every call, including historical reads.

`save_regression_suite` takes a `suiteId`, a new durable `requestId`, `name`, optional multiline `description`, and 1–32 `cases`. Each case contains a short stable `key`, an exact saved `scenarioId` and its lowercase `scenarioSha256`. Case keys and scenario selections must be distinct. For a new suite, omit both `expectedVersionId` and `expectedVersionSha256`; later saves must supply both values from the current head. Every save appends an immutable version.

To capture a candidate, call `capture_regression_suite_release` with the chosen `suiteId`, `versionId`, `versionSha256`, a new durable `requestId`, `title` and optional multiline `requirements`. Every case must still match current inputs. Changed expectations need reviewed replacement scenarios and a new suite version. A captured candidate remains linked to its original version even after later suite edits.

New saves and captures require all five discipline reads, `reviews:comment` and current trial resource access, without an editor seat. Retry an uncertain operation with its exact original UUID and arguments; a changed body conflicts. Completed exact retries and history remain available after trial expiry or comment permission removal while all current reads still apply. After a project revision changes, recover a saved version using its request UUID as `versionId`, or a candidate using `get_release`, with the current revision.

Suite capture saves expectations. Start native observations separately with `start_release_execution` using the returned release ID and candidate digest, then inspect or compare the retained results. Saving a suite or candidate never creates a browser pass, human release decision or Engine approval.

Complete regression coverage

## Every selected outcome. Every saved profile.

The matrix workflow saves explicit viewport, currency, language, reduced-motion and ordered-action combinations. It applies every combination to every exact selected saved outcome, with a maximum of 32 cells. A matrix records expectations; an isolated browser run supplies observations.

### Save an exact profile version

Use `save_profile_matrix` with a durable `matrixId`, `requestId`, name and 1–32 `combinations`. Each contains a stable `key` and a scenario `profile`. Preserve the action array’s order. For later versions, send both observed `expectedVersionId` and `expectedVersionSha256`; previous versions remain unchanged.

### Prepare the complete set

Call `prepare_profile_matrix_expansion` with that exact `matrixId`, `versionId`, `versionSha256`, a new durable `requestId` and selected `outcomes`. Each outcome has a stable `key`, original `scenarioId` and `scenarioSha256`. Repeated captures also pin both current `expectedSuiteVersionId` and `expectedSuiteVersionSha256`. Inspect every returned cell and its original provenance.

### Capture, then run deliberately

Send the unchanged prepared request as `target` and its plan digest as `reviewedSha256` to `capture_profile_matrix_expansion`. Every case and one suite version are saved together. Use that returned version with `capture_regression_suite_release`, then start its execution separately. There is no automatic run, math promotion or human approval.

Keys use up to 31 lowercase letters, numbers, underscores or hyphens. Changed original inputs must first be reviewed through scenario carry-forward. Too many cells, stale outcomes or unsupported runner profiles reject the complete preparation; no cells disappear silently. The runner currently accepts `replay`, `wait:complete`, `skip` and `turbo` in the saved order, with viewports up to 4096 pixels per dimension. Actual game support is checked during each isolated run, where unsupported controls remain explicit failed results.

All operations require project and every discipline’s read access. New versions and captures also need `reviews:comment` and current studio resources, without an editor seat. Retained reads and exact completed retries remain available after resource expiry under current key authority. Keep the original request UUID and body after an uncertain reply; read its exact version or expansion before another mutation. Human decisions remain in the account workflow.

new owned projects

## Reserve a separate project from your build pipeline.

Explicit `projects:create` access lets a key on an existing project upload an initial-contract TAR, request isolated validation and register a distinct new project. It requires the complete import scope set and current editor access. Existing import keys keep their original scopes.

The selected project is the authorization anchor. Its source stays unchanged, and the key gains no ordinary access to the destination. Issue a separate destination key in Developer access for later automated editing. Portable restoration adds a separate explicit plan review below; [machine cloning uses a separate explicit capture](https://reelgrove.net/docs/mcp/#project-cloning).

Call `project_context` first and send its current revision as `expectedAnchorRevision`. Keep the begin request UUID, exact archive and returned admission ID; use a separate UUID for explicit registration. A later anchor edit can change this authorization precondition on an exact retry without changing the original reservation. Same-actor replacement read keys can inspect or cancel permitted work and recover completed registration; unfinished writes require the original key.

The [studioctl owned-project workflow](https://reelgrove.net/downloads/#new-project) saves private retry receipts before new effects. Upload never validates or registers automatically.

explicit portable restoration

## Review a portable plan before creating its editable copy.

Prepare a portable archive, upload its TAR through `owned-project`, and validate it. `get_project_restoration_context` returns its exact archive and plan digests. Start only with the reviewed `planSha256` and a separately saved request UUID; the worker verifies the complete capsule before copying.

All five calls use the current `expectedAnchorRevision`. The original creation key owns new effects; a replacement read key for the same actor and anchor can recover or request permitted cleanup. A changed anchor revision never recaptures the destination. Imported reviews remain unattested, and later automated editing needs a separately issued destination key.

Use the [CLI inspection, explicit start and status commands](https://reelgrove.net/downloads/#machine-restoration). Inspection and polling never start work automatically. Keep both receipts after an uncertain response.

copy saved work

## Keep the exact source behind each copy.

`start_project_clone` copies the current saved source and Lab state into a different project in the same studio. Supply the current `expectedActiveRevision`, immutable `sourceRevision`, name and saved request UUID. New captures require creation, import and export scopes with current editing capacity. A context read starts no work.

Keep the source revision, name and request UUID after an uncertain reply. On an accepted retry, use the current authorization revision while preserving the original source revision. The result returns the same captured build and destination. A changed semantic request is refused; recovery never silently copies a newer source.

The original key owns unfinished effects. A same-actor replacement read key can recover accepted history and request permitted cleanup, including after editing expires. The destination needs its own separately issued key. Imported history grants no destination approval. Use the [durable clone CLI workflow](https://reelgrove.net/downloads/#machine-cloning).

reusable creative work

## Review a kit before installing it.

Twelve scoped tools bring the existing [Studio kits workflow](https://reelgrove.net/downloads/#install-kit) to MCP. The key selects one existing project; every call names its current revision. Selected artwork, sound and animations use their matching permissions, including media embedded in animation documents.

- Check `get_kit_context`, then persist the exact ZIP hash, decimal byte count, selected inventory paths and a request UUID before `begin_kit_upload`.

- Upload verified 1 MiB chunks at the committed offset, then explicitly call `inspect_kit_upload`.

- Persist another UUID and call `plan_kit_installation`. Review the exact added or reused media, fresh animation identities and storage charge.

- Confirm that reviewed `planSha256` with a separate persisted UUID through `install_kit`. Refresh the Lab, inspect playback and configure bindings explicitly.

Get and list tools recover your original receipts; list calls accept either a cursor or the exact planning/upload request UUID. A lost response keeps the same request, archive and plan. Upload and plan deadlines remain 30 minutes, including rate-limit pauses. Completed and expired receipts remain readable with current permissions after editing expires.

Continuing work requires its original live key. A replacement key for the same actor and project can read or cancel authorized history, but cannot adopt an upload or installation. Completed installations and restored review holds stay protected. Imported content remains an unverified source claim; installation creates no bindings, rendered-pass result or release approval.

project archives

## Keep a verified copy from CI.

Export tools use a key with `projects:export`, project read and Art, Sound, Motion, Frontend and Math read access. Existing keys keep their original permissions. Each operation stays within the key’s project and its creator’s own export history.

Call `create_project_export` with the current `expectedActiveRevision`, a new durable `requestId` and `kind`: `PROJECT_EXPORT_KIND_STANDALONE`, `PROJECT_EXPORT_KIND_DEVELOPMENT` or `PROJECT_EXPORT_KIND_PORTABLE`. Repeat the same request after an uncertain response. Poll `get_project_export` using the returned `exportId` until it is ready.

Download to a fresh file in your private workspace

```
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  export download -export-id EXPORT_UUID -expected-revision CURRENT_REVISION_UUID \
  -output /private/project-backup.zip
```

The CLI verifies each chunk and the complete archive’s SHA-256 before creating the destination file, and never overwrites an existing file. It pauses and retries the same read when admission is busy. Downloads allow 30 minutes by default, with an explicit timeout up to one hour. Archives are limited to 2 GiB and expire after 24 hours; job history lasts seven days. A reset or newly activated revision prevents downloading a capture from the previous revision. Download before switching builds.

Revoking or expiring the requesting key stops its unfinished export work. A new authorized key can recover its creator’s retained history without replacing the original request. `cancel_project_export` revokes delivery; storage cleanup can finish later. This scope grants no project creation, restoration, kit installation or release approval.

Readiness and CI

## Inspect the exact evidence behind a decision.

Six read-only tools connect the account’s structured readiness policies and human reviews to your assistant and CI. They require project read plus Art, Sound, Motion, Frontend and Math read access. Editing access can expire while those authorized historical reads remain available.

Discover policies with `list_readiness_policies`, follow `list_readiness_policy_versions`, and inspect an exact `versionId` with `get_readiness_policy`. The returned suite is the version selected by that policy. Use `get_release` and `get_release_execution` to inspect a candidate and its observed runs.

`assess_release_readiness` takes the current `expectedActiveRevision`, exact `releaseId` and `candidateSha256`, and an explicit `observations` array. Select up to 32 distinct runs using each `executionId`, `runId` and lowercase `receiptSha256`. An empty array records missing observations. The tool never chooses a passing run automatically.

Optionally supply `retainedReviewId` to reuse the original human assertions for this same candidate. The server verifies that review and its evidence first. Omit it to leave human requirements unrecorded. Machines cannot supply their own requirement resolutions, browser verdicts, exceptions or approval. Use `get_readiness_review` and `list_readiness_reviews` for immutable decisions and separate current stale markers.

Save the exact selected arguments in readiness-selection.json

```
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  call assess_release_readiness -args-file readiness-selection.json > readiness-result.json
```

Stop CI on a command error. A successful call can still return `report.ready: false`: inspect that field and every reported check. Keep the exact selection, report and its SHA with your build artifacts. A human exception preserves the failed check, so it cannot pass a strict all-checks-pass gate. Policy changes and human decisions stay in the account review workflow; a computed ready report creates no studio or Engine approval.

Animation workflow

## Edit a document. Pin the version you reviewed.

Use `list_animation_documents` and `get_animation_document` to inspect the exact saved native document. `list_animation_revisions` discovers retained revisions; pass a returned UUID as `projectRevision` while keeping the current `expectedActiveRevision`. Follow `nextCursor` on history lists.

To save, send `documentId`, base64 native `json`, its lowercase `sha256`, the observed `expectedSequence` as a decimal string, and a new durable `requestId` UUID. Explicit `"0"` creates the first head. Native document validation still applies to documents up to format version 13, including tint, dark colour, blend modes, clip `loop` and `tags`, and event values; use [Animation Lab](https://reelgrove.net/docs/getting-started/#animation) to author visually and inspect the result. A rejected document returns `invalid_argument` with an `issue` naming the first fault’s JSON `path` (for example `animations[0].tracks[3].keys[2].easing`), reason `code`, `message` and any `suggestion`. Nothing is saved; fix that field and save again.

Every embedded image needs `art:read`, and every embedded sound needs `sound:read`, including unused assets. Introducing new bytes also needs that discipline’s write scope. Existing authorized media can be preserved; an optional `mediaClaims` entry can select exact project Lab bytes using `mediaId` and `labAssetId`, or exact retained media using `documentId`, `versionId` and `mediaId` inside `retained`. Claims never grant permission or authorize changed bytes.

Run `list_animation_scenarios` to discover the game’s declared animation hooks. These hooks are separate from saved QA scenarios. `set_animation_binding` requires the exact document version and digest, current declaration and source hashes, the observed binding sequence, and an explicit clip or mix selection. Send `sound: false` for silent playback; enabling sound requires Sound read permission. Later document edits do not retarget an existing binding.

Save, restore, set and clear operations append history. After an uncertain reply, keep the same request UUID and identical inputs, or query `get_animation_save_result` / `get_animation_binding_save_result`. The receipt distinguishes the originally applied version from the current head. A missing receipt does not prove an outstanding request cannot commit. Reads and your retained receipts remain accessible after editor capacity expires; mutation retries still require current editing authority.

Native JSON reads and saves through MCP are limited to 4 MiB; metadata for larger saved documents remains available. Use Animation Lab for larger bodies. A saved document or binding does not prove that a game rendered it: inspect the preview and capture the relevant outcome evidence separately.

The [project-key animation file commands](https://reelgrove.net/downloads/#animation-files) transfer native documents up to 24 MiB without an account session. They preserve the editor’s permission checks and exact save receipts. Inline MCP keeps its 4 MiB limit.

exact retained evidence

## Archive saved QA explicitly.

These three tools use the same service as the [account archive controls](https://reelgrove.net/docs/existing-games/#qa-history). `get_qa_history_usage` returns project and studio working counts, retained counts and exact decimal byte usage. Archiving frees working capacity; it does not delete records, free retained storage or create an approval.

Read the selected record first. Persist a new `requestId` UUID and the full request before calling `archive_scenario` with `scenarioId` and `scenarioSha256`, or `archive_release` with `releaseId` and `candidateSha256`. Both require the current `expectedActiveRevision`, every evidence read capability, `reviews:comment` and effective editing capacity. The key fixes the studio and project; the receipt identifies its real human actor.

Retry only the same UUID and exact body after an uncertain reply. A completed retry remains readable after editing expires. If the active revision changes, use `get_scenario` or `get_release` with the current revision and compare its `summary.archive` to the original request, actor and digest. Do not replace the saved request’s revision or create another archive automatically.

The `history` filter on `list_scenarios` and `list_releases` accepts `QA_HISTORY_SELECTION_ACTIVE`, `QA_HISTORY_SELECTION_ARCHIVED` or `QA_HISTORY_SELECTION_ALL`. Omission keeps complete history. Follow `nextOffset` through pages of at most 50; scenario offsets are bounded at 4096 and release offsets at 2048. Archived records retain their exact identity, stale-input information, books, human decisions and suite membership.

Connected review

## Capture a candidate, then inspect its evidence.

Use `capture_release` with `expectedActiveRevision`, a durable `requestId`, a short `title`, optional multiline `requirements` and up to 32 distinct `scenarioIds`. Every selected scenario must match the current source, math and creative inputs. The server captures those commitments; the client cannot supply an approval or replace their hashes.

Retry the exact UUID and body after an uncertain response. Read `list_releases` with optional `offset`, then `get_release` with the returned `releaseId`. A changed input marks old evidence stale while preserving its history. The account shows the same candidate and historical human decisions. Human approval and requests for changes stay in the account review workflow.

Optional workers

## Request observations and math experiments explicitly.

These tools require enabled hosted workers. A candidate's `executionAvailable` and the result of `math_experiment_context` report installation availability. Your key and current membership are checked independently on every operation. Local [browser QA and math commands](https://reelgrove.net/downloads/) remain available for local workflows.

### Observe a frozen release candidate

Pass the exact `releaseId`, `candidateSha256`, active revision and a new durable `requestId` to `start_release_execution`. Keep these arguments until the receipt is known. List and inspect the resulting executions to distinguish observed passes or failures from interrupted infrastructure. Your frontend needs the documented observer integration; unsupported controls fail the check. This observation does not grant human or Engine approval.

Use `compare_release_observations` with the current `expectedActiveRevision` and explicit `baseline` and `target` selections. Each selection contains the exact `executionId`, `runId` and `receiptSha256` returned by `get_release_execution`. Both runs must belong to this project and retain their verified artifacts; you may compare observations from earlier revisions after a new build becomes active.

The comparison reports changed input commitments, expected and observed event positions, payout differences, pass/fail direction and screenshot pixel counts. It identifies whether replay conditions match and marks each side stale against the current project. Different dimensions or screenshots beyond the pixel budget have an explicit unavailable pixel-diff status. Differences describe observations; they do not establish a cause, carry a scenario forward to a new build, or grant approval. All five discipline read scopes are required. Retained observations remain comparable after paid or trial editor capacity expires, while current membership and key access still apply.

Cancellation preserves completed observations. Retirement requests file removal after containers have stopped; receipt identities remain. Use the account review screen for screenshots and larger evidence files. Account download URLs are not project-key capabilities.

### Generate and compare math

[Build receipt comparisons](https://reelgrove.net/docs/mcp/#math-build-receipts) are a separate workflow.

Start with `math_experiment_context`. Select exact listed source files, an available profile, Python commands, a seed, time/output limits and mode costs with optional RTP or hit-rate targets. Submit the reviewed specification with `inputsReviewed: true`, its exact `sourceSha256`, active revision and a durable UUID. Workers run without network access; dependencies must already exist in the selected profile or reviewed source.

The optional [pinned Engine Math SDK profile](https://reelgrove.net/docs/existing-games/#math-sdk) supplies Python generation dependencies and source-path helpers. Use it only when the context lists it; the standard-library profile remains a separate choice.

`find_math_experiment_outcomes` reads up to 32 exact generated books per page. Supply the retained `jobId`, `expectedOutputSha256`, `expectedReportSha256`, generated `mode`, optional `variant` and the same explicit outcome filters used by `find_scenario_outcomes`. Keep both hashes on continuations with `afterBookId`. Search requires current Project and Math read access and remains available after paid editing expires. It creates no preview or build. Frozen replay opens only through the account’s [Math experiments](https://reelgrove.net/docs/existing-games/#math-experiments) controls.

Read the retained experiment and independent validation report before comparing results. Keep decimal strings and rational values exact. MCP responses are bounded to 8 MiB; the account handles larger reports. An explicit `promote_math_experiment` request prepares an ordinary owned build. Review its validation and activate it separately: neither a successful experiment nor promotion changes the active game automatically.

native build evidence

## Compare recorded builds.

`get_math_build_receipt` accepts only a retained `jobId` and returns canonical JSON bytes, their SHA-256 and the recorded limitations. `compare_math_build_receipts` takes `beforeJobId` and `afterJobId` from the same project and returns both receipt hashes plus separate subject, recipe, selected-byte, output-byte and independent-run checks. Both need current Project and Math read access, including on historical revisions; editing capacity is not required.

The separately enabled `python313-normalized-v1` profile measures fixed input metadata and its actual toolchain before each isolated phase. Only two distinct eligible native runs with matching inputs, recipe, toolchain and output can state two clean runs matched. That statement does not guarantee future determinism or approve a game. Legacy, SDK and optimizer observations retain their original limitations.

Imported JSON, equal submitted hashes and repeated use of one job cannot create native evidence. The tools accept no uploaded receipt or trust flag. A canceled or removed result cannot issue a new receipt. MCP responses remain bounded to 8 MiB. The [workspace view](https://reelgrove.net/docs/existing-games/#math-build-evidence) supports larger receipt downloads. See the [CLI examples](https://reelgrove.net/downloads/#build-receipts); ordinary `compare_math_experiments` continues to compare distributions.

Research

## Math tools and market activity.

The seven research tools accept `expectedActiveRevision` and an `input` object. The discovered schema describes each input and its decimal-string units. Published comparisons and simulations can only read the project selected by your key.

```
{
  "name": "get_engine_tracker",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111",
    "input": {"ranking": "games", "period": "past30Days", "sort": "turnover", "query": "Waylanders", "limit": 20}
  }
}
```

The tracker includes every source-tracked game, with search, provider filtering and optional pagination. Missing statistics and artwork remain `null`. Turnover uses USD micro-unit strings; RTP is source-declared. `imageUrl` and `thumbnailUrl` reference public artwork. Cached snapshots include source and freshness information; updates are normally checked every 15 minutes.

Submitted archives and lookup CSVs are limited to 4 MiB through the customer API, within an 8 MiB total request. Browser imports run locally and support up to 32 MiB. Simulations run at most 2 million rounds. Private inputs are not logged or saved. These tools model test outcomes and never place bets or modify project files.

Working together

## Two revisions keep changes deliberate.

`expectedActiveRevision`

The project revision UUID from `project_context`. A project reset changes it. Refresh the context and inspect the new state before continuing.

`expectedRevision`

The current binding revision from `art_slots`, `sound_cues` or `list_motions`. Send it as a decimal string, including `"0"` when that is the observed value.

If a teammate edits the same binding, the older write is rejected with `aborted`. Reread the current value, compare the changes and decide what to save. Do not automatically resend with an incremented revision.

After a timeout, cancellation or an unconfirmed response, a change may already have been saved. Read the current state before trying again. The client should inspect MCP `isError` and the structured `code` and `message`; an error is not a successful tool result.

Restore is a new change.

Use `restoreDefault: true` with the observed binding revision. Do not send `null`, an empty asset ID, or both an asset and a restore operation. Motion likewise accepts either `settings` or `restoreDefault: true`.

Credentials

## A small key with a clear lifetime.

- The secret is shown once. Closing its dialog, changing pages or studios, or signing out clears the displayed secret. It cannot be retrieved from the key list.

- If key creation times out, refresh the list and revoke any key from that attempt before creating another. An uncertain response is not a reason to create several keys.

- Use Developer access to revoke your own keys, including keys for studios you have left. A revoked or expired key cannot authenticate.

- Signing out of the browser does not revoke machine keys. Revoke a key explicitly when you no longer need it. Password recovery revokes your existing keys; removing your membership revokes that studio’s keys.

- Resetting a project does not move the key to another project. Fetch the new active revision. Rejoining a studio does not revive a revoked key.

You can have up to 5 active keys per user and project. Keys do not add paid seats; creating more keys cannot increase your permissions or editing capacity.

When something needs attention

## Find the next useful check.

### Cannot connect / `unauthenticated`

Check the exact endpoint from Developer access and the `Authorization: Bearer …` header. Check expiry and revocation. Browser cookies, query tokens and `X-API-Key` do not authenticate this endpoint.

### `permission_denied`

Check both the key’s scopes and the creator’s current studio membership and permissions. The server also checks any supplied Origin. Reconnecting cannot expand a key’s saved scopes.

### `failed_precondition`

For writes, check the studio subscription and confirmed editor capacity. Read the message: a required Lab or math-report service may also be unavailable in this deployment.

### `aborted`

Reread project context and the affected binding. A project reset or another edit can make the supplied revision stale. Review the new state before saving again.

### `invalid_argument` / `not_found`

Use the discovered camelCase schema, exact registry slot or cue, and an asset ID from this project revision. Check data hashes, image formats and the build’s Motion bounds. Unknown, duplicate, null and missing required fields are rejected.

### `resource_exhausted`

A request, upload, key or storage limit was reached. Read the message, wait if the service is busy, or use the Lab for a file above the MCP size limit. Retrying cannot bypass a storage limit.

### `unavailable`, `deadline_exceeded` or `canceled`

Treat a mutation as unconfirmed. Inspect the current binding before another deliberate action. For reads, retry when the service is available.

Product scope

## What this connection supports today.

Asset reads and uploads through MCP are limited to 4 MiB per file. Images support PNG, JPEG and WebP; SVG uploads are not supported. Audio supports WAV, MP3, OGG, FLAC, M4A and AIFF. Files still undergo the Lab’s format and storage checks. Use the Lab UI for supported larger files.

`list_motions` and `set_motion` edit the build’s declared `idle` and `win` presentation states. Supported presets are pulse, bob and tilt, with linear, sineInOut or quadOut easing; individual states may allow only a subset and impose tighter bounds. The separate animation-document tools read and save native timeline and rig data and bind exact versions to declared game hooks.

When owned projects are enabled, MCP supports prepared TAR uploads, isolated validation and explicit revision activation for the key’s existing owned project. Create the initial project in the account or use [scoped initial creation through MCP](https://reelgrove.net/docs/mcp/#new-project) with explicit creation access. The [studioctl download](https://reelgrove.net/downloads/) provides `owned-build upload|status|validate|cancel|activate` commands with durable retry receipts; upload never activates automatically. Keep the same receipt and archive after an uncertain response. A revoked or expired admitting key stops new queued effects.

The customer MCP endpoint supports scoped asset and animation edits, prepared builds, retained review evidence and explicitly enabled math and browser workers. It does not generate images or audio, edit repository source, run arbitrary build commands, operate real-money games, publish to Engine, or manage keys, teams and billing. Human review remains a separate account action. Validation and browser observations do not grant Engine approval.

### Connect to your project.

Choose a ready game and the smallest useful set of scopes.

[Open Developer access ](https://reelgrove.net/app/#developer)

---

Source: https://reelgrove.net/downloads/

Your game. Your development environment.

# Bring your local build back to ReelGrove.

Download bundlepack to package an edited development bundle for Import new build. It runs locally and needs no ReelGrove credentials.

Linux amd64 & arm64  Works in a Linux WSL2 environment  Local execution

-  1 ExportGet your development ZIP.

-  2 BuildEdit and compile locally.

-  3 PackageMake a verified TAR.

-  4 ReturnUpload, validate, activate.

Choose the architecture of the Linux environment where you will run the command. Run `uname -m` there: `x86_64` means amd64; `aarch64` means arm64.

Enable JavaScript to check the available bundlepack release.

<p>Download links require JavaScript to check the release supplied by this installation. Ask your ReelGrove operator for bundlepack if you cannot enable it.</p>

Before the first run

## Check the download.

- Download the utility and its matching SHA-256 file into the same folder.

- Open Verify and run this download on your architecture’s card. Run its `sha256sum -c` command from that folder and check that the result says OK.

- Run the displayed `chmod` command, then `-version`. Its JSON reports `version`, `os` and `arch`; check these against the card.

If the checksum does not match, download both files again before running the utility. The checksum identifies the utility download; the pack command later reports a separate checksum for your game archive.

Make room for the build

## Use a private Linux workspace.

In your project’s Export game dialog, choose Development bundle. Extract its ZIP into a private working folder, then follow `source/development/README.md` and the included source instructions to edit and rebuild both frontend targets.

Each export reserves 2 GiB of studio storage until it expires, and a studio holds up to 4 GiB of exports across all its projects. If a new export has no room, cancel exports you no longer need under Export game → Your exports on the project that made them, or wait for them to expire. The message says how much of the reservation is yours and how much belongs to exports or math previews requested by other studio members, which only they can cancel, and when the next of their exports expires.

Using Windows?

Run bundlepack inside WSL2’s Linux terminal. Keep the working bundle in your Linux home directory, such as `~/studio-work/`, so Linux file permissions apply. Use that workspace instead of `/mnt/c` or a shared Windows folder.

The completed bundle folder must be private (mode `0700`). Keep dependency installs, build caches, hidden files and credentials outside it. Use regular files and directories; symbolic links and hard links are rejected.

Keep the supplied layout, notices and game declarations. The bundle’s root contains:

Completed bundle

```
bundle.json
source/
frontend/
standalone/frontend/
math/
notices/
```

Keep the supplied runtime override arrays empty. Uploaded assets and saved Art, Sound, Motion and Animation Lab work stay in the original project and are preserved when you activate the rebuilt game in that same project. A build imported into another project does not transfer that saved Lab work. The [Animation Lab export guide](https://reelgrove.net/docs/getting-started/#animation-export) explains how to download editable rigs and standalone playback packages.

[Saved game-animation bindings](https://reelgrove.net/docs/getting-started/#animation-game-hooks) use the hooks implemented by that project’s original source. Retain their declarations when rebuilding. Standalone exports carry the exact bound rig versions and playback runtime; development downloads keep the empty binding manifests. Check real game placement, sound, skip, turbo and reduced motion after integrating a new hook.

After the build finishes

## Make the import archive.

Stop build watchers and other processes writing to the finished bundle. From the folder containing your verified utility, run the example below. Replace the paths with your own; for ARM64 use `bundlepack-linux-arm64`.

Linux amd64 example · replace the paths before running

```
chmod 700 /absolute/path/to/completed-bundle
./bundlepack-linux-amd64 \
  -source /absolute/path/to/completed-bundle \
  -out /absolute/path/to/game.tar
```

The output folder must already exist outside the completed bundle. Choose a new filename: bundlepack never overwrites an existing archive. When it finishes, it prints the archive path, byte count and SHA-256.

The pack command packages completed files. Follow your game’s build instructions first; packaging does not compile source or generate math.

Pick up where your team left off

## Upload, review, then activate.

- To update your existing project, open its Import new build action. For an independent Engine game, use Import existing game where enabled. Template-build imports keep their approved original.

- Select the `.tar` created by bundlepack, upload it, and submit it for validation.

- Review the result and choose Activate build when ready. Uploading alone does not change the project.

- Open the Lab and preview, inspect your saved artwork, sounds, motion and animations, and check the math and frontend reports. Confirm that the rebuilt game still declares the hooks used by your saved animation bindings.

Import and activation must be enabled for your installation and role. A passing validation report checks the supplied files; play and review the rebuilt game before submission.

### Your project is waiting.

Continue from Overview when your archive is ready.

[Open studio ↗](https://reelgrove.net/app/)

explicit project creation

## Create a separate owned project with a durable receipt.

The CLI provides `owned-project upload|status|validate|cancel|register`. Use a key on an existing project with explicit `projects:create` and every required import scope. The server reserves a distinct destination; the anchor key gains no destination access. Issue a separate destination key for subsequent automation.

Explicit initial-project commands

```
studioctl -url ACCOUNT_MCP_URL -key-file /private/anchor.key \
  owned-project upload -archive game.tar -receipt creation.json -name 'My game'
studioctl -url ACCOUNT_MCP_URL -key-file /private/anchor.key \
  owned-project validate -receipt creation.json
studioctl -url ACCOUNT_MCP_URL -key-file /private/anchor.key \
  owned-project status -receipt creation.json
studioctl -url ACCOUNT_MCP_URL -key-file /private/anchor.key \
  owned-project register -receipt creation.json
```

Review the isolated validation result before registration. Keep the exact TAR and private receipt after an uncertain response; resuming reuses the reservation and committed offset. Upload allows 30 minutes by default, up to 1 hour with `-timeout`; a larger TAR gets 1.5 seconds per 1 MiB chunk plus 10 minutes, up to 4 seconds per chunk plus 10 minutes. Chunks are paced within the request budget. HTTP 429 stops with retry timing guidance; uncertain writes are never retried automatically. Read the [authority and recovery contract](https://reelgrove.net/docs/mcp/#new-project).

Local preflight

## Check preview space and tile assets before upload.

`bundlepack math seekable` converts large book files into standard seekable Zstandard with byte-exact verification. The matching preview worker reads bounded frames without expanding the books into runtime scratch. Ordinary compressed files retain their existing behavior. Hosted preview creation allows up to four minutes to verify and prepare large inputs; the isolated game still has a separate 30-second startup limit.

The current `bundlepack prepare` reports expanded book bytes, index space and 128 MiB reserved for database and filesystem overhead against the preview’s 1 GiB runtime. Add `-require-preview-budget` to fail CI when the estimate exceeds that budget. Prepared files and the JSON receipt remain available. This checks disk headroom; it does not prove that the game boots or renders.

The current tile check verifies matching filenames, decoded image formats, transparent foreground/logo pixels and the decimal 3 MB background-plus-foreground limit. It prints dimensions and hashes without modifying the artwork. Composition, rights and small-size legibility still need review. Use the matching current downloadable tool release.

Local tile check

```
bundlepack tiles -background GameTitle-BG.jpg \
  -foreground GameTitle-FG.png -logo ProviderName-Logo.png
```

Project-key file transfer

## Save a full native rig without an account login.

The account and CLI support `studioctl animation save|get|get-version` for native files up to 24 MiB. They use the same project key, revision checks, Motion and embedded-media permissions, and immutable save receipts as Animation Lab. Inline MCP keeps its 4 MiB limit. The file service uses project-key authentication; an account browser session is unnecessary.

Keep an intent JSON with `expectedActiveRevision`, `documentId`, `expectedSequence` and a durable `requestId`. The CLI reads and hashes the input file; it never retries a write automatically. Recover uncertain results using `get_animation_save_result` before changing the intent. A rejected document reports the JSON path, reason code and any suggestion of its first fault and is not saved.

Full-document save using the existing project key

```
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  animation save -args-file intent.json -input rig.animation.json
```

For downloads, use `animation get -args-file scope.json -output rig.animation.json` with `expectedActiveRevision` and `documentId` in the scope file. `get-version` additionally requires `versionId`. Verified downloads create a private file and never replace an existing destination. Read the [animation authority and recovery guide](https://reelgrove.net/docs/mcp/#animation).

Your repository and build pipeline

## Upload with a project-scoped CLI.

Studioctl connects to your existing independent project with a project key. Create a key with Import whole game bundles access and its required disciplines, then keep the key in a private file. Register a new project in the studio or use the [initial-project commands](https://reelgrove.net/downloads/#new-project) with a key on an existing project and explicit creation access. Follow the [existing-game workflow](https://reelgrove.net/docs/existing-games/) to prepare your first independent bundle.

Enable JavaScript to check the available studioctl release.

Use your project’s MCP URL and a private key file

```
chmod 600 /private/path/project.key
./studioctl-linux-amd64 -url YOUR_PROJECT_MCP_URL \
  -key-file /private/path/project.key \
  owned-build upload -archive game.tar -receipt build-request.json
./studioctl-linux-amd64 -url YOUR_PROJECT_MCP_URL \
  -key-file /private/path/project.key \
  owned-build validate -receipt build-request.json
./studioctl-linux-amd64 -url YOUR_PROJECT_MCP_URL \
  -key-file /private/path/project.key \
  owned-build status -receipt build-request.json
```

The current `studioctl` paces owned-build chunks below the shared admission rate. It allows 30 minutes by default, up to one hour with `-timeout`; a TAR larger than 800 MiB gets 1.5 seconds per 1 MiB chunk plus 10 minutes, up to 4 seconds per chunk plus 10 minutes and never beyond 23 hours. A 4 GB build with a million-book library uploads in roughly 40 to 60 minutes. If another client consumes the remaining rate allowance, wait one minute and resume the identical archive and receipt. Uncertain writes are never automatically retried.

Keep the receipt to resume the same upload or recover an uncertain response. It contains request identities and hashes, never the key or game files. Uploading and validation leave your active game unchanged. After reviewing a validated candidate, explicitly run `owned-build activate -receipt build-request.json` with the same URL and key options to preserve Lab work and switch builds.

The server checks current permissions, revision and editor capacity. Revoking or expiring the key stops unfinished work from acquiring new authority. Use an owner-only workspace for the archive, receipt and key; share review results separately from credentials.

`studioctl export download` saves a ready project archive with per-chunk and complete-file verification, without overwriting existing files. It handles temporary read-rate limits within the download timeout. See [project exports through MCP and CI](https://reelgrove.net/docs/mcp/#project-exports) for capture, recovery, required permissions and the complete download command.

saved QA capacity

## Read capacity and archive exact records.

The [three scoped QA history tools](https://reelgrove.net/docs/mcp/#qa-history) are available through `studioctl call`. Keep the exact archive request JSON privately before sending it; choose a new UUID only for a new, explicit action. After a lost reply, recover the original receipt instead of creating another request.

Read current working and retained capacity

```
studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  call get_qa_history_usage -args-file current-project-revision.json
```

The arguments file contains `expectedActiveRevision` from `project_context`. Read-only keys need every evidence read permission. Archival additionally requires review-comment permission and current editing capacity. It releases working capacity while retaining original evidence and storage; portable archive limits remain separate.

Keep your editable work

## Recover a portable project offline.

Choose Portable project in Export game to capture your source, math, current Lab settings, every uploaded asset, editable animation versions, review lineage and saved QA scenarios. The same download verifies this archive and recovers its files without an account connection.

When archived QA exists, the portable capture retains the project’s saved scenarios, candidates, reviews and archive receipts across revisions. It verifies paged history and all referenced evidence before export and import. The complete archive remains limited to 2 GiB; capacity overflow fails the capture instead of omitting old evidence.

Retained hosted browser observations travel with the exact frontend, selected outcomes and settings that were tested. Completed observations include their raw results and screenshots, including failed checks. Retired files cannot be exported. Offline inspection labels these records as imported evidence; they do not approve a new project.

[Profile matrices](https://reelgrove.net/docs/existing-games/#profile-matrices) retain every definition and complete expansion, including original outcome books and requested profiles. [Readiness policies and decisions](https://reelgrove.net/docs/existing-games/#release-readiness) retain their exact selected evidence across builds. [Named regression suites](https://reelgrove.net/docs/existing-games/#regression-suites) retain every saved version, exact referenced scenarios and books, and release links for the captured revision. The export verifies complete membership and history within the shared capture limit; it does not silently omit cases. A new project keeps the original capsule as imported evidence, without converting it into native suite authority or approval.

Linux or WSL example · replace the paths before running

```
./bundlepack-linux-amd64 portable verify \
  -archive /absolute/path/to/studio-portable.zip
./bundlepack-linux-amd64 portable unpack \
  -archive /absolute/path/to/studio-portable.zip \
  -out /absolute/path/to/recovered-project
```

Choose a new recovery directory. Files are verified before publication and written privately; existing files and directories are never replaced. New exports include every retained animation version in the project, including earlier branches and documents with no current head. Older archives contain only the versions captured by their original exporter; verification cannot recover missing history.

Keep the original ZIP. To reproduce an unchanged extracted archive, use `bundlepack portable pack -directory recovered-project -out archived-again.zip` with the new ZIP outside that directory. Edited or extra files cause verification to fail. To rebuild the game, work from the recovered `development.zip` and follow its instructions.

Before planning a new project, run `bundlepack portable plan -archive studio-portable.zip`. It also checks the nested development source, editable Lab data, media and animation references, saved outcomes and release-review relationships. Its JSON report marks imported evidence as `imported_unattested` and requires fresh isolated source validation. Planning does not create a hosted project or transfer another studio’s approvals.

Offline recovery writes local files. To create a new editable project on an installation with restoration enabled, follow the steps below. Import new build preserves the destination project's existing Lab work; it does not import these Lab sidecars.

Create an independent project

## Restore the captured source and Lab work.

Use a Portable project ZIP from an export you are authorized to use. Prepare it locally, then package the new directory as a normal import TAR. Choose new output paths outside the archive and recovery directories.

The prepared candidate must fit within 2 GiB, including the current source, retained original ZIP and preparation metadata. A successful export, `portable verify` or `portable plan` does not establish this fit. Run `portable prepare` below before uploading for hosted restoration.

Prepare the exact archive for fresh validation

```
./bundlepack-linux-amd64 portable prepare \
  -archive /absolute/path/to/studio-portable.zip \
  -out /absolute/path/to/prepared-restoration
./bundlepack-linux-amd64 -source /absolute/path/to/prepared-restoration \
  -out /absolute/path/to/restoration.tar
```

01

### Upload and validate.

Choose Import existing game in the destination studio, select the prepared TAR and request validation. Keep the identical file for upload recovery.

02

### Review the portable project.

Open the validated candidate. Its Restore editable project panel identifies the archive and saved request. Choose Restore project explicitly; the worker verifies the complete archive before copying saved work.

03

### Open and review the result.

After completion, open the new project. Its captured Lab settings, media, animation heads and retained history are editable. Review the game and create fresh test scenarios and release decisions for the destination.

Restoration requires current project-creation and discipline permissions, editing capacity and an enabled worker. Source, math and saved Lab work receive new project ownership; original review decisions and browser records remain imported evidence. They do not grant access, approve the new project or become fresh hosted runs.

After a lost response or reload, use Check status or Retry same restoration. The saved request recovers the same project. Cancellation is available before final creation starts, including after editing expires. A stopped candidate keeps its history; another attempt needs a newly prepared and uploaded candidate. For a request requiring operator review, retain its ID and [contact support](https://reelgrove.net/support/).

Older archives restore only the history they actually contain. Source and non-animation Lab settings describe the captured revision; earlier complete project revisions are not recreated. On installations with cloning enabled, [Clone project copies current saved work into another project in the same studio](https://reelgrove.net/docs/existing-games/#clone-project) without a manual archive upload. It retains compact imported history; the current source, that history and preparation metadata must fit the same 2 GiB candidate limit. Imported history grants no destination approval. To reuse selected creative content, create a studio kit below.

Carry creative work into your next game

## Build a reusable studio kit.

Select uploaded images, audio and exact animation versions from a Portable project export. The kit keeps their original bytes and embedded animation media. Start by listing the available paths, then copy the paths you want into a selection file.

List the captured content

```
./bundlepack-linux-amd64 kit list \
  -portable studio-portable.zip > available.json
```

Save `selection.json` with `{"version":1,"paths":["EXACT_PATH_FROM_AVAILABLE_JSON"]}`, replacing the placeholder with a listed path. Add more paths to select multiple files.

Create, verify and extract into a new directory

```
./bundlepack-linux-amd64 kit create -portable studio-portable.zip \
  -selection selection.json -out reusable-kit.zip
./bundlepack-linux-amd64 kit verify -archive reusable-kit.zip
./bundlepack-linux-amd64 kit unpack -archive reusable-kit.zip \
  -out reusable-kit
```

Use Open JSON in AnimationLab to load an extracted `animations/*.animation.json` file, then save it explicitly in a writable project. Upload files from `assets/` through ImageLab or SoundLab. Configure game bindings in the destination project. Outputs are private and existing files are never replaced.

The local workflow works without a hosted installer. Where the project menu in your Lab offers Studio kits, you can upload the ZIP and [review a separate installation plan](https://reelgrove.net/downloads/#install-kit). Kits carry content hashes; project approvals and private reviewer records are excluded. Verification checks byte integrity and animation structure, not rendered playback or Engine acceptance.

a separate saved copy

## Copy a project through the CLI.

Use a key on the source project with explicit creation, import and export scopes. Save drafts first, inspect availability, then start the copy with a durable private receipt:

Capture a separate destination and retain the exact request

```
studioctl -url ACCOUNT_MCP_URL -key-file /private/source.key clone context
studioctl -url ACCOUNT_MCP_URL -key-file /private/source.key \
  clone start -name 'Alternate direction' -receipt clone.json
studioctl -url ACCOUNT_MCP_URL -key-file /private/source.key \
  clone wait -receipt clone.json
```

`context` and `list` only read. `status` checks a saved receipt once; `wait` polls every two seconds for up to 30 minutes by default. Stopping the CLI leaves server work running. Use `cancel -receipt clone.json` explicitly for permitted asynchronous cleanup.

Keep the receipt after a lost reply. Accepted retries recover the original captured source and destination even after the source project changes. New work needs the original credential and current editing capacity; a replacement read key can recover the same actor's accepted history. The copied project requires a separate key for further automation. See the [scoped clone contract](https://reelgrove.net/docs/mcp/#project-cloning).

a reviewed portable plan

## Restore through your project key.

After preparing the portable archive above, use [`owned-project upload` and `validate`](https://reelgrove.net/downloads/#new-project) with a creation-enabled key on an existing project. Keep its private receipt, then inspect and explicitly start the restoration:

Review the plan, then restore its reserved destination

```
studioctl -url ACCOUNT_MCP_URL -key-file /private/anchor.key \
  restore inspect -creation-receipt creation.json -receipt restoration.json
studioctl -url ACCOUNT_MCP_URL -key-file /private/anchor.key \
  restore start -creation-receipt creation.json -receipt restoration.json \
  -reviewed-plan-sha256 EXACT_PLAN_SHA256
studioctl -url ACCOUNT_MCP_URL -key-file /private/anchor.key \
  restore wait -creation-receipt creation.json -receipt restoration.json
```

Review the exact plan produced by portable preparation before supplying its digest. Inspection reads the protected marker; the worker separately verifies the complete archive. `status` checks once; `wait` polls reads for up to 30 minutes by default. Stopping the CLI does not cancel server work. Use `cancel` explicitly when cleanup is permitted.

Keep both receipts after a lost reply. The same request recovers the same destination, including after the anchor changes. The original key owns new effects; a replacement read key can recover permitted history. The destination needs a separately issued key for further automation. See [the scoped tool contract](https://reelgrove.net/docs/mcp/#project-restoration).

Review what enters this project

## Install selected kit contents.

Open the destination project’s Lab, choose the project name at the top left and choose Studio kits from the project menu when your installation enables it. Uploading needs current editing access for each selected discipline, including image or audio permissions for media embedded in animations. Some workspaces allow inspected uploads but do not offer installation.

01

### Choose and upload.

Select the kit ZIP, give it a name and choose its exact files. The local inventory only helps you choose; Upload selected kit hashes the archive and sends bounded chunks. Keep that identical ZIP to resume an interrupted upload.

02

### Inspect the complete archive.

Choose Inspect uploaded archive. The server checks every payload, including unselected files, and reports the selected media and embedded animation contents. Inspection does not install anything.

03

### Review the destination.

Choose Review installation. Check which images and sounds will be added or reused, the fresh identity for each animation and the additional Lab storage. Download the exact inspection and installation plan when you need to retain the review.

04

### Confirm, then review playback.

Tick the review confirmation and choose Install reviewed contents. Existing Lab content is preserved. Refresh the relevant Lab library, open the imported work and check its playback. Configure game bindings explicitly.

After a lost response, reopen Studio kits from the project menu and use Recover saved request before starting another operation. The same browser tab retains the exact request and confirmation; reselect the identical ZIP when more bytes are needed. Closing the dialog pauses local work and keeps the request. Your kit history remains readable with the required permissions after editing expires.

[scoped kit tools for MCP](https://reelgrove.net/docs/mcp/#studio-kits) offer the same upload, inspection, separate plan review and explicit installation steps. Use either the scoped tools or the workspace controls above with current permissions.

Each upload and installation plan expires after 30 minutes; recovering the same request keeps its original deadline. Expired unfinished work is cleaned up only after the server verifies what it can remove. Selected-file lists, inspections and plans remain in history, and completed installations retain their original archive. Unfinished operations recovered from a backup stay available for operator review.

Use the offered cancellation action while an upload or installation is cancelable. Completed installations retain their history and original archive. A record requiring review needs [operator support](https://reelgrove.net/support/); copied recovery records do not authorize resuming an old installation. Origin hashes remain unverified source claims, and installation does not create a browser pass or an Engine approval.

Use the same download in CI

## Retain an exact replay scenario.

The `qa` commands capture a published outcome and hash its source, frontend, math and optional creative files. They preserve the original event bytes. Stop input writers, then save a request outside the directories being checked.

qa-request.json · adapt the game, revision, directories and published outcome

```
{
  "projectId": "my-game", "gameId": "my-game", "revision": "git-commit",
  "roots": {"source": "./source", "frontend": "./dist", "math": "./my-game"},
  "selection": {"mode": "base", "variant": "", "bookId": "1", "costX100": "100"},
  "profile": {"name": "desktop", "width": 1280, "height": 720,
    "currency": "USDT", "language": "en", "reducedMotion": false,
    "actions": ["replay", "wait:complete"]}
}
```

Paths resolve relative to the request. The math directory needs its published index, books and lookup weights. The game ID and mode cost must match those files; `100` means a 1× mode. Add `art`, `sound`, `motion` and `animation` roots when you have creative overrides, including their binding and settings documents.

Capture and recover events · keep output files outside all input roots

```
./bundlepack-linux-amd64 qa capture -request qa-request.json > scenario.json
./bundlepack-linux-amd64 qa replay -request qa-request.json \
  -scenario scenario.json > replay-events.json
./bundlepack-linux-amd64 qa verify -request qa-request.json \
  -scenario scenario.json > report.json
```

Replay fails if the saved inputs or outcome changed. Verify reports browser execution as pending and exits nonzero when no separately collected browser observation is supplied. Saving a scenario does not run the game or establish that it passed a browser test. These local files are independent of the saved scenarios in your hosted workspace.

In the workspace, [find a published outcome](https://reelgrove.net/docs/existing-games/#find-outcomes) by zero payout, payout range, published maximum or exact recorded event type before explicitly saving a scenario. Results retain exact IDs and weights; zero-weight published records remain available for deliberate replay review.

Observe the built game

## Replay an outcome in isolated Chromium.

Download the local browser runtime for Linux AMD64, then use the current bundlepack above. Docker and Python 3 are required. Integrate the opt-in adapter with your real game handlers to record replay completions, requested controls, errors and a screenshot.

- [Browser runtime · 328 MiB](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/reelgrove-browser-linux-amd64-2afb0e26967a.tar.gz) · Chromium 152.0.7977.82

- [Release manifest](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/manifest.json) · [Verifier and loader](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/browser-image.py) · [Third-party notices](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/browser-notices.txt) · [Checksums](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/SHA256SUMS)

- [Adapter integration and replay guide](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/browser-guide.md)

- [Corresponding third-party source · 1.81 GiB](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/browser-corresponding-source.tar.gz) · [Component index and hashes](https://reelgrove.net/downloads/browser/caa186d882d083902134c9ed376571d58331691ff0ce7602ac496758ce86dedf/browser-source-index.json)

Save the runtime archive, manifest, notices and loader in one new directory. Before executing the loader, verify these exact downloaded files:

Check the manifest and loader, then verify and load the image

```
printf '%s  %s\n' \
  'c68dd18a2494e1657a253aa902ab0592ccfe5e5499a4dacd90af61935675ec86' manifest.json \
  '910a413b7e09f0537cc59491bb1811c370e5b2e0c99f0c0f64131628fc9b5ead' browser-image.py | sha256sum --check
python3 browser-image.py verify .
python3 browser-image.py load . > browser-image-id.txt
```

Follow the integration guide to build your game with the observer adapter, capture a scenario and create `browser.json`. Use the verified local ID returned by the loader:

Run once into a new result directory, then check the retained receipt

```
./bundlepack-linux-amd64 browser run -request browser.json \
  -image "$(cat browser-image-id.txt)" -out browser-result
./bundlepack-linux-amd64 browser verify -directory browser-result
```

These receipts contain local observations. Where hosted workers are enabled, use [Run browser checks](https://reelgrove.net/docs/existing-games/#browser-runs) in the workspace for separately retained server observations. Neither workflow grants automatic release approval. An observer-enabled starter release supplies its own integration; existing studios keep earlier template releases, so a newer default does not add the adapter to those projects. The runtime source revision is `2afb0e2`; the host verifier requires bundlepack from `63cd53c` or later. Different Docker image stores can report different local IDs; the loader verifies their configuration and layer mapping before returning one.

Keep the reason behind every math change

## Run and compare local experiments.

The `math` commands run your reviewed generator or optimizer in a new local job, retain selected inputs and generated distributions, and compare the results. They use your installed tooling with your operating-system permissions. They do not install an SDK or provide a hosted execution sandbox.

Choose an explicit file list, include deterministic seed and dependency configuration where your tooling supports them, and pin the executable using `bundlepack math hash-tool -path /absolute/path/to/python3`. Save a reviewed spec outside your source directory. Adapt every path, file, game ID, mode and target below; replace the SHA placeholder with that command’s result.

experiment.json · example for a generator that writes sdk/generated

```
{
  "schemaVersion": 1, "name": "base-rtp", "gameId": "my-game",
  "inputsReviewed": true,
  "inputs": [{"name": "sdk", "root": "/absolute/path/to/my-game",
    "files": ["generate.py", "config.json"]}],
  "commands": [{"name": "generate", "argv": ["/usr/bin/python3", "generate.py"],
    "executableSha256": "REPLACE_WITH_TOOL_SHA256"}],
  "workingDirectory": "sdk", "outputDirectory": "sdk/generated",
  "targets": [{"mode": "base", "costX100": 100,
    "rtpPercent": {"min": "96", "max": "96.1"}}],
  "timeoutSeconds": 60, "maxOutputBytes": 104857600, "maxProcessBytes": 65536
}
```

Run, inspect and compare · use the job directories returned by run

```
./bundlepack-linux-amd64 math run -spec experiment.json -jobs /absolute/path/to/jobs
./bundlepack-linux-amd64 math verify -job /absolute/path/to/jobs/first
./bundlepack-linux-amd64 math compare \
  -before /absolute/path/to/jobs/first -after /absolute/path/to/jobs/second
```

Completed output must contain valid Engine books, lookup weights and an index matching every declared mode and cost. Comparisons use exact published weights. The `math run` exit codes are `0` for success, `3` for a valid result that misses its targets, `2` for invalid usage or a spec that cannot be read, and `1` for execution or integrity failure. `math verify` checks receipt integrity and can succeed for an intact job that missed its targets. Failed jobs retain their evidence; `math recover -job …` records an interrupted attempt without rerunning it.

Promote generated math deliberately through your game’s build and import workflow. A successful experiment does not update a hosted project, independently recompute your paytable, or establish Engine approval.

For a studio-owned project with hosted workers enabled, the workspace’s [Math experiments](https://reelgrove.net/docs/existing-games/#math-experiments) panel offers reviewed execution profiles, retained comparisons and explicit preparation of a new build. Build validation and activation remain separate steps.

retained native evidence

## Read and compare build receipts.

The MCP service provides two read-only tools for completed hosted math jobs. Use a current key with Project and Math read access; the key selects the project. Save the exact UUID returned by your experiment in `receipt-read.json` as `{"jobId":"YOUR_JOB_UUID"}`. For a pair, save `{"beforeJobId":"FIRST_JOB_UUID","afterJobId":"SECOND_JOB_UUID"}` in `receipt-pair.json`. Replace every placeholder with your retained UUID.

Read evidence and compare two retained native jobs

```
./studioctl-linux-amd64 -url https://reelgrove.net/mcp -key-file ./project.key \
  call get_math_build_receipt -args-file receipt-read.json
./studioctl-linux-amd64 -url https://reelgrove.net/mcp -key-file ./project.key \
  call compare_math_build_receipts -args-file receipt-pair.json
```

The read result contains base64 `receiptJson` and its exact `receiptSha256`. Keep the original bytes when saving evidence. The comparison binds both receipt hashes and reports its limitations. Only two distinct verified normalized runs may state two clean runs matched; matching runs do not guarantee future determinism. Legacy jobs remain ineligible. Downloaded or imported JSON cannot create a new native observation.

These reads do not execute source, promote math or activate a build. They remain subject to current key/membership access and retained output. MCP responses are bounded to 8 MiB. See the [receipt tool contract](https://reelgrove.net/docs/mcp/#math-build-receipts) for profile availability and authority limits, or the [workspace controls](https://reelgrove.net/docs/existing-games/#math-build-evidence) for receipt downloads.

---