Fix broken links

Natalie Arellano · Natalie Arellano · commit f5dd2990c056 · 2024-02-13T15:14:06.000-05:00
Signed-off-by: Natalie Arellano &lt;narellano@vmware.com&gt;
diff --git a/content/docs/_index.md b/content/docs/_index.md
@@ -23,17 +23,17 @@ Learn the [concepts](/docs/concepts) of Cloud Native Buildpacks.
 
 Set of guides tailored to specific personas:
 
-*  [App Developers](/docs/app-developer-guide/)
-*  [Buildpack Authors](/docs/buildpack-author-guide/)
+*  [App Developers](/docs/for-app-developers/)
+*  [Buildpack Authors](/docs/for-buildpack-authors/)
 *  [Operators](/docs/for-platform-operators/)
 
-## [Tools](/docs/tools/)
+## [Tools](/docs/for-platform-operators/)
 
-* **[CircleCI](/docs/tools/circleci)** - {{< summary "/docs/tools/circleci" >}}
-* **[GitLab](/docs/tools/gitlab)** - {{< summary "/docs/tools/gitlab" >}}
-* **[kpack](/docs/tools/kpack)** - {{< summary "/docs/tools/kpack" >}}
-* **[Pack](/docs/tools/pack)** - {{< summary "/docs/tools/pack" >}}
-* **[Tekton](/docs/tools/tekton)** - {{< summary "/docs/tools/tekton" >}}
+* **[CircleCI](/docs/for-platform-operators/how-to/integrate-ci/circleci)** - {{< summary "/docs/for-platform-operators/how-to/integrate-ci/circleci" >}}
+* **[GitLab](/docs/for-platform-operators/how-to/integrate-ci/gitlab)** - {{< summary "/docs/for-platform-operators/how-to/integrate-ci/gitlab" >}}
+* **[kpack](/docs/for-platform-operators/how-to/integrate-ci/kpack)** - {{< summary "/docs/for-platform-operators/how-to/integrate-ci/kpack" >}}
+* **[Pack](/docs/for-platform-operators/how-to/integrate-ci/pack)** - {{< summary "/docs/for-platform-operators/how-to/integrate-ci/pack" >}}
+* **[Tekton](/docs/for-platform-operators/how-to/integrate-ci/tekton)** - {{< summary "/docs/for-platform-operators/how-to/integrate-ci/tekton" >}}
 
 ## [Reference](/docs/reference/)
 
diff --git a/content/docs/app-journey.md b/content/docs/app-journey.md
@@ -99,7 +99,7 @@ deploying your new image to your favorite cloud!
 
 Windows image builds are now supported!
 
-<a href="/docs/app-developer-guide/build-a-windows-app" class="button bg-blue">Windows build guide</a>
+<a href="/docs/for-app-developers/how-to/configure-build/build-for-windows" class="button bg-blue">Windows build guide</a>
 
 [builder]: /docs/concepts/components/builder/
 [buildpack]: /docs/concepts/components/buildpack/
diff --git a/content/docs/buildpack-author-guide/create-buildpack/adding-bill-of-materials.md b/content/docs/buildpack-author-guide/create-buildpack/adding-bill-of-materials.md
@@ -217,4 +217,4 @@ Now that you've finished your buildpack, how about extending it? Try:
 - Caching the downloaded NodeJS version
 - [Packaging your buildpack for distribution][package-a-buildpack]
 
-[package-a-buildpack]: /docs/buildpack-author-guide/package-a-buildpack/
+[package-a-buildpack]: /docs/for-buildpack-authors/how-to/distribute-buildpacks/package-buildpack/
diff --git a/content/docs/concepts/components/buildpack.md b/content/docs/concepts/components/buildpack.md
@@ -45,5 +45,5 @@ Learn more about buildpacks by referring to the [Buildpack API][buildpack-api].
 
 [buildpack-api]: /docs/reference/buildpack-api
 [buildpack-group]: /docs/concepts/components/buildpack-group/
