Nomenclature cleanup throughout rover docs (#1571)

Mostly replacing Studio w/ GraphOS, with other wording cleanup along the
way

docs/source/commands/config.mdx

@@ -3,7 +3,7 @@ title: Rover config commands
 description: Create and manage configuration profiles
 ---
 
-The Rover CLI enables you to create multiple **configuration profiles**, each of which corresponds to a different identity in Apollo Studio. Each configuration profile has an associated [API key](/graphos/api-keys), which determines its permissions. You manage your configuration profiles with the `rover config` set of commands.
+Rover enables you to create multiple **configuration profiles**, each of which corresponds to a different GraphOS identity. Each configuration profile has an associated [API key](/graphos/api-keys), which determines its permissions. You manage your configuration profiles with the `rover config` set of commands.
 
 ## Displaying configuration profiles
 

docs/source/commands/contracts.mdx

@@ -1,17 +1,32 @@
 ---
 title: Rover contract commands
-description: For use with Apollo Contract variants
+description: For use with GraphOS contract variants
 ---
 
-A **contract** is a variant that is the result of filtering out schema elements from a source variant.
+GraphOS [contracts](/graphos/delivery/contracts/) enable you to create variants of a supergraph that filter out schema elements according to inclusion and exclusion rules:
+
+```mermaid
+graph LR;
+  subgraph "Source variant";
+  api("Supergraph<br/>schema<br/>▉");
+  end
+  subgraph "Contract variant B"
+  contractB("Contract schema B<br/>▟")
+  end
+  subgraph "Contract variant A"
+  contractA("Contract schema A<br/>▛");
+  end
+  api -."Filter schema<br/>according to contract A".->contractA
+  api -."Filter schema<br/>according to contract B".->contractB
+```
 
-Rover commands that interact with [contracts](https://www.apollographql.com/docs/graphos/delivery/contracts/) begin with `rover contract`.
+The `rover contract` command set enables you to interact with your existing contracts and create new ones.
 
-## Publishing a contract to Apollo Studio
+## Publishing a contract to GraphOS
 
 ### `contract publish`
 
-> This command requires [authenticating Rover with Apollo Studio](../configuring/#authenticating-with-apollo-studio).
+> This command requires [authenticating Rover with GraphOS](../configuring/#authenticating-with-graphos).
 
 You can use Rover to publish a new contract or publish configuration changes to an existing contract.
 
@@ -26,9 +41,9 @@ rover contract publish my-graph@my-contract-variant \
   --hide-unreachable-types
 ```
 
-The argument `my-graph@my-contract-variant` in the example above is a [graph ref](../conventions/#graph-refs) that specifies the ID of the Studio graph you're publishing to, along with which [variant](/graphos/graphs/overview/#variants) you're publishing to.
+The argument `my-graph@my-contract-variant` in the example above is a [graph ref](../conventions/#graph-refs) that specifies the ID of the graph you're publishing to, along with which contract variant you're creating or modifying.
 
-If this variant already exists in the graph registry, its configuration is updated; otherwise, a new contract variant is created.
+If this contract variant already exists in the graph registry, its configuration is updated. Otherwise, a new contract variant is created.
 
 Options include:
 
@@ -48,13 +63,13 @@ Options include:
 </td>
 <td>
 
-The name of the [source variant](https://www.apollographql.com/docs/graphos/delivery/contracts/#2-fed1-enable-variant-support-for-tag) whose supergraph schema is used for filtering.
+The name of the [source variant](/graphos/delivery/contracts/#2-fed1-enable-variant-support-for-tag) to use for supergraph schema filtering.
 
-The source variant must be on the same graph as the contract variant and cannot be changed after contract creation. It must also be a federated variant with subgraphs. If your graph is using Federation 1, support for the `@tag` directive must be explicitly enabled in Studio.
+The source variant must belong to the same graph as the contract variant. It must also be a federated variant with subgraphs. If your graph uses Federation 1, you must enable its support for the `@tag` directive in Apollo Studio.
 
 **Required** the first time you publish a contract.
 
-**Optional** after your first publish, but if provided it must match the previously published source variant in Studio.
+**Optional** after your first publish. If provided, it must match the value provided for the first publish (the source variant for a particular contract variant can't change).
 
 </td>
 </tr>
@@ -66,14 +81,22 @@ The source variant must be on the same graph as the contract variant and cannot
 </td>
 <td>
 
-**Required unless `--no-include-tags` is used.** A tag name to [include](https://www.apollographql.com/docs/graphos/delivery/contracts/#contract-filters) when filtering. To include multiple tag names, specify `--include-tag` multiple times (e.g. `--include-tag foo --include-tag bar`). To include no tag names/use an empty list, specify `--no-include-tags` instead.
+A tag name to [include](/graphos/delivery/contracts/#contract-filters) when filtering. To include multiple tag names, specify `--include-tag` multiple times:
+
+```bash
+--include-tag foo --include-tag bar
+```
+
+To specify an _empty_ include list, provide`--no-include-tags` instead of this option.
 
 Every tag name **must**:
 
 * Begin with a letter (capital or lowercase) or underscore.
 * Include only letters, numbers, underscores (`_`), hyphens (`-`), or slashes (`/`).
 * Have a maximum of 128 characters.
 
+One of `--include-tag` or `--no-include-tags` is **required**.
+
 </td>
 </tr>
 <tr class="required">
@@ -84,7 +107,9 @@ Every tag name **must**:
 </td>
 <td>
 
-**Required unless `--include-tag` is used.** [Include](https://www.apollographql.com/docs/graphos/delivery/contracts/#contract-filters) no tag names when filtering. To include a non-empty list of tag names, specify `--include-tag` instead.
+Specifies an empty [include list](/graphos/delivery/contracts/#contract-filters) for the published contract.
+
+One of `--include-tag` or `--no-include-tags` is **required**.
 
 </td>
 </tr>
@@ -96,14 +121,22 @@ Every tag name **must**:
 </td>
 <td>
 
-**Required unless `--no-exclude-tags` is used.** A tag name to [exclude](https://www.apollographql.com/docs/graphos/delivery/contracts/#contract-filters) when filtering. To exclude multiple tag names, specify `--exclude-tag` multiple times (e.g. `--exclude-tag foo --exclude-tag bar`). To exclude no tag names/use an empty list, specify `--no-exclude-tags` instead.
+A tag name to [exclude](/graphos/delivery/contracts/#contract-filters) when filtering. To exclude multiple tag names, specify `--exclude-tag` multiple times:
+
+```
+--exclude-tag foo --exclude-tag bar
+```
+
+To specify an _empty_ exclude list, provide`--no-exclude-tags` instead of this option.
 
 Every tag name **must**:
 
 * Begin with a letter (capital or lowercase) or underscore.
 * Include only letters, numbers, underscores (`_`), hyphens (`-`), or slashes (`/`).
 * Have a maximum of 128 characters.
 
+One of `--exclude-tag` or `--no-exclude-tags` is **required**.
+
 </td>
 </tr>
 <tr class="required">
@@ -114,7 +147,9 @@ Every tag name **must**:
 </td>
 <td>
 
-**Required unless `--exclude-tag` is used.** [Exclude](https://www.apollographql.com/docs/graphos/delivery/contracts/#contract-filters) no tag names when filtering. To exclude a non-empty list of tag names, specify `--exclude-tag` instead.
+Specifies an empty [exclude list](/graphos/delivery/contracts/#contract-filters) for the published contract.
+
+One of `--exclude-tag` or `--no-exclude-tags` is **required**.
 
 </td>
 </tr>
@@ -126,7 +161,9 @@ Every tag name **must**:
 </td>
 <td>
 
-**Required unless `--no-hide-unreachable-types` is used.** Automatically [hide](https://www.apollographql.com/docs/graphos/delivery/contracts/#contract-filters) types that can never be reached in operations on the contract schema
+If provided, the contract automatically [hides](/graphos/delivery/contracts/#contract-filters) types that are unreachable from the contract schema's root fields.
+
+One of `--hide-unreachable-types` or `--no-hide-unreachable-types` is **required**.
 
 </td>
 </tr>
@@ -138,7 +175,9 @@ Every tag name **must**:
 </td>
 <td>
 
-**Required unless `--hide-unreachable-types` is used.** Do not automatically [hide](https://www.apollographql.com/docs/graphos/delivery/contracts/#contract-filters) types that can never be reached in operations on the contract schema
+If provided, the contract does _not_ automatically hide types that are unreachable from the contract schema's root fields.
+
+One of `--hide-unreachable-types` or `--no-hide-unreachable-types` is **required**.
 
 </td>
 </tr>
@@ -150,30 +189,30 @@ Every tag name **must**:
 </td>
 <td>
 
-**Optional.** Do not trigger a [launch](https://www.apollographql.com/docs/graphos/delivery/contracts/#review-and-launch) in Studio after updating the contract configuration
+**Optional.** If provided, this command does not trigger a [launch](/graphos/delivery/contracts/#review-and-launch) in GraphOS after updating the contract configuration.
 
 </td>
 </tr>
 </tbody>
 </table>
 
-## Describing a contract variant
+## Fetching contract details
 
 ### `contract describe`
 
-> This command requires [authenticating Rover with Apollo Studio](../configuring/#authenticating-with-apollo-studio).
+> This command requires [authenticating Rover with GraphOS](../configuring/#authenticating-with-graphos).
 
-You can use Rover to describe the configuration of any contract variant that Rover has access to.
+You can use Rover to fetch the configuration of any contract variant that Rover has access to.
 
 Run the `contract describe` command, like so:
 
 ```bash
 rover contract describe my-graph@my-contract-variant
 ```
 
-The argument `my-graph@my-contract-variant` in the example above is a [graph ref](../conventions/#graph-refs) that specifies the ID of the Studio graph you're fetching from, along with which [variant](/graphos/graphs/overview/#variants) you're fetching.
+The argument `my-graph@my-contract-variant` in the example above is a [graph ref](../conventions/#graph-refs) that specifies the ID of the GraphOS graph you're fetching from, along with which contract variant you're fetching.
 
-The output will contain information of how the contract variant was configured such as the source variant, include and exclude tags.
+This command prints a summary of the contract's configuration, including its source variant and include/exclude lists:
 
 ```
 Fetching description for configuration of my-graph@my-contract-variant using credentials from the default profile.

docs/source/commands/dev.mdx

@@ -3,7 +3,7 @@ title: The Rover dev command
 description: Query a locally federated GraphQL API
 ---
 
-> ⚠️ **Note:** The `rover dev` command is _only_ for local development. Do **not** run this command in production.
+> ⚠️ **Do not run `rover dev` in production!** This command is for local development _only_.
 
 A **subgraph** is a graph that contributes to the composition of a federated **supergraph**:
 
@@ -16,27 +16,29 @@ graph BT;
   gateway --- serviceA & serviceB & serviceC;
 ```
 
-You can use Rover to start a local router that can query across one or more running GraphQL APIs (i.e., subgraphs)
-through one endpoint (i.e., supergraph). As you add, edit, and remove subgraphs, Rover automatically
-composes their separate schemas into a unified supergraph schema that the router reloads and serves. 
+You can use Rover to start a local router that can query across one or more running GraphQL APIs (i.e., subgraphs) through one endpoint. As you add, edit, and remove subgraphs, Rover automatically composes their separate schemas into a unified supergraph schema that the router reloads and serves.
 
 Think plug-n-play USB devices but with your GraphQL APIs!
 
 ## Creating a federated session
 
 ### Starting the session
 
-Before using Rover's `dev` command, you first need to have access to a running GraphQL API (subgraph). You'll need the URL the GraphQL API is serving and the location of the schema in the filesystem. If you don't have a local schema file, your subgraph must enable introspection.
+Before using `rover dev`, you need at least one running GraphQL API (subgraph). You'll need the URL the GraphQL API is serving, along with the location of its schema in your filesystem.
 
-An example `rover dev` command for running a local subgraph might look something like this:
+> If you don't have a local schema file, your subgraph must enable introspection.
 
-`rover dev --name products --schema ./products.graphql --url http://localhost:4000`
+Here's an example `rover dev` command that provides a locally running subgraph:
 
-The above command starts the `rover dev` session, watching `./products.graphql` for changes to the schema, and starts up a local Apollo Router at the default endpoint (i.e., `http://localhost:3000`). This session also listens for other `rover dev` processes that include different subgraph schemas.
+```bash
+rover dev --name products --schema ./products.graphql --url http://localhost:4000
+```
+
+This starts the `rover dev` session, which watches `./products.graphql` for changes to the schema. It also starts up a local Apollo Router instance at its default endpoint (`http://localhost:3000`). Finally, the session listens for _other_ `rover dev` processes that include different subgraph schemas.
 
 ### Stopping the session
 
-If you stop the first `rover dev` session (by pressing `CTRL+C`), it will shut down the router, and any attached `rover dev` processes are detached and shut down.
+If you stop the first `rover dev` session (by pressing `CTRL+C`), it shuts down the local router instance. It _also_ detaches and shuts down any secondary `rover dev` processes.
 
 ### Attaching additional subgraphs to a session
 
@@ -54,11 +56,11 @@ If you pass the `--schema <PATH>` argument, `rover dev` watches that schema file
 
 #### Via introspection
 
-If you don't pass the `--schema <PATH>` argument, `rover dev` will introspect the URL specified by the `--url <SUBGRAPH_URL>` argument once every second. The command prefers to use the same query as `rover subgraph introspect` but falls back to `rover graph introspect` if your GraphQL API doesn't support introspecting federated SDL. If this is the case, directives are stripped from the subgraph schema.
+If you don't pass the `--schema <PATH>` argument, `rover dev` introspects the URL specified by the `--url <SUBGRAPH_URL>` argument once every second. The command prefers to use the same query as `rover subgraph introspect` but it falls back to `rover graph introspect` if your GraphQL API doesn't support introspecting federated SDL. If this is the case, directives are stripped from the subgraph schema.
 
 ### Stopping an attached process
 
-If you stop an attached `rover dev` process (by pressing `CTRL+C`), the supergraph will de-compose the removed subgraph and reload the router.
+If you stop an attached `rover dev` process (by pressing `CTRL+C`), the supergraph will recompose its schema _without_ the removed subgraph and reload the router.
 
 ### Health check
 

docs/source/commands/graphs.mdx

@@ -3,7 +3,7 @@ title: Rover graph commands
 description: Publish and retrieve your API schema
 ---
 
-These Rover commands are _primarily_ for interacting with monolithic graphs that do _not_ use [federation](/federation/). However, you can also use them to fetch a federated graph's API schema [from Apollo Studio](#graph-fetch) or [via introspection](#graph-introspect).
+These Rover commands are _primarily_ for interacting with [monographs](/graphos/graphs/overview/#monographs) that do _not_ use [federation](/federation/). However, you can also use them to fetch a federated graph's API schema [from GraphOS](#graph-fetch) or [via introspection](#graph-introspect).
 
 > To fetch a federated graph's _supergraph_ schema instead of its _API_ schema, use [`supergraph` commands](./supergraphs/). [Learn about different schema types.](/federation/federated-types/overview/)
 >
@@ -13,9 +13,9 @@ These Rover commands are _primarily_ for interacting with monolithic graphs that
 
 ### `graph fetch`
 
-> This command requires [authenticating Rover with Apollo Studio](../configuring/#authenticating-with-apollo-studio).
+> This command requires [authenticating Rover with GraphOS](../configuring/#authenticating-with-graphos).
 
-You can use Rover to fetch the current schema of any Studio graph and variant it has access to.
+You can use Rover to fetch the current schema of any GraphOS graph and variant it has access to.
 
 Run the `graph fetch` command, like so:
 
@@ -68,25 +68,23 @@ rover graph fetch my-graph@my-variant --output prod-schema.graphql
 
 > For more on passing values via `stdout`, see [Conventions](../conventions#using-stdout).
 
-## Publishing a schema to Apollo Studio
+## Publishing a schema to GraphOS
 
 ### `graph publish`
 
-> This command requires [authenticating Rover with Apollo Studio](../configuring/#authenticating-with-apollo-studio).
+> This command requires [authenticating Rover with GraphOS](../configuring/#authenticating-with-graphos).
 
-You can use Rover to publish schema changes to one of your [Apollo Studio graphs](/studio/org/graphs/).
+You can use Rover to publish schema changes to one of your [GraphOS monographs](/studio/org/graphs/#monographs).
 
 Use the `graph publish` command, like so:
 
 ```shell
 rover graph publish my-graph@my-variant --schema ./schema.graphql
 ```
 
-The argument `my-graph@my-variant` in the example above specifies the ID of the Studio graph you're publishing to, along with which [variant](/studio/org/graphs/#variants) you're publishing to.
+The argument `my-graph@my-variant` in the example above specifies the ID of the GraphOS graph you're publishing to, along with which [variant](/studio/org/graphs/#variants) you're publishing to.
 
-> You can omit `@` and the variant name. If you do, Rover publishes the schema to the default variant, named `current`.
-
-If the graph exists in the graph registry, but the variant does not, a new variant will be created on publish.
+If the graph exists in GraphOS but the _variant_ doesn't, a new variant is be created on publish.
 
 ### Providing the schema
 
@@ -106,7 +104,7 @@ Whenever possible, we recommend publishing a `.graphql` file directly instead of
 
 ### `graph check`
 
-Before you [publish schema changes to Apollo Studio](#publishing-a-schema-to-apollo-studio), you can [check those changes](/graphos/delivery/schema-checks/) to confirm that you aren't introducing breaking changes to your application clients.
+Before you [publish schema changes to GraphOS](#publishing-a-schema-to-graphos), you can [check those changes](/graphos/delivery/schema-checks/) to confirm that you aren't introducing breaking changes to your application clients.
 
 To do so, you can run the `graph check` command:
 
@@ -126,13 +124,13 @@ If you don't want to wait for the check to complete, you can run the command wit
 
 #### Running checks in CI
 
-If you're running schema checks in CI, you might want to pass the `--background` flag to `rover graph check`. This flag instructs Rover to initiate schema checks but _not_ await their result. If you've [connected Apollo Studio to your GitHub repository](/graphos/delivery/github-integration/), the integration detects the checks execution and adds a status to the associated pull request.
+If you're running schema checks in CI, you might want to pass the `--background` flag to `rover graph check`. This flag instructs Rover to initiate schema checks but _not_ await their result. If you've [connected GraphOS to your GitHub repository](/graphos/delivery/github-integration/), the integration detects the checks execution and adds a status to the associated pull request.
 
 ## Deleting a variant
 
 ### `graph delete`
 
-> This command requires [authenticating Rover with Apollo Studio](../configuring/#authenticating-with-apollo-studio).
+> This command requires [authenticating Rover with GraphOS](../configuring/#authenticating-with-graphos).
 
 You can delete a single variant of a graph by running `rover graph delete`: