@testdriverai/mcp 7.11.136-test → 7.11.138-test

package/docs/{v7/agent.mdx → agent.mdx}

@@ -1,27 +1,27 @@
 ---
 title: "The TestDriver Agent"
-sidebarTitle: "Agent"
+sidebarTitle: "Introduction"
 description: "How the TestDriver agent behaves on GitHub issues, pull requests, and @mentions"
-icon: "robot"
+icon: "hand-horns"
 ---
 
-The TestDriver agent is an AI teammate that lives in your GitHub repository. It's
-**code review that runs your app** — instead of only reading a diff and guessing
-what might break, it starts a real sandbox, drives the real app, and reports what
-actually happens.
+The TestDriver agent is an AI teammate in your GitHub repository. It is
+**code review that runs your app**. It does not only read a diff and guess
+what can break. It starts a real sandbox, controls the real app, and reports what
+really happens.
 
 ## Scope: it only builds and maintains tests
 
-The agent is focused. The one thing it does is **write, debug, fix, and maintain
-automated tests** with TestDriver, and review pull requests by writing and running
-a test against the change. It will politely decline off-scope work — it won't edit
-your application code, fix product bugs, answer unrelated programming questions, or
+The agent has one purpose. It does one thing: it **writes, debugs, fixes, and keeps
+automated tests** with TestDriver. It reviews pull requests. It writes and runs
+a test against the change. It does not do work that is not in scope. It does not edit
+your application code, fix product bugs, answer other programming questions, or
 act as a general coding assistant.
 
 ## How it behaves depends on the surface
 
-The agent reacts to three different GitHub surfaces, and its behavior is
-noticeably different on each.
+The agent reacts to three different GitHub surfaces. Its behavior is
+different on each one.
 
 | Surface | Trigger | What it does |
 |---------|---------|--------------|
@@ -31,13 +31,13 @@ noticeably different on each.
 
 ## Pull requests — automatic code review
 
-When a pull request is **opened**, the agent reviews it automatically — nobody has
+When a pull request is **opened**, the agent reviews it automatically. Nobody has
 to ask.
 
-- **The review is the deliverable, not chatter.** An automatic review is
-  unsolicited, so the agent stays quiet while it works and posts a **single review
-  comment** at the end rather than scattering inline threads across the diff or
-  narrating each step.
+- **The review is the deliverable, not chatter.** No person asks for an automatic review.
+  Thus the agent stays quiet while it works. It posts a **single review
+  comment** at the end. It does not put many inline threads across the diff. It does not
+  tell each step.
 - **It runs the change when it can.** Its default first move is to start a session,
   work out what the PR changes from a user's point of view, and write and run a
   TestDriver test that exercises exactly that. A bug it *watched happen* is far

package/docs/{v7/assert.mdx → assert.mdx}

@@ -7,7 +7,7 @@ icon: "check-circle"
 
 ## Overview
 
-Make AI-powered assertions about the current screen state using natural language. The AI analyzes the screen and verifies that your assertion is true.
+Make assertions about the screen state with natural language and AI. The AI examines the screen. It makes sure that your assertion is true.
 
 ## Syntax
 
@@ -54,7 +54,7 @@ await testdriver.assert(assertion, options)
 
 ## Returns
 
-`Promise<boolean>` - `true` if assertion passes, throws error if assertion fails
+`Promise<boolean>` - `true` if the assertion passes. It throws an error if the assertion fails.
 
 ## Examples
 
@@ -101,7 +101,7 @@ await testdriver.assert('the modal dialog is open');
 <Check>
   **Assert state changes**
   
