docs(factories): final copy pass for launch

src/content/docs/factories/factory-agents.mdx

@@ -80,7 +80,7 @@ Default model IDs change over time, so choose based on what each agent has to do
 | Triage | Research, evidence gathering, and working with connected tools |
 | Spec | Synthesizing requirements, technical reasoning, and precise writing |
 | Implement | Coding strength, with a harness that fits your repositories and toolchain |
-| Review | A different model or harness from implement, so the two don't share blind spots |
+| Review | A different model or harness from the implement agent, so the two don't share blind spots |
 
 See [model choice for agents](/agents/inference/model-choice/) and [harnesses for cloud agents](/platform/harnesses/) for available options. Define reusable procedures with [skills](/agents/capabilities/skills/), and scope each agent's external access through [MCP servers](/platform/mcp/) and [cloud agent secrets](/platform/secrets/).
 

src/content/docs/factories/factory-as-code.mdx

@@ -47,7 +47,7 @@ skills/
     SKILL.md
 ```
 
-Only `factory.yaml` and at least one agent are required. For a complete working definition, see the [example](#example-factory-definition) below.
+Only `factory.yaml` and at least one agent are required. For a complete working definition, see the [example factory definition](#example-factory-definition) below.
 
 ## `factory.yaml`
 

src/content/docs/factories/how-factories-work.mdx

@@ -55,7 +55,7 @@ A factory is built to pause where the call belongs to a person. By default, that
 * **Answering questions** - When requirements are unclear or a review finding is ambiguous, the foreman asks instead of guessing.
 * **Merging** - The factory opens the pull request and hands it off. Whether and when it merges is your team's call.
 
-The first two are workflow policy, written into the foreman's instructions — edit them to change when the factory checks in. Merging is enforced by your repository, so if you require human-only merges, use branch protection and repository permissions.
+The first two are workflow policy, written into the foreman's instructions; edit them to change when the factory checks in. Merging is enforced by your repository, so if you require human-only merges, use branch protection and repository permissions.
 
 ## How the factory improves itself
 

src/content/docs/factories/index.mdx

@@ -8,7 +8,7 @@ sidebar:
 ---
 import { VARS } from '@data/vars';
 
-Warp Factories lets engineering teams define and operate **software factories**: cloud workflows where specialized agents move engineering work from intake to a reviewed pull request. The factory does the repetitive work; your team stays in the loop at the points that matter, approving specs and merging every pull request.
+Warp Factories lets engineering teams define and operate **software factories**: cloud workflows where specialized agents move engineering work from intake to a reviewed pull request. The factory does the repetitive work; your team stays in the loop at the points that matter, approving specs when needed and merging every pull request.
 
 :::note
 Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team.

src/content/docs/factories/integrations/github.mdx

@@ -77,7 +77,7 @@ Use filters to route work precisely. For example, send failed runs of a specific
 
 Handing an issue or pull request to a factory takes two things:
 
-1. **Add the factory's label.** Each factory has one, named `factory:` followed by its [**Foreman name**](/factories/factory-dashboard/#change-factory-settings) — a factory whose foreman is named `payments` uses `factory:payments`. Warp creates the label in every connected repository, so it's already in the list.
+1. **Add the factory's label.** Each factory has one, named `factory:` followed by its [**Foreman name**](/factories/factory-dashboard/#change-factory-settings). For example, a factory whose foreman is named `payments` uses `factory:payments`. Warp creates the label in every connected repository, so it's already in the list.
 2. **Mention or assign @warp-factory**, in the body or in any new comment.
 
 The factory picks up the request and replies in the same thread.

src/content/docs/factories/integrations/gitlab.mdx

@@ -29,7 +29,7 @@ When you create a factory, choose **I want to use repos from GitLab** as the cod
 
 That's the setup. A GitLab factory starts with one default automation, **gitlab-bot-mentions**, so mentioning the bot in a merge request comment starts work right away. To confirm it, do exactly that: comment on a merge request in one of the selected projects, mention the bot, and watch for a work item in the factory's [dashboard](/factories/factory-dashboard/).
 
-To start work from merge request events as well, add a **Merge request** trigger to an automation — see [automation filters](/factories/automation-filters/#edit-filters-on-an-automation).
+To start work from merge request events as well, add a **Merge request** trigger to an automation; [automation filters](/factories/automation-filters/#edit-filters-on-an-automation) covers the steps.
 
 ## Supported triggers
 
@@ -74,7 +74,7 @@ The factory acts on GitLab as its bot account:
 
 * **Replies in the thread it was mentioned in** - Its comments link back to the run session and the factory work item. New comments on the same merge request continue that work item instead of starting a new one.
 * **Pushes branches and opens draft merge requests** - Branches are named `factory/<slug>`, and merge requests open as drafts that the factory marks ready when the work is done. Commits and comments attribute to the bot's GitLab profile.
-* **Labels what it touches** - Merge requests and issues the factory opens or adopts carry its own label, named `factory:` followed by the factory's Foreman name.
+* **Labels what it touches** - Merge requests and issues the factory opens or adopts carry its own label, named `factory:` followed by the factory's [**Foreman name**](/factories/factory-dashboard/#change-factory-settings).
 * **Posts review feedback as comments** - A review lands as a summary note plus inline discussions on the diff. When a later revision addresses a finding, the factory replies in that discussion and resolves it.
 
 The factory never merges or approves a merge request, and your project's protection and approval rules apply to everything the bot does.
@@ -107,7 +107,7 @@ triggers:
 Triage newly opened merge requests and post an initial review.
 ```
 
