Fix docs

CONTRIBUTING.md

@@ -78,7 +78,7 @@ We've chosen to use ADRs to document architecturally significant decisions. We p
 # Create a new ADR titled "Use Bisquick for all waffle making"
 adr new Use Bisquick for all waffle making
 
-# Create a new ADR that supercedes a previous one. Let's say for example that the previous ADR about Bisquick was ADR number 9.
+# Create a new ADR that supersedes a previous one. Let's say for example that the previous ADR about Bisquick was ADR number 9.
 adr new -s 9 Use scratch ingredients for all waffle making
 
 # Create a new ADR that amends a previous one. Let's say the previous one was ADR number 15

docs/0-zarf-overview.md

@@ -197,4 +197,4 @@ Coming Soon!
 </TabItem>
 </Tabs>
 
-Zarf is being activity developed by the community. Our releases can be found [here](https://github.com/defenseunicorns/zarf/releases).
+Zarf is being actively developed by the community. Our releases can be found [here](https://github.com/defenseunicorns/zarf/releases).

docs/1-understand-the-basics.md

@@ -1,6 +1,6 @@
 # Understand The Basics
 
-Before you are able to effectively use Zarf, it is would be useful to have an underlying understanding of the technology Zarf is built on/around. The section below provides some helpful links to start build up this foundation as well as a glossary of the terms used in this project.
+Before you are able to effectively use Zarf, it is useful to have an underlying understanding of the technology Zarf is built on and around. The sections below provide some helpful links to start building up this foundation as well as a glossary of the terms used in this project.
 
 :::caution Hard Hat Area
 This page is still being developed. More content will be added soon!
@@ -31,11 +31,11 @@ This page is still being developed. More content will be added soon!
 
 **declarative** — A user states (via configuration file) which resources are needed and Zarf locates & packages them. A user does not have to know _how_ to download / collect / roll & unroll dependencies for transport, they only have to know _what_ they need.
 
-**package** — A well-defined (tool-generated / versioned / compressed) collection of software intended for movement (and later use) across a network / adminstrative boundary.
+**package** — A well-defined (tool-generated / versioned / compressed) collection of software intended for movement (and later use) across a network / administrative boundary.
 
 **remote systems** — Systems organized such that development & maintenance actions occur _primarily_ in locations physically & logically separate from where operations occur.
 
-**constrained systems** — Systems with explicit resource / adminstrative / capability limitations.
+**constrained systems** — Systems with explicit resource / administrative / capability limitations.
 
 **independent systems** — Systems organized such that continued operation is possible even when disconnected (temporarily or otherwise) from external systems dependencies.
 

docs/13-walkthroughs/1-initializing-a-k8s-cluster.md

@@ -30,7 +30,7 @@ zarf init       # Run the initialization command
 ### Confirming the Deployment
 Just like how we got a prompt when creating a package in the prior walkthrough, we will also get a prompt when deploying a package.
 ![Confirm Package Deploy](../.images/walkthroughs/package_deploy_confirm.png)
-Since there are container images within our init-package, we also get a notification about the [Software Bill of Materials (SBOM)](https://www.ntia.gov/SBOM) Zarf included for our package with a file location of where we could view the [SBOM Dashoard](../7-dashboard-ui/1-sbom-dashboard.md) if interested incase we were interested in viewing it.
+Since there are container images within our init-package, we also get a notification about the [Software Bill of Materials (SBOM)](https://www.ntia.gov/SBOM) Zarf included for our package with the file location of where the [SBOM Dashboard](../7-dashboard-ui/1-sbom-dashboard.md) can be viewed.
 
 <br />
 

docs/2-core-concepts.md

@@ -8,4 +8,4 @@ Now, assuming you're familiar with Kubernetes, the AirGap, and GitOps from [Unde
 
 - [**Zarf Package**](./4-user-guide/2-zarf-packages/1-zarf-packages.md) - A binary file that contains the instructions and dependencies necessary to install an application on a system.
 - [**Zarf Component**](./4-user-guide/2-zarf-packages/2-zarf-components.md) - A set of defined functionality and resources that build up a package.
-- [**Zarf Init Package**](./4-user-guide/2-zarf-packages/3-the-zarf-init-package.md) - The initial package that lays the groundwork for other packages
+- [**Zarf Init Package**](./4-user-guide/2-zarf-packages/3-the-zarf-init-package.md) - The initial package that lays the groundwork for other packages.

docs/4-user-guide/index.md

@@ -51,7 +51,7 @@ Find out more about that by calling the CLI for help, or check out an example pa
   <img alt="diagram showing the process to ship a package" src={require('../.images/what-is-zarf/ship-the-package.png').default} height="255" />
 </a>
 
-What this activity looks like is _very_ situationally specific so Zarf tries not to have an opinion&mdash;transfer Zarf packages between production & operating locations using whatever mechanisms are available.
+What this activity looks like is _very_ situational specific so Zarf tries not to have an opinion&mdash;transfer Zarf packages between production & operating locations using whatever mechanisms are available.
 
 Have to burn your package to disk & "sneakernet" it? That works.
 

docs/6-developer-guide/2-testing.md

@@ -53,7 +53,7 @@ There are a few requirements for all of our tests, that will need to be followed
 
 ## Test Naming Conventions
 
-The tests are run sequentially and the naming convention is set intentinonally:
+The tests are run sequentially and the naming convention is set intentionally:
 - 00-19 tests run prior to `zarf init` (cluster not initialized)
 - 20 is reserved for `zarf init`
 - 21 is reserved for logging tests so they can be removed first (they take the most resources in the cluster)

examples/git-data/README.md

@@ -1,6 +1,6 @@
 # Git Data
 
-This examples shows how to package `git` repositories to be bundled and pushed across the airgap.  This package does not deploy anything itself, but pushes assets to the specified `git` service to be consumed as desired.  Within Zarf, their are tow main ways to include `git` reposisotries as desribed below.
+This examples shows how to package `git` repositories to be bundled and pushed across the airgap.  This package does not deploy anything itself, but pushes assets to the specified `git` service to be consumed as desired.  Within Zarf, their are tow main ways to include `git` repositories as described below.
 
 :::info
 

examples/package-variables/README.md

@@ -15,7 +15,7 @@ To view the example source code, select the `Edit this page` link below the arti
  
 
 ## How to Use Deploy-Time Variables and Constants
-The 'placeholder' text in the manifest or chart yaml should have your desired key name in all caps with `###ZARF_VAR` prepended and `###` appened for `variables` or `###ZARF_CONST` prepended and `###` appened for `constants`.
+The 'placeholder' text in the manifest or chart yaml should have your desired key name in all caps with `###ZARF_VAR` prepended and `###` appended for `variables` or `###ZARF_CONST` prepended and `###` appended for `constants`.
 
 For example, if I wanted to create a template for a database username (using the variable `name`: `DATABASE_USERNAME`) I would do something like `###ZARF_VAR_DATABASE_USERNAME###` in the manifest or chart yaml.