chore: host context window after screenshots

.agents/skills/test-t3-app/SKILL.md

@@ -1,91 +1,41 @@
 ---
 name: test-t3-app
-description: Launch, retain, and test the T3 Code web app in isolated development environments, including first-try browser authentication with one-time pairing URLs, pairing-token recovery, worktree-safe state directories, cross-turn dev server lifecycle, and direct SQLite inspection or fixture seeding. Use when an agent needs to run T3 locally, iteratively test UI behavior with a human, recover from an expired or consumed pairing token, isolate dev state, or prepare test data in state.sqlite.
+description: Test T3 Code's web and desktop UI through its built-in Browser panel against isolated development state. Use for browser verification, browser pairing recovery, and test fixtures. Use test-t3-mobile for native mobile verification.
 ---
 
-# Test T3 App
+# Test T3 web and desktop
 
-Use this skill for the web client. For iOS Simulator, Android Emulator, or physical-device testing against an isolated T3 backend, use the sibling [`test-t3-mobile`](../test-t3-mobile/SKILL.md) skill.
+Use T3's built-in Browser panel for verification. If its tools are absent or
+the panel reports unavailable, explain the blocker and stop verification.
+Do not install or switch to another automation system. For native mobile
+testing, use [test-t3-mobile](../test-t3-mobile/SKILL.md).
 
-## Start an isolated web environment
+## Start the app
 
-1. Run commands from the repository root.
-2. Choose a base directory that belongs only to the current worktree or test:
-   - Use the repository's ignored `.t3` directory for reusable worktree-local state.
-   - Use `mktemp -d /tmp/t3code-test.XXXXXX` for disposable state and retain the printed absolute path.
-3. Start the full web stack with `vp run dev`. In a linked worktree it defaults to that worktree's gitignored `.t3`; pass `--home-dir <base-dir>` only when the test needs a different isolated directory.
-4. Keep the terminal session alive and read the selected server port, web port, base directory, and pairing URL from its output.
+Reuse this task's healthy dev server. Otherwise run `vp run dev` from the
+repository root and retain its terminal session. Use the worktree's ignored
+`.t3` state and read the actual ports and pairing URL from the dev-runner output.
+Never run against `~/.t3/userdata` or set `VITE_HTTP_URL` or `VITE_WS_URL`.
 
-Treat a base directory as disposable only when it was created or deliberately selected for the current test. Never delete or directly seed the shared `~/.t3` directory. Prefer starting with a new temporary base directory over clearing state of uncertain ownership.
+Test with meaningful project and thread data. Read
+[references/sqlite-fixtures.md](references/sqlite-fixtures.md) only when
+inspecting or seeding SQLite. Stop the test server before direct fixture writes.
 
-The worktree-local default deliberately outranks an ambient `T3CODE_HOME`; do not pass the shared home through to a worktree dev server.
+## Use the Browser panel
 
-The dev runner disables browser auto-open by default. Do not pass `--browser` during automated testing: an automatically opened page can consume the one-time bootstrap token before the controlled browser uses it.
+Call `preview_status`, then `preview_open` if the Browser panel is
+closed. Navigate to the complete startup pairing URL once with
+`preview_navigate`, then use `preview_snapshot` and T3's interaction tools.
+If the token was consumed or expired, run `node apps/server/src/bin.ts pair`
+for a fresh one. Keep using the same tab.
 
-## Preserve the environment while iterating
+## Verify and retain
 
-Treat the overall testing or implementation loop—not an assistant turn or one verification pass—as the environment lifecycle boundary.
+Exercise the affected flow and capture the state that proves it works. Keep
+the server, state, and panel available while the user inspects or iterates.
+An assistant turn ending is not teardown. Stop only processes you started,
+using retained terminal sessions or captured PIDs.
 
