Trait BenchmarkCases

Source

pub trait BenchmarkCases: Sized + Serialize {
    // Required method
    fn benchmark_cases(ctx: &CaseContext<'_>) -> Vec<NamedCase<Self>>;

    // Provided method
    fn benchmark_cases_json(ctx: &CaseContext<'_>) -> Vec<NamedCase<Value>> { ... }
}

Expand description

Representative inputs of a capability’s input type. Implemented once per input type; the capability! macro requires it, so a new capability without a benchmark case is a compile error, not a coverage report.

use majordomus_cli::capability::{BenchmarkCases, NamedCase, CaseContext};
#[derive(serde::Serialize)]
struct Input { limit: u64 }
impl BenchmarkCases for Input {
    fn benchmark_cases(_: &CaseContext<'_>) -> Vec<NamedCase<Self>> {
        vec![NamedCase::new("default", Input { limit: 10 })]
    }
}

Required Methods§

Source

fn benchmark_cases(ctx: &CaseContext<'_>) -> Vec<NamedCase<Self>>

The cases, in a stable order. An empty list means “nothing to benchmark in this repository”, which the coverage check reports as missing.

Provided Methods§

Source

fn benchmark_cases_json(ctx: &CaseContext<'_>) -> Vec<NamedCase<Value>>

The cases as JSON, the shape every runner serialises from.

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§

Source §

impl BenchmarkCases for majordomus_cli::capability::builtin::environment::ExplainInput

Source §

impl BenchmarkCases for majordomus_cli::devcontext::ExplainInput

Source §

impl BenchmarkCases for GetDeploymentInput

Source §

impl BenchmarkCases for GetInput

Source §

impl BenchmarkCases for GraphInput

Source §

impl BenchmarkCases for HistoryInput

Source §

impl BenchmarkCases for InspectInput

Source §

impl BenchmarkCases for IntentBindingInput

Source §

impl BenchmarkCases for IntentExplainInput

Source §

impl BenchmarkCases for IntentPreflightInput

Source §

impl BenchmarkCases for IntentProposeInput

Source §

impl BenchmarkCases for IntentRealizationInput

Source §

impl BenchmarkCases for IntentRecordInput

Source §

impl BenchmarkCases for KnowledgeRecordInput

Source §

impl BenchmarkCases for ListInput

Source §

impl BenchmarkCases for McpProjectionInput

Source §

impl BenchmarkCases for ModelsFilter

Source §

impl BenchmarkCases for NextInput

Source §

impl BenchmarkCases for ObservatoryEventsInput

Source §

impl BenchmarkCases for ObserveInput

Source §

impl BenchmarkCases for PackPlanInput

Source §

impl BenchmarkCases for PackVerifyInput

Source §

impl BenchmarkCases for PlanIssueFilter

Source §

impl BenchmarkCases for PlanMilestoneFilter

Source §

impl BenchmarkCases for PlanPreviewInput

Source §

impl BenchmarkCases for PlanRecordInput

Source §

impl BenchmarkCases for PlanTransitionInput

The benchmark cases of the one capability here that writes.

Every case is a refusal, and that is deliberate rather than a gap. A case is executed — by majordomus bench against this repository, and by the HTTP and MCP suites against a fixture — so a case that moved an issue would change the plan every time the suite ran, and a measurement whose cost is a changed record is not a measurement. The runner states the principle that makes this sound: “a refusal is an answer, and answering is the work a benchmark exists to measure”, and only Internal is fatal.

The refusal path is also the honest thing to time: it builds the plan, resolves the issue and evaluates the guard, which is everything the write path does except the two syscalls at the end.

The refusal must be a refusal and not a lookup miss. An earlier version named an issue that could not exist, which answered 404 rather than 422, and tests/http_serve.rs holds every route to answering its own cases — 200, or 422 for a command that turns a caller down. Choosing the move from the record keeps the case inside that contract.

So a plan with no issue yields no case, and the handler is not bent to make one: naming an issue the plan does not have is NotFound whether or not the plan holds other issues, and a 422 that appeared only when the plan is empty would make the same request’s answer depend on records it never named. The descriptor declares the requirement conditional on BenchmarkPrecondition::PlanHoldsAnIssue instead, and coverage reports it inapplicable in such a repository — and missing, as before, in one whose plan holds an issue.

Source §

impl BenchmarkCases for PreflightInput

Source §

impl BenchmarkCases for QualityInput

Source §

impl BenchmarkCases for majordomus_cli::why::Query

Source §

impl BenchmarkCases for majordomus_cli::mesh::page::Query

Source §

impl BenchmarkCases for ReasoningExplainInput

Source §

impl BenchmarkCases for ReasoningRecordInput

Source §

impl BenchmarkCases for ReasoningStatusInput

Source §

impl BenchmarkCases for RecoverOrphansInput

The benchmark cases of the capability that sweeps.

Every case is a check, and that is deliberate rather than a gap. A case is executed — by majordomus bench against this repository, and by the HTTP and MCP suites against a fixture — so a case that swept would delete this repository’s stray files every time the suite ran, and a measurement whose cost is a changed store is not a measurement. The check path is also the honest thing to time: it walks every store, stats every candidate and reads every publish temp, which is everything the sweep does except the unlink at the end.

Two cases rather than one because case 92 refuses a declared parameter that no case ever sets, and because the two thresholds measure different work: the generous one classifies every stray, the tight one classifies none of them as Live and so reads every file.

Source §