typo: Fix some minor typos.

Signed-off-by: Guillaume Coguiec <guillaume@logical.work>

docs/learn/1003-get-started.md

@@ -67,7 +67,7 @@ Dagger will load all `.cue` files recursively in the current Dagger project. Mor
 
 ### Write a Dagger Plan
 
-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.
+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 dependencies and calculate correct order on its own.
 
 Let’s first create a directory to hold our Dagger plan separately from our application code:
 
@@ -155,7 +155,7 @@ dockerSocket  struct            true         Mount local docker socket
 
 Notice that Dagger now reports that both inputs have been set.
 
-### Deploy the Appplication
+### Deploy the Application
 
 With our plan in place, our environment set, and our inputs defined, we can deploy the application as simply as:
 

docs/learn/1005-what_is_cue.md

@@ -10,7 +10,7 @@ CUE is a powerful configuration language created by Marcel van Lohuizen who co-c
 
 For decades, developers, engineers, and system administrators alike have used some combination of `INI`, `ENV`, `YAML`, `XML`, and `JSON` (as well as custom formats such as those for Apache, Nginx, et al) to describe configurations, resources, operations, variables, parameters, state, etc. While these examples work fine for storing data, they are merely _data formats_, not languages, and as such they each lack the ability to execute logic and operate on data directly.
 
-Simple—yet powerful!—things like if statements, for loops, comprehensions, and string interpolation, among others are just not possible in these formats without the use of a separate process for execution. The result is that variables or parameters must be injected, and any logic executed by a templating language (such as Jinja) or by a separate engine instructed by a DSL (Domain-specific Language). Often templating languages and DSLs are used in conjuction and while this technically works, the results are that we end up with code bases, or even single files, that are overly verbose, that intersperse templating languages with various DSLs (and sometimes multiple DSLs that feed ouput from one to the input of another!), that create rigid structures without enforcing schemas (not without more effort), thereby making the code challenging to reason about, difficult to maintain, brittle, and perhaps worst of all, _prone to side effects_.
+Simple—yet powerful!—things like if statements, for loops, comprehensions, and string interpolation, among others are just not possible in these formats without the use of a separate process for execution. The result is that variables or parameters must be injected, and any logic executed by a templating language (such as Jinja) or by a separate engine instructed by a DSL (Domain-specific Language). Often templating languages and DSLs are used in conjunction and while this technically works, the results are that we end up with code bases, or even single files, that are overly verbose, that intersperse templating languages with various DSLs (and sometimes multiple DSLs that feed output from one to the input of another!), that create rigid structures without enforcing schemas (not without more effort), thereby making the code challenging to reason about, difficult to maintain, brittle, and perhaps worst of all, _prone to side effects_.
 
 A _configuration language_ such as CUE, allows us to both _specify_ data as well as _act_ upon that data with any logic necessary to achieve the desired output. Furthermore, and perhaps most importantly, CUE allows us to not only specify data as concrete values, but also specify the _types_ those concrete values must be as well as any _constraints_ such as min and max for example. It gives us the ability to define a _schema_ but unlike doing so with say JSON Schema, CUE can both _define_ and _enforce_ the schema, whereas JSON Schema is merely a definition that requires some other process to enforce it.
 
@@ -147,7 +147,7 @@ Bob:
 
 ```
 
-The output here is a product of _*unifying*_ the `#Person` _definition_ with an object that contains _concrete values_ each of which is the product of unifying the concrete value with the _types_ and _constraints_ declared by the field in the defintion. [Try it in the CUE playground](https://cuelang.org/play/?id=nAUx1-VlrY4#cue@export@yaml)
+The output here is a product of _*unifying*_ the `#Person` _definition_ with an object that contains _concrete values_ each of which is the product of unifying the concrete value with the _types_ and _constraints_ declared by the field in the definition. [Try it in the CUE playground](https://cuelang.org/play/?id=nAUx1-VlrY4#cue@export@yaml)
 
 ### Default Values and the Nature of Inheritance
 

docs/learn/1007-kubernetes.md

@@ -179,7 +179,7 @@ The following `config.cue` defines:
 
 The below `config.cue` defines:
 
-- `kubeconfig` a generic value created to embbed this `gke.#KubeConfig` value
+- `kubeconfig` a generic value created to embed this `gke.#KubeConfig` value
 - `gcpConfig`: connection to Google using `alpha.dagger.io/gcp`
 - `gkeConfig`: transform a `gcpConfig` to a readable format for `kubernetes.#Resources.kubeconfig`
   using `alpha.dagger.io/gcp/gke`
@@ -194,7 +194,7 @@ The below `config.cue` defines:
 
 The below `config.cue` defines:
 
-- `kubeconfig`, a generic value created to embbed this `eksConfig.kubeconfig` value
+- `kubeconfig`, a generic value created to embed this `eksConfig.kubeconfig` value
 - `awsConfig`, connection to Amazon using `alpha.dagger.io/aws`
 - `eksConfig`, transform a `awsConfig` to a readable format for `kubernetes.#Resources.kubeconfig`
   using `alpha.dagger.io/aws/eks`

docs/learn/tests/cloudformation/source-end.cue

@@ -15,7 +15,7 @@ suffix: random.#String & {
 	seed: ""
 }
 
-// Query the Cloudformation stackname, or create one with a random suffix to keep unicity
+// Query the Cloudformation stackname, or create one with a random suffix for uniqueness
 cfnStackName: *"stack-\(suffix.out)" | string & dagger.#Input
 
 // AWS Cloudformation stdlib

docs/learn/tests/kube-aws/cue-manifest/todoapp.cue

@@ -16,7 +16,7 @@ tag:      "test-ecr"
 
 // Todoapp deployment pipeline
 todoApp: {
-	// Build the image from repositoru artifact
+	// Build the image from repository artifact
 	image: docker.#Build & {
 		source: repository
 	}
@@ -37,7 +37,7 @@ todoApp: {
 		image: remoteImage.ref
 	}
 
-	// Deploy the customized manifest to a kubernetes cluster 
+	// Deploy the customized manifest to a kubernetes cluster
 	kubeSrc: kubernetes.#Resources & {
 		"kubeconfig": kubeconfig
 		manifest:     deployment.manifest

docs/learn/tests/kube-kind/deployment/todoapp.cue

@@ -23,7 +23,7 @@ manifest: dagger.#Artifact & dagger.#Input
 
 // Todoapp deployment pipeline
 todoApp: {
-	// Build the image from repositoru artifact
+	// Build the image from repository artifact
 	image: docker.#Build & {
 		source: repository
 	}