-[package-a-buildpack]: /docs/buildpack-author-guide/package-a-buildpack/
+[package-a-buildpack]: /docs/for-buildpack-authors/how-to/distribute-buildpacks/package-buildpack/
 [platform]: /docs/concepts/components/platform
diff --git a/content/docs/concepts/components/lifecycle/analyze.md b/content/docs/concepts/components/lifecycle/analyze.md
@@ -21,4 +21,4 @@ For more information, please see [this migration guide][platform-api-06-07-migra
 | `1-10`, `13-19` | Generic lifecycle errors
 | `30-39`         | Analysis-specific lifecycle errors
 
-[platform-api-06-07-migration]: https://buildpacks.io/docs/reference/spec/migration/platform-api-0.6-0.7/
+[platform-api-06-07-migration]: https://buildpacks.io/docs/for-platform-operators/how-to/migrate/platform-api-0.6-0.7/
diff --git a/content/docs/concepts/components/stack.md b/content/docs/concepts/components/stack.md
@@ -13,8 +13,8 @@ A stack (deprecated) is the grouping together of the build and run base images,
 As of Platform API 0.12 and Buildpack API 0.10, stacks are deprecated in favor of existing constructs in the container image ecosystem such as operating system name, operating system distribution, and architecture.
 
 For more information, see
-* Platform API 0.12 [migration guide](/docs/reference/spec/migration/platform-api-0.11-0.12/)
-* Buildpack API 0.10 [migration guide](/docs/reference/spec/migration/buildpack-api-0.9-0.10/)
+* Platform API 0.12 [migration guide](/docs/for-platform-operators/how-to/migrate/platform-api-0.11-0.12/)
+* Buildpack API 0.10 [migration guide](/docs/for-buildpack-authors/how-to/migrate/buildpack-api-0.9-0.10/)
 * [Build image](/docs/concepts/components/base-images/build/) concept
 * [Run image](/docs/concepts/components/base-images/run/) concept
 * [Target data](/docs/concepts/components/targets/)
diff --git a/content/docs/concepts/operations/rebase.md b/content/docs/concepts/operations/rebase.md
@@ -30,4 +30,4 @@ $ pack rebase my-app:my-tag
 > **TIP:** `pack rebase` has a `--publish` flag that can be used to publish the updated app image directly to a registry. 
 > Using `--publish` is optimal when using a registry in comparison to the docker daemon.
 
-[build]: /docs/app-developer-guide/build-an-app/
+[build]: /docs/for-app-developers/tutorials/build-basic-app/
diff --git a/content/docs/for-app-developers/how-to/build-inputs/specify-buildpacks-from-cli.md b/content/docs/for-app-developers/how-to/build-inputs/specify-buildpacks-from-cli.md
@@ -110,5 +110,5 @@ A buildpack located in a CNB Registry
 <small><sup>†</sup> Directory buildpacks are not currently supported on Windows.</small><br />
 <small><sup>‡</sup> Version may be omitted if there is only one buildpack in the builder matching the `id`.</small>
 
-[project-toml]: /docs/app-developer-guide/using-project-descriptor/
+[project-toml]: /docs/for-app-developers/how-to/build-inputs/use-project-toml/
 [samples]: https://github.com/buildpacks/samples
diff --git a/content/docs/for-app-developers/how-to/build-inputs/use-inline-buildpacks.md b/content/docs/for-app-developers/how-to/build-inputs/use-inline-buildpacks.md
@@ -54,6 +54,6 @@ EOF
 ### Further Reading
 For more about project descriptors, look at the [schema][descriptor-schema], as well as the [specification][spec].
 
-[project-toml]: /docs/app-developer-guide/using-project-descriptor/
+[project-toml]: /docs/for-app-developers/how-to/build-inputs/use-project-toml/
 [descriptor-schema]: /docs/reference/project-descriptor/
 [spec]: https://github.com/buildpacks/spec/blob/main/extensions/project-descriptor.md
diff --git a/content/docs/for-app-developers/how-to/build-inputs/use-project-toml.md b/content/docs/for-app-developers/how-to/build-inputs/use-project-toml.md
@@ -106,8 +106,8 @@ docker run sample-app
 ### Further Reading
 For more about project descriptors, look at the [schema][descriptor-schema], as well as the [specification][spec].
 
-[specify-buildpacks]: /docs/app-developer-guide/specify-buildpacks/
-[descriptor-envs]: /docs/app-developer-guide/environment-variables/#using-project-descriptor
+[specify-buildpacks]: /docs/for-app-developers/how-to/build-inputs/specify-buildpacks-from-cli
+[descriptor-envs]: /docs/for-app-developers/how-to/build-inputs/configure-build-time-environment/#using-project-descriptor
 [descriptor-schema]: /docs/reference/project-descriptor/
 [samples]: https://github.com/buildpacks/samples
 [spec]: https://github.com/buildpacks/spec/blob/main/extensions/project-descriptor.md
diff --git a/content/docs/for-app-developers/how-to/configure-build/build-for-windows.md b/content/docs/for-app-developers/how-to/configure-build/build-for-windows.md
@@ -129,7 +129,7 @@ curl http://10.0.0.1:8080
 [container-mode]: https://docs.docker.com/desktop/faqs/windowsfaqs/#how-do-i-switch-between-windows-and-linux-containers
 [docker-env-vars]: https://docs.docker.com/engine/reference/commandline/cli/#environment-variables
 [docker-hosts]: #understanding-docker-hosts
-[build-linux]: /docs/app-developer-guide/build-an-app
+[build-linux]: /docs/for-app-developers/tutorials/build-basic-app
 [build]: /docs/concepts/operations/build
 [builder]: /docs/concepts/components/builder
 [buildpack]: /docs/concepts/components/buildpack
diff --git a/content/docs/for-app-developers/how-to/configure-build/export-to-oci-layout.md b/content/docs/for-app-developers/how-to/configure-build/export-to-oci-layout.md
@@ -39,7 +39,7 @@ to save images requires by `pack build` command in OCI layout format.
 
 ### 2. Build the app
 
-Please first follow the steps to [build an app](/docs/app-developer-guide/build-an-app), once you have successfully built an application you can export the sample application to disk in OCI layout format. 
+Please first follow the steps to [build an app](/docs/for-app-developers/tutorials/build-basic-app), once you have successfully built an application you can export the sample application to disk in OCI layout format. 
 
 The OCI layout feature must be enabled using the convention `oci:<path/to/save/image>` in the `<image-name>` parameter when invoking `pack build`.
 
diff --git a/content/docs/for-app-developers/tutorials/build-basic-app/build.md b/content/docs/for-app-developers/tutorials/build-basic-app/build.md
@@ -67,21 +67,21 @@ The app should now be running and accessible via [localhost:8080](http://localho
 Linux ARM image builds are now supported!
 
 <!--+- if false+-->
-<a href="/docs/app-developer-guide/build-an-arm-app" class="button bg-blue">Linux ARM build guide</a>
+<a href="/docs/for-app-developers/how-to/configure-build/build-for-arm" class="button bg-blue">Linux ARM build guide</a>
 <!--+end+-->
 
 <!--+ `
-Check out the [Linux ARM build guide](https://buildpacks.io//docs/app-developer-guide/build-an-arm-app).
+Check out the [Linux ARM build guide](https://buildpacks.io//docs/for-app-developers/how-to/configure-build/build-for-arm).
 ` +-->
 ## What about Windows apps?
 
 Windows image builds are now supported!
 
 <!--+- if false+-->
-<a href="/docs/app-developer-guide/build-a-windows-app" class="button bg-blue">Windows build guide</a>
+<a href="/docs/for-app-developers/how-to/configure-build/build-for-windows" class="button bg-blue">Windows build guide</a>
 <!--+end+-->
 <!--+ `
-Check out the [Windows build guide](https://buildpacks.io/docs/app-developer-guide/build-a-windows-app/).
+Check out the [Windows build guide](https://buildpacks.io/docs/for-app-developers/how-to/configure-build/build-for-windows/).
 ` +-->
 
 [build]: /docs/concepts/operations/build
diff --git a/content/docs/for-buildpack-authors/how-to/distribute-buildpacks/publish-buildpack/_index.md b/content/docs/for-buildpack-authors/how-to/distribute-buildpacks/publish-buildpack/_index.md
@@ -39,4 +39,4 @@ Click _Submit new issue_, and your request will be processed within seconds. If
 >
 > If you try to publish a buildpack with a namespace that's already in use, the request will fail and the GitHub issue will be closed. You can add or change namespace owners by submitting a Pull Request to the [buildpacks/registry-namespaces](https://github.com/buildpacks/registry-namespaces/).
 
-[package]: /docs/buildpack-author-guide/package-a-buildpack/
+[package]: /docs/for-buildpack-authors/how-to/distribute-buildpacks/package-buildpack
diff --git a/content/docs/for-buildpack-authors/how-to/distribute-buildpacks/publish-buildpack/with-github-actions.md b/content/docs/for-buildpack-authors/how-to/distribute-buildpacks/publish-buildpack/with-github-actions.md
@@ -85,7 +85,7 @@ It is possible to perform these same step on any automated CI platform, but the
 
 You may store your buildpack image in any standard OCI registry, such as [Docker Hub][docker-hub], [Google Container Registry][gcr], or [GitHub Container Registry][ghcr]. However, [GitHub Packages][github-packages] are not supported as they provide a non-standard implementation of the OCI Registry specification.
 
-[package]: /docs/buildpack-author-guide/package-a-buildpack/
+[package]: /docs/for-buildpack-authors/how-to/distribute-buildpacks/package-buildpack
 [github-actions]: https://github.com/buildpacks/github-actions
 [docker-hub]: https://hub.docker.com/
 [gcr]: https://cloud.google.com/container-registry/
diff --git a/content/docs/for-buildpack-authors/how-to/migrate/buildpack-api-0.8-0.9.md b/content/docs/for-buildpack-authors/how-to/migrate/buildpack-api-0.8-0.9.md
@@ -21,12 +21,14 @@ Buildpack processes can still use a shell! However, the `command` must now expli
 
 Hand-in-hand with shell removal is the introduction of overridable process arguments.
 
-In `launch.toml`, `command` is now a list. The first element in `command` is the command, and all following entries are arguments that are always provided to the process, regardless of how the application is started. The `args` list now designates arguments that can be overridden by the end user - if supported by the platform (Platform API version 0.10 and above). For further details, see the platform [migration guide](/docs/reference/spec/migration/platform-api-0.9-0.10).
+In `launch.toml`, `command` is now a list. The first element in `command` is the command, and all following entries are arguments that are always provided to the process, regardless of how the application is started. The `args` list now designates arguments that can be overridden by the end user - if supported by the platform (Platform API version 0.10 and above).
+
+For further details, see the platform [migration guide](/docs/for-platform-operators/how-to/migrate/platform-api-0.9-0.10).
 
 For older platforms (Platform API version 0.9 and below), arguments in `command` will be prepended to arguments in `args`, negating the new functionality (but preserving compatibility).
 
 ### Image extensions are supported (experimental)
 
-Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see [here](/docs/features/dockerfiles) for more information).
+Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see [here](/docs/for-platform-operators/concepts/dockerfiles) for more information).
 