-  Verify state before and after actions:
+  Make sure of the state before and after actions:
   
   ```javascript
   // Before
@@ -311,5 +311,5 @@ describe('Assertions', () => {
 
 ## Related Methods
 
-- [`extract()`](/v7/extract) - Extract information for detailed assertions
-- [`find()`](/v7/find) - Locate elements to verify
+- [`extract()`](/extract) - Extract information for detailed assertions
+- [`find()`](/find) - Locate elements to verify

package/docs/{v7/aws-setup.mdx → aws-setup.mdx}

@@ -5,7 +5,7 @@ description: "Deploy TestDriver on your AWS infrastructure using CloudFormation"
 icon: "aws"
 ---
 
-This guide walks you through setting up self-hosted TestDriver instances on AWS. By the end, you'll have fully automated test infrastructure that spawns and terminates instances on-demand.
+This guide helps you to set up self-hosted TestDriver instances on AWS. At the end, you have automated test infrastructure. It starts and stops instances when you need them.
 
 ```mermaid
 graph LR
@@ -17,13 +17,13 @@ graph LR
 
 ## How It Works
 
-TestDriver automatically manages AWS EC2 instances for your tests:
+TestDriver manages the AWS EC2 instances for your tests automatically:
 
-1. **Deploy CloudFormation** — One-time infrastructure setup
-2. **Configure Vitest** — Add one line to your config
-3. **Run Tests** — Instances spawn automatically, run tests, and terminate
+1. **Deploy CloudFormation**. Set up the infrastructure one time.
+2. **Configure Vitest**. Add one line to your config.
+3. **Run Tests**. The instances start automatically, run the tests, and stop.
 
-That's it! No manual instance management needed.
+That is all. You do not need to manage the instances by hand.
 
 # Quickstart
 

package/docs/{v7/cache.mdx → cache.mdx}

@@ -1,6 +1,6 @@
 ---
 title: "Cache"
-sidebarTitle: "Cache"
+sidebarTitle: "Configuring the Cache"
 description: "Speed up tests with screenshot-based caching"
 icon: "bolt-lightning"
 mode: "wide"
@@ -8,18 +8,18 @@ mode: "wide"
 
 ## Overview
 
-The cache system speeds up repeated test runs by comparing screenshots to cached results. When the screen hasn't changed significantly, cached element positions are reused instead of making an AI call.
+The cache system makes repeated test runs faster. It compares screenshots to cached results. When the screen did not change much, TestDriver uses the cached element positions again. It does not make an AI call.
 
-Cache works at two levels:
-- **Screen cache** — pixel diff comparison between the current screenshot and the cached screenshot
-- **Element cache** — OpenCV template matching to verify the cached element position is still correct
+The cache works at two levels:
+- **Screen cache**: a pixel diff comparison between the present screenshot and the cached screenshot
+- **Element cache**: OpenCV template matching to make sure that the cached element position is still correct
 
 ## How It Works
 
-1. On `find()`, the SDK sends the current screenshot and cache metadata to the API
-2. The API compares the screenshot against previously cached results for the same `cacheKey`
-3. If the screen pixel diff is within the `screen` threshold AND the element template match exceeds the `element` threshold, the cached position is returned
-4. Otherwise, a new AI call is made and the result is cached
+1. On `find()`, the SDK sends the present screenshot and the cache metadata to the API.
+2. The API compares the screenshot against the cached results for the same `cacheKey`.
+3. If the screen pixel diff is in the `screen` threshold AND the element template match is more than the `element` threshold, TestDriver returns the cached position.
+4. If not, TestDriver makes a new AI call and caches the result.
 
 ```mermaid
 flowchart LR

package/docs/{v7/caching.mdx → caching.mdx}

@@ -1,13 +1,14 @@
 ---
-title: "Learn"
-sidebarTitle: "Learn"
+title: "Self-Learning"
+sidebarTitle: "Self-Learning"
 description: "How TestDriver learns your app and caches what it discovers for instant, deterministic replays"
 icon: "brain"
 ---
 
-Once the agent has [explored your app](/v7/generating-tests), TestDriver remembers what it found. Every element the AI vision agent discovers is cached with a vision fingerprint—a perceptual hash of the screen state where it was located. On the next run, TestDriver matches against that cache instead of calling the AI again. Passing tests replay instantly, deterministically, and cheaply.
+After the agent [explored your app](/generating-tests), TestDriver keeps what it found. TestDriver caches each element that the AI vision agent finds. It uses a vision fingerprint. This is a perceptual hash of the screen state at the element location. On the next run, TestDriver matches against that cache. It does not call the AI again. Tests that pass replay quickly, in the same way each time, and at a low cost.
+
+This learning makes TestDriver fast. The cache makes the test run a maximum of **1.7x faster**. It does not do the same AI vision analysis again. The agent thinks only when it sees something new.
 
-This learning is what makes TestDriver fast. Intelligent caching delivers up to **1.7x faster** test execution by skipping redundant AI vision analysis—the agent only thinks when it sees something new.
 
 ```javascript
 // First run: builds cache
