Overview

The core component is a Rust library that implements the majority of The Test Cabinet’s functionality. Most other The Test Cabinet components link against this library and expose its functionality through their own interface — a CLI, an HTTP API, a desktop GUI — rather than re-implementing any of it. Keeping the orchestration here, and out of the interfaces, is what lets runs be driven identically whether they are launched from a script, a remote request, or a window. See Architecture.

Responsibilities

The core owns everything that happens during a run, and defines the data contracts the rest of the system is built around:

• Test cases — resolving a test case version and its selected variant, and reading the test-case.toml manifest that says what gets seeded, rendered, and checked.
• Execution — seeding a fresh git repository, running the harness inside an isolated container, and collecting the produced working tree.
• Agent harnesses — a single abstraction for invoking any supported third-party coding harness, absorbing each one’s quirks.
• Harness events — translating each harness’s raw output into one normalized, live event stream.
• Metrics — recording the run time, token, and cost data every run produces.
• Validation — the automated first pass that builds, loads, and optionally screenshot-compares an implementation.
• Run records — the fixed data contract a run emits.
• Results — getting a finished run onto the gallery through review and publish: gathering its reviews, then releasing its code and flipping it public. The record is stored on the backend automatically when the run finishes.

Wrapping the Core

The wrapping components are deliberately thin:

• The CLI exposes the core as the tcab binary.
• The driver exposes the same run functionality as a per-run executor that the backend dispatches into a Kubernetes Job.
• The Tauri app exposes it as an interactive desktop GUI.

Each adds only the surface its interface requires; the behavior of a run lives here.