-For more information, see [authoring an image extension](/docs/extension-guide/create-extension).
+For more information, see our tutorial on [authoring an image extension](/docs/for-buildpack-authors/tutorials/write-basic-extension).
diff --git a/content/docs/for-buildpack-authors/how-to/migrate/buildpack-api-0.9-0.10.md b/content/docs/for-buildpack-authors/how-to/migrate/buildpack-api-0.9-0.10.md
@@ -53,4 +53,4 @@ Buildpacks can use this information to modify their behavior depending on the ta
 
 In Platform 0.12, extensions can be used to extend not only build-time base images, but runtime base images as well.
 
-For more information, see [authoring an image extension](/docs/extension-guide/create-extension).
+For more information, see [authoring an image extension](/docs/for-buildpack-authors/tutorials/write-basic-extension).
diff --git a/content/docs/for-buildpack-authors/tutorials/write-basic-extension/building-blocks-extension.md b/content/docs/for-buildpack-authors/tutorials/write-basic-extension/building-blocks-extension.md
@@ -40,7 +40,7 @@ You should see something akin to the following:
     for further details.
 
 We'll take a closer look at the executables for the `vim` extension in the next step.
-For guidance around writing extensions and more advanced use cases, see [here](/docs/extension-guide/create-extension/advanced-extensions).
+For guidance around writing extensions and more advanced use cases, see [here](/docs/for-buildpack-authors/how-to/write-extensions).
 
 <!--+ if false+-->
 ---
