proofreading corrections

Signed-off-by: Richard Jones <richard@dagger.io>

docs/learn/1003-get-started.md

@@ -4,7 +4,7 @@ slug: /1003/get-started/
 
 # Get Started with Dagger
 
-In this tutorial, you will learn the basics of Dagger by building a Dagger project from scratch. This simple project deploys a [React](https://reactjs.org/) application to your local machine via Docker. In later tutorials, you will learn how to configure Dagger to deploy to your infrastructure. And, for advanced users, how to share access to your infrastructure in the same way that we share access to ours now.
+In this tutorial, you will learn the basics of Dagger by building a Dagger project from scratch. This simple project deploys a [React](https://reactjs.org/) application to your local machine via Docker. In later tutorials, you will learn how to configure Dagger to deploy to remote infrastructure such as EKS and GKE.
 
 This tutorial does involve writing CUE, so if you haven’t already, be sure to read [What is CUE?](../introduction/1005-what_is_cue.md)
 
@@ -16,7 +16,7 @@ In this tutorial we will learn:
   - environments
   - inputs and outputs
 - How to write CUE for Dagger
-- How to deploy an application using `dagger up`
+- How to deploy an application with Dagger
 
 ## Deploy an Application Locally
 
@@ -57,7 +57,7 @@ ls -la
 You will now see 2 new directories:
 
 - The `.dagger` directory will store metadata about _environments_, _inputs_, and _outputs_ which we will cover later.
-- The `cue.mod` directory stores libraries such as [dagger/universe](https://github.com/dagger/universe) which can be _imported_ into your Dagger _plan_.
+- The `cue.mod` directory stores libraries such as [dagger/universe](https://github.com/dagger/universe) which can be _imported_ into your Dagger plan.
 
 Dagger will load all `.cue` files recursively in the current Dagger project. More directories can be added to help organize code.
 
@@ -67,7 +67,7 @@ Dagger will load all `.cue` files recursively in the current Dagger project. Mor
 
 A Dagger _plan_ is written in CUE and defines the _resources_, _dependencies_, and _logic_ to deploy an application to an environment. Unlike traditional glue code written in a scripting language such as Bash or PowerShell, a Dagger plan is _declarative_ rather than _imperative_. This frees us from thinking about the order of operations, since Dagger will infer dependendencies and calculate correct order on its own.
 
-Let's first create a directory to hold our plan separately from our application code:
+Let’s first create a directory to hold our Dagger plan separately from our application code:
 
 ```bash
 mkdir -p ./plans/local
@@ -109,8 +109,8 @@ image: os.#Container & {
 
 // push the image to a registry
 push: docker.#Push & {
-  // leave target as a string here so that 
-  // different environments can push to different registries
+  // leave target blank here so that different
+  // environments can push to different registries
   target: string 
 
   // the source of our push resource
@@ -133,14 +133,16 @@ import (
 )
 
 // run our todoapp in our local Docker engine
-todoapp: docker.#Run & {
+run: docker.#Run & {
   ref: push.ref
   name: "todoapp"
   ports: ["8080:80"]
   socket: dagger.#Stream & dagger.#Input
 }
 
 // push to our local registry
+// this concrete value satisfies the string constraint
+// we defined in the previous file
 push: target: "localhost:5000/todoapp"
 ```
 
@@ -167,7 +169,7 @@ local ...todoapp/.dagger/env/local
 
 ### Define Input Values per Environment
 
-Our Dagger plan includes a number of references to `dagger.#Input` which inform the Dagger engine that the concrete value should be pulled from inputs. While some things such as the registry target we saw above can be expressed purely in CUE, others such as directories, secrets, and sockets are required to be explicitly defined as _inputs_ to protect against malicious code  being injected by third-party packages. If Dagger allowed such things to be stated in CUE, the entire package system could become a source of attacks.
+Our Dagger plan includes a number of references to `dagger.#Input` which inform the Dagger engine that the concrete value should be pulled from inputs at runtime. While some values such as the registry target we saw above can be expressed purely in CUE, others such as directories, secrets, and sockets are required to be explicitly defined as _inputs_ to protect against malicious code being injected by third-party packages. If Dagger allowed such things to be stated in CUE, the entire package system could become a source of attacks.
 
 List the inputs Dagger is aware of according to our plan:
 
@@ -178,29 +180,29 @@ dagger -e local input list
 You should see the following output:
 
 ```bash
-Input           Value             Set by user  Description
-app.source      dagger.#Artifact  false         Application source code
-todoapp.socket  struct            false         Mount local docker socket
+Input       Value             Set by user  Description
+app.source  dagger.#Artifact  false        Application source code
+run.socket  struct            false        Mount local docker socket
 ```
 
-Notice that `Set by user` is false for both, because we have not yet provided Dagger with those values.
+Notice that `Set by user` is _false_ for both, because we have not yet provided Dagger with those values.
 
 Let’s provide them now:
 
 ```shell
-dagger -e local input socket todoapp.socket /var/run/docker.sock
+dagger -e local input socket run.socket /var/run/docker.sock
 dagger -e local input dir app.source ./
 
 ```
 
-This defines the `todoapp.socket` as a `socket` input type, and the `app.source` input as a `dir` input type.
+This defines the `run.socket` as a `socket` input type, and the `app.source` input as a `dir` input type.
 
-Now let's replay the `dagger input list` command:
+Now let’s replay the `dagger input list` command:
 
 ```bash
-Input           Value             Set by user  Description
-app.source      dagger.#Artifact  true         Application source code
-todoapp.socket  struct            true         Mount local docker socket
+Input       Value             Set by user  Description
+app.source  dagger.#Artifact  true         Application source code
+run.socket  struct            true         Mount local docker socket
 ```
 
 Notice that Dagger now reports that both inputs have been set.
@@ -216,12 +218,12 @@ dagger up
 Once complete you should get logs, and a final output like this:
 
 ```bash
-Output                     Value                                          Description
-app.build                  struct                                         Build output directory
-push.ref                   "localhost:5000/todoapp:latest@sha256:<hash>"  Image ref
-push.digest                "sha256:<hash>"                                Image digest
-todoapp.ref                "localhost:5000/todoapp:latest@sha256:<hash>"  Image reference (e.g: nginx:alpine)
-todoapp.run.env.IMAGE_REF  "localhost:5000/todoapp:latest@sha256:<hash>"  -
+Output                 Value                                          Description
+app.build              struct                                         Build output directory
+push.ref               "localhost:5000/todoapp:latest@sha256:<hash>"  Image ref
+push.digest            "sha256:<hash>"                                Image digest
+run.ref                "localhost:5000/todoapp:latest@sha256:<hash>"  Image reference (e.g: nginx:alpine)
+run.run.env.IMAGE_REF  "localhost:5000/todoapp:latest@sha256:<hash>"  -
 ```
 
-Congratulations! You&rsquo;ve deployed your first Dagger plan! You can now open [http://localhost:8080](http://localhost:8080) in your browser!
+Congratulations! You&rsquo;ve deployed your first Dagger plan! You can now [view the todo app](http://localhost:8080) in your browser!