Fix some broken links (#602)

content/docs/fundamentals/atmos.md

@@ -9,7 +9,7 @@ custom_edit_url: https://github.com/cloudposse/refarch-scaffold/tree/main/docs/d
 
 `atmos` is both a command-line tool and Golang module for provisioning, managing and orchestrating workflows across various toolchains including `terraform` and `helmfile`.
 
-The `atmos` tool is part of the SweetOps toolchain and was built to make DevOps and Cloud automation easier across multiple tools. It has direct support for automating Terraform, Helmfile. By utilizing [Stacks](/reference-architecture/fundamentals/tools/stacks), `atmos` enable you to effortlessly manage your Terraform and Helmfile [Components](/components) from your local machine, in your CI/CD pipelines, or using [spacelift](/components/library/aws/spacelift/).
+The `atmos` tool is part of the SweetOps toolchain and was built to make DevOps and Cloud automation easier across multiple tools. It has direct support for automating Terraform, Helmfile. By utilizing [Stacks](/fundamentals/stacks), `atmos` enable you to effortlessly manage your Terraform and Helmfile [Components](/components) from your local machine, in your CI/CD pipelines, or using [spacelift](/components/library/aws/spacelift/).
 
 ## Problem
 A modern infrastructure depends on lots of various tools like terraform, packer, helmfile, helm, kubectl, docker, etc. All these tools have varying degrees of configuration support, but most are not optimized for defining DRY configurations across dozens or hundreds of environments. Moreover, the configuration format is very different between the tools, but usually, boils down to some kind of key-value configuration in either JSON or YAML. This lack of configuration consistency poses a problem when we want to make it easy to declaratively define the settings that end-users should care about.
@@ -313,7 +313,7 @@ For example, to run the `deploy-all` workflow from the [workflows](https://githu
 ## Recommended Filesystem Layout
 
 :::info
-For an example of what this looks like within [Geodesic](/reference-architecture/fundamentals/tools/geodesic) see the section on “Filesystem Layout”
+For an example of what this looks like within [Geodesic](/fundamentals/geodesic) see the section on “Filesystem Layout”
 
 :::
 
@@ -356,7 +356,7 @@ infrastructure/
 
 Atmos supports a CLI configuration to define configure the behavior working with stacks and components.
 
-In [Geodesic](/reference-architecture/fundamentals/tools/geodesic) we typically put this in `/usr/local/etc/atmos/atmos.yaml` (e.g. in `rootfs/...` in the `infrastructure` repository). Note this file uses the stack config format for consistency, but we do not consider it a stack configuration.
+In [Geodesic](/fundamentals/geodesic) we typically put this in `/usr/local/etc/atmos/atmos.yaml` (e.g. in `rootfs/...` in the `infrastructure` repository). Note this file uses the stack config format for consistency, but we do not consider it a stack configuration.
 
 The CLI config is loaded from the following locations (from lowest to highest priority):
 
@@ -475,6 +475,6 @@ stacks:
 
 ## Concepts
 
-- [Stacks](/reference-architecture/fundamentals/tools/stacks)
+- [Stacks](/fundamentals/stacks)
 
 - [Components](/components)

content/docs/fundamentals/concepts.md

@@ -101,7 +101,7 @@ Great, so what can you do with a stack? Stacks are meant to be a language and to
 3. [Spacelift](https://spacelift.io/): By using the [terraform-spacelift-cloud-infrastructure-automation module](https://github.com/cloudposse/terraform-spacelift-cloud-infrastructure-automation) you can configure Spacelift continuously deliver components. Read up on why we [Use Spacelift for GitOps with Terraform](/reference-architecture/reference/adrs/use-spacelift-for-gitops-with-terraform) .
 
 ### Catalogs
-Catalogs in SweetOps are collections of sharable and reusable configurations. Think of the configurations in catalogs as defining archetypes (a very typical example of a certain thing) of configuration (E.g. `s3/public` and `s3/logs` would be two kinds of archtypes of S3 buckets). They are also convenient for managing [Terraform](/reference-architecture/fundamentals/tools/terraform). These are typically YAML configurations that can be imported and provide solid baselines to configure security, monitoring, or other 3rd party tooling. Catalogs enable an organization to codify its best practices of configuration and share them. We use this pattern both with our public terraform modules as well as with our stack configurations (e.g. in the `stacks/catalog` folder).
+Catalogs in SweetOps are collections of sharable and reusable configurations. Think of the configurations in catalogs as defining archetypes (a very typical example of a certain thing) of configuration (E.g. `s3/public` and `s3/logs` would be two kinds of archtypes of S3 buckets). They are also convenient for managing [Terraform](/fundamentals/terraform). These are typically YAML configurations that can be imported and provide solid baselines to configure security, monitoring, or other 3rd party tooling. Catalogs enable an organization to codify its best practices of configuration and share them. We use this pattern both with our public terraform modules as well as with our stack configurations (e.g. in the `stacks/catalog` folder).
 
 SweetOps provides many examples of how to use the catalog pattern to get you started.
 
@@ -122,15 +122,15 @@ Collections are groups of stacks.
 Sements are interconnected networks. For example, a production segment connects all production-tier stacks, while a non-production segment connects all non-production stacks.
 
 ### Primary vs Delegated
-Primary vs Delegated is a common implementation pattern in SweetOps. This is most easily described when looking at the example of domain and DNS usage in a mutli-account AWS organization: SweetOps takes the approach that the root domain (e.g. `example.com`) is owned by a **primary** AWS account where the apex zone resides. Subdomains on that domain (e.g. `dev.example.com`) are then **delegated** to the other AWS accounts via an `NS` record on the primary hosted zone which points to the delegated hosted zone’s name servers.
+Primary vs Delegated is an implementation pattern in SweetOps. This is most easily described when looking at the example of domain and DNS usage in a mutli-account AWS organization: SweetOps takes the approach that the root domain (e.g. `example.com`) is owned by a **primary** AWS account where the apex zone resides. Subdomains on that domain (e.g. `dev.example.com`) are then **delegated** to the other AWS accounts via an `NS` record on the primary hosted zone which points to the delegated hosted zone’s name servers.
 
-You can see examples of this pattern in the [dns-primary](/components/library/aws/dns-primary/), [dns-delegated](/components/library/aws/dns-delegated/) and [iam-primary-roles](https://github.com/cloudposse/terraform-aws-components/tree/main/deprecated/iam-primary-roles)  / [iam-delegated-roles](https://github.com/cloudposse/terraform-aws-components/tree/main/deprecated/iam-delegated-roles)  components.
+You can see an example of this pattern in the [dns-primary](/components/library/aws/dns-primary/) and [dns-delegated](/components/library/aws/dns-delegated/) components.
 
 ### Live vs Model (or Synthetic)
 Live represents something that is actively being used. It differs from stages like “Production” and “Staging” in the sense that both stages are “live” and in-use. While terms like “Model” and “Synthetic” refer to something which is similar, but not in use by end-users. For example, a live production vanity domain of `acme.com` might have a synthetic vanity domain of `acme-prod.net`.
 
 ### Docker Based Toolbox (aka Geodesic)
-In the landscape of developing infrastructure, there are dozens of tools that we all need on our personal machines to do our jobs. In SweetOps, instead of having you install each tool individually, we use Docker to package all of these tools into one convenient image that you can use as your infrastructure automation toolbox. We call it [Geodesic](/reference-architecture/fundamentals/tools/geodesic) and we use it as our DevOps automation shell and as the base Docker image for all of our DevOps tooling.
+In the landscape of developing infrastructure, there are dozens of tools that we all need on our personal machines to do our jobs. In SweetOps, instead of having you install each tool individually, we use Docker to package all of these tools into one convenient image that you can use as your infrastructure automation toolbox. We call it [Geodesic](/fundamentals/geodesic) and we use it as our DevOps automation shell and as the base Docker image for all of our DevOps tooling.
 
 Geodesic is a DevOps Linux Distribution packaged as a Docker image that provides users the ability to utilize `atmos`, `terraform`, `kubectl`, `helmfile`, the AWS CLI, and many other popular tools that compromise the SweetOps methodology without having to invoke a dozen `install` commands to get started. It’s intended to be used as an interactive cloud automation shell, a base image, or in CI/CD workflows to ensure that all systems are running the same set of versioned, easily accessible tools.
 

content/docs/fundamentals/geodesic.md

@@ -28,7 +28,8 @@ An organization may choose to leverage all of these components or just the parts
 :::info
 **Apple Silicon (M1, M2, etc. Chips) Support**
 
-Geodesic is comprised of a large collection of mostly [third-party open-source tools distributed via our packages repository](https://github.com/cloudposse/packages).
+Geodesic is comprised of a large collection of open-source tools, most of them not created or maintained by Cloud Posse.
+(Most of them and many more can be installed individually using packages from our [`packages` repository](https://github.com/cloudposse/packages).)
 As such, **support for Macs with Apple chips (M1, M2, etc.) is fully not under Cloud Posse's control**, rather it
 depends on each tool author updating each tool for the Apple chips, referred to as the `arm64` architecture. 
 **The Debian-based Geodesic is provided as a multi-architecture Docker image, supporting both Intel chips (`amd64`) and 
@@ -253,5 +254,5 @@ If a user runs the Docker daemon as `root`, files may fail to be written to the
 The recommended solution for Linux users is to run Docker in ["rootless"](https://docs.docker.com/engine/security/rootless/)
 mode. In this mode, the Docker daemon runs as the host user (rather than as root) and files created by the root user in Geodesic
 are owned by the host user on the host. Not only does this configuration solve this issue, but it provides much better system security overall.
-[Ref](https://github.com/cloudposse/geodesic/issues/594).
+See [this issue](https://github.com/cloudposse/geodesic/issues/594) for more details.
 

content/docs/fundamentals/stacks.md

@@ -12,7 +12,7 @@ Stacks are a way to express the complete infrastructure needed for an environmen
 
 Stacks are a central SweetOps abstraction layer that is used to instantiate [Components](/components). They’re a set of YAML files [that follow a standard schema](https://github.com/cloudposse/atmos/blob/master/docs/schema/stack-config-schema.json) to enable a **fully declarative description of your various environments**. This empowers you with the ability to separate your infrastructure’s environment configuration settings from the business logic behind it (provided via components).
 
-SweetOps utilizes a custom YAML configuration format for stacks because it’s an easy-to-work-with format that is nicely portable across multiple tools. The stack YAML format is natively supported today via [Atmos](/reference-architecture/fundamentals/tools/atmos) , [the terraform-yaml-stack-config module](https://github.com/cloudposse/terraform-yaml-stack-config), and [Spacelift](https://spacelift.io/) via [the terraform-spacelift-cloud-infrastructure-automation module](https://github.com/cloudposse/terraform-spacelift-cloud-infrastructure-automation).
+SweetOps utilizes a custom YAML configuration format for stacks because it’s an easy-to-work-with format that is nicely portable across multiple tools. The stack YAML format is natively supported today via [Atmos](/fundamentals/atmos) , [the terraform-yaml-stack-config module](https://github.com/cloudposse/terraform-yaml-stack-config), and [Spacelift](https://spacelift.io/) via [the terraform-spacelift-cloud-infrastructure-automation module](https://github.com/cloudposse/terraform-spacelift-cloud-infrastructure-automation).
 
 :::note
 Stacks define a generic schema for expressing infrastructure
@@ -36,7 +36,7 @@ Stacks define a generic schema for expressing infrastructure
 We have a number of important conventions around stacks that are worth noting.
 
 :::info
-Make sure you’re already familiar with the core [Concepts](/reference-architecture/fundamentals/tools/concepts).
+Make sure you’re already familiar with the core [Concepts](/fundamentals/concepts).
 
 :::
 

content/docs/fundamentals/terraform.md

@@ -11,7 +11,7 @@ import ReactPlayer from 'react-player'
 
 For the most part, we assume users have a solid grasp of `terraform`. Cloud Posse has adopted a number of conventions for how we work with `terraform` that we document here. Review [our opinionated public “best practices” as it relates to terraform](/reference/best-practices/terraform-best-practices/).
 
-We use [Atmos](/reference-architecture/fundamentals/tools/atmos) together with [Stacks](/reference-architecture/fundamentals/tools/stacks) to call [Components](/components) that provision infrastructure with `terraform`.
+We use [Atmos](/fundamentals/atmos) together with [Stacks](/fundamentals/stacks) to call [Components](/components) that provision infrastructure with `terraform`.
 
 :::caution
 Be aware of [Terraform Environment Variables](https://www.terraform.io/docs/cli/config/environment-variables.html) that can alter the behavior of `terraform` when run outside of what you see in `atmos` or `geodesic`. These are also helpful to change default behavior as well, such as by setting the `TF_DATA_DIR`.
@@ -116,7 +116,7 @@ Every input value can also be specified individually by name as a standard Terra
 
 ### Stacks and Components
 
-We use [Stacks](/reference-architecture/fundamentals/tools/stacks) to define and organize configurations. We place terraform “root” modules in the `components/terraform` directory (e.g. `components/terraform/s3-bucket`). Then we define one or more catalog archetypes for using the component (e.g. `catalog/s3-bucket/logs.yaml` and `catalog/s3-bucket/artifacts`).
+We use [Stacks](/fundamentals/stacks) to define and organize configurations. We place terraform “root” modules in the `components/terraform` directory (e.g. `components/terraform/s3-bucket`). Then we define one or more catalog archetypes for using the component (e.g. `catalog/s3-bucket/logs.yaml` and `catalog/s3-bucket/artifacts`).
 
 ### Atmos CLI