Enforce your style guide: voice and terminology fixes in Flash docs

flash/apps/build-app.mdx

@@ -119,7 +119,7 @@ Besides starting the API server, `flash dev` also starts an interactive API expl
 To run endpoint functions in the explorer:
 
 1. Expand one of the functions under **GPU Workers** or **CPU Workers**.
-2. Click **Try it out** and then **Execute**.
+2. Select **Try it out**, then **Execute**.
 
 You'll get a response from your workers right in the explorer.
 

flash/cli/build.mdx

@@ -80,7 +80,7 @@ If you use other environment file variants like `.env.dev` or `.env.staging`, ad
 
 Local (non-pip) modules that your endpoints import are bundled automatically, provided they pass the ignore filter: your `.gitignore` plus the built-in patterns listed above. During the build, Flash resolves the transitive local-import closure of every shipped Python file and checks it against the files the ignore filter already selected.
 
-If shipped code imports a local module that an ignore rule excludes (for example, a `test_*.py` sibling or a file under `tests/`), the build fails with a `LocalModuleResolutionError` instead of silently overriding your ignore rules or shipping a broken artifact. Flash names each excluded file and the file that imports it:
+If shipped code imports a local module that an ignore rule excludes (for example, a `test_*.py` sibling or a file under `tests/`), the build fails with a `LocalModuleResolutionError`. Failing early is deliberate: Flash won't silently override your ignore rules or ship a broken artifact. The error names each excluded file and the file that imports it:
 
 ```
 Shipped code imports local modules that the build ignore rules (.gitignore or built-in defaults) exclude:
@@ -89,7 +89,7 @@ Shipped code imports local modules that the build ignore rules (.gitignore or bu
 Shipping them would silently override a deliberate exclusion, and omitting them would break the worker with ModuleNotFoundError. Remove the matching ignore pattern or stop importing these modules from shipped code.
 ```
 
-If an `@Endpoint` file has a local import Flash can't resolve at all (a broken relative import, or a file outside your project root), the build also fails with a clear error. A file that fails resolution but doesn't define an endpoint is skipped with a warning and the build continues. For details on how local imports are resolved and bundled, see [Import local modules](/flash/create-endpoints#import-local-modules).
+If an `@Endpoint` file has a local import Flash can't resolve at all (for example, a broken relative import or a file outside your project root), the build fails with a clear error. If a file that doesn't define an endpoint fails resolution, Flash skips it with a warning and continues the build. For details on how local imports are resolved and bundled, see [Import local modules](/flash/create-endpoints#import-local-modules).
 
 ## Build artifacts
 
@@ -208,6 +208,6 @@ ls .flash/.build/
 
 <Note>
 
-Most users should use `flash deploy` instead, which runs build and deploy in one step. Use `flash build` when you need more control or want to inspect the artifact.
+In most cases, use `flash deploy` instead, which runs build and deploy in one step. Use `flash build` when you need more control or want to inspect the artifact.
 
 </Note>

flash/create-endpoints.mdx

@@ -244,13 +244,13 @@ async def process_video(video_data):
 
 ## Import local modules
 
-Your endpoint can import local (non-pip) Python modules that live alongside it in your project, such as a sibling `utils.py` file or a `helpers/` package. Flash detects these imports, follows them transitively, and ships the module source to the worker for you, so an import like `import utils` or `from helpers import load` works remotely with no extra configuration.
+Your endpoint can import local (non-pip) Python modules that live alongside it in your project, such as a sibling `utils.py` file or a `helpers/` package. Flash detects these imports, follows them transitively, and ships the module source to the worker for you. Imports like `import utils` or `from helpers import load` work remotely with no extra configuration.
 
 Flash resolves local imports whether they appear at the top of the file or inside the function body, and it supports absolute imports (`import utils`), relative imports (`from . import helpers`), and dynamic imports with a literal name (`importlib.import_module("plugin")`). It also pulls in the `__init__.py` files for any packages you import. Flash can't resolve dynamic imports whose module name is computed at runtime, so it emits a warning, and you're responsible for making those modules available on the worker.
 
-Flash bundles only local project files. Standard library modules are already present in the worker image, and pip packages must still be declared through the `dependencies` parameter. This applies transitively: if a bundled local module imports a pip package at its top level, that package must still be declared in the `dependencies` of any endpoint that uses the module.
+Flash bundles only local project files. Standard library modules are already present in the worker image, and pip packages must still be declared through the `dependencies` parameter. This applies transitively. If a bundled local module imports a pip package at its top level, declare that package in the `dependencies` of any endpoint that uses the module.
 
-On `flash build` and `flash deploy`, local modules are bundled when they pass the ignore filter, and importing a local module that an ignore rule excludes (or one Flash can't resolve) fails the build. See [Local modules and the ignore filter](/flash/cli/build#local-modules-and-the-ignore-filter) for details.
+On `flash build` and `flash deploy`, Flash bundles local modules that pass the ignore filter. Importing a local module that an ignore rule excludes (or one Flash can't resolve) fails the build. See [Local modules and the ignore filter](/flash/cli/build#local-modules-and-the-ignore-filter) for details.
 
 ### Live execution size limit
 

flash/overview.mdx

@@ -50,7 +50,7 @@ Flash requires a Runpod account with a verified email address.
 ### Install Flash
 
 <Note>
-Flash requires [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) and runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+Flash requires [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) and runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 </Note>
 
 Install Flash using `pip` or `uv`:
@@ -104,7 +104,7 @@ flash --help
 
 ## Limitations
 
-- Flash runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+- Flash runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 - CPU endpoints are restricted to the `EU-RO-1` datacenter. GPU endpoints can deploy to [multiple datacenters](/flash/configuration/parameters#datacenter).
 - Flash can rapidly scale workers across multiple endpoints, and you may hit your maximum worker threshold quickly. Contact [Runpod support](https://www.runpod.io/contact) to increase your account's capacity if needed.
 

flash/quickstart.mdx

@@ -16,7 +16,7 @@ This quickstart gets you running GPU workloads on Runpod in minutes. You'll exec
 ## Step 1: Install Flash
 
 <Note>
-Flash runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+Flash runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 </Note>
 
 Create a virtual environment and install Flash using [uv](https://docs.astral.sh/uv/):

flash/troubleshooting.mdx

@@ -35,7 +35,7 @@ Available levels: `DEBUG`, `INFO`, `WARNING`, `ERROR`.
 View detailed metrics and logs in the [Runpod console](https://console.runpod.io/serverless):
 
 1. Navigate to the **Serverless** section.
-2. Click on your endpoint to view:
+2. Select your endpoint to view:
    - Active workers and queue depth.
    - Request history and job status.
    - Worker logs and execution details.
@@ -48,7 +48,7 @@ Access detailed logs for specific workers:
 
 1. Go to the [Serverless console](https://console.runpod.io/serverless).
 2. Select your endpoint.
-3. Click on a worker to view its logs.
+3. Select a worker to view its logs.
 
 Logs include dependency installation output, function execution output (print statements, errors), and system-level messages.