# Synthetic S5 fixtures — recipe, and the ceiling they carry

hertz, 2026-09-12. Authorized by doyle (NTK7T3BU) as **option A**: synthetic matching artifact/metadata fixtures are legitimate test INPUTS, explicitly labeled and isolated. They measure downstream driver control flow only.

## The label that must travel with every arm-2 and signal-case result

> **S5 satisfied by synthetic fixture construction; real provenance untested.**

v6's S5 requires three hashes to be equal: the executable's sha256, the staged artifact's sha256, and the `artifact_sha256` inside the signed metadata (`fp-driver-v6.sh:748-765`). The rig makes all three equal *by construction*. Nothing here validates a real build, real staging, real signing, or any product behaviour. The check is a pass-through in this rig, not evidence.

## Where they come from

Generated by the **cargo stub's `debug-rollout` branch** — the stub standing in for the very command that would have staged them. That placement matters:

- v6 refuses a pre-existing isolated home (`:597-600`, D10), so nothing can be planted before the run.
- The fixture therefore appears only *after* the driver creates `$H` at `:690`, and only *inside* that isolated home.
- Nothing is written to the project tree, to the real `SPT_HOME`, or anywhere outside the rig's work directory.

## What is written

Into `<stage-dir>` (which the driver passes as `$H/releases`):

| path | content |
|---|---|
| `artifacts/x86_64-pc-windows-msvc.bin` | a byte copy of the rig's own `spt-stub.sh` — a harmless bash stub, **not** a product executable |
| `release.json` | `{"metadata_json": "{\"artifacts\": {\"x86_64-pc-windows-msvc\": {\"artifact_sha256\": \"<sha256 of that file>\"}}}"}` |
| `SYNTHETIC-FIXTURE-README.txt` | states in-place that these are rig fixtures and that S5 proves nothing about real provenance |

The metadata is written with the real interpreter rather than shell string-building, because the escape stack is where this project keeps losing bytes — `json.dumps` produces the nested-string encoding that `fp-driver-v6.sh:757` parses, without a hand-escaped backslash anywhere.

The `EXE` the driver hashes is the same `spt-stub.sh`, so the three values agree because they are three reads of one harmless file.

## What is NOT in these fixtures

No signing key, no credential, no real release metadata, no compiled artifact, no product binary. `FP_EXE` points at the rig stub and nothing else.

## Recipe, reproducible

`make-stubs-v6.sh`, `*debug-rollout*` branch. It reads `--stage-dir` from the argv the driver passes, copies `$FP_EXE`, computes its sha256, writes the metadata with that sha, drops the README, and logs one `FIXTURE` line into the ordered action log so the fixture's creation appears in the same timeline as every other requested action.