-- Keep the dev process, base directory, selected ports, authenticated browser tab, registered projects, and seeded fixtures alive while the user may inspect the result or request follow-up changes.
-- Do not stop the server merely because one verification pass completed or because you are yielding a response to the user.
-- Before starting another environment, check whether the existing process and browser tab still serve the task. Reuse them when healthy instead of discarding useful state.
-- On a later turn, verify that the existing process is alive and reuse its printed ports and base directory. If it exited, restart with the same base directory; create a new pairing token only when the browser session is no longer valid.
-- Tell the user when a test environment remains available, including its non-secret web URL when useful. Never include a pairing token.
-
-## Authenticate the browser on the first navigation
-
-1. Wait for the server log that says authentication is required and includes a URL ending in `/pair#token=...`.
-2. Use the controlled in-app browser or browser-automation surface available to the agent. Do not use a system-browser launch command during automated testing.
-3. Open that complete URL exactly once as the controlled browser's first navigation. Preserve the fragment and token verbatim.
-4. Wait for the pairing exchange and redirect to finish before navigating elsewhere.
-5. Continue in the same browser context so its stored bearer session remains available.
-
-Treat pairing URLs as secrets. Do not copy them into final responses, screenshots, committed files, or durable logs. A pairing token is short-lived and single-use; opening the URL in another browser or opening it twice can consume it.
-
-## Recover a consumed or expired pairing token
-
-Create another token against the same database and web URL as the running dev server:
-
-```bash
-T3CODE_PORT=<server-port> node apps/server/src/bin.ts auth pairing create \
-  --base-dir <base-dir> \
-  --dev-url <web-url> \
-  --base-url <web-url> \
-  --ttl 15m \
-  --label agent-ui-test
-```
-
-Use the `Pair URL` from this command once. Derive `<server-port>` and `<web-url>` from the current dev-runner output, including any automatically selected port offset. Setting `T3CODE_PORT` keeps the administrative CLI from probing for an unrelated free port.
-
-Always pass `--dev-url` for a dev-runner environment so the generated pairing URL uses the current web origin. An explicit base directory stores runtime state in `<base-dir>/userdata`; the `<base-dir>/dev` fallback is only used by an implicit dev home. A worktree-local `.t3` counts as explicit, so its state lives in `<worktree>/.t3/userdata`. Use `auth pairing list` to inspect active token metadata; it intentionally cannot reveal token secrets.
-
-## Inspect or seed SQLite state
-
-Read [references/sqlite-fixtures.md](references/sqlite-fixtures.md) before changing the database.
-
-- Use `node apps/server/scripts/t3-sqlite-state.ts query` for schema discovery and read-only checks.
-- Stop the dev server before using `node apps/server/scripts/t3-sqlite-state.ts exec`, then restart it with the same base directory.
-- Seed projection tables only for disposable UI fixtures. Use application commands and APIs when testing business behavior or projection correctness.
-- Use the auth CLI, not direct `auth_*` table edits, for pairing and sessions.
-
-The helper refuses to write to the shared `~/.t3` directory by default and creates a database backup before each mutation.
-
-## Tear down only when the testing loop is finished
-
-Tear down when the user explicitly asks, confirms the iteration is finished, or the overall task is genuinely complete with no pending human review. Do not infer completion from the end of an assistant turn.
-
-When teardown is appropriate:
-
-1. Stop the dev process with its terminal interrupt.
-2. Preserve the isolated base directory when it contains useful reproduction evidence or state for a likely follow-up.
-3. Otherwise remove only a path created for this test after resolving and verifying the exact target.
-
-If completion is uncertain, keep the environment alive and mention that it is retained for further iteration. A fresh isolated base directory remains the safest reset when authentication, migrations, or fixture state becomes ambiguous.
-
-## Troubleshoot predictably
-
-- If the browser shows an unauthenticated pairing screen, issue a new token instead of retrying the consumed URL.
-- If the pairing URL is no longer visible, create a replacement token with both `--dev-url` and `--base-url`.
-- If the replacement token is rejected, verify that the CLI and server use the identical absolute base directory and web URL.
-- If the UI shows unexpected data, verify that every command uses the identical explicit base directory before editing anything.
-- If ports move because another instance is running, trust the current dev-runner output rather than assuming ports `13773` and `5733`.
+When sharing is requested, start with `vp run dev --share` and give the user
+a fresh complete pairing URL that you have not consumed. Keep other credentials
+out of screenshots, commits, and replies.

.agents/skills/test-t3-app/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "T3 App Testing"
-  short_description: "Launch and retain isolated T3 test environments"
-  default_prompt: "Use $test-t3-app to launch an isolated T3 environment and iteratively test it in the browser while preserving state."
+  short_description: "Test web and desktop in T3's Browser panel"
+  default_prompt: "Use $test-t3-app to verify the affected web or desktop flow through T3's Browser panel."