@@ -19,14 +20,14 @@ await testdriver.find('submit button');
 
 ## Automatic Caching
 
-Learning is enabled automatically with zero configuration. The cache key—the fingerprint TestDriver uses to recognize what it already knows—is computed from:
+TestDriver enables learning automatically. You do not need configuration. TestDriver computes the cache key from these. The cache key is the fingerprint that TestDriver uses to know what it learned:
 
-- **File hash**: SHA-256 hash of the test file contents
-- **Selector prompt**: The exact text description passed to `find()`
-- **Screenshot context**: Perceptual hash of the current screen state
-- **Platform**: Operating system and browser version
+- **File hash**: The SHA-256 hash of the test file contents
+- **Selector prompt**: The exact text description that you give to `find()`
+- **Screenshot context**: The perceptual hash of the present screen state
+- **Platform**: The operating system and the browser version
 
-When you modify your test file, the hash changes automatically, invalidating stale cache entries and ensuring fresh AI analysis with your updated test logic.
+When you change your test file, the hash changes automatically. This makes the old cache entries not valid. Then TestDriver does a new AI analysis with your new test logic.
 
 ```javascript
 import { test } from 'vitest';
@@ -47,7 +48,7 @@ test('auto-cached test', async (context) => {
 
 ## Managing the Cache
 
-You can clear the cache within the TestDriver console. There, you'll also find previews of cached elements, the input prompts, as well as analytics on cache hit rates.
+You can clear the cache in the TestDriver console. There, you also find previews of cached elements, the input prompts, and analytics on the cache hit rates.
 
 <Card href="https://console.testdriver.ai/cache" title="TestDriver Cache" icon="database">
   Manage and clear your test cache from the TestDriver console.
@@ -127,6 +128,6 @@ await testdriver.find(`order ${orderId} status`, {
 
 ## Next
 
-<Card href="/v7/copilot/running-tests" title="Run" icon="play">
+<Card href="/copilot/running-tests" title="Run" icon="play">
   Now that TestDriver has learned your app, run your tests in CI and locally—replaying the cache for fast, deterministic results.
 </Card>

package/docs/{v7/captcha.mdx → captcha.mdx}

@@ -7,7 +7,7 @@ icon: "shield-check"
 
 # Captcha Solving
 
-TestDriver can automatically solve captchas during your tests using the 2captcha service. This feature works on both **Linux** and **Windows** sandboxes.
+TestDriver can solve captchas automatically during your tests. It uses the 2captcha service. This feature works on **Linux** sandboxes and **Windows** sandboxes.
 
 ## Quick Start
 
@@ -21,12 +21,12 @@ console.log(result.success); // true
 console.log(result.token);   // The solved captcha token
 ```
 
-That's it! TestDriver will automatically:
-- Detect the captcha type on the page
-- Extract the sitekey
-- Solve the captcha via 2captcha
-- Inject the token into the page
-- Trigger any callbacks
+That is all. TestDriver does these automatically:
+- Finds the captcha type on the page
+- Gets the sitekey
+- Solves the captcha with 2captcha
+- Puts the token into the page
+- Starts the callbacks
 
 ## Supported Captcha Types
 

