git:20260910.8b8e2ed to git:20260914.34daa72

---

name: run-scenario

description: Drive a reproducible request scenario against a locally running service - ad-hoc requests, or a stored k6 benchmark from .odd/benchmarks/ - and record it verbatim, so the telemetry it produces can be compared with a later run. Use when traffic must be generated before observing a service, when a stored k6 benchmark must be run, when an observation report needs a replayable scenario, or when verifying after a fix that the same scenario now measures better.

---

# Run a Scenario

One protocol on both ends of the ODD loop: the same commands that produced

the numbers in an observation report produce the numbers that verify the

fix. A scenario that cannot be replayed verbatim makes before/after

comparison an impression, not a measurement.

**A step this package ships a script for is run, never rewritten.** The

## Read by situation

block that applies, never whole:

| Situation | Reference |

| --- | --- |

Start with the identity reference, then follow the steps below.

## 1. Decide what to exercise

In order of preference:

1. **The caller's list** — endpoints, payloads, and counts given in the

mission. Use them as-is; do not "improve" them.

2. **Traces already in the stack** — the operations the stack's traces

name for this service are what the service actually serves: the

service probe (the `setup-local-stack` skill's) and the backend

reference's discovery script both list them — read that output

rather than querying again.

3. **The service's own contract** — an OpenAPI/Swagger document, a route

table, a CLI entry point in the repository (read-only).

Prefer a handful of representative operations covered properly over every

operation covered once. Note anything you deliberately left out.

## 3. Iterate enough to quote a number

- **>= 30 requests per operation** before quoting a p95 — an operation

being the unit the service serves distinctly: on an HTTP server the

method and the route together, so two verbs sharing a route need the

- **~100** before quoting a p99.

- Keep inputs deterministic: fixed IDs, fixed payloads, a fixed seed. A

## 4. Record verbatim

```text

Scenario: <name>

Started (UTC): 2026-08-17T10:04:12Z

Ended (UTC): 2026-08-17T10:05:03Z

Commands:

```

## 5. Wait for the flush — once per query point

## Output

## Rules

- Drive the service only; never change its code or configuration to make a

scenario nicer. If a scenario cannot run as given, report why.

- Replay after a fix with the **same** commands, counts, warmup, and

concurrency — one changed variable invalidates the comparison.

- Same machine, same data volume, same environment where possible; if

something differed between the two runs, say so next to the numbers.

- A failed or partial run is data: record the failures and their counts

rather than retrying silently until the numbers look clean.

- A driven request that calls a paid model spends money — every warmup

and every iteration of it. Like a drive at a remote target, it is

confirmed by the caller before the first such request goes out: the

operation, the model when known, and the request count with the

warmup included; the mission block saying the spend is accepted is

that confirmation, a stored benchmark's manifest never is — it

authorizes the load's shape, not the bill. No confirmation, no

drive: leave the model-calling operations out, or stop, and say

which in the record. An operation calls a paid model when the

mission says so, when the stack's traces already show `gen_ai.*`

spans under it, or when the service's own contract names a model;

an operation you cannot rule either way is left out too, named in

the record as unruled — a stop-and-report, never a question the

drive waits on.