Module history 

Run-history routes: GET /api/runs (filtered, paginated list), GET /api/runs/{id} (full run detail: config, initial readings, samples, results, writes), GET /api/runs/{id}/export (CSV/JSON sample export), and DELETE /api/runs/{id}.

DTO shapes deliberately mirror bhtune-cli’s commands::history --output json JSON (RunSummaryJson/RunDetailJson/etc.) field-for-field, so the CLI and the HTTP API describe the same run the same way – one shape for the product’s two faces, per this workspace’s DTO-decoupling convention (every JSON-facing consumer builds its own projection of the non-Serialize bhtune-db row types, rather than the row types themselves growing a Serialize impl). The one deliberate addition over the CLI’s own RunDetailJson is a full samples array (not just a samples_recorded count) – the trend chart (history-explorer-ui) needs the raw per-tick data, and the data-volume math in AGENTS.md’s “History explorer” section (thousands of rows per run, not millions) says inlining it is cheap enough not to need its own paginated route.

Structs

InitialReadingsResponse

Local projection of bhtune_db::models::TuneRunInitialReadings – see this module’s doc comment for why every JSON-facing type here is its own projection rather than a Serialize impl on the bhtune-db row type.

MvActuationResponse

Local projection of one accepted OPC DA manipulated-variable command and its independent live readback evidence. Commanded MV samples remain in SampleResponse; this audit trail is the only response surface that reports measured MV values.

PidConstantTagsResponse

A run’s snapshotted PID constant tag names, present only when all three were configured. Nested under RunDetailResponse::pid_constant_tags following the same “Option<...> presence itself is the signal” convention initial_readings already uses, rather than a separate boolean plus three more nullable top-level fields.

PidParameterLabelsResponse

The operator-facing names for the three calculated PID constants, derived from the template snapshot stored on the run rather than the mutable template catalog.

ResultResponse

Local projection of TuneResultRow.

RunDetailResponse

RunExportQuery

RunListQuery

Query parameters for GET /api/runs, mirroring TuneRunFilter’s fields one-to-one plus Pagination. Every field is optional; an absent limit/offset falls back to Pagination::default (50 rows, offset 0), matching the CLI’s own default page size.

RunListResponse

RunSummaryResponse

One run in GET /api/runs’s runs array – deliberately a subset matching the CLI’s own history list table columns, not the full detail (that’s RunDetailResponse, for GET /api/runs/{id}).

SampleResponse

One recorded tick: the Tick input and resulting engine state, plus the driver- reported PV quality at read time. Tick/MrftState already derive Serialize in bhtune-core (they round-trip through golden-trace fixtures too), so they’re embedded directly rather than re-projected field-by-field like the other DTOs here.

WriteResponse

Local projection of TuneWriteRow.

Enums

RunExportFormat

Format for GET /api/runs/{id}/export – deliberately a local, HTTP-facing enum rather than reusing bhtune_cli::args::ExportFormat directly: that type is clap-oriented (ValueEnum) and has no Deserialize/ToSchema, matching this module’s own DTO-decoupling convention (see the module doc comment). Converted to bhtune_cli::args::ExportFormat at the one call site that needs it ([export_run]), so the actual CSV/JSON serialization (bhtune_cli::commands::export::samples_to_bytes) is implemented exactly once and the CLI’s bhtune export and this route can never disagree about what a run’s export looks like.

Functions

router