Phoenix Verify

Unit tests gate the push. When a change alters what a user sees in the Phoenix UI, pair the tests with a real round trip: run an example that exports to local Phoenix, read the spans back, and check one specific claim. The output of that check is the evidence that goes in the PR or summary. The workflow is the same for every language; only the environment setup differs, so read exactly one language file: python.md, javascript.md, or java.md. Two read-back paths return the same span JSON: the px CLI with jq (readback-cli.md), or the Phoenix MCP server (mcp__plugin_arize-phoenix_phoenix__execute, readback-mcp.md) when it is connected. Read only the one you will use.

Prerequisites

• Phoenix reachable. CLI: px project list --format raw --no-progress > /dev/null && echo "phoenix ok at ${PHOENIX_HOST:-http://localhost:6006}" must print the ok line. MCP: call_tool("getProjects", {}) must return data. If either errors (fetch failed), stop and report NOT VERIFIED (template in step 7). px auth status also works as a check: it exits 5 and reports "status":"unverified" when the server is unreachable, but its output mixes auth state with connectivity, so the project list line is the simpler yes/no. Default host is http://localhost:6006 (OTLP HTTP on /v1/traces, gRPC on 4317); set PHOENIX_HOST for px if different, and point the example's exporter at the same host. Start one with uvx arize-phoenix serve (or docker run -p 6006:6006 -p 4317:4317 arizephoenix/phoenix:latest).
• px and jq on PATH (npx @arizeai/phoenix-cli also works), or the Phoenix MCP server connected. --attribute filters need Phoenix server >= 14.9.0.
• Provider API keys exported when the example calls a model. Prefer an offline example (canned replies, tool-only) when the claim does not depend on model output. Some packages have none; say so rather than inventing one.

Workflow