Scenario inputs live here, one strict versioned JSON file each. A scenario names the surface and task it stands for, carries fixture metadata and a permission mode, scripts the sequence the fake provider replies with, and pins each fault to an exact occurrence of a named point. Its tags place it in a tier, and its expectations state the terminal reason and the event invariants the run has to satisfy. Nothing executes until ../schema.py has loaded the file: an unknown or ambiguous field fails the load, and ../runner.py never gets to run it.
| File | Responsibility |
|---|---|
.gitkeep |
Keeps the scenario root tracked on its own, whatever scenario groups exist beneath it. |
| Directory | Responsibility |
|---|---|
baseline/ |
The required offline tier:pr scenarios. They cover deterministic provider sequencing, terminal submission, and scheduled failure behavior. |
orchestration/ |
Twelve scenarios that drive the real Reconciler against a scripted backend (M4-4). Unlike the baseline family, these import production code on purpose — the reconciler's decision function has no live boundary a fake would stand in for, and its inputs are a workload row and an observation, both of which are data. Seven of the twelve declare a non-success terminal — a refused submission, a cancellation, or a lost job — and such a scenario fails when the run reports success. |
Scenario JSON is input to the declared Harness fakes and nothing else; it is not permission to replay production side effects. Run a tier with uv run python -m harness.cli run --tier pr --offline.