fix links

Author: colleenmcginnis

docs/configure/site/versions.md

@@ -16,4 +16,4 @@ Versions set in this file are surfaced to the user via `applies_to` tags.
 :::{include} /contribute/_snippets/tag-processing.md
 :::
 
-See [](../../contribute/cumulative-docs.md) for more information.
+See [](/contribute/cumulative-docs/index.md) for more information.

docs/contribute/_snippets/docs-intro.md

@@ -2,4 +2,4 @@ elastic.co/docs uses our new build system, also known as "Docs V3", which uses a
 
 Docs for {{stack}} 9.x, {{ece}} 4.x, and {{eck}} 3.x can all be found on this site. All unversioned products, such as {{ech}} and {{serverless-full}}, are also documented on elastic.co/docs.
 
-This documentation is **cumulative**. This means that a new set of docs is not published for every minor release. Instead, each page stays valid over time and incorporates version-specific changes directly within the content. [Learn how to write cumulative documentation](/contribute/cumulative-docs.md).
+This documentation is **cumulative**. This means that a new set of docs is not published for every minor release. Instead, each page stays valid over time and incorporates version-specific changes directly within the content. [Learn how to write cumulative documentation](/contribute/cumulative-docs/index.md).

docs/contribute/add-repo.md

@@ -17,7 +17,7 @@ The new docs repository needs to satisfy these requirements:
 
 Follow these instructions to add a new repository to the docs.
 
-:::::{stepper}   
+:::::{stepper}
 
 ::::{step} Add the repo to docs-infra
 
@@ -55,7 +55,7 @@ references:
 ```
 
 :::{tip}
-In this file, you can optionally specify custom branches to deploy docs from, depending on your preferred [branching strategy](branching-strategy.md). You might want to change your branching strategy so you can have more control over when content added for a specific release is published.
+In this file, you can optionally specify custom branches to deploy docs from, depending on your preferred [branching strategy](/contribute/branching-strategy.md). You might want to change your branching strategy so you can have more control over when content added for a specific release is published.
 :::
 
 Then, edit the [`navigation.yml`](https://github.com/elastic/docs-builder/blob/main/config/navigation.yml) file to add the repository to the navigation. Refer to [navigation.yml](../configure/site/navigation.md) for more information.
@@ -98,5 +98,5 @@ For example, to add version 13.5 of yadda-docs:
 For a more comfortable local `docs-builder` experience, add the following line to the `.gitignore` file of the repo:
 
 ```
