Updates from review

docs/sources/tasks/migrate/from-operator.md

@@ -11,12 +11,12 @@ weight: 320
 You can migrate from Grafana Agent Operator to {{< param "PRODUCT_NAME" >}}.
 
 - The Monitor types (`PodMonitor`, `ServiceMonitor`, `Probe`, and `PodLogs`) are all supported natively by {{< param "PRODUCT_NAME" >}}.
-- The parts of the Operator that deploy the {{< param "PRODUCT_NAME" >}} itself (`GrafanaAgent`, `MetricsInstance`, and `LogsInstance` CRDs) are deprecated.
+- The parts of Grafana Agent Operator that deploy the Grafana Agent itself (`GrafanaAgent`, `MetricsInstance`, and `LogsInstance` CRDs) are deprecated.
 
 ## Deploy {{% param "PRODUCT_NAME" %}} with Helm
 
 1. Create a `values.yaml` file, which contains options for deploying {{< param "PRODUCT_NAME" >}}.
-   You can start with the [default values][] and customize as you see fit, or start with this snippet, which should be a good starting point for what the Operator does.
+   You can start with the [default values][] and customize as you see fit, or start with this snippet, which should be a good starting point for what Grafana Agent Operator does.
 
     ```yaml
     alloy:
@@ -50,7 +50,7 @@ You can migrate from Grafana Agent Operator to {{< param "PRODUCT_NAME" >}}.
 1. Create a Helm release. You can name the release anything you like. The following command installs a release called `alloy-metrics` in the `monitoring` namespace.
 
     ```shell
-    helm upgrade alloy-metrics grafana/alloy -i -n monitoring -f values.yaml --set-file alloy.configMap.content=alloy.alloy
+    helm upgrade alloy-metrics grafana/alloy -i -n monitoring -f values.yaml --set-file alloy.configMap.content=config.alloy
     ```
 
     This command uses the `--set-file` flag to pass the configuration file as a Helm value so that you can continue to edit it as a regular {{< param "PRODUCT_NAME" >}} configuration file.
@@ -59,7 +59,7 @@ You can migrate from Grafana Agent Operator to {{< param "PRODUCT_NAME" >}}.
 
 A `MetricsInstance` resource primarily defines:
 
-- The remote endpoints {{< param "PRODUCT_NAME" >}} should send metrics to.
+- The remote endpoints Grafana Agent should send metrics to.
 - The `PodMonitor`, `ServiceMonitor`, and `Probe` resources this {{< param "PRODUCT_NAME" >}} should discover.
 
 You can use these functions in {{< param "PRODUCT_NAME" >}} with the `prometheus.remote_write`, `prometheus.operator.podmonitors`, `prometheus.operator.servicemonitors`, and `prometheus.operator.probes` components respectively.
@@ -127,7 +127,7 @@ Our current recommendation is to create an additional DaemonSet deployment of {{
 > still considered experimental, but if you would like to try them, see the documentation for [loki.source.kubernetes][] and
 > [loki.source.podlogs][].
 
-These values are close to what the Operator currently deploys for logs:
+These values are close to what Grafana Agent Operator deploys for logs:
 
 ```yaml
 alloy:
@@ -268,7 +268,7 @@ The logging subsystem is very powerful and has many options for processing logs.
 ## Integrations
 
 The `Integration` CRD isn't supported with {{< param "PRODUCT_NAME" >}}.
-However, all static mode integrations have an equivalent component in the [`prometheus.exporter`][prometheus.exporter] namespace.
+However, all Grafana Agent Static integrations have an equivalent component in the [`prometheus.exporter`][prometheus.exporter] namespace.
 The [reference documentation][component documentation] should help convert those integrations to their {{< param "PRODUCT_NAME" >}} equivalent.
 
 <!-- ToDo: Validate path -->

docs/sources/tasks/migrate/from-static.md

@@ -46,7 +46,7 @@ This conversion will enable you to take full advantage of the many additional fe
    Replace the following:
 
     * _`<INPUT_CONFIG_PATH>`_: The full path to the Grafana Agent Static configuration.
-    * _`<OUTPUT_CONFIG_PATH>_`: The full path to output the {{< param "PRODUCT_NAME" >}} configuration.
+    * _`<OUTPUT_CONFIG_PATH>`_: The full path to output the {{< param "PRODUCT_NAME" >}} configuration.
 
 1. [Run][run alloy] {{< param "PRODUCT_NAME" >}} using the new {{< param "PRODUCT_NAME" >}} configuration from _`<OUTPUT_CONFIG_PATH>`_:
 

docs/sources/tutorials/first-components-and-stdlib/index.md

@@ -191,7 +191,7 @@ This is to prevent infinite loops from forming in the pipeline.
 Let's start a container running Redis and configure {{< param "PRODUCT_NAME" >}} to scrape metrics from it.
 
 ```bash
-docker container run -d --name flow-redis -p 6379:6379 --rm redis
+docker container run -d --name alloy-redis -p 6379:6379 --rm redis
 ```
 
 Try modifying the pipeline to scrape metrics from the Redis exporter.
@@ -221,7 +221,7 @@ After the first scrape, you should be able to query for `redis` metrics as well
 To shut down the Redis container, run:
 
 ```bash
-docker container stop flow-redis
+docker container stop alloy-redis
 ```
 
 If you get stuck, you can always view a solution here:

docs/sources/tutorials/get-started.md

@@ -11,7 +11,7 @@ This set of tutorials contains a collection of examples that build on each other
 
 ## What is {{% param "PRODUCT_NAME" %}}?
 
-{{< param "PRODUCT_NAME" >}} uses a declarative configuration language that allows you to define a pipeline of telemetry collection, processing, and output. It is built on top of the [{{< param "PRODUCT_NAME" >}} configuration syntax][configuration], which is designed to be fast, simple, and easy to debug.
+{{< param "PRODUCT_NAME" >}} uses a [configuration syntax][configuration] that allows you to define a pipeline of telemetry collection, processing, and output.
 
 ## What do I need to get started?