fix: still rolling

Signed-off-by: Bailey Hayes <bailey@cosmonic.com>

Author: ricochet

blog/2022-05-25-wasmcloud-capabilities-are-managed-algebraic-effects-for-webassembly-functions/index.mdx

@@ -58,7 +58,7 @@ Algebraic effects don't need to be big, high-level concepts like database or net
 Logger.debug("Performing international withdrawal")
 ```
 
-wasmCloud takes these algebraic effects even further by requiring each of our WebAssembly modules to be <u>[cryptographically signed](https://wasmcloud.com/docs/hosts/security)</u> with the explicit list of capabilities it can use (effects it can produce).
+wasmCloud takes these algebraic effects even further by requiring each of our WebAssembly modules to be <u>[cryptographically signed](https://wasmcloud.com/docs/v1/hosts/security)</u> with the explicit list of capabilities it can use (effects it can produce).
 
 Ultimately what we've done is provided a means to maintain portable function purity in WebAssembly modules while allowing for all algebraic effects to not only be testable, but distributed, hot-swappable, and dynamically scalable across a flat topology system comprised of multiple disparate environments.
 

blog/2022-06-16-webassembly-components-and-wasmcloud-actors-a-glimpse-of-the-future/index.mdx

@@ -28,7 +28,7 @@ are able to glue together arbitrary Wasm modules that import or export functions
 interface file. These interface files are called `wit` files (Wasm Interface Types) and allow for
 language agnostic code generation. This code is what handles converting the raw numbers of plain
 Wasm (i.e. integers and bytes) into concrete types. If you are familiar with wasmCloud already, this
-is [very similar](https://wasmcloud.com/docs/concepts/interfaces) to what we call "contract driven development,"
+is [very similar](https://wasmcloud.com/docs/v1/concepts/interfaces) to what we call "contract driven development,"
 which we use to separate non-functional requirements from business logic. Still confused? Don't
 worry, we'll be using some specific examples below. If this topic interests you and you'd like more
 information, we highly recommend you check out all of the

blog/2023-02-22-zero-trust-security/index.mdx

@@ -48,11 +48,11 @@ With wasmCloud, we use signed JSON Web Tokens ([JWT](https://jwt.io)) embedded d
 
 Actors are signed with identifiers for the capability contracts to which they have been granted access, like `HTTP Server`, `Message Subscriber`, or `Key Value Store`. These capabilities are abstract contracts, the implementations for which are linked at runtime. You can use mock, test, or lightweight implementations when going through your inner development loop on your workstation and then swap to different implementations in higher environments, all without having to rebuild or redeploy your actors.
 
-Because actors are cryptographically signed with [ed25519 keys](https://wasmcloud.com/docs/reference/host-runtime/security#managing-keys), we can also subject actors to policies that utilize metadata like the issuer of the module, its expiration date, its "not valid before" date, and much more. We can use policies like this to only allow actors from a certain set of trusted issuers, split the issuers allowed for production and dev/test, and any number of other additional security measures.
+Because actors are cryptographically signed with [ed25519 keys](https://wasmcloud.com/docs/v1/reference/host-runtime/security#managing-keys), we can also subject actors to policies that utilize metadata like the issuer of the module, its expiration date, its "not valid before" date, and much more. We can use policies like this to only allow actors from a certain set of trusted issuers, split the issuers allowed for production and dev/test, and any number of other additional security measures.
 
 ### Cluster Security
 
-As we continue moving up the abstraction level from a single wasmCloud host, next we can look at a cluster of wasmCloud hosts known as a _[lattice](https://wasmcloud.com/docs/reference/lattice/)_. In a lattice, only those hosts that have been authorized to communicate with the cluster can do so, and invocations from invalid issuers or from spoofed senders or MITM (man-in-the-middle) attackers can all be rejected.
+As we continue moving up the abstraction level from a single wasmCloud host, next we can look at a cluster of wasmCloud hosts known as a _[lattice](https://wasmcloud.com/docs/v1/reference/lattice/)_. In a lattice, only those hosts that have been authorized to communicate with the cluster can do so, and invocations from invalid issuers or from spoofed senders or MITM (man-in-the-middle) attackers can all be rejected.
 
 To accomplish this, each host in a wasmCloud cluster generates its own unique identity key pair, but is also given a _[cluster signing key](https://wasmcloud.com/docs/app-dev/secure/clusterkeys#zero-trust-invocations)_. This key is used to sign invocations to actors and providers elsewhere on the cluster. These remote hosts receiving those calls can then verify the issuer of that invocation, as well as whether the invocation's bytes have been tampered with.
 

blog/2023-03-30-all-the-clouds-a-stage-webassembly-actor/index.mdx

@@ -58,4 +58,4 @@ The latter of what I just described is pure business logic that remains pure reg
 
 Infrastructure is the dynamic runtime shape of my environment that my actors should not know about. This view may be controversial, but I firmly believe that separating my business logic from my supervision tree is crucial to being able to easily, securely, and reliably build distributed applications.
 
-Check out our [documentation](/docs/intro) to get started with wasmCloud.
+Check out our [documentation](/docs/v1/intro) to get started with wasmCloud.

blog/2023-06-13-objects-instances-state-distributed-systems/index.mdx

@@ -59,4 +59,4 @@ If you want to run your actors with state associated with each one, you can do t
 
 You can pick one, or both, and adjust over time as your application, customer base, and capacity needs evolve.
 
-Take a look at our [getting started](/docs/tour/hello-world) guide and decide for yourself what kind of paradigm you want to use to build your next amazing distributed application.
+Take a look at our [getting started](/docs/v1/tour/hello-world) guide and decide for yourself what kind of paradigm you want to use to build your next amazing distributed application.

blog/2023-12-06-wasmcloud-a-retrospective/index.mdx

@@ -22,7 +22,7 @@ In the last six months alone, innovation has hastened dramatically as the commun
 
 It's important to note, wasmCloud seeks to evolve alongside the WebAssembly ecosystem, adopting standards and best practices as they become available. We strongly believe this is the best way to accomplish our goals as a project. This was the theme of the wasmCloud Roadmap that we published this summer. Let's take a look at our goals and how we fared:
 
-1. **Leverage as many WebAssembly standards as possible (WASI, Wasm components, wasi-cloud).** Since we published our [roadmap](https://wasmcloud.com/docs/roadmap) in summer, much of our effort has focused around engineering wasmCloud to leverage WASI Preview 2 and the Component Model. This lets us deprioritize our [wasmbus Stable ABI](https://wasmcloud.com/docs/0.82/hosts/abis/wasmbus/ffi) in favor of a common standard, and lets developers get rid of wasmCloud specific dependencies in our projects. As shown in the [29 Nov 2023 community meeting](https://www.youtube.com/watch?v=GFc0gzvn8Oo), you can create a component with Bytecode Alliance tooling and run it right in wasmCloud. Goal accomplished.
+1. **Leverage as many WebAssembly standards as possible (WASI, Wasm components, wasi-cloud).** Since we published our [roadmap](https://wasmcloud.com/docs/v1/roadmap) in summer, much of our effort has focused around engineering wasmCloud to leverage WASI Preview 2 and the Component Model. This lets us deprioritize our [wasmbus Stable ABI](https://wasmcloud.com/docs/0.82/hosts/abis/wasmbus/ffi) in favor of a common standard, and lets developers get rid of wasmCloud specific dependencies in our projects. As shown in the [29 Nov 2023 community meeting](https://www.youtube.com/watch?v=GFc0gzvn8Oo), you can create a component with Bytecode Alliance tooling and run it right in wasmCloud. Goal accomplished.
 2. **Provide a seamless developer experience for building, testing, and deploying WebAssembly components.** wasmCloud has come a long way in terms of developer usability and this will continue to be a focus in the coming months. There are always areas we can improve, but what's really exciting is how streamlined and rewarding the experience becomes as we adopt a components- and WIT-centric approach. With WIT, the component model inherently strips away much of the complexity of building Wasm components and applications, breaking down language barriers to create true interoperability. We also allow developers to bring their own Wasm components to wasmCloud — a major step forward.
 3. **Develop the wasmCloud runtime in Rust.** Having recently been accepted as [ADR-0013](https://github.com/wasmCloud/wasmCloud/blob/main/adr/0013-transition-feature-focus-to-rust.md), writing a new host runtime in Rust has been instrumental in enabling us to achieve our first goal, to adopt the latest Wasm standards. Essentially, it has permitted us to to compile to many elements we had experimental support for. As a result, we now have support for Wasm components, and core WASI APIs `wasi-http-proxy` and `wasi-cli`. We're also introducing support for custom interfaces defined by WIT, a hard requirement for developers to be able to extend the provided interfaces.
 4. **Be the best, and most joyful way to build vendor-less components for WebAssembly applications.** wasmCloud really is the best way to build a completely vendor-less components for Wasm applications. We absolutely know that the developer experience can be improved and so this continues to be in focus for us ongoing. Having said that, once you've built a Wasm application, running it in wasmCloud really is a joyful experience. As a developer, you don't need to worry about what vendor or SDK will supply the implementation for a capability when you're building an application. You can also take your application components and distribute them across any infrastructure; all components can communicate as if they are on the same machine. Platform engineers love the ability to run developer applications and manage the underlying requirements, deployment, and implementation at runtime. This is a continual goal, and I'm glad we captured it in our roadmap for the end of this year.

blog/2023-12-13-wasmcloud-a-refreshed-roadmap/index.mdx

@@ -10,15 +10,15 @@ slug: wasmcloud-a-refreshed-roadmap
 
 ![New roadmap](./images/2024q1roadmap.png)
 
-Last week, we [looked back](https://wasmcloud.com/blog/wasmcloud-a-retrospective) at how far the wasmCloud project has come. In particular, the progress made in the last few months since the [Q3/Q4 roadmap](https://wasmcloud.com/docs/roadmap/q3q4) was published. We're nearing the release of wasmCloud 1.0; our stable, standards-led and production-ready release due to be unveiled in early 2024. As we reach this major milestone, we're excited to unveil a [refreshed roadmap for Q1 2024](https://wasmcloud.com/docs/roadmap).
+Last week, we [looked back](https://wasmcloud.com/blog/wasmcloud-a-retrospective) at how far the wasmCloud project has come. In particular, the progress made in the last few months since the [Q3/Q4 roadmap](https://wasmcloud.com/docs/v1/roadmap/q3q4) was published. We're nearing the release of wasmCloud 1.0; our stable, standards-led and production-ready release due to be unveiled in early 2024. As we reach this major milestone, we're excited to unveil a [refreshed roadmap for Q1 2024](https://wasmcloud.com/docs/v1/roadmap).
 
 {/* truncate */}
 
 In our second post in our Road to 1.0 series, we'll review our revised goals, feature set and the final tasks in the plan to get wasmCloud to 1.0. The fresh roadmap is available on [GitHub Projects](https://github.com/orgs/wasmCloud/projects/7/views/8); this is a snapshot of the current state of the project, and will evolve as the project progresses. In the coming weeks, we'll share a host of new documentation, RFCs and guidance on all things wasmCloud 1.0. In the meantime, let's take a look at how our goals and features have evolved.
 
 ## Goals and Features
 
-Our [Q3/Q4 roadmap](https://wasmcloud.com/docs/roadmap/q3q4) focused heavily on the desire to embrace common Wasm and cloud-native standards, and to make the developer experience a genuine delight. These aspirations stay in focus as we push to release wasmCloud 1.0 and so it won't be a surprise to see our goals remain, largely, unchanged.
+Our [Q3/Q4 roadmap](https://wasmcloud.com/docs/v1/roadmap/q3q4) focused heavily on the desire to embrace common Wasm and cloud-native standards, and to make the developer experience a genuine delight. These aspirations stay in focus as we push to release wasmCloud 1.0 and so it won't be a surprise to see our goals remain, largely, unchanged.
 
 1. A core ongoing tenet of is to **provide a seamless developer experience** for building, testing, and deploying WebAssembly components.
 2. We recognise the importance of being a completely vendor-agnostic development environment and so our goal is to **enable developers to build features without vendor lock-in**, **platform specific dependencies, or language constraints.**
@@ -53,4 +53,4 @@ There are many smaller tasks that are included as well, such as [namespacing our
 
 Because wasmCloud 1.0 will be stable, standards-led and production-ready, it makes sense for us to approach official incubation status within the CNCF. Achieving incubation status shows we align to a standardized process of development, and that we have active contribution from stakeholders in a host of different industries. This is the sign of a project that is seeing healthy growth and cross-community support. Gaining incubation status will allow us to benefit from the CNCF's considerable resources, and get wasmCloud in the hands of more developers. Developers and contributors are, in turn, confident they are using a stable and sustainable platform.
 
-Take a look at the full [roadmap page in docs](https://wasmcloud.com/docs/roadmap) for more detail and practical adjustments we're making to nomenclature and task tracking. Don't forget, also, to join the [wasmCloud community](https://wasmcloud.com/community) meetings every Wednesday at 1pm ET to hear the latest news. We're live every wasmCloud Wednesday on [YouTube](https://www.youtube.com/@wasmCloud/streams), [X](https://twitter.com/wasmcloud), and [LinkedIn](https://www.linkedin.com/company/cosmonic-corp/).
+Take a look at the full [roadmap page in docs](https://wasmcloud.com/docs/v1/roadmap) for more detail and practical adjustments we're making to nomenclature and task tracking. Don't forget, also, to join the [wasmCloud community](https://wasmcloud.com/community) meetings every Wednesday at 1pm ET to hear the latest news. We're live every wasmCloud Wednesday on [YouTube](https://www.youtube.com/@wasmCloud/streams), [X](https://twitter.com/wasmcloud), and [LinkedIn](https://www.linkedin.com/company/cosmonic-corp/).

blog/2024-01-25-wasi-preview-2-officially-launches/index.mdx

@@ -14,7 +14,7 @@ slug: wasi-preview-2-officially-launches
 
 {/* truncate */}
 
-If you look in our [quickstart](https://wasmcloud.com/docs/tour/hello-world) now you'll notice that we now provide documentation for building WebAssembly components, starting with Rust and TinyGo. As seen in previous [community calls](https://wasmcloud.com/community), JavaScript and Python are also supported thanks to the [ComponentizeJS](https://github.com/bytecodealliance/componentizejs/) and [componentize-py](https://github.com/bytecodealliance/componentize-py) projects. I worked on getting examples up-and-running for components, and there are upsides and downsides to the initial approach we're taking. This post will focus on what current component support looks like and what WASI 0.2.0 means for wasmCloud.
+If you look in our [quickstart](https://wasmcloud.com/docs/v1/tour/hello-world) now you'll notice that we now provide documentation for building WebAssembly components, starting with Rust and TinyGo. As seen in previous [community calls](https://wasmcloud.com/community), JavaScript and Python are also supported thanks to the [ComponentizeJS](https://github.com/bytecodealliance/componentizejs/) and [componentize-py](https://github.com/bytecodealliance/componentize-py) projects. I worked on getting examples up-and-running for components, and there are upsides and downsides to the initial approach we're taking. This post will focus on what current component support looks like and what WASI 0.2.0 means for wasmCloud.
 
 ## The Hello World of WASI:HTTP
 

blog/2024-02-21-wasmcloud-0.82-wasi-p2-is-here/index.mdx

@@ -78,4 +78,4 @@ The Docker Compose files are [available on GitHub](https://github.com/wasmCloud/
 
 wasmCloud 1.0 is right around the corner, and the Wasm ecosystem is growing day by day. We couldn't be more excited to see language support expanding, and if we don't have built-in support for your language of choice yet, please let us know what you'd like to see!
 
-If it's been a while since you've created a new project, or if you'd like to learn how to build a component, check out our [Quickstart](https://wasmcloud.com/docs/tour/hello-world)—it's up-to-date with instructions to build components from Go, Rust, Python, and TypeScript. If you run into any speedbumps as you run through the tutorials, or anywhere else in the wasmCloud experience, let us know on the [wasmCloud Slack](https://slack.wasmcloud.com/) or [file an issue on GitHub](https://github.com/wasmCloud/wasmCloud/issues).
+If it's been a while since you've created a new project, or if you'd like to learn how to build a component, check out our [Quickstart](https://wasmcloud.com/docs/v1/tour/hello-world)—it's up-to-date with instructions to build components from Go, Rust, Python, and TypeScript. If you run into any speedbumps as you run through the tutorials, or anywhere else in the wasmCloud experience, let us know on the [wasmCloud Slack](https://slack.wasmcloud.com/) or [file an issue on GitHub](https://github.com/wasmCloud/wasmCloud/issues).

blog/2024-03-20-otel-observable/index.mdx

@@ -38,7 +38,7 @@ Additionally, the default endpoint for HTTP/OpenTelemetry Protocol exports (`loc
 OTEL_EXPORTER_OTLP_ENDPOINT=http://my-custom-host:4318
 ```
 
-Refer to the [wasmCloud documentation](/docs/deployment/observability/observability-with-opentelemetry) for advanced and signal-specific options.
+Refer to the [wasmCloud documentation](/docs/v1/deployment/observability/observability-with-opentelemetry) for advanced and signal-specific options.
 
 ## Explore the wasmCloud observability ecosystem locally
 
@@ -76,7 +76,7 @@ WASMCLOUD_OBSERVABILITY_ENABLED="true" wash up
 
 Now you can access Grafana's "Explore" interface at [http://localhost:5050/explore](http://localhost:5050/explore).
 
-At this point, you may optionally wish to run a hello-world application from the wasmCloud [quickstart](https://wasmcloud.com/docs/tour/hello-world) to give your system a little more activity to observe.
+At this point, you may optionally wish to run a hello-world application from the wasmCloud [quickstart](https://wasmcloud.com/docs/v1/tour/hello-world) to give your system a little more activity to observe.
 
 Select **Tempo** in the left-hand dropdown menu and run a query to view traces.