Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 13 additions & 10 deletions .agents/skills/test-t3-app/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
name: test-t3-app
description: Launch 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, dev server lifecycle, and direct SQLite inspection or fixture seeding. Use when an agent needs to run T3 locally, test UI behavior in a browser, recover from an expired or consumed pairing token, isolate dev state, or prepare test data in state.sqlite.
description: Launch and test the T3 Code web app in isolated development environments, including reusable worktree-scoped dev authentication, real pairing-token recovery, worktree-safe state directories, dev server lifecycle, and direct SQLite inspection or fixture seeding. Use when an agent needs to run T3 locally, test UI behavior in a browser, exercise real pairing behavior, isolate dev state, or prepare test data in state.sqlite.
---

# Test T3 App
Expand All @@ -14,25 +14,25 @@ Use this skill for the web client. For iOS Simulator, Android Emulator, or physi
- 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 --home-dir <base-dir>`.
4. Keep the terminal session alive and read the selected server port, web port, base directory, and pairing URL from its output.
4. Keep the terminal session alive and read the selected server port, web port, base directory, and explicitly labeled `reusable web pairing URL` from the dev-runner output.

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.

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.
The dev runner disables browser auto-open by default. Do not pass `--browser` during automated testing so the controlled browser remains the only client surface.

## Authenticate the browser on the first navigation
## Authenticate the browser

1. Wait for the server log that says authentication is required and includes a URL ending in `/pair#token=...`.
1. Wait for the dev runner's explicitly labeled `reusable web pairing URL`. The server also prints a real one-time pairing URL during startup; do not confuse the two.
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.
3. Open the complete reusable URL 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.
The reusable development credential is deterministically derived from the canonical worktree path and is intentionally limited to loopback servers. It may be opened repeatedly by browsers testing the same running worktree. Do not mistake it for a production secret or configure it on a remotely reachable server.

## Recover a consumed or expired pairing token
## Exercise real pairing or recover a one-time token

Create another token against the same database and web URL as the running dev server:
When the behavior under test is pairing itself, create a real one-time 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 \
Expand All @@ -47,6 +47,8 @@ Use the `Pair URL` from this command once. Derive `<server-port>` and `<web-url>

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. Use `auth pairing list` to inspect active token metadata; it intentionally cannot reveal token secrets.

Real pairing URLs remain secret, short-lived, and single-use. Do not copy them into final responses, screenshots, committed files, or durable logs.

## Inspect or seed SQLite state

Read [references/sqlite-fixtures.md](references/sqlite-fixtures.md) before changing the database.
Expand All @@ -64,7 +66,8 @@ Stop the dev process with its terminal interrupt. Preserve the isolated base dir

## Troubleshoot predictably

- If the browser shows an unauthenticated pairing screen, issue a new token instead of retrying the consumed URL.
- If the reusable dev URL is rejected, confirm the runner and server use the same worktree and that the backend is loopback-only.
- If a real one-time URL was consumed, issue a new token instead of retrying it.
- 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.
Expand Down
49 changes: 31 additions & 18 deletions .agents/skills/test-t3-mobile/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,11 +50,21 @@ Running `project add` before the backend starts gives it exclusive offline datab

Use direct SQLite mutation only for disposable projection fixtures. Follow `test-t3-app` and stop the backend before writing.

Start a headless backend after seeding:
For an iOS Simulator or Android Emulator, start the backend through the worktree-aware dev runner after seeding:

```bash
node apps/server/src/bin.ts serve \
vp run dev:server \
--host 127.0.0.1 \
--home-dir <base-dir>
```

Keep the process alive and retain the selected server port plus the explicitly labeled reusable iOS and Android pairing URLs. They contain the worktree-scoped development credential and can be retried against this loopback server.

For a physical device, use the real-pairing path because the reusable development credential is refused on non-loopback hosts:

```bash
node apps/server/src/bin.ts serve \
--host 0.0.0.0 \
--port <server-port> \
--base-dir <base-dir> \
--no-browser
Expand All @@ -64,7 +74,7 @@ Use these client origins:

- iOS Simulator: `http://127.0.0.1:<server-port>`
- Android Emulator: `http://10.0.2.2:<server-port>`
- Physical device: bind the backend to `0.0.0.0` and use the host's reachable LAN origin
- Physical device: use the host's reachable LAN origin

Always enter the complete `http://` origin; the mobile host field otherwise assumes HTTPS. When testing web and mobile together, run `vp run dev --home-dir <base-dir> --host 127.0.0.1` instead and do not launch a second backend over the same base directory.

Expand Down Expand Up @@ -123,7 +133,21 @@ adb -s <emulator-serial> shell am start -W \

Do not start, stop, erase, or reconfigure an emulator owned by another task. Track and later stop only processes owned by this test.

## Pair each client once
## Connect a simulator or emulator

After the development client is running the correct Metro bundle, open the matching reusable URL printed by `vp run dev:server`:

```bash
xcrun simctl openurl <simulator-udid> '<printed-reusable-ios-pairing-url>'
adb -s <emulator-serial> shell am start -W \
-a android.intent.action.VIEW \
-d '<printed-reusable-android-pairing-url>' \
com.t3tools.t3code.dev
```

Run only the command for the selected platform. The `connections/new` route automatically sends the embedded credential through the normal onboarding exchange; verify that it closes and the expected seeded projects appear. The reusable development URL may be reopened after resetting the client connection.

## Pair a physical device or test real pairing

Issue a fresh credential against the running backend's exact base directory:

Expand All @@ -137,21 +161,9 @@ T3CODE_PORT=<server-port> node apps/server/src/bin.ts auth pairing create \

In PowerShell, set `$env:T3CODE_PORT = "<server-port>"` first and run the `node ... auth pairing create` command without the leading assignment.

If the visible Add Environment action is not exposed as a semantic target, open the app's registered route instead of guessing coordinates:

```bash
xcrun simctl openurl <simulator-udid> 't3code-dev://connections/new'
adb -s <emulator-serial> shell am start -W \
-a android.intent.action.VIEW \
-d 't3code-dev://connections/new' \
com.t3tools.t3code.dev
```

Run only the command for the selected platform.

In T3 Code Dev, open Add Environment and enter the complete `<mobile-origin>` and newly printed `Token`. Verify the expected seeded projects appear before exercising the affected flow.

Pairing credentials are secret, short-lived, and single-use. Create a different credential for every simulator, emulator, physical device, or browser. If an attempt fails, issue a new credential rather than retrying the old one. Do not expose tokens in screenshots, commits, or final responses.
Real pairing credentials are secret, short-lived, and single-use. Create a different credential for every physical device or real-pairing test client. If an attempt fails, issue a new credential rather than retrying the old one. Do not expose tokens in screenshots, commits, or final responses.

## Drive and observe the affected flow

Expand Down Expand Up @@ -182,7 +194,8 @@ Keep local verification focused. Do not turn this workflow into a full repositor

- **Old UI or an old error appears:** verify Metro's worktree, variant, URL, and port before diagnosing the app.
- **The environment remains empty:** verify the platform-specific HTTP origin, use a fresh token, and confirm project seeding used the identical base directory.
- **A second client cannot pair:** pairing tokens are single-use; issue another token.
- **A simulator or emulator cannot reconnect:** reopen the platform-specific reusable URL and confirm the backend is still loopback-only.
- **A physical or real-pairing client cannot pair:** pairing tokens are single-use; issue another token.
- **iOS semantic actions fail:** set explicit XcodeBuildMCP defaults and refresh with `snapshot_ui`.
- **Android cannot reach Metro:** verify `adb reverse` for the exact Metro port and relaunch the development-client URL.
- **Android cannot reach the backend:** use `10.0.2.2`, not `127.0.0.1`, for the Android Emulator.
Loading
Loading