# Real provider evidence for PR 24576 Evidence only; no production/test source changes. Worktree: `/home/ubuntu/wt/pr-24576`. Baseline: `3cc31ed27c8956b36cee35a50509fb7c6869592b`, verified merge-base with origin/main. Head: `13e24a9d913e9bf072a2d00a72bdb65ee12f4af7`. Each SHA has one completed real turn per row: - **A-real:** installed **OpenCode 1.18.18** via **T3 generic ACP/local-command adapter** (`acpRegistry`, instance `acp-real`), model `openai/gpt-6.1-sol`. Actual ACP `session/prompt` arrays plus actual `end_turn` responses and completed T3 run replies `EV24576_ACP_OK`. This is a real ACP subprocess, not the mocked acp-test provider. It does not claim a successful Grok/Cursor/Pi turn. - **O-real:** scratch-installed **OpenCode 2.0.28**, selected through T3's native v2 adapter with a **T3-owned server**, model `openai/gpt-6.1-sol`. Actual MCP PUT 204, `session.instructions.entry.put` HTTP PUT 204, native prompt POST 200 and completed T3 run replies `EV24576_OC2_OK`. Both captured baseline payloads contain CORE, the Codex discovery example, and the ACP paragraph. After: ACP retains CORE + ACP, gains the full delegate_task launcher, and excludes the Codex example. Native OpenCode retains CORE and excludes both provider-specific paragraphs. `assertions.json` checks the actual captured payload strings; no instruction builder is called by the capture or export scripts. `*-real.json` preserves the selected actual transport messages, complete instruction strings and completed run results. `*-real.txt` decodes the complete delivered instruction text (ACP text blocks appear in order separated by blank lines). `*-delivered.diff` compares the delivered text. Runtime turn/session identifiers naturally differ. `production.diff` records the pinned source delta for provenance, not as a substitute for the live captures. ## Capture method ACP uses a scratch-only Python byte-forwarding tee that launches the installed real CLI with unchanged args, forwards stdin/stdout lines unchanged, and observes protocol messages. Only prompt/update/completion payloads are recorded in full; other methods are recorded as method/status metadata, so injected MCP credentials are never copied into this public evidence. Native OpenCode uses a scratch-only Node preload wrapping global fetch. T3's production FetchHttpClient still executes its actual HTTP requests against its actual owned OpenCode server. The preload observes cloned request/response bodies and statuses; it neither replaces the client/service nor supplies responses. Authorization headers are not captured. Public MCP configuration bodies are omitted; actual MCP status and endpoint remain. Complete instructions and prompt bodies are retained. The baseline trace initially observed inventory GETs too; the exporter allowlists only the relevant successful MCP/instructions/prompt requests. The head tracer narrows observation to those routes. No unredacted private server logs, provider configs, credential files, databases, or .env files are included. An export scan checked all public text against inherited credential values and selected provider-config credentials. ## Reproduce one row Scripts are in `scripts/`. They expect the same installed workspace dependencies, installed OpenCode 1.18.18 location, and the machine's existing OpenCode provider endpoint configuration. `setup.py` reads that provider config and copies it **only into an isolated scratch config**. It selects only endpoint settings from Grok config; no shared config is modified. Run commands from `/home/ubuntu/wt/pr-24576`. Stop prior capture servers first. Ensure the desired pinned SHA is checked out and clean. Restore scripts into `/tmp/ev-24576-capture/` if extracted elsewhere. Install the matching v2 binary once: ```bash npm install --prefix /tmp/ev-24576-capture/opencode2 @opencode/cli@2.0.28 --no-audit --no-fund python3 /tmp/ev-24576-capture/setup.py python3 /tmp/ev-24576-capture/server.py ``` The server supervisor starts the exact required `vp run dev --no-seed --home-dir /tmp/ev-24576/`, with no VITE_HTTP_URL or VITE_WS_URL and no ambient T3 home or telemetry endpoints. It records the runner PID and continuously records descendant PID/start-time identities. Keep it running in a terminal; no browser is needed. In a second terminal, after the isolated server has started (do not print its private pairing URL): ```bash node apps/server/src/bin.ts project add /home/ubuntu/wt/pr-24576 --base-dir /tmp/ev-24576/$(git rev-parse HEAD) python3 /tmp/ev-24576-capture/run-row.py A # Or run-row.py O for native v2. python3 /tmp/ev-24576-capture/stop.py /tmp/ev-24576/$(git rev-parse HEAD) ``` If reusing the isolated database, `project add` reports that the project already exists; continue to run-row. The row driver creates one new real turn, bounds its completion wait to 240 seconds, and writes the result without dumping private logs. For another complete paired export, capture both rows at each pinned SHA, stopping all owned processes before switching. `export.py` validates and exports the pair. Preserve existing evidence first: rerunning a row overwrites its result file and appends to the wire log, so export.py intentionally rejects multiple prompts/instruction PUTs rather than silently selecting one. The primary captures used the same tee/preload approach. Baseline launch commands predated run-row.py; that script now reproduces the same CLI invocation. The head captures used run-row.py directly. A baseline OpenCode internal title-helper request failed on an unavailable small-model alias, but the main requested gpt-6.1-sol turn subsequently completed successfully. Head scratch config pins the helper small_model to gpt-6.1-sol to avoid that unrelated request failure. ## Limits and cleanup Grok 1.0.67 was attempted first. It failed before prompt delivery: it advertises only `grok.com` authentication, but T3 selected `xai.api_key`. No successful Grok turn is claimed. No live service was restarted. No credentials were printed or uploaded. Coverage is the two requested real core paths, one successful turn per row per SHA. It does not add detached, compaction, mode-transition or all-provider live coverage; prior fixture matrix covers those separately. Real ACP/native acceptance and completed model turns do not prove that every possible agent will follow the instructions. Both dev servers and captured provider descendants were stopped before returning. `pids.jsonl` records captured PID/start-time identities. `before-cleanup.json` and `after-cleanup.json` report cleanup. Baseline supervisor: 2670337; head supervisor: 2676149. Runner and provider PIDs are enumerated in the ledger. The tee ledger uses its original `grok` kind label for every child it launches, including the later OpenCode ACP children; this is a logger label, not a provider identity claim. The successful ACP wire sections have argv `["acp"]`; their actual configured executable and cached provider identity are recorded in `provider-provenance.json`. Cleanup was graceful; fallback TERM/KILL survivor lists are empty. The final cleanup audit is in `final-process-audit.json`. No browser, preview recorder, real T3 userdata access, shared credential modification, PR mutation/comment/watch, or source change. Scratch retained for pass 2 audit. Captured with Codex harness, gpt-6.1-sol; uploads use the ghdrop skill.