Rename the metric triple and the parameter set field

[epompeii]

The renames

Three renames and the migration one of them needs. No behavior change.

JsonMetric -> JsonMetricTriple

A JsonMetric is a value with its two bounds: the triple a metric row used to be
before named values existed. The plain name read like the whole of what a metric is,
which it is not any more. This is a type rename only. Every serde field that carries
one keeps its own name (JsonAlert.metric, JsonPerfMetric.metric, and the rest), so
not one response byte changes. The OpenAPI component and the TypeScript type follow.

JsonReportParameter.parameters -> set

The object is already named parameter where a report result carries it, so the field
spelled its parent again. It now spells what it holds:

"parameter": { "uuid": "...", "set": { "size_mb": 16 } }

This one does change report response bytes. It is free right now: no released CLI
deserializes the report parameter object, so nothing in the wild reads the old
spelling. Once the next release ships a client that does, the same rename becomes a
break. The type name JsonReportParameter is unchanged.

The BMF v1 input format is untouched. A report still submits "parameters" on each
entry, and every adapter fixture stays as it was.

JsonParameters -> ParameterSet

The type has been called a parameter set in its own prose since it was written. It is
an internal newtype with a hand written JsonSchema impl, so the component name is
renamed there as well, and the typeshare mapping follows.

The migration

2026-08-23-120000_parameter_set renames the parameter.parameters column to
parameter.set, and the model fields follow it (QueryParameter.set,
InsertParameter.set, UpdateParameter.set).

set is an SQL keyword, so the migration and the raw SQL that reads the column quote
it. Diesel quotes identifiers of its own accord, so the DSL needs nothing.

The migration is metadata only:

ALTER TABLE parameter RENAME COLUMN parameters TO "set";

SQLite rewrites the stored DDL in place, UNIQUE(benchmark_id, "set") and the index
that backs it included, without reading a row. down.sql is the reverse, and just as
cheap.

Migrations already written keep the spelling that was true when they ran: the
migrations that create and read parameter.parameters are history and are left alone.
The one seed in the migration tests that hand writes a parameter row below this
layer now does so in raw SQL under the old column name, which is what the schema at
that point in the chain has; the chain renames it on the way back up.

Gates

• cargo fmt -- --check
• cargo clippy --no-deps --all-targets --all-features -- -Dwarnings
• cargo nextest run --all-features --profile ci, cargo test --doc --all-features
• cargo check --no-default-features
• cargo gen-types, with the regenerated spec and TypeScript types committed

[github-actions]

Bencher Report

Project	Bencher
Branch	rename/metric-triple-parameter-set
Testbed	intel-v1

🚨 4 Alerts

Benchmark	Measure Units	View	Benchmark Result (Result Δ%)	Upper Boundary (Limit %)
Adapter::Json	Latency microseconds (µs)	📈 plot 🚷 threshold 🚨 alert (🔔)	5.21 µs (+10.72%) Baseline: 4.70 µs	5.18 µs (100.48%)
Adapter::Magic (JSON)	Latency microseconds (µs)	📈 plot 🚷 threshold 🚨 alert (🔔)	5.03 µs (+10.20%) Baseline: 4.56 µs	4.99 µs (100.88%)
Adapter::Rust	Latency microseconds (µs)	📈 plot 🚷 threshold 🚨 alert (🔔)	4.64 µs (+30.33%) Baseline: 3.56 µs	4.45 µs (104.27%)
Adapter::RustBench	Latency microseconds (µs)	📈 plot 🚷 threshold 🚨 alert (🔔)	4.65 µs (+30.57%) Baseline: 3.56 µs	4.45 µs (104.53%)

Click to view all benchmark results

Benchmark	Latency	Benchmark Result microseconds (µs) (Result Δ%)	Upper Boundary microseconds (µs) (Limit %)
Adapter::Json	📈 view plot 🚷 view threshold 🚨 view alert (🔔)	5.21 µs (+10.72%) Baseline: 4.70 µs	5.18 µs (100.48%)
Adapter::Magic (JSON)	📈 view plot 🚷 view threshold 🚨 view alert (🔔)	5.03 µs (+10.20%) Baseline: 4.56 µs	4.99 µs (100.88%)
Adapter::Magic (Rust)	📈 view plot 🚷 view threshold	26.99 µs (+4.22%) Baseline: 25.90 µs	27.39 µs (98.56%)
Adapter::Rust	📈 view plot 🚷 view threshold 🚨 view alert (🔔)	4.64 µs (+30.33%) Baseline: 3.56 µs	4.45 µs (104.27%)
Adapter::RustBench	📈 view plot 🚷 view threshold 🚨 view alert (🔔)	4.65 µs (+30.57%) Baseline: 3.56 µs	4.45 µs (104.53%)

🐰 View full continuous benchmarking report in Bencher