diff --git a/content/docs/for-platform-operators/concepts/dockerfiles.md b/content/docs/for-platform-operators/concepts/dockerfiles.md
@@ -62,7 +62,7 @@ An image extension could be defined with the following directory:
   outputs either or both of `build.Dockerfile` or `run.Dockerfile` for extending the builder or run image.
 
 For more information and to see a build in action,
-see [authoring an image extension](/docs/extension-guide/create-extension).
+see [authoring an image extension](/docs/for-buildpack-authors/tutorials/write-basic-extension).
 
 ## A platform's perspective
 
@@ -93,7 +93,7 @@ The ordering of lifecycle phases looks like the following:
 * `build`
 * `export`
 
-For more information, consult the [migration guide](/docs/reference/spec/migration/platform-api-0.9-0.10).
+For more information, consult the [migration guide](/docs/for-platform-operators/how-to/migrate/platform-api-0.9-0.10).
 
 #### Platform support for Dockerfiles
 
diff --git a/content/docs/for-platform-operators/how-to/integrate-ci/pack/_index.md b/content/docs/for-platform-operators/how-to/integrate-ci/pack/_index.md
@@ -58,7 +58,7 @@ To configure your `zsh` shell to load completions for each session, add the foll
 
 ### References
 
-- [Docs](/docs/tools/pack/cli/pack/)
+- [Docs](/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack/)
 - [Source](https://github.com/buildpacks/pack/)
 
 ---
diff --git a/content/docs/for-platform-operators/how-to/integrate-ci/pack/concepts/trusted_builders.md b/content/docs/for-platform-operators/how-to/integrate-ci/pack/concepts/trusted_builders.md
@@ -21,16 +21,16 @@ When `pack` trusts a builder `pack build` will run a single lifecycle binary whi
 If `pack` were to use the `creator` lifecycle phase with an untrusted builder, each of the buildpack's `bin/detect` and `bin/build` processes would run within a container that has heightened privileges or access to registry credentials. The buildpacks distributed with the untrusted builder could be constructed to act maliciously with these privileges or credentials.
 
 ## Which Builders are trusted?
-You may view which builders are trusted via  [`pack config trusted-builders list`](/docs/tools/pack/cli/pack_config_trusted-builders_list/).
+You may view which builders are trusted via  [`pack config trusted-builders list`](/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack_config_trusted-builders_list/).
 
 Here are some other related commands:
 
-* By default, any builder suggested by  [`pack builder suggest`](/docs/tools/pack/cli/pack_builder_suggest/) is considered trusted.
-* Any other builder can be trusted using  [`pack config trusted-builders add <builder-name>`](/docs/tools/pack/cli/pack_config_trusted-builders_add/).
+* By default, any builder suggested by  [`pack builder suggest`](/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack_builder_suggest/) is considered trusted.
+* Any other builder can be trusted using  [`pack config trusted-builders add <builder-name>`](/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack_config_trusted-builders_add/).
 
-* To stop trusting a builder use [`pack config trusted-builders remove <builder-name`](/docs/tools/pack/cli/pack_config_trusted-builders_remove/).
+* To stop trusting a builder use [`pack config trusted-builders remove <builder-name`](/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack_config_trusted-builders_remove/).
 
-* You may trust any builder for the duration of a single build by using the `--trust-builder` flag with [`pack build`](/docs/tools/pack/cli/pack_build/).
+* You may trust any builder for the duration of a single build by using the `--trust-builder` flag with [`pack build`](/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack_build/).
 
 > **Note:** A published lifecycle image is available for lifecycle versions 0.7.5+ and 0.6.1. If your builder has been created with an earlier version of the lifecycle `pack build` will **fail** due to this security related change.
 ><br/>
diff --git a/content/docs/for-platform-operators/how-to/migrate/deprecated/platform-api-0.3-0.4.md b/content/docs/for-platform-operators/how-to/migrate/deprecated/platform-api-0.3-0.4.md
@@ -11,13 +11,13 @@ See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%
 
 ### Windows support
 
-Windows image builds are now supported! See the [Windows build guide](/docs/app-developer-guide/build-a-windows-app)
+Windows image builds are now supported! See the [Windows build guide](/docs/for-app-developers/how-to/configure-build/build-for-windows)
 for more details.
 
 ### Multicall launcher
 
 When running the exported application image, it is now possible to provide arguments to pre-defined process types. 
-The new flow is described [here](/docs/app-developer-guide/run-an-app/#run-a-multi-process-app).
+The new flow is described [here](/docs/for-app-developers/tutorials/build-basic-app/run/#run-a-multi-process-app).
 As part of these changes, the exporter will not set, and the launcher no longer accepts, the `CNB_PROCESS_TYPE` variable.
 See the associated [RFC](https://github.com/buildpacks/rfcs/blob/main/text/0045-launcher-arguments.md) and [spec PR](https://github.com/buildpacks/spec/pull/118)
 for more details.
diff --git a/content/docs/for-platform-operators/how-to/migrate/platform-api-0.11-0.12.md b/content/docs/for-platform-operators/how-to/migrate/platform-api-0.11-0.12.md
@@ -67,7 +67,7 @@ To use the feature, platforms should:
 * Invoke `restorer` with the `-dameon` flag (newly added in this Platform API version) if the export target is a daemon
   * When extensions switch the run image, the `restorer` must re-read target data from the new run image in order to provide this information to buildpacks; if `-daemon` is provided the `restorer` will look for the run image in a daemon instead of a registry
   * When extensions extend the run image, the `-daemon` flag has no effect as the `restorer` must be able to pull the run image manifest from a registry
-* Invoke `extender` as usual to extend the builder image (see [migration guide](/docs/reference/spec/migration/platform-api-0.9-0.10/index.html) for Platform 0.10)
+* Invoke `extender` as usual to extend the builder image (see [migration guide](/docs/for-platform-operators/how-to/migrate/platform-api-0.9-0.10/index.html) for Platform 0.10)
 * Inspect the contents of `analyzed.toml` - if `run-image.extend` is `true` we must run the `extender` on the run image
 * Using the **run image** as the basis for the container, invoke `extender` with flags `-kind run` and `-extended <extended dir>`
   * `<extended dir>` is the directory where layers created from the application of each `run.Dockerfile` to the run image will be saved for use by the `exporter`; it defaults to `<layers>/extended`
diff --git a/content/docs/for-platform-operators/how-to/migrate/platform-api-0.9-0.10.md b/content/docs/for-platform-operators/how-to/migrate/platform-api-0.9-0.10.md
@@ -81,7 +81,7 @@ For processes from older buildpacks, upgrading the platform will not change the
 
 ### Image extensions are supported (experimental)
 
-Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see [here](/docs/features/dockerfiles) for more information). Image extensions output Dockerfiles which are applied by the lifecycle using [kaniko][https://github.com/GoogleContainerTools/kaniko], a tool for building container images in Kubernetes, as a library.
+Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see [here](/docs/for-platform-operators/concepts/dockerfiles) for more information). Image extensions output Dockerfiles which are applied by the lifecycle using [kaniko][https://github.com/GoogleContainerTools/kaniko], a tool for building container images in Kubernetes, as a library.
 
 Note: image extensions are not supported for Windows container images.
 
diff --git a/content/docs/for-platform-operators/how-to/prepare-build-inputs/create-stack.md b/content/docs/for-platform-operators/how-to/prepare-build-inputs/create-stack.md
