Run with the backend virtual environment from the repository root. Credentials are read from the private fixture env file and are recursively removed from evidence. The backend target is restricted to localhost and configured Superset origins are restricted to the three isolated Compose services.

backend/.venv/bin/python scripts/full_flow/create_fixture.py
backend/.venv/bin/python scripts/full_flow/verify.py \
  --env-file /tmp/ss-tools-full-flow.env \
  --fixture /tmp/full-flow-fixture.json --phase setup

For a fresh isolated ledger, run the complete verifier with --phase all. It also registers trusted local live providers through the admin API and restarts only the isolated backend to load them. Expected unresolved product boundaries remain exit code 1 with retained evidence; no terminal PASS is manufactured.

Run phases in order: setup, release, scenario, reference, publication, profile, runtime_prepare, live_config, replay, scheduled. After a standalone live_config phase, restart the backend with the isolated Compose command before replay. Each phase retains previous evidence and real object IDs in specs/050-mcp-interface/evidence/docker-full-flow/report.json. A failed boundary stops the phase. Historical failed attempts remain visible. Exit code 1 means the current phase has unresolved evidence; the report never grants production GO.

The public fixture JSON contains backend_url, dashboard_id, metric, expected_value, reference_url, catalog_repo, catalog_branch. The reference URL uses the backend's configured Superset origin and explicit native filter state. For the seeded region North, total revenue is the hardcoded value 16350.

After baseline consume, independently extract the actual persisted baselines.yaml.revisions.jsonl from the isolated backend filesystem into /tmp/full-flow-catalog-revisions.jsonl, and set fixture revision_file to that path. The extraction command performs this read and updates the fixture:

backend/.venv/bin/python scripts/full_flow/extract_revision.py \
  --env-file /tmp/ss-tools-full-flow.env --fixture /tmp/full-flow-fixture.json

The publication phase verifies that the persisted revision names the actual consumed baseline and capture artifact before posting it to the normal publication API. This operator extraction is necessary because the REST catalog reader exposes entries without the server-owned revision envelope.

Publication uses real Gitea mutations and independently reads committed bytes. It does not manufacture receipt rows. The profile phase uses a fresh MCP HTTP client and preserves unresolved baseline binding as a real T029a blocker. The baseline-free T01 registry flow exists to exercise the reference preview boundary; runtime_prepare obtains fresh MCP-owned AgentRun/handles and a current revision through the real bootstrap_authoring_scenario tool. live_config observes actual Superset Admin login and empty RLS configuration, and binds the genuine release and fresh query-model snapshot through the admin settings API. replay pins the published catalog on both manual and scheduled runs. The scheduled phase pauses the test cron after retaining the independent scheduler outcome.

Runnable status must be demonstrated by the replay phase, which fails closed if the existing executor cannot bind that graph. No literal expectation or arbitrary runtime step metadata is injected.