test: every real-server cycle writes a recipe and exports through it

[JArmandoAnaya]

Part of the pre-processing epic (#785): the last phase, which puts a recipe into every real-server cycle. A change that alters export output escalates to the cycle scenarios by the checks policy, and until now none of the four walked past the shipped recipe surface.

What changed

The browser cycle (frontend/app/cycle/cycle.spec.ts) publishes its release with a split — the dialog's own 0.7 / 0.15 / 0.15, which puts two of the three assets in the train fold — and, after the existing yolo11 export, walks two more steps. The first writes a recipe on the Dataset's Pre-processing view the way a person does: the empty view's invitation, a name, YOLO11 as the target (asserting its hints preselected letterbox 640×640), hflip ticked (asserting it made one variant), the first preview row rendered through the real preview route, Save recipe. The second exports through it from the export dialog's recipe picker, meets the lossy consent again, and opens the download: the report names the recipe under a 64-hex recipe_hash, and both train-fold images have an images/train/<hash>-aug1.png with a labels/train/<hash>-aug1.txt beside them, traced to their source by the report's mapping. The refused-call roster gains the second export's 409 — the consent question, asked once per launch, exactly as before. The zip reader now walks the central directory into a listing so a variant can be found by pattern.

The three surface examples each gain a recipe step in their own idiom. HTTP creates the recipe with POST /projects/{p}/preprocessing-recipes, asserts the first ?target=yolo11&recipe=yolo-640 launch answers 409 LOSSY_EXPORT_NOT_CONSENTED, retries with allow_lossy=true, and reads the report and the -aug1 label out of the downloaded zip. MCP calls create_preprocessing_recipe and list_preprocessing_recipes, exports with recipe= and allow_lossy=True, and checks the result's preprocessing mapping against the files on disk. The shell script runs visionset recipe create … --resize letterbox:640x640 --augment hflip --variants 1 --target yolo11 and export --target yolo11 --recipe yolo-640 --allow-lossy, then asserts the report and its three train variants through python3. Every release in the three examples was already published with a split, so augmentation runs in all of them; each Summary carries the hash and the variant, and the smoke tests under tests/examples/ pin them.

docs/content/examples.md and docs/content/mcp-walkthrough.md describe the new steps.

Found, not fixed

hflip is a seeded coin per variant, so a variant can be byte-identical to its source (the HTTP example's single train image is). The cycles assert on names and the mapping, never on bytes.

Stack

Position 6 of the pre-processing stack (#785); based on main after #801.

Checks

Targeted while iterating: uv run python examples/http_end_to_end.py, uv run python examples/mcp_end_to_end.py, uv run bash examples/cli_end_to_end.sh, uv run pytest tests/examples/test_{http,mcp,cli}_end_to_end.py (22 passed), pnpm --filter @visionset/app lint, and the cycle suite (1 passed (32.8s)).

Full bash scripts/check.sh on the final tree:

Timing
     41s  python tests
      0s  ruff (lint)
      0s  ruff (format)
      7s  mypy
      0s  import contracts
      5s  frontend build
     30s  frontend tests
     11s  frontend lint
      1s  openapi drift
      1s  generated client drift
      0s  mcp tool reference drift
      1s  export target catalog drift
      0s  version sync
     45s  annotator + app e2e (chromium)
     34s  browser cycle, real server (chromium)
    176s  total

All checks passed.

check.sh: PASSED  ran=python,frontend,generated,browser  skipped=docs