package/docs/changelog.mdx

@@ -65,12 +65,12 @@ Releases test.11 through test.22 include version bumps and internal CI improveme
 - **VS Code environment switching** — The TestDriver VS Code extension now includes a status bar indicator and a new **TestDriver: Switch Environment** command. You can switch between stable, canary, and test environments directly from VS Code, and your MCP server configuration updates automatically.
 - **Plan rename: Starter → Pro** — The "Starter" plan has been renamed to **Pro**. No changes to pricing or features — just a clearer name. The "Self-Hosted" tier is now labeled **Enterprise**.
 - **SDK network resilience** — API requests now automatically retry on transient server errors (500, 502, 503, 504) with exponential backoff, reducing flaky test failures caused by brief infrastructure hiccups.
-- **Pricing page refresh** — The [hosted plans page](/v7/hosted) now shows plan cards with included minutes, concurrency limits, and pricing at a glance.
+- **Pricing page refresh** — The [hosted plans page](/hosted) now shows plan cards with included minutes, concurrency limits, and pricing at a glance.
 
 📚 Docs updates
 
-- **Quickstart redesign** — The [quickstart](/v7/quickstart) now has tabbed setup paths for CLI, GitHub Copilot, and manual installation.
-- **Deployment section** — "Cloud" is now [Hosted](/v7/hosted) and the previous Enterprise page has been consolidated into [Self-Hosted](/v7/self-hosted), which covers both standard and air-gapped deployments.
+- **Quickstart redesign** — The [quickstart](/quickstart) now has tabbed setup paths for CLI, GitHub Copilot, and manual installation.
+- **Deployment section** — "Cloud" is now [Hosted](/hosted) and the previous Enterprise page has been consolidated into [Self-Hosted](/self-hosted), which covers both standard and air-gapped deployments.
 
 </Update>
 
@@ -93,7 +93,7 @@ This release includes all changes from v7.8.0-test.6 with version bumps across a
 
 ✨ New features
 
