Label the variant in comments, the CLI table, and the BMF v1 reference

[epompeii]

The tail of the benchmark parameters stack: the places a variant still had no name.

The pull request comment

A result row names its variant by the same rule the perf image uses. A
benchmark whose every row in the comment carries empty parameters keeps the
bare benchmark name it has always had. One variant with non-empty parameters among
its rows names them all, the empty parameters among them included, which read {}.
The parameters are spelled in their canonical form and follow the benchmark name.
Results and alerts are counted together when the decision is made, so the two
tables of one comment never disagree about how a benchmark is named. Every BMF v0
comment renders exactly as it did: without parameters there is nothing to spell.

A measure that carries metrics beyond the conventional trio renders one column per
name, headed Measure (name), after the measure's existing columns. A measure that
named no point estimate renders its named columns instead of nothing, which is the
one behavior this changes for a payload that has names at all. The per measure name
cap bounds the width. A named column shows what a threshold computed for that name
inside the cell, the way the point estimate column shows its baseline, so a name is
one column and never three.

Finding the alert for a cell now matches four of the things an alert fires on: the
benchmark, the variant, the measure, and the name. Matching on the benchmark and
the measure alone attached one alert to every variant of that benchmark and
bolded the wrong row. The iteration stays deliberately unmatched, as it always has
been, because matching it would change what an existing multi-iteration comment
renders. The alert table reads the flat value it already read, labels the variant
from alert.variant, and names the metric from alert.threshold.metric
when that is not value.

The cell's threshold badge, the no threshold warning, and --ci-only-thresholds ask
one predicate, which reads the deprecated bare check first and falls back to the
boundaries on the metric rows. Every threshold a BMF v0 payload can create is bare,
so the v0 cell is the cell it always was. A measure checked only by a threshold that
names a metric or filters variants used to render a cell shouting NO THRESHOLD
under a warning that stayed silent about it. It now links the threshold that checked
it.

The CLI perf table

The perf table gains a Parameters column between the benchmark and the measure,
where the variant's parameters sit in a perf result. The column is removed entirely
unless some line of the query plots non-empty parameters, so a project that never
reported parameters prints the table it always printed, column for column, which a
test pins byte for byte. Every cell spells its parameters canonically, the empty
ones as {}. Display of metrics other than value in the table is deferred.

The BMF v1 reference

The Bencher Metric Format reference gains a v1 section beside the v0 material, in all
nine locales: the array of entries, parameters as JSON scalars with their caps and
their canonical form, metrics with the conventional trio and the per measure cap,
bmf_version on the report and the project default a report that declares none is
read as, the v1 thresholds.models list with its optional metric and its
parameters filter, every matching threshold firing, what reset can reach at each
version, and fold being warned about and ingested unfolded.

The warning the format owes its authors is called out on its own: a v1 payload
written without its array wrapper is a valid v0 payload, so the generic json
adapter reads parameters and every metric as measures and the intended results
are silently lost. The json_v1 adapter accepts nothing but v1, so it is what
turns that mistake into a rejected report rather than a quiet downgrade.

A v1/bmf.json schema artifact is published beside v0/bmf.json. The unversioned
bmf.json is unchanged and stays the default version, v0, so nothing an existing
author validates against moves.

[github-actions]

Bencher Report

Project	Bencher
Branch	u/ep/parameters-api/tail
Testbed	intel-v1

Click to view all benchmark results

Benchmark	Latency	Benchmark Result microseconds (µs) (Result Δ%)	Upper Boundary microseconds (µs) (Limit %)
Adapter::Json	📈 view plot 🚷 view threshold	5.19 µs (+6.65%) Baseline: 4.87 µs	5.92 µs (87.78%)
Adapter::Magic (JSON)	📈 view plot 🚷 view threshold	4.97 µs (+5.37%) Baseline: 4.71 µs	5.61 µs (88.48%)
Adapter::Magic (Rust)	📈 view plot 🚷 view threshold	27.80 µs (+5.03%) Baseline: 26.47 µs	30.02 µs (92.60%)
Adapter::Rust	📈 view plot 🚷 view threshold	4.70 µs (+19.57%) Baseline: 3.93 µs	6.14 µs (76.53%)
Adapter::RustBench	📈 view plot 🚷 view threshold	4.67 µs (+19.07%) Baseline: 3.92 µs	6.11 µs (76.38%)

🐰 View full continuous benchmarking report in Bencher

[epompeii]

Review after the rebase onto devel

Rebased onto devel with the terminology sweep, carried into all nine locales of the BMF v1 reference. A second sentence describing the retired project version gate was rewritten in every locale to match devel: a project's bmf_version is the default for a report that declares none. Two independent reviews and an adjudication found one major finding.

Major: the BMF v1 reference's adoption advice cannot be followed from the CLI

v1.mdx, in all nine locales, says to select the json_v1 adapter and to set bmf_version to 1 on the report. CliReportAdapter has no json_v1 value, so bencher run --adapter json_v1 is a CLI error, and no CLI flag sets bmf_version. Only an API caller can follow either instruction, yet the page says BMF v1 needs a current bencher CLI.

The one CLI route left is an admin raising the project's bmf_version plus the generic json adapter. That route gives up the array wrapper protection the section recommends, and it is the configuration where every CLI threshold run fails (see the major finding on #1019).

Fix, a product call: either give the CLI a json_v1 adapter value and a way to declare bmf_version, or scope both instructions to API callers and describe the CLI route as it is. The threshold and reset paragraphs on the same page should follow whichever resolution #1019 takes.