-A `bot_mentioned` trigger takes only a `repos` filter — leave `mentioned` out, since the bot username isn't yours to set.
+A `bot_mentioned` trigger takes only a `repos` filter. Leave `mentioned` out, since the bot username isn't yours to set.
 
 A GitLab-backed factory can still be managed as code, but the definition itself lives either in Warp or in a GitHub repository — GitLab is not yet available as a definition host. See [where the definition lives](/factories/factory-as-code/#where-the-definition-lives).
 

src/content/docs/factories/integrations/jira.mdx

@@ -58,7 +58,7 @@ All Jira work reaches the factory through a single event, `agent_session_created
 A session must match every field you set; within a field, any listed value is a match. Omit a field to match everything. For the matching rules shared by every source, see [automation filters](/factories/automation-filters/).
 
 :::caution
-A Jira event is offered to every automation in the connected workspace, so another team's automation with a broader filter can start its own run on the same work item. Filters decide what *your* automation picks up, not who else can see the event — see [automation filters](/factories/automation-filters/#filters-route-work-they-dont-restrict-access).
+A Jira event is offered to every automation in the connected workspace, so another team's automation with a broader filter can start its own run on the same work item. Filters decide what *your* automation picks up, not who else can see the event. See [automation filters](/factories/automation-filters/#filters-route-work-they-dont-restrict-access).
 :::
 
 ## What happens during a run

src/content/docs/factories/measure-and-improve.mdx

@@ -38,7 +38,7 @@ The **Dashboard** page shows activity, cost, autonomy, and evaluation results:
 **PRs merged**, **Autonomy**, **PR cycle time**, and the detail in **Most expensive PRs** require the GitHub App and only cover activity from after you install it.
 :::
 
-Use the dashboard to pick which runs to investigate, not to conclude what caused a change. **Total runs** includes evaluation, benchmark, and Self-improvement runs, so a higher run count with a flat PR count could mean harder tasks, retries, or measurement activity.
+Use the **Dashboard** page to pick which runs to investigate, not to conclude what caused a change. **Total runs** includes evaluation, benchmark, and Self-improvement runs, so a higher run count with a flat PR count could mean harder tasks, retries, or measurement activity.
 
 ## Configure Scorers
 

src/content/docs/factories/quickstart.mdx

@@ -89,7 +89,7 @@ Send the request from the tool your team already works in. Mention the factory i
    * **Runs** - The foreman's run and the child runs it dispatches.
    * **Activity** - The work item as it moves through its stages. Open it for the event history and pull request artifacts.
 
-3. When the Code agent finishes, the work item links a pull request. Review and merge it the way you would any other: a factory hands off at the pull request and never merges for you.
+3. When the Code agent finishes, the work item links to the pull request. Review and merge it the way you would any other: a factory hands off at the pull request and never merges for you.
 
 ## Next steps
 

src/content/docs/factories/troubleshooting.mdx

@@ -84,7 +84,7 @@ Then check the causes specific to where the work came from:
 
 **Cause:** The factory can't push, or the work never reached implementation.
 
-**Fix:** Confirm the **Code** agent is enabled on the factory, that the code host connection still grants write access to the target repository, and that the work item actually reached the implementation stage. Branch protection rules apply to everything the factory pushes.
+**Fix:** Confirm that the **Code** agent is enabled on the factory, that the code host connection still grants write access to the target repository, and that the work item actually reached the implementation stage. Branch protection rules apply to everything the factory pushes.
 
 ## Related pages
 

src/content/docs/reference/cli/index.mdx

@@ -9,15 +9,11 @@ import { Tabs, TabItem } from '@astrojs/starlight/components';
 import { VARS } from '@data/vars';
 
 :::caution
-The {VARS.WARP_AGENT_CLI} (the `oz` binary) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement.
+The {VARS.WARP_AGENT_CLI} (the `oz` binary, which previously shipped as `warp-cli`) is being deprecated in favor of the {VARS.WARP_CLI} (the `warp` binary). See the [Warp Agent CLI docs](/agents/cli/) for the replacement.
 :::
 
 The {VARS.WARP_AGENT_CLI} is the command-line tool for running and managing Warp's cloud agents from any terminal, script, or CI pipeline. Use it to start agents locally or in the cloud, connect MCP servers, configure integrations, and authenticate without requiring the Warp desktop app.
 
-:::note
-**`warp-cli` is deprecated and has been replaced by `oz`.** If you have `warp-cli` installed, it will auto-update to `oz`. All the same commands are available, just replace `warp-cli` with `oz` in your scripts and workflows.
-:::
-
 ## What is the CLI?
 
 The {VARS.WARP_AGENT_CLI} is the command-line tool that lets you run [Cloud Agents](/platform/) from anywhere, including terminals, scripts, automated systems, or services.