Trace-To-Test Autopilot

Trace-to-test Autopilot turns a captured HAR, OpenTelemetry trace JSON, normalized browser recording, or source and destination message pair into a safe starter scenario plan.

What this page helps you do

What this page helps you do

Trace-to-test Autopilot turns a captured HAR, OpenTelemetry trace JSON, normalized browser recording, or source and destination message pair into a safe starter scenario plan.

Who this is for

Engineers writing or reviewing scenario code in one of the supported SDKs.

Prerequisites

  • A scenario or runtime surface you want to wire correctly in code

By the end

The exact SDK surface you need for this part of the runtime.

Use this page when

Use this reference when you already know the workflow and need the exact Trace-To-Test Autopilot API surface in code.

Visual guide

Trace-To-Test Autopilot readiness flow diagram
Autopilot parses captured evidence, redacts sensitive values, checks readiness, and only builds a starter scenario after required bindings or manual review are resolved.

Guide

Supported Inputs

Generate an Autopilot result from Kind values `Har`, `OtelTrace`, `PlaywrightRecording`, or `MessagePair`. FilePath and Content are supported for file-based artifacts, while MessagePair uses explicit source and destination message samples. The result includes a plan, endpoint summary, tracking selector suggestions, threshold suggestions, redactions, warnings, confidence, and optional preview report evidence.

Plan Gate

Trace-To-Test Autopilot is available on Business and above through the autopilot.trace_to_test entitlement. Generated scenarios still run through normal runner validation, so any endpoint, sink, cluster, tracking, threshold, or extension features used by the scenario must also be included in the active plan.

Safety Gates

Autopilot is fail-closed. BuildScenario only succeeds when Readiness is `Ready`. Captured secrets, missing endpoint bindings, unsafe replay targets, missing target rewrites, or weak tracking selectors return readiness states such as RequiresSecrets, RequiresEndpointBinding, RequiresTargetBinding, RequiresTrackingSelector, or RequiresReview instead of producing a runnable scenario.

Readiness Failure Reasons

`ReadinessFailures` lists every active gate with Readiness, Reason, RequiredInput, and Locations so callers know exactly what to provide next. `RequiresSecrets` means secret-like header, query, or body values were redacted and need SecretBindings that point to environment variables. `RequiresTargetBinding` means the captured HTTP target is not safe to replay until it is loopback, listed in AllowedReplayHosts, rewritten with BaseUrlRewrite, or bound through EndpointBindings as source-http. `RequiresTrackingSelector` means Autopilot could not infer a stable tracking selector and needs TrackingSelector. `RequiresEndpointBinding` means a MessagePair artifact is missing source or destination endpoint metadata and needs EndpointBindings. `RequiresReview` means the artifact is empty, malformed, missing runnable evidence, uses an unsupported replay shape, or represents a bound non-HTTP MessagePair that must still be authored manually today. When a user supplies the required setup, that failure is removed from ReadinessFailures and no longer blocks readiness.

Binding Inputs

Use SecretBindings to bind each redaction location to an environment variable, TrackingSelector to provide a selector when one cannot be inferred, and EndpointBindings to bind named endpoints such as source-http. Secret bindings store environment variable references in the generated plan and resolve the values only when the scenario executes.

Replay Target Binding

HTTP replay is only considered ready when the captured host is loopback, is listed in AllowedReplayHosts, is rewritten with BaseUrlRewrite, or is bound through an EndpointBindings entry for source-http. This prevents a recorded production host from being replayed by accident. Secret headers, query values, and body fields are redacted unless they are explicitly bound from environment variables.

Starter Scenario Shape

A ready Autopilot result builds a small starter scenario with warmup disabled, IterationsForConstant(1, 1), the inferred HTTP replay step, and conservative threshold suggestions such as zero failures and observed latency bounds. Treat it as the first runnable draft before you scale load or add richer assertions.

Preview Is Not Execution

IncludePreviewReport returns evidence about inferred endpoints, selectors, redactions, and warnings. It is separate from normal run reports; executed reports are produced only after BuildScenario returns a scenario and the normal licensed runner executes it.

Go SDK Boundary

Go workloads should use the documented `loadstrike.com/sdk/go` package and the same runner flow as other scenarios. Autopilot stays behind the same public SDK surface as the rest of LoadStrike.

SDK reference samples

Use these samples to generate a safe starter scenario from a captured artifact, bind any required secrets, targets, endpoints, or tracking selector, and only execute after Autopilot reports Ready.

If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.

Autopilot From HAR

using LoadStrike;

var result = LoadStrikeAutopilot.Generate(new LoadStrikeAutopilotRequest
{
    Kind = "Har",
    Content = File.ReadAllText("orders.har.json"),
    Options = new LoadStrikeAutopilotOptions
    {
        ScenarioName = "orders-autopilot",
        BaseUrlRewrite = "http://127.0.0.1:5080",
        IncludePreviewReport = true,
        TrackingSelector = "header:x-correlation-id",
        SecretBindings =
        [
            new LoadStrikeAutopilotSecretBinding
            {
                Location = "header:Authorization",
                ValueFromEnv = "ORDERS_AUTH_HEADER"
            }
        ]
    }
});

if (result.Readiness != LoadStrikeAutopilotReadiness.Ready)
{
    throw new InvalidOperationException(string.Join("; ", result.Warnings));
}

var scenario = result.BuildScenario();

LoadStrikeRunner.RegisterScenarios(scenario)
    .WithRunnerKey("rkl_your_local_runner_key")
    .Run();

Autopilot Flow

Input kinds

Use Har, OtelTrace, PlaywrightRecording, or MessagePair depending on the artifact you captured.

Readiness

BuildScenario is available only when Readiness is Ready. Other states explain what must be bound or reviewed first.

Readiness failures

ReadinessFailures reports every active gate with the required input and affected locations. RequiresSecrets needs SecretBindings, RequiresTargetBinding needs BaseUrlRewrite, AllowedReplayHosts, or a source-http EndpointBindings entry, RequiresTrackingSelector needs TrackingSelector, RequiresEndpointBinding needs MessagePair EndpointBindings, and RequiresReview means the artifact still needs manual review or cannot yet produce a runnable non-HTTP starter.

Target safety

Use BaseUrlRewrite, AllowedReplayHosts, or an EndpointBindings entry for source-http before replaying a captured non-loopback host.

Secret bindings

Use SecretBindings to map returned redaction locations such as header:Authorization or body:$.client_secret to environment variables. Secret values are resolved at execution time, not written into the generated plan.

Tracking selectors

Use TrackingSelector when the artifact does not contain a stable inferred selector.

Redactions

Review the returned redactions and warnings before committing the generated scenario to a longer test.

Preview report

IncludePreviewReport produces inference evidence only; executed LoadStrike reports still come from the normal runner.

Start with the generated one-iteration scenario, then raise load, add assertions, and commit the final scenario only after the captured workflow is safe to replay locally or in your test environment.