ss-tools/scripts/full_flow_v2

Typed metric Docker verification

This harness writes a separate ledger under specs/050-mcp-interface/evidence/docker-full-flow-v2; earlier evidence is retained. It uses actual HTTP/MCP boundaries and the existing isolated Docker services.

The initial inspect phase records current server model and public tool inventory. The author phase calls the public M01 propose → resolve → register → bootstrap tools. It checks stale CAS rejection, exact approved capture binding, idempotent resolution replay and server-issued v2 eligibility. It never supplies result types or expected values.

Prepare a new public fixture using scripts/full_flow/create_fixture.py with a new /tmp/full-flow-v2-fixture.json output. Add a unique accepted version such as v0.3.0-docker.v2 and capture_context_report pointing to the previous retained report. Existing scenario IDs are used solely as a real authoring context for fresh capture; execution must create and admit its own M01 revision.

backend/.venv/bin/python scripts/full_flow_v2/verify.py \
  --env-file /tmp/ss-tools-full-flow.env \
  --fixture /tmp/full-flow-v2-fixture.json --phase inspect

The capture must follow a new real release. Its new IDs, revised model fingerprint, exact North filter and separately published generation will be checked before metric execution. PREPROD capture uses the release candidate's environment; publishing PROD does not change that provenance.

After genuine release/capture/publication and live binding restart:

# Use the same private env and public fixture flags shown above.
# --phase author        new server-owned M01 current revision
# --phase manual        genuine producer + comparator PASS
# --phase mutate_restore  isolated DB revenue110→111→110, FAIL then PASS
# --phase scheduled     independent cron run, exact pin, pause after observation

mutate_restore requires Docker access and restores the fixture row in a finally block. No catalog or expected entry is changed. The scheduled phase observes up to 55 seconds; repeat it if the next cron boundary was not reached. Prior failed attempts remain in the ledger and are never relabeled as PASS.

Retained acceptance checkpoint (2026-10-01)

The real Docker public M01 chain admitted scenario 39593d44-0bc8-4ce3-b7f5-aa0aa68ed210, revision 315151ad-b731-4300-9bc4-9ee478cf8359, against published release 7212c87b-4954-4d22-9de7-4c8685258d39 (v0.3.0-docker.v2) and baseline 03833feb-06bd-4332-bc05-dc3ca63325f2 in full-flow-sales-v2/1, Git commit db09f883181cde36dab54bd67a71f4a4cb4fb5f3.

Actual run	ID	Observed / expected	Verdict
Manual	17c953d0-6b58-4619-8ce9-87f01c2e5835	16350 / 16350	PASS
Mutated North fixture	986e4c04-e5eb-4baf-876d-1eaf44c4a89b	16351 / 16350	FAIL
Restored fixture	45410e80-0df0-4771-b2e8-1fd90df16986	16350 / 16350	PASS
Independent cron	0a99673d-7890-462a-ad3e-1a932a0481d9	16350 / 16350	PASS

Each result contains both required producer and comparison steps, exactly one attempt each. Approved pins and the saved scenario revision are identical across these runs. The restored source response SHA equals the original manual SHA. The fixture row was restored to 110.00. Independent cron acceptance also passed with the same immutable pin. Schedule 284ae170-34a3-4f9a-a735-43a8a29380b6 was paused through the normal API after observation. An earlier cron attempt exposed a missing server release selector and is retained as a failure.

The admitted current model fingerprint is sha256:bfc5ca501dfc040add49d1fcb0853890f3427ad04065bfe702c46d5453638d81. report.ids.query_model_fingerprint belongs to the historical initial inspect phase before DEV changes; it is not the admitted execution fingerprint.

After all four actual result files exist, run the independent read-only proof:

backend/.venv/bin/python scripts/full_flow_v2/audit_results.py

It creates independent-result-audit.json and refuses missing comparison rows, wrong scalars, changed approved pins or missing cron evidence. This acceptance covers isolated numeric M01 execution only. It does not declare global or production GO. Historical failures, including the earlier producer-only partial PASS, remain in the report and do not count toward acceptance.

Closed table text recipe

The recipe driver uses a fresh ledger under specs/050-mcp-interface/evidence/docker-stage6/table-text-live. Prepare it with prepare_recipe_driver.py, a configured provider ID, and the previous fixture and report. Preparation copies approved publication locators only; it creates fresh authoring and run IDs. The public request adds the paired evidence_recipe=table_text_v1 and evaluation_provider_id fields.

Run verify.py with the new fixture and explicit output directory, first with --phase author, then --phase manual and --phase scheduled. The recipe observes cron for up to 180 seconds and pauses its schedule after observation. These phases require all five nodes: metric query, explicit North filter, observed table, declared evaluation and immutable baseline comparison.

After both runs finish, use extract_recipe_evidence.py with both actual run IDs to create a new recipe-evidence-map.json, then run --phase recipe_evidence. The extractor reads whitelisted ownership and immutable evaluation fields. The driver retrieves artifact bytes through authenticated content routes and checks ownership, SHA, length, declared JSON inputs, observed North scope, exact raw metric, approved pin and released evaluator capacity leases. Other run leases remain in the map. Browser display rounding is context evidence; the raw metric supplies the exact numeric comparison.

The final independent recipe authority scope passed 99 tests, including actual plan-to-transport input projection and refusal after unproven native scope. Separate real PostgreSQL gates passed nine allocator and four transport tests, including contention, committed admission before HTTP, cancellation and a real timeout. These checks do not replace the actual public manual/cron evidence or the outstanding full-suite and global GO gates.