refactor(dashboard): remove Phoenix read-through UI

.agents/product-boundary.md

@@ -25,9 +25,9 @@ After the 2026-06-20 product decision, Phoenix is not an AgentV artifact owner o
 
 AgentV must not export or project completed AgentV runs, traces, transcripts, datasets, experiments, or indexes into Phoenix. AgentV-owned Git/GitHub run artifacts and the local Dashboard remain the supported zero-infra inspection path for AgentV run, trace, session, transcript, and comparison data.
 
-Phoenix may be referenced as UI inspiration and as optional external trace infrastructure when Codex, Arize, or another hook already emitted spans independently. The supported integration shape is read-only correlation/read-through through Phoenix GraphQL/API using safe `external_trace` metadata. That metadata can point from an AgentV artifact to an external Phoenix trace or session, but Phoenix does not become the storage, transcript, index, or run system of record.
+Phoenix may be referenced as UI inspiration and as optional external trace infrastructure when Codex, Arize, or another hook already emitted spans independently. The supported integration shape is link-out correlation through safe `external_trace` metadata. That metadata can point from an AgentV artifact to an external Phoenix trace or session and provide an `Open in Phoenix` URL, but Phoenix does not become the storage, transcript, index, or run system of record.
 
-Dashboard must not require the `px` CLI at runtime, must not query Phoenix database tables directly, and must not introduce a Phoenix runtime dependency for the zero-infra local path. If Phoenix data is surfaced later, it should be through the public Phoenix GraphQL/API boundary and should degrade cleanly when Phoenix is unavailable.
+Dashboard must not require the `px` CLI at runtime, must not query Phoenix database tables directly, must not proxy Phoenix GraphQL/REST, and must not introduce a Phoenix runtime dependency for the zero-infra local path. If Phoenix data is needed, Dashboard should direct users to Phoenix through a safe external link instead of duplicating Phoenix sessions, traces, or spans inside AgentV.
 
 AgentV transcript artifacts are not Phoenix-native conversation inputs. Model-call spans may contain cumulative input messages, so treating Phoenix span input as a linear transcript can duplicate or distort the conversation. Keep AgentV transcript/index/storage semantics in AgentV artifacts.
 

AGENTS.md

@@ -17,7 +17,7 @@ Phoenix boundary after the 2026-06-20 product decision:
 - AgentV-owned run bundles, traces, transcripts, datasets, experiments, indexes, and Git-backed artifacts are not exported or projected into Phoenix.
 - The local Dashboard is the supported zero-infra inspection path for AgentV run, trace, and session artifacts.
 - Phoenix may be referenced as UI inspiration and optional external trace infrastructure only when Codex, Arize, or another hook already emitted spans independently.
-- Optional Phoenix integration is read-only correlation/read-through through Phoenix GraphQL/API using safe `external_trace` metadata.
+- Optional Phoenix integration is link-out correlation only through safe `external_trace` metadata and an `Open in Phoenix` URL when available.
 - Dashboard must not require the `px` CLI at runtime or query Phoenix database tables directly.
 
 Design guardrails:

ROADMAP.md

@@ -11,20 +11,20 @@ This roadmap translates [STRATEGY.md](STRATEGY.md) into the next few product pha
 - Phoenix is optional external trace infrastructure only when Codex, Arize, or another hook already emitted spans independently; AgentV may correlate with those sessions but does not write AgentV artifacts into Phoenix.
 - Harbor stays an optional benchmark-grade runner boundary, not AgentV core.
 - AgentV YAML remains the authoring surface even when execution moves behind another runner; prefer a lightweight translation layer over duplicated specs.
-- Adapters, workers, and artifact projections are preferred over rebuilding adjacent platforms inside AgentV, except Phoenix: Phoenix integration is read-only correlation/read-through and not an AgentV-to-Phoenix projection path.
+- Adapters, workers, and artifact projections are preferred over rebuilding adjacent platforms inside AgentV, except Phoenix: Phoenix integration is link-out correlation only and not an AgentV-to-Phoenix projection path.
 
 ## Phase 1: Finish the artifact and local inspection foundation
 
 - Keep the canonical handoff surface centered on completed run bundles, `index.jsonl`, grading/timing artifacts, and `outputs/trace.json` sidecars.
 - Finish the vendor-neutral local export seams that let completed runs be re-read, compared, exported, and attached to non-Phoenix adapters without vendor-specific logic in core.
 - Keep OTLP/OpenInference mapping generic and reusable before building backend-specific upload or import paths.
 
-## Phase 2: Keep Phoenix read-only and externally owned
+## Phase 2: Keep Phoenix link-only and externally owned
 
 - Document the Phoenix boundary across public docs, CLI help, Dashboard copy, and AI-facing guides.
-- Allow optional read-only Phoenix session links or views through Phoenix GraphQL/API when safe `external_trace` metadata points at spans emitted independently by Codex, Arize, or another hook.
+- Allow optional Phoenix links when safe `external_trace` metadata points at spans emitted independently by Codex, Arize, or another hook.
 - Keep Phoenix from owning AgentV transcript, index, run, dataset, experiment, or storage state.
-- Keep Dashboard free of a Phoenix runtime dependency: no `px` CLI requirement and no direct reads from Phoenix database tables.
+- Keep Dashboard free of a Phoenix runtime dependency: no `px` CLI requirement, no Phoenix GraphQL/REST proxy, and no direct reads from Phoenix database tables.
 
 ## Phase 3: Strengthen the local cockpit and the product boundary
 
@@ -38,7 +38,7 @@ This roadmap translates [STRATEGY.md](STRATEGY.md) into the next few product pha
 - Harbor: move toward Harbor becoming the benchmark-grade runner behind a lightweight translation layer from AgentV YAML, while AgentV stays the authoring, gating, import, and comparison surface.
 - Harbor: in the near term, launch or import benchmark-grade runs through a runner boundary; over time, converge on Harbor as the execution layer for the suites it already owns.
 - Opik and similar systems: consume completed AgentV projection bundles as post-run adapters rather than as runtime owners.
-- Phoenix: remain excluded from AgentV post-run export/projection; use read-only correlation/read-through only.
+- Phoenix: remain excluded from AgentV post-run export/projection; use link-out correlation only.
 - Additional observability backends should reuse the same projection and export seams instead of adding new core product models.
 
 ## Not On This Roadmap

STRATEGY.md

@@ -40,7 +40,7 @@ _Why it serves the approach:_ Portable artifacts let local runs, CI, static repo
 
 ### Adapter-led integrations
 
-Add Phoenix, Harbor, Opik, Langfuse, and similar systems through narrow correlation, runner, adapter, or export boundaries rather than copying their product models into core. For Phoenix specifically, the supported boundary is read-only correlation/read-through from safe `external_trace` metadata; AgentV does not export or project completed runs, traces, transcripts, datasets, experiments, or indexes into Phoenix.
+Add Phoenix, Harbor, Opik, Langfuse, and similar systems through narrow correlation, runner, adapter, or export boundaries rather than copying their product models into core. For Phoenix specifically, the supported boundary is link-out correlation from safe `external_trace` metadata; AgentV does not read through, export, or project completed runs, traces, transcripts, datasets, experiments, or indexes into Phoenix.
 
 _Why it serves the approach:_ This expands AgentV's reach without turning it into a hosted observability stack, benchmark platform, or integration kitchen sink.