-docs/.artifacts 
+docs/.artifacts
 ```

docs/contribute/branching-strategy.md

@@ -4,30 +4,30 @@ navigation_title: Choose a branching strategy
 
 # Choose the docs branching strategy for a repository
 
-With Docs V3 (elastic.co/docs), a single branch is published per repository. This branch is set to `main` by default. This is known as the continuous deployment branching strategy. However, it is possible to instead publish a different branch, also known as the tagged branching strategy. 
+With Docs V3 (elastic.co/docs), a single branch is published per repository. This branch is set to `main` by default. This is known as the continuous deployment branching strategy. However, it is possible to instead publish a different branch, also known as the tagged branching strategy.
 
 On this page, you'll learn how to choose the right branching strategy for your repository, and how to change the branching strategy. You'll also learn about the workflows for working with each branching strategy.
 
 ## Why is `main` the default publication branch?
 
 The main reasons for this choice are:
 
-* With Docs V3, there is no longer a different version of each page for each minor release. Instead, the same page [covers all versions](cumulative-docs.md), and any changes are indicated throughout the content.  
+* With Docs V3, there is no longer a different version of each page for each minor release. Instead, the same page [covers all versions](/contribute/cumulative-docs/index.md), and any changes are indicated throughout the content.
 * More and more products are released from `main` branches, making these branches the most up to date at any given time. This is especially true for {{serverless-full}} and {{ecloud}}.
 
- 
+
 ## Why would we want to publish a different branch instead?
 
 Publishing from the main branch isn’t the best option for all repositories.
 
-* `main` can contain code and docs for unreleased versions that we don’t want to publish yet.  
+* `main` can contain code and docs for unreleased versions that we don’t want to publish yet.
 * The versioning scheme and release cadence of the product associated with a repository can vary, and it can be inconsistent to have the docs associated with a certain version live in a different branch than the code.
 
 If you choose this publication model for your repository AND that repository includes {{serverless-short}} or {{ecloud}} documentation, you will need to make sure that {{serverless-short}}- and {{ecloud}}-related changes are also backported to the branch that is publishing to the public docs site.
 
-You **don't** need to change your branching strategy to enable writing docs about future versions. Review the [continuous deployment workflow](#workflow-1-default-continuous-deployment) and [](cumulative-docs.md) to learn more.
+You **don't** need to change your branching strategy to enable writing docs about future versions. Review the [continuous deployment workflow](#workflow-1-default-continuous-deployment) and [](/contribute/cumulative-docs/index.md) to learn more.
 
-Note that regardless of the publication branch that is set, the documentation must still flag all changes introduced so far since the last major release. This is NOT an alternative to [writing docs cumulatively](cumulative-docs.md).
+Note that regardless of the publication branch that is set, the documentation must still flag all changes introduced so far since the last major release. This is NOT an alternative to [writing docs cumulatively](/contribute/cumulative-docs/index.md).
 
 ## How to change the published branch
 
@@ -39,10 +39,10 @@ After it has been established that a repository should publish from a version br
 
 1. [Add new triggers to the `docs-build` CI integration](/configure/content-sources.md#ci-configuration). Merge these changes to `main` or `master` and the intended version branches.
 2. Open a PR to trigger the CI integration and confirm that the docs build.
-3. Open a PR updating the [`assembler.yml`](https://github.com/elastic/docs-builder/blob/main/config/assembler.yml):  
-   * Specify which is the `current` branch for the repository. This branch is the branch from which docs are deployed to production at [elastic.co/docs](http://elastic.co/docs).  
-   * Specify which is the `next` branch for the repository. The branch defined as `next` publishes docs internally to [staging-website.elastic.co/docs](http://staging-website.elastic.co/docs)  
-     * Setting this branch to the next version branch in line is a good practice to preview docs change for an upcoming version.  
+3. Open a PR updating the [`assembler.yml`](https://github.com/elastic/docs-builder/blob/main/config/assembler.yml):
+   * Specify which is the `current` branch for the repository. This branch is the branch from which docs are deployed to production at [elastic.co/docs](http://elastic.co/docs).
+   * Specify which is the `next` branch for the repository. The branch defined as `next` publishes docs internally to [staging-website.elastic.co/docs](http://staging-website.elastic.co/docs)
+     * Setting this branch to the next version branch in line is a good practice to preview docs change for an upcoming version.
      * Otherwise, keeping it set to `main` is also an option since this is where the content is initially developed and merged. This is the default.
 4. In the assembler PR, add the `ci` label. After CI runs, confirm that the intended version branches are publishing to the link service. When links are being published as intended, they can be found at the following URL, where `repo` is your repo name and `branch` is your newly configured branch:
 
@@ -58,12 +58,12 @@ After these steps are completed, the docs engineering team needs to release a ne
 
 When you publish from specific version branches, you need to bump the version branch as part of the release process.
 
-Add an action as part of that repo’s release process for the release manager to update this same assembler file and bump the `current` branch with each release, as appropriate. The `next` branch also needs to be bumped if it is not set to `main`. 
+Add an action as part of that repo’s release process for the release manager to update this same assembler file and bump the `current` branch with each release, as appropriate. The `next` branch also needs to be bumped if it is not set to `main`.
 
 When these releases happen, create a PR against the [`assembler.yml`](https://github.com/elastic/docs-builder/blob/main/config/assembler.yml) that defines the new `current` branch, to merge on release day.
 
 :::{tip}
-Regardless of the branching strategy, you also need to update the current version in [`versions.yml`](https://github.com/elastic/docs-builder/blob/main/config/versions.yml) as part of your release process. This version number is used in documentation variables and drives our [dynamic version badge logic](/contribute/cumulative-docs.md#how-do-these-tags-behave-in-the-output).
+Regardless of the branching strategy, you also need to update the current version in [`versions.yml`](https://github.com/elastic/docs-builder/blob/main/config/versions.yml) as part of your release process. This version number is used in documentation variables and drives our [dynamic version badge logic](/contribute/cumulative-docs/index.md#how-do-these-tags-behave-in-the-output).
 :::
 
 
@@ -77,7 +77,7 @@ Initiate the changes by opening a PR against the `main` branch of the repo.
 
 ### How to write those changes [write-changes-cd]
 
-In elastic.co/docs (Docs V3), we [write docs cumulatively](cumulative-docs.md) regardless of the branching strategy selected.
+In elastic.co/docs (Docs V3), we [write docs cumulatively](/contribute/cumulative-docs/index.md) regardless of the branching strategy selected.
 
 ### Merging and backporting [merge-backport-cd]
 
@@ -86,8 +86,8 @@ When a repo publishes docs from its `main` branch, any merged changes are publis
 | | Case | Approach |
 | --- | --- | --- |
 | 1 | You are documenting changes for an unversioned product (typically Serverless or Elastic Cloud), and the changes should only go live when the corresponding code or feature is available to users. | The PR should be merged on or after the release date of the feature. |
-| 2 | You are documenting changes for a versioned product (any Stack components, ECE, ECK, etc.). | You have the choice between merging the PR as soon as it is approved, or merging it only on release day.<br><br>We have an automatic mechanism in place as part of the [cumulative docs strategy](cumulative-docs.md) that will show any changes published before its associated code or feature is available as `Planned`. |
-| 3 | You are documenting changes that apply to both versioned and unversioned products (typically a change that is being released for both Serverless and an upcoming Stack release). | The PR should only be merged on or after the release date of the feature in Serverless.<br><br>For versioned products, we have an automatic mechanism in place as part of the [cumulative docs strategy](cumulative-docs.md) that will show any changes published before its associated code or feature is available as `Planned`. |
+| 2 | You are documenting changes for a versioned product (any Stack components, ECE, ECK, etc.). | You have the choice between merging the PR as soon as it is approved, or merging it only on release day.<br><br>We have an automatic mechanism in place as part of the [cumulative docs strategy](/contribute/cumulative-docs/index.md) that will show any changes published before its associated code or feature is available as `Planned`. |
+| 3 | You are documenting changes that apply to both versioned and unversioned products (typically a change that is being released for both Serverless and an upcoming Stack release). | The PR should only be merged on or after the release date of the feature in Serverless.<br><br>For versioned products, we have an automatic mechanism in place as part of the [cumulative docs strategy](/contribute/cumulative-docs/index.md) that will show any changes published before its associated code or feature is available as `Planned`. |
 
 When a repo is publishing docs from its `main` branch, no backporting is needed.
 
@@ -97,15 +97,15 @@ If you don’t want to hold on too many PRs to publish on release day, merge the
 
 ## Workflow 2: Tagged
 
-Learn how to make updates in the continuous deployment branching strategy, where the repo is publishing docs from a specific version branch. 
+Learn how to make updates in the continuous deployment branching strategy, where the repo is publishing docs from a specific version branch.
 
 ### Where to make docs changes [make-changes-td]
 
 Initiate the changes by opening a PR against the `main` branch of the repo, and backport the changes to the relevant version branches as detailed below.
 
 ### How to write those changes [write-changes-td]
 
-In elastic.co/docs (Docs V3), we [write docs cumulatively](cumulative-docs.md) regardless of the branching strategy selected.
+In elastic.co/docs (Docs V3), we [write docs cumulatively](/contribute/cumulative-docs/index.md) regardless of the branching strategy selected.
 
 ### Merging and backporting [merge-backport-td]
 
@@ -116,19 +116,19 @@ The changes must then be backported to their relevant version branches, and no f
 | | Case | Approach |
 | --- | --- | --- |
 | 1 | You are documenting changes for an unversioned product (typically Serverless or Elastic Cloud), the changes should go live when the corresponding code or feature is available to users. | The PR should be backported to the docs `current` branch, and any intermediate version branches that already exist between `current` and `main`. Merge the backport PR for `current` only when you’re sure the corresponding feature is released. |
-| 2 | You are documenting changes for a versioned product (any Stack components, ECE, ECK, etc.). | Backport the PR to the relevant version branch and to any intermediate version branch that already exists. The changes will go live whenever these branches become the `current` docs branch.<br><br>We have an automatic mechanism in place as part of the [cumulative docs strategy](cumulative-docs.md) that will show any changes published before its associated code or feature is available as `Planned`. |
-| 3 | You are documenting changes that apply to both versioned and unversioned products (typically a change that is being released for both Serverless and an upcoming Stack release). | The PR should be backported to the docs `current` branch, and any intermediate version branches that already exist between `current` and `main`. Merge the backport PR for `current` only when you’re sure the corresponding feature is released. <br><br>For versioned products, we have an automatic mechanism in place as part of the [cumulative docs strategy](cumulative-docs.md) that will show any changes published before its associated code or feature is available as `Planned`. |
+| 2 | You are documenting changes for a versioned product (any Stack components, ECE, ECK, etc.). | Backport the PR to the relevant version branch and to any intermediate version branch that already exists. The changes will go live whenever these branches become the `current` docs branch.<br><br>We have an automatic mechanism in place as part of the [cumulative docs strategy](/contribute/cumulative-docs/index.md) that will show any changes published before its associated code or feature is available as `Planned`. |
+| 3 | You are documenting changes that apply to both versioned and unversioned products (typically a change that is being released for both Serverless and an upcoming Stack release). | The PR should be backported to the docs `current` branch, and any intermediate version branches that already exist between `current` and `main`. Merge the backport PR for `current` only when you’re sure the corresponding feature is released. <br><br>For versioned products, we have an automatic mechanism in place as part of the [cumulative docs strategy](/contribute/cumulative-docs/index.md) that will show any changes published before its associated code or feature is available as `Planned`. |
 
 #### Example [example-td]
 
 For example, in a situation where 9.0, 9.1, and 9.2 are already released, and the 9.3 branch has already been cut:
 
-* The branch set as `current` in the [`assembler.yml`](https://github.com/elastic/docs-builder/blob/main/config/assembler.yml) is 9.2.  
-* The branch set as `next` (where the content development first happens), is `main`.  
-* 9.4 changes are only done on the `main` branch.  
-* 9.3 changes are done on the `main` branch and backported to the 9.3 branch.  
-* 9.1 changes are done on the `main` branch and backported to the 9.3 and 9.2 branches. Since 9.2 is the current docs branch, no need to go further.  
-* Serverless changes are done on the `main` branch. They are backported to the `current` docs branch and any intermediate branches. In this case: 9.3 and 9.2.  
+* The branch set as `current` in the [`assembler.yml`](https://github.com/elastic/docs-builder/blob/main/config/assembler.yml) is 9.2.
+* The branch set as `next` (where the content development first happens), is `main`.
+* 9.4 changes are only done on the `main` branch.
+* 9.3 changes are done on the `main` branch and backported to the 9.3 branch.
+* 9.1 changes are done on the `main` branch and backported to the 9.3 and 9.2 branches. Since 9.2 is the current docs branch, no need to go further.
+* Serverless changes are done on the `main` branch. They are backported to the `current` docs branch and any intermediate branches. In this case: 9.3 and 9.2.
 * Changes not specific to a version are done on the `main` branch and backported to all branches down to the `current` docs branch. In this case: 9.3 and 9.2.
 
 :::{note}

docs/contribute/cumulative-docs/best-practices.md

@@ -14,7 +14,7 @@ Depending on what you're trying to communicate, you can use the following patter
   Instead, contributors should be able to add them anywhere they need, and the system should
   be in charge of rendering them clearly.
 
-* Always put the newest version first when [listing multiple versions]().
+* Always put the newest version first when listing multiple versions.
 
 % Reference: https://github.com/elastic/kibana/pull/229485/files#r2231876006
 * Avoid using version numbers in prose adjacent to `applies_to` badge to prevent

docs/contribute/cumulative-docs/index.md

@@ -4,7 +4,7 @@
 This page explains our cumulative documentation philosophy, paired with examples. Component guidance for reference purposes goes in syntax/applies.md.
 -->
 
-In elastic.co/docs (Docs V3), we write docs cumulatively regardless of the [branching strategy](branching-strategy.md) selected.
+In elastic.co/docs (Docs V3), we write docs cumulatively regardless of the [branching strategy](/contribute/branching-strategy.md) selected.
 
 **What does this mean?**
 
@@ -123,7 +123,7 @@ For this case, no specific version tagging is necessary.
 **A new feature is added to {{serverless-short}} or {{ecloud}}. How do I tag it?**
 Cumulative documentation is not meant to replace release notes. If a feature becomes available in {{serverless-short}} and doesn’t have a particular lifecycle state to call out (preview, beta, deprecated…), it does not need specific tagging.
 
-However, in this scenario, it is important to consider carefully [when the change is going to be published](branching-strategy.md).
+However, in this scenario, it is important to consider carefully [when the change is going to be published](/contribute/branching-strategy.md).
 
 We do not do date-based tagging for unversioned products.