-- **[GitHub Copilot integration](/v7/copilot/running-tests)** — Use TestDriver directly from GitHub Copilot in VS Code. The new MCP server lets Copilot launch sandboxes, interact with elements, and run assertions through natural language. Includes guides for [creating tests](/v7/generating-tests), [running tests](/v7/copilot/running-tests), [GitHub Actions integration](/v7/copilot/auto-healing#use-testdriver-in-github), and [auto-healing](/v7/copilot/auto-healing).
+- **[GitHub Copilot integration](/copilot/running-tests)** — Use TestDriver directly from GitHub Copilot in VS Code. The new MCP server lets Copilot launch sandboxes, interact with elements, and run assertions through natural language. Includes guides for [creating tests](/generating-tests), [running tests](/copilot/running-tests), [GitHub Actions integration](/copilot/auto-healing#use-testdriver-in-github), and [auto-healing](/copilot/auto-healing).
 
 🔧 Improvements
 
@@ -109,18 +109,18 @@ This release includes all changes from v7.8.0-canary.4 with version bumps.
 
 ✨ New features
 
-- **[Cache API](/v7/cache)** — Speed up repeated test runs with screenshot-based caching. The system compares screenshots to cached results and reuses element positions when the screen hasn't changed, reducing AI calls.
-- **[Custom error classes](/v7/errors)** — New `ElementNotFoundError` class with rich debugging info including screenshot paths, pixel diffs, and detailed messages.
-- **[Events system](/v7/events)** — Listen to SDK lifecycle events with wildcard support via `testdriver.emitter`. Uses colon-delimited namespaces (e.g., `command:start`, `log:*`).
-- **[Provision API](/v7/provision)** — Launch browsers, desktop apps, VS Code, and Chrome extensions in your sandbox before tests run. Access via `testdriver.provision.*`.
-- **[Redraw detection](/v7/redraw)** — Wait for screens to stabilize after interactions using two-phase detection with pixel comparison and z-score analysis.
-- **[Screenshots API](/v7/screenshots)** — Capture screenshots manually with `testdriver.screenshot()` or automatically before/after every command.
+- **[Cache API](/cache)** — Speed up repeated test runs with screenshot-based caching. The system compares screenshots to cached results and reuses element positions when the screen hasn't changed, reducing AI calls.
+- **[Custom error classes](/errors)** — New `ElementNotFoundError` class with rich debugging info including screenshot paths, pixel diffs, and detailed messages.
+- **[Events system](/events)** — Listen to SDK lifecycle events with wildcard support via `testdriver.emitter`. Uses colon-delimited namespaces (e.g., `command:start`, `log:*`).
+- **[Provision API](/provision)** — Launch browsers, desktop apps, VS Code, and Chrome extensions in your sandbox before tests run. Access via `testdriver.provision.*`.
+- **[Redraw detection](/redraw)** — Wait for screens to stabilize after interactions using two-phase detection with pixel comparison and z-score analysis.
+- **[Screenshots API](/screenshots)** — Capture screenshots manually with `testdriver.screenshot()` or automatically before/after every command.
 
 📚 New examples
 
-- [Exec output](/v7/examples/exec-output) — Capture and use output from PowerShell commands
-- [Exec PowerShell](/v7/examples/exec-pwsh) — Generate dynamic data with PowerShell
-- [Focus window](/v7/examples/focus-window) — Switch focus between application windows
+- [Exec output](/examples/exec-output) — Capture and use output from PowerShell commands
+- [Exec PowerShell](/examples/exec-pwsh) — Generate dynamic data with PowerShell
+- [Focus window](/examples/focus-window) — Switch focus between application windows
 
 🔧 Improvements
 

package/docs/{v7/ci-cd.mdx → ci-cd.mdx}

@@ -5,21 +5,21 @@ description: "Run TestDriver tests in CI/CD with parallel execution and cross-pl
 icon: "code-branch"
 ---
 
-TestDriver integrates seamlessly with popular CI providers, enabling automated end-to-end testing on every push and pull request.
+TestDriver integrates with the common CI providers. It lets you do automated end-to-end tests on each push and pull request.
 
 ## Authentication
 
-On **GitHub Actions, prefer OIDC** via the published `testdriverai/action` —
-there's no `TD_API_KEY` secret to store, copy, or rotate. The action proves the
-workflow is running inside your org and TestDriver exchanges that proof for your
+On **GitHub Actions, use OIDC** through the published `testdriverai/action`. Then
+there is no `TD_API_KEY` secret to store, copy, or change. The action shows that the
+workflow runs in your org. TestDriver changes that proof for your
 team's key at run time. See the GitHub Actions tab below.
 
-For other CI providers (or self-hosted runners without OIDC), fall back to a
-stored API key from [console.testdriver.ai/settings](https://console.testdriver.ai/settings),
-added as a `TD_API_KEY` secret in your CI provider's settings.
+For other CI providers (or self-hosted runners without OIDC), use a
+stored API key from [console.testdriver.ai/settings](https://console.testdriver.ai/settings).
+Add it as a `TD_API_KEY` secret in the settings of your CI provider.
 
 <Note>
-  Never commit your API key directly in code. Always use OIDC or your CI provider's secrets management.
+  Never commit your API key in the code. Always use OIDC or the secrets management of your CI provider.
 </Note>
 
 ## CI Provider Examples
@@ -28,10 +28,10 @@ added as a `TD_API_KEY` secret in your CI provider's settings.
   <Tab title="GitHub Actions">
     ### Authenticate with OIDC via `testdriverai/action` (recommended)
 
-    Use the published [`testdriverai/action`](https://github.com/testdriverai/action) — it mints the OIDC token, exchanges it for your team's API key, and exports `TD_API_KEY` for the steps that follow. **No `TD_API_KEY` secret to store or rotate.**
+    Use the published [`testdriverai/action`](https://github.com/testdriverai/action). It makes the OIDC token, changes it for your team's API key, and exports `TD_API_KEY` for the steps that come after. **There is no `TD_API_KEY` secret to store or change.**
 
     <Note>
-      One-time setup: authorize the [TestDriver GitHub App](https://console.testdriver.ai) for your org so the org → team binding exists. If your org authorized the App before OIDC support shipped, re-authorize once. If the App isn't authorized, the action fails with a console link (or falls back to the `api-key` secret if you provide one).
+      Do this one time: authorize the [TestDriver GitHub App](https://console.testdriver.ai) for your org. Then the org → team binding exists. If your org authorized the App before OIDC support was available, authorize it again one time. If the App is not authorized, the action fails with a console link. (Or it uses the `api-key` secret if you give one.)
     </Note>
 
     ```yaml .github/workflows/testdriver.yml

package/docs/{v7/click.mdx → click.mdx}

@@ -7,7 +7,7 @@ icon: "mouse-pointer"
 
 ## Element Click
 
-When called on an Element object, clicks on the located element.
+When you call this on an Element object, it clicks on the found element.
 
 ### Syntax
 
@@ -90,7 +90,7 @@ await testdriver.click(500, 300, 'right-click');
 
 ### Regular Click
 
-Single left-click action.
+One left-click action.
 
 ```javascript
 const button = await testdriver.find('Login button');
@@ -99,7 +99,7 @@ await button.click();
 
 ### Double Click
 
-Double-click action, commonly used to open files or select text.
+A double-click action. It usually opens files or selects text.
 
 ```javascript
 const file = await testdriver.find('document.pdf');
@@ -123,7 +123,7 @@ await folder.rightClick();
 
 ### Mouse Down / Mouse Up
 
-For drag operations or custom click behavior.
+Use these for drag operations or custom click behavior.
 
 ```javascript
 const draggable = await testdriver.find('draggable item');
@@ -142,9 +142,9 @@ await dropZone.mouseUp();
 ## Best Practices
 
 <Check>
-  **Prefer element clicks over coordinate clicks**
+  **Prefer element clicks to coordinate clicks**
   
-  Element-based clicking is more reliable and resolution-independent:
+  A click on an element is more reliable. It does not depend on the resolution:
   
   ```javascript
   // ✅ Preferred
@@ -157,7 +157,7 @@ await dropZone.mouseUp();
 </Check>
 
 <Check>
-  **Verify element was found**
+  **Make sure that TestDriver found the element**
   
   ```javascript
   const element = await testdriver.find('button');
@@ -169,9 +169,9 @@ await dropZone.mouseUp();
 </Check>
 
 <Warning>
-  **Element must be found before clicking**
+  **TestDriver must find the element before you click it**
   
-  The `find()` method automatically locates elements, but clicking an element that wasn't found will throw an error:
+  The `find()` method finds elements automatically. But a click on an element that TestDriver did not find throws an error:
   
   ```javascript
   const element = await testdriver.find('button');
@@ -281,7 +281,7 @@ describe('Click Interactions', () => {
 
 ## Related Methods
 
-- [`find()`](/v7/find) - Locate elements to click
-- [`hover()`](/v7/hover) - Hover without clicking
-- [`doubleClick()`](/v7/double-click) - Dedicated double-click method
-- [`rightClick()`](/v7/right-click) - Dedicated right-click method
+- [`find()`](/find) - Find elements to click
+- [`hover()`](/hover) - Put the cursor on the element without a click
+- [`doubleClick()`](/double-click) - The double-click method
+- [`rightClick()`](/right-click) - The right-click method