# Documentation

## Docs v2 - DRAFT (Git Sync)

- [Drizz Docs](https://docs.drizz.dev/readme.md): Drizz automates mobile apps with Vision AI. Write tests in plain English and run them on Android and iOS.
- [Introduction](https://docs.drizz.dev/start-here/introduction.md): How Drizz works — Vision AI, plain-English commands, and the five stages every test step runs through.
- [Quickstart: Your first test](https://docs.drizz.dev/start-here/quickstart.md): Write and run your first Drizz test in about 10 minutes, on a device connected to the desktop app.
- [Platform & Device support](https://docs.drizz.dev/start-here/platform-support.md): Which platforms and device types Drizz supports, and where each one runs — locally, in the Drizz cloud, or on private devices.
- [Use cases](https://docs.drizz.dev/start-here/use-cases.md): The scenarios teams automate with Drizz — onboarding, authentication, search, checkout, navigation and full regression suites.
- [Download & install](https://docs.drizz.dev/desktop-app/download-and-install.md): Download the Drizz desktop app, check your Mac meets the requirements, and install it.
- [Sign in & get access](https://docs.drizz.dev/desktop-app/sign-in-and-access.md): Sign in to the desktop app with your work email, how your organization is created, and what to do when you see nothing.
- [Updates](https://docs.drizz.dev/desktop-app/updates.md): How the desktop app updates itself, what a forced update does, and how to install one by hand if the download fails.
- [Set up a device: Guided wizard](https://docs.drizz.dev/desktop-app/device-setup-wizard.md): The guided wizard installs and configures everything needed to run an Android emulator or an iOS simulator on your Mac.
- [Android setup](https://docs.drizz.dev/desktop-app/android-setup.md): Set up an Android emulator and the command-line tools by hand, when the guided wizard isn't the right path.
- [Android real device](https://docs.drizz.dev/desktop-app/android-real-device.md): Connect a real Android phone or tablet over USB — developer options, USB debugging, and the adb check that answers most problems.
- [iOS simulator setup](https://docs.drizz.dev/desktop-app/ios-simulator-setup.md): Install Xcode, open it once, launch a simulator, and connect it to Drizz. What happens on the first connect.
- [iOS physical device](https://docs.drizz.dev/desktop-app/ios-physical-device.md): Connect a real iPhone or iPad — developer mode, the Apple team picker, signing, and the free-account limits.
- [Networks, proxies & preflight](https://docs.drizz.dev/desktop-app/networks-and-preflight.md): Run the network preflight check, read its results, and work with corporate proxies and TLS inspection.
- [Tour of the interface](https://docs.drizz.dev/desktop-app/interface-tour.md): A map of the desktop app window — what each panel does and what each control means.
- [Projects, tests & modules](https://docs.drizz.dev/desktop-app/projects-tests-and-modules.md): How the file explorer organizes work — tests, modules, folders, the green M badge, and the Online/Local toggle.
- [Report an issue](https://docs.drizz.dev/desktop-app/report-an-issue.md): Report Issue bundles your logs, screenshots and device state and sends them to Drizz support in one click.
- [Drizz AI](https://docs.drizz.dev/writing-tests/chat.md): Describe a flow in plain language and Drizz explores the app and writes the script for you. Android only, best under 25 steps.
- [The shape of a test](https://docs.drizz.dev/writing-tests/writing-tests.md): The structure of a Drizz test: one instruction per line, five beats, and the command palette that lists everything Drizz understands.
- [Command index](https://docs.drizz.dev/writing-tests/command-index.md): Every command Drizz understands, in one table — syntax, what it does, and where the detail lives.
- [Actions](https://docs.drizz.dev/writing-tests/tap.md): Tap an element by describing it in plain English, and the six ways to describe it so only one element matches.
- [Type](https://docs.drizz.dev/writing-tests/tap/type.md): Enter text into a field. Drizz focuses the field, clears what's there, and dismisses the keyboard afterwards.
- [Validate](https://docs.drizz.dev/writing-tests/tap/validate.md): Assert that something is true on screen — presence, state, numbers, or a value you captured earlier.
- [Scroll](https://docs.drizz.dev/writing-tests/tap/scroll.md): Scroll by a fixed amount, or scroll until a target comes into view. Quote the target, give a direction, validate afterwards.
- [MAP\_ACTION](https://docs.drizz.dev/writing-tests/tap/map-action.md): Coordinate-based taps, drags and pinches for map surfaces, canvases and sliders — the least deterministic command in Drizz.
- [System commands](https://docs.drizz.dev/writing-tests/system-commands.md): The nine commands that control the app lifecycle and the device — OPEN\_APP, KILL\_APP, CLEAR\_APP and the rest, in one table.
- [Waits & timing](https://docs.drizz.dev/writing-tests/waits-and-timing.md): Drizz supports fixed-duration waits: where to put them, how to spell them, and why element-conditioned wording is not a substitute.
- [Conditionals](https://docs.drizz.dev/writing-tests/conditionals.md): IF / ELSE IF / ELSE blocks let one script survive apps that show different screens to different users.
- [Variables & data](https://docs.drizz.dev/writing-tests/which-variable.md): The four mechanisms that hold a value in Drizz — Store, SET, dataset variables and placeholders — compared in one table.
- [Variables](https://docs.drizz.dev/writing-tests/which-variable/store-and-set.md): Capture a value from the screen with Store, or assign one with SET. The four right-hand sides SET accepts, and what it rejects.
- [Datasets](https://docs.drizz.dev/writing-tests/which-variable/datasets.md): Datasets supply {{variable}} values from outside your script, bound when a test plan runs. Same script, different data.
- [Lockable pools](https://docs.drizz.dev/writing-tests/which-variable/lockable-pools.md): Lease test data that two runs can't share — logins, phone numbers, accounts. One row per run, released at the end.
- [Modules](https://docs.drizz.dev/writing-tests/modules.md): Write a flow once and call it from every test. Module definition, CALL, parameters, and the limits that apply to them.
- [API](https://docs.drizz.dev/writing-tests/api-steps.md): Call a registered API mid-test to seed data, fetch an expected value, or check the UI against the backend.
- [Memory & Blockers](https://docs.drizz.dev/writing-tests/memory-and-blockers.md): Memory is org-level context attached to your app. Blocker rules dismiss popups automatically, with no step in any script.
- [Authoring rules](https://docs.drizz.dev/writing-tests/authoring-rules.md): The rule list for writing Drizz tests — what to do and what to avoid, with the reason each rule exists.
- [Recipes](https://docs.drizz.dev/writing-tests/recipes.md): Six complete, runnable Drizz tests — login, checkout, multi-app, mobile web, location and data-driven runs.
- [Running locally](https://docs.drizz.dev/running-tests/running-locally.md): Run a test on the device connected to your Mac, watch each step execute, and stop the run.
- [Test plans](https://docs.drizz.dev/running-tests/test-plans.md): A test plan is a set of tests plus how to run them — devices, app build, dataset, concurrency and a quality gate.
- [Creating & Running a plan](https://docs.drizz.dev/running-tests/creating-and-running-a-plan.md): Create a test plan, add tests, pick devices and data, set concurrency and a quality gate, run it, and read the run screen.
- [Devices](https://docs.drizz.dev/running-tests/devices.md): The three places a Drizz test runs — your Mac, the Drizz device cloud, or your org's private devices — and what happens when none is free.
- [Self-healing](https://docs.drizz.dev/running-tests/self-healing.md): When a step fails, Drizz repairs it mid-run instead of failing the whole test. Healed steps are badged in the report.
- [Caching](https://docs.drizz.dev/running-tests/caching.md): Drizz reuses how it resolved a step on a screen it has seen before. Cached steps run faster and cost less.
- [Game mode](https://docs.drizz.dev/running-tests/game-mode.md): Games don't expose a normal view hierarchy, so Drizz can run vision-only. Game mode is enabled per app by Drizz.
- [Reading a Report](https://docs.drizz.dev/reports-and-debugging/reading-a-report.md): Every run produces a report — per-step screenshots, timestamped logs, a video recording and DT usage.
- [Statuses](https://docs.drizz.dev/reports-and-debugging/statuses.md): What Passed, Passed (healed), Failed, Error and Blocked each mean, and why infrastructure failures now report as Error.
- [When a step fails](https://docs.drizz.dev/reports-and-debugging/when-a-step-fails.md): Triage procedure for a failed step, and the before-screenshot table that maps symptom to cause to fix.
- [Recordings](https://docs.drizz.dev/reports-and-debugging/recordings.md): Every run is recorded end to end. Download the video, screenshots and logs from the Actions section of a test attempt.
- [Troubleshooting](https://docs.drizz.dev/reports-and-debugging/troubleshooting.md): Symptom to fix, in three tables: devices that won't connect, sign-in and network problems, and runs that misbehave.
- [Organizations & Access](https://docs.drizz.dev/your-account/organizations-and-access.md): How a Drizz organization is created, what is shared inside one, and what to do when files are missing after sign-in.
- [Billing & Tokens](https://docs.drizz.dev/your-account/billing-and-tokens.md): How Drizz meters test runs in DT, what drives the cost of a step, what each wallet state means, and how to top up.
- [Managing Apps](https://docs.drizz.dev/your-account/managing-apps.md): Register app builds with Drizz so test plans and Memory can use them — the 500 MB cap, iOS build types, and what cannot be downloaded back.
- [API Overview](https://docs.drizz.dev/automate-and-integrate/api-overview.md): The Drizz REST API in one page — the auth model, the 24-hour token, rate limits, and the three calls that get a build running.
- [Authenticate](https://docs.drizz.dev/automate-and-integrate/authenticate.md): Exchange client credentials for a Drizz access token and send it on every API call. Tokens are valid for 24 hours.
- [Upload a build](https://docs.drizz.dev/automate-and-integrate/upload-a-build.md): Upload an app binary to Drizz over the API so test plans can run against it. Multipart form, one file, 500 MB cap.
- [Trigger a run](https://docs.drizz.dev/automate-and-integrate/trigger-a-run.md): Start one test plan or a batch over the API. Returns an execution\_id and nothing else — there is no status endpoint.
- [Errors & limits](https://docs.drizz.dev/automate-and-integrate/errors-and-limits.md): Every status code the Drizz API returns, what each common failure means, and the rate limits to design around.
- [CI/CD](https://docs.drizz.dev/automate-and-integrate/ci-cd.md): Trigger Drizz test plans from GitHub Actions, Jenkins, GitLab CI and others — and what a pipeline cannot do yet.
- [Jira](https://docs.drizz.dev/automate-and-integrate/jira.md): Create Jira issues from failed Drizz tests, and the shared-token attribution caveat that applies to every generated ticket.
- [Glossary](https://docs.drizz.dev/reference/glossary.md): Every Drizz term in one place — DT, Memory, modules, datasets, lockable pools, MAP\_ACTION, Vision AI and the rest.
- [Known Limitations](https://docs.drizz.dev/reference/known-limitations.md): What Drizz doesn't do — platform gaps, language limits, Chat's scope, the accessibility boundary, and what's missing from the API.
- [Changelog](https://docs.drizz.dev/reference/changelog.md): User-visible changes to Drizz, newest first — new features, changed behavior, and anything affecting tests already written.