# Pi alias runtime proof

The app is unmodified on both commits, with separate fresh databases and synthetic data.
The replay scenario runner cannot exercise Pi's tool loadout.

The unmodified prompt did not yield reliable alias calls: one read used the public
hyphenated name, and discovery-enabled attempts declined to call an undeclared tool.
Those attempts are not counted as successful proof.

The controlled comparison adds alias-request.ts to both Pi launches. It changes only
the provider request's tool declaration and first-call tool choice, making the real
Anthropic model request the exact underscore alias. It neither registers nor activates
any Pi tool and neither executes a call nor injects a result. The real Pi 1.4.0 runtime,
T3 bridge, HTTP MCP endpoint, orchestration, database and web client execute the call.
Base returns "Tool mcp__t3_code__t3_thread_read not found". Head executes the same alias
and returns Thread A. Both first and second controlled head runs report AMBER-KITE-742
in their final assistant replies.

The terminal visible inside the app runs inspect-runtime.py against that thread's native
Pi session, showing actual toolCall.name, matching result name, error flag and returned
messages. Names and returned message text are not rewritten. Native JSON evidence
omits model metadata and capability inventories; the native-session inspection script is included.

Additional head checks use loadout-observer.ts:
- --exclude-tools mcp__t3-code__t3_thread_read leaves the alias inactive; the exact
  alias returns not found.
- Deactivate a direct public tool in tool_call immediately before execute, leaving
  its alias active: execute returns not found.
- Toggle the direct public tool off and on, each followed by real model-selection
  events: reconciliation removes then restores its alias; the restored alias executes.
- An alias mutation in approval-required mode waits for approval. Decline blocks it;
  Thread A still contains only its original user message. A supervised read waits for
  approval too (thread reads are annotated non-readonly), then succeeds after approval.

All captures use Chromium, 1280x800 CSS viewport, 2x device scale, light theme.
Images are unchanged except opaque redaction of the model selector. Videos are cropped
to the conversation/terminal column, with opaque strips covering composer metadata, initial terminal setup, and the initial details-panel edge. The stills supply the full readable tool arguments and results. Video cropping and
redaction can clip the right edge of long lines; no tool-name prefix is rewritten.
Published stills were taken in identical pairs at least 500ms apart; the terminal cursor was hidden. The reconciliation image is cropped to the actual app terminal to omit private capability inventories.

Known limits: declaration-only fixture is required to make the exact model request
repeatable; original unmodified model behavior remains unproven. Session-tree replay,
legacy Pi versions, OpenAI-completions eager loading and codemode discoverability were
not separately exercised. The model-selection reconciliation path was exercised.

AI-assisted; verified with the tests and tools listed above.

Reproduction setup: install Pi 1.4.0, configure its existing Anthropic credentials,
and configure the app Pi provider binary path to that executable. Start each app
with T3CODE_DEV_SEED=0 vp run dev. Run seed.sh in each checkout. In the synthetic
workspace, save proof-case.example.json as proof-case.json. Launch Pi with:
--approve --no-extensions -e builtin:tool-search -e <alias-request.ts>
Use browser-driver.js to install the driver in that app, then proof.start with the
attached seed-thread id and the exact prompt visible in the captures. For the
supplemental checks also add -e <loadout-observer.ts>. Exclusion adds
--exclude-tools mcp__t3-code__t3_thread_read. The inactive-public case uses the
orchestrator_capabilities alias, an empty-object schema, and disablePublic:true.
The reconciliation case uses that same alias and reconcile:true. Approval cases
use runtimeMode:'approval-required' and the actual app's Approve/Decline controls.