User Guides

User guides are the detailed, end-to-end walkthroughs of the tasks people perform with The Test Cabinet. Where a quickstart gives just the steps for someone who already knows the tool, a user guide states the prerequisites, the exact commands, and the reasoning behind the design choices along the way.

If you only need a refresher, the matching quickstart is faster. Reach for the guide when you are doing the task for the first time, or when you need to know why a step is the way it is.

Guides

Setup

• First Time Setup — install the toolchain, container runtime, run-container image, browser, and credentials, then make a first run.

Development

• Running the Local Service Stack — stand up the backend, auth, dispatcher, driver, artifact service, and web console on local k3d, and drive runs the way a deployment does.
• Reviewing Test Run Results — play a finished run, read its validation signals, and write the required review.

Authoring — end-to-end

• Writing Case Specifications and Prompts — the editorial rules every playable case’s seeded specs and prompt must follow: authoritative and self-contained, no history, no sign that this is a test, edge cases as review items rather than warnings, and no advice in the prompt.
• Authoring an End-to-End Test Case — write a new playable-game case or version: its specification, prompt, references, and manifest.
• Creating an End-to-End Variant — add a new playable mode to an existing end-to-end version.

Authoring — 2D asset generation

• Authoring an Asset-Generation Test Case — write a new sprite (draw) or sprite-sheet (draw-sheet) case or version: its brief, tool, output, and manifest.
• Creating a Single-Sprite Variant — add a brief variation to a single-sprite version (asset_kind = "sprite").
• Creating a Sprite-Sheet Variant — add a brief variation to a sprite-sheet version (asset_kind = "sprite-sheet").
• Authoring a UI Test Case — write a high-resolution interface asset (asset_kind = "ui"): one image or a kit of named elements, painted with the paint and ui binaries.
• Authoring a Material Test Case — write a tileable PBR material (asset_kind = "material"): a set of maps painted with the texture and pbr binaries.

Authoring — 3D asset generation

• Authoring a Voxel Model Test Case — sculpt a static cube-voxel model (asset_kind = "voxel-model") with the voxel binary.
• Creating a Voxel Model Variant — add a brief variation to a static voxel-model version.
• Authoring a Voxel Animation Test Case — sculpt a rigged voxel model and author its required animations (asset_kind = "voxel-animation").
• Creating a Voxel Animation Variant — add a brief variation to a rigged voxel version.
• Authoring a Mesh Model Test Case — sculpt a static meshed signed-distance field (asset_kind = "mc-model"/"sn-model"/"dc-model").
• Creating a Mesh Model Variant — add a brief variation to a static meshed version.
• Authoring a Mesh Animation Test Case — sculpt and rig an animated meshed model (asset_kind = "mc-animation"/"sn-animation"/"dc-animation") with declared required animations.
• Creating a Mesh Animation Variant — add a brief variation to a rigged meshed version.
• Authoring a Skinned Character Test Case — write a single continuous deforming skin bound to a model-invented skeleton (asset_kind = "mc-skinned"/"sn-skinned"/"dc-skinned").
• Authoring a Blender Character Test Case — build a rigged, skinned character in headless Blender via build.py + tcab-blend (asset_kind = "blender-character").

Authoring — effects & audio

• Authoring a Particle Test Case — write an emitter system simulated live (asset_kind = "particle-2d"/"particle-3d").
• Authoring an Audio Test Case — write a short rendered clip (asset_kind = "sfx-synth"/"sfx-sample"/"music").
• Publishing an Audio Sample Pack — build an sfx-sample/music pack from its manifest, publish it to the private R2 bucket, and pin it into the run-container image.

DevOps

• Adding or Updating a Model — curate a model in the app (display name, aliases, provider logo, description), how derived models appear from runs, and how price history is recorded.
• Publishing a Test Run Result — release a reviewed run to public hosting and the gallery.
• Publishing a Reference Implementation — deploy a case variant’s authored, correct static build out-of-band, and the non-experimental release gate that governs when a reference is required.
• Rolling Production Service Images — promote a CI-built service-image sha to the production cluster: re-pin the overlay, apply it through the private cluster, and commit.
• Cutting a Release — the whole vX.Y.Z sequence: prepare nightly, rehearse on staging, publish the artifacts from GitHub, then land the catalog and the services in production.

These guides describe how to use The Test Cabinet. To understand how it works internally, see the Components section.