# Delegated account recovery proof

Run from a current main checkout with dependencies installed. Place the scenario in `scripts/scenarios/` and keep the two driver files together outside the checkout.

```sh
node configure-recovery.mjs "$CHECKOUT" "$DRIVER_DIR/recovery-agent.mjs"
cd "$CHECKOUT"
T3CODE_DEV_SEED=0 vp run scenarios:prove scripts/scenarios/delegated-account-recovery.e2e.ts \
  --base ed52af3a478652c55aeaaf5a64bbf6584dd6a0b4 \
  --head f2b003f91c50bc1cd19fcfb19bba751856e59ae1 \
  --upload-command "ghdrop upload"
```

The harness adds two deterministic local ACP instances, Account A and Account B. They invoke the real HTTP MCP endpoint using the credentials T3 issues to the parent and child. No application implementation is patched. All state is synthetic and created through project/thread commands. The Auto change uses the same client RPC command as the composer because the local ACP instance does not expose the Full-access picker.

The parent delegates a Full-access child on A, waits for completion, is lowered to Auto, then configures that same child on B and sends a continuation. The child reads its own persisted conversation through `t3_thread_read` to recall the code word. A real text attachment is uploaded and sent to that child. An unrelated Full-access target and a new Full-access child are negative controls. The parent report contains returned server outcomes. A final report-only turn prevents completion notifications from leaving the capture mid-turn.

This demonstrates the runtime permission gate, durable history availability, attachment send, and preserved child modes. It does not simulate OAuth authentication, account usage exhaustion, a real provider's native-session recovery, or organization/link and plan-mode restrictions. The browser is Chromium, light theme, 1440×1000 on both sides.

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